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.a...
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.
Cheers, Andre