On Sun, 3 Nov 2024 at 19:06, Simon Glass sjg@chromium.org wrote:
Hi Mark,
On Sun, 3 Nov 2024 at 09:15, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Simon Glass sjg@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.przywara@arm.com wrote:
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?
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.