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

[Tom Rini via U-Boot <u-boot@lists.u-boot-project.org>]

[-- Attachment #1: Type: text/plain, Size: 4426 bytes --]

On Thu, Jul 09, 2026 at 10:36:06AM +0200, Carlo Caione wrote:
> On Wed, Jul 8, 2026 at 7:18 PM Tom Rini <trini@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?

I was hoping that someone on the FWU side of things would chime in by
now, but I assume people have been too busy. This is I suppose a
reasonable starting path and will give people time to chime in if they
see a problem with it.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]