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

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

[Jose Marinho]

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/

Re: [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@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/
>
>

RE: [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@chromium.org>
> Sent: 03 May 2022 08:59
> To: Jose Marinho <Jose.Marinho@arm.com>
> Cc: u-boot@lists.denx.de; Heinrich Schuchardt <xypron.glpk@gmx.de>; Ilias
> Apalodimas <ilias.apalodimas@linaro.org>; Tom Rini <trini@konsulko.com>;
> Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>; Manish Pandey2
> <Manish.Pandey2@arm.com>; nd <nd@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@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@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/
> >
> >

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

[Simon Glass]

Hi Jose,

On Tue, 3 May 2022 at 02:26, Jose Marinho <Jose.Marinho@arm.com> wrote:
>
> 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.

Yes it looks like I can do that, so will share with you when done.

Regards,
Simon

>
> Cheers,
> Jose
>
> > -----Original Message-----
> > From: Simon Glass <sjg@chromium.org>
> > Sent: 03 May 2022 08:59
> > To: Jose Marinho <Jose.Marinho@arm.com>
> > Cc: u-boot@lists.denx.de; Heinrich Schuchardt <xypron.glpk@gmx.de>; Ilias
> > Apalodimas <ilias.apalodimas@linaro.org>; Tom Rini <trini@konsulko.com>;
> > Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>; Manish Pandey2
> > <Manish.Pandey2@arm.com>; nd <nd@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@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@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/
> > >
> > >

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

[Jose Marinho]

Good morning Simon,

Thank you for reviewing the FW handoff ALP0 spec proposal, and for your comments.

We have integrated your comments and iterated the spec proposal to ALP1.
The ALP1 document can be obtained here: https://developer.arm.com/documentation/den0135/a

A quick summary of the comments you made:
- rename handoff list since it can easily be confused with the HOB list (HOB list = HandOff Block list): we've adopted the term "Transfer List".
- rename node to entry.
- rename Host to Application Processor (Host for embedded developers is the development host and so was a confusing term to denote the main processor on the target/board)
- rename payload to data.
- don't use CRC-32 for the checksum (it requires 1Kb of constants for a SW implementation): adopted a simple sum to 0 scheme (similar to ACPI tables).
- mandate entry and list alignment to 16-bytes rather than 8-bytes.
- allow entries to have arbitrary size instead of mandating multiples of 8 bytes. (this requires a small padding area at the end of each entry whose size is not a multiple of 16 bytes).
- Create a new entry for a full set of ACPI tables: this requirement does not originate in ACPI, but it's rather a result of the legacy u-boot ACPI table creation code.

Hopefully this is a complete recount 😊. Please let us know if something is missing.

Note that for the ACPI table aggregate, we opted to mandate an RSDP at the start of the entry. The RSDP then points to a RSDT or XSDT (or both).

Also, In your comments you requested an entry type specific for the TCPA or TPM2 ACPI tables.  This makes for a quicker TPM log retrieval.
For this release we were asked to keep the number of ACPI entry types to a minimum.
For now, we can leverage the generic ACPI table entry (tag_id=4) to carry the TCPA or TPM2 tables.
Having said this, the intent is for communities to request the entry definitions that they require.
Hopefully this more specific TPM2/TCPA entry can be soon integrated as a community contribution!

Please let us know if you (and the u-boot community) have additional comments on the ALP1 spec.

Kind Regards,
Jose


> -----Original Message-----
> From: Simon Glass <sjg@chromium.org>
> Sent: 03 May 2022 10:32
> To: Jose Marinho <Jose.Marinho@arm.com>
> Cc: u-boot@lists.denx.de; Heinrich Schuchardt <xypron.glpk@gmx.de>; Ilias
> Apalodimas <ilias.apalodimas@linaro.org>; Tom Rini <trini@konsulko.com>;
> Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>; Manish
> Pandey2 <Manish.Pandey2@arm.com>; nd <nd@arm.com>
> Subject: Re: [RFC] Data structure for information handoff between firmware
> boot stages
> 
> Hi Jose,
> 
> On Tue, 3 May 2022 at 02:26, Jose Marinho <Jose.Marinho@arm.com> wrote:
> >
> > 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.
> 
> Yes it looks like I can do that, so will share with you when done.
> 
> Regards,
> Simon
> 
> >
> > Cheers,
> > Jose
> >
> > > -----Original Message-----
> > > From: Simon Glass <sjg@chromium.org>
> > > Sent: 03 May 2022 08:59
> > > To: Jose Marinho <Jose.Marinho@arm.com>
> > > Cc: u-boot@lists.denx.de; Heinrich Schuchardt <xypron.glpk@gmx.de>;
> > > Ilias Apalodimas <ilias.apalodimas@linaro.org>; Tom Rini
> > > <trini@konsulko.com>; Samer El-Haj-Mahmoud
> > > <Samer.El-Haj-Mahmoud@arm.com>; Manish Pandey2
> > > <Manish.Pandey2@arm.com>; nd <nd@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@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.trusted
> > > > firm ware.org/message/LUIUOVGUMVWID5RUMTYA463KGIU2EHIU/
> > > >
> > > > [2]
> > > > https://lore.kernel.org/u-
> boot/CAODwPW_FwFN1E84cV1+nC1aiahiwOL-
> > > TV=mP_6
> > > > o8h0y9+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@chromiu
> > > > m.or
> > > > g/
> > > >
> > > >

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

[Simon Glass]

Hi Jose,

Thank you for that and good to talk to you the other day.

This looks very close to me. My comments are mostly on the terminology
/ level of detail:

1. 'Board controller' may not exist so really should be in dotted lines
2. The Producer / Consumer terminology seems off to me. The Transfer
List is passed through multiple firmware stages which may add to it,
use bits of it, etc. They don't really consume it. Nor does one stage
produce the whole thing. I suggest calling it sender / receiver.
3. Figure 2 is so small it is illegible. Please can you expand it?
4. Can you use lower-case hex in the tables? Let's break with Intel
:-) Or is that an ARM standard?
5. In 2.3 for the alignment sum can use use ~15 instead of 0xffffff00
so it works on 64-bit machines also?
6. The need for a TPM log is that this log may start in VPL before
DRAM is running. The ACPI tables are not created until U-Boot starts.
Also, the TPM log needs to be available with non-ACPI devices.
7. Section 2.5.6. s/etiher an RSDT or XSDT/either or both of an RSDT
or XSDT/ since this is commonly done
8. We can't really have a platform-specific CPU ID in a doc like this.
Can you add some detail about what it means and an example of how to
find it out and how to use it? Also. please add a description of why
this needs to be in a register. You told me this verbally but I think
it is important.
9. Re 2.5.5 - is it actually useful to create a single ACPI-table
entry? Can you add some text about why it would be used?
10. Need to describe how to allocate a new tag. Also let's give each
tag a name, like XFERLISTT_FDT so we can find it in source code.
11. I cannot find any problem with using x2 the AArch64 entry, but I
do wonder about the 'signature'. How about a 1 in the last nibble so
we can use it as a version number in future if needed? See context at
[1, although. I suspect you already have.
12. I believe we need a device tree offset in the registers also,
since we may need to access the device tree before we access the
bloblist. So I think x0 and r2 should always be set to the DT address.
13. Can we note that x30/lr must be set to the return address? That
allows firmware to fail to start and return an error code in r0/x0.
See this doc [2]
14. We should note that the data structures in TL should be simple C
structures and not complex things, for which devicetree should be
used, since it has a basic structure on which a schema can be built.
The exception to this is historical, custom, binary formats which I
hope that Intel is now moving past.

[1] https://lists.denx.de/pipermail/u-boot/2021-November/466543.html
[2] https://patchwork.ozlabs.org/project/uboot/patch/20220117080353.v2.12.I91d5b9ae45e8d1081b1e165620ad1946bd69af00@changeid/

Regards,
Simon


On Mon, 30 May 2022 at 03:24, Jose Marinho <Jose.Marinho@arm.com> wrote:
>
> Good morning Simon,
>
> Thank you for reviewing the FW handoff ALP0 spec proposal, and for your comments.
>
> We have integrated your comments and iterated the spec proposal to ALP1.
> The ALP1 document can be obtained here: https://developer.arm.com/documentation/den0135/a
>
> A quick summary of the comments you made:
> - rename handoff list since it can easily be confused with the HOB list (HOB list = HandOff Block list): we've adopted the term "Transfer List".
> - rename node to entry.
> - rename Host to Application Processor (Host for embedded developers is the development host and so was a confusing term to denote the main processor on the target/board)
> - rename payload to data.
> - don't use CRC-32 for the checksum (it requires 1Kb of constants for a SW implementation): adopted a simple sum to 0 scheme (similar to ACPI tables).
> - mandate entry and list alignment to 16-bytes rather than 8-bytes.
> - allow entries to have arbitrary size instead of mandating multiples of 8 bytes. (this requires a small padding area at the end of each entry whose size is not a multiple of 16 bytes).
> - Create a new entry for a full set of ACPI tables: this requirement does not originate in ACPI, but it's rather a result of the legacy u-boot ACPI table creation code.
>
> Hopefully this is a complete recount 😊. Please let us know if something is missing.
>
> Note that for the ACPI table aggregate, we opted to mandate an RSDP at the start of the entry. The RSDP then points to a RSDT or XSDT (or both).
>
> Also, In your comments you requested an entry type specific for the TCPA or TPM2 ACPI tables.  This makes for a quicker TPM log retrieval.
> For this release we were asked to keep the number of ACPI entry types to a minimum.
> For now, we can leverage the generic ACPI table entry (tag_id=4) to carry the TCPA or TPM2 tables.
> Having said this, the intent is for communities to request the entry definitions that they require.
> Hopefully this more specific TPM2/TCPA entry can be soon integrated as a community contribution!
>
> Please let us know if you (and the u-boot community) have additional comments on the ALP1 spec.
>
> Kind Regards,
> Jose
>
>
> > -----Original Message-----
> > From: Simon Glass <sjg@chromium.org>
> > Sent: 03 May 2022 10:32
> > To: Jose Marinho <Jose.Marinho@arm.com>
> > Cc: u-boot@lists.denx.de; Heinrich Schuchardt <xypron.glpk@gmx.de>; Ilias
> > Apalodimas <ilias.apalodimas@linaro.org>; Tom Rini <trini@konsulko.com>;
> > Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>; Manish
> > Pandey2 <Manish.Pandey2@arm.com>; nd <nd@arm.com>
> > Subject: Re: [RFC] Data structure for information handoff between firmware
> > boot stages
> >
> > Hi Jose,
> >
> > On Tue, 3 May 2022 at 02:26, Jose Marinho <Jose.Marinho@arm.com> wrote:
> > >
> > > 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.
> >
> > Yes it looks like I can do that, so will share with you when done.
> >
> > Regards,
> > Simon
> >
> > >
> > > Cheers,
> > > Jose
> > >
> > > > -----Original Message-----
> > > > From: Simon Glass <sjg@chromium.org>
> > > > Sent: 03 May 2022 08:59
> > > > To: Jose Marinho <Jose.Marinho@arm.com>
> > > > Cc: u-boot@lists.denx.de; Heinrich Schuchardt <xypron.glpk@gmx.de>;
> > > > Ilias Apalodimas <ilias.apalodimas@linaro.org>; Tom Rini
> > > > <trini@konsulko.com>; Samer El-Haj-Mahmoud
> > > > <Samer.El-Haj-Mahmoud@arm.com>; Manish Pandey2
> > > > <Manish.Pandey2@arm.com>; nd <nd@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@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.trusted
> > > > > firm ware.org/message/LUIUOVGUMVWID5RUMTYA463KGIU2EHIU/
> > > > >
> > > > > [2]
> > > > > https://lore.kernel.org/u-
> > boot/CAODwPW_FwFN1E84cV1+nC1aiahiwOL-
> > > > TV=mP_6
> > > > > o8h0y9+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@chromiu
> > > > > m.or
> > > > > g/
> > > > >
> > > > >

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

[Jose Marinho]

Hi Simon,

Thank you for the comments, and for the additional discussion!

We'll make the changes requested on comments 1 to 5, 7, 10, 11, 12, 14.

Comment 6:
   During our discussion, we came to the conclusion that a specific TPM log entry is required (instead of leveraging the TPM2 ACPI table), but would defer this design until the spec is hosted in a git repo. 

Comment 8:
  We'll drop the CPU ID as it's not currently required. In the future we can introduce the CPU ID by increasing the register convention version (see comment 11).

Comment 9:
  Since we plan to have a specific TPM log entry, there is no immediate need for the isolated ACPI tables. We'll remove the isolated ACPI entry type for now.

Comment 13:
  We propose adding a note suggesting that sufficient information must be kept by a firmware phase allowing it to resume execution from the handoff point, if the next phase returns due to some failure.

We'll work to integrate the comments into the draft spec.

Regards,
Jose



> -----Original Message-----
> From: Simon Glass <sjg@chromium.org>
> Sent: 20 June 2022 14:32
> To: Jose Marinho <Jose.Marinho@arm.com>
> Cc: u-boot@lists.denx.de; Heinrich Schuchardt <xypron.glpk@gmx.de>; Ilias
> Apalodimas <ilias.apalodimas@linaro.org>; Tom Rini <trini@konsulko.com>;
> Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>; Manish
> Pandey2 <Manish.Pandey2@arm.com>; nd <nd@arm.com>
> Subject: Re: [RFC] Data structure for information handoff between firmware
> boot stages
> 
> Hi Jose,
> 
> Thank you for that and good to talk to you the other day.
> 
> This looks very close to me. My comments are mostly on the terminology /
> level of detail:
> 
> 1. 'Board controller' may not exist so really should be in dotted lines 2. The
> Producer / Consumer terminology seems off to me. The Transfer List is
> passed through multiple firmware stages which may add to it, use bits of it,
> etc. They don't really consume it. Nor does one stage produce the whole
> thing. I suggest calling it sender / receiver.
> 3. Figure 2 is so small it is illegible. Please can you expand it?
> 4. Can you use lower-case hex in the tables? Let's break with Intel
> :-) Or is that an ARM standard?
> 5. In 2.3 for the alignment sum can use use ~15 instead of 0xffffff00 so it
> works on 64-bit machines also?
> 6. The need for a TPM log is that this log may start in VPL before DRAM is
> running. The ACPI tables are not created until U-Boot starts.
> Also, the TPM log needs to be available with non-ACPI devices.
> 7. Section 2.5.6. s/etiher an RSDT or XSDT/either or both of an RSDT or XSDT/
> since this is commonly done 8. We can't really have a platform-specific CPU ID
> in a doc like this.
> Can you add some detail about what it means and an example of how to find
> it out and how to use it? Also. please add a description of why this needs to
> be in a register. You told me this verbally but I think it is important.
> 9. Re 2.5.5 - is it actually useful to create a single ACPI-table entry? Can you
> add some text about why it would be used?
> 10. Need to describe how to allocate a new tag. Also let's give each tag a
> name, like XFERLISTT_FDT so we can find it in source code.
> 11. I cannot find any problem with using x2 the AArch64 entry, but I do
> wonder about the 'signature'. How about a 1 in the last nibble so we can use
> it as a version number in future if needed? See context at [1, although. I
> suspect you already have.
> 12. I believe we need a device tree offset in the registers also, since we may
> need to access the device tree before we access the bloblist. So I think x0
> and r2 should always be set to the DT address.
> 13. Can we note that x30/lr must be set to the return address? That allows
> firmware to fail to start and return an error code in r0/x0.
> See this doc [2]
> 14. We should note that the data structures in TL should be simple C
> structures and not complex things, for which devicetree should be used,
> since it has a basic structure on which a schema can be built.
> The exception to this is historical, custom, binary formats which I hope that
> Intel is now moving past.
> 
> [1] https://lists.denx.de/pipermail/u-boot/2021-November/466543.html
> [2]
> https://patchwork.ozlabs.org/project/uboot/patch/20220117080353.v2.12.I9
> 1d5b9ae45e8d1081b1e165620ad1946bd69af00@changeid/
> 
> Regards,
> Simon
> 
> 
> On Mon, 30 May 2022 at 03:24, Jose Marinho <Jose.Marinho@arm.com>
> wrote:
> >
> > Good morning Simon,
> >
> > Thank you for reviewing the FW handoff ALP0 spec proposal, and for your
> comments.
> >
> > We have integrated your comments and iterated the spec proposal to
> ALP1.
> > The ALP1 document can be obtained here:
> > https://developer.arm.com/documentation/den0135/a
> >
> > A quick summary of the comments you made:
> > - rename handoff list since it can easily be confused with the HOB list (HOB
> list = HandOff Block list): we've adopted the term "Transfer List".
> > - rename node to entry.
> > - rename Host to Application Processor (Host for embedded developers
> > is the development host and so was a confusing term to denote the main
> > processor on the target/board)
> > - rename payload to data.
> > - don't use CRC-32 for the checksum (it requires 1Kb of constants for a SW
> implementation): adopted a simple sum to 0 scheme (similar to ACPI tables).
> > - mandate entry and list alignment to 16-bytes rather than 8-bytes.
> > - allow entries to have arbitrary size instead of mandating multiples of 8
> bytes. (this requires a small padding area at the end of each entry whose size
> is not a multiple of 16 bytes).
> > - Create a new entry for a full set of ACPI tables: this requirement does not
> originate in ACPI, but it's rather a result of the legacy u-boot ACPI table
> creation code.
> >
> > Hopefully this is a complete recount 😊. Please let us know if something is
> missing.
> >
> > Note that for the ACPI table aggregate, we opted to mandate an RSDP at
> the start of the entry. The RSDP then points to a RSDT or XSDT (or both).
> >
> > Also, In your comments you requested an entry type specific for the TCPA
> or TPM2 ACPI tables.  This makes for a quicker TPM log retrieval.
> > For this release we were asked to keep the number of ACPI entry types to
> a minimum.
> > For now, we can leverage the generic ACPI table entry (tag_id=4) to carry
> the TCPA or TPM2 tables.
> > Having said this, the intent is for communities to request the entry
> definitions that they require.
> > Hopefully this more specific TPM2/TCPA entry can be soon integrated as a
> community contribution!
> >
> > Please let us know if you (and the u-boot community) have additional
> comments on the ALP1 spec.
> >
> > Kind Regards,
> > Jose
> >
> >
> > > -----Original Message-----
> > > From: Simon Glass <sjg@chromium.org>
> > > Sent: 03 May 2022 10:32
> > > To: Jose Marinho <Jose.Marinho@arm.com>
> > > Cc: u-boot@lists.denx.de; Heinrich Schuchardt <xypron.glpk@gmx.de>;
> > > Ilias Apalodimas <ilias.apalodimas@linaro.org>; Tom Rini
> > > <trini@konsulko.com>; Samer El-Haj-Mahmoud
> > > <Samer.El-Haj-Mahmoud@arm.com>; Manish
> > > Pandey2 <Manish.Pandey2@arm.com>; nd <nd@arm.com>
> > > Subject: Re: [RFC] Data structure for information handoff between
> > > firmware boot stages
> > >
> > > Hi Jose,
> > >
> > > On Tue, 3 May 2022 at 02:26, Jose Marinho <Jose.Marinho@arm.com>
> wrote:
> > > >
> > > > 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.
> > >
> > > Yes it looks like I can do that, so will share with you when done.
> > >
> > > Regards,
> > > Simon
> > >
> > > >
> > > > Cheers,
> > > > Jose
> > > >
> > > > > -----Original Message-----
> > > > > From: Simon Glass <sjg@chromium.org>
> > > > > Sent: 03 May 2022 08:59
> > > > > To: Jose Marinho <Jose.Marinho@arm.com>
> > > > > Cc: u-boot@lists.denx.de; Heinrich Schuchardt
> > > > > <xypron.glpk@gmx.de>; Ilias Apalodimas
> > > > > <ilias.apalodimas@linaro.org>; Tom Rini <trini@konsulko.com>;
> > > > > Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>;
> Manish
> > > > > Pandey2 <Manish.Pandey2@arm.com>; nd <nd@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@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.tru
> > > > > > sted firm
> ware.org/message/LUIUOVGUMVWID5RUMTYA463KGIU2EHIU/
> > > > > >
> > > > > > [2]
> > > > > > https://lore.kernel.org/u-
> > > boot/CAODwPW_FwFN1E84cV1+nC1aiahiwOL-
> > > > > TV=mP_6
> > > > > > o8h0y9+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@chr
> > > > > > omiu
> > > > > > m.or
> > > > > > g/
> > > > > >
> > > > > >