RPi3 VS edk2

Projects like Tow-Boot, a distribution of U-Boot, provide a nice boot menu and allow you to boot the "generic ARM" ISOs that are usually just UEFI. On the Raspberry Pi 3 and 4, you can put Tianocore EDK2 onto the SD card and boot any UEFI image, including Windows 10 or 11 for ARM.

The approach I used is very different from the conventional setup. Most setups will rely on the default boot loader stack that the Raspberry Pi uses, but this project instead relies on the UEFI images provided by https://github.com/pftf/RPi3/ and https://github.com/pftf/RPi4 instead. There are two reasons for this.

> Isn't a faster boot what everybody wants?

I’ll rather have slow boot and proper UEFI support so I can boot any vanilla ARM64 Linux distro (Debian proper), instead of images/distros which have been crafted to be device-specific (Raspbian).

I boot this thing once every second month at most. I honestly couldn’t care less about boot-times.

Luckily for me, there are solutions to my problem too ;)

https://github.com/pftf/RPi3

It's been manually implemented for many devices - the Renegade Project and Raspberry Pi 3 implementation do exactly this.

Odd to see using UEFI to NetBoot not considered an option at all.

It should eliminate the timing-bug and leave you in a more reliable (and scriptable!) pre-boot environment. What more do you need?!?

Both the RPi3 and 4 can be UEFI booted, so this is definitely a real-world option.

Links:

- https://github.com/pftf/RPi3

- https://github.com/pftf/RPi4

For the modern server/desktop and even laptop, that's also no bad thing. It is somewhat ridiculous that UEFI bioses, internally, still boot in 16-bit real mode and have to do all the steps your bios bootloader used to do to set up a 64-bit environment ready to go: https://github.com/tianocore/edk2/blob/edc6681206c1a8791981a..., https://github.com/tianocore/edk2/blob/edc6681206c1a8791981a..., https://github.com/tianocore/edk2/blob/edc6681206c1a8791981a...

Why not just start the CPU in "long mode", which is what everyone is using it for, in the first place?

These newer ARM processors support 32-bit code at EL0 only (userspace). That seems like a reasonable approach for x86 as well and the freebsd announcement has this to say:

> There is currently no plan to remove support for 32-bit binaries on 64-bit kernels.

So for the moment, you can run 32-bit applications just fine.

Download this UEFI shell and place it in the BOOT subfolder

They could have at least informed TianoCore. the affected code in edk2 hasn't been modified in 2 years.... https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Library/BaseBmpSupportLib/BmpSupportLib.c

I have half fixed it.. Using this solution: https://github.com/tianocore/edk2/discussions/4662

You need only EDK2 and some lööps.

What is the difference between this and https://github.com/tianocore/edk2

From there you'll need to get an EFI Shell. There may be one built into your system, but you can also get one here from Tianocore (aka, the people mostly making UEFI). Neither this EFI Shell nor Keytool.efi (the thing you need to load the keys) are signed of course, so you will need to turn off SecureBoot to continue. From there just run Keytool with your new keys, turn back on SecureBoot, and move on with your life.

I had the same issue. What fixed it for me was compiling my own OVMF.fd file from here and using that to boot. The version of OVMF that shipped with fedora was broken for me for some reason.