Hi Heinrich, On Tue, 17 Oct 2023 at 13:12, Heinrich Schuchardt < heinrich.schucha...@canonical.com> wrote:
> On 17.10.23 11:49, Ilias Apalodimas wrote: > > > > > > On Tue, 17 Oct 2023 at 12:23, Heinrich Schuchardt > > <heinrich.schucha...@canonical.com > > <mailto:heinrich.schucha...@canonical.com>> wrote: > > > > On 17.10.23 11:14, Ilias Apalodimas wrote: > > > Hi Heinrich, > > > > > > On Tue, 17 Oct 2023 at 11:55, Heinrich Schuchardt > > > <heinrich.schucha...@canonical.com > > <mailto:heinrich.schucha...@canonical.com> > > > <mailto:heinrich.schucha...@canonical.com > > <mailto: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. > > > > > > Signed-off-by: Heinrich Schuchardt > > > <heinrich.schucha...@canonical.com > > <mailto:heinrich.schucha...@canonical.com> > > > <mailto:heinrich.schucha...@canonical.com > > <mailto:heinrich.schucha...@canonical.com>>> > > > --- > > > lib/efi_loader/efi_setup.c | 26 ++++++++++++++++++++++++++ > > > 1 file changed, 26 insertions(+) > > > > > > diff --git a/lib/efi_loader/efi_setup.c > > b/lib/efi_loader/efi_setup.c > > > index e6de685e87..b24feb94dc 100644 > > > --- a/lib/efi_loader/efi_setup.c > > > +++ b/lib/efi_loader/efi_setup.c > > > @@ -26,6 +26,27 @@ void __weak allow_unaligned(void) > > > { > > > } > > > > > > +/** > > > + * efi_init_fdtfile() - set EFI variable FdtFile > > > + * > > > + * Return: status code > > > + */ > > > +static efi_status_t efi_init_fdtfile(void) > > > +{ > > > + char *val; > > > + > > > + val = env_get("fdtfile"); > > > + if (!val) > > > + return EFI_SUCCESS; > > > + > > > + return efi_set_variable_int(u"FdtFile", > > > + &efi_u_boot_guid, > > > + > > EFI_VARIABLE_BOOTSERVICE_ACCESS | > > > + > EFI_VARIABLE_RUNTIME_ACCESS | > > > > > > > > > Why is runtime access needed? Wouldn't the choice be done before > > > ExitBootServices? > > > > > > Having runtime access will allow to use the content of the variable > to > > write a devicetree command to grub.cfg or to copy the relevant > > device-tree to a predefined location. > > > > As GRUB cannot read EFI variables, yet, this would be the easiest > > short-term approach. > > > > Do you mean to write EFI variables? If you want GRUB to be able to do > > that, wouldn't it be better to use a generic GUID instead of the U-Boot > one? > > No, I meant read. It is U-Boot writing the variable. > > Concerning the GUID the UEFI 2.10 specification requires a unique > VendorGuid other than EFI_GLOBAL_VARIABLE. > > If we think about adding a recommendation to the EBBR, it might make > sense to use a GUID other than a U-Boot specific one (at the expense of > 16 bytes of code). > > Best regards > > Heinrich > Ok, I like the idea of standardizing it, since GRUB needs to pick this up eventually. I guess we can use the u-boot GUID until is there, so Reviewed-by: Ilias Apalodimas <ilias.apalodi...@linaro.org>
