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

[Tony Dinh]

Hi Tom,

On Sat, Jan 18, 2025 at 6:41 AM Tom Rini <trini at konsulko.com> wrote:
>
> 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 at chromium.org> wrote:
> > >
> > > 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
>
> 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).

Yes, indeed. The image size growth would be a problem.

Thanks,
Tony

>
> --
> Tom