For completeness sake - uboot can also boot EFI binaries, though upstream won’t support GOP video on RK3588, and is also device tree only so no Windows, just Linux and BSDs.
This here is the important next step for ARM SBCs. A working UEFI. Maybe they can get together and standardize something they can work on together. But this whole SD card flashing nonsense needs to stop.
The Rock 5 ITX+ is a nice board. I wish a 1U back panel were available for it.
UEFI does make things a lot easier. It's a shame that this isn't more common for Arm boards, but it's good to see things heading in the right direction.
U-Boot does basic enough UEFI emulation for most use cases. I find that I don't need native UEFI firmware and I can just build U-Boot with UEFI support for most ARM devices.
For example, right now I have an old armhf i.MX6 Wandboard Quad that runs:
U-Boot -> UEFI (with Secure Boot if desired) -> Systemd Boot (or Linux EFI Boot Stub) -> Debian (or other distro)
That same layout should be doable on any U-Boot¹ supported device.
Some arm devices such as the i.MX6, are strict on the placement of their boot firmware where it would interfere with a normal GPT table. One solution to this is to use a special "--move-main-table" option in gdisk² so that the GPT doesn't clobber U-Boot. While technically GPT is optional as long as U-Boot can read your main partition, I still always setup GPT anyway or Systemd Boot complains.
UEFI is a fairly insane spec, but at least it's a fairly complete spec. Following it is preferable to custom nonsense. (Spoken as someone writing a custom non-UEFI bootloader right now)
Whenever I think of how various parts are insane, I'm reminded of numerous cases in different systems in the past where I missed the insane part I am reading about...
There are two fundamental issues in the ARM ecosystem for general-purpose computing: the lack of a standard boot environment and the lack of a reliable device auto-discovery mechanism. Device trees still require a lot of manual intervention. I haven't yet come across an ARM board that can boot a vanilla Debian AArch64 image without extra work. This makes me skeptical about the prospects of ARM in the desktop and laptop space. Is it really worth giving up the messy but standards-based x86 platform in exchange for bespoke ARM solutions?
I find it amazing that ARM hasn't come up with an auto-discovery mechanism for their platforms. They're the only ones in a position to do it, and they've done exactly nothing about it. The device tree junk we have to live with is here to stay.
The U-Boot situation is really no better. Nearly every vendor ships with U-Boot, and it's always, always a fork that never gets updated. ARM should have taken that situation in hand decades ago, too.
i understand why OP did it. But wouldn't it be nice if we took it all the way and just let the OS figure this out? [1]
This is a radical departure from the abstraction-on-abstraction that is implicated by BIOS/UEFI but it feels like it would make the whole architecture not feel like a fossil once it's out of the vendor's hands.
This would mean that every OS would need to make an implementation and feels like wasted effort, however, looking at all the BIOS bugs that i encountered which were OS specific, I have to say I'd rather see OS specific implementations than having to convince your vendor that you hit a bug which happens to be on a OS other than Windows or an ancient redhat patched Linux kernel.
UEFI and ACPI is actually blowback from living in exactly that kind of world.
ACPI even included "compatible interface discovery" to handle the possibility that newer features might confuse older OSes without requiring end user to install newer OS (which they might not want to for various reasons) which used to be the norm. I owned a ~1994 UNIX workstation whose manual came with explicit instructions "you need to use at least this specific emergency upgrade version or the OS won't boot". PPC macs despite OpenFirmware had the same issue, because OpenFirmware had no such "interface discovery" mechanism allowing varying interface according to OS being run - it could only specify compatible device identifiers, which was not enough.
Also, you often need (a bit less today, but still important in server systems) considerable amount of vendor-specific drivers in firmware just to get to the OS.
Of course you can also go the completely other way, and implement always-virtualized environment like some IBM POWER systems, where the CPU wakes up with all of hardware already initialized and instruction pointer pointing to hypervisor scheduler loop.
14 comments
[ 3.3 ms ] story [ 36.9 ms ] threadhttps://docs.u-boot.org/en/latest/develop/uefi/uefi.html
UEFI does make things a lot easier. It's a shame that this isn't more common for Arm boards, but it's good to see things heading in the right direction.
For example, right now I have an old armhf i.MX6 Wandboard Quad that runs:
That same layout should be doable on any U-Boot¹ supported device.Some arm devices such as the i.MX6, are strict on the placement of their boot firmware where it would interfere with a normal GPT table. One solution to this is to use a special "--move-main-table" option in gdisk² so that the GPT doesn't clobber U-Boot. While technically GPT is optional as long as U-Boot can read your main partition, I still always setup GPT anyway or Systemd Boot complains.
¹ https://docs.u-boot.org/en/latest/develop/uefi/uefi.html
² https://www.rodsbooks.com/gdisk/sgdisk.html
Like the entire HII thing, with an UI toolkit!
There is also a specification[2] on how UEFI is to be implemented.
0. https://github.com/riscv-non-isa/riscv-server-platform/relea...
1. https://github.com/riscv-non-isa/riscv-uefi/releases
I find it amazing that ARM hasn't come up with an auto-discovery mechanism for their platforms. They're the only ones in a position to do it, and they've done exactly nothing about it. The device tree junk we have to live with is here to stay.
The U-Boot situation is really no better. Nearly every vendor ships with U-Boot, and it's always, always a fork that never gets updated. ARM should have taken that situation in hand decades ago, too.
This is a radical departure from the abstraction-on-abstraction that is implicated by BIOS/UEFI but it feels like it would make the whole architecture not feel like a fossil once it's out of the vendor's hands.
This would mean that every OS would need to make an implementation and feels like wasted effort, however, looking at all the BIOS bugs that i encountered which were OS specific, I have to say I'd rather see OS specific implementations than having to convince your vendor that you hit a bug which happens to be on a OS other than Windows or an ancient redhat patched Linux kernel.
[1]: https://www.osfc.io/2022/talks/i-have-come-to-bury-the-bios-...
ACPI even included "compatible interface discovery" to handle the possibility that newer features might confuse older OSes without requiring end user to install newer OS (which they might not want to for various reasons) which used to be the norm. I owned a ~1994 UNIX workstation whose manual came with explicit instructions "you need to use at least this specific emergency upgrade version or the OS won't boot". PPC macs despite OpenFirmware had the same issue, because OpenFirmware had no such "interface discovery" mechanism allowing varying interface according to OS being run - it could only specify compatible device identifiers, which was not enough.
Also, you often need (a bit less today, but still important in server systems) considerable amount of vendor-specific drivers in firmware just to get to the OS.
Of course you can also go the completely other way, and implement always-virtualized environment like some IBM POWER systems, where the CPU wakes up with all of hardware already initialized and instruction pointer pointing to hypervisor scheduler loop.