[PATCH v5 00/25] passage: Define a standard for firmware data flow

[Simon Glass]

Hi Tom,

On Wed, 28 May 2025 at 16:19, Tom Rini <trini at konsulko.com> wrote:
>
> On Wed, May 28, 2025 at 03:32:12PM +0100, Simon Glass wrote:
> > Hi Tom,
> >
> > On Wed, 28 May 2025 at 15:25, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Wed, May 28, 2025 at 06:32:02AM -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.
> > > >
> > > > To try this out:
> > > >
> > > > $ ./scripts/build-qemu -a arm -rsx
> > > >
> > > > This will build and run QEMU for arm64 and you should see the standdard
> > > > passage working:
> > > >
> > > >    Core:  49 devices, 13 uclasses, devicetree: passage
> > > >
> > > > This series is available at u-boot-dm/pass-working
> > > >
> > > > Changes in v5:
> > > > - Add RFC for test script
> > >
> > > And this is why I question if you are working in good faith. I've
> > > rejected this countless times. I'm still rejecting it. Stop including
> > > it. Point at the version you could easily be maintaining in the contrib
> > > repository where you have write access and no one will be telling you to
> > > not do something. People would even review the patches since it would be
> > > against mainline.
> >
> > I fully understand that you don't want the script and I'm only
> > including (as an RFC) so people can actually try this series out. I
> > didn't want to point to my tree as I thought that would annoy you. I
> > already went through why the contrib tree is not suitable for me.
>
> So I have to take changes that I disagree with, but you can't work with
> a tree for your tooling where the community would be happy to provide
> feedback? That does not sound like compromise. Again, I have trouble
> believing that you are working in good faith to resolve the differences
> here.

Yes, as mentioned before I would like you to take changes you disagree
with, at least once we have discussed alternatives and I'm sure that's
the way I want to go. It would save a lot of grief if you could do
that.

I could use your contrib/ repo but there isn't a lot of point, since I
have to have my own tree anyway, due to rejected / changes-requested
patches. It's just lots of fiddling around for no gain. I'm fine with
your not having the scripts in your tree and I'm fine with maintaining
the Python tools in my tree. Basically it seems my tree is the dumping
ground for the stuff you don't want in 'pure U-Boot', or don't want
yet. If you would like me to sync my scripts to the contrib/ tree
every now and then, yes I can do that. I don't see much point since we
can't reference them in docs or test them in CI, but I'm willing to do
it.

But I do want to post patches so I can get feedback from people who
are interested. Perhaps we could set up an 'experimental' mailing list
for that, since you seem really unhappy when I send them to the U-Boot
mailing list?

Re your 'good faith' thing, I'm really just trying to make progress
and I wish there was less 'email overhead' and more action. If you
have concerns, it would be better to discuss a resolution f2f or on a
VC, not endless email threads which don't relate to the patches I'm
sending. The series we are discussing here was sent in 2021 based on
bloblist from 2018! [1]. It is why Firmware Handoff happened. Give me
some credit for foresight, at least.

Regards,
Simon

[1] https://patchwork.ozlabs.org/project/uboot/cover/20211101011734.1614781-1-sjg@chromium.org/