Re: [PATCH v3 00/19] bootstd: Support recording images

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 2813 bytes --]

On Fri, Jan 17, 2025 at 09:49:43PM -0800, Tony Dinh wrote:
> On Fri, Jan 17, 2025 at 8:32 PM Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Tom,
> >
> > On Thu, 16 Jan 2025 at 10:22, Tom Rini <trini@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@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

On what migrations? A board that has a boot command is not some legacy
non-migrated case. That's a valid regular use case.

But yes, I'm suggesting we should put some default y if ... logic around
BOOTSTD.

> > 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


In case you missed it, EFI_LOADER is default for some ARM32, ARM64, X86,
RISC-V and sandbox. None of those are cases where I'm suggesting BOOTSTD
shouldn't be default.

> I'd agree with Simon on 2. Boards that have never been upgraded to
> distro boot or standard boot usually have an internal envs script in
> include/configs/xxx.h that boots the board the legacy way. Even if
> bootstd is enabled by default, it won't hurt those.

It hurts them because of the strong likelyhood that they do have
practical image size limitations (before they would then be leaking in
to U-Boot environment or some other part of flash).

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]