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

[Tom Rini]

On Wed, Oct 25, 2023 at 09:57:44PM +0200, Heinrich Schuchardt wrote:
> 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.
> 
> 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, OK. And I think we want to try and have things phrased in a more
neutral and less confrontational manner is part of the issue. Maybe:

In ideal circumstances, U-Boot will be able to expose the device-tree it
is using to boot any operation system. However, in some cases operating
systems need to load a specific device-tree rather than utilize the same
one that U-Boot is currently using. In this case there is a need to load
a specific device-tree binary from another location.

And as a more general concern I see right now, "fdt_file" and "fdtfile"
are both used today, including new rather than older platforms that
might avoid EFI_LOADER all the same, perhaps we should check for both?
Or do you instead want to get board maintainers to switch over, as
fdt_file isn't listed under doc/ today.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20231025/63bbe4c5/attachment.sig>