[PATCH v4 1/1] efi_loader: expose the device-tree file name

Simon Glass sjg at chromium.org
Tue Apr 1 17:48:28 CEST 2025 

Hi Caleb,

On Mon, 31 Mar 2025 at 03:38, Caleb Connolly <caleb.connolly at linaro.org> wrote:
>
> Hi Heinrich,
>
> On 3/28/25 15:18, Heinrich Schuchardt wrote:
> > On 28.03.25 14:00, Caleb Connolly wrote:
> >>
> >>
> >> On 3/28/25 13:01, Simon Glass wrote:
> >>> Hi Caleb,
> >>>
> >>> On Sun, 23 Mar 2025 at 12:39, Caleb Connolly
> >>> <caleb.connolly at linaro.org> wrote:
> >>>>
> >>>> Hi all,
> >>>>
> >>>> Reviving this as it is still very much an issue, and especially
> >>>> relevant
> >>>> for Qualcomm platforms.
> >>>>
> >>>> On 11/3/23 20:44, Simon Glass wrote:
> >>>>> Hi Heinrich,
> >>>>>
> >>>>> On Wed, 25 Oct 2023 at 15:22, Heinrich Schuchardt
> >>>>> <heinrich.schuchardt at canonical.com> wrote:
> >>>>>>
> >>>>>> On 10/25/23 23:13, Tom Rini wrote:
> >>>>>>> On Wed, Oct 25, 2023 at 10:28:05PM +0200, Mark Kettenis wrote:
> >>>>>>>>> Date: Wed, 25 Oct 2023 21:57:44 +0200
> >>>>>>>>> From: Heinrich Schuchardt <heinrich.schuchardt at canonical.com>
> >>>>>>>>>
> >>>>>>>>> On 10/25/23 20:23, Simon Glass wrote:
> >>>>>>>>>> Hi Heinrich,
> >>>>>>>>>>
> >>>>>>>>>> On Tue, 24 Oct 2023 at 18:02, Simon Glass <sjg at google.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Hi Heinrich,
> >>>>>>>>>>>
> >>>>>>>>>>> On Mon, 23 Oct 2023 at 23:20, Heinrich Schuchardt
> >>>>>>>>>>> <heinrich.schuchardt at canonical.com> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Forward and backward compatibility of Linux kernel device-
> >>>>>>>>>>>> trees is
> >>>>>>>>>>>> sometimes missing. One solution approach is to load a kernel
> >>>>>>>>>>>> specific
> >>>>>>>>>>>> device-tree. This can either be done via a U-Boot scripts
> >>>>>>>>>>>> (like the one
> >>>>>>>>>>>> generated by Debian package flash-kernel or by a boot loader
> >>>>>>>>>>>> like GRUB.
> >>>>>>>>>>>> The boot loader approach currently requires to know the
> >>>>>>>>>>>> device-tree name
> >>>>>>>>>>>> before first boot which makes it unusable for generic images.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Expose the device-tree file name as EFI variable FdtFile.
> >>>>>>>>>>>> This will allow bootloaders to load a kernel specific
> >>>>>>>>>>>> device- tree.
> >>>>>>>>>>>
> >>>>>>>>>>> kernel-specific
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> The variable will not be exposed on ACPI based systems or if
> >>>>>>>>>>>> the
> >>>>>>>>>>>> environment variable fdtfile is not defined.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Signed-off-by: Heinrich Schuchardt
> >>>>>>>>>>>> <heinrich.schuchardt at canonical.com>
> >>>>>>>>>>>> ---
> >>>>>>>>>>>> v4:
> >>>>>>>>>>>>             Generalize the description of the content of
> >>>>>>>>>>>> $fdtfile.
> >>>>>>>>>>>> v3:
> >>>>>>>>>>>>             Add documentation
> >>>>>>>>>>>> v2:
> >>>>>>>>>>>>             Use a unique GUID to enable future U-Boot
> >>>>>>>>>>>> independent
> >>>>>>>>>>>>             standardization.
> >>>>>>>>>>>>             Do not try to add the variable on ACPI based
> >>>>>>>>>>>> systems.
> >>>>>>>>>>>> ---
> >>>>>>>>>>>>      doc/develop/uefi/uefi.rst  | 14 ++++++++++++++
> >>>>>>>>>>>>      include/efi_loader.h       |  5 +++++
> >>>>>>>>>>>>      lib/efi_loader/efi_setup.c | 30 +++++++++++++++++++++++
> >>>>>>>>>>>> + ++++++
> >>>>>>>>>>>>      3 files changed, 49 insertions(+)
> >>>>>>>>>>>>
> >>>>>>>>>>>> diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/
> >>>>>>>>>>>> uefi.rst
> >>>>>>>>>>>> index fb16ac743a..702c490831 100644
> >>>>>>>>>>>> --- a/doc/develop/uefi/uefi.rst
> >>>>>>>>>>>> +++ b/doc/develop/uefi/uefi.rst
> >>>>>>>>>>>> @@ -916,6 +916,20 @@ So our final format of the
> >>>>>>>>>>>> FilePathList[] is::
> >>>>>>>>>>>>
> >>>>>>>>>>>>          Loaded image - end node (0xff) - VenMedia -
> >>>>>>>>>>>> initrd_1 - [end node (0x01) - initrd_n ...] - end node (0xff)
> >>>>>>>>>>>>
> >>>>>>>>>>>> +EFI variable FdtFile
> >>>>>>>>>>>> +~~~~~~~~~~~~~~~~~~~~
> >>>>>>>>>>>> +
> >>>>>>>>>>>> +Ideally U-Boot would always expose a device-tree that can
> >>>>>>>>>>>> be used for booting
> >>>>>>>>>>>> +any operating systems. Unfortunately operating systems like
> >>>>>>>>>>>> Linux sometimes
> >>>>>>>>>>>> +break forward and backward compatibility. In this case
> >>>>>>>>>>>> there is a need to load
> >>>>>>>>>>>> +an operating system version specific device-tree.
> >>>>>>>>>>>
> >>>>>>>>>>> This seems to be a strong statement. Given the effort that
> >>>>>>>>>>> goes into
> >>>>>>>>>>> the DT, changes are supposed to be backwards-compatible. Is this
> >>>>>>>>>>> generally true, or is it just that we want an up-to-date DT
> >>>>>>>>>>> for the
> >>>>>>>>>>> kernel to enable new features?
> >>>>>>>>>>
> >>>>>>>>>> Did you see this comment?
> >>>>>>>>>
> >>>>>>>>> It would have been nice to put the person which made that
> >>>>>>>>> comment on copy.
> >>>>>>>>>
> >>>>>>>>> The truth lies in the world "supposed":
> >>>>>>>>>
> >>>>>>>>> The idea of a device-tree that never needs to change is quite
> >>>>>>>>> old and
> >>>>>>>>> never became true on ARM devices.
> >>>>>>>>>
> >>>>>>>>> We all know Linux tends to break both forward and backward
> >>>>>>>>> compatibility
> >>>>>>>>> of device-trees. Here is a nice example:
> >>>>>>>>>
> >>>>>>>>> d0c6707ca423 ("arm64: dts: allwinner: H5: NanoPi Neo Plus2:
> >>>>>>>>> phy- mode
> >>>>>>>>> rgmii-id")
> >>>>>>>>>
> >>>>>>>>> Driver changes broke forward and backwards compatibility of a
> >>>>>>>>> lot of
> >>>>>>>>> Allwinner boards.
> >>>>>>>>
> >>>>>>>> Well, that happened in 2020.  Things have gotten better over time.
> >>>>
> >>>> (kinda off-topic context on DT version compat)
> >>>>
> >>>>   From what I've seen, there is not yet very much infrastructure or
> >>>> common practise in place in the kernel to handle parsing DTB in a
> >>>> backwards compatible way. For example there has been efforts to
> >>>> simplify
> >>>> the dwc3 devicetree for Qualcomm platforms with a series dating back
> >>>> about as far as this U-Boot patch!
> >>>>
> >>>> https://lore.kernel.org/linux-arm-msm/20250318-dwc3-refactor-
> >>>> v5-1-90ea6e5b3ba4 at oss.qualcomm.com/
> >>>>
> >>>> Earlier versions attempted to convert the older DTS to the newer format
> >>>> internally, but after much discussion it was decided that this wasn't
> >>>> really feasible, instead the new approach is to duplicate the entire
> >>>> dwc3 driver to maintain DT compatibility.
> >>>>
> >>>> It's obviously good to see compatibility taken seriously, since it
> >>>> seems
> >>>> clear that if we ever want to treat DT as firmware, the kernel will
> >>>> need
> >>>> to do this (and eventually vendors could ship laptops with DT out of
> >>>> the
> >>>> box which works with upstream -- crazier things have happened).
> >>>>
> >>>> But I think in the mean time we still want to be able to drive distro
> >>>> adoption, and the way I see it teaching GRUB and systemd-boot about a
> >>>> new FdtFile EFI variable is going to make that way simpler...
> >
> > There was a discussion in the context of EBBR if this is the right way
> > forward. And the general opinion was that the compatible string should
> > be used for matching the dtb files.
>
> Ideally, the file name should contain the same information as the
> compatible string, or more. Currently in upstream there are devices with
> different display variants that have identical compatible strings but
> different dtb files.
>
> >
> >>>
> >>> GRUB is unlikely even to handle devicetree properly as it does not
> >>> implement FIT, nor the best-match algorithm in FIT. So everything is a
> >>> workaround.
> >
> > For the Qualcomm laptop case the current patch would not solve anything
> > as the selection of the device-tree needs to be based on SMBIOS value.
>
> I bought this idea up with the laptops team and the upstream Qualcomm
> maintainer, everyone agreed that this approach would be a much more
> scalable intermediate solution. Since the HWID matching stuff will just
> not scale or make it into distros easily (e.g. generic installer won't
> work on the laptops currently because of this).
>
> If my understanding of EFI is correct, it would be possible to set this
> variable on the laptops via EFI shell (or even some custom EFI app for
> simplicity), and there is a non-zero chance that we could get some
> vendors to support setting this variable directly in their EFI firmware
> setup.
>
> >
> > Systemd-boot allows to add a rule-table to the UKI header to select
> > device-trees from a UKI image.
> >
> > That is a smarter solution than trying to hard-code logic in U-Boot to
> > set fdtfile and an FdtFile EFI variable.
>
> Right, we try to guess fdtfile today in mach-snapdragon and that sucks.
> I brainstormed this a bit with Ilias and what we came up with is to have
> U-Boot embed the fdtfile value directly into the /chosen node of every
> DTB we build with OF_UPSTREAM. Since the paths are identical to the kernel.
>
> This way you can have a single U-Boot binary (as we support for
> Qualcomm) boot on different boards and whichever DTB you give to U-Boot
> (say qcom/sdm845-db845c.dtb for example) will be the value that FdtFile
> gets. Then sd-boot/GRUB will look for a DTB under the same name relative
> to the devicetree-dir for the kernel version you're booting.
>
> Yes long term all this is far from the ideal solution, but it's a lot
> better than what we have today and much less hacky than every other
> proposal I've seen particularly for the laptops.
>
> Most importantly, it doesn't require distro changes, we already know for
> sure that distros are not going to adopt FIT. Arguing on the merits is
> pointless.

While it is very hard to predict the future, I don't share your pessimism :-)

IMO UKI is a poor man's FIT and eventually it will end up with similar
features to FIT, just uglier and with less flexibility.

Regards,
Simon


>
> Kind regards,
>
> >
> >>
> >> FIT has nothing to do with DT loading
> >>>
> >>>>>>>
> >>>>>>> Well, yes and no.  Given the brief summary here, I bet this was just
> >>>>>>> like when phy-mode and am335x platforms had DT compatibility
> >>>>>>> broken and
> >>>>>>> the answer was that it was OK because the DT was incorrectly
> >>>>>>> describing
> >>>>>>> hardware. So this is the reminder that there are cases of
> >>>>>>> breaking DT
> >>>>>>> compatibility that are allowed. Even if the DT has been out (and
> >>>>>>> wrong)
> >>>>>>> for several years.
> >>>>>>>
> >>>>>>> That's not the main point of this thread and I don't want to derail
> >>>>>>> things further along this point, I just want to note that the
> >>>>>>> details
> >>>>>>> here reminded me of when things are allowed to be incompatible with
> >>>>>>> previous trees.
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>> Unfortunately I was off the list for a week or so, but I see this one
> >>>>> so will reply here.
> >>>>>
> >>>>>> You are conflating things:
> >>>>>>
> >>>>>> The EFI variable is a hint to the GRUB OS to find the correct
> >>>>>> device-tree file without scanning hundreds of device-tree. You can
> >>>>>> not
> >>>>>> build a compatibility check for it into U-Boot.
> >>>>>
> >>>>> Actually we can...and I think that is what we should do.
> >>>>
> >>>> No, how and where an EFI bootloader app chooses to load the FDT from is
> >>>> entirely implementation dependent. It may be extremely costly to
> >>>> compare
> >>>> compatible strings for every single dtb, and whether or not to do so is
> >>>> the decision of the distro anyways, all we can do in U-Boot is try to
> >>>> promote best practise (which clearly isn't compatible prop comparison
> >>>> for hundreds of DTBs...)
> >>>
> >>> U-Boot promotes best practice, which is to check the compatible
> >>> properties of hundreds of nodes in the FIT to find the right one.
> >>
> >> Distros don't ship FIT images (which would be absolutely huge by the
> >> way, 75M for all DTBs today), they ship DTBs in a directory structure
> >> following the kernel layout.
> >
> > It might make sense to support compressed FIT images.
> >
> > Whether all device-trees are stored as files in /lib/firmware/<kernel-
> > version>/device-tree/ or are part of the kernel image (FIT or UKI) does
> > not change the space requirement on disk.
> >
> > Best regards
> >
> > Heinrich
> >
> >>
> >> If the kernel started outputting FIT images with all DTBs it would
> >> have to be installed in addition to the directory layout, and only
> >> provide a considerably less efficient interface to pick a DTB.
> >>
> >> We want Fedora images that you download today to be able to boot and
> >> select an appropriate DTB. FIT is just not a good fit (haha) for this
> >> problem.
> >>
> >> A fit mapping compatible strings to filenames would be an improvement
> >> but that's so much additional complexity to come up with a value that
> >> U- Boot already has...
> >>
> >>>>
> >>>> Providing FdtFile as an EFI variable will make it possible for grub and
> >>>> systemd-boot to support the same kind of "fdtdir" property that
> >>>> extlinux
> >>>> does, this would simply enable versioned DTB loading for distros and
> >>>> make booting wayyyyy easier.
> >>>
> >>> It is perpetuating an incorrect approach, though. It won't lead to
> >>> happiness. Perhaps systemd-boot should support FIT?
> >>
> >> What do i even say to this. You haven't explained what's incorrect
> >>>
> >>> As to versions, the compatible string needs to handle that. We cannot
> >>> have a situation where we ship two different devices trees that have
> >>> the same compatible strings but different contents as there is no
> >>> (spec-correct) way to distinguish them.
> >>>
> >>>>
> >>>> With regards to the design, I think a good follow-up patch would set a
> >>>> default value for $fdtfile (and consequently FdtFile) from the
> >>>> DEVICE_TREE build variable as a constant (maybe only if OF_UPSTREAM is
> >>>> enabled).
> >>>
> >>> Please no. We should not continue down this broken path.
> >>
> >> ???
> >>>
> >>>>
> >>>> This would be correct in almost all cases (and wayyy better than the
> >>>> hacky fdtfile generating code we have in mach-snapdragon right now).
> >>>
> >>> Yes, but you really should figure out how to remove that code. It is
> >>> present on other boards too. One of the things not on my list (but I
> >>> wish it were) is to clean up how RISC-V does devicetree selection
> >>> within U-Boot.
> >>
> >> That is why i revived this patch...
> >>>
> >>>>>
> >>>>> For distro-boot, do you mean the scripts? We are trying to deprecate
> >>>>> those. Of course we have brought in all the same work-arounds, etc.,
> >>>>> but with bootstd we can start to clean things up, I hope.
> >>>>>
> >>>>> So let's think about how we can have U-Boot choose the right DT to
> >>>>> boot with.
> >>>>>
> >>>>> Regards,
> >>>>> Simon
> >>>>
> >>>> Heinrich, since it's been a while, if you aren't super interested in
> >>>> re-sending this patch I'd be happy to address the wording feedback and
> >>>> re-spin it, along with a patch setting the default $fdtfile (else I can
> >>>> send that as a follow-up).
> >>>
> >>> The best thing to do here is to use FIT. You can put all the FDTs in a
> >>> FIT and leave the kernel out, if necessary.
> >>
> >> You cannot do this, distros will not do this for thousands of FDTs
> >>>
> >>> Another idea, which I may have suggested before (can't remember) would
> >>> be to add an EFI service which U-Boot implements, which returns the
> >>> correct FDT to use. U-Boot can then scan the files one by one to
> >>> figure it out, although hopefully that would prompt someone to create
> >>> a FIT (or a text file?) which has this information in it.
> >>>
> >>> But fdtfile is just not the right approach.
> >>
> >> You've pushed for FIT but never explained why fdtfile is a bad solution.
> >>>
> >>>>
> >>>> I'll also open an issue for getting support for this added to
> >>>> systemd-boot.
> >>>
> >>> FIT?
> >>>
> >>> Regards,
> >>> Simon
> >>
> >
>
> --
> Caleb (they/them)
>

More information about the U-Boot mailing list