u-boot.git/lib/efi_loader, branch v2022.10

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

lib: efi_loader: don't delete invalid handles

2022-09-09T14:07:54+00:00

Change efi_delete_handle() to not free EFI handles twice.

This change tries to resolved an issue seen since U-Boot v2022.07
in which ExitBootService() attempts to release some EFI handles twice.

The issue was seen booting a EFI shell that invokes 'connect -r' and
then boots a Linux kernel. Execution of connect command makes EFI
subsystem to bind a block device for each root block devices EFI handles.
However these EFI device handles are already bound to a driver and we
can have 2 registered devices relating to the same EFI handler. On
ExitBootService(), the loop removing the devices makes these EFI handles
to be released twice which corrupts memory.

This patch prevents the memory release operation caused by the issue but
but does not resolve the underlying problem.

Signed-off-by: Etienne Carriere 

Add log message.
Reviewed-by: Heinrich Schuchardt 
Reviewed-by: Ilias Apalodimas

efi_loader: fix display of NVMe EUI-64

2022-09-03T08:49:17+00:00

UEFI specification 2.9A requires to display the EUI-64 "in hexadecimal
format with byte 7 first (i.e., on the left) and byte 0 last".

This is in contrast to what the NVMe specification wants.
But it is what EDK II has been implementing.

Here is an example with the patch applied:

    qemu-system-aarch64 -machine virt -cpu cortex-a72 -nographic \
    -bios denx/u-boot.bin \
    -device nvme,id=nvme1,serial=9ff81223 \
    -device nvme-ns,bus=nvme1,drive=nvme1n0,eui64=0x123456789ABCDEF0 \
    -drive file=arm64.img,if=none,format=raw,id=nvme1n0

    => nvme scan
    => efidebug devices
    Device Path
    ====================
    /VenHw(…)/NVMe(0x1,f0-de-bc-9a-78-56-34-12)

Signed-off-by: Heinrich Schuchardt

efi: ECPT add EBBRv2.0 conformance profile

2022-09-03T08:13:26+00:00

Display the EBBRv2.0 conformance in the ECPT table.

The EBBRv2.0 conformance profile is set in the ECPT if
CONFIG_EFI_EBBR_2_0_CONFORMANCE=y.

Signed-off-by: Jose Marinho 

Add dependencies for CONFIG_EFI_EBBR_2_0_CONFORMANCE.
Enable the setting by default.
Reviewed-by: Heinrich Schuchardt

efi: Create ECPT table

2022-09-03T07:35:48+00:00

The ECPT table will be included in the UEFI specification 2.9+.
The ECPT table was introduced in UEFI following the code-first path. The
acceptance ticket can be viewed at:
	https://bugzilla.tianocore.org/show_bug.cgi?id=3591

The Conformance Profiles table is a UEFI configuration table that contains
GUID of the UEFI profiles that the UEFI implementation conforms with.

The ECPT table is created when CONFIG_EFI_ECPT=y.
The config is set by default.

Signed-off-by: Jose Marinho 
Reviewed-by: Heinrich Schuchardt

efi_loader: support CTRL+\ - CTRL+_

2022-09-03T06:16:09+00:00

In the extended text input protocol support input of control letters
0x1c - 0x1f.

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

efi_loader: compliance Simple Text Input Ex Protocol

2022-09-03T06:16:09+00:00

We cannot expect the buffers passed to the input protocols to be zero
filled. If only modifier keys are pressed, we have to return EFI_NOT_READY
but we still have to fill the key structure.

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

efi_loader: printing UEFI revision in helloworld.efi

2022-09-03T06:16:09+00:00

We need to support multiple digits in the parts of the UEFI verision
number. E.g.

    EFI_SPECIFICATION_VERSION = (123 << 16) | 456

must be printed as

    123.45.6

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

efi_loader: ensure all block devices are probed

2022-09-01T05:21:25+00:00

Only probed block devices are available in the UEFI sub-system. Multiple
block devices may be involved in the boot process. So we have to make sure
that all block devices are probed. Another reason is that we store UEFI
variables on the ESP which may be on any block device.

On the sandbox before the patch:

=> efidebug devices
No EFI system partition
Device           Device Path
================ ====================
000000001b027c70 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
000055d078bc1ae0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Uart(0,0,D,D)
000000001b22e0b0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/MAC(020011223344,1)

After the patch:

=> efidebug devices
No EFI system partition
Device           Device Path
================ ====================
000000001b027c70 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
000055bdac8ddae0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Uart(0,0,D,D)
000000001b230920 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(2)/SD(0)
000000001b233ac0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(1)
000000001b233b80 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(1)/HD(1,GPT,d0a914ee-a71c-fc1e-73f0-7e302b0e6c20,0x30,0x1)
000000001b234110 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(1)/HD(2,GPT,9330a0ea-8aff-f67a-294c-fa05d60896c3,0x31,0x1)
000000001b22f0e0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(2)
000000001b238df0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/MAC(020011223344,1)

Fixes: a9bf024b2933 ("efi_loader: disk: a helper function to create efi_disk objects from udevice")
Signed-off-by: Heinrich Schuchardt

efi_loader: disk: remove unused field

2022-08-20T06:38:12+00:00

The field, ifname, in efi_disk_obj is set but never used anywhere.
Just remove it.

Signed-off-by: AKASHI Takahiro 
Reviewed-by: Heinrich Schuchardt