On Sat Aug 15, 2026 at 8:45 PM CEST, Simon Glass wrote: > Hi Carlo, > > On 2026-07-28T13:20:42, Carlo Caione <[email protected]> wrote: > >> Patch 1 makes an FDT passed to efi_bootmgr_run() outrank a Boot#### FDT, >> as an independent behaviour fix. Patch 2 adds the loader, binding, >> documentation and shared EFI staging policy. Patches 3 and 4 integrate >> the EFI bootmeth and boot manager. Patch 5 adds sandbox coverage. > [..] > >> - 'fw_fdt_part' can pin an A/B partition and 'fw_fdt_config' can select >> an explicit configuration. > > Just to check - is exposing these as environment variables really the > right long-term interface? U-Boot has been moving configuration into > the control devicetree, and both of these look like properties that > would sit naturally on the u-boot,firmware-fdt-block node, with the > env var overriding for A/B slot selection only. What do you think?
Hi Simon, Replying only to this point because all the other comments have my ACK. Agreed regarding fw_fdt_part: it is indeed intended as the runtime A/B slot override, while the stable storage location remains described by the provider phandle and partition UUID/name in the control devicetree. Now, fw_fdt_config is slightly different though. We need configuration selection to depend on the selected boot target. For example in our usecase, the same firmware FIT may provide a base-only configuration for a generic distribution and an overlay configuration for a platform image. The control devicetree is identical in both cases, so a fixed property there cannot express that choice. Static selection is already covered by compatible best-match and the FIT default. I would retain fw_fdt_config only as an explicit runtime override above those mechanisms and clarify that role in the documentation if that is ok with you. Cheers, -- Carlo Caione
