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

[Tom Rini]

On Thu, Apr 17, 2025 at 03:59:13PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, 17 Apr 2025 at 15:54, Tom Rini <trini at konsulko.com> wrote:
> >
> > 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.
> 
> I think my QEMU test is a good approach, since we can make it work on
> any arch in CI, without need particular hardware.

It's one of those "yes, and" cases. QEMU is good. This test platform is
just a different emulator, not QEMU.

> > > > 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.
> 
> Yes, I gave up with the TF-A thing, but when I hear from Raymond I'll
> give it another crack. It can't be that hard. There are just too many
> 'in flight' things at present.

Well, the good news would be that vexpress_fvp_bloblist needs nothing
"in flight". It's already in U-Boot. It's already in TF-A (build as
documented in U-Boot for vexpress_fvp, add TRANSFER_LIST=1). It's just
not in our CI right this second for reasons I mentioned above.

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