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