Hi,
This is the revised version of [1].
After the discussion we had with Akashi and Heinrich, storing a device path in the variable is preferable to a custom U-Boot string.
In hindsight and after reading the EFI spec a bit further, using a custom EFI variable to hold that device path doesn't look great either, we can do better than that. Turns out we can use the array of device paths defined in the EFI spec and store OS specific device paths [2]. So I converted this to an RFC instead, exploring this idea. The variabale is now stored as the second array member in the EFI_LOAD_OPTIONS and later retrieved in order to load the file when the kernel requests it. Another big change is that installing the EFI protocol itself will cause an error if the file's not found and the bootmgr will fallback to other valid boot options.
The efi selftest for the load option itself is not included in the RFC. I'll go ahead and change it if there's general agreement on the feature.
[1] https://lists.denx.de/pipermail/u-boot/2020-December/436080.html [2] https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf section 3.1.3
Ilias Apalodimas (3): efi_loader: Introduce helper functions for EFI efi_loader: efi_loader: Replace config option for initrd loading efidebug: add multiple device path instances on Boot####
cmd/bootefi.c | 3 + cmd/efidebug.c | 89 ++++++++++++++++-- include/efi_helper.h | 23 +++++ include/efi_loader.h | 1 + lib/efi_loader/Kconfig | 13 +-- lib/efi_loader/efi_bootmgr.c | 3 + lib/efi_loader/efi_helper.c | 146 +++++++++++++++++++++++++++++ lib/efi_loader/efi_load_initrd.c | 154 ++++++++++++++++--------------- 8 files changed, 341 insertions(+), 91 deletions(-) create mode 100644 include/efi_helper.h create mode 100644 lib/efi_loader/efi_helper.c