u-boot.git/lib/efi_loader/efi_disk.c, branch v2022.10 Unnamed repository; edit this file 'description' to name the repository. efi_loader: ensure all block devices are probed 2022-09-01T05:21:25+00:00 Heinrich Schuchardt heinrich.schuchardt@canonical.com 2022-08-31T14:37:35+00:00 d5391bf02b9dc6a84fe33ba913caf70061909950 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 <heinrich.schuchardt@canonical.com> 
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 <heinrich.schuchardt@canonical.com>
efi_loader: disk: remove unused field 2022-08-20T06:38:12+00:00 AKASHI Takahiro takahiro.akashi@linaro.org 2022-08-19T00:48:30+00:00 ab31c8a158715abe4bceadb8eb78aa3e281d0bdc The field, ifname, in efi_disk_obj is set but never used anywhere. Just remove it. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> 
The field, ifname, in efi_disk_obj is set but never used anywhere.
Just remove it.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
efi_loader: move udevice pointer into struct efi_object 2022-08-13T09:09:49+00:00 Masahisa Kojima masahisa.kojima@linaro.org 2022-07-22T02:39:10+00:00 ee576662947330748b4cca1890d0e1d826d870f4 This is a preparation patch to provide the unified method to access udevice pointer associated with the EFI handle by adding udevice pointer into struct efi_object. The patch also introduces a helper function efi_link_dev() to link the udevice and EFI handle. The EFI handles of both EFI block io driver implemented in lib/efi_loader/efi_disk.c and EFI block io driver implemented as EFI payload can access the udevice pointer in the struct efi_object. We can use this udevice pointer to get the U-Boot friendly block device name(e.g. mmc 0:1, nvme 0:1) through EFI handle. Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> 
This is a preparation patch to provide the unified method
to access udevice pointer associated with the EFI handle
by adding udevice pointer into struct efi_object.
The patch also introduces a helper function efi_link_dev()
to link the udevice and EFI handle.

The EFI handles of both EFI block io driver implemented in
lib/efi_loader/efi_disk.c and EFI block io driver implemented
as EFI payload can access the udevice pointer in the struct efi_object.
We can use this udevice pointer to get the U-Boot friendly
block device name(e.g. mmc 0:1, nvme 0:1) through EFI handle.

Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
EFI: Fix ReadBlocks API reading incorrect sector for UCLASS_PARTITION devices 2022-07-02T12:19:12+00:00 Paul Barbieri plb365@gmail.com 2022-06-30T11:02:04+00:00 7a85f32413a34b18a2f84c865d7b448790200b13 The requsted partition disk sector incorrectly has the parition start sector added in twice for UCLASS_PARTITION devices. The efi_disk_rw_blocks() routine adds the diskobj->offset to the requested lba. When the device is a UCLASS_PARTITION, the dev_read() or dev_write() routine is called which adds part-gpt_part_info.start. This causes I/O to the wrong sector. Takahiro Akashi suggested removing the offset field from the efi_disk_obj structure since disk-uclass.c handles the partition start biasing. Device types other than UCLASS_PARTITION set the diskobj->offset field to zero which makes the field unnecessary. This change removes the offset field from the structure and removes all references from the code which is isolated to the lib/efi_loader/efi_disk.c module. This change also adds a test for the EFI ReadBlocks() API in the EFI selftest code. There is already a test for reading a FAT file. The new test uses ReadBlocks() to read the same "disk" block and compare it to the data read from the file system API. Signed-Off-by: Paul Barbieri <plb365@gmail.com> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> 
The requsted partition disk sector incorrectly has the parition start
sector added in twice for UCLASS_PARTITION devices. The efi_disk_rw_blocks()
routine adds the diskobj->offset to the requested lba. When the device
is a UCLASS_PARTITION, the dev_read() or dev_write() routine is called
which adds part-gpt_part_info.start. This causes I/O to the wrong sector.

Takahiro Akashi suggested removing the offset field from the efi_disk_obj
structure since disk-uclass.c handles the partition start biasing. Device
types other than UCLASS_PARTITION set the diskobj->offset field to zero
which makes the field unnecessary. This change removes the offset field
from the structure and removes all references from the code which is
isolated to the lib/efi_loader/efi_disk.c module.

This change also adds a test for the EFI ReadBlocks() API in the EFI
selftest code. There is already a test for reading a FAT file. The new
test uses ReadBlocks() to read the same "disk" block and compare it to
the data read from the file system API.

Signed-Off-by: Paul Barbieri <plb365@gmail.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
efi_loader: disk: add efi_disk_is_removable() 2022-05-28T08:59:27+00:00 AKASHI Takahiro takahiro.akashi@linaro.org 2022-05-12T02:29:01+00:00 05f391e2fc73bf9f746534929b4436b86518f4fc This helper function will be used to determine if the device is removable media, initially for handling a short-path loading. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> 
This helper function will be used to determine if the device is
removable media, initially for handling a short-path loading.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
efi_loader: disk: allow blk devices even without UCLASS_PARTITION 2022-04-29T12:25:40+00:00 AKASHI Takahiro takahiro.akashi@linaro.org 2022-04-28T04:49:16+00:00 6c640422baa46c5061efa5d2ff1b386bca72253c While GPT partition is mandated in UEFI specification, CONFIG_PARTITION is seen optional under the current implementation. So modify efi_disk_rw_blocks() to allow accepting UCLASS_BLK devices. Fixes: commit d97e98c887ed ("efi_loader: disk: use udevice instead of blk_desc") Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Mark Kettenis <kettenis@openbsd.org> 
While GPT partition is mandated in UEFI specification, CONFIG_PARTITION is
seen optional under the current implementation.
So modify efi_disk_rw_blocks() to allow accepting UCLASS_BLK devices.

Fixes: commit d97e98c887ed ("efi_loader: disk: use udevice instead of blk_desc")
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Tested-by: Mark Kettenis <kettenis@openbsd.org>
efi_loader: disk: use udevice instead of blk_desc 2022-04-23T20:05:41+00:00 AKASHI Takahiro takahiro.akashi@linaro.org 2022-04-19T01:05:17+00:00 d97e98c887ed8fa4a339350c02f093f03cd1cf4d In most of all cases, we can avoid using blk_desc which is expected to be private to udevice(UCLASS_BLK), that is, the data should not be manipulated outside the device driver unless really needed. Now efi_disk's internally use dev_read/write() interfaces if CONFIG_PARTITIONS is enabled. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> 
In most of all cases, we can avoid using blk_desc which is expected
to be private to udevice(UCLASS_BLK), that is, the data should not
be manipulated outside the device driver unless really needed.

Now efi_disk's internally use dev_read/write() interfaces
if CONFIG_PARTITIONS is enabled.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
efi_loader: disk: not delete BLK device for BLK(IF_TYPE_EFI_LOADER) devices 2022-04-23T20:05:41+00:00 AKASHI Takahiro takahiro.akashi@linaro.org 2022-04-19T01:05:15+00:00 a3cb34e9b7506dec1e5f55279f17a12eded86c48 When we create an efi_disk device with an UEFI application using driver binding protocol, the 'efi_driver' framework tries to create a corresponding block device(UCLASS_BLK/IF_TYPE_EFI). This will lead to calling a PROBE callback, efi_disk_probe(). In this case, however, we don't need to create another "efi_disk" device as we already have this device instance. So we should avoid recursively invoke further processing in the callback function. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> 
When we create an efi_disk device with an UEFI application using driver
binding protocol, the 'efi_driver' framework tries to create
a corresponding block device(UCLASS_BLK/IF_TYPE_EFI). This will lead to
calling a PROBE callback, efi_disk_probe().
In this case, however, we don't need to create another "efi_disk" device
as we already have this device instance.

So we should avoid recursively invoke further processing in the callback
function.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
efi_loader: disk: a helper function to delete efi_disk objects 2022-04-23T20:05:41+00:00 AKASHI Takahiro takahiro.akashi@linaro.org 2022-04-19T01:05:14+00:00 b406eb04c360b4842a02bcfedd9bbee015c3d127 This function is expected to be called, in particular from dm's pre_remove hook, when associated block devices no longer exist. Add efi_disk_remove() function. This function removes an efi_disk object for a raw disk device (UCLASS_BLK) and related objects for its partitions (UCLASS_PARTITION). So this function is expected to be called through driver model's "remove" interface every time a raw disk device is to be disconnected. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> 
This function is expected to be called, in particular from dm's pre_remove
hook, when associated block devices no longer exist.

Add efi_disk_remove() function.
This function removes an efi_disk object for a raw disk device (UCLASS_BLK)
and related objects for its partitions (UCLASS_PARTITION).

So this function is expected to be called through driver model's "remove"
interface every time a raw disk device is to be disconnected.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
efi_loader: disk: not create BLK device for BLK(IF_TYPE_EFI_LOADER) devices 2022-04-23T20:05:41+00:00 AKASHI Takahiro takahiro.akashi@linaro.org 2022-04-19T01:05:13+00:00 3c809dfed757c37b92ff543c8f1c941407bafc2e When we create an efi_disk device with an UEFI application using driver binding protocol, the 'efi_driver' framework tries to create a corresponding block device(UCLASS_BLK/IF_TYPE_EFI). This will lead to calling a PROBE callback, efi_disk_probe(). In this case, however, we don't need to create another "efi_disk" device as we already have this device instance. So we should avoid recursively invoke further processing in the callback function. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> 
When we create an efi_disk device with an UEFI application using driver
binding protocol, the 'efi_driver' framework tries to create
a corresponding block device(UCLASS_BLK/IF_TYPE_EFI). This will lead to
calling a PROBE callback, efi_disk_probe().
In this case, however, we don't need to create another "efi_disk" device
as we already have this device instance.

So we should avoid recursively invoke further processing in the callback
function.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>