Trying again to add Doug as we chatted briefly about this yesterday.
On Fri, Oct 20, 2023, 07:21 Simon Glass <s...@google.com> wrote: > > +Doug Anderson > > Hi Heinrich, > > On Thu, 19 Oct 2023 at 09:09, Heinrich Schuchardt > <heinrich.schucha...@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.schucha...@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.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. > > >>>> > > >>>> 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> > > >>>> --- > > >>>> 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