On Sun, 03 Nov 2024 18:54:38 +0100 Mark Kettenis mark.kettenis@xs4all.nl wrote:
Hi Mark,
Date: Sun, 3 Nov 2024 10:36:26 +0000 From: Andre Przywara andre.przywara@arm.com
Hi Andre,
On Sat, 2 Nov 2024 11:35:31 -0600 Simon Glass sjg@chromium.org wrote:
Hi Simon,
On Thu, 17 Oct 2024 at 17:25, Simon Glass sjg@chromium.org wrote:
Drop support for distroboot and move to using bootstd instead.
Signed-off-by: Simon Glass sjg@chromium.org
(no changes since v2)
Changes in v2:
- Convert the other DISTRO_DEFAULTS in the Kconfig too
arch/arm/Kconfig | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
Could this series be applied, please?
So I played with that a bit:
- The FEL script boot method works: it has the highest priority, which is what we want, because the script would be deliberately injected by the user to be executed. So thanks for the changes!
- However the other global boot method (efimgr) takes precedence over other, *higher* priority methods (extlinux.conf/boot.scr). This leads to behavioural regressions, I think, like:
- Say there is a bootaa64.efi on some ESP on the eMMC. If you now boot from SD card, with boot.scr or extlinux.conf on there, U-Boot will still find the EFI app first and execute that. I don't think that's what we want?
- Similar, if you have a boot script on the eMMC, and boot from there, but with a USB stick carrying a bootaa64.efi plugged in. Then EFI would win as well. This might be intended, but maybe not, and I don't see how one would influence that?
Is there a way to change the bootflow to look for any boot payload on the *boot* media first? So when I boot from SD, it checks this first for EFI, boot.scr, extlinux.conf, then goes to eMMC and USB. Similarly, when booting from eMMC, check there first before considering SD and USB. Maybe I am missing something obvious here?
The issue here is that the EFI bootmanager by its very nature considers all possible devices for which boot options have been included in the BootOptions EFI variable. So if you have enabled bootmeth_efi_mgr (and you probably should), and you have an active boot option (that is a boot option that is included in the BootOptions EFI variable) that points at eMMC or USB, it will try too boot using
I think that's the point: sunxi is one of the platforms that doesn't feature persistent UEFI variables, at least not when set via UEFI RT services. So we don't typically have any UEFI variables to help us point at the right boot location, which leaves us only with ...
that boot option. So you'd think things would be fine as long as you don't add boot options for eMMC or USB to the BootOrder variable.
Unfortunately the EFI_LOADER code will automatically generate media device boot options for all the block devices that get added and adds those to the BootOrder variables in an attempt to implement the requirement to boot from removable media if everything else fails.
... exactly removable media. So UEFI boot so far was relying on efi/boot/bootaa64.efi, though I think you can construct a more specific entry by manually setting (and storing!) this on the U-Boot shell.
Another complication is that very often microSD cards are either the only or the preferred "hard disk" for those boards, and they are surely removable, even though in those scenarios they are treated more like "fixed" disks.
The Allwinner BootROM is writing a boot source ID into SRAM, so we know whether we were booted from SD card, eMMC, or SPI flash, and set $mmc_bootdev accordingly. I need to check whether and how this is reflected in bootstd.
But I think that's a mistake. I can't find a requirement to add boot options for these in the spec, let alone a requirement to add those to BootOrder. I suppose this fallback could be implemented as a separate bootmeth that can be low priority.
Yeah, I also feel like splitting this up might help. So one bootmeth for removable media, and one BootOrder variable based.
But I think the culprit in this particular situation is this "global" flag, which makes it live outside of the priority scheme, IIUC: "When global bootmeths are available, these are typically checked before the above bootdev scanning."
Not sure if there is a good solution to this problem? Maybe check at least the boot device first, for all bootmeth's, and only then consult global bootmeth's? But then again we want to current behaviour for FEL script booting, I wonder if this could be modelled as some pseudo bootdev instead of marked as global (because we are booting via the BootROM's USB-OTG routines in this case).
Cheers, Andre
So while I am personally happy with EFI being a prominent citizen, I think many sunxi users would still expect more traditional boot methods to at least work - at the moment they might be permanently "shadowed" by some bootaa64.efi sitting *somewhere*. That actually bites me at the moment when working on a new SoC port, where I use an extlinux.conf as an override, to load a custom dev kernel and DTB, but bootstd still finds that grub on that SD card and uses that first :-(
So I feel like EFI should still be the preferred boot method, but the more custom ways should be allowed to override that.
Do you have any ideas how to solve that, or am I holding it wrong?
Cheers, Andre