[RFC] Data structure for information handoff between firmware boot stages

Jose Marinho Jose.Marinho at arm.com
Thu Apr 7 21:22:54 CEST 2022


Hi All,

The topic of information handoff between TF-A's BL31 and BL33 (e.g. U-boot proper, EDK2) was discussed last year in the TF-A and U-boot mailing lists [1], [2].

Examples of information to be handed off between firmware stages are the TPM log, HOB nodes, etc.
Having a standard data structure which is usable/supported by every community contributes to code reuse and leads to simpler codebase maintenance.

Some already existing data structures, such as the UEFI HOB list [3], and the Bloblist from U-boot, were proposed to be employed for the handoffs.
There are pros and cons with both HOBs and Bloblist.
The discussion settled with a consensus that a data structure ought to be defined which encapsulates the best traits of HOBs and Bloblist.

Properties that the data structure should have:
- node types identified by an integer,
- easily relocatable,
- straightforward to append new nodes,
- easy to read and append to from resource constrained environments.

The data structure should be suitable to pass information between different firmware stages, such as:
U-boot SPL -> BL31 -> U-boot
BL1 -> BL2 -> BL31 -> U-boot

As requested in the ML, an initial proposal was drafted [4].
The document [4] is an initial proposal (at an alpha stage).
The document [4] is being circulated for the purpose of gathering initial feedback.
This proposal is closely aligned with an ongoing effort in the u-boot mailing list [5].
The proposal defines 1) a set of standard nodes and 2) the registers used at the handoff boundary.

Standard nodes:
- fdt node: HW description fdt,
- HOB node,
- ACPI table node: the main use-case for this node is to carry the TPM log.

The document [4] accommodates an OEM range, which enables IMPDEF nodes to be caried in the handoff list.
By definition, the nodes in the OEM range are not standard and can be defined per-platform.

Note: the document [4] encapsulates the standard node definition as that is the simplest approach for feedback gathering.
Once there is sufficient consensus around the proposal, the standard node definitions should be moved to a project independent repository. The repository location is TBD.
The list of standard nodes is expected to grow with community contribution.

Kind Regards,
Jose

[1] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.org/message/LUIUOVGUMVWID5RUMTYA463KGIU2EHIU/
[2] https://lore.kernel.org/u-boot/CAODwPW_FwFN1E84cV1+nC1aiahiwOL-TV=mP_6o8h0y9+pCNvg@mail.gmail.com/
[3] https://uefi.org/sites/default/files/resources/PI_Spec_1_6.pdf
[4] https://developer.arm.com/documentation/den0135/a
[5] https://lore.kernel.org/u-boot/20220113022625.413990-1-sjg@chromium.org/



More information about the U-Boot mailing list