[TF-A] [RFC] Proposed location to host the firmware handoff specification.

[Dan Handley]

Hi Julius

> -----Original Message-----
> From: Julius Werner <jwerner at chromium.org>
> Sent: 06 December 2022 04:18
> 
> It seems like some of us still have very different opinions about how this
> handoff structure should and shouldn't be used, which I really think need to
> be worked out and then codified in the spec before we can call the document
> final, because otherwise no firmware project can trust that it is safe to
> adopt this.
Yes, there are some very differing opinions on usage, but I think it's possible to accommodate multiple usage models at the same time. I agree we need to have maintainer consensus on how the spec will evolve and have this written down (e.g. the tag allocation policy).

> My understanding was that this is supposed to be a universal
> handoff structure that's free to be used by any open source firmware project
> for any of its internal purposes at any stage of the boot flow as a
> standalone solution that doesn't force them to pull in dependencies to any
> other format.
That is a valid usage model, though not the only (universal) one.

> If that is the case then I think the spec should reflect this
> very clearly and should particularly not contain any language about deferring
> certain types of data to other handoff structures wrapped in the TL. It needs
> to be clear that projects will be allowed to freely register tags for their
> needs without the risk of suddenly getting told by the maintainers that they
> need to use an FDT for this or that instead.
> 
OK, this seems to be the crux of the problem. Is it possible for us say that users are free to register new TLs, while at the same time recommending the use of existing formats for complex structures (e.g. FDT, HOB)?

> On the other hand, if this is just supposed to be an early boot flow
> extension to FDTs, then that's very different from what I understood the goal
> to be and then I think the text of the spec should be honest about that front
> and center. In that case, I wouldn't expect much adoption beyond the
> ecosystem that's already deeply tied to FDT to begin with, though, and that
> would be far from "universal".

That is another valid usage model. Some ecosystems are deeply wedded to FDT or HOB/ACPI (there may be others) and this spec is not going to change that. I don't think we're going to get something universal in the way you're hoping. But we might be able to at least enable better interoperability/reusability between fw components across different ecosystems.

Regards

Dan.