public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: u-boot@lists.denx.de
Subject: [PATCH v2 2/2] efi_loader: identify EFI system partition
Date: Tue, 14 Apr 2020 14:20:38 +0900	[thread overview]
Message-ID: <20200414052038.GA3168@laputa> (raw)
In-Reply-To: <20200406053134.GB27014@linaro.org>

Heinrich,

On Mon, Apr 06, 2020 at 02:31:35PM +0900, AKASHI Takahiro wrote:
> On Mon, Apr 06, 2020 at 07:12:56AM +0200, Heinrich Schuchardt wrote:
> > 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@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?
> 
> I think that most UEFI systems have ability for user to specify
> "boot order."

Any comment?
The discussion and your patch will have some impact on
my efi capsule patch.

-Takahiro Akashi

> -Takahiro Akashi
> > 
> > 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
> > >>
> > 

  reply	other threads:[~2020-04-14  5:20 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-05  9:28 [PATCH v2 0/2] efi_loader: identify EFI system partition Heinrich Schuchardt
2020-04-05  9:28 ` [PATCH v2 1/2] part: detect " Heinrich Schuchardt
2020-04-14  5:31   ` AKASHI Takahiro
2020-04-14  6:01     ` Heinrich Schuchardt
2020-04-05  9:28 ` [PATCH v2 2/2] efi_loader: identify " Heinrich Schuchardt
2020-04-06  4:21   ` AKASHI Takahiro
2020-04-06  5:12     ` Heinrich Schuchardt
2020-04-06  5:31       ` AKASHI Takahiro
2020-04-14  5:20         ` AKASHI Takahiro [this message]
2020-04-14  5:53           ` Heinrich Schuchardt
2020-04-14  6:12             ` AKASHI Takahiro
2020-04-14  7:41               ` Heinrich Schuchardt
2020-04-14 22:57                 ` AKASHI Takahiro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200414052038.GA3168@laputa \
    --to=takahiro.akashi@linaro.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox