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

[Simon Glass]

Hi Tom,

On Thu, 17 Apr 2025 at 15:24, Tom Rini <trini at konsulko.com> wrote:
>
> On Thu, Apr 17, 2025 at 12:15:42PM -0600, Simon Glass 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
>
> Before I get into further feedback, my first bit of feedback is that
> this breaks transfer list support. I didn't check this on Raymond's QEMU
> but did test it on vexpress_fvp_bloblist and expect QEMU is also broken.
> The most likely reason I think is:
> >   passage: spl: Support passing the passage to U-Boot
> [snip]
> >   xferlist: Drop old xferlist code

CI passes for me:

https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/25806

>
> These are not the same. And they should be. And they should be using
> the register layout / values other projects use today.
>
> And I am bluntly uninterested in who shuffled the registers around and
> made them no longer agree. What TF-A is doing now is what's in the wild
> now. And shame on them if there wasn't a good reason for changing things
> either.

They are the same and any difference is a bug, quite possibly in my
code. I am hoping that Raymond can point it out, as I believe I am
following the spec that we created.

The xferlist is a little harder to maintain and it has a bit of an
unusual API. It's better to use global_data for this case.

Regards,
Simon