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? Cheers, -- Carlo Caione
