[PATCH v3 00/19] bootstd: Support recording images
Simon Glass
sjg at chromium.org
Sat Jan 18 05:32:31 CET 2025
Hi Tom,
On Thu, 16 Jan 2025 at 10:22, Tom Rini <trini at konsulko.com> wrote:
>
> On Thu, Jan 16, 2025 at 08:52:38AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Wed, 15 Jan 2025 at 16:32, Tom Rini <trini at konsulko.com> wrote:
> [snip]
> > > I'm referring to the whole bootmeth/bootflow/etc thing. Is this going
to
> > > be put to use by anyone / anywhere on PowerPC? M68K? MIPS? 32bit ARM
is
> > > a harder question there, which is also where this particular overflow
> > > was.
> >
> > I'm still not sure what you are saying. Are you wanting to disable
> > bootstd by default / go back to distro scripts / force everyone to use
> > EFI_LOADER / ?
>
> Yes, I'm asking where it's appropriate to enable this new functionality
> by default. It certainly should be enabled on arm64 (there's new
> designs) and riscv (there's new designs). It still ought to be enabled
> on arm32 because we otherwise lack a easy way to say "new" arm32 (say
> i.MX7) and not "old" arm32 (say i.MX23). What is the point of enabling
> this on PowerPC for example? The active users there are (generally)
> supporting legacy hardware and I have no idea how much they want to
> change their boot process, once bootstd supports flash for example.
> There's similar questions for everything else under arch/ as well.
To me this is in fact two different questions.
1. For PowerPC, m68k, MIPS, I suppose we can just disable BOOTSTD and wait
for them to go away, if you are saying that they are behind on migrations
will never catch up
2. As to the default, I believe BOOTSTD should be on by default, if we
intend to remove the distro scripts and support things that are not EFI
Regards,
Simon
More information about the U-Boot
mailing list