HN Distilled

Essential insights from Hacker News discussions

Installing UEFI Firmware on ARM SBCs

Original Article

Hacker News Discussion

This discussion revolves around the adoption and benefits of UEFI for ARM System-on-Chips (SoCs), contrasting it with existing solutions like U-Boot and older firmware standards like Open Firmware. A major underlying theme is the fragmentation and proprietary nature of the ARM ecosystem, which hinders a unified and user-friendly booting experience comparable to x86 PCs.

The Need for a Standardized Boot Environment on ARM

A core sentiment is that ARM's current approach to booting is overly fragmented and proprietary, making it difficult for users to install and boot standard operating systems without significant device-specific effort. The experience on x86 PCs, with their standardized boot processes (BIOS/UEFI), is often held up as the ideal that ARM should strive for.

  • "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." - BadBadJellyBean
  • "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." - userbinator
  • "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?" - dingi
  • "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." - general1465

UEFI as a Solution for ARM Boot Simplification

Many participants see UEFI as a crucial step towards simplifying the boot process on ARM devices. The ability to boot standard OS installers directly, move drives between machines, and reduce reliance on vendor-specific disk images are highlighted as key advantages.

  • "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 than needing to get a specific disk image and dd it to an SD card." - bpye
  • "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." - johnklos
  • "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." - raggi
  • "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." - iod
  • "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)." - raggi

U-Boot's Role and Capabilities

U-Boot is frequently mentioned as the current de facto standard bootloader for many ARM devices. While it's seen as a powerful tool, there's discussion about its limitations, particularly concerning its UEFI support and the need for device-specific configurations (like Device Trees) compared to the more standardized UEFI/ACPI approach.

  • "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." - bpye
  • "U-Boot does actually have some support for GOP Videoš. It's rather new, so it might be worth revisiting with your specific devices." - iod
  • "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" - raggi
  • "iod: 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." - iod
  • "what areas of u-boot do you find much simpler than edk2?" - raggi

The Role of ACPI and Device Trees

The discussion touches upon the trade-offs between ACPI (Associated Configuration and Power Interface) and Device Trees (DTBs). While ACPI on x86 aims to abstract hardware details, making it easier for OSes to boot, DTBs are often seen as necessary on ARM to describe hardware specifics, but this also leads to fragmentation and manufacturer dependency.

  • "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." - raggi
  • "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." - raggi
  • "UEFI doesn't solve the problem of peripheral discovery, for example. SBSA standard in the server realm seems to have it figured out. phendrenad2: UEFI+ACPI+PCIE+XHCI pretty much covers everything you could want." - heavyset_go and phendrenad2
  • "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)." - jeroenhd
  • "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." - jeroenhd
  • "yusyusyus: 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." - yusyusyus

Criticisms and Alternatives to UEFI

While UEFI is generally seen as a positive development, some users express reservations about its complexity and size, preferring simpler or more established standards.

  • "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." - phendrenad2
  • "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)" - inamberclad
  • "Ugh. Instead of propagating UEFI further, we as an industry should be promoting and improving IEEE 1275 Open Firmware." - eschaton
  • "stephen_g: Why would we base modern computer firmware around a 1994 standard, on which work had mostly stopped by 1998?" - stephen_g
  • "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." - shrubble

The Potential for OS-Driven Hardware Discovery

A more radical suggestion is to shift the responsibility of hardware discovery and initialization from firmware entirely to the operating system, thereby sidestepping the complexities of both UEFI and Device Trees.

  • "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." - hbogert
  • "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." - hbogert

Standardization Efforts and Compliance

The Arm SystemReady Compliance Program is mentioned as an effort to standardize ARM server booting, implying a similar need for broader standardization across all ARM devices. RISC-V's adoption of UEFI for server platforms is also noted as a positive step for standardization in that area.

  • "That is what the Arm SystemReady Compliance Program was supposed to achieve. Unfortunately not many manufacturers are following it yet" - robotnikman
  • "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." - snvzz