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

[Heinrich Schuchardt]

On 20.10.23 15:21, Simon Glass wrote:
> +Doug Anderson
> 
> Hi Heinrich,
> 
> On Thu, 19 Oct 2023 at 09:09, Heinrich Schuchardt
> <heinrich.schuchardt at canonical.com> wrote:
>>
>> On 19.10.23 15:55, Simon Glass wrote:
>>> Hi Heinrich,
>>>
>>> On Wed, 18 Oct 2023 at 02:15, Heinrich Schuchardt
>>> <heinrich.schuchardt at canonical.com> wrote:
>>>>
>>>> On 10/18/23 05:33, Simon Glass wrote:
>>>>> Hi Heinrich,
>>>>>
>>>>> On Tue, 17 Oct 2023 at 07:50, 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.
>>>>>>
>>>>>> 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>
>>>>>> ---
>>>>>> v2:
>>>>>>            Use a unique GUID to enable future U-Boot independent
>>>>>>            standardization.
>>>>>>            Do not try to add the variable on ACPI based systems.
>>>>>> ---
>>>>>>     include/efi_loader.h       |  5 +++++
>>>>>>     lib/efi_loader/efi_setup.c | 30 ++++++++++++++++++++++++++++++
>>>>>>     2 files changed, 35 insertions(+)
>>>>>
>>>>> I was too slow to reply to v1.
>>>>>
>>>>> Does grub load the DT? I was assuming that U-Boot would pass it on?
>>>>> What is the interface between U-Boot and grub?
>>>>
>>>> The device-tree built into U-Boot is often out of date and not usable to
>>>> boot current Linux. A single device-tree can be loaded by U-Boot from
>>>> file and passed on as EFI configuration table. This device-tree may not
>>>> be compatible with all kernel versions exposed by GRUB.
>>>>
>>>> GRUB provides a devicetree command. It is disabled if you use secure
>>>> boot. At least in Debian and Ubuntu GRUB invokes the
>>>> EFI_DT_FIXUP_PROTOCOL exposed by U-Boot to run U-Boot's device-tree
>>>> fix-ups after loading a device-tree.
>>>>
>>>> Vendor scripts for GRUB like Ubuntu's /etc/grub.d/10_linux add
>>>> devicetree commands to the boot options in grub.cfg.
>>>
>>> Thanks. I wonder if you could document this somewhere? It seems like
>>> there are a lot of options and it is quite complicated.
>>>
>>> Back to the question, I suppose you are expecting grub to load the DT
>>> using this filename? But why doesn't U-Boot load it instead? It seems
>>> very convoluted.
>>
>> A separate file of this name exists for every kernel version installed.
>> The loaded dtb must match the kernel. U-Boot does not know what kernel
>> version will be chosen in GRUB. And for a generic image GRUB does not
>> what board it is on.
>>
>>>
>>> Also, can we test this interface?
>>
>> Neither the sandbox nor QEMU have environment variable fdtfile. And we
>> don't create the EFI variable with ACPI as used on the sandbox.
> 
> I worry that this is creating another interface that some poor sod is
> going to have to deal with in the future. Is this part of the EFI
> standard?

No, the UEFI standard does not care much about device-trees. It only 
defines the GUID for the configuration table.

> 
> We should really be using the compatible string to choose the
> devicetree. Why are we using filenames at all? What is the
> relationship between the compatible string and the filename? Is there
> a lookup table, or should we create one?

There is no 1:1 relationship between compatible string and filename, 
e.g. the following arm64 device-trees use the same compatible string:

amd/amd-overdrive-rev-b0.dts
amd/amd-overdrive-rev-b1.dts

amlogic/meson-axg-jethome-jethub-j110-rev-2.dts
amlogic/meson-axg-jethome-jethub-j110-rev-3.dts

xilinx/zynqmp-zc1751-xm015-dc1.dts
xilinx/zynqmp-zc1751-xm015-dc1.dts
xilinx/zynqmp-zc1751-xm015-dc1.dts
xilinx/zynqmp-zc1751-xm015-dc1.dts

> 
> The correct way of doing this is implemented in U-Boot with
> CONFIG_FIT_BEST_MATCH. Can we mirror something like that in grub, etc?

Why should we write complicated code to find a *possibly* matching file 
if we already know the filename that needs to be loaded?

Best regards

Heinrich

> 
> Regards,
> Simon