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
<[email protected]> 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
<[email protected]> 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 <[email protected]>
On 10/25/23 20:23, Simon Glass wrote:
Hi Heinrich,
On Tue, 24 Oct 2023 at 18:02, Simon Glass <[email protected]> wrote:
Hi Heinrich,
On Mon, 23 Oct 2023 at 23:20, Heinrich Schuchardt
<[email protected]> 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
<[email protected]>
---
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-
[email protected]/
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.
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.
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.
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
