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

[Mark Kettenis]

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

> Distros will continue to load the device-tree that matches the kernel to 
> get the best possible board support and need to do this efficiently.

Right.  Even if there is full backward/forward compatibility, you
probably want the latest device-tree to make sure you get the most
complete hardware support.

But this shouldn't be used as an argument to not care about
backward/forward compatibility.