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.
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.
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.
In distro-boot we are using the same value from environment variable
$fdtfile. Here you could check the compatible string but this might
break booting .
Best regards
Heinrich
