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

[Tom Rini]

On Thu, Apr 17, 2025 at 03:38:07PM -0600, Simon Glass wrote:
> 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

Sure, good, I was wondering about some of the other changes.

As a reminder there are a number of CI labs (of which none are "Linaro",
they still need to get moving on that, yes I'm calling them out here as
a reminder to them) that monitor mainline directly (I push a tree, it
triggers, they speak up if there's specific breakage) and indirectly
(Toradex has given talks about their CI which includes weekly mainline
U-Boot builds) those reports are equally as important as our GitLab and
Azure pipelines.

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

Yes, I'm not completely sure where the bug is but your code breaks the
other platforms and you should have enough information at this point
to run and reproduce it. If it's weirdly only vexpress_fvp_bloblist that
breaks, I can tell you how that's run with transfer list. I can't just
point CI at it because... nasm.us is down which means that coreboot
can't build from source which means I can't rebuild our docker
containers to include the TF-A blobs too.

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