On 24/11/25 08:33, John Paul Adrian Glaubitz wrote:
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.
Great :) I should post something shortly so you can play with.
Regards,
Phil.
