From mboxrd@z Thu Jan  1 00:00:00 1970
From: Paulo Alcantara <pc@cjr.nz>
Date: Mon, 09 Nov 2020 11:35:26 -0300
Subject: [PATCH] efi_loader: improve detection of ESP for storing UEFI
 variables
In-Reply-To: <e94a6aaad5229ee9@bloch.sibelius.xs4all.nl>
References: <20201108235855.28788-1-pc@cjr.nz>
 <abe2c884-76b9-be6e-20b5-73e2030dcd8c@gmx.de> <87lffad5on.fsf@cjr.nz>
 <e94a6aaad5229ee9@bloch.sibelius.xs4all.nl>
Message-ID: <87imaed2dt.fsf@cjr.nz>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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.