Re: [PATCH v1] mips/mips_malta: Allow more than 2G RAM

[Jiaxun Yang]

 ---- 在 星期六, 2020-03-14 17:09:08 Philippe Mathieu-Daudé <address@hidden> 撰写 ----
 > Hi Aleksandar,
 > 

 > >>
 > >> This is annoying, because the CoreLV/CoreFPGA core cards only have 4
 > >> DIMM slots for PC-100 SDRAM, and the Memory Controller of the GT–64120A
 > >> north bridge accept at most 256 MiB per SCS for address decoding, so we
 > >> have a maximum of 1 GiB on 32-bit boards.
 > >>
 > >> In 64-bit emulation we use the a 20Kc core, provided by the Core20K core
 > >> card which doesn't use the GT–64120A but the Bonito64. So the model is
 > >> incorrect... The Bonito64 indeed allow more memory.
 > >>
 > >> Maybe it is time to consider that for 64-bit targets, since we are not
 > >> modelling a Malta core board, we can name it the official 'virt' 
 > >> machine...
 > >>
 > > 
 > > Philippe, I almost agree 100% with you wrt last three paragraphs.
 > > (in any case, I know much less than you about details of GT-64120A
 > > and Bonito64, but I trust you).
 > > 
 > > The only area I have a slightly different opinion is that I believe we
 > > should never declare Malta as a virtual board, and try to be within the
 > > boundaries of physical capabilities of real boards, even if in software
 > > (QEMU) we could "enhance" some features.
 > > 
 > > If we want MIPS virtual board, than we should devise a full blown
 > > virtual board, similar to what was already done for MIPS Android
 > > emulator. I really don't want some real/virtual frankenstein in QEMU
 > > upstream just because it is convenient for let's say a particular
 > > test setup.

So probably it's time to work on a "virt" machine. What style would you prefer?
PC-like or SoC style?

In fact we've got two pseudo board (mips, mipssim) for MIPS,
but non of them seems modern enough.

I can launch a Loongson-3 style board after dealing with Kernel code clean-up.

 > 
 > IIUC today all distributions supporting MIPS ports are building their 
 > MIPS packages on QEMU instances because it is faster than the native 
 > MIPS hardware they have.
 > 
 > Since one (or two?) years, some binaries (Linux kernel? QEMU?) are 
 > failing to link because the amount of guest memory is restricted to 2GB 
 > (probably advance of linker techniques, now linkers use more memory).
 > 
 > YunQiang, is this why you suggested this change?
 > 
 > See:
 > - https://www.mail-archive.com/address@hidden/msg10912.html
 > - 
 > https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2019-January/004844.html
 > 
 > I believe most of the QEMU Malta board users don't care it is a Malta 
 > board, they only care it is a fast emulated MIPS machine.
 > Unfortunately it is the default board.

Yeah. That's the truth.

 > 
 > However 32-bit MIPS port is being dropped on Debian:
 > https://lists.debian.org/debian-mips/2019/07/msg00010.html

mipsel (MIPS 32-bit Little Endian) is still alive. I believe Debian won't give 
up it as long as i386
still exist.

 > 
 > Maybe we can sync with the Malta users, ask them to switch to the Boston 
 > machines to build 64-bit packages, then later reduce the Malta board to 1GB.
 > (The Boston board is more recent, but was not available at the time 
 > users started to use QEMU to build 64-bit packages).
 > 
 > Might it be easier starting introducing a malta-5.0 machine restricted 
 > to 1GB?
 > 
 > > 
 > > Aleksandar
 > > 
 > >>>            exit(1);
 > >>>        }
 > >>> +#endif
 > >>>
 > >>>        /* register RAM at high address where it is undisturbed by IO */
 > >>>        memory_region_add_subregion(system_memory, 0x80000000, 
 > >>> machine->ram);
 > >>>
 > >>
 > >>
 > > 
 > 
 > 


--
Jiaxun Yang