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
