UEFI on U-Boot vs. EDK2

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.

2 Likes

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

Genuinely curious.

1 Like

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.

1 Like

This is very interesting input. At this time I think we’ll support both U-Boot and EDK2 on RK3588.

2 Likes

What about retrofitting UEFI to existing boards?

I’m not aware of a list of UEFI implementations.

AFAIK there is no UEFI support for any i.MX or Layerscape platform so no support for i.MX8MQ, i.MX8MPlus and LS1028A.

Rockchip RK3588 has pretty good support: GitHub - edk2-porting/edk2-rk3588: EDK2 UEFI firmware for Rockchip RK3588 platforms which could work for the RCORE RK3588

Raspberry Pi too: GitHub - pftf/RPi4: Raspberry Pi 4 UEFI Firmware Images for the RCM4 with Rasperry Pi

edit: I found GitHub - pftf/edk2-platforms: EDK II sample platform branches and tags and edk2-platforms/Platform/NXP/LS1043aRdbPkg at master · pftf/edk2-platforms · GitHub for an LS1043A

1 Like

Hm, so will we use a downstream fork of EDK2 for each SoC? The situation is not ideal, to be honest…

I only plan to do an official image with EDK2 for RK3588, not other platforms.

1 Like

The u-boot EFI support is very rudimentary.

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.

1 Like

Thanks for the info.

Hm, the page mentions using OP-TEE for EFI variables but it lacks something, right?

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.

1 Like

If it runs u-boot you can have EFI on it.

The question is what is the practical benefit.

When both u-boot and OS are on the same medium the interface between u-boot and OS is an implementation detail.

1 Like