Loading today’s stories
Build1 distinct publisher3 min readUpdated
Arm certification now requires firmware to hand the kernel a device tree and to accept capsule updates. The compatibility rules that would make that safe across kernel versions are not finished.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Follow any of these and your For You feed starts watching them — no settings page required.
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].
Ranked by verification strength, evidence, and original report placement.
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".
EBBR's 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 source's stated key insight is that exactly one system description must reach the operating system and the platform decides which; a board that ships a DTB inside its kernel image and another in its firmware has not met the requirement and has two answers to the same question.
Under Arm's SystemReady Devicetree band the platform firmware supplies the device tree, the kernel arrives as an ordinary UEFI application, and firmware update stops being a product choice and becomes a requirement.
Arm's SystemReady Devicetree band requires: 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; and at least three Linux distributions must be able to boot, install, and run storage medium tests through the UEFI boot flow.
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, then 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.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Specification-anchored but single-source
The technical core is unusually checkable for a blog post: named specification versions and sections (EBBR 2.4.0, section 2.1, section 2.7.4, UEFI 2.11), quoted normative and non-normative wording, and named implementation symbols (CONFIG_EFI_LOADER, EFI_DTB_TABLE_GUID, EfiACPIReclaimMemory). It is nonetheless one publisher paraphrasing primary documents that are not themselves in the cluster, and the central caveat about unfinished compatibility rules carries no citation.
Requirements and plumbing exist; deployments undisclosed
Supplied material shows an actively revised specification, upstream support in U-Boot and mainline Linux, and Yocto layers for the compliance suite and distribution installation tests. It names no certified platform, SoC vendor, product or shipment figure, and the assertion that the band is 'already shipping' is unquantified, so measurable adoption stays low.
Mostly aligned, slight momentum overstatement
The piece hedges deliberately — it flags the arrangement as partial, notes the guiding-principles section is non-normative, warns that the boot flow is illustrative, and says nothing forces existing products to move — which keeps claims close to evidence. The small positive gap comes from framing an unquantified 'already shipping' state and a headline consequence ('the bill lands on updates') on top of adoption evidence that names no platform or vendor.
No affiliation or funding information supplied
The cluster contains one self-published community-platform post with no disclosure of the author's employer, vendor relationships, sponsorship or commercial interest, and no statements from Arm, SoC vendors or certification bodies. Assigning an incentive score would require inferring facts the sources do not provide.
Moderate-low: verifiable specs, one publisher
Confidence is supported by precise, independently checkable specification and implementation references, and limited by the absence of any second publisher, any named adopter, and any citation for the claim that cross-version compatibility rules are unfinished — the point on which the story's central caution depends.
invest
Singular Photonics raises $2.15M, and the sales line matters more than the round1 distinct publisher
security
The bottleneck moved: 622 CVEs in July, and no one left to write up the fixes1 distinct publisher
product
Linux 7.2 ships cache-aware scheduling, and Torvalds calls AI bug reports the new normal1 distinct publisher
security
Hugging Face breach ran 69 days: a containment failure, not a rogue-agent flash1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 19, 2026