> 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. 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…