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

[Aleksandar Markovic]

On Sat, Mar 14, 2020 at 1:28 PM Jiaxun Yang <address@hidden> wrote:
>
>
>
>  ---- 在 星期六, 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?
>

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/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
>