u-boot.git/lib/efi_loader/efi_load_initrd.c, branch v2025.01

efi_loader: rename struct efi_initrd_dp to efi_lo_dp_prefix

2024-06-10T09:43:37+00:00

As we now also store device-tree device-paths in load options rename
struct efi_initrd_dp to efi_lo_dp_prefix.

Signed-off-by: Heinrich Schuchardt

efi_loader: pass GUID by address to efi_dp_from_lo

2024-05-01T06:40:42+00:00

We should not pass GUIDs by value as this requires copying.

Signed-off-by: Heinrich Schuchardt 
Reviewed-by: Ilias Apalodimas

efi_loader: use event callback for initrd deregistration

2024-04-20T06:21:59+00:00

Currently efi_initrd_deregister() is called in bootefi.c
when the image started from bootefi command returns.
Since efi_guid_event_group_return_to_efibootmgr event is
implemented, so let's use this event for invoking
initrd deregistration.

Signed-off-by: Masahisa Kojima 
Reviewed-by: Ilias Apalodimas 
Tested-by: Ilias Apalodimas 
Signed-off-by: Heinrich Schuchardt

efi_loader: Remove

2023-12-21T13:54:37+00:00

We largely do not need  in these files, so drop it. The only
exception here is that efi_freestanding.c needs  and had
been getting that via .

Reviewed-by: Simon Glass 
Signed-off-by: Tom Rini

efi_loader: remove efi_delete_handle on loadfile2

2022-10-16T10:23:22+00:00

Loadfile2 code is installing two protocols on it's own handle
and uses efi_delete_handle() to clean it up on failure(s). However
commit 05c4c9e21ae6 ("efi_loader: define internal implementations of
install/uninstallmultiple") prepares the ground for us to clean up
efi_delete_handle() used in favor of Install/UninstallMultipleProtocol.

While at it clean up the non needed void casts to (void *) on the
protolcol installation.

Signed-off-by: Ilias Apalodimas 
Reviewed-by: Heinrich Schuchardt

efi_loader: define internal implementations of install/uninstallmultiple

2022-10-06T20:54:58+00:00

A following patch is cleaning up the core EFI code trying to remove
sequences of efi_create_handle, efi_add_protocol.

Although this works fine there's a problem with the latter since it is
usually combined with efi_delete_handle() which blindly removes all
protocols on a handle and deletes the handle.  We should try to adhere to
the EFI spec which only deletes a handle if the last instance of a protocol
has been removed.  Another problem is that efi_delete_handle() never checks
for opened protocols,  but the EFI spec defines that the caller is
responsible for ensuring that there are no references to a protocol
interface that is going to be removed.

So let's fix this by replacing all callsites of
efi_create_handle(), efi_add_protocol() , efi_delete_handle() with
Install/UninstallMultipleProtocol.

In order to do that redefine functions that can be used by the U-Boot
proper internally and add '_ext' variants that will be used from the
EFI API

Signed-off-by: Ilias Apalodimas 
Reviewed-by: Heinrich Schuchardt

efi_loader: fix efi_initrd_deregister()

2022-09-30T00:03:23+00:00

Don't try to delete a non-existent handle.

Signed-off-by: Heinrich Schuchardt

efi_loader: avoid multiple local copies of lf2_initrd_guid

2021-10-21T01:46:04+00:00

Create the GUID as a global variable.

Signed-off-by: Heinrich Schuchardt 
Reviewed-by: Ilias Apalodimas

efi_loader: Replace config option for initrd loading

2021-03-25T19:14:26+00:00

Up to now we install EFI_LOAD_FILE2_PROTOCOL to load an initrd
unconditionally. Although we correctly return various EFI exit codes
depending on the file status (i.e EFI_NO_MEDIA, EFI_NOT_FOUND etc), the
kernel loader, only falls back to the cmdline interpreted initrd if the
protocol is not installed.

This creates a problem for EFI installers, since they won't be able to
load their own initrd and continue the installation. It also makes the
feature hard to use, since we can either have a single initrd or we have
to recompile u-boot if the filename changes.

So let's introduce a different logic that will decouple the initrd
path from the config option we currently have.
When defining a UEFI BootXXXX we can use the filepathlist and store
a file path pointing to our initrd. Specifically the EFI spec describes:

"The first element of the array is a device path that describes the device
and location of the Image for this load option. Other device paths may
optionally exist in the FilePathList, but their usage is OSV specific"

When the EFI application is launched through the bootmgr, we'll try to
interpret the extra device path. If that points to a file that exists on
our disk, we'll now install the load_file2 and the efi-stub will be able
to use it.

This opens up another path using U-Boot and defines a new boot flow.
A user will be able to control the kernel/initrd pairs without explicit
cmdline args or GRUB.

Signed-off-by: Ilias Apalodimas 
Reviewed-by: Heinrich Schuchardt

efi_loader: Remove unused headers from efi_load_initrd.c

2020-12-31T13:33:22+00:00

dm.h and env.h serve no purpose here. Remove them and sort the
remaining in alphabetical order.

Signed-off-by: Ilias Apalodimas 
Reviewed-by: Heinrich Schuchardt