[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