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

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

[Heinrich Schuchardt]

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.schuchardt@canonical.com>
---
v4:
	Generalize the description of the content of $fdtfile.
v3:
	Add documentation
v2:
	Use a unique GUID to enable future U-Boot independent
	standardization.
	Do not try to add the variable on ACPI based systems.
---
 doc/develop/uefi/uefi.rst  | 14 ++++++++++++++
 include/efi_loader.h       |  5 +++++
 lib/efi_loader/efi_setup.c | 30 ++++++++++++++++++++++++++++++
 3 files changed, 49 insertions(+)

diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
index fb16ac743a..702c490831 100644
--- a/doc/develop/uefi/uefi.rst
+++ b/doc/develop/uefi/uefi.rst
@@ -916,6 +916,20 @@ So our final format of the FilePathList[] is::
 
     Loaded image - end node (0xff) - VenMedia - initrd_1 - [end node (0x01) - initrd_n ...] - end node (0xff)
 
+EFI variable FdtFile
+~~~~~~~~~~~~~~~~~~~~
+
+Ideally U-Boot would always expose a device-tree that can be used for booting
+any operating systems. Unfortunately operating systems like Linux sometimes
+break forward and backward compatibility. In this case there is a need to load
+an operating system version specific device-tree.
+
+U-Boot has an environment variable fdtfile identifying the device-tree file to
+load. The content of this variable is exposed as EFI variable Fdtfile, vendor
+GUID d45dde69-3bd6-40e0-90d5-6b606aa57730. It contains the device-tree path
+name as a NUL terminated ASCII string. On many architectures the file name is
+preceded by a vendor directory ('vendor-directory/board-name.dtb').
+
 Links
 -----
 
diff --git a/include/efi_loader.h b/include/efi_loader.h
index e24410505f..146e7f1bce 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -152,6 +152,11 @@ static inline efi_status_t efi_launch_capsules(void)
 	EFI_GUID(0x8108ac4e, 0x9f11, 0x4d59, \
 		 0x85, 0x0e, 0xe2, 0x1a, 0x52, 0x2c, 0x59, 0xb2)
 
+/* Vendor GUID for the FdtFile variable */
+#define VENDOR_FDTFILE_GUID \
+	EFI_GUID(0xd45dde69, 0x3bd6, 0x40e0, \
+		 0x90, 0xd5, 0x6b, 0x60, 0x6a, 0xa5, 0x77, 0x30)
+
 /* Use internal device tree when starting UEFI application */
 #define EFI_FDT_USE_INTERNAL NULL
 
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
index e6de685e87..71bcde645b 100644
--- a/lib/efi_loader/efi_setup.c
+++ b/lib/efi_loader/efi_setup.c
@@ -17,6 +17,8 @@
 
 efi_status_t efi_obj_list_initialized = OBJ_LIST_NOT_INITIALIZED;
 
+efi_guid_t vendor_fdtfile_guid = VENDOR_FDTFILE_GUID;
+
 /*
  * Allow unaligned memory access.
  *
@@ -26,6 +28,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",
+				    &vendor_fdtfile_guid,
+				    EFI_VARIABLE_BOOTSERVICE_ACCESS |
+				    EFI_VARIABLE_RUNTIME_ACCESS |
+				    EFI_VARIABLE_READ_ONLY,
+				    strlen(val) + 1, val, false);
+}
+
 /**
  * efi_init_platform_lang() - define supported languages
  *
@@ -250,6 +273,13 @@ efi_status_t efi_init_obj_list(void)
 	if (ret != EFI_SUCCESS)
 		goto out;
 
+	/* Define EFI variable FdtFile */
+	if (!CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE)) {
+		ret = efi_init_fdtfile();
+		if (ret != EFI_SUCCESS)
+			goto out;
+	}
+
 	/* Indicate supported features */
 	ret = efi_init_os_indications();
 	if (ret != EFI_SUCCESS)
-- 
2.40.1

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

[Simon Glass]

Hi Heinrich,

On Mon, 23 Oct 2023 at 23:20, Heinrich Schuchardt
<heinrich.schuchardt@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.

kernel-specific

>
> 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.schuchardt@canonical.com>
> ---
> v4:
>         Generalize the description of the content of $fdtfile.
> v3:
>         Add documentation
> v2:
>         Use a unique GUID to enable future U-Boot independent
>         standardization.
>         Do not try to add the variable on ACPI based systems.
> ---
>  doc/develop/uefi/uefi.rst  | 14 ++++++++++++++
>  include/efi_loader.h       |  5 +++++
>  lib/efi_loader/efi_setup.c | 30 ++++++++++++++++++++++++++++++
>  3 files changed, 49 insertions(+)
>
> diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
> index fb16ac743a..702c490831 100644
> --- a/doc/develop/uefi/uefi.rst
> +++ b/doc/develop/uefi/uefi.rst
> @@ -916,6 +916,20 @@ So our final format of the FilePathList[] is::
>
>      Loaded image - end node (0xff) - VenMedia - initrd_1 - [end node (0x01) - initrd_n ...] - end node (0xff)
>
> +EFI variable FdtFile
> +~~~~~~~~~~~~~~~~~~~~
> +
> +Ideally U-Boot would always expose a device-tree that can be used for booting
> +any operating systems. Unfortunately operating systems like Linux sometimes
> +break forward and backward compatibility. In this case there is a need to load
> +an operating system version specific device-tree.

This seems to be a strong statement. Given the effort that goes into
the DT, changes are supposed to be backwards-compatible. Is this
generally true, or is it just that we want an up-to-date DT for the
kernel to enable new features?

> +
> +U-Boot has an environment variable fdtfile identifying the device-tree file to
> +load. The content of this variable is exposed as EFI variable Fdtfile, vendor
> +GUID d45dde69-3bd6-40e0-90d5-6b606aa57730. It contains the device-tree path
> +name as a NUL terminated ASCII string. On many architectures the file name is

NUL-terminated

> +preceded by a vendor directory ('vendor-directory/board-name.dtb').
> +
>  Links
>  -----
>
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index e24410505f..146e7f1bce 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -152,6 +152,11 @@ static inline efi_status_t efi_launch_capsules(void)
>         EFI_GUID(0x8108ac4e, 0x9f11, 0x4d59, \
>                  0x85, 0x0e, 0xe2, 0x1a, 0x52, 0x2c, 0x59, 0xb2)
>
> +/* Vendor GUID for the FdtFile variable */
> +#define VENDOR_FDTFILE_GUID \
> +       EFI_GUID(0xd45dde69, 0x3bd6, 0x40e0, \
> +                0x90, 0xd5, 0x6b, 0x60, 0x6a, 0xa5, 0x77, 0x30)
> +
>  /* Use internal device tree when starting UEFI application */
>  #define EFI_FDT_USE_INTERNAL NULL
>
> diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
> index e6de685e87..71bcde645b 100644
> --- a/lib/efi_loader/efi_setup.c
> +++ b/lib/efi_loader/efi_setup.c
> @@ -17,6 +17,8 @@
>
>  efi_status_t efi_obj_list_initialized = OBJ_LIST_NOT_INITIALIZED;
>
> +efi_guid_t vendor_fdtfile_guid = VENDOR_FDTFILE_GUID;
> +
>  /*
>   * Allow unaligned memory access.
>   *
> @@ -26,6 +28,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",
> +                                   &vendor_fdtfile_guid,
> +                                   EFI_VARIABLE_BOOTSERVICE_ACCESS |
> +                                   EFI_VARIABLE_RUNTIME_ACCESS |
> +                                   EFI_VARIABLE_READ_ONLY,
> +                                   strlen(val) + 1, val, false);
> +}
> +
>  /**
>   * efi_init_platform_lang() - define supported languages
>   *
> @@ -250,6 +273,13 @@ efi_status_t efi_init_obj_list(void)
>         if (ret != EFI_SUCCESS)
>                 goto out;
>
> +       /* Define EFI variable FdtFile */
> +       if (!CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE)) {
> +               ret = efi_init_fdtfile();
> +               if (ret != EFI_SUCCESS)
> +                       goto out;
> +       }
> +
>         /* Indicate supported features */
>         ret = efi_init_os_indications();
>         if (ret != EFI_SUCCESS)
> --
> 2.40.1
>

Assuming my concerns above are figured out:

Reviewed-by: Simon Glass <sjg@chromium.org>

Regards,
SImon

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

[Simon Glass]

Hi Heinrich,

On Tue, 24 Oct 2023 at 18:02, Simon Glass <sjg@google.com> wrote:
>
> Hi Heinrich,
>
> On Mon, 23 Oct 2023 at 23:20, Heinrich Schuchardt
> <heinrich.schuchardt@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.
>
> kernel-specific
>
> >
> > 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.schuchardt@canonical.com>
> > ---
> > v4:
> >         Generalize the description of the content of $fdtfile.
> > v3:
> >         Add documentation
> > v2:
> >         Use a unique GUID to enable future U-Boot independent
> >         standardization.
> >         Do not try to add the variable on ACPI based systems.
> > ---
> >  doc/develop/uefi/uefi.rst  | 14 ++++++++++++++
> >  include/efi_loader.h       |  5 +++++
> >  lib/efi_loader/efi_setup.c | 30 ++++++++++++++++++++++++++++++
> >  3 files changed, 49 insertions(+)
> >
> > diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
> > index fb16ac743a..702c490831 100644
> > --- a/doc/develop/uefi/uefi.rst
> > +++ b/doc/develop/uefi/uefi.rst
> > @@ -916,6 +916,20 @@ So our final format of the FilePathList[] is::
> >
> >      Loaded image - end node (0xff) - VenMedia - initrd_1 - [end node (0x01) - initrd_n ...] - end node (0xff)
> >
> > +EFI variable FdtFile
> > +~~~~~~~~~~~~~~~~~~~~
> > +
> > +Ideally U-Boot would always expose a device-tree that can be used for booting
> > +any operating systems. Unfortunately operating systems like Linux sometimes
> > +break forward and backward compatibility. In this case there is a need to load
> > +an operating system version specific device-tree.
>
> This seems to be a strong statement. Given the effort that goes into
> the DT, changes are supposed to be backwards-compatible. Is this
> generally true, or is it just that we want an up-to-date DT for the
> kernel to enable new features?

Did you see this comment?

Regards,
Simon

>
> > +
> > +U-Boot has an environment variable fdtfile identifying the device-tree file to
> > +load. The content of this variable is exposed as EFI variable Fdtfile, vendor
> > +GUID d45dde69-3bd6-40e0-90d5-6b606aa57730. It contains the device-tree path
> > +name as a NUL terminated ASCII string. On many architectures the file name is
>
> NUL-terminated
>
> > +preceded by a vendor directory ('vendor-directory/board-name.dtb').
> > +
> >  Links
> >  -----
> >
> > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > index e24410505f..146e7f1bce 100644
> > --- a/include/efi_loader.h
> > +++ b/include/efi_loader.h
> > @@ -152,6 +152,11 @@ static inline efi_status_t efi_launch_capsules(void)
> >         EFI_GUID(0x8108ac4e, 0x9f11, 0x4d59, \
> >                  0x85, 0x0e, 0xe2, 0x1a, 0x52, 0x2c, 0x59, 0xb2)
> >
> > +/* Vendor GUID for the FdtFile variable */
> > +#define VENDOR_FDTFILE_GUID \
> > +       EFI_GUID(0xd45dde69, 0x3bd6, 0x40e0, \
> > +                0x90, 0xd5, 0x6b, 0x60, 0x6a, 0xa5, 0x77, 0x30)
> > +
> >  /* Use internal device tree when starting UEFI application */
> >  #define EFI_FDT_USE_INTERNAL NULL
> >
> > diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
> > index e6de685e87..71bcde645b 100644
> > --- a/lib/efi_loader/efi_setup.c
> > +++ b/lib/efi_loader/efi_setup.c
> > @@ -17,6 +17,8 @@
> >
> >  efi_status_t efi_obj_list_initialized = OBJ_LIST_NOT_INITIALIZED;
> >
> > +efi_guid_t vendor_fdtfile_guid = VENDOR_FDTFILE_GUID;
> > +
> >  /*
> >   * Allow unaligned memory access.
> >   *
> > @@ -26,6 +28,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",
> > +                                   &vendor_fdtfile_guid,
> > +                                   EFI_VARIABLE_BOOTSERVICE_ACCESS |
> > +                                   EFI_VARIABLE_RUNTIME_ACCESS |
> > +                                   EFI_VARIABLE_READ_ONLY,
> > +                                   strlen(val) + 1, val, false);
> > +}
> > +
> >  /**
> >   * efi_init_platform_lang() - define supported languages
> >   *
> > @@ -250,6 +273,13 @@ efi_status_t efi_init_obj_list(void)
> >         if (ret != EFI_SUCCESS)
> >                 goto out;
> >
> > +       /* Define EFI variable FdtFile */
> > +       if (!CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE)) {
> > +               ret = efi_init_fdtfile();
> > +               if (ret != EFI_SUCCESS)
> > +                       goto out;
> > +       }
> > +
> >         /* Indicate supported features */
> >         ret = efi_init_os_indications();
> >         if (ret != EFI_SUCCESS)
> > --
> > 2.40.1
> >
>
> Assuming my concerns above are figured out:
>
> Reviewed-by: Simon Glass <sjg@chromium.org>
>
> Regards,
> SImon

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

[Heinrich Schuchardt]

On 10/25/23 20:23, Simon Glass wrote:
> Hi Heinrich,
> 
> On Tue, 24 Oct 2023 at 18:02, Simon Glass <sjg@google.com> wrote:
>>
>> Hi Heinrich,
>>
>> On Mon, 23 Oct 2023 at 23:20, Heinrich Schuchardt
>> <heinrich.schuchardt@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.
>>
>> kernel-specific
>>
>>>
>>> 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.schuchardt@canonical.com>
>>> ---
>>> v4:
>>>          Generalize the description of the content of $fdtfile.
>>> v3:
>>>          Add documentation
>>> v2:
>>>          Use a unique GUID to enable future U-Boot independent
>>>          standardization.
>>>          Do not try to add the variable on ACPI based systems.
>>> ---
>>>   doc/develop/uefi/uefi.rst  | 14 ++++++++++++++
>>>   include/efi_loader.h       |  5 +++++
>>>   lib/efi_loader/efi_setup.c | 30 ++++++++++++++++++++++++++++++
>>>   3 files changed, 49 insertions(+)
>>>
>>> diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
>>> index fb16ac743a..702c490831 100644
>>> --- a/doc/develop/uefi/uefi.rst
>>> +++ b/doc/develop/uefi/uefi.rst
>>> @@ -916,6 +916,20 @@ So our final format of the FilePathList[] is::
>>>
>>>       Loaded image - end node (0xff) - VenMedia - initrd_1 - [end node (0x01) - initrd_n ...] - end node (0xff)
>>>
>>> +EFI variable FdtFile
>>> +~~~~~~~~~~~~~~~~~~~~
>>> +
>>> +Ideally U-Boot would always expose a device-tree that can be used for booting
>>> +any operating systems. Unfortunately operating systems like Linux sometimes
>>> +break forward and backward compatibility. In this case there is a need to load
>>> +an operating system version specific device-tree.
>>
>> This seems to be a strong statement. Given the effort that goes into
>> the DT, changes are supposed to be backwards-compatible. Is this
>> generally true, or is it just that we want an up-to-date DT for the
>> kernel to enable new features?
> 
> Did you see this comment?

It would have been nice to put the person which made that comment on copy.

The truth lies in the world "supposed":

The idea of a device-tree that never needs to change is quite old and 
never became true on ARM devices.

We all know Linux tends to break both forward and backward compatibility 
of device-trees. Here is a nice example:

d0c6707ca423 ("arm64: dts: allwinner: H5: NanoPi Neo Plus2: phy-mode 
rgmii-id")

Driver changes broke forward and backwards compatibility of a lot of 
Allwinner boards.

Distros will continue to load the device-tree that matches the kernel to 
get the best possible board support and need to do this efficiently.

Best regards

Heinrich

> 
> Regards,
> Simon
> 
>>
>>> +
>>> +U-Boot has an environment variable fdtfile identifying the device-tree file to
>>> +load. The content of this variable is exposed as EFI variable Fdtfile, vendor
>>> +GUID d45dde69-3bd6-40e0-90d5-6b606aa57730. It contains the device-tree path
>>> +name as a NUL terminated ASCII string. On many architectures the file name is
>>
>> NUL-terminated
>>
>>> +preceded by a vendor directory ('vendor-directory/board-name.dtb').
>>> +
>>>   Links
>>>   -----
>>>
>>> diff --git a/include/efi_loader.h b/include/efi_loader.h
>>> index e24410505f..146e7f1bce 100644
>>> --- a/include/efi_loader.h
>>> +++ b/include/efi_loader.h
>>> @@ -152,6 +152,11 @@ static inline efi_status_t efi_launch_capsules(void)
>>>          EFI_GUID(0x8108ac4e, 0x9f11, 0x4d59, \
>>>                   0x85, 0x0e, 0xe2, 0x1a, 0x52, 0x2c, 0x59, 0xb2)
>>>
>>> +/* Vendor GUID for the FdtFile variable */
>>> +#define VENDOR_FDTFILE_GUID \
>>> +       EFI_GUID(0xd45dde69, 0x3bd6, 0x40e0, \
>>> +                0x90, 0xd5, 0x6b, 0x60, 0x6a, 0xa5, 0x77, 0x30)
>>> +
>>>   /* Use internal device tree when starting UEFI application */
>>>   #define EFI_FDT_USE_INTERNAL NULL
>>>
>>> diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
>>> index e6de685e87..71bcde645b 100644
>>> --- a/lib/efi_loader/efi_setup.c
>>> +++ b/lib/efi_loader/efi_setup.c
>>> @@ -17,6 +17,8 @@
>>>
>>>   efi_status_t efi_obj_list_initialized = OBJ_LIST_NOT_INITIALIZED;
>>>
>>> +efi_guid_t vendor_fdtfile_guid = VENDOR_FDTFILE_GUID;
>>> +
>>>   /*
>>>    * Allow unaligned memory access.
>>>    *
>>> @@ -26,6 +28,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",
>>> +                                   &vendor_fdtfile_guid,
>>> +                                   EFI_VARIABLE_BOOTSERVICE_ACCESS |
>>> +                                   EFI_VARIABLE_RUNTIME_ACCESS |
>>> +                                   EFI_VARIABLE_READ_ONLY,
>>> +                                   strlen(val) + 1, val, false);
>>> +}
>>> +
>>>   /**
>>>    * efi_init_platform_lang() - define supported languages
>>>    *
>>> @@ -250,6 +273,13 @@ efi_status_t efi_init_obj_list(void)
>>>          if (ret != EFI_SUCCESS)
>>>                  goto out;
>>>
>>> +       /* Define EFI variable FdtFile */
>>> +       if (!CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE)) {
>>> +               ret = efi_init_fdtfile();
>>> +               if (ret != EFI_SUCCESS)
>>> +                       goto out;
>>> +       }
>>> +
>>>          /* Indicate supported features */
>>>          ret = efi_init_os_indications();
>>>          if (ret != EFI_SUCCESS)
>>> --
>>> 2.40.1
>>>
>>
>> Assuming my concerns above are figured out:
>>
>> Reviewed-by: Simon Glass <sjg@chromium.org>
>>
>> Regards,
>> SImon

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

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 4500 bytes --]

On Wed, Oct 25, 2023 at 09:57:44PM +0200, Heinrich Schuchardt wrote:
> On 10/25/23 20:23, Simon Glass wrote:
> > Hi Heinrich,
> > 
> > On Tue, 24 Oct 2023 at 18:02, Simon Glass <sjg@google.com> wrote:
> > > 
> > > Hi Heinrich,
> > > 
> > > On Mon, 23 Oct 2023 at 23:20, Heinrich Schuchardt
> > > <heinrich.schuchardt@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.
> > > 
> > > kernel-specific
> > > 
> > > > 
> > > > 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.schuchardt@canonical.com>
> > > > ---
> > > > v4:
> > > >          Generalize the description of the content of $fdtfile.
> > > > v3:
> > > >          Add documentation
> > > > v2:
> > > >          Use a unique GUID to enable future U-Boot independent
> > > >          standardization.
> > > >          Do not try to add the variable on ACPI based systems.
> > > > ---
> > > >   doc/develop/uefi/uefi.rst  | 14 ++++++++++++++
> > > >   include/efi_loader.h       |  5 +++++
> > > >   lib/efi_loader/efi_setup.c | 30 ++++++++++++++++++++++++++++++
> > > >   3 files changed, 49 insertions(+)
> > > > 
> > > > diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
> > > > index fb16ac743a..702c490831 100644
> > > > --- a/doc/develop/uefi/uefi.rst
> > > > +++ b/doc/develop/uefi/uefi.rst
> > > > @@ -916,6 +916,20 @@ So our final format of the FilePathList[] is::
> > > > 
> > > >       Loaded image - end node (0xff) - VenMedia - initrd_1 - [end node (0x01) - initrd_n ...] - end node (0xff)
> > > > 
> > > > +EFI variable FdtFile
> > > > +~~~~~~~~~~~~~~~~~~~~
> > > > +
> > > > +Ideally U-Boot would always expose a device-tree that can be used for booting
> > > > +any operating systems. Unfortunately operating systems like Linux sometimes
> > > > +break forward and backward compatibility. In this case there is a need to load
> > > > +an operating system version specific device-tree.
> > > 
> > > This seems to be a strong statement. Given the effort that goes into
> > > the DT, changes are supposed to be backwards-compatible. Is this
> > > generally true, or is it just that we want an up-to-date DT for the
> > > kernel to enable new features?
> > 
> > Did you see this comment?
> 
> It would have been nice to put the person which made that comment on copy.
> 
> The truth lies in the world "supposed":
> 
> The idea of a device-tree that never needs to change is quite old and never
> became true on ARM devices.
> 
> We all know Linux tends to break both forward and backward compatibility of
> device-trees. Here is a nice example:
> 
> d0c6707ca423 ("arm64: dts: allwinner: H5: NanoPi Neo Plus2: phy-mode
> rgmii-id")
> 
> Driver changes broke forward and backwards compatibility of a lot of
> Allwinner boards.
> 
> Distros will continue to load the device-tree that matches the kernel to get
> the best possible board support and need to do this efficiently.

Right, OK. And I think we want to try and have things phrased in a more
neutral and less confrontational manner is part of the issue. Maybe:

In ideal circumstances, U-Boot will be able to expose the device-tree it
is using to boot any operation system. However, in some cases operating
systems need to load a specific device-tree rather than utilize the same
one that U-Boot is currently using. In this case there is a need to load
a specific device-tree binary from another location.

And as a more general concern I see right now, "fdt_file" and "fdtfile"
are both used today, including new rather than older platforms that
might avoid EFI_LOADER all the same, perhaps we should check for both?
Or do you instead want to get board maintainers to switch over, as
fdt_file isn't listed under doc/ today.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

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

[Mark Kettenis]

> Date: Wed, 25 Oct 2023 21:57:44 +0200
> From: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
> 
> On 10/25/23 20:23, Simon Glass wrote:
> > Hi Heinrich,
> > 
> > On Tue, 24 Oct 2023 at 18:02, Simon Glass <sjg@google.com> wrote:
> >>
> >> Hi Heinrich,
> >>
> >> On Mon, 23 Oct 2023 at 23:20, Heinrich Schuchardt
> >> <heinrich.schuchardt@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.
> >>
> >> kernel-specific
> >>
> >>>
> >>> 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.schuchardt@canonical.com>
> >>> ---
> >>> v4:
> >>>          Generalize the description of the content of $fdtfile.
> >>> v3:
> >>>          Add documentation
> >>> v2:
> >>>          Use a unique GUID to enable future U-Boot independent
> >>>          standardization.
> >>>          Do not try to add the variable on ACPI based systems.
> >>> ---
> >>>   doc/develop/uefi/uefi.rst  | 14 ++++++++++++++
> >>>   include/efi_loader.h       |  5 +++++
> >>>   lib/efi_loader/efi_setup.c | 30 ++++++++++++++++++++++++++++++
> >>>   3 files changed, 49 insertions(+)
> >>>
> >>> diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
> >>> index fb16ac743a..702c490831 100644
> >>> --- a/doc/develop/uefi/uefi.rst
> >>> +++ b/doc/develop/uefi/uefi.rst
> >>> @@ -916,6 +916,20 @@ So our final format of the FilePathList[] is::
> >>>
> >>>       Loaded image - end node (0xff) - VenMedia - initrd_1 - [end node (0x01) - initrd_n ...] - end node (0xff)
> >>>
> >>> +EFI variable FdtFile
> >>> +~~~~~~~~~~~~~~~~~~~~
> >>> +
> >>> +Ideally U-Boot would always expose a device-tree that can be used for booting
> >>> +any operating systems. Unfortunately operating systems like Linux sometimes
> >>> +break forward and backward compatibility. In this case there is a need to load
> >>> +an operating system version specific device-tree.
> >>
> >> This seems to be a strong statement. Given the effort that goes into
> >> the DT, changes are supposed to be backwards-compatible. Is this
> >> generally true, or is it just that we want an up-to-date DT for the
> >> kernel to enable new features?
> > 
> > Did you see this comment?
> 
> It would have been nice to put the person which made that comment on copy.
> 
> The truth lies in the world "supposed":
> 
> The idea of a device-tree that never needs to change is quite old and 
> never became true on ARM devices.
> 
> We all know Linux tends to break both forward and backward compatibility 
> of device-trees. Here is a nice example:
> 
> d0c6707ca423 ("arm64: dts: allwinner: H5: NanoPi Neo Plus2: phy-mode 
> rgmii-id")
> 
> Driver changes broke forward and backwards compatibility of a lot of 
> Allwinner boards.

Well, that happened in 2020.  Things have gotten better over time.

> Distros will continue to load the device-tree that matches the kernel to 
> get the best possible board support and need to do this efficiently.

Right.  Even if there is full backward/forward compatibility, you
probably want the latest device-tree to make sure you get the most
complete hardware support.

But this shouldn't be used as an argument to not care about
backward/forward compatibility.

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

[Heinrich Schuchardt]

On 10/25/23 22:28, Mark Kettenis wrote:
>> Date: Wed, 25 Oct 2023 21:57:44 +0200
>> From: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
>>
>> On 10/25/23 20:23, Simon Glass wrote:
>>> Hi Heinrich,
>>>
>>> On Tue, 24 Oct 2023 at 18:02, Simon Glass <sjg@google.com> wrote:
>>>>
>>>> Hi Heinrich,
>>>>
>>>> On Mon, 23 Oct 2023 at 23:20, Heinrich Schuchardt
>>>> <heinrich.schuchardt@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.
>>>>
>>>> kernel-specific
>>>>
>>>>>
>>>>> 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.schuchardt@canonical.com>
>>>>> ---
>>>>> v4:
>>>>>           Generalize the description of the content of $fdtfile.
>>>>> v3:
>>>>>           Add documentation
>>>>> v2:
>>>>>           Use a unique GUID to enable future U-Boot independent
>>>>>           standardization.
>>>>>           Do not try to add the variable on ACPI based systems.
>>>>> ---
>>>>>    doc/develop/uefi/uefi.rst  | 14 ++++++++++++++
>>>>>    include/efi_loader.h       |  5 +++++
>>>>>    lib/efi_loader/efi_setup.c | 30 ++++++++++++++++++++++++++++++
>>>>>    3 files changed, 49 insertions(+)
>>>>>
>>>>> diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
>>>>> index fb16ac743a..702c490831 100644
>>>>> --- a/doc/develop/uefi/uefi.rst
>>>>> +++ b/doc/develop/uefi/uefi.rst
>>>>> @@ -916,6 +916,20 @@ So our final format of the FilePathList[] is::
>>>>>
>>>>>        Loaded image - end node (0xff) - VenMedia - initrd_1 - [end node (0x01) - initrd_n ...] - end node (0xff)
>>>>>
>>>>> +EFI variable FdtFile
>>>>> +~~~~~~~~~~~~~~~~~~~~
>>>>> +
>>>>> +Ideally U-Boot would always expose a device-tree that can be used for booting
>>>>> +any operating systems. Unfortunately operating systems like Linux sometimes
>>>>> +break forward and backward compatibility. In this case there is a need to load
>>>>> +an operating system version specific device-tree.
>>>>
>>>> This seems to be a strong statement. Given the effort that goes into
>>>> the DT, changes are supposed to be backwards-compatible. Is this
>>>> generally true, or is it just that we want an up-to-date DT for the
>>>> kernel to enable new features?
>>>
>>> Did you see this comment?
>>
>> It would have been nice to put the person which made that comment on copy.
>>
>> The truth lies in the world "supposed":
>>
>> The idea of a device-tree that never needs to change is quite old and
>> never became true on ARM devices.
>>
>> We all know Linux tends to break both forward and backward compatibility
>> of device-trees. Here is a nice example:
>>
>> d0c6707ca423 ("arm64: dts: allwinner: H5: NanoPi Neo Plus2: phy-mode
>> rgmii-id")
>>
>> Driver changes broke forward and backwards compatibility of a lot of
>> Allwinner boards.
> 
> Well, that happened in 2020.  Things have gotten better over time.

The 2020 event struck me because a Linux kernel would not even be 
compatible with the device-tree of the same kernel release.

This year I once again had issues with booting an Allwinner board with a 
device-tree from a different Debian kernel version. Both backward and 
forward compatibility were broken. But at least I could boot with a 
matching device-tree.

> 
>> Distros will continue to load the device-tree that matches the kernel to
>> get the best possible board support and need to do this efficiently.
> 
> Right.  Even if there is full backward/forward compatibility, you
> probably want the latest device-tree to make sure you get the most
> complete hardware support.
> 
> But this shouldn't be used as an argument to not care about
> backward/forward compatibility.

Nobody in this thread suggested to not care about forward and backward 
compatibility.

Best regards

Heinrich

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

[Simon Glass]

Hi Heinrich,

On Wed, 25 Oct 2023 at 20:51, Heinrich Schuchardt
<heinrich.schuchardt@canonical.com> wrote:
>
> On 10/25/23 22:28, Mark Kettenis wrote:
> >> Date: Wed, 25 Oct 2023 21:57:44 +0200
> >> From: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
> >>
> >> On 10/25/23 20:23, Simon Glass wrote:
> >>> Hi Heinrich,
> >>>
> >>> On Tue, 24 Oct 2023 at 18:02, Simon Glass <sjg@google.com> wrote:
> >>>>
> >>>> Hi Heinrich,
> >>>>
> >>>> On Mon, 23 Oct 2023 at 23:20, Heinrich Schuchardt
> >>>> <heinrich.schuchardt@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.
> >>>>
> >>>> kernel-specific
> >>>>
> >>>>>
> >>>>> 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.schuchardt@canonical.com>
> >>>>> ---
> >>>>> v4:
> >>>>>           Generalize the description of the content of $fdtfile.
> >>>>> v3:
> >>>>>           Add documentation
> >>>>> v2:
> >>>>>           Use a unique GUID to enable future U-Boot independent
> >>>>>           standardization.
> >>>>>           Do not try to add the variable on ACPI based systems.
> >>>>> ---
> >>>>>    doc/develop/uefi/uefi.rst  | 14 ++++++++++++++
> >>>>>    include/efi_loader.h       |  5 +++++
> >>>>>    lib/efi_loader/efi_setup.c | 30 ++++++++++++++++++++++++++++++
> >>>>>    3 files changed, 49 insertions(+)
> >>>>>
> >>>>> diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
> >>>>> index fb16ac743a..702c490831 100644
> >>>>> --- a/doc/develop/uefi/uefi.rst
> >>>>> +++ b/doc/develop/uefi/uefi.rst
> >>>>> @@ -916,6 +916,20 @@ So our final format of the FilePathList[] is::
> >>>>>
> >>>>>        Loaded image - end node (0xff) - VenMedia - initrd_1 - [end node (0x01) - initrd_n ...] - end node (0xff)
> >>>>>
> >>>>> +EFI variable FdtFile
> >>>>> +~~~~~~~~~~~~~~~~~~~~
> >>>>> +
> >>>>> +Ideally U-Boot would always expose a device-tree that can be used for booting
> >>>>> +any operating systems. Unfortunately operating systems like Linux sometimes
> >>>>> +break forward and backward compatibility. In this case there is a need to load
> >>>>> +an operating system version specific device-tree.
> >>>>
> >>>> This seems to be a strong statement. Given the effort that goes into
> >>>> the DT, changes are supposed to be backwards-compatible. Is this
> >>>> generally true, or is it just that we want an up-to-date DT for the
> >>>> kernel to enable new features?
> >>>
> >>> Did you see this comment?
> >>
> >> It would have been nice to put the person which made that comment on copy.
> >>
> >> The truth lies in the world "supposed":
> >>
> >> The idea of a device-tree that never needs to change is quite old and
> >> never became true on ARM devices.
> >>
> >> We all know Linux tends to break both forward and backward compatibility
> >> of device-trees. Here is a nice example:
> >>
> >> d0c6707ca423 ("arm64: dts: allwinner: H5: NanoPi Neo Plus2: phy-mode
> >> rgmii-id")
> >>
> >> Driver changes broke forward and backwards compatibility of a lot of
> >> Allwinner boards.
> >
> > Well, that happened in 2020.  Things have gotten better over time.
>
> The 2020 event struck me because a Linux kernel would not even be
> compatible with the device-tree of the same kernel release.
>
> This year I once again had issues with booting an Allwinner board with a
> device-tree from a different Debian kernel version. Both backward and
> forward compatibility were broken. But at least I could boot with a
> matching device-tree.

Oh dear.

>
> >
> >> Distros will continue to load the device-tree that matches the kernel to
> >> get the best possible board support and need to do this efficiently.
> >
> > Right.  Even if there is full backward/forward compatibility, you
> > probably want the latest device-tree to make sure you get the most
> > complete hardware support.
> >
> > But this shouldn't be used as an argument to not care about
> > backward/forward compatibility.
>
> Nobody in this thread suggested to not care about forward and backward
> compatibility.

The key thing we need to agree on is that the compatible string is the
source of truth for booting. You check the model compatible and search
for a matching DT with the best match, taking into account board
revisions, etc. It is defined to be correct. If for some reason this
process is wrong, then the board *should not boot*.

So anything which suggests that the above is not correct, or doesn't
always work, or doesn't work well with EFI...is really going in the
wrong direction.

Of course there will be workarounds, like this one, but the 'correct'
way of doing it must still work. Nor is it 'slow' to do this, as I
have demonstrated.

Perhaps we should add a compatible check into U-Boot, to make sure we
are not choosing the wrong DT? At least for me, trying to get the
filename right is a bit of a pain, with so many characters looking the
same.

Regards,
Simon

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

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 4370 bytes --]

On Wed, Oct 25, 2023 at 10:28:05PM +0200, Mark Kettenis wrote:
> > Date: Wed, 25 Oct 2023 21:57:44 +0200
> > From: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
> > 
> > On 10/25/23 20:23, Simon Glass wrote:
> > > Hi Heinrich,
> > > 
> > > On Tue, 24 Oct 2023 at 18:02, Simon Glass <sjg@google.com> wrote:
> > >>
> > >> Hi Heinrich,
> > >>
> > >> On Mon, 23 Oct 2023 at 23:20, Heinrich Schuchardt
> > >> <heinrich.schuchardt@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.
> > >>
> > >> kernel-specific
> > >>
> > >>>
> > >>> 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.schuchardt@canonical.com>
> > >>> ---
> > >>> v4:
> > >>>          Generalize the description of the content of $fdtfile.
> > >>> v3:
> > >>>          Add documentation
> > >>> v2:
> > >>>          Use a unique GUID to enable future U-Boot independent
> > >>>          standardization.
> > >>>          Do not try to add the variable on ACPI based systems.
> > >>> ---
> > >>>   doc/develop/uefi/uefi.rst  | 14 ++++++++++++++
> > >>>   include/efi_loader.h       |  5 +++++
> > >>>   lib/efi_loader/efi_setup.c | 30 ++++++++++++++++++++++++++++++
> > >>>   3 files changed, 49 insertions(+)
> > >>>
> > >>> diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
> > >>> index fb16ac743a..702c490831 100644
> > >>> --- a/doc/develop/uefi/uefi.rst
> > >>> +++ b/doc/develop/uefi/uefi.rst
> > >>> @@ -916,6 +916,20 @@ So our final format of the FilePathList[] is::
> > >>>
> > >>>       Loaded image - end node (0xff) - VenMedia - initrd_1 - [end node (0x01) - initrd_n ...] - end node (0xff)
> > >>>
> > >>> +EFI variable FdtFile
> > >>> +~~~~~~~~~~~~~~~~~~~~
> > >>> +
> > >>> +Ideally U-Boot would always expose a device-tree that can be used for booting
> > >>> +any operating systems. Unfortunately operating systems like Linux sometimes
> > >>> +break forward and backward compatibility. In this case there is a need to load
> > >>> +an operating system version specific device-tree.
> > >>
> > >> This seems to be a strong statement. Given the effort that goes into
> > >> the DT, changes are supposed to be backwards-compatible. Is this
> > >> generally true, or is it just that we want an up-to-date DT for the
> > >> kernel to enable new features?
> > > 
> > > Did you see this comment?
> > 
> > It would have been nice to put the person which made that comment on copy.
> > 
> > The truth lies in the world "supposed":
> > 
> > The idea of a device-tree that never needs to change is quite old and 
> > never became true on ARM devices.
> > 
> > We all know Linux tends to break both forward and backward compatibility 
> > of device-trees. Here is a nice example:
> > 
> > d0c6707ca423 ("arm64: dts: allwinner: H5: NanoPi Neo Plus2: phy-mode 
> > rgmii-id")
> > 
> > Driver changes broke forward and backwards compatibility of a lot of 
> > Allwinner boards.
> 
> Well, that happened in 2020.  Things have gotten better over time.

Well, yes and no.  Given the brief summary here, I bet this was just
like when phy-mode and am335x platforms had DT compatibility broken and
the answer was that it was OK because the DT was incorrectly describing
hardware. So this is the reminder that there are cases of breaking DT
compatibility that are allowed. Even if the DT has been out (and wrong)
for several years.

That's not the main point of this thread and I don't want to derail
things further along this point, I just want to note that the details
here reminded me of when things are allowed to be incompatible with
previous trees.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

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

[Heinrich Schuchardt]

On 10/25/23 23:13, Tom Rini wrote:
> On Wed, Oct 25, 2023 at 10:28:05PM +0200, Mark Kettenis wrote:
>>> Date: Wed, 25 Oct 2023 21:57:44 +0200
>>> From: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
>>>
>>> On 10/25/23 20:23, Simon Glass wrote:
>>>> Hi Heinrich,
>>>>
>>>> On Tue, 24 Oct 2023 at 18:02, Simon Glass <sjg@google.com> wrote:
>>>>>
>>>>> Hi Heinrich,
>>>>>
>>>>> On Mon, 23 Oct 2023 at 23:20, Heinrich Schuchardt
>>>>> <heinrich.schuchardt@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.
>>>>>
>>>>> kernel-specific
>>>>>
>>>>>>
>>>>>> 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.schuchardt@canonical.com>
>>>>>> ---
>>>>>> v4:
>>>>>>           Generalize the description of the content of $fdtfile.
>>>>>> v3:
>>>>>>           Add documentation
>>>>>> v2:
>>>>>>           Use a unique GUID to enable future U-Boot independent
>>>>>>           standardization.
>>>>>>           Do not try to add the variable on ACPI based systems.
>>>>>> ---
>>>>>>    doc/develop/uefi/uefi.rst  | 14 ++++++++++++++
>>>>>>    include/efi_loader.h       |  5 +++++
>>>>>>    lib/efi_loader/efi_setup.c | 30 ++++++++++++++++++++++++++++++
>>>>>>    3 files changed, 49 insertions(+)
>>>>>>
>>>>>> diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
>>>>>> index fb16ac743a..702c490831 100644
>>>>>> --- a/doc/develop/uefi/uefi.rst
>>>>>> +++ b/doc/develop/uefi/uefi.rst
>>>>>> @@ -916,6 +916,20 @@ So our final format of the FilePathList[] is::
>>>>>>
>>>>>>        Loaded image - end node (0xff) - VenMedia - initrd_1 - [end node (0x01) - initrd_n ...] - end node (0xff)
>>>>>>
>>>>>> +EFI variable FdtFile
>>>>>> +~~~~~~~~~~~~~~~~~~~~
>>>>>> +
>>>>>> +Ideally U-Boot would always expose a device-tree that can be used for booting
>>>>>> +any operating systems. Unfortunately operating systems like Linux sometimes
>>>>>> +break forward and backward compatibility. In this case there is a need to load
>>>>>> +an operating system version specific device-tree.
>>>>>
>>>>> This seems to be a strong statement. Given the effort that goes into
>>>>> the DT, changes are supposed to be backwards-compatible. Is this
>>>>> generally true, or is it just that we want an up-to-date DT for the
>>>>> kernel to enable new features?
>>>>
>>>> Did you see this comment?
>>>
>>> It would have been nice to put the person which made that comment on copy.
>>>
>>> The truth lies in the world "supposed":
>>>
>>> The idea of a device-tree that never needs to change is quite old and
>>> never became true on ARM devices.
>>>
>>> We all know Linux tends to break both forward and backward compatibility
>>> of device-trees. Here is a nice example:
>>>
>>> d0c6707ca423 ("arm64: dts: allwinner: H5: NanoPi Neo Plus2: phy-mode
>>> rgmii-id")
>>>
>>> Driver changes broke forward and backwards compatibility of a lot of
>>> Allwinner boards.
>>
>> Well, that happened in 2020.  Things have gotten better over time.
> 
> Well, yes and no.  Given the brief summary here, I bet this was just
> like when phy-mode and am335x platforms had DT compatibility broken and
> the answer was that it was OK because the DT was incorrectly describing
> hardware. So this is the reminder that there are cases of breaking DT
> compatibility that are allowed. Even if the DT has been out (and wrong)
> for several years.
> 
> That's not the main point of this thread and I don't want to derail
> things further along this point, I just want to note that the details
> here reminded me of when things are allowed to be incompatible with
> previous trees.
> 

You are conflating things:

The EFI variable is a hint to the GRUB OS to find the correct 
device-tree file without scanning hundreds of device-tree. You can not 
build a compatibility check for it into U-Boot.

In distro-boot we are using the same value from environment variable 
$fdtfile. Here you could check the compatible string but this might 
break booting .

Best regards

Heinrich

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

[Simon Glass]

Hi Heinrich,

On Wed, 25 Oct 2023 at 15:22, Heinrich Schuchardt
<heinrich.schuchardt@canonical.com> wrote:
>
> On 10/25/23 23:13, Tom Rini wrote:
> > On Wed, Oct 25, 2023 at 10:28:05PM +0200, Mark Kettenis wrote:
> >>> Date: Wed, 25 Oct 2023 21:57:44 +0200
> >>> From: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
> >>>
> >>> On 10/25/23 20:23, Simon Glass wrote:
> >>>> Hi Heinrich,
> >>>>
> >>>> On Tue, 24 Oct 2023 at 18:02, Simon Glass <sjg@google.com> wrote:
> >>>>>
> >>>>> Hi Heinrich,
> >>>>>
> >>>>> On Mon, 23 Oct 2023 at 23:20, Heinrich Schuchardt
> >>>>> <heinrich.schuchardt@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.
> >>>>>
> >>>>> kernel-specific
> >>>>>
> >>>>>>
> >>>>>> 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.schuchardt@canonical.com>
> >>>>>> ---
> >>>>>> v4:
> >>>>>>           Generalize the description of the content of $fdtfile.
> >>>>>> v3:
> >>>>>>           Add documentation
> >>>>>> v2:
> >>>>>>           Use a unique GUID to enable future U-Boot independent
> >>>>>>           standardization.
> >>>>>>           Do not try to add the variable on ACPI based systems.
> >>>>>> ---
> >>>>>>    doc/develop/uefi/uefi.rst  | 14 ++++++++++++++
> >>>>>>    include/efi_loader.h       |  5 +++++
> >>>>>>    lib/efi_loader/efi_setup.c | 30 ++++++++++++++++++++++++++++++
> >>>>>>    3 files changed, 49 insertions(+)
> >>>>>>
> >>>>>> diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
> >>>>>> index fb16ac743a..702c490831 100644
> >>>>>> --- a/doc/develop/uefi/uefi.rst
> >>>>>> +++ b/doc/develop/uefi/uefi.rst
> >>>>>> @@ -916,6 +916,20 @@ So our final format of the FilePathList[] is::
> >>>>>>
> >>>>>>        Loaded image - end node (0xff) - VenMedia - initrd_1 - [end node (0x01) - initrd_n ...] - end node (0xff)
> >>>>>>
> >>>>>> +EFI variable FdtFile
> >>>>>> +~~~~~~~~~~~~~~~~~~~~
> >>>>>> +
> >>>>>> +Ideally U-Boot would always expose a device-tree that can be used for booting
> >>>>>> +any operating systems. Unfortunately operating systems like Linux sometimes
> >>>>>> +break forward and backward compatibility. In this case there is a need to load
> >>>>>> +an operating system version specific device-tree.
> >>>>>
> >>>>> This seems to be a strong statement. Given the effort that goes into
> >>>>> the DT, changes are supposed to be backwards-compatible. Is this
> >>>>> generally true, or is it just that we want an up-to-date DT for the
> >>>>> kernel to enable new features?
> >>>>
> >>>> Did you see this comment?
> >>>
> >>> It would have been nice to put the person which made that comment on copy.
> >>>
> >>> The truth lies in the world "supposed":
> >>>
> >>> The idea of a device-tree that never needs to change is quite old and
> >>> never became true on ARM devices.
> >>>
> >>> We all know Linux tends to break both forward and backward compatibility
> >>> of device-trees. Here is a nice example:
> >>>
> >>> d0c6707ca423 ("arm64: dts: allwinner: H5: NanoPi Neo Plus2: phy-mode
> >>> rgmii-id")
> >>>
> >>> Driver changes broke forward and backwards compatibility of a lot of
> >>> Allwinner boards.
> >>
> >> Well, that happened in 2020.  Things have gotten better over time.
> >
> > Well, yes and no.  Given the brief summary here, I bet this was just
> > like when phy-mode and am335x platforms had DT compatibility broken and
> > the answer was that it was OK because the DT was incorrectly describing
> > hardware. So this is the reminder that there are cases of breaking DT
> > compatibility that are allowed. Even if the DT has been out (and wrong)
> > for several years.
> >
> > That's not the main point of this thread and I don't want to derail
> > things further along this point, I just want to note that the details
> > here reminded me of when things are allowed to be incompatible with
> > previous trees.
> >
>

Unfortunately I was off the list for a week or so, but I see this one
so will reply here.

> You are conflating things:
>
> The EFI variable is a hint to the GRUB OS to find the correct
> device-tree file without scanning hundreds of device-tree. You can not
> build a compatibility check for it into U-Boot.

Actually we can...and I think that is what we should do.

>
> In distro-boot we are using the same value from environment variable
> $fdtfile. Here you could check the compatible string but this might
> break booting .

We need to figure that point out. The compatible string is
programmatically is defined to be correct, so it is the filename that
may/may not be useful. What am I missing?

For distro-boot, do you mean the scripts? We are trying to deprecate
those. Of course we have brought in all the same work-arounds, etc.,
but with bootstd we can start to clean things up, I hope.

So let's think about how we can have U-Boot choose the right DT to boot with.

Regards,
Simon

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

[Caleb Connolly]

Hi all,

Reviving this as it is still very much an issue, and especially relevant 
for Qualcomm platforms.

On 11/3/23 20:44, Simon Glass wrote:
> Hi Heinrich,
> 
> On Wed, 25 Oct 2023 at 15:22, Heinrich Schuchardt
> <heinrich.schuchardt@canonical.com> wrote:
>>
>> On 10/25/23 23:13, Tom Rini wrote:
>>> On Wed, Oct 25, 2023 at 10:28:05PM +0200, Mark Kettenis wrote:
>>>>> Date: Wed, 25 Oct 2023 21:57:44 +0200
>>>>> From: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
>>>>>
>>>>> On 10/25/23 20:23, Simon Glass wrote:
>>>>>> Hi Heinrich,
>>>>>>
>>>>>> On Tue, 24 Oct 2023 at 18:02, Simon Glass <sjg@google.com> wrote:
>>>>>>>
>>>>>>> Hi Heinrich,
>>>>>>>
>>>>>>> On Mon, 23 Oct 2023 at 23:20, Heinrich Schuchardt
>>>>>>> <heinrich.schuchardt@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.
>>>>>>>
>>>>>>> kernel-specific
>>>>>>>
>>>>>>>>
>>>>>>>> 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.schuchardt@canonical.com>
>>>>>>>> ---
>>>>>>>> v4:
>>>>>>>>            Generalize the description of the content of $fdtfile.
>>>>>>>> v3:
>>>>>>>>            Add documentation
>>>>>>>> v2:
>>>>>>>>            Use a unique GUID to enable future U-Boot independent
>>>>>>>>            standardization.
>>>>>>>>            Do not try to add the variable on ACPI based systems.
>>>>>>>> ---
>>>>>>>>     doc/develop/uefi/uefi.rst  | 14 ++++++++++++++
>>>>>>>>     include/efi_loader.h       |  5 +++++
>>>>>>>>     lib/efi_loader/efi_setup.c | 30 ++++++++++++++++++++++++++++++
>>>>>>>>     3 files changed, 49 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
>>>>>>>> index fb16ac743a..702c490831 100644
>>>>>>>> --- a/doc/develop/uefi/uefi.rst
>>>>>>>> +++ b/doc/develop/uefi/uefi.rst
>>>>>>>> @@ -916,6 +916,20 @@ So our final format of the FilePathList[] is::
>>>>>>>>
>>>>>>>>         Loaded image - end node (0xff) - VenMedia - initrd_1 - [end node (0x01) - initrd_n ...] - end node (0xff)
>>>>>>>>
>>>>>>>> +EFI variable FdtFile
>>>>>>>> +~~~~~~~~~~~~~~~~~~~~
>>>>>>>> +
>>>>>>>> +Ideally U-Boot would always expose a device-tree that can be used for booting
>>>>>>>> +any operating systems. Unfortunately operating systems like Linux sometimes
>>>>>>>> +break forward and backward compatibility. In this case there is a need to load
>>>>>>>> +an operating system version specific device-tree.
>>>>>>>
>>>>>>> This seems to be a strong statement. Given the effort that goes into
>>>>>>> the DT, changes are supposed to be backwards-compatible. Is this
>>>>>>> generally true, or is it just that we want an up-to-date DT for the
>>>>>>> kernel to enable new features?
>>>>>>
>>>>>> Did you see this comment?
>>>>>
>>>>> It would have been nice to put the person which made that comment on copy.
>>>>>
>>>>> The truth lies in the world "supposed":
>>>>>
>>>>> The idea of a device-tree that never needs to change is quite old and
>>>>> never became true on ARM devices.
>>>>>
>>>>> We all know Linux tends to break both forward and backward compatibility
>>>>> of device-trees. Here is a nice example:
>>>>>
>>>>> d0c6707ca423 ("arm64: dts: allwinner: H5: NanoPi Neo Plus2: phy-mode
>>>>> rgmii-id")
>>>>>
>>>>> Driver changes broke forward and backwards compatibility of a lot of
>>>>> Allwinner boards.
>>>>
>>>> Well, that happened in 2020.  Things have gotten better over time.

(kinda off-topic context on DT version compat)

 From what I've seen, there is not yet very much infrastructure or 
common practise in place in the kernel to handle parsing DTB in a 
backwards compatible way. For example there has been efforts to simplify 
the dwc3 devicetree for Qualcomm platforms with a series dating back 
about as far as this U-Boot patch!

https://lore.kernel.org/linux-arm-msm/20250318-dwc3-refactor-v5-1-90ea6e5b3ba4@oss.qualcomm.com/

Earlier versions attempted to convert the older DTS to the newer format 
internally, but after much discussion it was decided that this wasn't 
really feasible, instead the new approach is to duplicate the entire 
dwc3 driver to maintain DT compatibility.

It's obviously good to see compatibility taken seriously, since it seems 
clear that if we ever want to treat DT as firmware, the kernel will need 
to do this (and eventually vendors could ship laptops with DT out of the 
box which works with upstream -- crazier things have happened).

But I think in the mean time we still want to be able to drive distro 
adoption, and the way I see it teaching GRUB and systemd-boot about a 
new FdtFile EFI variable is going to make that way simpler...
>>>
>>> Well, yes and no.  Given the brief summary here, I bet this was just
>>> like when phy-mode and am335x platforms had DT compatibility broken and
>>> the answer was that it was OK because the DT was incorrectly describing
>>> hardware. So this is the reminder that there are cases of breaking DT
>>> compatibility that are allowed. Even if the DT has been out (and wrong)
>>> for several years.
>>>
>>> That's not the main point of this thread and I don't want to derail
>>> things further along this point, I just want to note that the details
>>> here reminded me of when things are allowed to be incompatible with
>>> previous trees.
>>>
>>
> 
> Unfortunately I was off the list for a week or so, but I see this one
> so will reply here.
> 
>> You are conflating things:
>>
>> The EFI variable is a hint to the GRUB OS to find the correct
>> device-tree file without scanning hundreds of device-tree. You can not
>> build a compatibility check for it into U-Boot.
> 
> Actually we can...and I think that is what we should do.

No, how and where an EFI bootloader app chooses to load the FDT from is 
entirely implementation dependent. It may be extremely costly to compare 
compatible strings for every single dtb, and whether or not to do so is 
the decision of the distro anyways, all we can do in U-Boot is try to 
promote best practise (which clearly isn't compatible prop comparison 
for hundreds of DTBs...)

I'll note that systemd-uki does actually do this compatible prop check, 
but this would not be feasible for regular systemd-boot.
> 
>>
>> In distro-boot we are using the same value from environment variable
>> $fdtfile. Here you could check the compatible string but this might
>> break booting .
> 
> We need to figure that point out. The compatible string is
> programmatically is defined to be correct, so it is the filename that
> may/may not be useful. What am I missing?

Current distro images don't have a way to map from compatible strings to 
a filename, but they ship DTBs as normal files on the ESP.. They often 
have multiple kernel versions installed, and therefore multiple DTB 
directories which are versioned.

U-Boot doesn't know what boot entry is picked (and should not NEED to know).

Providing FdtFile as an EFI variable will make it possible for grub and 
systemd-boot to support the same kind of "fdtdir" property that extlinux 
does, this would simply enable versioned DTB loading for distros and 
make booting wayyyyy easier.

With regards to the design, I think a good follow-up patch would set a 
default value for $fdtfile (and consequently FdtFile) from the 
DEVICE_TREE build variable as a constant (maybe only if OF_UPSTREAM is 
enabled).

This would be correct in almost all cases (and wayyy better than the 
hacky fdtfile generating code we have in mach-snapdragon right now).
> 
> For distro-boot, do you mean the scripts? We are trying to deprecate
> those. Of course we have brought in all the same work-arounds, etc.,
> but with bootstd we can start to clean things up, I hope.
> 
> So let's think about how we can have U-Boot choose the right DT to boot with.
> 
> Regards,
> Simon

Heinrich, since it's been a while, if you aren't super interested in 
re-sending this patch I'd be happy to address the wording feedback and 
re-spin it, along with a patch setting the default $fdtfile (else I can 
send that as a follow-up).

I'll also open an issue for getting support for this added to systemd-boot.

-- 
Caleb (they/them)

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

[Simon Glass]

Hi Caleb,

On Sun, 23 Mar 2025 at 12:39, Caleb Connolly <caleb.connolly@linaro.org> wrote:
>
> Hi all,
>
> Reviving this as it is still very much an issue, and especially relevant
> for Qualcomm platforms.
>
> On 11/3/23 20:44, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Wed, 25 Oct 2023 at 15:22, Heinrich Schuchardt
> > <heinrich.schuchardt@canonical.com> wrote:
> >>
> >> On 10/25/23 23:13, Tom Rini wrote:
> >>> On Wed, Oct 25, 2023 at 10:28:05PM +0200, Mark Kettenis wrote:
> >>>>> Date: Wed, 25 Oct 2023 21:57:44 +0200
> >>>>> From: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
> >>>>>
> >>>>> On 10/25/23 20:23, Simon Glass wrote:
> >>>>>> Hi Heinrich,
> >>>>>>
> >>>>>> On Tue, 24 Oct 2023 at 18:02, Simon Glass <sjg@google.com> wrote:
> >>>>>>>
> >>>>>>> Hi Heinrich,
> >>>>>>>
> >>>>>>> On Mon, 23 Oct 2023 at 23:20, Heinrich Schuchardt
> >>>>>>> <heinrich.schuchardt@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.
> >>>>>>>
> >>>>>>> kernel-specific
> >>>>>>>
> >>>>>>>>
> >>>>>>>> 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.schuchardt@canonical.com>
> >>>>>>>> ---
> >>>>>>>> v4:
> >>>>>>>>            Generalize the description of the content of $fdtfile.
> >>>>>>>> v3:
> >>>>>>>>            Add documentation
> >>>>>>>> v2:
> >>>>>>>>            Use a unique GUID to enable future U-Boot independent
> >>>>>>>>            standardization.
> >>>>>>>>            Do not try to add the variable on ACPI based systems.
> >>>>>>>> ---
> >>>>>>>>     doc/develop/uefi/uefi.rst  | 14 ++++++++++++++
> >>>>>>>>     include/efi_loader.h       |  5 +++++
> >>>>>>>>     lib/efi_loader/efi_setup.c | 30 ++++++++++++++++++++++++++++++
> >>>>>>>>     3 files changed, 49 insertions(+)
> >>>>>>>>
> >>>>>>>> diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
> >>>>>>>> index fb16ac743a..702c490831 100644
> >>>>>>>> --- a/doc/develop/uefi/uefi.rst
> >>>>>>>> +++ b/doc/develop/uefi/uefi.rst
> >>>>>>>> @@ -916,6 +916,20 @@ So our final format of the FilePathList[] is::
> >>>>>>>>
> >>>>>>>>         Loaded image - end node (0xff) - VenMedia - initrd_1 - [end node (0x01) - initrd_n ...] - end node (0xff)
> >>>>>>>>
> >>>>>>>> +EFI variable FdtFile
> >>>>>>>> +~~~~~~~~~~~~~~~~~~~~
> >>>>>>>> +
> >>>>>>>> +Ideally U-Boot would always expose a device-tree that can be used for booting
> >>>>>>>> +any operating systems. Unfortunately operating systems like Linux sometimes
> >>>>>>>> +break forward and backward compatibility. In this case there is a need to load
> >>>>>>>> +an operating system version specific device-tree.
> >>>>>>>
> >>>>>>> This seems to be a strong statement. Given the effort that goes into
> >>>>>>> the DT, changes are supposed to be backwards-compatible. Is this
> >>>>>>> generally true, or is it just that we want an up-to-date DT for the
> >>>>>>> kernel to enable new features?
> >>>>>>
> >>>>>> Did you see this comment?
> >>>>>
> >>>>> It would have been nice to put the person which made that comment on copy.
> >>>>>
> >>>>> The truth lies in the world "supposed":
> >>>>>
> >>>>> The idea of a device-tree that never needs to change is quite old and
> >>>>> never became true on ARM devices.
> >>>>>
> >>>>> We all know Linux tends to break both forward and backward compatibility
> >>>>> of device-trees. Here is a nice example:
> >>>>>
> >>>>> d0c6707ca423 ("arm64: dts: allwinner: H5: NanoPi Neo Plus2: phy-mode
> >>>>> rgmii-id")
> >>>>>
> >>>>> Driver changes broke forward and backwards compatibility of a lot of
> >>>>> Allwinner boards.
> >>>>
> >>>> Well, that happened in 2020.  Things have gotten better over time.
>
> (kinda off-topic context on DT version compat)
>
>  From what I've seen, there is not yet very much infrastructure or
> common practise in place in the kernel to handle parsing DTB in a
> backwards compatible way. For example there has been efforts to simplify
> the dwc3 devicetree for Qualcomm platforms with a series dating back
> about as far as this U-Boot patch!
>
> https://lore.kernel.org/linux-arm-msm/20250318-dwc3-refactor-v5-1-90ea6e5b3ba4@oss.qualcomm.com/
>
> Earlier versions attempted to convert the older DTS to the newer format
> internally, but after much discussion it was decided that this wasn't
> really feasible, instead the new approach is to duplicate the entire
> dwc3 driver to maintain DT compatibility.
>
> It's obviously good to see compatibility taken seriously, since it seems
> clear that if we ever want to treat DT as firmware, the kernel will need
> to do this (and eventually vendors could ship laptops with DT out of the
> box which works with upstream -- crazier things have happened).
>
> But I think in the mean time we still want to be able to drive distro
> adoption, and the way I see it teaching GRUB and systemd-boot about a
> new FdtFile EFI variable is going to make that way simpler...

GRUB is unlikely even to handle devicetree properly as it does not
implement FIT, nor the best-match algorithm in FIT. So everything is a
workaround.

> >>>
> >>> Well, yes and no.  Given the brief summary here, I bet this was just
> >>> like when phy-mode and am335x platforms had DT compatibility broken and
> >>> the answer was that it was OK because the DT was incorrectly describing
> >>> hardware. So this is the reminder that there are cases of breaking DT
> >>> compatibility that are allowed. Even if the DT has been out (and wrong)
> >>> for several years.
> >>>
> >>> That's not the main point of this thread and I don't want to derail
> >>> things further along this point, I just want to note that the details
> >>> here reminded me of when things are allowed to be incompatible with
> >>> previous trees.
> >>>
> >>
> >
> > Unfortunately I was off the list for a week or so, but I see this one
> > so will reply here.
> >
> >> You are conflating things:
> >>
> >> The EFI variable is a hint to the GRUB OS to find the correct
> >> device-tree file without scanning hundreds of device-tree. You can not
> >> build a compatibility check for it into U-Boot.
> >
> > Actually we can...and I think that is what we should do.
>
> No, how and where an EFI bootloader app chooses to load the FDT from is
> entirely implementation dependent. It may be extremely costly to compare
> compatible strings for every single dtb, and whether or not to do so is
> the decision of the distro anyways, all we can do in U-Boot is try to
> promote best practise (which clearly isn't compatible prop comparison
> for hundreds of DTBs...)

U-Boot promotes best practice, which is to check the compatible
properties of hundreds of nodes in the FIT to find the right one.

You don't need to look at the actual DTs, as the compatible string is
available in the configuration node.

See Linux 'make image.fit' for how this works.

>
> I'll note that systemd-uki does actually do this compatible prop check,
> but this would not be feasible for regular systemd-boot.

Then it can't work properly, unfortunately.

> >
> >>
> >> In distro-boot we are using the same value from environment variable
> >> $fdtfile. Here you could check the compatible string but this might
> >> break booting .
> >
> > We need to figure that point out. The compatible string is
> > programmatically is defined to be correct, so it is the filename that
> > may/may not be useful. What am I missing?
>
> Current distro images don't have a way to map from compatible strings to
> a filename, but they ship DTBs as normal files on the ESP.. They often
> have multiple kernel versions installed, and therefore multiple DTB
> directories which are versioned.

This should be handled by compatible strings. See how Chromebooks do
this, for example.

>
> U-Boot doesn't know what boot entry is picked (and should not NEED to know).

That's not germain to this discussion, but it is actually one of the
challenges with having GRUB in the chain. From U-Boot, with 'bootflow
scan' we may get a choice of booting 3 things, but one of those is
GRUB which then has another 4 of its own. It's quite messy.

>
> Providing FdtFile as an EFI variable will make it possible for grub and
> systemd-boot to support the same kind of "fdtdir" property that extlinux
> does, this would simply enable versioned DTB loading for distros and
> make booting wayyyyy easier.

It is perpetuating an incorrect approach, though. It won't lead to
happiness. Perhaps systemd-boot should support FIT?

As to versions, the compatible string needs to handle that. We cannot
have a situation where we ship two different devices trees that have
the same compatible strings but different contents as there is no
(spec-correct) way to distinguish them.

>
> With regards to the design, I think a good follow-up patch would set a
> default value for $fdtfile (and consequently FdtFile) from the
> DEVICE_TREE build variable as a constant (maybe only if OF_UPSTREAM is
> enabled).

Please no. We should not continue down this broken path.

>
> This would be correct in almost all cases (and wayyy better than the
> hacky fdtfile generating code we have in mach-snapdragon right now).

Yes, but you really should figure out how to remove that code. It is
present on other boards too. One of the things not on my list (but I
wish it were) is to clean up how RISC-V does devicetree selection
within U-Boot.

> >
> > For distro-boot, do you mean the scripts? We are trying to deprecate
> > those. Of course we have brought in all the same work-arounds, etc.,
> > but with bootstd we can start to clean things up, I hope.
> >
> > So let's think about how we can have U-Boot choose the right DT to boot with.
> >
> > Regards,
> > Simon
>
> Heinrich, since it's been a while, if you aren't super interested in
> re-sending this patch I'd be happy to address the wording feedback and
> re-spin it, along with a patch setting the default $fdtfile (else I can
> send that as a follow-up).

The best thing to do here is to use FIT. You can put all the FDTs in a
FIT and leave the kernel out, if necessary.

Another idea, which I may have suggested before (can't remember) would
be to add an EFI service which U-Boot implements, which returns the
correct FDT to use. U-Boot can then scan the files one by one to
figure it out, although hopefully that would prompt someone to create
a FIT (or a text file?) which has this information in it.

But fdtfile is just not the right approach.

>
> I'll also open an issue for getting support for this added to systemd-boot.

FIT?

Regards,
Simon

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

[Caleb Connolly]

On 3/28/25 13:01, Simon Glass wrote:
> Hi Caleb,
> 
> On Sun, 23 Mar 2025 at 12:39, Caleb Connolly <caleb.connolly@linaro.org> wrote:
>>
>> Hi all,
>>
>> Reviving this as it is still very much an issue, and especially relevant
>> for Qualcomm platforms.
>>
>> On 11/3/23 20:44, Simon Glass wrote:
>>> Hi Heinrich,
>>>
>>> On Wed, 25 Oct 2023 at 15:22, Heinrich Schuchardt
>>> <heinrich.schuchardt@canonical.com> wrote:
>>>>
>>>> On 10/25/23 23:13, Tom Rini wrote:
>>>>> On Wed, Oct 25, 2023 at 10:28:05PM +0200, Mark Kettenis wrote:
>>>>>>> Date: Wed, 25 Oct 2023 21:57:44 +0200
>>>>>>> From: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
>>>>>>>
>>>>>>> On 10/25/23 20:23, Simon Glass wrote:
>>>>>>>> Hi Heinrich,
>>>>>>>>
>>>>>>>> On Tue, 24 Oct 2023 at 18:02, Simon Glass <sjg@google.com> wrote:
>>>>>>>>>
>>>>>>>>> Hi Heinrich,
>>>>>>>>>
>>>>>>>>> On Mon, 23 Oct 2023 at 23:20, Heinrich Schuchardt
>>>>>>>>> <heinrich.schuchardt@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.
>>>>>>>>>
>>>>>>>>> kernel-specific
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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.schuchardt@canonical.com>
>>>>>>>>>> ---
>>>>>>>>>> v4:
>>>>>>>>>>             Generalize the description of the content of $fdtfile.
>>>>>>>>>> v3:
>>>>>>>>>>             Add documentation
>>>>>>>>>> v2:
>>>>>>>>>>             Use a unique GUID to enable future U-Boot independent
>>>>>>>>>>             standardization.
>>>>>>>>>>             Do not try to add the variable on ACPI based systems.
>>>>>>>>>> ---
>>>>>>>>>>      doc/develop/uefi/uefi.rst  | 14 ++++++++++++++
>>>>>>>>>>      include/efi_loader.h       |  5 +++++
>>>>>>>>>>      lib/efi_loader/efi_setup.c | 30 ++++++++++++++++++++++++++++++
>>>>>>>>>>      3 files changed, 49 insertions(+)
>>>>>>>>>>
>>>>>>>>>> diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
>>>>>>>>>> index fb16ac743a..702c490831 100644
>>>>>>>>>> --- a/doc/develop/uefi/uefi.rst
>>>>>>>>>> +++ b/doc/develop/uefi/uefi.rst
>>>>>>>>>> @@ -916,6 +916,20 @@ So our final format of the FilePathList[] is::
>>>>>>>>>>
>>>>>>>>>>          Loaded image - end node (0xff) - VenMedia - initrd_1 - [end node (0x01) - initrd_n ...] - end node (0xff)
>>>>>>>>>>
>>>>>>>>>> +EFI variable FdtFile
>>>>>>>>>> +~~~~~~~~~~~~~~~~~~~~
>>>>>>>>>> +
>>>>>>>>>> +Ideally U-Boot would always expose a device-tree that can be used for booting
>>>>>>>>>> +any operating systems. Unfortunately operating systems like Linux sometimes
>>>>>>>>>> +break forward and backward compatibility. In this case there is a need to load
>>>>>>>>>> +an operating system version specific device-tree.
>>>>>>>>>
>>>>>>>>> This seems to be a strong statement. Given the effort that goes into
>>>>>>>>> the DT, changes are supposed to be backwards-compatible. Is this
>>>>>>>>> generally true, or is it just that we want an up-to-date DT for the
>>>>>>>>> kernel to enable new features?
>>>>>>>>
>>>>>>>> Did you see this comment?
>>>>>>>
>>>>>>> It would have been nice to put the person which made that comment on copy.
>>>>>>>
>>>>>>> The truth lies in the world "supposed":
>>>>>>>
>>>>>>> The idea of a device-tree that never needs to change is quite old and
>>>>>>> never became true on ARM devices.
>>>>>>>
>>>>>>> We all know Linux tends to break both forward and backward compatibility
>>>>>>> of device-trees. Here is a nice example:
>>>>>>>
>>>>>>> d0c6707ca423 ("arm64: dts: allwinner: H5: NanoPi Neo Plus2: phy-mode
>>>>>>> rgmii-id")
>>>>>>>
>>>>>>> Driver changes broke forward and backwards compatibility of a lot of
>>>>>>> Allwinner boards.
>>>>>>
>>>>>> Well, that happened in 2020.  Things have gotten better over time.
>>
>> (kinda off-topic context on DT version compat)
>>
>>   From what I've seen, there is not yet very much infrastructure or
>> common practise in place in the kernel to handle parsing DTB in a
>> backwards compatible way. For example there has been efforts to simplify
>> the dwc3 devicetree for Qualcomm platforms with a series dating back
>> about as far as this U-Boot patch!
>>
>> https://lore.kernel.org/linux-arm-msm/20250318-dwc3-refactor-v5-1-90ea6e5b3ba4@oss.qualcomm.com/
>>
>> Earlier versions attempted to convert the older DTS to the newer format
>> internally, but after much discussion it was decided that this wasn't
>> really feasible, instead the new approach is to duplicate the entire
>> dwc3 driver to maintain DT compatibility.
>>
>> It's obviously good to see compatibility taken seriously, since it seems
>> clear that if we ever want to treat DT as firmware, the kernel will need
>> to do this (and eventually vendors could ship laptops with DT out of the
>> box which works with upstream -- crazier things have happened).
>>
>> But I think in the mean time we still want to be able to drive distro
>> adoption, and the way I see it teaching GRUB and systemd-boot about a
>> new FdtFile EFI variable is going to make that way simpler...
> 
> GRUB is unlikely even to handle devicetree properly as it does not
> implement FIT, nor the best-match algorithm in FIT. So everything is a
> workaround.

FIT has nothing to do with DT loading
> 
>>>>>
>>>>> Well, yes and no.  Given the brief summary here, I bet this was just
>>>>> like when phy-mode and am335x platforms had DT compatibility broken and
>>>>> the answer was that it was OK because the DT was incorrectly describing
>>>>> hardware. So this is the reminder that there are cases of breaking DT
>>>>> compatibility that are allowed. Even if the DT has been out (and wrong)
>>>>> for several years.
>>>>>
>>>>> That's not the main point of this thread and I don't want to derail
>>>>> things further along this point, I just want to note that the details
>>>>> here reminded me of when things are allowed to be incompatible with
>>>>> previous trees.
>>>>>
>>>>
>>>
>>> Unfortunately I was off the list for a week or so, but I see this one
>>> so will reply here.
>>>
>>>> You are conflating things:
>>>>
>>>> The EFI variable is a hint to the GRUB OS to find the correct
>>>> device-tree file without scanning hundreds of device-tree. You can not
>>>> build a compatibility check for it into U-Boot.
>>>
>>> Actually we can...and I think that is what we should do.
>>
>> No, how and where an EFI bootloader app chooses to load the FDT from is
>> entirely implementation dependent. It may be extremely costly to compare
>> compatible strings for every single dtb, and whether or not to do so is
>> the decision of the distro anyways, all we can do in U-Boot is try to
>> promote best practise (which clearly isn't compatible prop comparison
>> for hundreds of DTBs...)
> 
> U-Boot promotes best practice, which is to check the compatible
> properties of hundreds of nodes in the FIT to find the right one.

Distros don't ship FIT images (which would be absolutely huge by the 
way, 75M for all DTBs today), they ship DTBs in a directory structure 
following the kernel layout.

If the kernel started outputting FIT images with all DTBs it would have 
to be installed in addition to the directory layout, and only provide a 
considerably less efficient interface to pick a DTB.

We want Fedora images that you download today to be able to boot and 
select an appropriate DTB. FIT is just not a good fit (haha) for this 
problem.

A fit mapping compatible strings to filenames would be an improvement 
but that's so much additional complexity to come up with a value that 
U-Boot already has...

>>
>> Providing FdtFile as an EFI variable will make it possible for grub and
>> systemd-boot to support the same kind of "fdtdir" property that extlinux
>> does, this would simply enable versioned DTB loading for distros and
>> make booting wayyyyy easier.
> 
> It is perpetuating an incorrect approach, though. It won't lead to
> happiness. Perhaps systemd-boot should support FIT?

What do i even say to this. You haven't explained what's incorrect
> 
> As to versions, the compatible string needs to handle that. We cannot
> have a situation where we ship two different devices trees that have
> the same compatible strings but different contents as there is no
> (spec-correct) way to distinguish them.
> 
>>
>> With regards to the design, I think a good follow-up patch would set a
>> default value for $fdtfile (and consequently FdtFile) from the
>> DEVICE_TREE build variable as a constant (maybe only if OF_UPSTREAM is
>> enabled).
> 
> Please no. We should not continue down this broken path.

???
> 
>>
>> This would be correct in almost all cases (and wayyy better than the
>> hacky fdtfile generating code we have in mach-snapdragon right now).
> 
> Yes, but you really should figure out how to remove that code. It is
> present on other boards too. One of the things not on my list (but I
> wish it were) is to clean up how RISC-V does devicetree selection
> within U-Boot.

That is why i revived this patch...
> 
>>>
>>> For distro-boot, do you mean the scripts? We are trying to deprecate
>>> those. Of course we have brought in all the same work-arounds, etc.,
>>> but with bootstd we can start to clean things up, I hope.
>>>
>>> So let's think about how we can have U-Boot choose the right DT to boot with.
>>>
>>> Regards,
>>> Simon
>>
>> Heinrich, since it's been a while, if you aren't super interested in
>> re-sending this patch I'd be happy to address the wording feedback and
>> re-spin it, along with a patch setting the default $fdtfile (else I can
>> send that as a follow-up).
> 
> The best thing to do here is to use FIT. You can put all the FDTs in a
> FIT and leave the kernel out, if necessary.

You cannot do this, distros will not do this for thousands of FDTs
> 
> Another idea, which I may have suggested before (can't remember) would
> be to add an EFI service which U-Boot implements, which returns the
> correct FDT to use. U-Boot can then scan the files one by one to
> figure it out, although hopefully that would prompt someone to create
> a FIT (or a text file?) which has this information in it.
> 
> But fdtfile is just not the right approach.

You've pushed for FIT but never explained why fdtfile is a bad solution.
> 
>>
>> I'll also open an issue for getting support for this added to systemd-boot.
> 
> FIT?
> 
> Regards,
> Simon

-- 
Caleb (they/them)

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

[Heinrich Schuchardt]

On 28.03.25 14:00, Caleb Connolly wrote:
> 
> 
> On 3/28/25 13:01, Simon Glass wrote:
>> Hi Caleb,
>>
>> On Sun, 23 Mar 2025 at 12:39, Caleb Connolly 
>> <caleb.connolly@linaro.org> wrote:
>>>
>>> Hi all,
>>>
>>> Reviving this as it is still very much an issue, and especially relevant
>>> for Qualcomm platforms.
>>>
>>> On 11/3/23 20:44, Simon Glass wrote:
>>>> Hi Heinrich,
>>>>
>>>> On Wed, 25 Oct 2023 at 15:22, Heinrich Schuchardt
>>>> <heinrich.schuchardt@canonical.com> wrote:
>>>>>
>>>>> On 10/25/23 23:13, Tom Rini wrote:
>>>>>> On Wed, Oct 25, 2023 at 10:28:05PM +0200, Mark Kettenis wrote:
>>>>>>>> Date: Wed, 25 Oct 2023 21:57:44 +0200
>>>>>>>> From: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
>>>>>>>>
>>>>>>>> On 10/25/23 20:23, Simon Glass wrote:
>>>>>>>>> Hi Heinrich,
>>>>>>>>>
>>>>>>>>> On Tue, 24 Oct 2023 at 18:02, Simon Glass <sjg@google.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Heinrich,
>>>>>>>>>>
>>>>>>>>>> On Mon, 23 Oct 2023 at 23:20, Heinrich Schuchardt
>>>>>>>>>> <heinrich.schuchardt@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.
>>>>>>>>>>
>>>>>>>>>> kernel-specific
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 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.schuchardt@canonical.com>
>>>>>>>>>>> ---
>>>>>>>>>>> v4:
>>>>>>>>>>>             Generalize the description of the content of 
>>>>>>>>>>> $fdtfile.
>>>>>>>>>>> v3:
>>>>>>>>>>>             Add documentation
>>>>>>>>>>> v2:
>>>>>>>>>>>             Use a unique GUID to enable future U-Boot 
>>>>>>>>>>> independent
>>>>>>>>>>>             standardization.
>>>>>>>>>>>             Do not try to add the variable on ACPI based 
>>>>>>>>>>> systems.
>>>>>>>>>>> ---
>>>>>>>>>>>      doc/develop/uefi/uefi.rst  | 14 ++++++++++++++
>>>>>>>>>>>      include/efi_loader.h       |  5 +++++
>>>>>>>>>>>      lib/efi_loader/efi_setup.c | 30 ++++++++++++++++++++++++ 
>>>>>>>>>>> ++++++
>>>>>>>>>>>      3 files changed, 49 insertions(+)
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/ 
>>>>>>>>>>> uefi.rst
>>>>>>>>>>> index fb16ac743a..702c490831 100644
>>>>>>>>>>> --- a/doc/develop/uefi/uefi.rst
>>>>>>>>>>> +++ b/doc/develop/uefi/uefi.rst
>>>>>>>>>>> @@ -916,6 +916,20 @@ So our final format of the 
>>>>>>>>>>> FilePathList[] is::
>>>>>>>>>>>
>>>>>>>>>>>          Loaded image - end node (0xff) - VenMedia - initrd_1 
>>>>>>>>>>> - [end node (0x01) - initrd_n ...] - end node (0xff)
>>>>>>>>>>>
>>>>>>>>>>> +EFI variable FdtFile
>>>>>>>>>>> +~~~~~~~~~~~~~~~~~~~~
>>>>>>>>>>> +
>>>>>>>>>>> +Ideally U-Boot would always expose a device-tree that can be 
>>>>>>>>>>> used for booting
>>>>>>>>>>> +any operating systems. Unfortunately operating systems like 
>>>>>>>>>>> Linux sometimes
>>>>>>>>>>> +break forward and backward compatibility. In this case there 
>>>>>>>>>>> is a need to load
>>>>>>>>>>> +an operating system version specific device-tree.
>>>>>>>>>>
>>>>>>>>>> This seems to be a strong statement. Given the effort that 
>>>>>>>>>> goes into
>>>>>>>>>> the DT, changes are supposed to be backwards-compatible. Is this
>>>>>>>>>> generally true, or is it just that we want an up-to-date DT 
>>>>>>>>>> for the
>>>>>>>>>> kernel to enable new features?
>>>>>>>>>
>>>>>>>>> Did you see this comment?
>>>>>>>>
>>>>>>>> It would have been nice to put the person which made that 
>>>>>>>> comment on copy.
>>>>>>>>
>>>>>>>> The truth lies in the world "supposed":
>>>>>>>>
>>>>>>>> The idea of a device-tree that never needs to change is quite 
>>>>>>>> old and
>>>>>>>> never became true on ARM devices.
>>>>>>>>
>>>>>>>> We all know Linux tends to break both forward and backward 
>>>>>>>> compatibility
>>>>>>>> of device-trees. Here is a nice example:
>>>>>>>>
>>>>>>>> d0c6707ca423 ("arm64: dts: allwinner: H5: NanoPi Neo Plus2: phy- 
>>>>>>>> mode
>>>>>>>> rgmii-id")
>>>>>>>>
>>>>>>>> Driver changes broke forward and backwards compatibility of a 
>>>>>>>> lot of
>>>>>>>> Allwinner boards.
>>>>>>>
>>>>>>> Well, that happened in 2020.  Things have gotten better over time.
>>>
>>> (kinda off-topic context on DT version compat)
>>>
>>>   From what I've seen, there is not yet very much infrastructure or
>>> common practise in place in the kernel to handle parsing DTB in a
>>> backwards compatible way. For example there has been efforts to simplify
>>> the dwc3 devicetree for Qualcomm platforms with a series dating back
>>> about as far as this U-Boot patch!
>>>
>>> https://lore.kernel.org/linux-arm-msm/20250318-dwc3-refactor- 
>>> v5-1-90ea6e5b3ba4@oss.qualcomm.com/
>>>
>>> Earlier versions attempted to convert the older DTS to the newer format
>>> internally, but after much discussion it was decided that this wasn't
>>> really feasible, instead the new approach is to duplicate the entire
>>> dwc3 driver to maintain DT compatibility.
>>>
>>> It's obviously good to see compatibility taken seriously, since it seems
>>> clear that if we ever want to treat DT as firmware, the kernel will need
>>> to do this (and eventually vendors could ship laptops with DT out of the
>>> box which works with upstream -- crazier things have happened).
>>>
>>> But I think in the mean time we still want to be able to drive distro
>>> adoption, and the way I see it teaching GRUB and systemd-boot about a
>>> new FdtFile EFI variable is going to make that way simpler...

There was a discussion in the context of EBBR if this is the right way 
forward. And the general opinion was that the compatible string should 
be used for matching the dtb files.

>>
>> GRUB is unlikely even to handle devicetree properly as it does not
>> implement FIT, nor the best-match algorithm in FIT. So everything is a
>> workaround.

For the Qualcomm laptop case the current patch would not solve anything 
as the selection of the device-tree needs to be based on SMBIOS value.

Systemd-boot allows to add a rule-table to the UKI header to select 
device-trees from a UKI image.

That is a smarter solution than trying to hard-code logic in U-Boot to 
set fdtfile and an FdtFile EFI variable.

> 
> FIT has nothing to do with DT loading
>>
>>>>>>
>>>>>> Well, yes and no.  Given the brief summary here, I bet this was just
>>>>>> like when phy-mode and am335x platforms had DT compatibility 
>>>>>> broken and
>>>>>> the answer was that it was OK because the DT was incorrectly 
>>>>>> describing
>>>>>> hardware. So this is the reminder that there are cases of breaking DT
>>>>>> compatibility that are allowed. Even if the DT has been out (and 
>>>>>> wrong)
>>>>>> for several years.
>>>>>>
>>>>>> That's not the main point of this thread and I don't want to derail
>>>>>> things further along this point, I just want to note that the details
>>>>>> here reminded me of when things are allowed to be incompatible with
>>>>>> previous trees.
>>>>>>
>>>>>
>>>>
>>>> Unfortunately I was off the list for a week or so, but I see this one
>>>> so will reply here.
>>>>
>>>>> You are conflating things:
>>>>>
>>>>> The EFI variable is a hint to the GRUB OS to find the correct
>>>>> device-tree file without scanning hundreds of device-tree. You can not
>>>>> build a compatibility check for it into U-Boot.
>>>>
>>>> Actually we can...and I think that is what we should do.
>>>
>>> No, how and where an EFI bootloader app chooses to load the FDT from is
>>> entirely implementation dependent. It may be extremely costly to compare
>>> compatible strings for every single dtb, and whether or not to do so is
>>> the decision of the distro anyways, all we can do in U-Boot is try to
>>> promote best practise (which clearly isn't compatible prop comparison
>>> for hundreds of DTBs...)
>>
>> U-Boot promotes best practice, which is to check the compatible
>> properties of hundreds of nodes in the FIT to find the right one.
> 
> Distros don't ship FIT images (which would be absolutely huge by the 
> way, 75M for all DTBs today), they ship DTBs in a directory structure 
> following the kernel layout.

It might make sense to support compressed FIT images.

Whether all device-trees are stored as files in 
/lib/firmware/<kernel-version>/device-tree/ or are part of the kernel 
image (FIT or UKI) does not change the space requirement on disk.

Best regards

Heinrich

> 
> If the kernel started outputting FIT images with all DTBs it would have 
> to be installed in addition to the directory layout, and only provide a 
> considerably less efficient interface to pick a DTB.
> 
> We want Fedora images that you download today to be able to boot and 
> select an appropriate DTB. FIT is just not a good fit (haha) for this 
> problem.
> 
> A fit mapping compatible strings to filenames would be an improvement 
> but that's so much additional complexity to come up with a value that U- 
> Boot already has...
> 
>>>
>>> Providing FdtFile as an EFI variable will make it possible for grub and
>>> systemd-boot to support the same kind of "fdtdir" property that extlinux
>>> does, this would simply enable versioned DTB loading for distros and
>>> make booting wayyyyy easier.
>>
>> It is perpetuating an incorrect approach, though. It won't lead to
>> happiness. Perhaps systemd-boot should support FIT?
> 
> What do i even say to this. You haven't explained what's incorrect
>>
>> As to versions, the compatible string needs to handle that. We cannot
>> have a situation where we ship two different devices trees that have
>> the same compatible strings but different contents as there is no
>> (spec-correct) way to distinguish them.
>>
>>>
>>> With regards to the design, I think a good follow-up patch would set a
>>> default value for $fdtfile (and consequently FdtFile) from the
>>> DEVICE_TREE build variable as a constant (maybe only if OF_UPSTREAM is
>>> enabled).
>>
>> Please no. We should not continue down this broken path.
> 
> ???
>>
>>>
>>> This would be correct in almost all cases (and wayyy better than the
>>> hacky fdtfile generating code we have in mach-snapdragon right now).
>>
>> Yes, but you really should figure out how to remove that code. It is
>> present on other boards too. One of the things not on my list (but I
>> wish it were) is to clean up how RISC-V does devicetree selection
>> within U-Boot.
> 
> That is why i revived this patch...
>>
>>>>
>>>> For distro-boot, do you mean the scripts? We are trying to deprecate
>>>> those. Of course we have brought in all the same work-arounds, etc.,
>>>> but with bootstd we can start to clean things up, I hope.
>>>>
>>>> So let's think about how we can have U-Boot choose the right DT to 
>>>> boot with.
>>>>
>>>> Regards,
>>>> Simon
>>>
>>> Heinrich, since it's been a while, if you aren't super interested in
>>> re-sending this patch I'd be happy to address the wording feedback and
>>> re-spin it, along with a patch setting the default $fdtfile (else I can
>>> send that as a follow-up).
>>
>> The best thing to do here is to use FIT. You can put all the FDTs in a
>> FIT and leave the kernel out, if necessary.
> 
> You cannot do this, distros will not do this for thousands of FDTs
>>
>> Another idea, which I may have suggested before (can't remember) would
>> be to add an EFI service which U-Boot implements, which returns the
>> correct FDT to use. U-Boot can then scan the files one by one to
>> figure it out, although hopefully that would prompt someone to create
>> a FIT (or a text file?) which has this information in it.
>>
>> But fdtfile is just not the right approach.
> 
> You've pushed for FIT but never explained why fdtfile is a bad solution.
>>
>>>
>>> I'll also open an issue for getting support for this added to 
>>> systemd-boot.
>>
>> FIT?
>>
>> Regards,
>> Simon
> 

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

[Caleb Connolly]

Hi Heinrich,

On 3/28/25 15:18, Heinrich Schuchardt wrote:
> On 28.03.25 14:00, Caleb Connolly wrote:
>>
>>
>> On 3/28/25 13:01, Simon Glass wrote:
>>> Hi Caleb,
>>>
>>> On Sun, 23 Mar 2025 at 12:39, Caleb Connolly 
>>> <caleb.connolly@linaro.org> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Reviving this as it is still very much an issue, and especially 
>>>> relevant
>>>> for Qualcomm platforms.
>>>>
>>>> On 11/3/23 20:44, Simon Glass wrote:
>>>>> Hi Heinrich,
>>>>>
>>>>> On Wed, 25 Oct 2023 at 15:22, Heinrich Schuchardt
>>>>> <heinrich.schuchardt@canonical.com> wrote:
>>>>>>
>>>>>> On 10/25/23 23:13, Tom Rini wrote:
>>>>>>> On Wed, Oct 25, 2023 at 10:28:05PM +0200, Mark Kettenis wrote:
>>>>>>>>> Date: Wed, 25 Oct 2023 21:57:44 +0200
>>>>>>>>> From: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
>>>>>>>>>
>>>>>>>>> On 10/25/23 20:23, Simon Glass wrote:
>>>>>>>>>> Hi Heinrich,
>>>>>>>>>>
>>>>>>>>>> On Tue, 24 Oct 2023 at 18:02, Simon Glass <sjg@google.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Heinrich,
>>>>>>>>>>>
>>>>>>>>>>> On Mon, 23 Oct 2023 at 23:20, Heinrich Schuchardt
>>>>>>>>>>> <heinrich.schuchardt@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.
>>>>>>>>>>>
>>>>>>>>>>> kernel-specific
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 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.schuchardt@canonical.com>
>>>>>>>>>>>> ---
>>>>>>>>>>>> v4:
>>>>>>>>>>>>             Generalize the description of the content of 
>>>>>>>>>>>> $fdtfile.
>>>>>>>>>>>> v3:
>>>>>>>>>>>>             Add documentation
>>>>>>>>>>>> v2:
>>>>>>>>>>>>             Use a unique GUID to enable future U-Boot 
>>>>>>>>>>>> independent
>>>>>>>>>>>>             standardization.
>>>>>>>>>>>>             Do not try to add the variable on ACPI based 
>>>>>>>>>>>> systems.
>>>>>>>>>>>> ---
>>>>>>>>>>>>      doc/develop/uefi/uefi.rst  | 14 ++++++++++++++
>>>>>>>>>>>>      include/efi_loader.h       |  5 +++++
>>>>>>>>>>>>      lib/efi_loader/efi_setup.c | 30 +++++++++++++++++++++++ 
>>>>>>>>>>>> + ++++++
>>>>>>>>>>>>      3 files changed, 49 insertions(+)
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/ 
>>>>>>>>>>>> uefi.rst
>>>>>>>>>>>> index fb16ac743a..702c490831 100644
>>>>>>>>>>>> --- a/doc/develop/uefi/uefi.rst
>>>>>>>>>>>> +++ b/doc/develop/uefi/uefi.rst
>>>>>>>>>>>> @@ -916,6 +916,20 @@ So our final format of the 
>>>>>>>>>>>> FilePathList[] is::
>>>>>>>>>>>>
>>>>>>>>>>>>          Loaded image - end node (0xff) - VenMedia - 
>>>>>>>>>>>> initrd_1 - [end node (0x01) - initrd_n ...] - end node (0xff)
>>>>>>>>>>>>
>>>>>>>>>>>> +EFI variable FdtFile
>>>>>>>>>>>> +~~~~~~~~~~~~~~~~~~~~
>>>>>>>>>>>> +
>>>>>>>>>>>> +Ideally U-Boot would always expose a device-tree that can 
>>>>>>>>>>>> be used for booting
>>>>>>>>>>>> +any operating systems. Unfortunately operating systems like 
>>>>>>>>>>>> Linux sometimes
>>>>>>>>>>>> +break forward and backward compatibility. In this case 
>>>>>>>>>>>> there is a need to load
>>>>>>>>>>>> +an operating system version specific device-tree.
>>>>>>>>>>>
>>>>>>>>>>> This seems to be a strong statement. Given the effort that 
>>>>>>>>>>> goes into
>>>>>>>>>>> the DT, changes are supposed to be backwards-compatible. Is this
>>>>>>>>>>> generally true, or is it just that we want an up-to-date DT 
>>>>>>>>>>> for the
>>>>>>>>>>> kernel to enable new features?
>>>>>>>>>>
>>>>>>>>>> Did you see this comment?
>>>>>>>>>
>>>>>>>>> It would have been nice to put the person which made that 
>>>>>>>>> comment on copy.
>>>>>>>>>
>>>>>>>>> The truth lies in the world "supposed":
>>>>>>>>>
>>>>>>>>> The idea of a device-tree that never needs to change is quite 
>>>>>>>>> old and
>>>>>>>>> never became true on ARM devices.
>>>>>>>>>
>>>>>>>>> We all know Linux tends to break both forward and backward 
>>>>>>>>> compatibility
>>>>>>>>> of device-trees. Here is a nice example:
>>>>>>>>>
>>>>>>>>> d0c6707ca423 ("arm64: dts: allwinner: H5: NanoPi Neo Plus2: 
>>>>>>>>> phy- mode
>>>>>>>>> rgmii-id")
>>>>>>>>>
>>>>>>>>> Driver changes broke forward and backwards compatibility of a 
>>>>>>>>> lot of
>>>>>>>>> Allwinner boards.
>>>>>>>>
>>>>>>>> Well, that happened in 2020.  Things have gotten better over time.
>>>>
>>>> (kinda off-topic context on DT version compat)
>>>>
>>>>   From what I've seen, there is not yet very much infrastructure or
>>>> common practise in place in the kernel to handle parsing DTB in a
>>>> backwards compatible way. For example there has been efforts to 
>>>> simplify
>>>> the dwc3 devicetree for Qualcomm platforms with a series dating back
>>>> about as far as this U-Boot patch!
>>>>
>>>> https://lore.kernel.org/linux-arm-msm/20250318-dwc3-refactor- 
>>>> v5-1-90ea6e5b3ba4@oss.qualcomm.com/
>>>>
>>>> Earlier versions attempted to convert the older DTS to the newer format
>>>> internally, but after much discussion it was decided that this wasn't
>>>> really feasible, instead the new approach is to duplicate the entire
>>>> dwc3 driver to maintain DT compatibility.
>>>>
>>>> It's obviously good to see compatibility taken seriously, since it 
>>>> seems
>>>> clear that if we ever want to treat DT as firmware, the kernel will 
>>>> need
>>>> to do this (and eventually vendors could ship laptops with DT out of 
>>>> the
>>>> box which works with upstream -- crazier things have happened).
>>>>
>>>> But I think in the mean time we still want to be able to drive distro
>>>> adoption, and the way I see it teaching GRUB and systemd-boot about a
>>>> new FdtFile EFI variable is going to make that way simpler...
> 
> There was a discussion in the context of EBBR if this is the right way 
> forward. And the general opinion was that the compatible string should 
> be used for matching the dtb files.

Ideally, the file name should contain the same information as the 
compatible string, or more. Currently in upstream there are devices with 
different display variants that have identical compatible strings but 
different dtb files.

> 
>>>
>>> GRUB is unlikely even to handle devicetree properly as it does not
>>> implement FIT, nor the best-match algorithm in FIT. So everything is a
>>> workaround.
> 
> For the Qualcomm laptop case the current patch would not solve anything 
> as the selection of the device-tree needs to be based on SMBIOS value.

I bought this idea up with the laptops team and the upstream Qualcomm 
maintainer, everyone agreed that this approach would be a much more 
scalable intermediate solution. Since the HWID matching stuff will just 
not scale or make it into distros easily (e.g. generic installer won't 
work on the laptops currently because of this).

If my understanding of EFI is correct, it would be possible to set this 
variable on the laptops via EFI shell (or even some custom EFI app for 
simplicity), and there is a non-zero chance that we could get some 
vendors to support setting this variable directly in their EFI firmware 
setup.

> 
> Systemd-boot allows to add a rule-table to the UKI header to select 
> device-trees from a UKI image.
> 
> That is a smarter solution than trying to hard-code logic in U-Boot to 
> set fdtfile and an FdtFile EFI variable.

Right, we try to guess fdtfile today in mach-snapdragon and that sucks. 
I brainstormed this a bit with Ilias and what we came up with is to have 
U-Boot embed the fdtfile value directly into the /chosen node of every 
DTB we build with OF_UPSTREAM. Since the paths are identical to the kernel.

This way you can have a single U-Boot binary (as we support for 
Qualcomm) boot on different boards and whichever DTB you give to U-Boot 
(say qcom/sdm845-db845c.dtb for example) will be the value that FdtFile 
gets. Then sd-boot/GRUB will look for a DTB under the same name relative 
to the devicetree-dir for the kernel version you're booting.

Yes long term all this is far from the ideal solution, but it's a lot 
better than what we have today and much less hacky than every other 
proposal I've seen particularly for the laptops.

Most importantly, it doesn't require distro changes, we already know for 
sure that distros are not going to adopt FIT. Arguing on the merits is 
pointless.

Kind regards,

> 
>>
>> FIT has nothing to do with DT loading
>>>
>>>>>>>
>>>>>>> Well, yes and no.  Given the brief summary here, I bet this was just
>>>>>>> like when phy-mode and am335x platforms had DT compatibility 
>>>>>>> broken and
>>>>>>> the answer was that it was OK because the DT was incorrectly 
>>>>>>> describing
>>>>>>> hardware. So this is the reminder that there are cases of 
>>>>>>> breaking DT
>>>>>>> compatibility that are allowed. Even if the DT has been out (and 
>>>>>>> wrong)
>>>>>>> for several years.
>>>>>>>
>>>>>>> That's not the main point of this thread and I don't want to derail
>>>>>>> things further along this point, I just want to note that the 
>>>>>>> details
>>>>>>> here reminded me of when things are allowed to be incompatible with
>>>>>>> previous trees.
>>>>>>>
>>>>>>
>>>>>
>>>>> Unfortunately I was off the list for a week or so, but I see this one
>>>>> so will reply here.
>>>>>
>>>>>> You are conflating things:
>>>>>>
>>>>>> The EFI variable is a hint to the GRUB OS to find the correct
>>>>>> device-tree file without scanning hundreds of device-tree. You can 
>>>>>> not
>>>>>> build a compatibility check for it into U-Boot.
>>>>>
>>>>> Actually we can...and I think that is what we should do.
>>>>
>>>> No, how and where an EFI bootloader app chooses to load the FDT from is
>>>> entirely implementation dependent. It may be extremely costly to 
>>>> compare
>>>> compatible strings for every single dtb, and whether or not to do so is
>>>> the decision of the distro anyways, all we can do in U-Boot is try to
>>>> promote best practise (which clearly isn't compatible prop comparison
>>>> for hundreds of DTBs...)
>>>
>>> U-Boot promotes best practice, which is to check the compatible
>>> properties of hundreds of nodes in the FIT to find the right one.
>>
>> Distros don't ship FIT images (which would be absolutely huge by the 
>> way, 75M for all DTBs today), they ship DTBs in a directory structure 
>> following the kernel layout.
> 
> It might make sense to support compressed FIT images.
> 
> Whether all device-trees are stored as files in /lib/firmware/<kernel- 
> version>/device-tree/ or are part of the kernel image (FIT or UKI) does 
> not change the space requirement on disk.
> 
> Best regards
> 
> Heinrich
> 
>>
>> If the kernel started outputting FIT images with all DTBs it would 
>> have to be installed in addition to the directory layout, and only 
>> provide a considerably less efficient interface to pick a DTB.
>>
>> We want Fedora images that you download today to be able to boot and 
>> select an appropriate DTB. FIT is just not a good fit (haha) for this 
>> problem.
>>
>> A fit mapping compatible strings to filenames would be an improvement 
>> but that's so much additional complexity to come up with a value that 
>> U- Boot already has...
>>
>>>>
>>>> Providing FdtFile as an EFI variable will make it possible for grub and
>>>> systemd-boot to support the same kind of "fdtdir" property that 
>>>> extlinux
>>>> does, this would simply enable versioned DTB loading for distros and
>>>> make booting wayyyyy easier.
>>>
>>> It is perpetuating an incorrect approach, though. It won't lead to
>>> happiness. Perhaps systemd-boot should support FIT?
>>
>> What do i even say to this. You haven't explained what's incorrect
>>>
>>> As to versions, the compatible string needs to handle that. We cannot
>>> have a situation where we ship two different devices trees that have
>>> the same compatible strings but different contents as there is no
>>> (spec-correct) way to distinguish them.
>>>
>>>>
>>>> With regards to the design, I think a good follow-up patch would set a
>>>> default value for $fdtfile (and consequently FdtFile) from the
>>>> DEVICE_TREE build variable as a constant (maybe only if OF_UPSTREAM is
>>>> enabled).
>>>
>>> Please no. We should not continue down this broken path.
>>
>> ???
>>>
>>>>
>>>> This would be correct in almost all cases (and wayyy better than the
>>>> hacky fdtfile generating code we have in mach-snapdragon right now).
>>>
>>> Yes, but you really should figure out how to remove that code. It is
>>> present on other boards too. One of the things not on my list (but I
>>> wish it were) is to clean up how RISC-V does devicetree selection
>>> within U-Boot.
>>
>> That is why i revived this patch...
>>>
>>>>>
>>>>> For distro-boot, do you mean the scripts? We are trying to deprecate
>>>>> those. Of course we have brought in all the same work-arounds, etc.,
>>>>> but with bootstd we can start to clean things up, I hope.
>>>>>
>>>>> So let's think about how we can have U-Boot choose the right DT to 
>>>>> boot with.
>>>>>
>>>>> Regards,
>>>>> Simon
>>>>
>>>> Heinrich, since it's been a while, if you aren't super interested in
>>>> re-sending this patch I'd be happy to address the wording feedback and
>>>> re-spin it, along with a patch setting the default $fdtfile (else I can
>>>> send that as a follow-up).
>>>
>>> The best thing to do here is to use FIT. You can put all the FDTs in a
>>> FIT and leave the kernel out, if necessary.
>>
>> You cannot do this, distros will not do this for thousands of FDTs
>>>
>>> Another idea, which I may have suggested before (can't remember) would
>>> be to add an EFI service which U-Boot implements, which returns the
>>> correct FDT to use. U-Boot can then scan the files one by one to
>>> figure it out, although hopefully that would prompt someone to create
>>> a FIT (or a text file?) which has this information in it.
>>>
>>> But fdtfile is just not the right approach.
>>
>> You've pushed for FIT but never explained why fdtfile is a bad solution.
>>>
>>>>
>>>> I'll also open an issue for getting support for this added to 
>>>> systemd-boot.
>>>
>>> FIT?
>>>
>>> Regards,
>>> Simon
>>
> 

-- 
Caleb (they/them)

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

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 9562 bytes --]

On Sun, Mar 30, 2025 at 04:38:12PM +0200, Caleb Connolly wrote:
> Hi Heinrich,
> 
> On 3/28/25 15:18, Heinrich Schuchardt wrote:
> > On 28.03.25 14:00, Caleb Connolly wrote:
> > > 
> > > 
> > > On 3/28/25 13:01, Simon Glass wrote:
> > > > Hi Caleb,
> > > > 
> > > > On Sun, 23 Mar 2025 at 12:39, Caleb Connolly
> > > > <caleb.connolly@linaro.org> wrote:
> > > > > 
> > > > > Hi all,
> > > > > 
> > > > > Reviving this as it is still very much an issue, and
> > > > > especially relevant
> > > > > for Qualcomm platforms.
> > > > > 
> > > > > On 11/3/23 20:44, Simon Glass wrote:
> > > > > > Hi Heinrich,
> > > > > > 
> > > > > > On Wed, 25 Oct 2023 at 15:22, Heinrich Schuchardt
> > > > > > <heinrich.schuchardt@canonical.com> wrote:
> > > > > > > 
> > > > > > > On 10/25/23 23:13, Tom Rini wrote:
> > > > > > > > On Wed, Oct 25, 2023 at 10:28:05PM +0200, Mark Kettenis wrote:
> > > > > > > > > > Date: Wed, 25 Oct 2023 21:57:44 +0200
> > > > > > > > > > From: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
> > > > > > > > > > 
> > > > > > > > > > On 10/25/23 20:23, Simon Glass wrote:
> > > > > > > > > > > Hi Heinrich,
> > > > > > > > > > > 
> > > > > > > > > > > On Tue, 24 Oct 2023 at 18:02, Simon Glass <sjg@google.com> wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > Hi Heinrich,
> > > > > > > > > > > > 
> > > > > > > > > > > > On Mon, 23 Oct 2023 at 23:20, Heinrich Schuchardt
> > > > > > > > > > > > <heinrich.schuchardt@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.
> > > > > > > > > > > > 
> > > > > > > > > > > > kernel-specific
> > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 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.schuchardt@canonical.com>
> > > > > > > > > > > > > ---
> > > > > > > > > > > > > v4:
> > > > > > > > > > > > >             Generalize the
> > > > > > > > > > > > > description of the content
> > > > > > > > > > > > > of $fdtfile.
> > > > > > > > > > > > > v3:
> > > > > > > > > > > > >             Add documentation
> > > > > > > > > > > > > v2:
> > > > > > > > > > > > >             Use a unique
> > > > > > > > > > > > > GUID to enable future U-Boot
> > > > > > > > > > > > > independent
> > > > > > > > > > > > >             standardization.
> > > > > > > > > > > > >             Do not try to
> > > > > > > > > > > > > add the variable on ACPI
> > > > > > > > > > > > > based systems.
> > > > > > > > > > > > > ---
> > > > > > > > > > > > >      doc/develop/uefi/uefi.rst  | 14 ++++++++++++++
> > > > > > > > > > > > >      include/efi_loader.h       |  5 +++++
> > > > > > > > > > > > >     
> > > > > > > > > > > > > lib/efi_loader/efi_setup.c |
> > > > > > > > > > > > > 30 +++++++++++++++++++++++ +
> > > > > > > > > > > > > ++++++
> > > > > > > > > > > > >      3 files changed, 49 insertions(+)
> > > > > > > > > > > > > 
> > > > > > > > > > > > > diff --git
> > > > > > > > > > > > > a/doc/develop/uefi/uefi.rst
> > > > > > > > > > > > > b/doc/develop/uefi/ uefi.rst
> > > > > > > > > > > > > index fb16ac743a..702c490831 100644
> > > > > > > > > > > > > --- a/doc/develop/uefi/uefi.rst
> > > > > > > > > > > > > +++ b/doc/develop/uefi/uefi.rst
> > > > > > > > > > > > > @@ -916,6 +916,20 @@ So our
> > > > > > > > > > > > > final format of the
> > > > > > > > > > > > > FilePathList[] is::
> > > > > > > > > > > > > 
> > > > > > > > > > > > >          Loaded image - end
> > > > > > > > > > > > > node (0xff) - VenMedia -
> > > > > > > > > > > > > initrd_1 - [end node (0x01)
> > > > > > > > > > > > > - initrd_n ...] - end node
> > > > > > > > > > > > > (0xff)
> > > > > > > > > > > > > 
> > > > > > > > > > > > > +EFI variable FdtFile
> > > > > > > > > > > > > +~~~~~~~~~~~~~~~~~~~~
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +Ideally U-Boot would always
> > > > > > > > > > > > > expose a device-tree that
> > > > > > > > > > > > > can be used for booting
> > > > > > > > > > > > > +any operating systems.
> > > > > > > > > > > > > Unfortunately operating
> > > > > > > > > > > > > systems like Linux sometimes
> > > > > > > > > > > > > +break forward and backward
> > > > > > > > > > > > > compatibility. In this case
> > > > > > > > > > > > > there is a need to load
> > > > > > > > > > > > > +an operating system version specific device-tree.
> > > > > > > > > > > > 
> > > > > > > > > > > > This seems to be a strong
> > > > > > > > > > > > statement. Given the effort that
> > > > > > > > > > > > goes into
> > > > > > > > > > > > the DT, changes are supposed to be backwards-compatible. Is this
> > > > > > > > > > > > generally true, or is it just
> > > > > > > > > > > > that we want an up-to-date DT
> > > > > > > > > > > > for the
> > > > > > > > > > > > kernel to enable new features?
> > > > > > > > > > > 
> > > > > > > > > > > Did you see this comment?
> > > > > > > > > > 
> > > > > > > > > > It would have been nice to put the
> > > > > > > > > > person which made that comment on copy.
> > > > > > > > > > 
> > > > > > > > > > The truth lies in the world "supposed":
> > > > > > > > > > 
> > > > > > > > > > The idea of a device-tree that never
> > > > > > > > > > needs to change is quite old and
> > > > > > > > > > never became true on ARM devices.
> > > > > > > > > > 
> > > > > > > > > > We all know Linux tends to break both
> > > > > > > > > > forward and backward compatibility
> > > > > > > > > > of device-trees. Here is a nice example:
> > > > > > > > > > 
> > > > > > > > > > d0c6707ca423 ("arm64: dts: allwinner:
> > > > > > > > > > H5: NanoPi Neo Plus2: phy- mode
> > > > > > > > > > rgmii-id")
> > > > > > > > > > 
> > > > > > > > > > Driver changes broke forward and
> > > > > > > > > > backwards compatibility of a lot of
> > > > > > > > > > Allwinner boards.
> > > > > > > > > 
> > > > > > > > > Well, that happened in 2020.  Things have gotten better over time.
> > > > > 
> > > > > (kinda off-topic context on DT version compat)
> > > > > 
> > > > >   From what I've seen, there is not yet very much infrastructure or
> > > > > common practise in place in the kernel to handle parsing DTB in a
> > > > > backwards compatible way. For example there has been efforts
> > > > > to simplify
> > > > > the dwc3 devicetree for Qualcomm platforms with a series dating back
> > > > > about as far as this U-Boot patch!
> > > > > 
> > > > > https://lore.kernel.org/linux-arm-msm/20250318-dwc3-refactor-
> > > > > v5-1-90ea6e5b3ba4@oss.qualcomm.com/
> > > > > 
> > > > > Earlier versions attempted to convert the older DTS to the newer format
> > > > > internally, but after much discussion it was decided that this wasn't
> > > > > really feasible, instead the new approach is to duplicate the entire
> > > > > dwc3 driver to maintain DT compatibility.
> > > > > 
> > > > > It's obviously good to see compatibility taken seriously,
> > > > > since it seems
> > > > > clear that if we ever want to treat DT as firmware, the
> > > > > kernel will need
> > > > > to do this (and eventually vendors could ship laptops with
> > > > > DT out of the
> > > > > box which works with upstream -- crazier things have happened).
> > > > > 
> > > > > But I think in the mean time we still want to be able to drive distro
> > > > > adoption, and the way I see it teaching GRUB and systemd-boot about a
> > > > > new FdtFile EFI variable is going to make that way simpler...
> > 
> > There was a discussion in the context of EBBR if this is the right way
> > forward. And the general opinion was that the compatible string should
> > be used for matching the dtb files.
> 
> Ideally, the file name should contain the same information as the compatible
> string, or more. Currently in upstream there are devices with different
> display variants that have identical compatible strings but different dtb
> files.

I've asked before for clarification on if that's allowed or a bug and
not really gotten an answer. It sure feels wrong and I think the
argument is that devices doing things like that aren't likely to be
general purpose anyhow.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

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

[Heinrich Schuchardt]

On 31.03.25 18:30, Tom Rini wrote:
> On Sun, Mar 30, 2025 at 04:38:12PM +0200, Caleb Connolly wrote:
>> Hi Heinrich,
>>
>> On 3/28/25 15:18, Heinrich Schuchardt wrote:
>>> On 28.03.25 14:00, Caleb Connolly wrote:
>>>>
>>>>
>>>> On 3/28/25 13:01, Simon Glass wrote:
>>>>> Hi Caleb,
>>>>>
>>>>> On Sun, 23 Mar 2025 at 12:39, Caleb Connolly
>>>>> <caleb.connolly@linaro.org> wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Reviving this as it is still very much an issue, and
>>>>>> especially relevant
>>>>>> for Qualcomm platforms.
>>>>>>
>>>>>> On 11/3/23 20:44, Simon Glass wrote:
>>>>>>> Hi Heinrich,
>>>>>>>
>>>>>>> On Wed, 25 Oct 2023 at 15:22, Heinrich Schuchardt
>>>>>>> <heinrich.schuchardt@canonical.com> wrote:
>>>>>>>>
>>>>>>>> On 10/25/23 23:13, Tom Rini wrote:
>>>>>>>>> On Wed, Oct 25, 2023 at 10:28:05PM +0200, Mark Kettenis wrote:
>>>>>>>>>>> Date: Wed, 25 Oct 2023 21:57:44 +0200
>>>>>>>>>>> From: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
>>>>>>>>>>>
>>>>>>>>>>> On 10/25/23 20:23, Simon Glass wrote:
>>>>>>>>>>>> Hi Heinrich,
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, 24 Oct 2023 at 18:02, Simon Glass <sjg@google.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Heinrich,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, 23 Oct 2023 at 23:20, Heinrich Schuchardt
>>>>>>>>>>>>> <heinrich.schuchardt@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.
>>>>>>>>>>>>>
>>>>>>>>>>>>> kernel-specific
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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.schuchardt@canonical.com>
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>> v4:
>>>>>>>>>>>>>>              Generalize the
>>>>>>>>>>>>>> description of the content
>>>>>>>>>>>>>> of $fdtfile.
>>>>>>>>>>>>>> v3:
>>>>>>>>>>>>>>              Add documentation
>>>>>>>>>>>>>> v2:
>>>>>>>>>>>>>>              Use a unique
>>>>>>>>>>>>>> GUID to enable future U-Boot
>>>>>>>>>>>>>> independent
>>>>>>>>>>>>>>              standardization.
>>>>>>>>>>>>>>              Do not try to
>>>>>>>>>>>>>> add the variable on ACPI
>>>>>>>>>>>>>> based systems.
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>       doc/develop/uefi/uefi.rst  | 14 ++++++++++++++
>>>>>>>>>>>>>>       include/efi_loader.h       |  5 +++++
>>>>>>>>>>>>>>      
>>>>>>>>>>>>>> lib/efi_loader/efi_setup.c |
>>>>>>>>>>>>>> 30 +++++++++++++++++++++++ +
>>>>>>>>>>>>>> ++++++
>>>>>>>>>>>>>>       3 files changed, 49 insertions(+)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> diff --git
>>>>>>>>>>>>>> a/doc/develop/uefi/uefi.rst
>>>>>>>>>>>>>> b/doc/develop/uefi/ uefi.rst
>>>>>>>>>>>>>> index fb16ac743a..702c490831 100644
>>>>>>>>>>>>>> --- a/doc/develop/uefi/uefi.rst
>>>>>>>>>>>>>> +++ b/doc/develop/uefi/uefi.rst
>>>>>>>>>>>>>> @@ -916,6 +916,20 @@ So our
>>>>>>>>>>>>>> final format of the
>>>>>>>>>>>>>> FilePathList[] is::
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>           Loaded image - end
>>>>>>>>>>>>>> node (0xff) - VenMedia -
>>>>>>>>>>>>>> initrd_1 - [end node (0x01)
>>>>>>>>>>>>>> - initrd_n ...] - end node
>>>>>>>>>>>>>> (0xff)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> +EFI variable FdtFile
>>>>>>>>>>>>>> +~~~~~~~~~~~~~~~~~~~~
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> +Ideally U-Boot would always
>>>>>>>>>>>>>> expose a device-tree that
>>>>>>>>>>>>>> can be used for booting
>>>>>>>>>>>>>> +any operating systems.
>>>>>>>>>>>>>> Unfortunately operating
>>>>>>>>>>>>>> systems like Linux sometimes
>>>>>>>>>>>>>> +break forward and backward
>>>>>>>>>>>>>> compatibility. In this case
>>>>>>>>>>>>>> there is a need to load
>>>>>>>>>>>>>> +an operating system version specific device-tree.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This seems to be a strong
>>>>>>>>>>>>> statement. Given the effort that
>>>>>>>>>>>>> goes into
>>>>>>>>>>>>> the DT, changes are supposed to be backwards-compatible. Is this
>>>>>>>>>>>>> generally true, or is it just
>>>>>>>>>>>>> that we want an up-to-date DT
>>>>>>>>>>>>> for the
>>>>>>>>>>>>> kernel to enable new features?
>>>>>>>>>>>>
>>>>>>>>>>>> Did you see this comment?
>>>>>>>>>>>
>>>>>>>>>>> It would have been nice to put the
>>>>>>>>>>> person which made that comment on copy.
>>>>>>>>>>>
>>>>>>>>>>> The truth lies in the world "supposed":
>>>>>>>>>>>
>>>>>>>>>>> The idea of a device-tree that never
>>>>>>>>>>> needs to change is quite old and
>>>>>>>>>>> never became true on ARM devices.
>>>>>>>>>>>
>>>>>>>>>>> We all know Linux tends to break both
>>>>>>>>>>> forward and backward compatibility
>>>>>>>>>>> of device-trees. Here is a nice example:
>>>>>>>>>>>
>>>>>>>>>>> d0c6707ca423 ("arm64: dts: allwinner:
>>>>>>>>>>> H5: NanoPi Neo Plus2: phy- mode
>>>>>>>>>>> rgmii-id")
>>>>>>>>>>>
>>>>>>>>>>> Driver changes broke forward and
>>>>>>>>>>> backwards compatibility of a lot of
>>>>>>>>>>> Allwinner boards.
>>>>>>>>>>
>>>>>>>>>> Well, that happened in 2020.  Things have gotten better over time.
>>>>>>
>>>>>> (kinda off-topic context on DT version compat)
>>>>>>
>>>>>>    From what I've seen, there is not yet very much infrastructure or
>>>>>> common practise in place in the kernel to handle parsing DTB in a
>>>>>> backwards compatible way. For example there has been efforts
>>>>>> to simplify
>>>>>> the dwc3 devicetree for Qualcomm platforms with a series dating back
>>>>>> about as far as this U-Boot patch!
>>>>>>
>>>>>> https://lore.kernel.org/linux-arm-msm/20250318-dwc3-refactor-
>>>>>> v5-1-90ea6e5b3ba4@oss.qualcomm.com/
>>>>>>
>>>>>> Earlier versions attempted to convert the older DTS to the newer format
>>>>>> internally, but after much discussion it was decided that this wasn't
>>>>>> really feasible, instead the new approach is to duplicate the entire
>>>>>> dwc3 driver to maintain DT compatibility.
>>>>>>
>>>>>> It's obviously good to see compatibility taken seriously,
>>>>>> since it seems
>>>>>> clear that if we ever want to treat DT as firmware, the
>>>>>> kernel will need
>>>>>> to do this (and eventually vendors could ship laptops with
>>>>>> DT out of the
>>>>>> box which works with upstream -- crazier things have happened).
>>>>>>
>>>>>> But I think in the mean time we still want to be able to drive distro
>>>>>> adoption, and the way I see it teaching GRUB and systemd-boot about a
>>>>>> new FdtFile EFI variable is going to make that way simpler...
>>>
>>> There was a discussion in the context of EBBR if this is the right way
>>> forward. And the general opinion was that the compatible string should
>>> be used for matching the dtb files.
>>
>> Ideally, the file name should contain the same information as the compatible
>> string, or more. Currently in upstream there are devices with different
>> display variants that have identical compatible strings but different dtb
>> files.
> 
> I've asked before for clarification on if that's allowed or a bug and
> not really gotten an answer. It sure feels wrong and I think the
> argument is that devices doing things like that aren't likely to be
> general purpose anyhow.
> 

Multiple device-trees in Linux having the same compatible string is a 
bug as indicated by the device-tree maintainer in earlier discussions. 
It should be fixed in Linux.

Best regards

Heinrich

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

[Simon Glass]

Hi Caleb,

On Mon, 31 Mar 2025 at 03:38, Caleb Connolly <caleb.connolly@linaro.org> wrote:
>
> Hi Heinrich,
>
> On 3/28/25 15:18, Heinrich Schuchardt wrote:
> > On 28.03.25 14:00, Caleb Connolly wrote:
> >>
> >>
> >> On 3/28/25 13:01, Simon Glass wrote:
> >>> Hi Caleb,
> >>>
> >>> On Sun, 23 Mar 2025 at 12:39, Caleb Connolly
> >>> <caleb.connolly@linaro.org> wrote:
> >>>>
> >>>> Hi all,
> >>>>
> >>>> Reviving this as it is still very much an issue, and especially
> >>>> relevant
> >>>> for Qualcomm platforms.
> >>>>
> >>>> On 11/3/23 20:44, Simon Glass wrote:
> >>>>> Hi Heinrich,
> >>>>>
> >>>>> On Wed, 25 Oct 2023 at 15:22, Heinrich Schuchardt
> >>>>> <heinrich.schuchardt@canonical.com> wrote:
> >>>>>>
> >>>>>> On 10/25/23 23:13, Tom Rini wrote:
> >>>>>>> On Wed, Oct 25, 2023 at 10:28:05PM +0200, Mark Kettenis wrote:
> >>>>>>>>> Date: Wed, 25 Oct 2023 21:57:44 +0200
> >>>>>>>>> From: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
> >>>>>>>>>
> >>>>>>>>> On 10/25/23 20:23, Simon Glass wrote:
> >>>>>>>>>> Hi Heinrich,
> >>>>>>>>>>
> >>>>>>>>>> On Tue, 24 Oct 2023 at 18:02, Simon Glass <sjg@google.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Hi Heinrich,
> >>>>>>>>>>>
> >>>>>>>>>>> On Mon, 23 Oct 2023 at 23:20, Heinrich Schuchardt
> >>>>>>>>>>> <heinrich.schuchardt@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.
> >>>>>>>>>>>
> >>>>>>>>>>> kernel-specific
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> 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.schuchardt@canonical.com>
> >>>>>>>>>>>> ---
> >>>>>>>>>>>> v4:
> >>>>>>>>>>>>             Generalize the description of the content of
> >>>>>>>>>>>> $fdtfile.
> >>>>>>>>>>>> v3:
> >>>>>>>>>>>>             Add documentation
> >>>>>>>>>>>> v2:
> >>>>>>>>>>>>             Use a unique GUID to enable future U-Boot
> >>>>>>>>>>>> independent
> >>>>>>>>>>>>             standardization.
> >>>>>>>>>>>>             Do not try to add the variable on ACPI based
> >>>>>>>>>>>> systems.
> >>>>>>>>>>>> ---
> >>>>>>>>>>>>      doc/develop/uefi/uefi.rst  | 14 ++++++++++++++
> >>>>>>>>>>>>      include/efi_loader.h       |  5 +++++
> >>>>>>>>>>>>      lib/efi_loader/efi_setup.c | 30 +++++++++++++++++++++++
> >>>>>>>>>>>> + ++++++
> >>>>>>>>>>>>      3 files changed, 49 insertions(+)
> >>>>>>>>>>>>
> >>>>>>>>>>>> diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/
> >>>>>>>>>>>> uefi.rst
> >>>>>>>>>>>> index fb16ac743a..702c490831 100644
> >>>>>>>>>>>> --- a/doc/develop/uefi/uefi.rst
> >>>>>>>>>>>> +++ b/doc/develop/uefi/uefi.rst
> >>>>>>>>>>>> @@ -916,6 +916,20 @@ So our final format of the
> >>>>>>>>>>>> FilePathList[] is::
> >>>>>>>>>>>>
> >>>>>>>>>>>>          Loaded image - end node (0xff) - VenMedia -
> >>>>>>>>>>>> initrd_1 - [end node (0x01) - initrd_n ...] - end node (0xff)
> >>>>>>>>>>>>
> >>>>>>>>>>>> +EFI variable FdtFile
> >>>>>>>>>>>> +~~~~~~~~~~~~~~~~~~~~
> >>>>>>>>>>>> +
> >>>>>>>>>>>> +Ideally U-Boot would always expose a device-tree that can
> >>>>>>>>>>>> be used for booting
> >>>>>>>>>>>> +any operating systems. Unfortunately operating systems like
> >>>>>>>>>>>> Linux sometimes
> >>>>>>>>>>>> +break forward and backward compatibility. In this case
> >>>>>>>>>>>> there is a need to load
> >>>>>>>>>>>> +an operating system version specific device-tree.
> >>>>>>>>>>>
> >>>>>>>>>>> This seems to be a strong statement. Given the effort that
> >>>>>>>>>>> goes into
> >>>>>>>>>>> the DT, changes are supposed to be backwards-compatible. Is this
> >>>>>>>>>>> generally true, or is it just that we want an up-to-date DT
> >>>>>>>>>>> for the
> >>>>>>>>>>> kernel to enable new features?
> >>>>>>>>>>
> >>>>>>>>>> Did you see this comment?
> >>>>>>>>>
> >>>>>>>>> It would have been nice to put the person which made that
> >>>>>>>>> comment on copy.
> >>>>>>>>>
> >>>>>>>>> The truth lies in the world "supposed":
> >>>>>>>>>
> >>>>>>>>> The idea of a device-tree that never needs to change is quite
> >>>>>>>>> old and
> >>>>>>>>> never became true on ARM devices.
> >>>>>>>>>
> >>>>>>>>> We all know Linux tends to break both forward and backward
> >>>>>>>>> compatibility
> >>>>>>>>> of device-trees. Here is a nice example:
> >>>>>>>>>
> >>>>>>>>> d0c6707ca423 ("arm64: dts: allwinner: H5: NanoPi Neo Plus2:
> >>>>>>>>> phy- mode
> >>>>>>>>> rgmii-id")
> >>>>>>>>>
> >>>>>>>>> Driver changes broke forward and backwards compatibility of a
> >>>>>>>>> lot of
> >>>>>>>>> Allwinner boards.
> >>>>>>>>
> >>>>>>>> Well, that happened in 2020.  Things have gotten better over time.
> >>>>
> >>>> (kinda off-topic context on DT version compat)
> >>>>
> >>>>   From what I've seen, there is not yet very much infrastructure or
> >>>> common practise in place in the kernel to handle parsing DTB in a
> >>>> backwards compatible way. For example there has been efforts to
> >>>> simplify
> >>>> the dwc3 devicetree for Qualcomm platforms with a series dating back
> >>>> about as far as this U-Boot patch!
> >>>>
> >>>> https://lore.kernel.org/linux-arm-msm/20250318-dwc3-refactor-
> >>>> v5-1-90ea6e5b3ba4@oss.qualcomm.com/
> >>>>
> >>>> Earlier versions attempted to convert the older DTS to the newer format
> >>>> internally, but after much discussion it was decided that this wasn't
> >>>> really feasible, instead the new approach is to duplicate the entire
> >>>> dwc3 driver to maintain DT compatibility.
> >>>>
> >>>> It's obviously good to see compatibility taken seriously, since it
> >>>> seems
> >>>> clear that if we ever want to treat DT as firmware, the kernel will
> >>>> need
> >>>> to do this (and eventually vendors could ship laptops with DT out of
> >>>> the
> >>>> box which works with upstream -- crazier things have happened).
> >>>>
> >>>> But I think in the mean time we still want to be able to drive distro
> >>>> adoption, and the way I see it teaching GRUB and systemd-boot about a
> >>>> new FdtFile EFI variable is going to make that way simpler...
> >
> > There was a discussion in the context of EBBR if this is the right way
> > forward. And the general opinion was that the compatible string should
> > be used for matching the dtb files.
>
> Ideally, the file name should contain the same information as the
> compatible string, or more. Currently in upstream there are devices with
> different display variants that have identical compatible strings but
> different dtb files.
>
> >
> >>>
> >>> GRUB is unlikely even to handle devicetree properly as it does not
> >>> implement FIT, nor the best-match algorithm in FIT. So everything is a
> >>> workaround.
> >
> > For the Qualcomm laptop case the current patch would not solve anything
> > as the selection of the device-tree needs to be based on SMBIOS value.
>
> I bought this idea up with the laptops team and the upstream Qualcomm
> maintainer, everyone agreed that this approach would be a much more
> scalable intermediate solution. Since the HWID matching stuff will just
> not scale or make it into distros easily (e.g. generic installer won't
> work on the laptops currently because of this).
>
> If my understanding of EFI is correct, it would be possible to set this
> variable on the laptops via EFI shell (or even some custom EFI app for
> simplicity), and there is a non-zero chance that we could get some
> vendors to support setting this variable directly in their EFI firmware
> setup.
>
> >
> > Systemd-boot allows to add a rule-table to the UKI header to select
> > device-trees from a UKI image.
> >
> > That is a smarter solution than trying to hard-code logic in U-Boot to
> > set fdtfile and an FdtFile EFI variable.
>
> Right, we try to guess fdtfile today in mach-snapdragon and that sucks.
> I brainstormed this a bit with Ilias and what we came up with is to have
> U-Boot embed the fdtfile value directly into the /chosen node of every
> DTB we build with OF_UPSTREAM. Since the paths are identical to the kernel.
>
> This way you can have a single U-Boot binary (as we support for
> Qualcomm) boot on different boards and whichever DTB you give to U-Boot
> (say qcom/sdm845-db845c.dtb for example) will be the value that FdtFile
> gets. Then sd-boot/GRUB will look for a DTB under the same name relative
> to the devicetree-dir for the kernel version you're booting.
>
> Yes long term all this is far from the ideal solution, but it's a lot
> better than what we have today and much less hacky than every other
> proposal I've seen particularly for the laptops.
>
> Most importantly, it doesn't require distro changes, we already know for
> sure that distros are not going to adopt FIT. Arguing on the merits is
> pointless.

While it is very hard to predict the future, I don't share your pessimism :-)

IMO UKI is a poor man's FIT and eventually it will end up with similar
features to FIT, just uglier and with less flexibility.

Regards,
Simon


>
> Kind regards,
>
> >
> >>
> >> FIT has nothing to do with DT loading
> >>>
> >>>>>>>
> >>>>>>> Well, yes and no.  Given the brief summary here, I bet this was just
> >>>>>>> like when phy-mode and am335x platforms had DT compatibility
> >>>>>>> broken and
> >>>>>>> the answer was that it was OK because the DT was incorrectly
> >>>>>>> describing
> >>>>>>> hardware. So this is the reminder that there are cases of
> >>>>>>> breaking DT
> >>>>>>> compatibility that are allowed. Even if the DT has been out (and
> >>>>>>> wrong)
> >>>>>>> for several years.
> >>>>>>>
> >>>>>>> That's not the main point of this thread and I don't want to derail
> >>>>>>> things further along this point, I just want to note that the
> >>>>>>> details
> >>>>>>> here reminded me of when things are allowed to be incompatible with
> >>>>>>> previous trees.
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>> Unfortunately I was off the list for a week or so, but I see this one
> >>>>> so will reply here.
> >>>>>
> >>>>>> You are conflating things:
> >>>>>>
> >>>>>> The EFI variable is a hint to the GRUB OS to find the correct
> >>>>>> device-tree file without scanning hundreds of device-tree. You can
> >>>>>> not
> >>>>>> build a compatibility check for it into U-Boot.
> >>>>>
> >>>>> Actually we can...and I think that is what we should do.
> >>>>
> >>>> No, how and where an EFI bootloader app chooses to load the FDT from is
> >>>> entirely implementation dependent. It may be extremely costly to
> >>>> compare
> >>>> compatible strings for every single dtb, and whether or not to do so is
> >>>> the decision of the distro anyways, all we can do in U-Boot is try to
> >>>> promote best practise (which clearly isn't compatible prop comparison
> >>>> for hundreds of DTBs...)
> >>>
> >>> U-Boot promotes best practice, which is to check the compatible
> >>> properties of hundreds of nodes in the FIT to find the right one.
> >>
> >> Distros don't ship FIT images (which would be absolutely huge by the
> >> way, 75M for all DTBs today), they ship DTBs in a directory structure
> >> following the kernel layout.
> >
> > It might make sense to support compressed FIT images.
> >
> > Whether all device-trees are stored as files in /lib/firmware/<kernel-
> > version>/device-tree/ or are part of the kernel image (FIT or UKI) does
> > not change the space requirement on disk.
> >
> > Best regards
> >
> > Heinrich
> >
> >>
> >> If the kernel started outputting FIT images with all DTBs it would
> >> have to be installed in addition to the directory layout, and only
> >> provide a considerably less efficient interface to pick a DTB.
> >>
> >> We want Fedora images that you download today to be able to boot and
> >> select an appropriate DTB. FIT is just not a good fit (haha) for this
> >> problem.
> >>
> >> A fit mapping compatible strings to filenames would be an improvement
> >> but that's so much additional complexity to come up with a value that
> >> U- Boot already has...
> >>
> >>>>
> >>>> Providing FdtFile as an EFI variable will make it possible for grub and
> >>>> systemd-boot to support the same kind of "fdtdir" property that
> >>>> extlinux
> >>>> does, this would simply enable versioned DTB loading for distros and
> >>>> make booting wayyyyy easier.
> >>>
> >>> It is perpetuating an incorrect approach, though. It won't lead to
> >>> happiness. Perhaps systemd-boot should support FIT?
> >>
> >> What do i even say to this. You haven't explained what's incorrect
> >>>
> >>> As to versions, the compatible string needs to handle that. We cannot
> >>> have a situation where we ship two different devices trees that have
> >>> the same compatible strings but different contents as there is no
> >>> (spec-correct) way to distinguish them.
> >>>
> >>>>
> >>>> With regards to the design, I think a good follow-up patch would set a
> >>>> default value for $fdtfile (and consequently FdtFile) from the
> >>>> DEVICE_TREE build variable as a constant (maybe only if OF_UPSTREAM is
> >>>> enabled).
> >>>
> >>> Please no. We should not continue down this broken path.
> >>
> >> ???
> >>>
> >>>>
> >>>> This would be correct in almost all cases (and wayyy better than the
> >>>> hacky fdtfile generating code we have in mach-snapdragon right now).
> >>>
> >>> Yes, but you really should figure out how to remove that code. It is
> >>> present on other boards too. One of the things not on my list (but I
> >>> wish it were) is to clean up how RISC-V does devicetree selection
> >>> within U-Boot.
> >>
> >> That is why i revived this patch...
> >>>
> >>>>>
> >>>>> For distro-boot, do you mean the scripts? We are trying to deprecate
> >>>>> those. Of course we have brought in all the same work-arounds, etc.,
> >>>>> but with bootstd we can start to clean things up, I hope.
> >>>>>
> >>>>> So let's think about how we can have U-Boot choose the right DT to
> >>>>> boot with.
> >>>>>
> >>>>> Regards,
> >>>>> Simon
> >>>>
> >>>> Heinrich, since it's been a while, if you aren't super interested in
> >>>> re-sending this patch I'd be happy to address the wording feedback and
> >>>> re-spin it, along with a patch setting the default $fdtfile (else I can
> >>>> send that as a follow-up).
> >>>
> >>> The best thing to do here is to use FIT. You can put all the FDTs in a
> >>> FIT and leave the kernel out, if necessary.
> >>
> >> You cannot do this, distros will not do this for thousands of FDTs
> >>>
> >>> Another idea, which I may have suggested before (can't remember) would
> >>> be to add an EFI service which U-Boot implements, which returns the
> >>> correct FDT to use. U-Boot can then scan the files one by one to
> >>> figure it out, although hopefully that would prompt someone to create
> >>> a FIT (or a text file?) which has this information in it.
> >>>
> >>> But fdtfile is just not the right approach.
> >>
> >> You've pushed for FIT but never explained why fdtfile is a bad solution.
> >>>
> >>>>
> >>>> I'll also open an issue for getting support for this added to
> >>>> systemd-boot.
> >>>
> >>> FIT?
> >>>
> >>> Regards,
> >>> Simon
> >>
> >
>
> --
> Caleb (they/them)
>

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

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 897 bytes --]

On Tue, Oct 24, 2023 at 08:20:32AM +0200, Heinrich Schuchardt 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.schuchardt@canonical.com>

Reviewed-by: Tom Rini <trini@konsulko.com>

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

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

[Ilias Apalodimas]

On Tue, 24 Oct 2023 at 09:20, Heinrich Schuchardt
<heinrich.schuchardt@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.schuchardt@canonical.com>
> ---
> v4:
>         Generalize the description of the content of $fdtfile.
> v3:
>         Add documentation
> v2:
>         Use a unique GUID to enable future U-Boot independent
>         standardization.
>         Do not try to add the variable on ACPI based systems.
> ---
>  doc/develop/uefi/uefi.rst  | 14 ++++++++++++++
>  include/efi_loader.h       |  5 +++++
>  lib/efi_loader/efi_setup.c | 30 ++++++++++++++++++++++++++++++
>  3 files changed, 49 insertions(+)
>
> diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
> index fb16ac743a..702c490831 100644
> --- a/doc/develop/uefi/uefi.rst
> +++ b/doc/develop/uefi/uefi.rst
> @@ -916,6 +916,20 @@ So our final format of the FilePathList[] is::
>
>      Loaded image - end node (0xff) - VenMedia - initrd_1 - [end node (0x01) - initrd_n ...] - end node (0xff)
>
> +EFI variable FdtFile
> +~~~~~~~~~~~~~~~~~~~~
> +
> +Ideally U-Boot would always expose a device-tree that can be used for booting
> +any operating systems. Unfortunately operating systems like Linux sometimes
> +break forward and backward compatibility. In this case there is a need to load
> +an operating system version specific device-tree.
> +
> +U-Boot has an environment variable fdtfile identifying the device-tree file to
> +load. The content of this variable is exposed as EFI variable Fdtfile, vendor
> +GUID d45dde69-3bd6-40e0-90d5-6b606aa57730. It contains the device-tree path
> +name as a NUL terminated ASCII string. On many architectures the file name is
> +preceded by a vendor directory ('vendor-directory/board-name.dtb').
> +
>  Links
>  -----
>
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index e24410505f..146e7f1bce 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -152,6 +152,11 @@ static inline efi_status_t efi_launch_capsules(void)
>         EFI_GUID(0x8108ac4e, 0x9f11, 0x4d59, \
>                  0x85, 0x0e, 0xe2, 0x1a, 0x52, 0x2c, 0x59, 0xb2)
>
> +/* Vendor GUID for the FdtFile variable */
> +#define VENDOR_FDTFILE_GUID \
> +       EFI_GUID(0xd45dde69, 0x3bd6, 0x40e0, \
> +                0x90, 0xd5, 0x6b, 0x60, 0x6a, 0xa5, 0x77, 0x30)
> +
>  /* Use internal device tree when starting UEFI application */
>  #define EFI_FDT_USE_INTERNAL NULL
>
> diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
> index e6de685e87..71bcde645b 100644
> --- a/lib/efi_loader/efi_setup.c
> +++ b/lib/efi_loader/efi_setup.c
> @@ -17,6 +17,8 @@
>
>  efi_status_t efi_obj_list_initialized = OBJ_LIST_NOT_INITIALIZED;
>
> +efi_guid_t vendor_fdtfile_guid = VENDOR_FDTFILE_GUID;
> +
>  /*
>   * Allow unaligned memory access.
>   *
> @@ -26,6 +28,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",
> +                                   &vendor_fdtfile_guid,
> +                                   EFI_VARIABLE_BOOTSERVICE_ACCESS |
> +                                   EFI_VARIABLE_RUNTIME_ACCESS |
> +                                   EFI_VARIABLE_READ_ONLY,
> +                                   strlen(val) + 1, val, false);
> +}
> +
>  /**
>   * efi_init_platform_lang() - define supported languages
>   *
> @@ -250,6 +273,13 @@ efi_status_t efi_init_obj_list(void)
>         if (ret != EFI_SUCCESS)
>                 goto out;
>
> +       /* Define EFI variable FdtFile */
> +       if (!CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE)) {
> +               ret = efi_init_fdtfile();
> +               if (ret != EFI_SUCCESS)
> +                       goto out;
> +       }
> +
>         /* Indicate supported features */
>         ret = efi_init_os_indications();
>         if (ret != EFI_SUCCESS)
> --
> 2.40.1
>

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

[Ilias Apalodimas]

On Tue, 24 Oct 2023 at 09:20, Heinrich Schuchardt
<heinrich.schuchardt@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.schuchardt@canonical.com>
> ---
> v4:
>         Generalize the description of the content of $fdtfile.
> v3:
>         Add documentation
> v2:
>         Use a unique GUID to enable future U-Boot independent
>         standardization.
>         Do not try to add the variable on ACPI based systems.
> ---
>  doc/develop/uefi/uefi.rst  | 14 ++++++++++++++
>  include/efi_loader.h       |  5 +++++
>  lib/efi_loader/efi_setup.c | 30 ++++++++++++++++++++++++++++++
>  3 files changed, 49 insertions(+)
>
> diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
> index fb16ac743a..702c490831 100644
> --- a/doc/develop/uefi/uefi.rst
> +++ b/doc/develop/uefi/uefi.rst
> @@ -916,6 +916,20 @@ So our final format of the FilePathList[] is::
>
>      Loaded image - end node (0xff) - VenMedia - initrd_1 - [end node (0x01) - initrd_n ...] - end node (0xff)
>
> +EFI variable FdtFile
> +~~~~~~~~~~~~~~~~~~~~
> +
> +Ideally U-Boot would always expose a device-tree that can be used for booting
> +any operating systems. Unfortunately operating systems like Linux sometimes
> +break forward and backward compatibility. In this case there is a need to load
> +an operating system version specific device-tree.
> +
> +U-Boot has an environment variable fdtfile identifying the device-tree file to
> +load. The content of this variable is exposed as EFI variable Fdtfile, vendor
> +GUID d45dde69-3bd6-40e0-90d5-6b606aa57730. It contains the device-tree path
> +name as a NUL terminated ASCII string. On many architectures the file name is
> +preceded by a vendor directory ('vendor-directory/board-name.dtb').
> +
>  Links
>  -----
>
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index e24410505f..146e7f1bce 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -152,6 +152,11 @@ static inline efi_status_t efi_launch_capsules(void)
>         EFI_GUID(0x8108ac4e, 0x9f11, 0x4d59, \
>                  0x85, 0x0e, 0xe2, 0x1a, 0x52, 0x2c, 0x59, 0xb2)
>
> +/* Vendor GUID for the FdtFile variable */
> +#define VENDOR_FDTFILE_GUID \
> +       EFI_GUID(0xd45dde69, 0x3bd6, 0x40e0, \
> +                0x90, 0xd5, 0x6b, 0x60, 0x6a, 0xa5, 0x77, 0x30)
> +
>  /* Use internal device tree when starting UEFI application */
>  #define EFI_FDT_USE_INTERNAL NULL
>
> diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
> index e6de685e87..71bcde645b 100644
> --- a/lib/efi_loader/efi_setup.c
> +++ b/lib/efi_loader/efi_setup.c
> @@ -17,6 +17,8 @@
>
>  efi_status_t efi_obj_list_initialized = OBJ_LIST_NOT_INITIALIZED;
>
> +efi_guid_t vendor_fdtfile_guid = VENDOR_FDTFILE_GUID;
> +
>  /*
>   * Allow unaligned memory access.
>   *
> @@ -26,6 +28,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",
> +                                   &vendor_fdtfile_guid,
> +                                   EFI_VARIABLE_BOOTSERVICE_ACCESS |
> +                                   EFI_VARIABLE_RUNTIME_ACCESS |
> +                                   EFI_VARIABLE_READ_ONLY,
> +                                   strlen(val) + 1, val, false);
> +}
> +
>  /**
>   * efi_init_platform_lang() - define supported languages
>   *
> @@ -250,6 +273,13 @@ efi_status_t efi_init_obj_list(void)
>         if (ret != EFI_SUCCESS)
>                 goto out;
>
> +       /* Define EFI variable FdtFile */
> +       if (!CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE)) {
> +               ret = efi_init_fdtfile();
> +               if (ret != EFI_SUCCESS)
> +                       goto out;
> +       }
> +
>         /* Indicate supported features */
>         ret = efi_init_os_indications();
>         if (ret != EFI_SUCCESS)
> --
> 2.40.1
>

Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>