Why Do ARM and RISC-V Systems Use Device Trees Over ACPI?

ARM and RISC-V embedded systems rely on flattened Device Trees rather than ACPI because embedded hardware requires a lightweight, static, and easily customizable way to describe non-discoverable components. While ACPI was designed for standardized x86 PCs and servers with complex firmware, Device Trees offer minimal overhead, simpler bootloaders, and rapid board bring-up for the diverse, resource-constrained world of embedded computing.

The Challenge of Non-Discoverable Hardware

In classical computing, buses like PCIe and USB are self-discoverable. When the operating system boots, it can query these buses to ask what devices are attached, what resources they need, and which drivers to load.

However, most peripherals inside an embedded System-on-Chip (SoC)—such as UARTs, I2C controllers, SPI buses, GPIO banks, and interrupt controllers—are memory-mapped directly into the processor's physical address space. They have no hardware mechanism to announce their presence, base addresses, clock sources, or interrupt lines. The operating system must be told about them externally before it can initialize them.

Static Data vs. Runtime Bytecode

The fundamental difference between a Flattened Device Tree (FDT) and the Advanced Configuration and Power Interface (ACPI) lies in how they represent hardware:

• Device Tree (FDT): A Device Tree is a static, declarative data structure. Developers write human-readable Device Tree Source (.dts) files that describe the hardware topology as a tree of nodes and properties. A compiler (dtc) converts this into a compact binary blob (.dtb), which the bootloader passes to the kernel in memory. The kernel simply parses the tree at boot.
• ACPI: ACPI is not just data; it is an executable specification. It relies on tables written in ACPI Source Language (ASL) that are compiled into ACPI Machine Language (AML) bytecode. The operating system must include a full AML interpreter to execute this bytecode at runtime to discover hardware, manage power states, and handle thermal events.

For an embedded system with tight RAM, flash, and CPU budgets, shipping and running an AML interpreter is unnecessary overhead when a simple static tree suffices.

Hardware Diversity and Rapid Bring-Up

The x86 ecosystem is relatively uniform, dominated by a small number of chipset vendors and standardized PC architectures. ACPI thrives there because firmware vendors can abstract away hardware differences behind a standard interface, allowing a single OS image to boot on any compliant machine.

In contrast, the ARM and RISC-V embedded ecosystems are fragmented across thousands of custom boards, industrial controllers, and consumer devices. Every board may wire pins differently, use different external sensors, or allocate different memory regions. With Device Trees, hardware engineers can describe a new board variant by modifying a few lines in a .dts file and recompiling the .dtb, without needing to write or debug complex firmware bytecode.

Firmware Simplicity and Determinism

ACPI typically pairs with UEFI firmware, which initializes the system and exposes ACPI tables to the OS. Many embedded ARM and RISC-V systems use minimal bootloaders like U-Boot or OpenSBI, which are small, fast, and easy to audit.

Using a Device Tree keeps the bootloader simple: it only needs to load the kernel and the .dtb into memory and jump to the kernel entry point. Because the .dtb is purely data rather than executable code, it also reduces the attack surface and makes boot behavior more deterministic—a critical requirement in safety-critical and real-time embedded systems.

When ACPI Is Used on ARM and RISC-V

While Device Trees dominate embedded systems, ACPI is not absent from ARM or RISC-V. In the server and cloud space, where hardware standardization and OS-agnosticism are priorities, ARM64 servers follow the Server Base System Architecture (SBSA) and Server Base Boot Requirements (SBBR), which mandate UEFI and ACPI. Similarly, emerging RISC-V server platforms are adopting ACPI for the same reasons. For everything else—from microcontrollers running Linux to single-board computers—the flattened Device Tree remains the practical standard.