SystemReady's Devicetree band moves the board description into firmware, and the bill lands on updates

Arm's SystemReady Devicetree band requires a certified platform's firmware, by default, to provide a device tree suitable for booting mainline Linux, and requires that the same firmware be updatable through the UEFI `UpdateCapsule()` service ^[5]. For teams that today build a DTB alongside the kernel from sources under `arch/arm64/boot/dts/` and patch the kernel tree when hardware changes, that is a change of owner rather than a change of boot mechanics ^[1][3].

Two documents do the work. The Embedded Base Boot Requirements 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 ^[4]. The band's compliance list is short: hardware implementing the Base System Architecture, firmware implementing EBBR's subset of UEFI, the firmware-provided device tree, capsule update, and at least three Linux distributions able to boot, install, and run storage medium tests through the UEFI boot flow ^[5].

The rule most likely to be misread is the exclusivity one. EBBR's 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" ^[6]. 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 ^[7]. The device tree has to 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` ^[8]. As the source puts it, a board shipping one DTB inside its kernel image and another in its firmware has two answers to the same question and has not met the requirement ^[9].

The plumbing is ordinary. On an Arm SoC, Trusted Firmware-A runs first, with BL1 from mask ROM, BL2 authenticating and loading images, and BL31 providing PSCI and other runtime services, before handing control to U-Boot as the non-secure BL33 payload and passing the DTB address in a register or inside a Transfer List structure ^[10]. The source cautions that vendor stacks vary, and the stage that authenticates and loads images may be U-Boot SPL or a vendor blob rather than TF-A BL2 ^[11]. U-Boot then acts as the UEFI implementation via `CONFIG_EFI_LOADER`, installing an `EFI_DTB_TABLE_GUID` entry in the EFI Configuration Table before loading an EFI executable ^[12]. The arm64 kernel presents itself as PE/COFF, so its EFI stub walks that table for the device tree, allocates a new flattened device tree describing EFI reserved memory, calls `ExitBootServices()`, and only then enters the normal entry path ^[13].

The consequence is commercial. Once the description lives in firmware and capsule update is a certification condition, fixing a wrong regulator or a missing clock on a shipped board is a signed firmware release, not a kernel package ^[16]. That moves the release cadence, the update mechanism's obligations, and the ownership of a hardware-description defect when a later kernel fails on the same board ^[15]. Nothing compels an existing product to move, and the direction is set by a certification programme with published requirements rather than by a trend ^[14]. The gap worth pricing: the compatibility rules that would keep a firmware-provided device tree durable across kernel versions are unfinished, and EBBR says so about itself ^[2].

Watch the next EBBR revision for normative compatibility language, and watch whether vendors treat the three-distribution boot-and-install test as a one-time certification artifact or a recurring gate against their own firmware releases ^[2][5].