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