[PATCH v2 2/2] efi_loader: identify EFI system partition

[Heinrich Schuchardt]

On 4/6/20 6:21 AM, AKASHI Takahiro wrote:
> Heinrich,
>
> On Sun, Apr 05, 2020 at 11:28:18AM +0200, Heinrich Schuchardt wrote:
>> For capsule updates we need to identify the EFI system partition.
>
> Right, but
>
>> Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de>
>> ---
>> v2:
>> 	no change
>> ---
>>  include/efi_loader.h      |  7 +++++++
>>  lib/efi_loader/efi_disk.c | 20 ++++++++++++++++++++
>>  2 files changed, 27 insertions(+)
>>
>> diff --git a/include/efi_loader.h b/include/efi_loader.h
>> index 3f2792892f..4a45033476 100644
>> --- a/include/efi_loader.h
>> +++ b/include/efi_loader.h
>> @@ -45,6 +45,13 @@ static inline void *guidcpy(void *dst, const void *src)
>>  /* Root node */
>>  extern efi_handle_t efi_root;
>>
>> +/* EFI system partition */
>> +extern struct efi_system_partition {
>> +	enum if_type if_type;
>> +	int devnum;
>> +	u8 part;
>> +} efi_system_partition;
>> +
>>  int __efi_entry_check(void);
>>  int __efi_exit_check(void);
>>  const char *__efi_nesting(void);
>> diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
>> index fc0682bc48..2f752a5e99 100644
>> --- a/lib/efi_loader/efi_disk.c
>> +++ b/lib/efi_loader/efi_disk.c
>> @@ -13,6 +13,8 @@
>>  #include <part.h>
>>  #include <malloc.h>
>>
>> +struct efi_system_partition efi_system_partition;
>> +
>>  const efi_guid_t efi_block_io_guid = EFI_BLOCK_IO_PROTOCOL_GUID;
>>
>>  /**
>> @@ -372,6 +374,24 @@ static efi_status_t efi_disk_add_dev(
>>  	diskobj->ops.media = &diskobj->media;
>>  	if (disk)
>>  		*disk = diskobj;
>> +
>> +	/* Store first EFI system partition */
>
> I don't think that the policy, first comes first serves as system
> partition, is a right decision as
> - the order of device probe on U-Boot is indeterministic, and

Indeterministic would mean that on two runs with the same media provided
you will get different results. I cannot see any source for such
randomness in the U-Boot code. In dm_init_and_scan() the device tree is
scanned and drivers and bound in the sequence of occurrence in the
device tree.

> - there can be several partitions that hold a system partition bit.
>   You may have OS installed on eMMC, but also may have bootable DVD
>   on the system.

This is a similar logic like finding the relevant boot.scr script to run.

What would be the alternative?

Definition via Kconfig would mean that a Linux distribution like Debian
would have to provide a separate U-Boot build for each boot medium that
a user might possibly use (eMMC, SD-card, USB, NVME, SCSI).

Best regards

Heinrich

>
> -Takahiro Akashi
>
>> +	if (part && !efi_system_partition.if_type) {
>> +		int r;
>> +		disk_partition_t info;
>> +
>> +		r = part_get_info(desc, part, &info);
>> +		if (r)
>> +			return EFI_DEVICE_ERROR;
>> +		if (info.bootable & PART_EFI_SYSTEM_PARTITION) {
>> +			efi_system_partition.if_type = desc->if_type;
>> +			efi_system_partition.devnum = desc->devnum;
>> +			efi_system_partition.part = part;
>> +			EFI_PRINT("EFI system partition: %s %d:%d\n",
>> +				  blk_get_if_type_name(desc->if_type),
>> +				  desc->devnum, part);
>> +		}
>> +	}
>>  	return EFI_SUCCESS;
>>  }
>>
>> --
>> 2.25.1
>>