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

[Jose Marinho]

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 <sjg at chromium.org>
> Sent: 03 May 2022 08:59
> To: Jose Marinho <Jose.Marinho at arm.com>
> Cc: u-boot at lists.denx.de; Heinrich Schuchardt <xypron.glpk at gmx.de>; Ilias
> Apalodimas <ilias.apalodimas at linaro.org>; Tom Rini <trini at konsulko.com>;
> Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud at arm.com>; Manish Pandey2
> <Manish.Pandey2 at arm.com>; nd <nd at arm.com>
> Subject: Re: [RFC] Data structure for information handoff between firmware
> boot stages
> 
> 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.trustedfirm
> > ware.org/message/LUIUOVGUMVWID5RUMTYA463KGIU2EHIU/
> >
> > [2]
> > https://lore.kernel.org/u-boot/CAODwPW_FwFN1E84cV1+nC1aiahiwOL-
> TV=mP_6
> > o8h0y9+pCNvg at 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.or
> > g/
> >
> >