Device Tree Ownership Is Moving Up Into Firmware

If you build embedded Linux products, the device tree is something you keep in the kernel. The source sits under arch/arm64/boot/dts/, the DTB is built alongside the kernel, and when the hardware changes you patch the kernel tree. On a growing set of Arm platforms that is no longer where it lives: the firmware owns the description of the board, and the kernel is handed one at boot like any other UEFI payload. A firmware-provided device tree is not a proposal. It is what the Arm SystemReady Devicetree band already requires of certified platforms.

This is not happening everywhere at once, and nothing forces a shipping product to move. But the direction is set by a certification programme with published requirements rather than by a trend, which makes it a planning question rather than a prediction. And the reason to pay attention is commercial rather than architectural: it changes which team owns the board description, which release cadence it follows, what your update mechanism has to do, and who owns a hardware-description defect when a later kernel release fails on the same board.

What the specification actually requires

Two documents do the work. The Embedded Base Boot Requirements (EBBR) specification defines the firmware interface; its revision history records 2.4.0 dated 11 March 2026, and section 2.1 states that the document uses version 2.11 of the UEFI specification. Arm’s SystemReady Devicetree band then defines what a platform must satisfy to claim compliance:

• Hardware implements the Base System Architecture (BSA).
• Firmware implements the subset of UEFI defined by EBBR.
• Firmware by default provides a device tree suitable for booting mainline Linux.
• Firmware can be updated using the UEFI UpdateCapsule() service.
• At least three Linux distributions must be able to boot, install, and run storage medium tests through the UEFI boot flow.

EBBR states the rule carefully. Its guiding-principles section, which the document notes is not a formal part of the specification, says EBBR “does require the system description to be supplied by the platform, not the OS”. The normative requirement is narrower: a compliant system provides one, but not both, of an ACPI table or a device tree through the EFI Configuration Table, and a platform supporting both must present only the selected one to the OS loader. The device tree itself must be a flattened DTB of format version 17 or higher, carry a /chosen node with a stdout-path property, and sit in memory of type EfiACPIReclaimMemory.

The firmware-provided device tree in the boot path

The mechanism is simpler than the specification text suggests. On an Arm SoC, Trusted Firmware-A runs first — BL1 from mask ROM, BL2 authenticating and loading images, BL31 providing PSCI and other runtime services — and hands control to U-Boot as the non-secure BL33 payload, passing the DTB address either in a register or inside a Transfer List structure designed for firmware handoff. Vendor stacks vary in the details — the stage that authenticates and loads images may be U-Boot SPL or a vendor blob rather than TF-A BL2 — so treat this as the shape of the flow rather than a description of every board.

U-Boot then acts as the UEFI implementation. Its minimal UEFI support comes from CONFIG_EFI_LOADER, and before loading an EFI executable it installs an EFI_DTB_TABLE_GUID entry into the EFI Configuration Table recording where the DTB lives.

The arm64 Linux kernel can present itself as a PE/COFF executable, so it loads as an EFI application. The EFI stub walks the configuration table to find the device tree, allocates a new flattened device tree that describes EFI reserved memory, calls ExitBootServices(), and only then enters the kernel’s normal entry path. A UEFI boot flow does not force ACPI, which is a common misunderstanding: under EBBR, passing a device tree to the EFI payload remains the usual choice. The consequence is worth stating directly: once firmware supplies the DTB through this path, firmware is no longer only a launcher. It is part of the kernel compatibility contract.

None of this is experimental. The pieces are in U-Boot and in mainline Linux, and Yocto layers exist for deploying the Architecture Compliance Suite image and running the distribution installation tests as part of a normal build.

Why firmware update is the bigger change

For many products the device tree is not the disruptive part. Firmware update is.

EBBR section 2.7.4 puts it plainly: “EBBR platforms are required to implement either an in-band or an out-of-band firmware update mechanism.” In-band means the firmware on the application processor updates itself, which requires UpdateCapsule(), authenticated updates in the Firmware Management Protocol capsule format, an EFI System Resource Table describing every image updatable in band, and capsule delivery as a file on a mass storage device. Out-of-band shifts the work to something else, such as a management controller, and then neither UpdateCapsule() nor an ESRT is required.

Security sits alongside this rather than inside it. UEFI Secure Boot is optional in EBBR. The Devicetree band recommends the Boot Security Requirements specification, and where that is not possible it still requires that capsule payloads for system firmware are digitally signed and that images are verified by digital signature before an update is applied. This is the cost of moving the board description upward: whoever holds the description must also hold a way to correct it in the field.

How to tell where your board already stands

You do not need a certification report to find out whether your platform booted through a UEFI flow. On a running target, three checks cover most of it.

raghu@techveda.org:~$ ls /sys/firmware/efi
config_table  efivars  esrt  fw_platform_size  runtime  runtime-map  systab

raghu@techveda.org:~$ dmesg | grep -i "efi:"
[    0.000000] efi: EFI v2.100 by Das U-Boot

raghu@techveda.org:~$ ls /sys/firmware/devicetree/base/ | head -5
#address-cells
#size-cells
aliases
chosen
compatible

If /sys/firmware/efi is absent, the kernel was not started as an EFI application, and its device tree came from the boot command rather than from a configuration table. If /sys/firmware/efi/esrt is missing, that is a strong sign no in-band capsule update path is being exposed through the UEFI runtime interface — though a platform that updates its firmware out of band is not required to publish an ESRT at all. The exact dmesg line varies with the firmware and the UEFI version it reports; what matters is that the line exists and names the implementation.

The unresolved part: compatibility across kernel versions

The gap is stated in the specification itself. Attached to the principle that the platform supplies the system description, EBBR carries a footnote acknowledging that platform compatibility rules for device tree platforms “are not well defined or documented”, and that the authors are working on the problem in parallel with the specification. A device tree provided by firmware is only useful across kernel versions if there is an agreed rule about what a kernel may assume, and that rule is unfinished.

• The operating system can still override. U-Boot’s generic distro boot path keeps a mechanism for an extlinux.conf entry to supply a DTB that takes precedence over the copy the hardware provides.
• Compliance is uneven, including at Arm. Arm’s own automotive reference software stack documents its non-alignments against the Devicetree band, and the list includes no support for capsule updates and missing device tree schemas for components not yet upstreamed.
• Most shipping BSPs are still on the old path. A vendor kernel with an in-tree DTB and a bootloader that jumps straight into it keeps working, and nothing here deprecates it.

What it changes for a product team

The practical consequences are ownership questions more than technical ones.

• Ask who owns the firmware component in your organisation, because it is often not the team that owns the kernel, and the board description now lives there.
• The work of board bring-up changes. Instead of patching a device tree into the kernel tree, you produce a description your firmware will ship, validated against the device tree schema tools.
• Your update design has to cover firmware, not only the root filesystem. Many teams have a solid A/B root filesystem story and no equivalent for the bootloader.
• The return is the three-distribution test. A platform that passes it can install a general-purpose distribution, which is a real reduction in the amount of custom image work a product needs.

The skill that gains value spans both sides of the handoff: what the firmware must hand over, and what the kernel does with it. That is the ground our Embedded Linux and Yocto training covers, because bootloader, firmware and image build are one problem seen from three places.

For a product already shipping, the reasonable position is neither to rewrite the boot flow this quarter nor to ignore the change: an in-tree DTB keeps working. For a new hardware programme, two decisions are worth making before the silicon is fixed — who owns the board description, and whether firmware can be updated in the field. Both are inexpensive to settle now and expensive to retrofit.

— Raghu Bharadwaj

Key takeaways

• The Arm SystemReady Devicetree band requires firmware to provide, by default, a device tree suitable for booting mainline Linux, and to be updatable through UEFI UpdateCapsule().
• EBBR 2.4.0 permits exactly one system description, ACPI or device tree, delivered through the EFI Configuration Table in DTB format version 17 or higher.
• The boot path already exists in shipping software: TF-A hands off to U-Boot, U-Boot installs the DTB pointer as a configuration table entry, and the Linux EFI stub picks it up.
• Firmware update is the harder requirement for most products, because signed capsules and an ESRT are architecture decisions, not features to add late.
• The unfinished part is admitted in EBBR itself: device tree platform compatibility rules are not yet well defined.

Frequently asked questions

Does a UEFI boot flow mean my board has to use ACPI?
No. EBBR supports both ACPI and device tree, and passing a device tree to the EFI payload is still the usual choice on embedded Arm platforms. What EBBR requires is that only one of the two reaches the operating system loader.

Where does the kernel get the device tree when firmware provides it?
The firmware installs an entry in the EFI Configuration Table pointing at the DTB in memory. The Linux EFI stub walks that table, allocates a new flattened device tree describing EFI reserved memory, and calls ExitBootServices() before the kernel’s normal startup path begins.

Is Secure Boot required for SystemReady Devicetree compliance?
UEFI Secure Boot is optional in EBBR. The Devicetree band recommends the Boot Security Requirements specification, and where that is not adopted it still requires firmware update capsules to be digitally signed and images to be verified by digital signature before an update is applied.

Should I move my existing product to a firmware-provided device tree now?
Not as a retrofit. Existing bootloader-to-kernel flows with an in-tree DTB continue to work and are not deprecated. The decision matters most for new hardware, where the questions to settle early are who owns the board description and whether the update mechanism can update firmware as well as the root filesystem.

Further reading

• Embedded Base Boot Requirements (EBBR) Specification — the normative source.
• Arm SystemReady Devicetree Band
• Arm SystemReady Devicetree — the band’s requirement list, plus a candid list of non-alignments in a reference stack.
• How Embedded Linux Systems Actually Boot on Arm — Benjamin Mordaunt, Linaro, April 2026.
• UEFI on U-Boot
• meta-arm-systemready — Yocto layer for the compliance suite and distribution installation tests (styhead branch).