Since you brought it up, the exact thing I said was: "UEFI is the only officially standardised way of booting aarch64." UEFI is a well defined standard. I am not aware of any other ARM booting way that is based on a similarly well defined standard.
Not really - there seems to be a perfectly well working Tianocore UEFI for Pi 3:dickon wrote: ↑Sun Oct 13, 2019 7:34 pmIf Redhat and (by extension, as they're the same thing) Centos only support UEFI, then that's their lookout. Debian are clearly more flexible. The Pi's bootloader doesn't support it -- UEFI is a mess, and a nightmare to implement -- so you'll need to use something that it does support: that, I'm afraid, is zImage.
Correct. The Pi is *not* a UEFI-based aarch64 dev board. So why you think you should be able to treat it as such is beyond me.I cannot grab a generic distro installer or distro kernel and expect it to "just work", the way I can expect it to work with an UEFI based aarch64 dev board
And u-boot has implemented EFI for some years now.
u-boot has supported exposing EFI since at least 2016, and I accept that u-boot is a defacto standard. I have an armv5tel Dreamplug running u-boot in EFI mode and loading grub-efi, which takes over from there.dickon wrote: ↑Sun Oct 13, 2019 9:25 pmI'm rejecting your assertion that UEFI is the only standardised way of booting an aarch64 kernel. That's simply wrong: lots of other platforms use U-Boot to do the same thing, without UEFI: I can name several SBCs which do this. UEFI is a standard that's most often used on x86 machines and the odd aarch64-based server. I have never met an ARM-based SBC which supports it. It's wild overkill. They all, with the exception of the Pi, use U-Boot.