Although we can get aur/edk2-avmf (extracted from fedora rpm though), I’m wondering why we don’t have extra/edk2-armvirt for ARM, while on x86_64 we have that package compiled.
It may be a little niche, as there aren’t that many ARM boards capable of running ARM VMs, especially most boards have BIG.little cores which makes it harder to run VMs.
But in fact for RPI4/CM4, there are 8G RAM version, which is definitely capable of running VMs.
In fact, I run my ARM VM to do some development with 64K page size, on my CM4 (8G ram, and running NVME using that x1 lane).
Thus the edk2-virtarm package would definitely help. (And maybe better to disable the debug output)
If doing kernel development, kernel crash is unavoidable, and you don’t want crash your board every time some stupid bugs are introduced.
Thus no matter if the host support UEFI, I still need the VM to have some way to boot.
And I just choose the precompiled edk2 firmware.
It’s also possible to boot VM directly using kernel+initramfs, but personally I prefer to compile kernel and its modules inside the VM other than passing it out of the VM.
edk2-armvirt seems to require the aarch64 crossbuilding toolchain ( aarch64-linux-gnu-gcc (make)) to build. And changing it to use regular gcc seems to not be a trivial change for a very niche usecase.
Er… in reading back, sorry for my question. I guess at the time I misread your post. But glad you are going to work with the rpi4 uefi. I have been using it with grub with good results.
I look forward to hearing about what you discover.
It turns out that, building just using local gcc is completely fine.
I have built the RPI4 UEFI target without any problem.
The steps I’m using is the same one provided by UEFI RPI4 workflow, except just using local gcc.
The building speed is even acceptable without using distcc, on CM4 bare metal.
I just need to create a PKGBUILD for RPI4 and armvirt target then.
The existing Archlinux PKGBUILD is a little different as it uses release source package, while I’m using git version.
But it looks like the release version is in fact a little fast as it avoid the tons of git repos.
BTW, since I have upstream Uboot running for RPI4 without any problem, I can test the built firmware by chainloading from Uboot.
Thus I’m even considering making Uboot-raspberry as a dependency so that we don’t need to pull all those RPI4 specific firmwares, but rely on uboot-raspberry to do everything.