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

[Tom Rini]

On Sat, Jan 25, 2025 at 10:13:54AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, 23 Jan 2025 at 10:17, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Thu, Jan 23, 2025 at 07:38:04AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Sat, 18 Jan 2025 at 07:41, 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.
> > >
> > > I'm referring to a board that uses distro scripts.
> >
> > OK. Just FYI, "distro scripts" weren't a thing outside of ARM (and maybe
> > RISC-V, and just turris_1x_sdcard on PPC?).
> 
> OK. If those boards don't boot distros then I suppose it doesn't
> matter what they do. It would still be nice to get rid of/reduce the
> scripts, but we shouldn't require it.

The complex "distro boot" script should be phased out. Ad-hoc boot
commands are a valid regular use case.

> So where are we with bootstd migration?

Waiting on Heinrich to have time to post what he and I talked about for
how to untangle "here's how the EFI custodians want to handle starting
EFI payloads" so that the sunxi series can be rebased on top of master
(which now has the BLK related problem solved) and that.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20250125/5f4284cb/attachment.sig>