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

[Carlo Caione]

On Wed, Jul 8, 2026 at 7:18 PM Tom Rini <trini at konsulko.com> wrote:

> I think I wasn't clear enough on the RFC, sorry. We need to get this
> binding approved over in https://github.com/devicetree-org/dt-schema/
> and I strongly suspect that barebox would be able to make use of this
> too, so a u-boot prefix would be inappropriate.

Addressing also the comment from David:

> 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).

Thank you both for the review.

I would like to split this into two parts:

1. The on-media contract: a firmware-owned devicetree FIT manifest
where configurations describe the valid base+overlay combinations and,
when signed, authenticate the whole combination.

2. The bootloader-local locator: how a particular bootloader finds
that FIT container on its platform.

The first part is the piece that looks useful beyond U-Boot. The
second part is bootloader policy (IMO).

For the U-Boot-local locator, I would like to follow the existing FWU
metadata precedent. FWU metadata solves a similar problem:
firmware-owned data whose storage location the bootloader must find,
using GPT and MTD backends. It uses a standalone U-Boot control-DT
node, not a child of the storage controller, and points to the storage
provider by phandle:

    fwu-mdata {
        compatible = "u-boot,fwu-mdata-gpt";
        fwu-mdata-store = <&sdmmc1>;
    };

Modeled the same way, the firmware-devicetree source would become a
standalone U-Boot control-DT node, per backend:

    /* eMMC / SD (GPT) */
    firmware-fdt {
        compatible = "u-boot,firmware-fdt-block";
        firmware-fdt-store = <&mmc0>;
        partition-type-uuid = "384e979b-eb76-435a-a3a6-1a071dbad91d";
        partition-name = "firmware";
        filename = "fdt.itb";
    };

    /* SPI-NOR / UBI */
    firmware-fdt {
        compatible = "u-boot,firmware-fdt-mtd";
        firmware-fdt-store = <&spi_nor>;
        ubi-volume = "firmware";
        filename = "fdt.itb";
    };

(please note that for the sake of simplification in the patchset we
are only implementing the `u-boot,firmware-fdt-block` backend, `-mtd`
variant to follow).

This fixes the child-node problem David raised: the controller node is
untouched and only referenced by a phandle. It also keeps this as
U-Boot control-DT policy, matching the existing FWU metadata pattern,
rather than defining a new cross-bootloader locator ABI in this series
(so exonerating us from dealing with dt-schema at all, considering
also that we would deal with that for each different
`u-boot,firmware-fdt-*` backend that we would introduce).

What I think is genuinely shareable with barebox is the on-media
contract: the `fdt.itb` FIT layout, configuration semantics, signing
model, and whatever partition or volume naming convention the platform
or specification defines. That seems like the right thing to document
at the EBBR level, where barebox could adopt the same container
convention independently of how each bootloader locates it. So we
share and define the 'what' but how then barebox (or any other
bootloader) would source `ftd.itb` (the what) is not part of the ABI
and very much bootloader specific.

Does following the existing U-Boot FWU-metadata precedent work if we
scope this binding explicitly as U-Boot control-DT policy?

Cheers,

--
Carlo Caione