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

["Carlo Caione" <ccaione@baylibre.com>]

On Sat Aug 15, 2026 at 8:45 PM CEST, Simon Glass wrote:
> Hi Carlo,
>
> On 2026-07-28T13:20:42, Carlo Caione <ccaione@baylibre.com> 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