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 <tr...@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 <tr...@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 <s...@chromium.org> wrote: > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 16 Jan 2025 at 10:22, Tom Rini <tr...@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 <tr...@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
signature.asc
Description: PGP signature
