public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Heinrich Schuchardt <xypron.glpk@gmx.de>
To: u-boot@lists.denx.de
Subject: [PATCH] efi_loader: improve detection of ESP for storing UEFI variables
Date: Mon, 9 Nov 2020 14:58:55 +0100	[thread overview]
Message-ID: <0be294e8-cb29-7dbe-2009-e6ec9c210a03@gmx.de> (raw)
In-Reply-To: <87lffad5on.fsf@cjr.nz>

On 09.11.20 14:24, Paulo Alcantara wrote:
> Heinrich Schuchardt <xypron.glpk@gmx.de> 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...
>

In your last mail you wrote you are working for SUSE. Is there a bug in
the SUSE installer that makes it create the wrong partition type?

Best regards

Heinrich

      parent reply	other threads:[~2020-11-09 13:58 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-08 23:58 [PATCH] efi_loader: improve detection of ESP for storing UEFI variables Paulo Alcantara
2020-11-09 10:02 ` Heinrich Schuchardt
2020-11-09 13:24   ` Paulo Alcantara
2020-11-09 13:51     ` Mark Kettenis
2020-11-09 14:35       ` Paulo Alcantara
2020-11-09 14:46         ` Heinrich Schuchardt
2020-11-09 14:36       ` Heinrich Schuchardt
2020-11-09 17:08         ` Mark Kettenis
2020-11-14  4:56           ` Heinrich Schuchardt
2020-11-16  5:02             ` Jonathan Gray
2020-11-09 13:58     ` Heinrich Schuchardt [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0be294e8-cb29-7dbe-2009-e6ec9c210a03@gmx.de \
    --to=xypron.glpk@gmx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox