[PATCH v5 00/25] passage: Define a standard for firmware data flow
Simon Glass
sjg at chromium.org
Wed May 28 16:32:12 CEST 2025
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.
Please just ignore that patch. I've marked it as rejected in patchwork
and if I send a v6, I'll drop it.
Regards,
Simon
More information about the U-Boot
mailing list