[0/4] bootstd: firmware-owned devicetree for EBBR / SystemReady IR

[Simon Glass]

Hi Carlo,

On 2026-07-06T15:06:41, Carlo Caione <ccaione at baylibre.com> wrote:

> This series adds a bootstd-level facility for sourcing the
> firmware-owned devicetree from a FIT manifest on a dedicated GPT
> partition

Thanks for working on this - a generic replacement for the vendor
dtbprobe-style commands is very welcome! Herewith a few general
comments.

The "bootstd-level facility" framing doesn't match what the code does.
Nothing plugs into the bootflow iterator: no bootdev, no bootmeth, no
bootflow, and the only consumers are the EFI bootmeth and
efi_bootmgr_run(). Shouldn't this feature be more general than just
EFI?

> the control devicetree points at the source: a 'firmware-fdt-source'
> phandle under /bootstd referencing a 'u-boot,firmware-fdt-block' node
> under the owning media device

I'm a bit nervous about adding this into a media node, but if that is
what your binding ends up as, OK. The other way to do this would be
like VBE, which has a node in bootstd which points to the media
(although it does not include the full path, nor a phandle...

> - both EFI launch paths consume it, the EFI bootmeth (disk and network)
>   and the EFI boot manager, all funneling into efi_install_fdt();

The two consumers (distro_efi_firmware_fdt() in bootmeth_efi.c and
the new block in efi_bootmgr_run()) carry near-identical staging
logic and log strings. Please factor into a single helper alongside
firmware_fdt_load() - e.g. efi_stage_firmware_fdt() - so one place
owns the staging policy (fdt_addr_r, size cap, fail-closed vs
-ENOENT).

> The 'boot_dtb' environment variable may pin an A/B partition number.

boot_dtb seems quite generic - it reads like an address or filename,
How about something like fw_fdt_part so it lines up with
fw_fdt_config. While you're there, both names deserve to appear in
doc/usage/environment.rst

Regards,
Simon