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

Fri Oct 20 18:24:10 CEST 2023

On Fri, Oct 20, 2023 at 05:40:03PM +0200, Heinrich Schuchardt wrote:
> On 20.10.23 15:21, Simon Glass wrote:
> > +Doug Anderson
> > 
> > Hi Heinrich,
> > 
> > On Thu, 19 Oct 2023 at 09:09, Heinrich Schuchardt
> > <heinrich.schuchardt at canonical.com> wrote:
> > > 
> > > On 19.10.23 15:55, Simon Glass wrote:
> > > > Hi Heinrich,
> > > > 
> > > > On Wed, 18 Oct 2023 at 02:15, Heinrich Schuchardt
> > > > <heinrich.schuchardt at canonical.com> wrote:
> > > > > 
> > > > > On 10/18/23 05:33, Simon Glass wrote:
> > > > > > Hi Heinrich,
> > > > > > 
> > > > > > On Tue, 17 Oct 2023 at 07:50, 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.
> > > > > > > 
> > > > > > > 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>
> > > > > > > ---
> > > > > > > v2:
> > > > > > >            Use a unique GUID to enable future U-Boot independent
> > > > > > >            standardization.
> > > > > > >            Do not try to add the variable on ACPI based systems.
> > > > > > > ---
> > > > > > >     include/efi_loader.h       |  5 +++++
> > > > > > >     lib/efi_loader/efi_setup.c | 30 ++++++++++++++++++++++++++++++
> > > > > > >     2 files changed, 35 insertions(+)
> > > > > > 
> > > > > > I was too slow to reply to v1.
> > > > > > 
> > > > > > Does grub load the DT? I was assuming that U-Boot would pass it on?
> > > > > > What is the interface between U-Boot and grub?
> > > > > 
> > > > > The device-tree built into U-Boot is often out of date and not usable to
> > > > > boot current Linux. A single device-tree can be loaded by U-Boot from
> > > > > file and passed on as EFI configuration table. This device-tree may not
> > > > > be compatible with all kernel versions exposed by GRUB.
> > > > > 
> > > > > GRUB provides a devicetree command. It is disabled if you use secure
> > > > > boot. At least in Debian and Ubuntu GRUB invokes the
> > > > > EFI_DT_FIXUP_PROTOCOL exposed by U-Boot to run U-Boot's device-tree
> > > > > fix-ups after loading a device-tree.
> > > > > 
> > > > > Vendor scripts for GRUB like Ubuntu's /etc/grub.d/10_linux add
> > > > > devicetree commands to the boot options in grub.cfg.
> > > > 
> > > > Thanks. I wonder if you could document this somewhere? It seems like
> > > > there are a lot of options and it is quite complicated.
> > > > 
> > > > Back to the question, I suppose you are expecting grub to load the DT
> > > > using this filename? But why doesn't U-Boot load it instead? It seems
> > > > very convoluted.
> > > 
> > > A separate file of this name exists for every kernel version installed.
> > > The loaded dtb must match the kernel. U-Boot does not know what kernel
> > > version will be chosen in GRUB. And for a generic image GRUB does not
> > > what board it is on.
> > > 
> > > > 
> > > > Also, can we test this interface?
> > > 
> > > Neither the sandbox nor QEMU have environment variable fdtfile. And we
> > > don't create the EFI variable with ACPI as used on the sandbox.
> > 
> > I worry that this is creating another interface that some poor sod is
> > going to have to deal with in the future. Is this part of the EFI
> > standard?
> 
> No, the UEFI standard does not care much about device-trees. It only defines
> the GUID for the configuration table.
> 
> > 
> > We should really be using the compatible string to choose the
> > devicetree. Why are we using filenames at all? What is the
> > relationship between the compatible string and the filename? Is there
> > a lookup table, or should we create one?
> 
> There is no 1:1 relationship between compatible string and filename, e.g.
> the following arm64 device-trees use the same compatible string:
> 
> amd/amd-overdrive-rev-b0.dts
> amd/amd-overdrive-rev-b1.dts
> 
> amlogic/meson-axg-jethome-jethub-j110-rev-2.dts
> amlogic/meson-axg-jethome-jethub-j110-rev-3.dts
> 
> xilinx/zynqmp-zc1751-xm015-dc1.dts
> xilinx/zynqmp-zc1751-xm015-dc1.dts
> xilinx/zynqmp-zc1751-xm015-dc1.dts
> xilinx/zynqmp-zc1751-xm015-dc1.dts
> 
> > 
> > The correct way of doing this is implemented in U-Boot with
> > CONFIG_FIT_BEST_MATCH.
> 
> Why should we write complicated code to find a *possibly* matching file if
> we already know the filename that needs to be loaded?

I think that is the unfortunate key here. We can make a guess, or best
match, but it might not be right. And we need a reliable way to find and
use the correct tree. And the U-Boot portion of that may be "set the EFI
var if it's not already set" rather than "and now load it".

> > Can we mirror something like that in grub, etc?

I'm splitting this part out because no, having to have N projects write
the same bit of code, but with its own quirks and bugs doesn't sound
like the right direction. It's why today we have a few different sets of
logic to try and find / set the right device tree, so that whatever
follows after doesn't have to also do that, and get updated for every
new platform too.

And of course yes, ideally, boards would be manufactured with an up to
date and correct device tree on them.

-- 
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/20231020/e5db1d4d/attachment.sig>