diff options
| author | Tom Rini <trini@konsulko.com> | 2025-10-22 14:17:16 -0600 |
|---|---|---|
| committer | Tom Rini <trini@konsulko.com> | 2025-10-22 16:16:31 -0600 |
| commit | b10c055d4e1b5153a331a61ef82a5b01b5bb4c45 (patch) | |
| tree | 71eed5c423cb81260e92ac32d37e5395d62c9393 /board/microsoft/surface-2/Makefile | |
| parent | 8bc918ed97b4c79eecd56969a2898a8c75886c5a (diff) | |
| parent | 6a56d10fdcf1309d2070b62dc15e80a047da971b (diff) | |
Simon Glass <sjg@chromium.org> says:
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.
Link: https://lore.kernel.org/r/20251015154423.908468-1-sjg@chromium.org
Diffstat (limited to 'board/microsoft/surface-2/Makefile')
0 files changed, 0 insertions, 0 deletions
