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

[Carlo Caione]

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).

> >   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,

--
Carlo Caione