[PATCH v2 0/8] efi_loader: improve device-tree loading

[Simon Glass]

Hi Heinrich,

On Wed, 5 Jun 2024 at 02:40, Heinrich Schuchardt
<heinrich.schuchardt at canonical.com> wrote:
>
> On 29.05.24 18:30, Simon Glass wrote:
> > Hi,
> >
> > On Tue, 28 May 2024 at 18:38, E Shattow <lucent at gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> On Tue, May 28, 2024 at 7:43 AM Heinrich Schuchardt
> >> <heinrich.schuchardt at canonical.com> wrote:
> >>>
> >>> In U-Boot EFI boot options can already specify both an EFI binary and
> >>> an initrd. With this series we can additionally define the matching
> >>> device-tree to be loaded in the boot option.
> >>>
> >>> With the last patch the boot manager will fall back the device-tree
> >>> specified by $fdtfile in directories '/dtb/', '/', or '/dtb/current/'
> >>> on the boot device if no device-tree is specified in the boot
> >>> option or via a bootefi command parameter.
> >>>
> >>
> >> As tested the $fdtfile environment variable has no effect on
> >> global EFI boot when i.e. EFI/BOOT/BOOTRISCV64.EFI
> >> on EFI System Partition and no user-added boot option;
> >> $fdtfile env variable is not used with "mmc 0" or whichever
> >> global boot option is enabled by default in the boot order.
> >>
> >> Adding a boot option for EFI/BOOT/BOOTRISCV64.EFI
> >> and giving this priority in the boot order allows $fdtfile to
> >> be effective here. This is consistent with what is described
> >> by the series. Would the global EFI boot also get support
> >> for $fdtfile either with this or a later series?
> >>
> >>> v2:
> >>>          Update efi_dp_concat() instead of new function efi_dp_merge().
> >>>          Carve out a function efi_load_option_dp_join() which we can
> >>>          use both for the eficonfig and the efidebug command.
> >>>          Rename variables id_dp, final_dp_size.
> >>>          Rename create_initrd_dp() to create_lo_dp_part().
> >>>          Use enum as parameter for create_lo_dp_part().
> >>>          Put all related changes into one patch.
> >>>
> >>> Heinrich Schuchardt (8):
> >>>    efi_loader: allow concatenation with contained end node
> >>>    cmd: eficonfig: add support for setting fdt
> >>>    cmd: efidebug: add support for setting fdt
> >>>    efi_loader: load device-tree specified in boot option
> >>>    efi_loader: move distro_efi_get_fdt_name()
> >>>    efi_loader: return binary from efi_dp_from_lo()
> >>>    efi_loader: export efi_load_image_from_path
> >>>    efi_loader: load distro dtb in bootmgr
> >>>
> >>>   boot/bootmeth_efi.c                        |  60 +---------
> >>>   cmd/eficonfig.c                            |  83 +++++++++----
> >>>   cmd/efidebug.c                             | 130 +++++++++++++++------
> >>>   include/efi_loader.h                       |  24 +++-
> >>>   lib/efi_loader/Makefile                    |   1 +
> >>>   lib/efi_loader/efi_bootbin.c               |   2 +-
> >>>   lib/efi_loader/efi_bootmgr.c               |  75 +++++++++++-
> >>>   lib/efi_loader/efi_boottime.c              |   3 +-
> >>>   lib/efi_loader/efi_device_path.c           |  40 ++++---
> >>>   lib/efi_loader/efi_device_path_utilities.c |   2 +-
> >>>   lib/efi_loader/efi_fdt.c                   | 117 +++++++++++++++++++
> >>>   lib/efi_loader/efi_helper.c                |  44 +++++++
> >>>   12 files changed, 445 insertions(+), 136 deletions(-)
> >>>   create mode 100644 lib/efi_loader/efi_fdt.c
> >>>
> >>> --
> >>> 2.43.0
> >>>
> >>
> >
> > Can we use the best-match compatible approach as expected by the new
> > 'make image.fit' in Linux?
> >
> > Filenames should be deprecated IMO. I am happy to help work on how to
> > do that if you agree.
>
> Hello Simon,
>
> It is the OS that creates boot options. The OS can determine the exact
> dtb file based on the compatible string and the kernel version once per
> kernel upgrade. This is much more efficient than doing the same on every
> boot.
>
> Replacing $fdtfile by a matching logic could make sense. But please
> consider the effect on boot time if have to read through more than 1000
> arm64 dtbs with U-Boot's non-caching file-system drivers.

The suggested option here is to use FIT, which is very fast at
scanning the files. Please see [1]

Failing that, we could implement a way (in FIT) of specifying that the
FDT is in an external file. In that case FIT would become a mapping
from compatible strings to filenames.

Regards,
Simon

[1] https://github.com/open-source-firmware/flat-image-tree/blob/main/source/chapter3-usage.rst