u-boot.git/cmd/bootefi.c, branch v2023.01

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

cmd: replace efi_create_handle/add_protocol with InstallMultipleProtocol

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

In general handles should only be deleted if the last remaining protocol
is removed.  Instead of explicitly calling
efi_create_handle -> efi_add_protocol -> efi_delete_handle which blindly
removes all protocols from a handle before removing it,  use
InstallMultiple/UninstallMultiple which adheres to the EFI spec and only
deletes a handle if there are no additional protocols present

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

treewide: Drop bootm_headers_t typedef

2022-09-29T20:07:57+00:00

This is not needed and we should avoid typedefs. Use the struct instead.

Signed-off-by: Simon Glass

efi_loader: memory leak in efi_set_bootdev()

2022-07-13T18:07:07+00:00

efi_dp_str() allocates memory which should be released after use.

Use %pD printf code. Adjust message wording.

Fixes: d837cb1e3b6b ("efi: Add debugging to efi_set_bootdev()")
Signed-off-by: Heinrich Schuchardt

cmd: load: add load command for memory mapped

2022-06-22T15:35:47+00:00

cp.b is used a lot as a way to load binaries to memory and execute
them, however we may need to integrate this with the efi subsystem to
set it up as a bootdev.

So, introduce a loadm command that will be consistent with the other
loadX commands and will call the efi API's.

ex: loadm $kernel_addr $kernel_addr_r $kernel_size

with this a kernel with CONFIG_EFI_STUB enabled will be loaded and
then subsequently booted with bootefi command.

Signed-off-by: Rui Miguel Silva 
Reviewed-by: Tom Rini

cmd/bootefi: correct command syntax

2022-05-28T08:59:27+00:00

For indicating the address and size of a memory region other commands use a
[:] syntax. Do the same for bootefi.

Fixes: 2058983689f0 ("cmd: bootefi: restore ability to boot arbitrary blob")
Signed-off-by: Heinrich Schuchardt

cmd: bootefi: restore ability to boot arbitrary blob

2022-04-23T20:05:33+00:00

Up until commit 5f59518a7b1ae ("efi_loader: setting boot device"), we
could boot an arbitrary blob with bootefi. Indeed, efi_run_image() even
has a special case for missing device paths indicating a payload that
was directly loaded via JTAG, for example.

Restore the ability to inject a UEFI payload into memory and `bootefi`
it. If the address passed isn't the last PE-COFF loaded, then we'll
wipe out the pre-existing DP/Image information and let efi_run_image()
synthesize a memory device path.

An image size is required if we're booting an arbitrary payload, and
the FDT argument has been changed to accept `-`. The size could be
deduced from the image header, but it's required anyways as an explicit
acknowledgment that one's trying to boot an arbitrary payload rather
than accidentally using the wrong address in the single-addr form.

Fixes: 5f59518a7b1a ("efi_loader: setting boot device")
Signed-off-by: Kyle Evans 
Reviewed-by: Heinrich Schuchardt

efi_loader: Ignore DT when ACPI is on

2022-03-20T10:03:06+00:00

For targets that enable ACPI, we should not pass Device Trees into
the payload. However, our distro boot logic always passes the builtin
DT as an argument.

To make it easy to use ACPI with distro boot, let's just ignore the DT
argument to bootefi when ACPI is enabled. That way, we can successfully
distro boot payloads on ACPI enabled targets.

Signed-off-by: Alexander Graf 
Reviewed-by: Mark Kettenis 
Reviewed-by: Heinrich Schuchardt

efi_loader: update the timing of enabling and disabling EFI watchdog

2022-02-26T06:37:01+00:00

UEFI specification requires that 5 minutes watchdog timer is
armed before the firmware's boot manager invokes an EFI boot option.
This watchdog timer is updated as follows, according to the
UEFI specification.

 1) The EFI Image may reset or disable the watchdog timer as needed.
 2) If control is returned to the firmware's boot manager,
    the watchdog timer must be disabled.
 3) On successful completion of EFI_BOOT_SERVICES.ExitBootServices()
    the watchdog timer is disabled.

1) is up to the EFI image, and 3) is already implemented in U-Boot.
This patch implements 2), the watchdog is disabled when control is
returned to U-Boot.

In addition, current implementation arms the EFI watchdog at only
the first "bootefi" invocation. The EFI watchdog must be armed
in every EFI boot option invocation.

Signed-off-by: Masahisa Kojima 
Reviewed-by: Heinrich Schuchardt

efi: Add debugging to efi_set_bootdev()

2022-02-05T19:20:01+00:00

The operation of this function can be confusing. Add some debugging so
we can see what it is doing and when it is called.

Also drop the preprocessor usage.

Signed-off-by: Simon Glass 
Reviewed-by: heinrich Schuchardt