UEFI and Device Trees on Non-ACPI Hardware

On non-ACPI hardware architectures such as ARM and RISC-V, combining UEFI with vendor-neutral Device Trees bridges the gap between standardized platform initialization and flexible hardware description. While the Unified Extensible Firmware Interface (UEFI) standardizes the pre-boot environment, secure boot process, and operating system loading, Device Trees describe the platform's non-discoverable hardware components without relying on proprietary firmware layers. This article explores how vendor-neutral Device Trees operate alongside UEFI to decouple operating systems from specific silicon designs, streamline distribution maintenance, and establish a consistent, standards-based boot architecture on non-ACPI platforms.

The Challenge of Non-ACPI Hardware

Traditional x86 architectures rely on Advanced Configuration and Power Interface (ACPI) tables to enable operating systems to discover and manage hardware devices, power states, and system configurations. Modern embedded, edge, and mobile processors—particularly those built on ARM, RISC-V, and MIPS architectures—often feature non-discoverable hardware. In these systems, memory-mapped I/O (MMIO) registers, clocks, interrupt routing, and power domains cannot be probed dynamically over a bus like PCIe or USB.

Implementing full ACPI on these systems can be complex, bloated, and impractical for cost- or resource-constrained boards. Historically, this led to fragmented, vendor-specific board files or hardcoded kernel forks, making it difficult to run generic operating system distributions across different hardware designs.

Defining the Roles: UEFI vs. Device Tree

To solve hardware fragmentation, modern embedded standards divide responsibilities between UEFI and Device Trees:

  • UEFI (Unified Extensible Firmware Interface): Standardizes platform initialization, boot variables, boot services, and runtime services. It exposes a consistent programmatic interface to OS loaders (such as GRUB or systemd-boot) and implements security features like UEFI Secure Boot.
  • Device Tree (DT): Provides a structured, static data representation of the hardware topology. Stored in a compiled format (.dtb), it details memory maps, peripheral addresses, interrupt assignments, and driver bindings that the OS kernel requires to initialize drivers for non-discoverable devices.

In this architecture, UEFI initializes core resources (such as DRAM and standard storage devices), locates the compiled Device Tree blob, applies any needed runtime fixups or overlays, and passes both the system control and the Device Tree to the OS bootloader or kernel.

The Importance of Vendor-Neutral Device Trees

For a Device Tree to function effectively with standardized firmware, it must be vendor-neutral. A vendor-neutral Device Tree adheres to the official Devicetree Specification and uses upstream, standardized hardware bindings rather than proprietary properties tailored to a single vendor's customized kernel.

  1. Single-Image OS Support: When Device Trees use standard bindings, an operating system distributor (like Debian, Fedora, or openSUSE) can build a single, generic kernel binary that works across dozens of boards from different manufacturers, matching drivers solely on standardized compatible strings.
  2. Long-Term Maintainability: Proprietary Device Trees often force developers to maintain out-of-tree kernels. Vendor-neutral trees allow systems to run mainline, upstream kernels, drastically reducing the cost and security risks of maintaining outdated board support packages (BSPs).
  3. Clean Separation of Concerns: Firmware vendors focus on platform initialization and hardware abstraction, while OS vendors focus on kernel and user-space features, minimizing the need for coordination between board makers and software maintainers.

Industry Standardization: EBBR and SystemReady

The synergy between UEFI and Device Trees is codified by industry standards, notably the Embedded Base Boot Requirements (EBBR) specification and the Arm SystemReady IR (IoT Ready) compliance program.

EBBR establishes that platforms are not required to implement ACPI to be considered standard-compliant; instead, they can provide a lightweight UEFI interface alongside an EBBR-compliant Device Tree. This standard guarantees that if a system satisfies these requirements, any standard Linux, BSD, or real-time operating system with generic Device Tree and UEFI support will boot out of the box.

Conclusion

On non-ACPI hardware, vendor-neutral Device Trees and UEFI represent a complementary pair rather than competing technologies. UEFI brings procedural consistency to system initialization and OS loading, while vendor-neutral Device Trees provide the structured, OS-agnostic data required to control non-discoverable hardware. Together, they eliminate the need for fragmented, single-use firmware ecosystems and provide non-ACPI platforms with the plug-and-play boot predictability traditionally reserved for enterprise servers and x86 PCs.