FWIW, there are working and usable ports of EDK2 to the RPi4 (not sure about v5) so you can just throw the image on an attached USB drive. The FSBL then boots t

FWIW, there are working and usable ports of EDK2 to the RPi4 (not sure about v5) so you can just throw the image on an attached USB drive. The FSBL then boots the EDK2 image, which can then load a generic UEFI image like normal. I used that reliably for quite a while; Fedora's generic UEFI aarch64 ISO worked out of the box with no extra fiddling, just burned it to a separate USB stick and booted the installer. There's also some in progress ports of EDK2 to RK3588, and various other boards, though there's often some missing features as they need to be implemented properly in EDK. Really, there's two parts to the whole story, the second being device enumeration, that gets handled by either a device tree blob (DTB) or via ACPI. For UEFI that means that either the UEFI build you're using needs to come with the DTBs pre-configured and embedded inside it so they can be passed to the OS you boot up. Or your device/build will be configured to use ACPI. (The story here is actually weirder than that on some devices where e.g. they have ACPI that requires enumeration, but they expose the actual raw DTBs from that, which you then pass on to the kernel, so you actually have to handle both.) UBoot also has a minimal EFI implementation that you can use, though I don't know how much it implements or if a random generic AArch64 linux ISOs will work with it. Last I checked modern UBoot can even netboot over HTTPS these days, too, so if it could do all the above on a supported board, that would be awesome.