On Sun, 3 Nov 2024 at 19:06, Simon Glass <s...@chromium.org> wrote: > > 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.
I think we can be a little less melodramatic, I mean after all that's what they've been using up until now.
