[PATCH 1/1] efi_loader: expose the device-tree file name
Ilias Apalodimas
ilias.apalodimas at linaro.org
Tue Oct 17 13:59:44 CEST 2023
Hi Heinrich,
On Tue, 17 Oct 2023 at 13:12, Heinrich Schuchardt <
heinrich.schuchardt at canonical.com> wrote:
> 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
>
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.apalodimas at linaro.org>
More information about the U-Boot
mailing list