| Message ID | 20241017232531.726559-6-sjg@chromium.org |
|---|---|
| State | New |
| Delegated to: | Andre Przywara |
| Headers | show |
| Series | bootstd: sunxi: Migrate to standard boot | expand |
Hi Andre, 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? Regards, Simon
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? Cheers, Andre
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? Regards, Simon
> 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.
> Date: Sun, 3 Nov 2024 10:36:26 +0000 > From: Andre Przywara <andre.przywara@arm.com> Hi Andre, > 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? 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 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. 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. > 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 >
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. Regards, SImon
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.
> From: Simon Glass <sjg@chromium.org> > Date: Sun, 3 Nov 2024 12:06:41 -0700 Hi Simon, > 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? The old distrboot scripts call the bootmgr; see the BOOTENV_EFI_BOOTMGR define in include/config_distro_bootcmd.h. So before boards were converted to standard boot they had a working EFI bootmanager. When bootstd was introduced that broke, and the patch you mention fixed that. So yes, reverting that patch would remove functionality that has been there for several years. > 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. Then let's fix the bootstd implementation. > Regards, > SImon >
On Sun, 03 Nov 2024 18:54:38 +0100 Mark Kettenis <mark.kettenis@xs4all.nl> wrote: Hi Mark, > > Date: Sun, 3 Nov 2024 10:36:26 +0000 > > From: Andre Przywara <andre.przywara@arm.com> > > Hi Andre, > > > 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? > > 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 ... > 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. 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. 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). 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 > >
> Date: Mon, 4 Nov 2024 13:34:29 +0000 > From: Andre Przywara <andre.przywara@arm.com> > > On Sun, 03 Nov 2024 18:54:38 +0100 > Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > Hi Mark, > > > > Date: Sun, 3 Nov 2024 10:36:26 +0000 > > > From: Andre Przywara <andre.przywara@arm.com> > > > > Hi Andre, > > > > > 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? > > > > 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. > 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. 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. > 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. 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? Cheers, Mark > > > 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 > > > > >
H Mark, Peter, On Mon, 4 Nov 2024 at 08:29, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > Date: Mon, 4 Nov 2024 13:34:29 +0000 > > From: Andre Przywara <andre.przywara@arm.com> > > > > On Sun, 03 Nov 2024 18:54:38 +0100 > > Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > Hi Mark, > > > > > > Date: Sun, 3 Nov 2024 10:36:26 +0000 > > > > From: Andre Przywara <andre.przywara@arm.com> > > > > > > Hi Andre, > > > > > > > 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? > > > > > > 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. > > > 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. > > 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. > > > 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. > > 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? > > Cheers, > > Mark > > > > > 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 > > > > > > > > I am not seeing an obvious solution here, certainly not one we can implement at rc1. Perhaps, Mark, you can carry a patch for your needs until we sort this out? I certainly did not understand the complexities introduced by the patch[1] to enable bootmgr within bootstd. Regards, SImon [1] f2bfa0cb179 bootstd: Make efi_mgr bootmeth work for non-sandbox setups
> From: Simon Glass <sjg@chromium.org> > Date: Tue, 5 Nov 2024 08:14:53 -0700 Heinrich, did you see this discussion concerning the EFI boot manager? Simon, > H Mark, Peter, > > On Mon, 4 Nov 2024 at 08:29, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > Date: Mon, 4 Nov 2024 13:34:29 +0000 > > > From: Andre Przywara <andre.przywara@arm.com> > > > > > > On Sun, 03 Nov 2024 18:54:38 +0100 > > > Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > > > > Hi Mark, > > > > > > > > Date: Sun, 3 Nov 2024 10:36:26 +0000 > > > > > From: Andre Przywara <andre.przywara@arm.com> > > > > > > > > Hi Andre, > > > > > > > > > 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? > > > > > > > > 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. > > > > > 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. > > > > 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. > > > > > 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. > > > > 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? > > > > Cheers, > > > > Mark > > > > > > > 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 > > > > > > > > > > > > > I am not seeing an obvious solution here, certainly not one we can > implement at rc1. > > Perhaps, Mark, you can carry a patch for your needs until we sort this > out? I certainly did not understand the complexities introduced by the > patch[1] to enable bootmgr within bootstd. Well obviously that is possible. But it doesn't make sense to me. I don't think we should convert more boards to use standard boot if that means that U-Boot's EFI bootmanager can't be used for booting those boards. Another thing that doesn't make sense to me is that if you revert that commit, the efi_mgr bootmeth only "works" in sandbox. At that point enabling it by default makes no sense anymore. If you really wanted to switch sunxi to use standard boot and drop the EFI bootmanager support, I think you should just disable BOOTMETH_EFI_BOOTMGR option for sunxi. > Regards, > SImon > > [1] f2bfa0cb179 bootstd: Make efi_mgr bootmeth work for non-sandbox setups >
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 060636e9e2d..c6ad706dfff 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1147,7 +1147,7 @@ config ARCH_SUNXI select BINMAN select CMD_GPIO select CMD_MMC if MMC - select CMD_USB if DISTRO_DEFAULTS && USB_HOST + select CMD_USB if BOOTSTD_DEFAULTS && USB_HOST select CLK select DM select DM_GPIO @@ -1169,9 +1169,9 @@ config ARCH_SUNXI select SUNXI_GPIO select SYS_NS16550 select SYS_THUMB_BUILD if !ARM64 - select USB if DISTRO_DEFAULTS - select USB_KEYBOARD if DISTRO_DEFAULTS && USB_HOST - select USB_STORAGE if DISTRO_DEFAULTS && USB_HOST + select USB if BOOTSTD_DEFAULTS + select USB_KEYBOARD if BOOTSTD_DEFAULTS && USB_HOST + select USB_STORAGE if BOOTSTD_DEFAULTS && USB_HOST select SPL_USE_TINY_PRINTF if SPL select USE_PREBOOT select SYS_RELOC_GD_ENV_ADDR @@ -1179,7 +1179,7 @@ config ARCH_SUNXI imply CMD_DM imply CMD_GPT imply CMD_UBI if MTD_RAW_NAND - imply DISTRO_DEFAULTS + imply BOOTSTD_DEFAULTS imply DM_REGULATOR imply DM_REGULATOR_FIXED imply FAT_WRITE
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(-)