---- 在 星期六, 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?
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/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
