[PATCH 1/4] bootstd: add a firmware-owned devicetree source

[David Lechner]

On 7/6/26 10:06 AM, Carlo Caione wrote:
> Platforms following EBBR / Arm SystemReady IR keep the devicetree on
> a firmware-owned partition, updated independently of the operating
> system, rather than shipping it in the OS image or on the EFI System
> Partition. U-Boot has no generic way to source the devicetree from such
> a partition, so vendors carry out-of-tree machinery for it.
> 
> Add a bootstd helper, firmware_fdt_load(), that assembles the OS
> devicetree from a FIT manifest carried on that partition: the FIT images
> hold the base DTB and its overlays, and each FIT configuration names one
> bootable combination through its 'fdt' property.
> 
> The partition is described in the control devicetree: the bootstd node
> carries a 'firmware-fdt-source' phandle to a source node, a child of
> the media device owning the partition, which identifies it by GPT type
> UUID and/or name. The 'boot_dtb' environment variable may pin an A/B
> partition number.
> 
> The error semantics are fail closed: -ENOENT strictly means "no source
> configured" (the only case where callers may fall back to their normal
> devicetree); once a source is configured, any assembly failure is
> fatal, and downstream -ENOENT codes (missing manifest, missing FIT
> configuration) are remapped so a missing or bad firmware devicetree is
> never silently replaced by an unverified one. Manifest images carrying
> a 'load' property are rejected so a misbuilt manifest cannot overwrite
> arbitrary memory.
> 

...

> diff --git a/boot/firmware_fdt.c b/boot/firmware_fdt.c
> new file mode 100644
> index 00000000000..952299f1e1b
> --- /dev/null
> +++ b/boot/firmware_fdt.c
> @@ -0,0 +1,382 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Firmware-owned devicetree (FDT) source.
> + *
> + * Some platforms (EBBR / Arm SystemReady IR) keep the devicetree on a
> + * firmware-owned partition rather than in the OS image or the EFI System
> + * Partition. The devicetree is carried by a FIT manifest on that partition:
> + * the FIT images hold the base DTB and its overlays, and each FIT
> + * configuration names one bootable combination through its 'fdt' property.
> + *
> + * The partition is described by the control devicetree: the bootstd node
> + * carries a 'firmware-fdt-source' phandle to a source node, a child of the
> + * media device that owns the partition, e.g.:
> + *
> + *	bootstd {
> + *		compatible = "u-boot,boot-std";
> + *		firmware-fdt-source = <&fw_fdt>;
> + *	};
> + *	&mmc0 {
> + *		fw_fdt: firmware-fdt {
> + *			compatible = "u-boot,firmware-fdt-block";
> + *			partition-type-uuid = "....";	(GPT type UUID)
> + *			partition-name = "firmware";	(optional fallback)
> + *			filename = "fdt.itb";		(optional, the default)
> + *		};
> + *	};

I have some doubts that it is safe to add arbitrary child nodes to
arbitrary storage controller devices like this. Many of these devices
already define child nodes in their bindings, so this could break
drivers that expect a certain type of child node already. (And also
break validation against the binding schemas.)

So it seems like it should go under /bootstd if this is u-boot-only
or /options [1] if we want to try to make it generic for other bootloaders.
And it could just have a phandle to reference the target block device
provider or just reference it by name (to match using alias).

[1]: https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/options.yaml