Please find my replies

To Julius's question:
Just to clarify: are you using "bloblist" as a general term for the concept of a simple linked list of tagged data blobs, or to refer specifically to the U-Boot implementation with that name? The existing TF-A implementation (bl_aux_params) is basically identical in concept to the U-Boot bloblist, but not binary compatible. Are we talking about just keeping that, or throwing it away in order to reimplement the exact structure U-Boot is using? (I would prefer to keep the bl_aux_params as they are to avoid disrupting existing uses, of course. Making backwards-incompatible changes to an interface that passes across multiple repos and firmware components is always a big pain.)
- "bloblist" is a general term for concept of linked list and it's not exactly U-boot implementation. The proposed solution will cause some degree of changes in all the participating projects. For backward compatibility issue, we have already though about it and proposed to have build configs which will be enabled by platform integrators.

To Daniel's question:
In short are you confident adopting a mantra of "it doesn't exist unless it's upstreamed" is sufficient?
- "If it is not upstreamed we don't know if it exists or not?", Since we can't know/control what all are hidden in closed sources, so we are only concentrating on open sources.

Finally, We are trying to solve a problem(in a standard way) which is already solved in different projects differently. To have a common solution acceptable to all, changes in participating projects are inevitable. Once we get agreement in principle, we should be ready to have some changes in the codebase. The TF-A project is willing to put effort to put something out there that will enable other projects, but we need some degree of assurances that proposed changes will be accepted in other projects also.


Thanks
Manish
From: Daniel Thompson <daniel.thompson@linaro.org>
Sent: 09 July 2021 11:07
To: François Ozog <francois.ozog@linaro.org>
Cc: Julius Werner <jwerner@chromium.org>; Ed Stuber <edstuber@amperecomputing.com>; Boot Architecture Mailman List <boot-architecture@lists.linaro.org>; undefined <loic.pallardy@st.com>; Harb Abdulhamid OS <abdulhamid@os.amperecomputing.com>; Simon Glass <sjg@chromium.org>; Arjun Khare <akhare@amperecomputing.com>; U-Boot Mailing List <u-boot@lists.denx.de>; tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.org>; Paul Isaac's <paul.isaacs@linaro.org>; Ron Minnich <rminnich@google.com>; Moe Ammar <moe@amperecomputing.com>; Manish Pandey2 <Manish.Pandey2@arm.com>
Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages
 
On Fri, Jul 09, 2021 at 09:05:09AM +0200, François Ozog wrote:
> Le ven. 9 juil. 2021 à 03:09, Julius Werner <jwerner@chromium.org> a écrit :
>
> > > Of course every project would like not to change...
> > >
> > > For TF-A I wonder whether it will/should in fact use devicetree if there
> > is a lot of complex data? TBD, I suppose.
> >
> > Okay, sorry, now I'm a bit confused -- I thought the discussion in
> > this thread was about which parameter hand-off mechanism to use *for
> > TF-A*? Or did it shift to discuss other projects in the meantime (I
> > didn't always follow it closely)? I think it started with the UEFI
> > guys wanting to implement a HOB format to interface with TF-A, and I
> > think we now concluded that they're okay with using a simple parameter
> > list instead (and wrapping their custom HOBs into a parameter blob
> > that contains their UUID and everything else in the data part).
> >
> > So for TF-A, if the decision is that we want a parameter list, I think
> > it makes sense to keep using the format that has already been there
> > and in use for several years, and define new tags for the UEFI HOB use
> > case in that. I don't really see a reason to switch TF-A and all other
> > projects currently interfacing with it that way (e.g. coreboot) to
> > something only used by U-Boot right now, if they're practically
> > identical in concept.
>
> Looking at bl_au_params: used by 3 SoCs to deal with gpio and serial.

I presume this analysis only covers those SoCs where someone (vendor,
customer, community) has upstreamed their TF-A implementation?

It is only relatively recently[1] that the TF-A CLA requirements that
inhibited upstreaming were relaxed. Additionally the current silicon
supply crunch is forcing board designers to second (third and forth)
source critical components which can drive usage of firmware parameter
passing.

In short are you confident adopting a mantra of "it doesn't exist
unless it's upstreamed" is sufficient?


Daniel.


[1] Perhaps not that recent if measured in years... but certainly
    recent relative to firmware life cycles!


> Migration may not be that a big effort (handful lines of code?).  The
> key thing is that the biggest consumer of them are BL33 and a little
> bit by some OS drivers (OS itself shall not be a consumer).  U-Boot
> has an established mechanism which is used in particular on all chrome
> books in both x86 and Arm environments.  I have the impression that
> U-Boot is the typical BL33 so I would import the mechanism into TFA,
> not the other way round.  EDK2 has typically its own code for TFA
> matters and may just import BL31, so it does not appear a priority in
> that decision. But I may be wrong…
>
> >
> > --
> François-Frédéric Ozog | *Director Business Development* T:
> +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
> _______________________________________________ boot-architecture
> mailing list boot-architecture@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/boot-architecture