Hi Philippe, On Mon, 2025-11-24 at 08:31 +0100, Philippe Mathieu-Daudé 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. And > > > > it has never been designed for this usage. What we had for 15+ > > > > years, unnoticed, is like `chmod u+s /bin/sh`, which is never > > > > supposed to be used like this. > > > > > > Perhaps, but there’s shades in between. > > > > I find qemu system emulation a LOT less problematic. > > > > For sh4 I boot qemu-system-sh4 and then use a network block device to > > provide swap (so the 64mb limitation of the board isn't a limiting > > factor). > > 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). > > 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. > > 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 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
