[RFC] bootstd: firmware-owned OS devicetree for EBBR / SystemReady IR

[Simon Glass]

Hi Carlo,

On Thu, 2 Jul 2026 at 08:27, Carlo Caione <ccaione at baylibre.com> wrote:
>
> On Thu, Jul 2, 2026 at 3:09 PM Simon Glass <sjg at chromium.org> 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