Hi Simon, Thank you for reviewing the draft proposal!
Would you be able to share your review comments on the PDF? Currently the document is not in a markup form and is yet to be hosted in a repository. That's the intent for the long term. Cheers, Jose > -----Original Message----- > From: Simon Glass <[email protected]> > Sent: 03 May 2022 08:59 > To: Jose Marinho <[email protected]> > Cc: [email protected]; Heinrich Schuchardt <[email protected]>; Ilias > Apalodimas <[email protected]>; Tom Rini <[email protected]>; > Samer El-Haj-Mahmoud <[email protected]>; Manish Pandey2 > <[email protected]>; nd <[email protected]> > Subject: Re: [RFC] Data structure for information handoff between firmware > boot stages > > Hi Jose, > > On Thu, 7 Apr 2022 at 13:23, Jose Marinho <[email protected]> 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/[email protected] > > ware.org/message/LUIUOVGUMVWID5RUMTYA463KGIU2EHIU/ > > > > [2] > > https://lore.kernel.org/u-boot/CAODwPW_FwFN1E84cV1+nC1aiahiwOL- > TV=mP_6 > > [email protected]/ > > > > [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/[email protected] > > g/ > > > >
