From: Tom Rini <trini@konsulko.com>
To: Simon Glass <sjg@chromium.org>
Cc: u-boot@lists.denx.de, Heinrich Schuchardt <xypron.glpk@gmx.de>,
Andrew Goodbody <andrew.goodbody@linaro.org>,
Guillaume La Roque <glaroque@baylibre.com>,
Jerome Forissier <jerome.forissier@linaro.org>,
Martin Schwan <m.schwan@phytec.de>,
Martyn Welch <martyn.welch@collabora.com>,
Mattijs Korpershoek <mkorpershoek@kernel.org>,
Maximilian Brune <maximilian.brune@9elements.com>,
Moritz Fischer <moritzf@google.com>,
Sam Protsenko <semen.protsenko@linaro.org>
Subject: Re: [PATCH v4 00/11] boot: Support priority for global bootmeths
Date: Wed, 15 Oct 2025 13:09:18 -0600 [thread overview]
Message-ID: <20251015190918.GT6113@bill-the-cat> (raw)
In-Reply-To: <20251015154423.908468-1-sjg@chromium.org>
[-- Attachment #1: Type: text/plain, Size: 1970 bytes --]
On Wed, Oct 15, 2025 at 04:44:03PM +0100, Simon Glass wrote:
> At present global bootmeths always run first, before all other
> bootmeths. Optimisations in the code take advantage of this, putting
> them at the end, so they can be used once and then forgotten.
>
> In some cases it is useful to run global bootmeths later in the boot.
> For example, the EFI-bootmgr bootmeth may itself scan devices and the
> network, so running it first can hold up the boot significantly for
> boards not actually relying on EFI-bootmgr to boot.
>
> This series introduces a new field in global bootmeths which indicates
> the priority, using the same scheme as is used with bootdev hunters.
> Thus it is possible to insert the EFI-bootmgr bootmeth just before the
> hunter for network bootdevs is invoked.
>
> Despite the simplicity of the concept and the relatively small series,
> this is a fairly significant enhancement. It is also quite tricky to
> implement, largely due to the way the original code was written, with
> global bootmeths being a small, size-optimised add-on to the original
> bootstd implementation.
>
> For now we only allow each global bootmeth to run at most once, but this
> implementation is written in a way that we could relax that if needed.
> Then the bootmeth itself could decide whether to run at any particular
> point in the bootflow iteration.
>
> Size growth is about 390 bytes on Thumb2 (e.g. firefly-rk3288) if
> CONFIG_BOOTMETH_GLOBAL is enabled, which it normally is. With that
> disabled (which saves about 4K on the same platform), there is no
> growth.
>
> Changes in v4:
> - Reword the commit message as Tom suggested
> - Drop call to bootflow_show()
> - Rebase on top of -master
Aside from my comment on the first patch, the big thing is if this
addresses the problems Andre reported or not. This is likely the right
step forward regardless, but might not be everything needed.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2025-10-15 19:09 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-15 15:44 [PATCH v4 00/11] boot: Support priority for global bootmeths Simon Glass
2025-10-15 15:44 ` [PATCH v4 01/11] boot: Try all bootmeths on the final partition Simon Glass
2025-10-15 19:04 ` Tom Rini
2025-10-16 12:55 ` Heinrich Schuchardt
2025-10-16 15:33 ` Tom Rini
2025-10-15 15:44 ` [PATCH v4 02/11] boot: Add a new test for global bootmeths Simon Glass
2025-10-15 15:44 ` [PATCH v4 03/11] boot: Update first_glob_method when dropping a bootmeth Simon Glass
2025-10-15 15:44 ` [PATCH v4 04/11] boot: Add a flag for whether there are global bootmeths Simon Glass
2025-10-15 15:44 ` [PATCH v4 05/11] boot: Keep track of which bootmeths have been used Simon Glass
2025-10-15 15:44 ` [PATCH v4 06/11] boot: Support rescanning the global bootmeths Simon Glass
2025-10-15 15:44 ` [PATCH v4 07/11] boot: Only run global bootmeths once each Simon Glass
2025-10-15 15:44 ` [PATCH v4 08/11] boot: Implement a priority for global bootmeths Simon Glass
2025-10-15 15:44 ` [PATCH v4 09/11] boot: Don't change the method count after " Simon Glass
2025-10-15 15:44 ` [PATCH v4 10/11] boot: Run global bootmeths after all bootdevs are exhausted Simon Glass
2025-10-15 15:44 ` [PATCH v4 11/11] boot: Run the EFI bootmgr just before network devices Simon Glass
2025-10-15 19:09 ` Tom Rini [this message]
2025-10-22 22:16 ` [PATCH v4 00/11] boot: Support priority for global bootmeths Tom Rini
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=20251015190918.GT6113@bill-the-cat \
--to=trini@konsulko.com \
--cc=andrew.goodbody@linaro.org \
--cc=glaroque@baylibre.com \
--cc=jerome.forissier@linaro.org \
--cc=m.schwan@phytec.de \
--cc=martyn.welch@collabora.com \
--cc=maximilian.brune@9elements.com \
--cc=mkorpershoek@kernel.org \
--cc=moritzf@google.com \
--cc=semen.protsenko@linaro.org \
--cc=sjg@chromium.org \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.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