On Sat, Mar 14, 2020 at 1:28 PM Jiaxun Yang <jiaxun.y...@flygoat.com> wrote: > > > > ---- 在 星期六, 2020-03-14 17:09:08 Philippe Mathieu-Daudé <phi...@redhat.com> > 撰写 ---- > > 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? >
It is time, agreed. Let's explore multiple alternatives, analyze pros and cons, and not rush into conclusions. There are several important factors to take into account: presence of kernel and QEMU support for involved devices, target users, other virtual machines in QEMU, relation to the general QEMU architecture, available time resources, etc. > In fact we've got two pseudo board (mips, mipssim) for MIPS, > but non of them seems modern enough. > They are terribly outdated, true. > I can launch a Loongson-3 style board after dealing with Kernel code clean-up. > Absolutely! You would be welcomed. Yours, Aleksandar > > > > 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/debian-mips@lists.debian.org/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 >
