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

[Jose Marinho]

Hi,

The Firmware Handoff specification has just been released at version 0.9.
The release can be found here: https://github.com/FirmwareHandoff/firmware_handoff/releases/tag/v0.9

Thanks to everyone that participated in the discussions about and on the spec development.

Once enough confidence has been obtained in the current specification, we will release a v1.0.

Note that PRs can be raised to request new entry types that are required for your platform.

Regards,
Jose

> -----Original Message-----
> From: Dan Handley <Dan.Handley at arm.com>
> Sent: Tuesday, December 6, 2022 4:15 PM
> To: Julius Werner <jwerner at chromium.org>; Simon Glass
> <sjg at chromium.org>
> Cc: Jose Marinho <Jose.Marinho at arm.com>; tf-a at lists.trustedfirmware.org;
> u-boot at lists.denx.de; boot-architecture at lists.linaro.org; Manish Pandey2
> <Manish.Pandey2 at arm.com>; Joanna Farley <Joanna.Farley at arm.com>; Ilias
> Apalodimas <ilias.apalodimas at linaro.org>; Matteo Carlini
> <Matteo.Carlini at arm.com>; Rob Herring <Rob.Herring at arm.com>; Harb
> Abdulhamid (harb at amperecomputing.com)
> <harb at amperecomputing.com>; Sivasakthivel Nainar
> <snainar at amperecomputing.com>; Samer El-Haj-Mahmoud <Samer.El-Haj-
> Mahmoud at arm.com>; nd <nd at arm.com>
> Subject: RE: [TF-A] [RFC] Proposed location to host the firmware handoff
> specification.
> 
> 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.
>