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

[Simon Glass]

Hi Jose,

On Thu, 7 Apr 2022 at 13:23, Jose Marinho <Jose.Marinho at arm.com> wrote:
>
> 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.

Thank you for the document. Is there a way to comment on it or should
I just send you my hand-written markup?

Regards,
Simon

>
> 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/
>
>