[PATCH v3 00/22] passage: Define a standard for firmware data flow

Wed Apr 30 17:20:56 CEST 2025

On Wed, Apr 30, 2025 at 08:51:53AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Wed, 30 Apr 2025 at 08:29, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Wed, Apr 30, 2025 at 07:55:01AM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Tue, 29 Apr 2025 at 11:11, Tom Rini <trini at konsulko.com> wrote:
> > > >
> > > > On Mon, Apr 28, 2025 at 10:41:25AM -0400, Raymond Mao wrote:
> > > > > Hi Simon,
> > > > >
> > > > > On Thu, 17 Apr 2025 at 14:16, Simon Glass <sjg at chromium.org> wrote:
> > > > > >
> > > > > >
> > > > > > This series adds a standard way of passing information between different
> > > > > > firmware phases. This already exists in U-Boot at a very basic level, in
> > > > > > the form of a bloblist containing an spl_handoff structure, but the intent
> > > > > > here is to define something useful across projects.
> > > > > >
> > > > > > The need for this is growing as firmware fragments into multiple binaries
> > > > > > each with its own purpose. Without any run-time connection, we must rely
> > > > > > on build-time settings which are brittle and painful to keep in sync.
> > > > > >
> > > > > > This feature is named 'standard passage' since the name is more unique
> > > > > > than many others that could be chosen, it is a passage in the sense that
> > > > > > information is flowing from one place to another and it is standard,
> > > > > > because that is what we want to create.
> > > > > >
> > > > > > The implementation is mostly a pointer to a bloblist in a register, with
> > > > > > an extra register to point to a devicetree, for more complex data. This
> > > > > > should cover all cases (small memory footprint as well as complex data
> > > > > > flow) and be easy enough to implement on all architectures.
> > > > > >
> > > > > > The emphasis is on enabling open communcation between binaries, not
> > > > > > enabling passage of secret, undocumented data, although this is possible
> > > > > > in a private environment.
> > > > > >
> > > > > > This series is available at u-boot-dm/pass-working
> > > > > >
> > > > >
> > > > > First of all, can you group those patches which are necessary for
> > > > > refactoring the "passage" concept into a smaller series for an easy
> > > > > review?
> > > > >
> > > > > Actually as I mentioned in our previous discussions, I don't agree to
> > > > > add a OF_BLOBLIST as this is duplicated with "BLOBLIST +
> > > > > BLOBLIST_PASSAGE_MANDATORY (aka PASSAGE_IN in the context of your
> > > > > patch - I am not sure the reason you prefer to rename it - do we have
> > > > > any other passage approaches other than using bloblist? And do you
> > > > > have any considerations to allow a fallback or not in case passage
> > > > > failures?)"
> > > >
> > > > As preamble, I am actively working to push the changes for
> > > > vexpress_fvp_bloblist to be available in CI and so provide an easier
> > > > testing path.
> > > >
> > > > At the high level, I don't see what the difference is between "BLOBLIST
> > > > + BLOBLIST_PASSAGE_MANDATORY" and "BLOBLIST + OF_BLOBLIST" or "BLOBLIST
> > > > + whatever v4 of this series ends up showing". Everyone seems wildly in
> > > > agreement that if the prior stage is supposed to give us information
> > > > then it must have done so.
> > > >
> > > > One of the long running "jokes" in computer science about naming being
> > > > one of the hardest problems applies here, too.
> > >
> > > I want to use OF_BLOBLIST as it clearly indicates that the devicetree
> > > comes from a bloblist. The BLOBLIST_PASSAGE_MANDATORY thing is a
> > > work-around to try to avoid having OF_BLOBLIST.
> >
> > Or:
> > Other people want to use BLOBLIST_PASSAGE_MANDATORY as it clearly
> > indicates that the standard passage will be present and so include the
> > devicetree and any other required logs/blobs/content. The OF_BLOBLIST
> > thing is a work-around to try and avoid having
> > BLOBLIST_PASSAGE_MANDATORY.
> >
> > It's a naming problem and I don't care as long as we end up with an
> > implementation that's useful. And *that* is where my list of what
> > bloblist needs to have, in the end, comes from.
> 
> My approach does the same thing, but allows my x86 boards to work
> without all the confusion. It shows fdt coming from 'standard passage'
> when it is.

It does not matter. Really. Whatever you're doing with OF_BLOBLIST can
also be done with BLOBLIST_PASSAGE_MANDATORY as it's just a naming
thing. There's nothing confusing here unless you insist on confusing it.
Which gets back to what I was saying before about what changes need to
happen to bloblist.

> > > > > Secondly I prefer to keep the register convention code as a xferlist
> > > > > library that can be used for arm arches other than split them into
> > > > > different low level assemblies. In case of any firmware handoff
> > > > > specification update, we just need to maintain this library.
> > > >
> > > > Yes, if things can be written in a C file, they should be in a C file,
> > > > not assembler.
> > >
> > > In this case I disagree and if you look at the x86 code, this kind of
> > > approach is just not sensible. Please take a look at the contortions
> > > of xferlist_from_boot_arg(). It was written for one architecture only,
> > > yet purports to be a general API. My approach is simpler. Also, if
> > > save_boot_args() is implemented by the board, then standard passage
> > > will be broken for that board. It's a weak function!
> >
> > I don't see why this has to be in assembly and not C, no. And it's a
> > weak function because it doesn't yet exist on other architectures and
> > everyone hates #if.
> 
> We just don't need it, though. If you would like this to work on x86,
> it needs to go.
> 
> >
> > > More generally, please decide if you are willing to let me maintain bloblist.
> >
> > Can you be given substantive feedback? Or is only trivial feedback
> > allowed?
> 
> I'm happy to discuss it on a call, but if you insist on
> BLOBLIST_PASSAGE_MANDATORY, then it is going to be tricky. The
> OF_BLOBLIST thing has consumed far too much time. If you want Linaro
> to maintain bloblist, please just say so. I had thought you were OK
> with my taking that on again.

As I've said numerous times now, BLOBLIST_PASSAGE_MANDATORY and
OF_BLOBLIS are just names. Names are one of the hardest problems in
computer science. As I've also said numerous times now, you need to
show ME that you have a good design. That means you need to implement
register passing rather than BLOBLIST_FIXED. You then also likely need
to untie "Is there a bloblist?" from "Make a bloblist" as that's what
complicates things.

-- 
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/20250430/bf770ca1/attachment.sig>