[PATCH] efi_loader: improve detection of ESP for storing UEFI variables

Heinrich Schuchardt xypron.glpk at gmx.de
Mon Nov 9 15:46:14 CET 2020


On 09.11.20 15:35, Paulo Alcantara wrote:
> Mark Kettenis <mark.kettenis at 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


More information about the U-Boot mailing list