According to the pre-launch page, MNT Reform Next will provide UEFI as OS loading interface, using EDK2.
While I am not strongly against EDK2, I am curious if you have considered and evaluated UEFI on U-Boot, since it may reduce the R&D cost if the SoM already support U-Boot, I guess.
A major difference would be the number of supported features. EDK2 should be enough to implement Server Base Boot Requirements (SBBR), while U-Boot’s UEFI support is intended to implement Embedded Base Boot Requirements (EBBR), a subset of the UEFI specification. According to Arm, “Windows Server, Windows 11, Windows IoT Enterprise, VMware ESXi, Amazon Linux, and Oracle Linux require SBBR” and “Fedora, Debian, openSUSE, SLES, and Ubuntu support EBBR.”
As SBBR seems basically a superset of EBBR, EDK2 will support more operating systems and hypervisors than U-Boot. On the other hand, U-Boot will provide a slim firmware that is enough to boot Debian and some popular distributions.
May I ask, if you are not strongly against, are you somewhat against? And if, what is the reason for that?
I always found u-boot troublesome to work with, with for example deploying new kernels. Although that has improved with extlinux.conf support - if the vendor enabled that option - these days UEFI support is a hard requirement for me to buy a board.
I’ve noticed UEFI on U-Boot but then one again relies on implementation by the vendor.
An advantage of UEFI over u-boot is that it abstracts away the difference between x86, aarch64 and risc-v
I had personally avoided EDK2 for its large footprint. Moreover, the quality of module varied. However, the code has been reorganized and polished in recent years, so I hope the problems have been addressed more or less.
Indeed.
Agreed. Note that, however, it is a comparison of UEFI vs. U-Boot’s own bootloader interface, not EDK2 vs. U-Boot as UEFI implementation.
It implements just enough to run grub and the Linux EFI stub, anything that could be omitted is not included.
In particular it does not support EFI variables. If you are installing an OS using EFI support you need to do it as if you were authoring a DVD - no integration with the firmware, just dropping the bootloader in the default location and hoping the firmware picks it up on next boot.
It looks like they jump through multiple hoops to include the EFI variable code from EDK2 in u-boot. It’s likely not missing anything other than mature, cross-device support for this feature.
That said the u-boot native EFI support is enough for booting a Linux distribution, it’s designed exactly for that. It works quite well in a scenario like Orange Pi Zero where the board includes a bootable SPI NOR memory big enough to store u-boot. Then u-boot can be flashed into the SPI NOR, it provides the EFI interface and the device tree. Copying random Linux distribution image that is set up for EFI boot on a SD card and inserting it into the board gets an OS running.