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

[Simon Glass]

Trying again to add Doug as we chatted briefly about this yesterday.

On Fri, Oct 20, 2023, 07:21 Simon Glass <sjg at google.com> 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?
>
> 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?
>
> The correct way of doing this is implemented in U-Boot with
> CONFIG_FIT_BEST_MATCH. Can we mirror something like that in grub, etc?
>
> Regards,
> Simon