Re: qemu-system-sh4eb build has something hinky in the ethernet

Re: qemu-system-sh4eb build has something hinky in the ethernet

[Philippe Mathieu-Daudé]

On 1/9/25 09:47, Geert Uytterhoeven wrote:

> On Sun, 24 Aug 2025 at 20:40, Rob Landley <rob@landley.net> wrote:
>> Anyway, this works fine on little endian, but the qemu-system-sh4eb
>> build has something hinky in the ethernet, I haven't tackled it myself
>> because I don't know whether the device emulation or the driver is
>> what's missing an endian swap. (I don't want to fix it the "wrong way",
> 
> That is using sh_eth, right?
> 
> Last time I tried booting a big-endian ARM kernel on R-Car M2-W,
> the Linux kernel booted fine, except for Ethernet.  So sh_eth is definitely
> not big-endian clean.

qemu-system-sh4{eb} only emulates the R2D+ board, which AFAIK
provides ethernet via a RTL8139 over PCI. While old, RTL8139
is very tested and expected to have endianness well handled.

> 
> [*] I didn't have a big-endian userspace.
> 
> Gr{oetje,eeting}s,
> 
>                          Geert
> 

64mb limitation of qemu-system-sh4 board

[Philippe Mathieu-Daudé]

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...

> The sh4 build in toybox's mkroot works fine for this (binaries 
> at https://landley.net/bin/mkroot if you'd like to try). It also works 
> with -hda but I think can only provide _one_ of those so you have to 
> partition it, which I generally don't bother.
> 
> qemu-system-sh4: -hdb hdb.img: machine type does not support 
> if=ide,bus=0,unit=1
> qemu-system-sh4: -hdc hdc.img: machine type does not support 
> if=ide,bus=1,unit=0
> qemu-system-sh4: -hdd hdd.img: machine type does not support 
> if=ide,bus=1,unit=1
> 
> (You'd think it could at least do -hdb since that's just master/slave on 
> the same controller but the qemu guys never bothered to wire it up. 
> Anyway, I stick a 4gb ext3 image in /dev/sda so I have lots of scratch 
> space for builds because building on network filesystems tends to have 
> strange permission hiccups for me, or rm -rf fails because nfs didn't 
> _really_ delete a file that's still open but just renamed it, or...)
> 
> Anyway, this works fine on little endian, but the qemu-system-sh4eb 
> build has something hinky in the ethernet, I haven't tackled it myself 
> because I don't know whether the device emulation or the driver is 
> what's missing an endian swap. (I don't want to fix it the "wrong way", 
> and don't have big endian physical hardware lying around to try it on. I 
> moved _again_ at the start of the month, just unpacked the storage space 
> with those boxes into my sister's garage last weekend, but haven't 
> sorted very far yet.)
> 
> In theory I could use a swap _file_ instead of swap partition, and thus 
> a single /dev/hda would be plenty without partitioning it, but I haven't 
> tried? (When the network doesn't work I can't upload the results of the 
> build in an automated fashion anyway, so...)
> 
> You can speed this build process up further by hooking up distcc to call 
> out to the cross compiler, which lets you keep about -j3 busy before the 
> preprocessing, data transmission, and linking become the bottleneck. (I 
> mean ./configure is _always_ the bottleneck but that's because autoconf 
> is really stupid and largely pointless.) I had that distcc setup working 
> (and even automated) back in https://landley.net/aboriginal/about.html 
> and can help anyone interested fish the relevant bits out of those old 
> build scripts.
> 
>>> If you rely on suid/sgid *foreign* binaries, that's where the
>>> problem lies.
>>
>> Yes. People expect to be able to run foreign-arch chroots.
>> Entire buildd setups partly rely on this, too…
> 
> A qemu-system vm doesn't require any weird translation. As far as the 
> kernel running in the emulator is concerned, everything is entirely 
> native. :)
> 
> Rob
> 

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

[John Paul Adrian Glaubitz]

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

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

[Philippe Mathieu-Daudé]

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.