[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 at canonical.com>
>>>
>>> On 10/25/23 20:23, Simon Glass wrote:
>>>> Hi Heinrich,
>>>>
>>>> On Tue, 24 Oct 2023 at 18:02, Simon Glass <sjg at google.com> wrote:
>>>>>
>>>>> Hi Heinrich,
>>>>>
>>>>> On Mon, 23 Oct 2023 at 23:20, Heinrich Schuchardt
>>>>> <heinrich.schuchardt at canonical.com> wrote:
>>>>>>
>>>>>> Forward and backward compatibility of Linux kernel device-trees is
>>>>>> sometimes missing. One solution approach is to load a kernel specific
>>>>>> device-tree. This can either be done via a U-Boot scripts (like the one
>>>>>> generated by Debian package flash-kernel or by a boot loader like GRUB.
>>>>>> The boot loader approach currently requires to know the device-tree name
>>>>>> before first boot which makes it unusable for generic images.
>>>>>>
>>>>>> Expose the device-tree file name as EFI variable FdtFile.
>>>>>> This will allow bootloaders to load a kernel specific device-tree.
>>>>>
>>>>> 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 at 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