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

[Heinrich Schuchardt]

On 17.10.23 11:49, Ilias Apalodimas wrote:
> 
> 
> On Tue, 17 Oct 2023 at 12:23, Heinrich Schuchardt 
> <heinrich.schuchardt at canonical.com 
> <mailto:heinrich.schuchardt at 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.schuchardt at canonical.com
>     <mailto:heinrich.schuchardt at canonical.com>
>      > <mailto:heinrich.schuchardt at canonical.com
>     <mailto: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.
>      >
>      >     Signed-off-by: Heinrich Schuchardt
>      >     <heinrich.schuchardt at canonical.com
>     <mailto:heinrich.schuchardt at canonical.com>
>      >     <mailto:heinrich.schuchardt at canonical.com
>     <mailto:heinrich.schuchardt at 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