Hi,
Arm worked to draft a firmware handoff [1] specification, evolving it based on community feedback.
This activity followed the request of some members of the Arm ecosystem [2].
The spec (still at ALP – feedback/comments welcome!) standardizes how information is propagated between different firmware components during boot.
The spec hopes to remove the reliance on bespoke/platform-specific information handoff mechanisms, thus reducing the code maintenance burden.
The concept of entry types is present in the spec – these are data structure layouts that carry a specific type of data.
New types are meant to be added, following the needs and use-cases of the different communities.
Thus, these communities should be empowered to request new types!
To enable community contributions, the specification must be hosted in a location that is friendly to change requests.
We propose to host the spec in trustedfirmware.org (tf.org).
Tf.org hosts several open-source projects and already has an open governance model.
TF-A, and the associated community, rely on tf.org, and thus are already well equipped to maintain this specification and keep it up to date.
Tf.org is agnostic of any downstream projects that would adopt this specification (e.g. U-boot, EDK2, etc.).
We welcome the views of the communities and want to understand if there are any strong objections to what’s being proposed!
If anyone has objections, we are happy to consider alternatives and associated trade-offs.
Regards
[1] https://developer.arm.com/documentation/den0135/latest
[2] Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages - TF-A - lists.trustedfirmware.org<https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…>
Hi all
Just picking up this old thread again...
There seemed to be general agreement to host the firmware hand-off spec in a separate repo with separate maintainers at TrustedFirmware.org, at least initially. Arm intends to progress with the initial population of this repo. We intend to use the CC-BY-SA-4.0 (https://spdx.org/licenses/CC-BY-SA-4.0.html) license, the same as used for EBBR (https://github.com/ARM-software/ebbr). Please say if you have any objections to this. We will also seek approval from the TrustedFirmware.org board.
Regards
Dan.
Hi,
Here is a quick follow up to our last EBBR call[1] and the discussion we had on
the DT fixup protocol[2].
After consulting with Samer (in Cc:), he has suggested that submitting an ECR to
the UEFI forum would be the way to go. There is a specific template for that,
but Samer is experienced in the process and has kindly offered to help.
Heinrich, would you be ok to work with Samer on an ECR, please?
Best regards,
Vincent Stehlé
System Architect - Arm
[1]: https://github.com/ARM-software/ebbr/wiki/EBBR-Notes-2022.09.26
[2]: https://github.com/ARM-software/ebbr/issues/68
Hi,
I hope everybody had a nice summer.
Could we please resume the EBBR bi-weekly calls?
Let us have our next call on Sep. 26.
Here is the list of proposed topics:
- EFI_CONFORMANCE_PROFILE_TABLE
- EFI_DT_FIXUP_PROTOCOL
- ESRT
- Authenticated capsules
- Bump UEFI specification version to 2.10
This is also captured on the wiki[1] with links. Feel free to add topics.
I would also like to take this opportunity to thank Grant for his work on EBBR.
Best regards,
Vincent Stehlé
System Architect - Arm
[1]: https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings
