Hi Carlo, On Thu, 2 Jul 2026 at 08:27, Carlo Caione <[email protected]> wrote: > > On Thu, Jul 2, 2026 at 3:09 PM Simon Glass <[email protected]> wrote: > > > For Mediatek specifically, I am hoping to eventually upstream support > > for a load-only FIT (the spec supports it) so that you can load the DT > > from a firmware partition, then still boot the OS (without a DT). This > > works with FIT, but would need adjustment if the OS is actually an EFI > > app. > > > > I wrote a post about this challenge: > > > > https://www-concept.deinde.dev/blog/devicetree-in-firmware-or-packaged-with-the-os/ > > Well, this is convenient because your suggestion converges nicely with > where this work has gone since I posted the RFC (I was ready to send > out a V2 soon-ish). > > v2 of this design replaces the environment-described file set with a > FIT manifest carried on the firmware partition itself: the FIT images > hold the base DTB and the overlays, and each FIT configuration names > one bootable combination through the standard 'fdt' property. > > Not exactly sure what you mean with “load-only” but there no kernel in > it, the assembled devicetree is handed to the EFI app via the > configuration table. > > v2 is implemented and validated on (my) hardware; I will post the > updated RFC shortly. Some of your comments below are already addressed > by it, noted inline. > > > > The *location* is described in the control devicetree. The bootstd node > > > carries > > > a `firmware-fdt-source` phandle to a node that is a child of the media > > > device > > > that owns the partition, and identifies the partition by GPT type UUID > > > and/or > > > name: > > > > > > bootstd { > > > compatible = "u-boot,boot-std"; > > > firmware-fdt-source = <&fw_fdt>; > > > }; > > > > > > &mmc0 { > > > fw_fdt: firmware-fdt { > > > compatible = "u-boot,firmware-fdt-block"; > > > > Does the -block suffix indicate that it is a block device, rather than > > a filesystem? How does this cope with the fast where multiple DTs are > > provided for different models? > > The suffix names the backend: this one is a block device with a GPT > partition holding a filesystem. It leaves room for sibling backends > later, e.g. an UBI/MTD variant for NOR-based boards, which some > MediaTek platforms would need. I will spell that out in the binding > text. > > Multiple models are the manifest's job in v2: one FIT configuration > per model/SKU, so the per-model knowledge lives with the devicetrees > it describes and is updated atomically with them. > > > > partition-type-uuid = "...."; /* GPT type UUID > > > */ > > > partition-name = "firmware"; /* optional */ > > > extra-size = <0x3000>; /* overlay > > > headroom */ > > > > This seems like a parameter which would be better handled by U-Boot itself? > > Yup, and it is gone in v2. > > > > - the control DT describes the source and the partition policy; > > > - the board default environment carries factory defaults for the static > > > values > > > (`fdtfile` and `dtb_path` for the base DTB, and the `fdt_addr_r` / > > > `fdtoverlay_addr_r` working addresses), so a from-source build boots > > > and > > > `env default` restores a loadable configuration; > > > > I wish we could move away from filenames and use compatible strings > > instead, as FIT does - this is how the FDT spec is written. > > v2 does this. 'fdtfile' and 'dtb_path' are gone leveraging > FIT_BEST_MATCH. The only filename left is the manifest container > itself (fdt.itb by default), which is a fixed convention (we can > change it of course, I don't have a strong imagination). > > > > each installing the result through `efi_install_fdt()`. That is the > > > convergence > > > point all EFI launches pass through, so the firmware devicetree is > > > installed > > > regardless of how the EFI application was started, including the > > > boot-manager > > > autoboot path that SystemReady IR uses. > > > > What if you run GRUB? > > Not sure I 100% got this objection but it is not very special I guess, > the firmware devicetree is installed into the EFI configuration table > before the EFI app starts, GRUB does not touch it, and the kernel's > EFI stub picks it up > from the table (as long as GRUB does not install a different DTB at that > point).
Just on this point, the question is really whether GRUB does not touch it. My understand is that it actually loads the FDT from a file (Ilias is the expert here) and that is why we have an EFI fix-up protocol to send that loaded FDT back to U-Boot to be fixed up before booting. > > > > 5. Should the signed-FIT verification be part of this series or a > > > follow-up? > > > > You likely get this for free, so I suggest including it. > > Indeed, since now the manifest is a FIT. > > I will post the v2 RFC as a follow-up to this thread. > > thanks for the review, > Regards, Simon
