Hi Carlo, On Mon, 24 Aug 2026 at 08:48, Carlo Caione <[email protected]> wrote: > > 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.
Yes that seems reasonable to me, thanks for explaining. Regards, Simon
