On Thu, Jul 09, 2026 at 10:36:06AM +0200, Carlo Caione wrote: > On Wed, Jul 8, 2026 at 7:18 PM Tom Rini <[email protected]> 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
signature.asc
Description: PGP signature
