U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: Simon Glass <sjg@chromium.org>
Cc: "Tony Dinh" <mibodhi@gmail.com>,
	"U-Boot Mailing List" <u-boot@lists.denx.de>,
	"AKASHI Takahiro" <akashi.tkhro@gmail.com>,
	"Caleb Connolly" <caleb.connolly@linaro.org>,
	"Dragan Simic" <dsimic@manjaro.org>,
	"Emil Kronborg" <emil.kronborg@protonmail.com>,
	"Etienne Carriere" <etienne.carriere@foss.st.com>,
	"Francis Laniel" <francis.laniel@amarulasolutions.com>,
	"Guillaume La Roque" <glaroque@baylibre.com>,
	"Heinrich Schuchardt" <xypron.glpk@gmx.de>,
	"Hou Zhiqiang" <Zhiqiang.Hou@nxp.com>,
	"Igor Opaniuk" <igor.opaniuk@gmail.com>,
	"Ilias Apalodimas" <ilias.apalodimas@linaro.org>,
	"Ion Agorria" <ion@agorria.com>,
	"Jerome Forissier" <jerome.forissier@linaro.org>,
	"Julien Masson" <jmasson@baylibre.com>,
	"Marek Vasut" <marek.vasut+renesas@mailbox.org>,
	"Mark Kettenis" <kettenis@openbsd.org>,
	"Martyn Welch" <martyn.welch@collabora.com>,
	"Mattijs Korpershoek" <mkorpershoek@baylibre.com>,
	"Maxim Moskalets" <maximmosk4@gmail.com>,
	"Maximilian Brune" <maximilian.brune@9elements.com>,
	"Michael Trimarchi" <michael@amarulasolutions.com>,
	"Michal Simek" <michal.simek@amd.com>,
	"Moritz Fischer" <moritzf@google.com>,
	"Nam Cao" <namcao@linutronix.de>,
	"Peter Robinson" <pbrobinson@gmail.com>,
	"Quentin Schulz" <quentin.schulz@cherry.de>,
	"Sean Anderson" <seanga2@gmail.com>,
	"Sean Edmond" <seanedmond@microsoft.com>,
	"Shantur Rathore" <i@shantur.com>,
	"Sughosh Ganu" <sughosh.ganu@linaro.org>,
	"Svyatoslav Ryhel" <clamor95@gmail.com>,
	"Thomas Weißschuh" <thomas.weissschuh@linutronix.de>,
	"Tim Harvey" <tharvey@gateworks.com>,
	"Vincent Stehlé" <vincent.stehle@arm.com>
Subject: Re: [PATCH v3 00/19] bootstd: Support recording images
Date: Sat, 25 Jan 2025 12:27:59 -0600	[thread overview]
Message-ID: <20250125182759.GA60249@bill-the-cat> (raw)
In-Reply-To: <CAFLszTjNLDbhOiE-_f7igzMkz3db_0YtwGN4t04tf9SsAbCeMQ@mail.gmail.com>

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

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

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

      reply	other threads:[~2025-01-25 20:04 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-04 17:50 [PATCH v3 00/19] bootstd: Support recording images Simon Glass
2024-11-04 17:50 ` [PATCH v3 01/19] bootstd: Move bootflow-adding to bootstd Simon Glass
2024-11-04 22:02   ` Heinrich Schuchardt
2024-11-05 15:13     ` Simon Glass
2024-11-05 15:39       ` Tom Rini
2024-11-05 16:07         ` Simon Glass
2024-11-04 17:50 ` [PATCH v3 02/19] bootstd: Move bootflow-clearing " Simon Glass
2024-11-04 22:04   ` Heinrich Schuchardt
2024-11-04 17:50 ` [PATCH v3 03/19] bootstd: Add a function to get bootstd only if available Simon Glass
2024-11-04 17:50 ` [PATCH v3 04/19] bootstd: Drop the bootdev-specific list of bootflows Simon Glass
2024-11-04 17:50 ` [PATCH v3 05/19] bootstd: Move the bootflow list into an alist Simon Glass
2024-11-04 17:50 ` [PATCH v3 06/19] bootstd: Maintain a list of images Simon Glass
2024-11-04 17:50 ` [PATCH v3 07/19] bootstd: Update bootmeth_alloc_file() to record images Simon Glass
2024-11-04 17:50 ` [PATCH v3 08/19] boot: pxe: Drop the duplicate comment on get_pxe_file() Simon Glass
2024-11-04 17:51 ` [PATCH v3 09/19] bootmeth_efi: Simplify reading files by using the common function Simon Glass
2024-11-04 17:51 ` [PATCH v3 10/19] bootmeth: Update the read_file() method to include a type Simon Glass
2024-11-04 17:51 ` [PATCH v3 11/19] bootmeth_efi: Check the filename-allocation in the network path Simon Glass
2024-11-04 21:42   ` Heinrich Schuchardt
2024-11-15 23:19     ` Simon Glass
2024-11-04 17:51 ` [PATCH v3 12/19] boot: Update extlinux pxe_getfile_func() to include type Simon Glass
2024-11-04 17:51 ` [PATCH v3 13/19] boot: Update pxe bootmeth to record images Simon Glass
2024-11-04 17:51 ` [PATCH v3 14/19] Update bootmeth_alloc_other() " Simon Glass
2024-11-04 17:51 ` [PATCH v3 15/19] bootstd: Update cros bootmeth " Simon Glass
2024-11-04 17:51 ` [PATCH v3 16/19] bootstd: Add a simple command to list images Simon Glass
2024-11-04 17:51 ` [PATCH v3 17/19] bootstd: Export bootdev_get_from_blk() Simon Glass
2024-11-04 17:51 ` [PATCH v3 18/19] bootstd: Add the concept of an ad-hoc bootflow Simon Glass
2024-11-04 17:51 ` [PATCH v3 19/19] fs: Record loaded files in " Simon Glass
2025-01-15 13:55 ` [PATCH v3 00/19] bootstd: Support recording images Simon Glass
2025-01-15 21:24   ` Tom Rini
2025-01-15 23:14     ` Simon Glass
2025-01-15 23:31       ` Tom Rini
2025-01-16 15:52         ` Simon Glass
2025-01-16 17:21           ` Tom Rini
2025-01-18  4:32             ` Simon Glass
2025-01-18  5:49               ` Tony Dinh
2025-01-18 14:41                 ` Tom Rini
2025-01-18 19:26                   ` Tony Dinh
2025-01-23 14:38                   ` Simon Glass
2025-01-23 17:17                     ` Tom Rini
2025-01-25 17:13                       ` Simon Glass
2025-01-25 18:27                         ` Tom Rini [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250125182759.GA60249@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=Zhiqiang.Hou@nxp.com \
    --cc=akashi.tkhro@gmail.com \
    --cc=caleb.connolly@linaro.org \
    --cc=clamor95@gmail.com \
    --cc=dsimic@manjaro.org \
    --cc=emil.kronborg@protonmail.com \
    --cc=etienne.carriere@foss.st.com \
    --cc=francis.laniel@amarulasolutions.com \
    --cc=glaroque@baylibre.com \
    --cc=i@shantur.com \
    --cc=igor.opaniuk@gmail.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=ion@agorria.com \
    --cc=jerome.forissier@linaro.org \
    --cc=jmasson@baylibre.com \
    --cc=kettenis@openbsd.org \
    --cc=marek.vasut+renesas@mailbox.org \
    --cc=martyn.welch@collabora.com \
    --cc=maximilian.brune@9elements.com \
    --cc=maximmosk4@gmail.com \
    --cc=mibodhi@gmail.com \
    --cc=michael@amarulasolutions.com \
    --cc=michal.simek@amd.com \
    --cc=mkorpershoek@baylibre.com \
    --cc=moritzf@google.com \
    --cc=namcao@linutronix.de \
    --cc=pbrobinson@gmail.com \
    --cc=quentin.schulz@cherry.de \
    --cc=seanedmond@microsoft.com \
    --cc=seanga2@gmail.com \
    --cc=sjg@chromium.org \
    --cc=sughosh.ganu@linaro.org \
    --cc=tharvey@gateworks.com \
    --cc=thomas.weissschuh@linutronix.de \
    --cc=u-boot@lists.denx.de \
    --cc=vincent.stehle@arm.com \
    --cc=xypron.glpk@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox