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

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.