"Guidance Needed on QEMU Package Installation for rpi4"

Dear Team,

I am exploring ways to utilize the build-system or an alternative approach to incorporate QEMU virtualization packages on specific hardware platforms. I'm particularly focusing on boards with robust CPU and RAM capabilities, like the rpi4b with 8GB RAM.

While navigating the build-system targets, I noticed that it's feasible to directly integrate these packages for the "Target System (Arm SystemReady (EFI) compliant)". However, this option seems absent for the rpi4, specifically the bcm2711 target.

I confess, my grasp on this topic is not comprehensive, and I find myself a bit perplexed. Whether integrating QEMU into a fresh image or compiling it as an independent package, I'm flexible with the approach.

Your insights and guidance would be invaluable to me.

Warm regards,

Erdem.

You will have to start with changing OpenWrt's qemu packaging to build on ARM in the first place, everything beyond that comes much, much later.

--
The RPi ecosystem is not ARMSR compliant, while it can be made to appear that way to the OS (u-boot+videocoreblobsgalore+tianocore+grub), that would require quite intensive adaptions for OpenWrt.

1 Like

I'm not sure if this changes anything, but the rpi4b appears to be certified as SystemReadyIR:

That is kind of true, but basically still incorrect.

You can configure your sdhc card (respectively $other_boot_medium) to boot from videocore into a tianocore UEFI installation, see e.g. https://github.com/pftf/RPi4 - only this installed UEFI emulation fakes enough of an ARMSR environment to boot a (kind of) generic ARMv8 system. The Raspberry Pi itself is not at all system ready, nor behaves like most other ARM boards (very, very different early boot procedure).

For the RPi, OpenWrt is tailored to provide full disk images for your boot medium, it's not using ARMSR, nor UEFI, but boots directly from the vc-to-arm handover, using the traditional -native- boot procedure you'd also see on Raspbian/ Raspberry Pi OS. These images will not boot in an ARMSR environment.

If you want to boot ARMSR images on the RPi, you'd first have to prepare your sdhc card with an UEFI environment (see the aforementioned link about installing plain Debian) - and then chainload an ARMSR image from a different storage medium (as neither OpenWrt images know about this tianocore installation). You will probably have to customize the ARMSR image further (enabling additional drivers, firmwares, etc.). From there you might investigate how to build RPi specific ARMSR-like images (e.g. including all the RPi specific UEFI stuff into a RPi specific ARMSR-like disk image), but those -while using ARMSR on top- will still need its hardware specific images (with their hardware specific UEFI/ bootloader in front), they aren't very 'generic' at all.

It might actually be quite sensible to switch RPi >=4, rockchip and sunxi to ARMSR subtargets, each with their own (videocore || u-boot) && edk2 boot environment prepended, in order to get a more uniform system environment for ARMv8 images and ease maintenance long term, but that adds another quite complex dependency into the mix (this (videocore || u-boot) && edk2 pre-boot loader would need to be maintained reliably, upstream and for OpenWrt). Done correctly, this could ease development for OpenWrt on ARMv8 significantly - but at the same time it's a major change, relying on a rather fragile foundation - and using code paths shared by few other projects.

--
Personally I'd love to see this, but I don't think OpenWrt would be the prime candidate for this approach - but if there is sufficient impetus, it might succeed, just don't expect it to be a walk in the park or a one-time effort.

1 Like