From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paulo Alcantara Date: Mon, 09 Nov 2020 10:24:08 -0300 Subject: [PATCH] efi_loader: improve detection of ESP for storing UEFI variables In-Reply-To: References: <20201108235855.28788-1-pc@cjr.nz> Message-ID: <87lffad5on.fsf@cjr.nz> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Heinrich Schuchardt 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...