Re: [v2,0/5] firmware-owned devicetree for EBBR / SystemReady IR

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