Hi Mark, On Sun, 3 Nov 2024 at 09:15, Mark Kettenis <mark.kette...@xs4all.nl> wrote: > > > From: Simon Glass <s...@chromium.org> > > Date: Sun, 3 Nov 2024 07:46:44 -0700 > > Hi Simon, > > > Hi Andre, > > > > On Sun, 3 Nov 2024 at 03:36, Andre Przywara <andre.przyw...@arm.com> wrote: > > > > > > On Sat, 2 Nov 2024 11:35:31 -0600 > > > Simon Glass <s...@chromium.org> wrote: > > > > > > Hi Simon, > > > > > > > On Thu, 17 Oct 2024 at 17:25, Simon Glass <s...@chromium.org> wrote: > > > > > > > > > > Drop support for distroboot and move to using bootstd instead. > > > > > > > > > > Signed-off-by: Simon Glass <s...@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? > > > > > > 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? > > > > Given that we are past rc1 the easiest thing might be to revert this: > > > > f2bfa0cb179 bootstd: Make efi_mgr bootmeth work for non-sandbox setups > > > > until we can figure this out. > > > > Can you try that? > > That will break setups that use the EFI bootmanager on platforms > already converted to bootstd (such as various Rockchip boards and the > Apple machines). I don't think that is acceptable as we've been > shipping releases with working EFI bootmanager support on those > platforms for several years already.
This patch only went in in 2024.01 so I'm not sure how you have been shipping releases for several years. Are you sure those devices won't boot without bootmgr? This issue will presumably block all bootstd migration if we don't find a solution, meaning that over 1000 boards will be stuck with the scripts, etc. Regards, SImon
