All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.