On Mon, 04 Nov 2024 16:29:20 +0100 Mark Kettenis <mark.kette...@xs4all.nl> wrote:
Hi Mark, Simon, > > Date: Mon, 4 Nov 2024 13:34:29 +0000 > > From: Andre Przywara <andre.przyw...@arm.com> > > > > On Sun, 03 Nov 2024 18:54:38 +0100 > > Mark Kettenis <mark.kette...@xs4all.nl> wrote: > > > > Hi Mark, > > > > > > Date: Sun, 3 Nov 2024 10:36:26 +0000 > > > > From: Andre Przywara <andre.przyw...@arm.com> > > > > > > Hi Andre, > > > > > > > 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? > > > > > > 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 ... > > Right. One of the suggested solutions for this was to store EFI > variables on the ESP in a well-defined format and have the OS update > that file directly. Ilias posted a diff for that some time ago, but I > don't think this was committed. I did some testing of that approach > on OpenBSD and I'm fairly confident I could make it work. But you'd > probably need support from at least a few Linux distros to make this > feasable. Anyway... > > > > 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. > > You can. But I don't think that is something you could expect the > average user to do. Exactly, I don't think anyone really does that outside of testing. > > 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. > > Well "removable media" is a bit of a misnomer here. The current UEFI > spec says: > > Searching for a default application to boot happens on both > removable and fixed media types. Ah, has that changed lately? I remember that was always a problem years ago, when this was quite PC centric, where CD-ROM / USB stick vs. harddisk was a quite clear distinction. And I dimly remember some Linux distribution were ignoring this anyway already, to make things work? > So the fallback actually needs to happen on "fixed" disks as well. At > least that is what most UEFI implementations do (and is what EDK2 > does). At this point OpenBSD (on all architectures, include amd64) > pretty much relies on this as we don't configure any boot options at > the moment. And it works on 99% of the machines out there. Well, that certainly sounds good enough for me. While I wish it would behave like "real computers", the reality in sunxi land is somewhat different, and there are a lot of people still using some custom boot scripts. > > 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). > > To some extent, we already have a solution. We have > BOOTMETH_EFILOADER, which is a per-device boot method which loads the > default application. So that pretty much does what's needed for the > fallback. Ah, so that is separate, right? In that case just BOOTMETH_EFILOADER sounds good enough for me! > So if it was possible to disabled the autogeneration of the default > media boot options you'd probably be closer to what you want for > sunxi. I believe that'd make you lose the EFI boot menu options for > the different devices though. So maybe the solution is for > BOOTMETH_EFI_MGR to simply skip the autogenerated options and let > BOOTMETH_EFILOADER take care of those? Not sure if that breaks something else, but could we just disable CONFIG_EFI_BOOTMETH_EFI_BOOTMGR for sunxi? default y if !ARCH_SUNXI? At least for now, until this is sorted? As this would probably unblock this series. I need to test this at home, but if the old boot scripts and bootaa64.efi still work in the right order, I am happy with bootstd. 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 > > > > > > > >
