RISC OS on QEMU
Pages: 1 2
Jan Rinze (235) 368 posts |
It’s been a long time since QEMU was considered as a target/test platform for RISC OS. I’m sure many here have been thinking about this but gave up because of the amount of work involved or simply not having the skills/knowledge.. |
Michael Grunditz (8594) 245 posts |
I am interested. I think that take the virt target platform and adjust it as needed. I say that bringing up riscos on it wouldn’t be that hard. I prefer the virt target before raspberry pi. My plan is to use qemu on genode to get a as small as possible emulation. I will receive the new QuartzPro from Pine64 soon. Since one of the cpus is 64bit only it would be the perfect platform for 64/32 bit experiments. The little cpu is 32 bit capable if I remember right. |
Jan Rinze (235) 368 posts |
@Michael: indeed. I think that a simple start could be to support serial port first. That way we get the output from the RISC OS startup. Also I think UEFI support could help a lot if we want to have early graphics output. UEFI can cater for a framebuffer and pass on the info. |
Michael Grunditz (8594) 245 posts |
I don’t think graphics will be a problem. It is after all it is emulated hw so the documentation is good. Getting riscos up to debug terminal is very easy. The virt target uses or can use GIC interrupts that we already handle. |
Charles Ferguson (8243) 427 posts |
The original 32bit versions of RISC OS Select were all run on QEmu as one of the primary targets, with the interrupt management modules targetting the original integrator machine. At that time the handling of flags was significantly poorer and there needed to be a number of patches to cater for the poor behaviour of QEmu’s emulation. However that was the primary reason that I knew that RISC OS Pyromaniac would be able to use Unicorn (which is based on QEMu) – its ARM emulation was sufficient to run anything that RISC OS might do. And so, yes, that’s what RISC OS Pyromaniac uses for its ARM emulation. Far from having given up, after over 3 years of continuous work, RISC OS Pyromaniac runs modules and applications sufficient to run the desktop, on Windows, Linux and macOS. It runs on local machines, and in the cloud. Its I/O facilities cover accelerated video (local, via VNC and physical hardware devices), keyboard, mouse, sound, speech synthesis, IPv4 and IPv6 networking, shared filing system, access to disc and CD images, serial port, parallel port emulation, GPIO, IIC, and RTC. Many of these are shared with the host, but can be isolated or placed into debug modes to enable easier debugging. The ability to trace instructions or blocks of instructions is provided easily through the emulation system, and the entire system can be instrumented to help diagnose problems. In short, QEmu was considered and used long ago by myself for RISC OS development, and is used every single day in my own development and use of RISC OS Pyromaniac. It is available for all to use through the RISC OS Build service, and as a demo system at shell.riscos.online. The entire purpose of RISC OS Pyromaniac is to make it easy to debug and to try out new things, for which it has been entirely successful. |
Michael Grunditz (8594) 245 posts |
I am fully aware of your efforts and the benefits of it. Very impressive! As you may know I have been tinkering with unicorn myself up to running basic and loading modules. I don’t want to reinvent the wheel. I want to be able to run a rom as it is. From my understanding much of RISC OS is done in your python framework, right? My idea is and has been for a while, is to run riscos on top of a thin micro kernel. Using python for that purpose isn’t doable. But using a emulator that hooks up to IO is possible. Qemu needs some new features , essentially to expand the pass through pci functionality. I want to be able to have drivers inside the RISC OS rom, in addition to the host system. But this is just my idea, I have no problems discussing it and change my mind. I don’t, as stated above ,want to compete with pyromaniac since I think it is perfect for the functionality you describe. I will start working on it when my obligation with other projects is done. Sorry for grammar errors etc , English is not my native language. |
Jon Abbott (1421) 2640 posts |
I used QEMU back in 2013/14 after Microsoft added enough extensions to emulate a Pi. I was using it during the initial development of the ARM3 JIT on ARMv5 in ADFFS and at that point it was running RO5 with everything except sound if I recall correctly. Surely they’ve added a full Pi VM by now, so RO won’t require a dedicated HAL? Sadly I’ve not checked on their progress for many years. |
Jan Rinze (235) 368 posts |
Okay, i have been fiddling on Asahi Linux to see if I can trick RISC OS on ARMLinux to use qemu instead of the native 32 bit. (The M1 on Apple doesn’t run32 bit.) the results are weird, to say the least. RISCOSmark 2.04 (30-Dec-2015) by Richard Spencer 2003Comparison with RiscPC SA 202MHz running RISC OS 4.02 800×600,256 MOS Utilities 5.29 (28 Apr 2021) Test Benchmark I can run !DOOM in 3840×2160 32bpp smooth.. this requires a bit of thinking.. |
Jan Rinze (235) 368 posts |
ROMark5 in 4k (almost full screen) RISCOSmark 2.04 (30-Dec-2015) by Richard Spencer 2003 MOS Utilities 5.29 (28 Apr 2021) Test Benchmark not sure what’s going on here but the memory transfer thingy probably gives a better idea of the CPU performance. |
Jan Rinze (235) 368 posts |
Benchmark superscalar test reveals the real performance! *superscalar |
Jan Rinze (235) 368 posts |
Compared this to ‘native 32 bit’ on an NVidia AGX: and we can see that it performs really well. |
Michael Grunditz (8594) 245 posts |
The reason why I choose the virt target is that it can grow. The rpi targets are static. But I am open for ideas! |
Michael Grunditz (8594) 245 posts |
The RISC OS on Linux effort is amazing and if you can live with Linux it is the best choice. |
Jan Rinze (235) 368 posts |
Technically the RISC OS on Linux effort turns RISC OS into a single application. To work properly a small patch is done for qemu by Timothy Baldwin. (for RISC OS itself he did an enormous effort making changes to many parts and add a HAL that supports all that) The patch is here: https://github.com/TimothyEBaldwin/RISC_OS_Linux_Source/blob/Linux2/Unix/LinuxSupport/qemu_swi.diff He designed it so you can run RISC OS on any Linux platform. This prompted me to think that I just needed the build scripts to understand that the M1 requires qemu. In priciple the qemu-arm binary can be compiled for just about any platform (probably including Android) and requires the front-end application to have a graphics screen, mouse keyboard etc. |
Michael Grunditz (8594) 245 posts |
Don’t mix up the system emulator with the user mode one. |
Jan Rinze (235) 368 posts |
It uses the user mode version, not the system emulator. I think it should be possible to create some micro linux distribution that will run everything inside a qemu-system-arm. i.i.r.c. SDL has the capability to run on the framebuffer device and thus not require X at all. |
Michael Grunditz (8594) 245 posts |
I would say using X11/Wayland is better since it usually hw accelerated. |
Jan Rinze (235) 368 posts |
X11/Wayland inside a qemu-system-arm probably will not be hardware accellerated. |
Michael Grunditz (8594) 245 posts |
It depends. X11/Wayland is not inside the emulator it is the base for emulator display. If used clever you can have accelerated rects drawing etc. I don’t know how sdl does draw. Best bet is to write a display driver without sdl. |
Theo Markettos (89) 919 posts |
For what it’s worth I tried to boot on the Pi QEMU emulation about a year ago. After spending some quality time in QEMU’s gdb, I ran into a couple of issues:
They wouldn’t be hard to work around by patching QEMU, but then everyone would have to build your patched version rather than just get it from their package manager. Better would be a HAL that uses VirtIO and a generic platform model, so will boot without having to pretend to be specific hardware. Although there might still be some unexpected snags there. It would also help if RISC OS supported device tree, so it could discover the hardware it had available, which might change from one boot to another of an emulator. |
Jan Rinze (235) 368 posts |
@Theo: did you manage to run RISC OS on QEMU with patches for QEMU? I would not mind using a patched QEMU if that is the way to test for now. |
Theo Markettos (89) 919 posts |
I didn’t try patching QEMU: the general philosophy being it’s easier to upstream patches in RISC OS than it is in QEMU, particularly for things which are really deficiencies in RISC OS rather than omissions from the QEMU emulation. I’m thinking of platforms like MacOS and iOS, where there’s already a packaged QEMU (an app called UTM), and it would be a nicer UX to have people just download the app and boot a RISC OS image than have them compile their own patched QEMU. In particular you don’t have to jump through the ‘developer’ notarisation hoops, you can just download and install UTM. While #2 above is perhaps something QEMU should implement and could perhaps be upstreamed, #1 is just RISC OS being peculiar, so arguably both should be patched. (I have a patch for #1 somewhere, but it needs thoroughly testing to ensure it doesn’t break real Pis, and I ran out of time to do that). Without a working timer implementation RISC OS got no further, so I couldn’t say if these were the only blockers. Probably not, I would guess. |
Jan Rinze (235) 368 posts |
Was a nice idea. Probably not feasible in any way but hey, a man can dream.. |
Michael Grunditz (8594) 245 posts |
Fixing timers should be quite easy. The way it is done in recent roms is the soc timers. There are good docs on the generic timers so I can’t see why we couldn’t use it. |
Theo Markettos (89) 919 posts |
The way Jeffrey proposed was to rework RISC OS to have a better timer interface. That work seems to have stalled, and SoC timers are something QEMU doesn’t seem to implement because it supports lots of different SoC and doesn’t want to have a different timer implementation for each. So the backup plan would be to use the ARM generic timers in a HAL module – I think you could make something that presents the kind of ‘countdown and interrupt when zero’ timer that RISC OS is expecting (I’m not sure if the timebase changes with CPU frequency – would need to workaround if so). I don’t think it’s hard, just that nobody has done it and tested it (and I ran out of time to work on anything here). |
Pages: 1 2