Installing UEFI Firmware on ARM SBCs
interfacinglinux.com
interfacinglinux.com
When the topic comes up some people express a lot of hatred for uefi (mostly users rather than implementors) but where it’s implementors the ms style APIs and so on are largely the center of it IME, and that’s not really an easy fix when it’s already spec’d. Sometimes there are concerns about size, but slimmed down deployments are common in the socs that ship already - perhaps standardizing on what that slimmed down thing is might help too. May also assuage some of the other concerns of excessive runtime services (which seems rare, but I get the existential concern)
People also rarely think of the complexity inherent in having an open platform where owner of a device does not need to build/acquire a custom OS build for their machine, and thus see cases of "enough to run something they care about" and think that's enough.
[0] I still remember BIOS config menus and PCI card option roms that effectively had stripped down windows 3.0 in them, or an approximation of it. And how it meant presence of Intel PCI hardware RAID controller in certain server meant I needed a full crash cart or remote KVM to fix RAID config.
https://www.arm.com/architecture/system-architectures/system...
SBSA standard in the server realm seems to have it figured out.
Manufacturers kind of suck at actually describing the hardware on their motherboards and hacks and workarounds are very much required to provide a usable experience on many machines.
Unless manufacturers stop lazily copy-pasting their DSDTs with minor changes, we should probably hope for a better solution.
On PC, the main check against it is Microsoft because they at least try to make vendors care with "Designed for Windows" and the like and their test suites.
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)
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://en.wikipedia.org/wiki/GUID_Partition_Table#Features
Honestly, my opinion after all this was that UEFI is pretty convenient and nice, and I'm glad U-Boot has its own implementation, even if it isn't fully grown yet; UEFI for the executable spec with a DTB for bringing up the SOC with nothing else was nicer than a lot of embedded boot flows I've handled.
¹ https://u-boot.org/blog/seeing-is-believing-video-support-la...
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.
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.
A common secondary piece is ACPI, which isn’t strictly mandatory, but when you provide both UEFI and ACPI then you can skip the whole dtb mess. Sadly ACPI isn’t the simplest of approaches, as it’s encoded in a way that requires executing bytecode in a stack machine. There are real and valid security concerns that come with this, but there are also big advantages- the abstraction generalizes over a lot of what would otherwise be specialization that has to be carried around in the bootloader and OS.
Uboot implements a subset of the uefi spec, but typically is used where there is no ACPI type configuration, with the gap filled by a combination of dtbs and vendor forks or patches (often before upstreaming, which sometimes never happens).
Depending on how deep your relationship is with all of this, you may live with uboot as a plain binary blob from a board vendor, in which case whatever version they formed and options they chose may bring various constraints or challenges doing anything novel like booting an alternative kernel or distro.
Typically a more complete uefi and ACPI system will be able to get much further in the boot process with far less hardware specialization, a lot of operating systems can boot very far with this combo even if they’ve never seen the specific hardware topology before.
Uboot upstream has a lot of implementations for a lot of hardware targets. There isn’t really so much of a central place for uefi implementations
Just look on Android phones - i.e. Lineage OS, special Android build for every phone. That would not be necessary if booting process would the same.
UEFI makes it so you can boot your Unix OS, like NetBSD, without needing to have specific bootblocks that are tailored to the given machine. You can move drives between Arm machines, too. Much simpler.
Or something 3D-printed...
Or did you mean the height of the ports on the backside itself is too large for 1U already?
The metal back panel is standard. It'd be nice to have one that's made to fit 1U cases.
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...
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.
Something as simple as handling evolution in available steps in backlight control can require updated OS build on OpenFirmware.
ACPI was built for a world where a newly released computer had to still boot properly a system that predated it, which is major source of complexity in its bytecode.
In the past it meant you were unable to even boot the install media, these days it often means something might boot but ends up stuck because it can't initialize for example input devices so you can't load extra driver - which you first need. For every OS you want to boot.
EDIT: In fact, I have a funny example. On my laptop, out of laziness, vendor didn't include necessary ACPI data for sound to work properly.
Why?
Because for windows they could just ship a minimal INF file that declared a "driver" for the speakers which was actually just collection of parameters for a generic driver. As we say in Poland, "finished, time for Counter Strike".
On Linux working sound required patching drivers to include potentially dangerous settings as "quirks", including things like capacitance of capacitors connected to amplifiers.