Hi Carlo, On 2026-07-06T15:06:41, Carlo Caione <[email protected]> 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
