Pull request efi-next-20250104

[Tom Rini]

On Sat, Jan 04, 2025 at 01:08:00PM +0100, Heinrich Schuchardt wrote:
> On 1/4/25 12:49, Jonas Karlman wrote:
> > Hi Heinrich,
> > 
> > On 2025-01-04 04:19, Heinrich Schuchardt wrote:
> > > Dear Tom,
> > > 
> > > The following changes since commit ec9263b4f15c4cf82eb6a211c67baa6385065b8e:
> > > 
> > >     Fix neighbor discovery ethernet address saving (2025-01-01 14:40:04
> > > -0600)
> > > 
> > > are available in the Git repository at:
> > > 
> > >     https://source.denx.de/u-boot/custodians/u-boot-efi.git
> > > tags/efi-next-20250104
> > > 
> > > for you to fetch changes up to ce190e1b33b8c0e1228f4123759dfa1981c202de:
> > > 
> > >     efi: Correct ECPT table GUID (2025-01-04 02:17:06 +0100)
> > > 
> > > Gitlab CI reported no issues:
> > > https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/24075
> > > 
> > > ----------------------------------------------------------------
> > > Pull request efi-next-20250104
> > > 
> > > Documentation:
> > > 
> > > * doc: develop: Fix typos and wording in binman/binman.rst
> > > * doc: develop: Fix typos and wording in gdb.rst
> > > * doc: sandbox: Fix the "sb" command name
> > > * doc/develop/distro.rst: Better document upstream definition of
> > > extlinux.conf
> > > 
> > > UEFI:
> > > 
> > > With this pull request the UEFI sub-system detects all boot devices even
> > > if they have not been probed before. If this adds to much boot delay
> > > individual bootmeths and bootdevs can be disabled via the customizing.
> > > 
> > > * efi_loader: avoid writing message in Exit() boot service
> > > * efi_loader: run bootdev_hunt() to find ESP
> > 
> > This patch still completely changes how standard boot operates, from
> > lazy probing boot devices from fastest to slowest (probe time) as
> > described in the standard boot documentation [1], to probing all boot
> > devices all at once before checking for a bootmeth/bootflow.
> > 
> > This slows down script and extlinux booing on my Rockchip board by
> > several seconds because now pcie and usb is probed before current fast
> > bootflow from mmc devices is tested.

I think there was some further discussion on IRC after these emails.

> 
> We need to scan all block devices to be EFI compliant.

In "efi bootmanager" mode, yes?

> As described in the pull request message, if you don't want to boot from
> PCIe or USB, you can disable these bootdevs.

But that will still cause them to be probed in the efi boot manager
instance yes?

> If you don't want to boot via EFI set CONFIG_EFI_LOADER=n.

But that's precisely what we're trying to avoid in the general case. We
want EFI_LOADER=y so that all the assorted modern SoCs can Just Work
with all of the assorted off the shelf FOSS OS images.

> > Will you work on a fix for this or do you recommend disabling the
> > efi_mgr bootmeth or similar? E.g. something like the diff below.
> > 
> > Similarly if I understand correctly the priority of efi_mgr bootmeth,
> > first regardless of configured bootmeth order, is the main blocker for
> > sunxi to fully move to standard boot.
> 
> Allowing to run global boot methods after non-global ones still has to
> be worked on.

Yes, this needs to be done first, then we can do things which will slow
down the boot process in the case of an un-optimized configuration.

> Please, elaborate why Sunxi cannot be migrated like other boards. If
> some embedded board needs to be trimmed to maximize boot speed you will
> anyway adjust the configuration to eliminate all unnecessary scanning of
> devices.

The problem with SUNXI was described well enough in the thread about
migration and I believe re-summarized in the past few weeks. But no one
wants their device to boot any slower than required. Which in turn means
getting things setup such that we can boot the specific case before the
global case.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20250104/7f57cf3a/attachment.sig>