* [PATCH] efi_loader: improve detection of ESP for storing UEFI variables
@ 2020-11-08 23:58 Paulo Alcantara
2020-11-09 10:02 ` Heinrich Schuchardt
0 siblings, 1 reply; 11+ messages in thread
From: Paulo Alcantara @ 2020-11-08 23:58 UTC (permalink / raw)
To: u-boot
The UEFI specification does not restrict on the number and location of
ESPs in a system. They are discovered as required by looking at the
partition type, but firmware implementations are allowed to support
ESPs which do not contain a valid partition type.
Besides checking for the partition type, for non-removable media check
if /EFI directory exists, otherwise check if /EFI/BOOT/BOOT{ARCH}.EFI
file exists as specified in UEFI 2.8 "13.3.1.3 Directory Structure".
Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
---
lib/efi_loader/efi_disk.c | 60 +++++++++++++++++++++++++--------------
1 file changed, 38 insertions(+), 22 deletions(-)
diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index 7bd1ccec4501..2940a2edf2e8 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -335,6 +335,35 @@ static int efi_fs_exists(struct blk_desc *desc, int part)
return 1;
}
+/**
+ * efi_part_is_esp() - check if a partition is an EFI system partition
+ *
+ * @desc: block device descriptor
+ * @part: partition number
+ * Return: true if a partition is an EFI system partition
+ * false otherwise
+ */
+static bool efi_part_is_esp(struct blk_desc *desc, int part)
+{
+ int ret;
+ struct disk_partition info;
+
+ ret = part_get_info(desc, part, &info);
+ if (ret)
+ return false;
+
+ if (info.bootable & PART_EFI_SYSTEM_PARTITION)
+ return true;
+
+ if (fs_set_blk_dev_with_part(desc, part))
+ return false;
+
+ if (!desc->removable)
+ return !!fs_exists("/EFI");
+
+ return !!fs_exists("/EFI/BOOT/" BOOTEFI_NAME);
+}
+
/**
* efi_disk_add_dev() - create a handle for a partition or disk
*
@@ -436,21 +465,14 @@ static efi_status_t efi_disk_add_dev(
*disk = diskobj;
/* Store first EFI system partition */
- if (part && !efi_system_partition.if_type) {
- int r;
- struct disk_partition 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);
- }
+ if (part && !efi_system_partition.if_type &&
+ efi_part_is_esp(desc, part)) {
+ 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;
}
@@ -614,9 +636,7 @@ bool efi_disk_is_system_part(efi_handle_t handle)
{
struct efi_handler *handler;
struct efi_disk_obj *diskobj;
- struct disk_partition info;
efi_status_t ret;
- int r;
/* check if this is a block device */
ret = efi_search_protocol(handle, &efi_block_io_guid, &handler);
@@ -625,9 +645,5 @@ bool efi_disk_is_system_part(efi_handle_t handle)
diskobj = container_of(handle, struct efi_disk_obj, header);
- r = part_get_info(diskobj->desc, diskobj->part, &info);
- if (r)
- return false;
-
- return !!(info.bootable & PART_EFI_SYSTEM_PARTITION);
+ return efi_part_is_esp(diskobj->desc, diskobj->part);
}
--
2.29.2
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH] efi_loader: improve detection of ESP for storing UEFI variables
2020-11-08 23:58 [PATCH] efi_loader: improve detection of ESP for storing UEFI variables Paulo Alcantara
@ 2020-11-09 10:02 ` Heinrich Schuchardt
2020-11-09 13:24 ` Paulo Alcantara
0 siblings, 1 reply; 11+ messages in thread
From: Heinrich Schuchardt @ 2020-11-09 10:02 UTC (permalink / raw)
To: u-boot
On 09.11.20 00:58, Paulo Alcantara wrote:
> The UEFI specification does not restrict on the number and location of
> ESPs in a system. They are discovered as required by looking at the
> partition type, but firmware implementations are allowed to support
> ESPs which do not contain a valid partition type.
I guess you refer to chapter "13.3.3 Number and Location of System
Partitions" of the UEFI spec saying: "Further, UEFI implementations may
allow the use of conforming FAT partitions which do not use the ESP GUID."
Why should U-Boot support FAT partitions that are not of type FAT 0xef
and GPT partition that do not use the ESP GUID?
Best regards
Heinrich
>
> Besides checking for the partition type, for non-removable media check
> if /EFI directory exists, otherwise check if /EFI/BOOT/BOOT{ARCH}.EFI
> file exists as specified in UEFI 2.8 "13.3.1.3 Directory Structure".
>
> Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
> ---
> lib/efi_loader/efi_disk.c | 60 +++++++++++++++++++++++++--------------
> 1 file changed, 38 insertions(+), 22 deletions(-)
>
> diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
> index 7bd1ccec4501..2940a2edf2e8 100644
> --- a/lib/efi_loader/efi_disk.c
> +++ b/lib/efi_loader/efi_disk.c
> @@ -335,6 +335,35 @@ static int efi_fs_exists(struct blk_desc *desc, int part)
> return 1;
> }
>
> +/**
> + * efi_part_is_esp() - check if a partition is an EFI system partition
> + *
> + * @desc: block device descriptor
> + * @part: partition number
> + * Return: true if a partition is an EFI system partition
> + * false otherwise
> + */
> +static bool efi_part_is_esp(struct blk_desc *desc, int part)
> +{
> + int ret;
> + struct disk_partition info;
> +
> + ret = part_get_info(desc, part, &info);
> + if (ret)
> + return false;
> +
> + if (info.bootable & PART_EFI_SYSTEM_PARTITION)
> + return true;
> +
> + if (fs_set_blk_dev_with_part(desc, part))
> + return false;
> +
> + if (!desc->removable)
> + return !!fs_exists("/EFI");
> +
> + return !!fs_exists("/EFI/BOOT/" BOOTEFI_NAME);
> +}
> +
> /**
> * efi_disk_add_dev() - create a handle for a partition or disk
> *
> @@ -436,21 +465,14 @@ static efi_status_t efi_disk_add_dev(
> *disk = diskobj;
>
> /* Store first EFI system partition */
> - if (part && !efi_system_partition.if_type) {
> - int r;
> - struct disk_partition 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);
> - }
> + if (part && !efi_system_partition.if_type &&
> + efi_part_is_esp(desc, part)) {
> + 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;
> }
> @@ -614,9 +636,7 @@ bool efi_disk_is_system_part(efi_handle_t handle)
> {
> struct efi_handler *handler;
> struct efi_disk_obj *diskobj;
> - struct disk_partition info;
> efi_status_t ret;
> - int r;
>
> /* check if this is a block device */
> ret = efi_search_protocol(handle, &efi_block_io_guid, &handler);
> @@ -625,9 +645,5 @@ bool efi_disk_is_system_part(efi_handle_t handle)
>
> diskobj = container_of(handle, struct efi_disk_obj, header);
>
> - r = part_get_info(diskobj->desc, diskobj->part, &info);
> - if (r)
> - return false;
> -
> - return !!(info.bootable & PART_EFI_SYSTEM_PARTITION);
> + return efi_part_is_esp(diskobj->desc, diskobj->part);
> }
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH] efi_loader: improve detection of ESP for storing UEFI variables
2020-11-09 10:02 ` Heinrich Schuchardt
@ 2020-11-09 13:24 ` Paulo Alcantara
2020-11-09 13:51 ` Mark Kettenis
2020-11-09 13:58 ` Heinrich Schuchardt
0 siblings, 2 replies; 11+ messages in thread
From: Paulo Alcantara @ 2020-11-09 13:24 UTC (permalink / raw)
To: u-boot
Heinrich Schuchardt <xypron.glpk@gmx.de> writes:
> On 09.11.20 00:58, Paulo Alcantara wrote:
>> The UEFI specification does not restrict on the number and location of
>> ESPs in a system. They are discovered as required by looking at the
>> partition type, but firmware implementations are allowed to support
>> ESPs which do not contain a valid partition type.
>
> I guess you refer to chapter "13.3.3 Number and Location of System
> Partitions" of the UEFI spec saying: "Further, UEFI implementations
> may allow the use of conforming FAT partitions which do not use the
> ESP GUID."
Yep, sorry. Thanks for pointing it out!
> Why should U-Boot support FAT partitions that are not of type FAT 0xef
> and GPT partition that do not use the ESP GUID?
In most UEFI (EDK2-based) systems I used, I could boot my OSes and
diagnostic tools by simply having a supported filesystem (FAT12/16/32)
and /EFI/BOOT/BOOT{ARCH}.EFI file and never cared about setting the
partition type at all. It took me a while for figuring out why I
couldn't get my UEFI variables loaded from my FAT partition that
contained /ubootefi.var and /EFI/BOOT/BOOTAA64.efi files.
I am not trying to support ESPs that lack the appropriate partition type
everywhere in U-Boot, but at least for the UEFI variables (ubootefi.var)
feature seemed a nice thing to have.
Perhaps we could make it a separate config option like "Allow searching
for ESPs without partition type" and default it to N, don't know...
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH] efi_loader: improve detection of ESP for storing UEFI variables
2020-11-09 13:24 ` Paulo Alcantara
@ 2020-11-09 13:51 ` Mark Kettenis
2020-11-09 14:35 ` Paulo Alcantara
2020-11-09 14:36 ` Heinrich Schuchardt
2020-11-09 13:58 ` Heinrich Schuchardt
1 sibling, 2 replies; 11+ messages in thread
From: Mark Kettenis @ 2020-11-09 13:51 UTC (permalink / raw)
To: u-boot
> From: Paulo Alcantara <pc@cjr.nz>
> Date: Mon, 09 Nov 2020 10:24:08 -0300
>
> Heinrich Schuchardt <xypron.glpk@gmx.de> writes:
>
> > On 09.11.20 00:58, Paulo Alcantara wrote:
> >> The UEFI specification does not restrict on the number and location of
> >> ESPs in a system. They are discovered as required by looking at the
> >> partition type, but firmware implementations are allowed to support
> >> ESPs which do not contain a valid partition type.
> >
> > I guess you refer to chapter "13.3.3 Number and Location of System
> > Partitions" of the UEFI spec saying: "Further, UEFI implementations
> > may allow the use of conforming FAT partitions which do not use the
> > ESP GUID."
>
> Yep, sorry. Thanks for pointing it out!
>
> > Why should U-Boot support FAT partitions that are not of type FAT 0xef
> > and GPT partition that do not use the ESP GUID?
>
> In most UEFI (EDK2-based) systems I used, I could boot my OSes and
> diagnostic tools by simply having a supported filesystem (FAT12/16/32)
> and /EFI/BOOT/BOOT{ARCH}.EFI file and never cared about setting the
> partition type at all. It took me a while for figuring out why I
> couldn't get my UEFI variables loaded from my FAT partition that
> contained /ubootefi.var and /EFI/BOOT/BOOTAA64.efi files.
The OpenBSD installation media for armv7 and arm64 use a FAT partition
of type 0x0c because the Raspberry Pi firmware doesn't support 0xef.
This allows us to have a single FAT partition with the Raspberry Pi
firmware, U-Boot and /EFI/BOOT/BOOT{ARCH}.EFI.
So far this works on all UEFI firmware I've tried (EDK2, U-Boot and
AMI AptioV UEFI).
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH] efi_loader: improve detection of ESP for storing UEFI variables
2020-11-09 13:24 ` Paulo Alcantara
2020-11-09 13:51 ` Mark Kettenis
@ 2020-11-09 13:58 ` Heinrich Schuchardt
1 sibling, 0 replies; 11+ messages in thread
From: Heinrich Schuchardt @ 2020-11-09 13:58 UTC (permalink / raw)
To: u-boot
On 09.11.20 14:24, Paulo Alcantara wrote:
> Heinrich Schuchardt <xypron.glpk@gmx.de> writes:
>
>> On 09.11.20 00:58, Paulo Alcantara wrote:
>>> The UEFI specification does not restrict on the number and location of
>>> ESPs in a system. They are discovered as required by looking at the
>>> partition type, but firmware implementations are allowed to support
>>> ESPs which do not contain a valid partition type.
>>
>> I guess you refer to chapter "13.3.3 Number and Location of System
>> Partitions" of the UEFI spec saying: "Further, UEFI implementations
>> may allow the use of conforming FAT partitions which do not use the
>> ESP GUID."
>
> Yep, sorry. Thanks for pointing it out!
>
>> Why should U-Boot support FAT partitions that are not of type FAT 0xef
>> and GPT partition that do not use the ESP GUID?
>
> In most UEFI (EDK2-based) systems I used, I could boot my OSes and
> diagnostic tools by simply having a supported filesystem (FAT12/16/32)
> and /EFI/BOOT/BOOT{ARCH}.EFI file and never cared about setting the
> partition type at all. It took me a while for figuring out why I
> couldn't get my UEFI variables loaded from my FAT partition that
> contained /ubootefi.var and /EFI/BOOT/BOOTAA64.efi files.
>
> I am not trying to support ESPs that lack the appropriate partition type
> everywhere in U-Boot, but at least for the UEFI variables (ubootefi.var)
> feature seemed a nice thing to have.
>
> Perhaps we could make it a separate config option like "Allow searching
> for ESPs without partition type" and default it to N, don't know...
>
In your last mail you wrote you are working for SUSE. Is there a bug in
the SUSE installer that makes it create the wrong partition type?
Best regards
Heinrich
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH] efi_loader: improve detection of ESP for storing UEFI variables
2020-11-09 13:51 ` Mark Kettenis
@ 2020-11-09 14:35 ` Paulo Alcantara
2020-11-09 14:46 ` Heinrich Schuchardt
2020-11-09 14:36 ` Heinrich Schuchardt
1 sibling, 1 reply; 11+ messages in thread
From: Paulo Alcantara @ 2020-11-09 14:35 UTC (permalink / raw)
To: u-boot
Mark Kettenis <mark.kettenis@xs4all.nl> writes:
> The OpenBSD installation media for armv7 and arm64 use a FAT partition
> of type 0x0c because the Raspberry Pi firmware doesn't support 0xef.
> This allows us to have a single FAT partition with the Raspberry Pi
> firmware, U-Boot and /EFI/BOOT/BOOT{ARCH}.EFI.
Yeah, it is the same partition type that my openSUSE Tumbleweed image
has and everything boots fine on rpi4.
My only problem with not having the partition type of 0xef in MBR is
that my UEFI variables (/ubootefi.var) could not be loaded because
U-Boot did not detect an ESP to either read or store them, but the UEFI
boot worked regardless.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH] efi_loader: improve detection of ESP for storing UEFI variables
2020-11-09 13:51 ` Mark Kettenis
2020-11-09 14:35 ` Paulo Alcantara
@ 2020-11-09 14:36 ` Heinrich Schuchardt
2020-11-09 17:08 ` Mark Kettenis
1 sibling, 1 reply; 11+ messages in thread
From: Heinrich Schuchardt @ 2020-11-09 14:36 UTC (permalink / raw)
To: u-boot
On 09.11.20 14:51, Mark Kettenis wrote:
>> From: Paulo Alcantara <pc@cjr.nz>
>> Date: Mon, 09 Nov 2020 10:24:08 -0300
>>
>> Heinrich Schuchardt <xypron.glpk@gmx.de> writes:
>>
>>> On 09.11.20 00:58, Paulo Alcantara wrote:
>>>> The UEFI specification does not restrict on the number and location of
>>>> ESPs in a system. They are discovered as required by looking at the
>>>> partition type, but firmware implementations are allowed to support
>>>> ESPs which do not contain a valid partition type.
>>>
>>> I guess you refer to chapter "13.3.3 Number and Location of System
>>> Partitions" of the UEFI spec saying: "Further, UEFI implementations
>>> may allow the use of conforming FAT partitions which do not use the
>>> ESP GUID."
>>
>> Yep, sorry. Thanks for pointing it out!
>>
>>> Why should U-Boot support FAT partitions that are not of type FAT 0xef
>>> and GPT partition that do not use the ESP GUID?
>>
>> In most UEFI (EDK2-based) systems I used, I could boot my OSes and
>> diagnostic tools by simply having a supported filesystem (FAT12/16/32)
>> and /EFI/BOOT/BOOT{ARCH}.EFI file and never cared about setting the
>> partition type at all. It took me a while for figuring out why I
>> couldn't get my UEFI variables loaded from my FAT partition that
>> contained /ubootefi.var and /EFI/BOOT/BOOTAA64.efi files.
>
> The OpenBSD installation media for armv7 and arm64 use a FAT partition
> of type 0x0c because the Raspberry Pi firmware doesn't support 0xef.
> This allows us to have a single FAT partition with the Raspberry Pi
> firmware, U-Boot and /EFI/BOOT/BOOT{ARCH}.EFI.
>
> So far this works on all UEFI firmware I've tried (EDK2, U-Boot and
> AMI AptioV UEFI).
>
The issue Paulo was addressing is that U-Boot only persists non-volatile
UEFI variables if it can find a partition indicated as ESP by the
partition type.
This becomes interesting if you want to have both Linux and OpenBSD on
the same device and you want to use UEFI boot variables to decide which
operating system to boot or if you want to use secure boot.
On Debian the ESP is an 0xef partition mounted at /boot/efi.
SUSE recommends the same:
https://www.suse.com/support/kb/doc/?id=000017007
https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-uefi.html
For a Raspberry I typically would have the following partitions:
/ - root file system
/boot/firmware - *first* FAT partition
/boot/efi - ESP, FAT formatted
As /boot/firmware and /boot/efi can be separate partitions with
different partition type why does OpenBSD not use this scheme?
Best regards
Heinrich
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH] efi_loader: improve detection of ESP for storing UEFI variables
2020-11-09 14:35 ` Paulo Alcantara
@ 2020-11-09 14:46 ` Heinrich Schuchardt
0 siblings, 0 replies; 11+ messages in thread
From: Heinrich Schuchardt @ 2020-11-09 14:46 UTC (permalink / raw)
To: u-boot
On 09.11.20 15:35, Paulo Alcantara wrote:
> Mark Kettenis <mark.kettenis@xs4all.nl> writes:
>
>> The OpenBSD installation media for armv7 and arm64 use a FAT partition
>> of type 0x0c because the Raspberry Pi firmware doesn't support 0xef.
>> This allows us to have a single FAT partition with the Raspberry Pi
>> firmware, U-Boot and /EFI/BOOT/BOOT{ARCH}.EFI.
>
> Yeah, it is the same partition type that my openSUSE Tumbleweed image
> has and everything boots fine on rpi4.
>
> My only problem with not having the partition type of 0xef in MBR is
> that my UEFI variables (/ubootefi.var) could not be loaded because
> U-Boot did not detect an ESP to either read or store them, but the UEFI
> boot worked regardless.
>
Hello Matthias,
While SUSE generally recommends to have an ESP partition with partition
type 0xef this is not so on the Raspberry images, e.g.
http://download.opensuse.org/ports/aarch64/tumbleweed/appliances/openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64.raw.xz
Device Boot Start
End Sectors Size Id Type
openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64.raw1 2048
133119 131072 64M c W95 FAT32 (LBA)
openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64.raw2 133120
1157119 1024000 500M 82 Linux swap / Solaris
openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64.raw3 1157120
4610014 3452895 1.6G 83 Linux
Why is SUSE not using a separate ESP partition mounted as /boot/efi here?
The mail thread starts here:
https://lists.denx.de/pipermail/u-boot/2020-November/432223.html
Best regards
Heinrich
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH] efi_loader: improve detection of ESP for storing UEFI variables
2020-11-09 14:36 ` Heinrich Schuchardt
@ 2020-11-09 17:08 ` Mark Kettenis
2020-11-14 4:56 ` Heinrich Schuchardt
0 siblings, 1 reply; 11+ messages in thread
From: Mark Kettenis @ 2020-11-09 17:08 UTC (permalink / raw)
To: u-boot
> From: Heinrich Schuchardt <xypron.glpk@gmx.de>
> Date: Mon, 9 Nov 2020 15:36:33 +0100
>
> On 09.11.20 14:51, Mark Kettenis wrote:
> >> From: Paulo Alcantara <pc@cjr.nz>
> >> Date: Mon, 09 Nov 2020 10:24:08 -0300
> >>
> >> Heinrich Schuchardt <xypron.glpk@gmx.de> writes:
> >>
> >>> On 09.11.20 00:58, Paulo Alcantara wrote:
> >>>> The UEFI specification does not restrict on the number and location of
> >>>> ESPs in a system. They are discovered as required by looking at the
> >>>> partition type, but firmware implementations are allowed to support
> >>>> ESPs which do not contain a valid partition type.
> >>>
> >>> I guess you refer to chapter "13.3.3 Number and Location of System
> >>> Partitions" of the UEFI spec saying: "Further, UEFI implementations
> >>> may allow the use of conforming FAT partitions which do not use the
> >>> ESP GUID."
> >>
> >> Yep, sorry. Thanks for pointing it out!
> >>
> >>> Why should U-Boot support FAT partitions that are not of type FAT 0xef
> >>> and GPT partition that do not use the ESP GUID?
> >>
> >> In most UEFI (EDK2-based) systems I used, I could boot my OSes and
> >> diagnostic tools by simply having a supported filesystem (FAT12/16/32)
> >> and /EFI/BOOT/BOOT{ARCH}.EFI file and never cared about setting the
> >> partition type at all. It took me a while for figuring out why I
> >> couldn't get my UEFI variables loaded from my FAT partition that
> >> contained /ubootefi.var and /EFI/BOOT/BOOTAA64.efi files.
> >
> > The OpenBSD installation media for armv7 and arm64 use a FAT partition
> > of type 0x0c because the Raspberry Pi firmware doesn't support 0xef.
> > This allows us to have a single FAT partition with the Raspberry Pi
> > firmware, U-Boot and /EFI/BOOT/BOOT{ARCH}.EFI.
> >
> > So far this works on all UEFI firmware I've tried (EDK2, U-Boot and
> > AMI AptioV UEFI).
> >
>
> The issue Paulo was addressing is that U-Boot only persists non-volatile
> UEFI variables if it can find a partition indicated as ESP by the
> partition type.
>
> This becomes interesting if you want to have both Linux and OpenBSD on
> the same device and you want to use UEFI boot variables to decide which
> operating system to boot or if you want to use secure boot.
>
> On Debian the ESP is an 0xef partition mounted at /boot/efi.
>
> SUSE recommends the same:
> https://www.suse.com/support/kb/doc/?id=000017007
> https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-uefi.html
>
> For a Raspberry I typically would have the following partitions:
>
> / - root file system
> /boot/firmware - *first* FAT partition
> /boot/efi - ESP, FAT formatted
>
> As /boot/firmware and /boot/efi can be separate partitions with
> different partition type why does OpenBSD not use this scheme?
Two reasons:
1. The installer and the scripts that build the installer image only
support creating a single FAT partition.
2. Adding another FAT partition would consume another slot in the
disklabel[1] which doesn't have a lot of empty slots left for a
default install.
Cheers,
Mark
[1] A disklabel is the platform-independent partition table that is
used by BSD systems and for example Solaris on SPARC.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH] efi_loader: improve detection of ESP for storing UEFI variables
2020-11-09 17:08 ` Mark Kettenis
@ 2020-11-14 4:56 ` Heinrich Schuchardt
2020-11-16 5:02 ` Jonathan Gray
0 siblings, 1 reply; 11+ messages in thread
From: Heinrich Schuchardt @ 2020-11-14 4:56 UTC (permalink / raw)
To: u-boot
On 09.11.20 18:08, Mark Kettenis wrote:
>> From: Heinrich Schuchardt <xypron.glpk@gmx.de>
>> Date: Mon, 9 Nov 2020 15:36:33 +0100
>>
>> On 09.11.20 14:51, Mark Kettenis wrote:
>>>> From: Paulo Alcantara <pc@cjr.nz>
>>>> Date: Mon, 09 Nov 2020 10:24:08 -0300
>>>>
>>>> Heinrich Schuchardt <xypron.glpk@gmx.de> writes:
>>>>
>>>>> On 09.11.20 00:58, Paulo Alcantara wrote:
>>>>>> The UEFI specification does not restrict on the number and location of
>>>>>> ESPs in a system. They are discovered as required by looking at the
>>>>>> partition type, but firmware implementations are allowed to support
>>>>>> ESPs which do not contain a valid partition type.
>>>>>
>>>>> I guess you refer to chapter "13.3.3 Number and Location of System
>>>>> Partitions" of the UEFI spec saying: "Further, UEFI implementations
>>>>> may allow the use of conforming FAT partitions which do not use the
>>>>> ESP GUID."
>>>>
>>>> Yep, sorry. Thanks for pointing it out!
>>>>
>>>>> Why should U-Boot support FAT partitions that are not of type FAT 0xef
>>>>> and GPT partition that do not use the ESP GUID?
>>>>
>>>> In most UEFI (EDK2-based) systems I used, I could boot my OSes and
>>>> diagnostic tools by simply having a supported filesystem (FAT12/16/32)
>>>> and /EFI/BOOT/BOOT{ARCH}.EFI file and never cared about setting the
>>>> partition type at all. It took me a while for figuring out why I
>>>> couldn't get my UEFI variables loaded from my FAT partition that
>>>> contained /ubootefi.var and /EFI/BOOT/BOOTAA64.efi files.
>>>
>>> The OpenBSD installation media for armv7 and arm64 use a FAT partition
>>> of type 0x0c because the Raspberry Pi firmware doesn't support 0xef.
>>> This allows us to have a single FAT partition with the Raspberry Pi
>>> firmware, U-Boot and /EFI/BOOT/BOOT{ARCH}.EFI.
>>>
>>> So far this works on all UEFI firmware I've tried (EDK2, U-Boot and
>>> AMI AptioV UEFI).
>>>
>>
>> The issue Paulo was addressing is that U-Boot only persists non-volatile
>> UEFI variables if it can find a partition indicated as ESP by the
>> partition type.
>>
>> This becomes interesting if you want to have both Linux and OpenBSD on
>> the same device and you want to use UEFI boot variables to decide which
>> operating system to boot or if you want to use secure boot.
>>
>> On Debian the ESP is an 0xef partition mounted at /boot/efi.
>>
>> SUSE recommends the same:
>> https://www.suse.com/support/kb/doc/?id=000017007
>> https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-uefi.html
>>
>> For a Raspberry I typically would have the following partitions:
>>
>> / - root file system
>> /boot/firmware - *first* FAT partition
>> /boot/efi - ESP, FAT formatted
>>
>> As /boot/firmware and /boot/efi can be separate partitions with
>> different partition type why does OpenBSD not use this scheme?
>
> Two reasons:
>
> 1. The installer and the scripts that build the installer image only
> support creating a single FAT partition.
>
> 2. Adding another FAT partition would consume another slot in the
> disklabel[1] which doesn't have a lot of empty slots left for a
> default install.
OpenBSD itself uses just a single partition of type 0xa6 on the SD-Card.
U-Boot supports logical partitions. So you can have three primary
partitions and additionally 60 logical partitions in your extended
partition. So the number of available slots should be the least of your
worries.
Best regards
Heinrich
>
> Cheers,
>
> Mark
>
> [1] A disklabel is the platform-independent partition table that is
> used by BSD systems and for example Solaris on SPARC.
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH] efi_loader: improve detection of ESP for storing UEFI variables
2020-11-14 4:56 ` Heinrich Schuchardt
@ 2020-11-16 5:02 ` Jonathan Gray
0 siblings, 0 replies; 11+ messages in thread
From: Jonathan Gray @ 2020-11-16 5:02 UTC (permalink / raw)
To: u-boot
On Sat, Nov 14, 2020 at 05:56:38AM +0100, Heinrich Schuchardt wrote:
> On 09.11.20 18:08, Mark Kettenis wrote:
> >> From: Heinrich Schuchardt <xypron.glpk@gmx.de>
> >> Date: Mon, 9 Nov 2020 15:36:33 +0100
> >>
> >> On 09.11.20 14:51, Mark Kettenis wrote:
> >>>> From: Paulo Alcantara <pc@cjr.nz>
> >>>> Date: Mon, 09 Nov 2020 10:24:08 -0300
> >>>>
> >>>> Heinrich Schuchardt <xypron.glpk@gmx.de> writes:
> >>>>
> >>>>> On 09.11.20 00:58, Paulo Alcantara wrote:
> >>>>>> The UEFI specification does not restrict on the number and location of
> >>>>>> ESPs in a system. They are discovered as required by looking at the
> >>>>>> partition type, but firmware implementations are allowed to support
> >>>>>> ESPs which do not contain a valid partition type.
> >>>>>
> >>>>> I guess you refer to chapter "13.3.3 Number and Location of System
> >>>>> Partitions" of the UEFI spec saying: "Further, UEFI implementations
> >>>>> may allow the use of conforming FAT partitions which do not use the
> >>>>> ESP GUID."
> >>>>
> >>>> Yep, sorry. Thanks for pointing it out!
> >>>>
> >>>>> Why should U-Boot support FAT partitions that are not of type FAT 0xef
> >>>>> and GPT partition that do not use the ESP GUID?
> >>>>
> >>>> In most UEFI (EDK2-based) systems I used, I could boot my OSes and
> >>>> diagnostic tools by simply having a supported filesystem (FAT12/16/32)
> >>>> and /EFI/BOOT/BOOT{ARCH}.EFI file and never cared about setting the
> >>>> partition type at all. It took me a while for figuring out why I
> >>>> couldn't get my UEFI variables loaded from my FAT partition that
> >>>> contained /ubootefi.var and /EFI/BOOT/BOOTAA64.efi files.
> >>>
> >>> The OpenBSD installation media for armv7 and arm64 use a FAT partition
> >>> of type 0x0c because the Raspberry Pi firmware doesn't support 0xef.
> >>> This allows us to have a single FAT partition with the Raspberry Pi
> >>> firmware, U-Boot and /EFI/BOOT/BOOT{ARCH}.EFI.
> >>>
> >>> So far this works on all UEFI firmware I've tried (EDK2, U-Boot and
> >>> AMI AptioV UEFI).
> >>>
> >>
> >> The issue Paulo was addressing is that U-Boot only persists non-volatile
> >> UEFI variables if it can find a partition indicated as ESP by the
> >> partition type.
> >>
> >> This becomes interesting if you want to have both Linux and OpenBSD on
> >> the same device and you want to use UEFI boot variables to decide which
> >> operating system to boot or if you want to use secure boot.
> >>
> >> On Debian the ESP is an 0xef partition mounted at /boot/efi.
> >>
> >> SUSE recommends the same:
> >> https://www.suse.com/support/kb/doc/?id=000017007
> >> https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-uefi.html
> >>
> >> For a Raspberry I typically would have the following partitions:
> >>
> >> / - root file system
> >> /boot/firmware - *first* FAT partition
> >> /boot/efi - ESP, FAT formatted
> >>
> >> As /boot/firmware and /boot/efi can be separate partitions with
> >> different partition type why does OpenBSD not use this scheme?
> >
> > Two reasons:
> >
> > 1. The installer and the scripts that build the installer image only
> > support creating a single FAT partition.
> >
> > 2. Adding another FAT partition would consume another slot in the
> > disklabel[1] which doesn't have a lot of empty slots left for a
> > default install.
>
> OpenBSD itself uses just a single partition of type 0xa6 on the SD-Card.
>
> U-Boot supports logical partitions. So you can have three primary
> partitions and additionally 60 logical partitions in your extended
> partition. So the number of available slots should be the least of your
> worries.
mbr, gpt, apple partion map, sgi disklabel etc are all mapped onto
an OpenBSD disklabel, one is spoofed if it doesn't exist.
https://man.openbsd.org/disklabel.5
"disklabel only supports up to a maximum of 15 partitions, ?a? through
?p?, excluding ?c?. The ?c? partition is reserved for the entire
physical disk. By convention, the ?a? partition of the boot disk is the
root partition, and the ?b? partition of the boot disk is the swap
partition, but all other letters can be used in any order for any other
partitions as desired."
What looks like a single mbr partition is normally used as multiple
disklabel partitions. For swap /tmp /var etc. Partitions outside the
OpenBSD area like FAT start showing up at 'i'.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2020-11-16 5:02 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-08 23:58 [PATCH] efi_loader: improve detection of ESP for storing UEFI variables Paulo Alcantara
2020-11-09 10:02 ` Heinrich Schuchardt
2020-11-09 13:24 ` Paulo Alcantara
2020-11-09 13:51 ` Mark Kettenis
2020-11-09 14:35 ` Paulo Alcantara
2020-11-09 14:46 ` Heinrich Schuchardt
2020-11-09 14:36 ` Heinrich Schuchardt
2020-11-09 17:08 ` Mark Kettenis
2020-11-14 4:56 ` Heinrich Schuchardt
2020-11-16 5:02 ` Jonathan Gray
2020-11-09 13:58 ` Heinrich Schuchardt
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.