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.g...@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 >>