From: "Philippe Mathieu-Daudé" <philmd@linaro.org>
To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
Rob Landley <rob@landley.net>, Thorsten Glaser <tg@debian.org>,
Michael Tokarev <mjt@tls.msk.ru>,
QEMU Developers <qemu-devel@nongnu.org>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>,
Rich Felker <dalias@libc.org>,
linux-sh@vger.kernel.org
Subject: Re: 64mb limitation of qemu-system-sh4 board
Date: Mon, 24 Nov 2025 09:48:56 +0100 [thread overview]
Message-ID: <ea61d8b0-8307-4796-85af-04113c13deeb@linaro.org> (raw)
In-Reply-To: <91b74af52f69c360a27269ab3145eeb377ef816a.camel@physik.fu-berlin.de>
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.
prev parent reply other threads:[~2025-11-24 8:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <aKi6IWVX2uIlGKnw@seger.debian.org>
[not found] ` <Pine.BSM.4.64L.2508230023030.21591@herc.mirbsd.org>
[not found] ` <6abe2750-5e2c-43a1-be57-1dc2ccabdd91@tls.msk.ru>
[not found] ` <119d5858-52f4-ce1b-9ee7-9615ce2054b9@debian.org>
[not found] ` <79f14fef-123f-4938-b069-10f07e7d0405@landley.net>
[not found] ` <CAMuHMdXZNroJF=s8gXj_vguGPGjUvgLu7w2PZxQg9tcHtSkNyg@mail.gmail.com>
2025-11-24 7:18 ` qemu-system-sh4eb build has something hinky in the ethernet Philippe Mathieu-Daudé
2025-11-24 7:31 ` 64mb limitation of qemu-system-sh4 board Philippe Mathieu-Daudé
2025-11-24 7:33 ` John Paul Adrian Glaubitz
2025-11-24 8:48 ` Philippe Mathieu-Daudé [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ea61d8b0-8307-4796-85af-04113c13deeb@linaro.org \
--to=philmd@linaro.org \
--cc=dalias@libc.org \
--cc=glaubitz@physik.fu-berlin.de \
--cc=linux-sh@vger.kernel.org \
--cc=mjt@tls.msk.ru \
--cc=qemu-devel@nongnu.org \
--cc=rob@landley.net \
--cc=tg@debian.org \
--cc=ysato@users.sourceforge.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).