From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heinrich Schuchardt Date: Mon, 9 Nov 2020 15:46:14 +0100 Subject: [PATCH] efi_loader: improve detection of ESP for storing UEFI variables In-Reply-To: <87imaed2dt.fsf@cjr.nz> References: <20201108235855.28788-1-pc@cjr.nz> <87lffad5on.fsf@cjr.nz> <87imaed2dt.fsf@cjr.nz> Message-ID: <504f143a-74a5-255a-1d9a-eec819ed0fad@gmx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 09.11.20 15:35, Paulo Alcantara wrote: > Mark Kettenis 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