Installing UEFI Firmware on ARM SBCs(interfacinglinux.com)
interfacinglinux.com
Installing UEFI Firmware on ARM SBCs
https://interfacinglinux.com/2025/08/25/edk2-uefi-for-the-rock-5-itx/
52 comments
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.
There is a UEFI standard in some of Arms specs, but it’s only mandatory for the server class IP atm. Some soc vendors are starting to adopt it even in non-server class but it’s slow. My feedback to an Arm devrel a few years ago was exactly this though: you need to provide a consistent standard boot path that also helps OS authors with enough bootstrap that debugging is less of a crapshoot every single time. I hope some progress is made on pushing that down the stack.
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)
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)
I don't understand the hatred for UEFI. It seems like people get irrationally disgusted when they find out that it's a big complex standard with lots of extraneous stuff that almost nobody cares about (on desktop, that is). Just give me text, a framebuffer, file system access, and a memory map. It's not difficult. Sadly I think that no one will be happy until there is some equally-overwrought spec on the ARM side.
Hrrm. File system. WTF do I need to have a VFATed EFI partiton somewhere, when I'm not using VFAT, or NTFS at all?
People have rose-tinted glasses for BIOS, have no idea of all sorts of hidden complexity that was involved in it, assumptions, etc. Or all the broken ideas that vendors put into BIOS-era firmware [0].
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.
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.
[deleted]
That is what the Arm SystemReady Compliance Program was supposed to achieve. Unfortunately not many manufacturers are following it yet
https://www.arm.com/architecture/system-architectures/system...
https://www.arm.com/architecture/system-architectures/system...
ARM SoCs have always been very proprietary and fragmented, and until/if something like the x86/PC comes along I don't think just UEFI is enough. The PC flourished because of many de-facto standards, and not just the BIOS. Unfortunately the companies these days seem to love their proprietariness, so I don't think something like that will happen again.
It's this. UEFI doesn't solve the problem of peripheral discovery, for example.
SBSA standard in the server realm seems to have it figured out.
SBSA standard in the server realm seems to have it figured out.
UEFI+ACPI+PCIE+XHCI pretty much covers everything you could want.
In theory yes, in practice ACPI isn't always a great solution (as can be seen by the many lines of kernel logs about broken DSDTs on my motherboard).
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.
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.
There is no a better solution because "manufacturer loads broken description table" does not care for the technology of the description table, just that manufacturer borked it.
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.
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.
Actually, I take that back. ACPI is fine except for the DSDT system, which should be nuked from orbit. These lazy PC hardware manufacturers keep pushing "please bro just let us run arbitrary code on your machine bro". This goes back to VGA BIOS (ugh). There's no need for it, other than the fact that it makes hardware vendor's lives slightly easier. Definitely something to avoid when designing a new interface.
Arguably, "full" UEFI implementation mandates use of ACPI, which solves discovery of components that don't have self-discovery mechanism to use (including finding the very roots of various self-discovering buses)
PC flourished, because IBM lost control, what is happening with ARM is basically what every other 8 and 16 bit home computers used to be.
And part of the lost control was emulating IBM PC enough that software that ignored sanity and did weird things to hardware or assumed certain behaviours worked even on clones and most importantly, upgrades
Ugh. Instead of propagating UEFI further, we as an industry should be promoting and improving IEEE 1275
Open Firmware.
Why would we base modern computer firmware around a 1994 standard, on which work had mostly stopped by 1998?
Because it’s actually still better than the alternatives, an actual open standard, and very lightweight despite also being extremely functional.
I could see myself supporting OpenFirmware which is a fraction of the size and complexity of UEFI and has a very limited attack surface. You could literally boot up a SPARC machine across the Internet with OFW in the mid 1990s, if you’re worried about functionality. And for configuring your system it’s simple and straightforward. The OLPC laptops used it, so it’s already somewhat proven on ARM.
And a major issue with OpenFirmware was that like other comparable interfaces from its time it required you to release a new OS version to support a new machine if it used different devices.
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.
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.
I’m not sure I’m following you; wouldn’t a driver solve that issue? You don’t have to release a new OS build for a new PCI card being released…
Backlight is a trivial example.
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.
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.
Since you ask: because it's the only firmware that has its own song, that's why.
https://www.youtube.com/watch?v=b8Wyvb9GotM
https://www.youtube.com/watch?v=b8Wyvb9GotM
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.
https://docs.u-boot.org/en/latest/develop/uefi/uefi.html
https://docs.u-boot.org/en/latest/develop/uefi/uefi.html
U-Boot does actually have some support for GOP Video¹. It's rather new, so it might be worth revisiting with your specific devices.
¹ https://u-boot.org/blog/seeing-is-believing-video-support-la...
¹ https://u-boot.org/blog/seeing-is-believing-video-support-la...
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.
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.
Serious question: what things does it make easier? Other than booting windows. I don't know anything about it except that it seems much more complicated than u-boot.
Having UEFI in some form means you can just boot your preferred Linux installer and install to disk, much as you would for an x86 device, rather that needing to get a specific disk image and dd it to an SD card.
UEFI is one step in many missing steps PCs take in the boot process that ARM SoCs in general don't.
what areas of u-boot do you find much simpler than edk2?
I have not developed using EDK2/UEFI - that's why I'm asking
They don’t have exactly the same coverage. UEFI provides a standard set of APIs, some optional, some mandatory. It also specifies a boot path via gpt and efi system partitions.
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
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
Then you can have ARM64 Linux which boots on anything what has UEFI, like today having x86/x64 Linux which boots on everything what has x86 processor inside under expectation that the mother board has BIOS/EFI/UEFI as well.
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.
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.
maybe one of the BSP people can give more info, but i believe that it comes with e.g. ACPI and such to avoid device trees.
No idea about Windows. No interest, either.
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.
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.
OpenBSD, too. I haven't tried FreeBSD on EFI on arm64 yet, but FreeBSD has done EFI on amd64 since version 10.
That backside is looking rather full. Nothing which a few blocks of styrofoam from packaging residue, maybe some cardboard or other plastics, and adhesive metal tape, and/or some super/hot-glue couldn't easily fill.
Or something 3D-printed...
Or did you mean the height of the ports on the backside itself is too large for 1U already?
Or something 3D-printed...
Or did you mean the height of the ports on the backside itself is too large for 1U already?
The ports would easily fit in a 1U case, as would everything else, including the fan and heat sink.
The metal back panel is standard. It'd be nice to have one that's made to fit 1U cases.
The metal back panel is standard. It'd be nice to have one that's made to fit 1U cases.
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:
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
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://docs.u-boot.org/en/latest/develop/uefi/uefi.html
² https://www.rodsbooks.com/gdisk/sgdisk.html
With eMMC can’t you just stick u-boot in a eMMC boot partition? Then the entire eMMC user area can be used without risk of clobbering u-boot.
You of course can, assuming that your hardware configuration supports eMMC with dedicated hardware boot partition(s). Some devices, like the one I used in my example, in its default configuration the hardware is actually booted from a MicroSD card as a regular mmc block device; which is quite common in hobbyist targeted SBCs. In those cases you have to be cognizant of boot loader firmware locations if you want a GPT partition table, as most user guides and sample disk images for these systems assume MBR style partition table reserving only the first block. Followed by system-specific boot blob(s) at the required offset location and then a fat32 partition somewhere thereafter with the OS. If the boot firmware blob starts before the 34th¹ block with 512-byte sectors blocks, then for setting up GPT, you move the main GPT table to after the firmware; otherwise you can just allocate the first partition space as reserved protected area in GPT for the firmware so that it doesn't get written to as a reference for future repartioning.
¹ https://en.wikipedia.org/wiki/GUID_Partition_Table#Features
¹ https://en.wikipedia.org/wiki/GUID_Partition_Table#Features
Does it provide ACPI and the RuntimeServices fully enough to operate as SBSA system?
U-Boot is implementing ACPI, yes, there was something at FOSDEM this year about it for ARM64 machines. QEMU can apparently now boot an arm64 virt machine with only ACPI tables and no device tree. This is all very recent. When I was working on a vague equivalent of systemd-stub last year as a fun exercise in UEFI development, I settled on U-Boot for UEFI and QEMU (but with virtualized device tree). I can't remember the specifics of what's unsupported by RuntimeServices when I was working on it. I'm like 99% certain it's not enough for SBSA compliance, at least.
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.
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.
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...
Like the entire HII thing, with an UI toolkit!
Like the entire HII thing, with an UI toolkit!
Note on RISC-V, the RISC-V Server Platform Specification[0] requires UEFI always.
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
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
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?
Hear, hear.
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 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.
[1]: https://www.osfc.io/2022/talks/i-have-come-to-bury-the-bios-...
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-...
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.
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.
[deleted]