On 31.03.25 18:30, Tom Rini wrote:
On Sun, Mar 30, 2025 at 04:38:12PM +0200, Caleb Connolly 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.conno...@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.schucha...@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.schucha...@canonical.com>
On 10/25/23 20:23, Simon Glass wrote:
Hi Heinrich,
On Tue, 24 Oct 2023 at 18:02, Simon Glass <s...@google.com> wrote:
Hi Heinrich,
On Mon, 23 Oct 2023 at 23:20, Heinrich Schuchardt
<heinrich.schucha...@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.schucha...@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-90ea6e5b3...@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.
I've asked before for clarification on if that's allowed or a bug and
not really gotten an answer. It sure feels wrong and I think the
argument is that devices doing things like that aren't likely to be
general purpose anyhow.
Multiple device-trees in Linux having the same compatible string is a
bug as indicated by the device-tree maintainer in earlier discussions.
It should be fixed in Linux.
Best regards
Heinrich
