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

[Tom Rini]

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

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.

-- 
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/20250417/ecacbcc5/attachment.sig>