Hi Tom,

On Tue, 29 Apr 2025 at 11:11, Tom Rini <tr...@konsulko.com> wrote:
>
> On Mon, Apr 28, 2025 at 10:41:25AM -0400, Raymond Mao wrote:
> > Hi Simon,
> >
> > On Thu, 17 Apr 2025 at 14:16, Simon Glass <s...@chromium.org> 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
> > >
> >
> > First of all, can you group those patches which are necessary for
> > refactoring the "passage" concept into a smaller series for an easy
> > review?
> >
> > Actually as I mentioned in our previous discussions, I don't agree to
> > add a OF_BLOBLIST as this is duplicated with "BLOBLIST +
> > BLOBLIST_PASSAGE_MANDATORY (aka PASSAGE_IN in the context of your
> > patch - I am not sure the reason you prefer to rename it - do we have
> > any other passage approaches other than using bloblist? And do you
> > have any considerations to allow a fallback or not in case passage
> > failures?)"
>
> As preamble, I am actively working to push the changes for
> vexpress_fvp_bloblist to be available in CI and so provide an easier
> testing path.
>
> At the high level, I don't see what the difference is between "BLOBLIST
> + BLOBLIST_PASSAGE_MANDATORY" and "BLOBLIST + OF_BLOBLIST" or "BLOBLIST
> + whatever v4 of this series ends up showing". Everyone seems wildly in
> agreement that if the prior stage is supposed to give us information
> then it must have done so.
>
> One of the long running "jokes" in computer science about naming being
> one of the hardest problems applies here, too.

I want to use OF_BLOBLIST as it clearly indicates that the devicetree
comes from a bloblist. The BLOBLIST_PASSAGE_MANDATORY thing is a
work-around to try to avoid having OF_BLOBLIST.

>
> > Secondly I prefer to keep the register convention code as a xferlist
> > library that can be used for arm arches other than split them into
> > different low level assemblies. In case of any firmware handoff
> > specification update, we just need to maintain this library.
>
> Yes, if things can be written in a C file, they should be in a C file,
> not assembler.

In this case I disagree and if you look at the x86 code, this kind of
approach is just not sensible. Please take a look at the contortions
of xferlist_from_boot_arg(). It was written for one architecture only,
yet purports to be a general API. My approach is simpler. Also, if
save_boot_args() is implemented by the board, then standard passage
will be broken for that board. It's a weak function!

More generally, please decide if you are willing to let me maintain bloblist.

Regards,
Simon

Reply via email to