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

[Tom Rini]

On Tue, Apr 29, 2025 at 08:33:16AM -0600, Simon Glass wrote:
> Hi Raymond,
> 
> On Mon, 28 Apr 2025 at 08:41, Raymond Mao <raymond.mao at linaro.org> 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?
> 
> What do you mean by refactoring? I don't believe my series has much
> value unless it actually brings in 'standard passage' and everything
> that goes with that, e.g. the validation and documentation.
> 
> >
> > 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?)"
> 
> This is how I would like it to work, i.e. that one specifically
> chooses OF_BLOBLIST. This split of bloblib and whether or not it is
> mandatory is just confusing.
> 
> >
> > 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.
> 
> I don't agree with that, sorry. This should be a standard feature of
> U-Boot. It is easier to update three 'store' instructions in the
> assembler than to figure out what is going on with the xferlist
> functions. They are really just an obfuscation from the Arm point of
> view, the only current implementer of the spec.
> 
> I have tried my series with your QEMU things but it doesn't work. So I
> went back to try your original instructions with your series and it
> didn't work either. Would it be possible for you to get the pending
> patches in the other projects submitted and then send me an update re
> the instructions? I would like to get the environment running again,
> but there are too many moving parts at present.

What I want to highlight here and now is that vexpress_fvp_bloblist also
uses standard passage and can be added to CI now:
https://patchwork.ozlabs.org/project/uboot/patch/20250422193657.512324-1-trini@konsulko.com/

I will apply this later today I think.

-- 
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/20250429/d0e8717b/attachment.sig>