Re: 64mb limitation of qemu-system-sh4 board

John Paul Adrian Glaubitz <[email protected]> Mon, 24 Nov 2025 08:33:11 +0100
Newsgroups gmane.linux.debian.ports.mips
Message-ID <91b74af52f69c360a27269ab3145eeb377ef816a.camel__7112.51036716334$1763969652$gmane$org@physik.fu-berlin.de>
Hi Philippe,

On Mon, 2025-11-24 at 08:31 +0100, Philippe Mathieu-Daud=C3=A9 wrote:
> On 24/8/25 20:07, Rob Landley wrote:
> > On 8/23/25 09:19, Thorsten Glaser wrote:
> > > > There are no alternatives - qemu is unique in this regard.=C2=A0 An=
d
> > > > it has never been designed for this usage.=C2=A0 What we had for 15=
+
> > > > years, unnoticed, is like `chmod u+s /bin/sh`, which is never
> > > > supposed to be used like this.
> > >=20
> > > Perhaps, but there=E2=80=99s shades in between.
> >=20
> > I find qemu system emulation a LOT less problematic.
> >=20
> > For sh4 I boot qemu-system-sh4 and then use a network block device to=
=20
> > provide swap (so the 64mb limitation of the board isn't a limiting=20
> > factor).
>=20
> The R2D+ board uses a SH7751 SoC, which memory controller can access
> 7 external banks. This board has its boot flash on CS#0, a FPGA on CS#1,
> 64MB of SDRAM on CS#3, a SM501 display on CS#4 and some ISA bus on CS#5;
> leaving CS#2, and CS#6 available. CS#2 can have SDRAM, while CS#6 only
> SRAM (not really a difference in emulation).
>=20
>  From QEMU side, we could fill these empty slots with 2*64MB of RAM, so
> the machine could use up to 192MB. But then it is up to the guest to
> use it.
>=20
> Looking at Linux i.e. it seems to hardcode the RAM base/size in
> arch/sh/include/asm/page.h, so we'd need changes there to use more
> memory, which seems unlikely to get for a such old board...

I'm the upstream kernel maintainer for arch/sh and I would be happy to make
the necessary changes to get the Linux kernel support more than 64 MB in
QEMU.

Adrian

--=20
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913