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.hand...@arm.com> > Sent: Tuesday, December 6, 2022 4:15 PM > To: Julius Werner <jwer...@chromium.org>; Simon Glass > <s...@chromium.org> > Cc: Jose Marinho <jose.mari...@arm.com>; t...@lists.trustedfirmware.org; > u-b...@lists.denx.de; boot-architecture@lists.linaro.org; Manish Pandey2 > <manish.pand...@arm.com>; Joanna Farley <joanna.far...@arm.com>; Ilias > Apalodimas <ilias.apalodi...@linaro.org>; Matteo Carlini > <matteo.carl...@arm.com>; Rob Herring <rob.herr...@arm.com>; Harb > Abdulhamid (h...@amperecomputing.com) > <h...@amperecomputing.com>; Sivasakthivel Nainar > <snai...@amperecomputing.com>; Samer El-Haj-Mahmoud <Samer.El-Haj- > mahm...@arm.com>; nd <n...@arm.com> > Subject: RE: [TF-A] [RFC] Proposed location to host the firmware handoff > specification. > > Hi Julius > > > -----Original Message----- > > From: Julius Werner <jwer...@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. > _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-le...@lists.linaro.org
