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 _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
