EFI / SystemReady support for OpenWrt on arm64

[Mathew McBride]

Hi all,

For some time now I have had a pull request open to add EFI boot support
to the armvirt target:
https://github.com/openwrt/openwrt/pull/4996

I recently did some revision to ensure sysupgrade does not affect any system firmware, files (e.g U-Boot ubootefi.var) and/or partitions already residing on the storage medium.

https://github.com/openwrt/openwrt/pull/4996#issuecomment-1524683095

I am just wondering if anyone has any significant objections that would
stop this pull from being merged? (after I fix any current conflicts)

23.05 has branched and there is already a pull request for kernel 6.1 on
master ( https://github.com/openwrt/openwrt/pull/12705 ), which will force
a revision of this pull request.

I am willing to do the work for both branches but would like some
indication of any required changes first.

Updating to 6.1 might take a few days of effort.

Some of our users (Ten64) would really love it to get merged in so they
can use buildbot images and packages for their hardware.

As the topic of UEFI on Arm64 also came up tangentially recently[1], I
thought I would provide a reason why this is happening and the benefits of
doing so.

Why EFI boot?
Firstly, this discussion only concerns boards with some kind of mass
storage (eMMC, SATA or NVMe). It is not a replacement for boards purely
booting out of NOR or NAND.

EFI is the main boot method for Arm SoCs complying with the "SystemReady"
specifications.
As new Arm platforms come closer to the capabilities of conventional
compute platforms, it provides a more standard way of booting operating
systems using familiar components (e.g GRUB, EDKII or U-Boot).

While the higher-end specifications (SR) resemble conventional x86 servers
(e.g must use ACPI), the lower end specification (IR) has relaxed
requirements allowing Device Tree etc and providing facilities for devices
that work entirely on a single eMMC/SD.

See more here:
https://www.arm.com/architecture/system-architectures/systemready-certific
ation-program

The current pull request happily works on boards ranging from imx8 up to
hyper-scale Arm servers (Ampere Altera, AWS Graviton).
The embedded levels (ES and IR) already have hardware based on various
vendors (Marvell, NXP, Raspberry Pi, Rockchip, Socionext, Xilinx)
certified.

The newer version of the IR Spec (2.0) facilities firmware updates /
capsules, secure boot and an alternative mechanism to update EFI variables
when the firmware is unable to do so (e.g U-Boot currently does not
provide SetVariable services).

This also ties in with a recent development in U-Boot called "Standard
Boot"[2] which provides a more 'solidified' boot process vs the script
driven 'distroboot'. EFI boot is supported out of the box with Standard
Boot.

(As a vendor who has shipped U-Boot with distroboot for a while now, I can
say that Standard Boot is quite an improvement. I spent a lot of time
trying to smooth over bumps in the distroboot system)

We (Traverse) have been 'shipping' this OpenWrt port on our Ten64 target
for quite a while now, and are now working with others to expand the hardware
support to as many devices as possible.

There are vendors interested in switching to this as their 'reference'
OpenWrt solution but need to see this merged and in the main tree first
before putting resources into it.

[1] -
http://lists.openwrt.org/pipermail/openwrt-devel/2023-March/040790.html
[2] - https://u-boot.readthedocs.io/en/latest/usage/cmd/bootdev.html

Best Regards,
Matt