Time for a Qemu port

Get a QEMU version working – and (as I say every single time this comes up) for the love of god just drop IOMD and Tungsten already.

Out of interest, has anyone recently tried a Bookworm Pi OS with 32-bit userland and 64-bit kernel on a Pi 3 or 4? Does that support the ‘Linux port’ at decent enough speed?

Out of interest, has anyone recently tried a Bookworm Pi OS with 32-bit userland and 64-bit kernel …

Partially answered by Chris Gransden over on https://www.riscosopen.org/forum/forums/1/topics/18861?page=3#posts-144806

I think I have expressed this before:
It is not that hard to do a port to QEMU (virt target). We have done ports to various hardware and getting RISC OS up to something we recognize is very quick. ( after that a hefty year long or more to get it up to release quality)
ARM generic timers is not an issue.

Happy Christmas!

It is not that hard to do a port to QEMU (virt target). We have done ports to various hardware and getting RISC OS up to something we recognize is very quick. ( after that a hefty year long or more to get it up to release quality)

Not that hard? Clearly a year’s effort! ;-)

I think a large barrier to anyone starting off on that particular path is the uncertainty regarding whether anyone else is already committed to the job. I, for one, do not want to waste time replicating others’ efforts. Coordination is needed.

I had RISC OS running under a virtual Pi in QEMU around 10 years ago. The only issue I recall was sound wasn’t working, but it was usable.

Microsoft got involved at the time and implemented most of the original Pi hardware, I believe it was related to their work towards a Windows ARM port.

Is there any particular reason that Linux RO has a problem with sound output – is it like the Qemu problem?

When using a bootloader that supports most hardware and not reinvent the wheel everytime porting takes 2 weeks up to desktop. My i.MX8 port proves that, not public.

@ Jon

I had RISC OS running under a virtual Pi in QEMU around 10 years ago.

Was this RO 5 or previous versions using that ARM26 patch that was then never accepted main stream?

AFAIR, even Linux needed some minor tweaks to boot on a QMEU emulated RPi2 (or 3). Also, extreme care needs to be made in configuring the emulated environment.

One very useful feature of running RISC OS on QEMU is the debugging feature that could be associated wiht GDB on the host, I have used this feature a tons of time to track issues down with the Linux kernel and other customs ones. It even allows step-in execution, fantastic to debug kernel modules.

However the Rpi2 AFAIR< is not fully emulated, so there should be needs for some adaptation as mentioned by Michael. AFAIR only the ARM26 patch booted RISC OS without changes… but I could remeber wrong.

@ Theo,

Is this work available anywhere?

AFAIR (it has been a while!), to boot RISC OS on QEMU what you need is to create an SD Image that has the right size for QEMU way of dealing with image FS and then use the following syntax (I remember QEMU complaining a lot about the ROOL Image, so I had to fiddle quite a bit to get that sorted). Which makes me wonder if anyone here has actually ever tried to debug this whole process…

In any case, below an exaple of configuration, I have long lost my original one, but this one should be close enough (use it as a starting point):

sudo qemu-system-aarch64 -M raspi3b \
     -cpu cortex-a53 \
     -dtb ./dtbs/bcm2710-rpi-3-b-plus.dtb \
     -m 1G -smp 4 -serial stdio \
     -usb -device usb-mouse -device usb-kbd \
     -device usb-net,netdev=net0 \
     -netdev user,id=net0,hostfwd=tcp::5555-:22 \
     -drive if=sd,media=disk,id=drive0,file=sdcard.qcow2,discard=unmap,detect-zeroes=unmap \
     -kernel ./RISCOS.IMG

Be careful when creating sdcard.qcow2 (again, I remember QMEU complained for a long time!)

RISCOS.IMG should be the IMG we build normally for the Pi, I don’t remember hacking it, but I could remember wrong (ie, I have quite a bunch of custom builds here, so apologies if I remember wrong).

This one I remember being important: ./dtbs/bcm2710-rpi-3-b-plus.dtb (it the original Pi3 dtb file)

As a side note and project (one of my too many!) I started to write a DTB parser library for RISC OS HAL, that should make everyone’s life easier when completed.

I’ve not managed to get any output from current RISC OS ROM for Pi using qemu-system-arm -M raspi2b or qemu-system-aarch64 -M raspi3b -dtb bcm2710-rpi-3-b-plus.dtb . Maybe it does need modifying. Booting a linux kernel with the same qemu-system-aarch64 seemed to proceed OK (to the point of panicing because I didn’t supply a disk image).

As well as Jon A, David F has had one working in the past https://www.riscosopen.org/forum/forums/10/topics/6271

Hummm that line in the forum link you’ve provided:

qemu-system-arm -cpu arm1176 -m 256 -M raspi2 -kernel RISCOS.IMG

This will not work now (and by a while actually), first it’s been a while that the -M for RP2 is raspi2b and second raspi2b requires smp. However, to get closer to the above you can try with something that has no smb support like this one:

sudo qemu-system-aarch64 -M raspi1ap \
     -cpu arm1176 \
     -m 512M -smp 1 -serial stdio \
     -usb -device usb-mouse -device usb-kbd \
     -device usb-net,netdev=net0 \
     -netdev user,id=net0,hostfwd=tcp::5555-:22 \
     -drive if=sd,media=disk,id=drive0,file=sdcard.qcow2,discard=unmap,detect-zeroes=unmap \
     -kernel ./RISCOS.IMG

Note: RPi1 will have the limitation of max 512MB RAM…

With this syntax (and also the previous one) you can access the QEMU compat_monitor0 which allows you to control and check what’s going on.

But I guess older releases of RISC OS may be more suitable if the HAL in the past did less (I am guessing here).

qemu-system-arm -cpu arm1176 -m 256 -M raspi2 -kernel RISCOS.IMG

I did also try going back to using QEMU 6.2 from that time with that command line, but no luck.

Am currently trying to use my own build-from-git QEMU and one 8.2.0 ish from the interweb (Windows, at the mo, for convenience).

Just wondering.. the -kernel option assumes something that can run out of the box. I also wonders about load address. How is this going to work? Is the elf blobs built into qemu? If someone can hookup a serial port (virtual mapped to ip) it would be interesting if you can print from HAL. That would be my first step when going rpi and in fact any qemu target.

I also wonders about load address.

can you not specify the load address with something like addr=0×8000 ??

I’m pretty sure it’s hard coded. Here’s what I needed to do to get the BIOS loaded at 0.

The file hw/arm/raspi.c has to be changed to load the kernel (-bios kernel7.img) at the bottom of RAM (emulating real firmware with kernel_old=1 in config.txt).

#define FIRMWARE_ADDR_2 0 // 0x8000 /* Pi 2 loads kernel.img here by default */
#define FIRMWARE_ADDR_3 0 // 0x80000 /* Pi 3 loads kernel.img here by default */

I’d like a simple but more powerful option like

—initial-ram FILE:ADDR’

Just wondering.. the -kernel option assumes something that can run out of the box. I also wonders about load address. How is this going to work?

In general terms the -kernel option loads a linux-like image (.IMG), it’s optional, in theory (but on some versions of QEMU this kinda got a little broken IIRC) you can boot just with the SD card image as I showed above, the problem with the Raspberry Pi emulation is that it has it’s own way of booting from the SD card, so building a RISCOS.IMG is actually (probably) easier than try to emulate the full boot on the Pi, which includes loading firmware etc…

Here is an example of how to use it with Linux with more details:

-kernel /some/where/vmlinuz -initrd /some/where/initrd -append "root=/dev/sda2 ro vga=...blah blah"

So, it can load a bz Image basically or a .bin file too.

When used in the context of ARM32 architecture, this option emulates a basic bootloader’s essential functions. It performs the minimal necessary tasks typically handled by a guest bootloader: loading the kernel into the guest’s memory, configuring various registers according to the requirements of the Linux kernel for startup, and setting the guest CPU’s program counter to the kernel’s entry point.

Now, the RISCOS.IMG for the RPi should start at 0×8000 itself IIRC. So, it should be fine used with the -kernel option. However, without passing a dtb file to QEMU I believe things will not be mapped as on the real Pi, so RISCOS shouldn’t initialize correctly. Which is probably why on David F. post it didn’t go beyond UtilityModule.

What I am not sure of is how people managed to make it pass the initial boot, given that is the most tricky part to get right… in my case I have never managed to get to the desktop.

HTH

I’m pretty sure it’s hard coded.

Yes, but it’s based on the arch.

[edit]
whoops sorry you added the “per architecture” bit.
[/edit]

The downside of edit!

A thought about RISC OS 64 (and QEMU)

The SoC in the RPi 5 still runs Aarch32 code, but only in user mode. This may well mean you could run user applications directly, within a 64-bit RISC OS;

In theory, it may be possible to emulate a full 32-bit core in QEMU, but get QEMU to run 32-bit user code ‘natively’. If QEMU couldn’t do this, then a custom version of RISC OS sitting on a hypervisor such as Xen might allow it;

Even if not possible, it may be possible to emulate a ‘standard’ RISC OS system (ARMv8AArch32), and develop a 64-bit extension to RISC OS. Down the line, we could end up with emulated RISC OS (with hardware acceleration for moving windows about etc), and slowly port it over to 64-bit.

Such an approach could also provide the opportunity to keep an emulated 32-bit compatibility layer even on pure ARM64 CPUs.

Even if the above is not possible, the a QEMU port could be a good foundation to do a graded transition to AArch64 for RISC OS