U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Heinrich Schuchardt <xypron.glpk@gmx.de>
To: Andre Przywara <andre.przywara@arm.com>,
	Simon Glass <sjg@chromium.org>, Tom Rini <trini@konsulko.com>
Cc: U-Boot Mailing List <u-boot@lists.denx.de>,
	Jagan Teki <jagan@amarulasolutions.com>,
	Quentin Schulz <quentin.schulz@cherry.de>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	Marek Vasut <marek.vasut+renesas@mailbox.org>,
	Mattijs Korpershoek <mkorpershoek@baylibre.com>
Subject: Re: [PATCH v5 3/8] efi_loader: bootstd: Drop bootmgr for sunxi
Date: Sat, 23 Nov 2024 05:06:49 +0100	[thread overview]
Message-ID: <3F1F4DAC-39AC-4D17-8C92-A467FE90DA38@gmx.de> (raw)
In-Reply-To: <20241123020802.26cba055@minigeek.lan>

Am 23. November 2024 03:08:02 MEZ schrieb Andre Przywara <andre.przywara@arm.com>:
>On Fri, 15 Nov 2024 07:21:53 -0700
>Simon Glass <sjg@chromium.org> wrote:
>
>Hi Simon, Tom, Heinrich,
>
>sorry for the delay, I was away.
>
>> On Wed, 13 Nov 2024 at 10:50, Tom Rini <trini@konsulko.com> wrote:
>> >
>> > On Wed, Nov 13, 2024 at 08:09:33AM -0700, Simon Glass wrote:
>> >  
>> > > This causes problems with the boot order, so drop it until we can figure
>> > > out a better way to know when bootmgr should be used.
>> > >
>> > > Link: https://lore.kernel.org/u-boot/20241112171205.4e80548d@donnerap.manchester.arm.com/
>> > >
>> > > Signed-off-by: Simon Glass <sjg@chromium.org>  
>> >
>> > I would really prefer a short summary of the contents of the link in the
>> > commit message. I'm not NAK'ing the patch as-is, but it would be helpful
>> > when revisiting this if there was a short explanation of the problem to
>> > solve here and not just "problems with the boot order". Thanks.  
>> 
>> The summary is that sunxi supports FEL (USB boot) but bootmgr is not
>> aware of it, so boots the OS instead.
>
>So that's not the problem: FEL is working fine, since it's marked as
>global, same as efi_bootmgr, but with a lower order number. The problem
>is that the higher priority non-global methods (scripts) are "ignored".
>
>So this is the list without this patch:
>Order  Seq  Name                Description
>-----  ---  ------------------  ------------------
>    0    0  extlinux            extlinux
> glob    1  fel                 FEL
>    2    2  script              script
> glob    3  efi_mgr             EFI bootmgr flow
>    4    4  efi                 EFI
>    5    5  pxe                 PXE
> glob    6  vbe_simple          vbe-simple
>-----  ---  ------------------  ------------------
>
>The sequence looks roughly alright, only that it's not the actual
>order, since "glob" takes precedence. So the actual order is:
>fel -> efi_mgr -> vbe_simple -> extlinux -> script -> efi -> pxe
>And that puts efi_mgr before extlinux and script, which is not what we
>want, because efi_mgr finds bootaa64.efi *somewhere* (eMMC or SD card or
>USB stick) and uses that, even when there is a tailored boot.scr or
>extlinux.conf on the *boot media* which should be higher priority.
>"fel" being first is fine, since it's *only* triggered if someone
>deliberately uploaded a boot script via USB: in this case they surely
>want to execute exactly that.
>
>So I think the underlying problem is the "glob" tag for efi_mgr PLUS
>the fact that it scans all media for bootaa64.efi files. I think it
>would be fine if efi_mgr would just consider EFI boot order variables,
>and would ignore any "removable media" default files (bootaa64.efi).
>The "efi" bootmeth does the scanning as well, and it's fine there,
>since it's lower priority, so we can still boot EFI systems.
>
>I guess it would make sense if an installer on an USB stick should boot
>even if there is something on the eMMC, for instance. But we want to
>control that, and we can't, because the order is ignored due to the
>"glob" flag.
>
>So while I agree that disabling efi_bootmgr sounds like a hack, it
>solves the problem quite elegantly: We keep the (current) boot order,
>which prioritises scripts over EFI, but still retain EFI. If people
>want EFI first, they can change the order in the environment (I think?).
>
>Without that patch there is quite a regression for users, because
>suddenly any bootaa64.efi files *somewhere* would be booted first, and
>there is no way to turn that off.
>
>This has bitten me actually: for development I put a custom boot.scr on
>an SD card which loads a kernel+DTB via TFTP from my box. And I want
>that to be first, despite there being a proper EFI setup on the eMMC or
>USB drive.
>
>So I hope that clears that up. I am not a big fan of that patch, but I
>would like sunxi to be converted, and Simon seemed to be eager to do
>this as well, so in the interest of not blocking this, I am fine with
>that.

Disabling EFI will break booting for users that rely on it (like me).

>
>Cheers,
>Andre

Yes, the introduction of boot standard changed the boot order and specifically deprioritizing scripts is unexpected.

The priority sequence used to be

scripts
extlinux
efi
pxe

bootmeth_efimgr always running before scripts be fixed. bootmeth_efi should be removed from the code base as redundant.

Best regards

Heinrich



  reply	other threads:[~2024-11-23  4:07 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-13 15:09 [PATCH v5 0/8] bootstd: sunxi: Migrate to standard boot Simon Glass
2024-11-13 15:09 ` [PATCH v5 1/8] bootstd: Avoid depending on BLK Simon Glass
2024-11-13 17:47   ` Tom Rini
2024-11-14  3:53     ` Simon Glass
2024-11-14 14:22       ` Tom Rini
2024-11-15 14:27         ` Simon Glass
2024-11-15 14:37           ` Tom Rini
2024-11-13 15:09 ` [PATCH v5 2/8] sunxi: Add a bootmeth for FEL Simon Glass
2024-11-13 15:09 ` [PATCH v5 3/8] efi_loader: bootstd: Drop bootmgr for sunxi Simon Glass
2024-11-13 17:50   ` Tom Rini
2024-11-15 14:21     ` Simon Glass
2024-11-23  2:08       ` Andre Przywara
2024-11-23  4:06         ` Heinrich Schuchardt [this message]
2024-11-23 13:07           ` Andre Przywara
2024-11-23 16:56             ` Ilias Apalodimas
2024-11-16  7:37   ` Heinrich Schuchardt
2024-11-13 15:09 ` [PATCH v5 4/8] RFC: Revert "bootstd: Make efi_mgr bootmeth work for non-sandbox setups" Simon Glass
2024-11-13 17:52   ` Tom Rini
2025-01-05  2:50   ` Heinrich Schuchardt
2025-01-09 15:01     ` Simon Glass
2025-01-09 15:04       ` Tom Rini
2025-01-09 15:11         ` Simon Glass
2025-01-09 15:22           ` Tom Rini
2025-01-10 13:41             ` Simon Glass
2025-01-10 17:05               ` Tom Rini
2025-01-15 13:22                 ` Simon Glass
2025-01-15 14:33                   ` Tom Rini
2024-11-13 15:09 ` [PATCH v5 5/8] sunxi: Move to bootstd Simon Glass
2024-11-13 15:09 ` [PATCH v5 6/8] sunxi: Drop old distro boot variables Simon Glass
2024-11-13 15:09 ` [PATCH v5 7/8] env: Provide a work-around for unquoting fdtfile Simon Glass
2024-11-13 17:53   ` Tom Rini
2025-03-10 22:26   ` Tom Rini
2024-11-13 15:09 ` [PATCH v5 8/8] sunxi: Move to text environment Simon Glass

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=3F1F4DAC-39AC-4D17-8C92-A467FE90DA38@gmx.de \
    --to=xypron.glpk@gmx.de \
    --cc=andre.przywara@arm.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=jagan@amarulasolutions.com \
    --cc=marek.vasut+renesas@mailbox.org \
    --cc=mkorpershoek@baylibre.com \
    --cc=quentin.schulz@cherry.de \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --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