Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages

17 Jun 2021

      Hi,
On Fri, 11 Jun 2021 at 05:52, François Ozog francois.ozog@linaro.org
wrote:
...
On Thu, 10 Jun 2021 at 23:57, Manish Pandey2 Manish.Pandey2@arm.com
wrote:
...
Hi Everyone,
I have tried to conclude the discussions we had in two of the TF-A tech
forum sessions and on mailing list.
The problem we are trying to solve is already solved in different
projects in different ways, the purpose of these discussions was to come up
with a standard way which can be adopted widely.
Considering that many Firmware projects are not DT aware its better to
avoid its usage and use simple C structures for wider acceptance. Based on
the discussions following design came up as most acceptable solution

Use list of pre-defined C data structures(blobs) to pass

information, let's call it bloblist

Only bootloaders stages will participate
Blobs will be identified by either tags or UUIDs

They always have a tag, but one of the tags can be BLOBLISTT_UUID
indicating it is for private use. But we should not allow this for passing
across a boundary, so that no software needs to deal with UUID unless it is
UEFI / private code. So, basically what Francios says below.
...
...

Pass pointer to the bloblist head through x0
Existing usage of x0 will be translated into a blob

After all discussions, I now support Simon proposal to use existing
bloblist: it does the job, is already upstream in key projects (core boot,
U-Boot), is supported on x86 and Arm.
I would think of a few additions on the bloblist_rec:
struct bloblist_rec https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/bloblist_rec {
   u32 https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/u32 tag https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/tag;
   u32 https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/u32 hdr_size https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/hdr_size;
   u32 https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/u32 size;
   u32 https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/u32 spare https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/spare;};
enum bloblist_tag_t https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/bloblist_tag_t {
   BLOBLISTT_NONE https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/BLOBLISTT_NONE = 0,
/* Vendor-specific tags are permitted here */
   BLOBLISTT_EC_HOSTEVENT https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/BLOBLISTT_EC_HOSTEVENT,		/* Chromium OS EC host-event mask */
We can give these each a value (=1, =2) so it is clear.
...
BLOBLISTT_SPL_HANDOFF https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/BLOBLISTT_SPL_HANDOFF,		/* Hand-off info from SPL */
   BLOBLISTT_VBOOT_CTX https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/BLOBLISTT_VBOOT_CTX,		/* Chromium OS verified boot context */
   BLOBLISTT_VBOOT_HANDOFF https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/BLOBLISTT_VBOOT_HANDOFF,	/* Chromium OS internal handoff info */
   /*	 * Advanced Configuration and Power Interface Global Non-Volatile	 * Sleeping table. This forms part of the ACPI tables passed to Linux.	 */
   BLOBLISTT_ACPI_GNVS https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/BLOBLISTT_ACPI_GNVS,
   BLOBLISTT_INTEL_VBT https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/BLOBLISTT_INTEL_VBT,		/* Intel Video-BIOS table */
   BLOBLISTT_TPM2_TCG_LOG https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/BLOBLISTT_TPM2_TCG_LOG,		/* TPM v2 log space */
   BLOBLISTT_TCPA_LOG https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/BLOBLISTT_TCPA_LOG,		/* TPM log space */
   BLOBLISTT_ACPI_TABLES https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/BLOBLISTT_ACPI_TABLES,		/* ACPI tables for x86 */
   BLOBLISTT_SMBIOS_TABLES https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/BLOBLISTT_SMBIOS_TABLES,	/* SMBIOS tables for x86 */
How about:
BLOBLISTT_LOCAL = 0xf0000000u   /* values in this space are for local use
during development */
...
BLOBLISTT_COUNT https://elixir.bootlin.com/u-boot/latest/source/include/latest/C/ident/BLOBLISTT_COUNT};
I would add a BLOBLISTT_UUID for all proprietary things that people want
to add. Using private space in a 64 bit field does not make the thing open.
So by using this tag, we know exactly the nature of the blob. Negotiating
for adding a new tag is a good open governance process.
+1
...
We may have to deal with super small SRAM (256KB) and thus we can assume
the bloblist will be a single region of blobs. So I would add a
BLOBLISTT_CONTINUATION which would be a pointer from the SRAM bloblist to a
DRAM backed bloblist.
It is possible to relocate a bloblist, so I wonder if another approach
would be to allow the bloblist to grow as it progresses through the boot
(e.g. once SDRAM is available). That is what U-Boot does and it makes the
code simpler (although only very slightly). However, it does introduce
copying overhead...?
...
Other tags to consider: PSCI interface details, DRAM information, SCMI
stuff, Secure SRAM and DRAM information...
...

Going forward we would provide core changes to demonstrate this

design on various TF-A boundries, BL1<->BL2, BL2<->BL31 and
   BL31<->BL33(only BL31 part)
Please share your thoughts if you disagree to the proposed solution.
Also, refer to attached slide deck which was presented during last tech
forum session on 3rd june, it also captures the points discussed during
meeting and next steps for implementing it in TF-A.
Re devicetree, how about we use bloblist for simple things, but use a
devicetree (perhaps in the bloblist) once SDRAM is available. Blobs that
were created pre-SDRAM can continue to be passed on, but anything created
after SDRAM is available should use devicetree? This would ensure that
complex structures use devicetree rather than C structs, which are of
course harder to extend / describe.
Regards,
Simon
...
...
Thanks
Manish Pandey

*From:* Joanna Farley Joanna.Farley@arm.com
*Sent:* 02 June 2021 16:26
*To:* Madhukar Pappireddy Madhukar.Pappireddy@arm.com; Okash Khawaja <
okash.khawaja@gmail.com>; Simon Glass sjg@chromium.org
*Cc:* Harb Abdulhamid OS abdulhamid@os.amperecomputing.com; Boot
Architecture Mailman List boot-architecture@lists.linaro.org; Ed
Stuber edstuber@amperecomputing.com; Arjun Khare <
akhare@amperecomputing.com>; U-Boot Mailing List u-boot@lists.denx.de;
Paul Isaac's paul.isaacs@linaro.org; Ron Minnich rminnich@google.com;
Moe Ammar moe@amperecomputing.com; tf-a@lists.trustedfirmware.org <
tf-a@lists.trustedfirmware.org>; Manish Pandey2 Manish.Pandey2@arm.com
*Subject:* Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for
information passing between boot stages

TF-A list that got dropped (again)!

Joanna
*From: *Joanna Farley Joanna.Farley@arm.com
*Date: *Wednesday, 2 June 2021 at 15:29
*To: *Madhukar Pappireddy Madhukar.Pappireddy@arm.com, Okash Khawaja <
okash.khawaja@gmail.com>, Simon Glass sjg@chromium.org
*Cc: *Harb Abdulhamid OS abdulhamid@os.amperecomputing.com, Boot
Architecture Mailman List boot-architecture@lists.linaro.org, Ed
Stuber edstuber@amperecomputing.com, Arjun Khare <
akhare@amperecomputing.com>, U-Boot Mailing List u-boot@lists.denx.de,
Paul Isaac's paul.isaacs@linaro.org, Ron Minnich rminnich@google.com,
Moe Ammar moe@amperecomputing.com
*Subject: *Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for
information passing between boot stages
Hi Everyone,
The Manish Pandy and  Madhukar Pappireddy of the TF-A team are planning
to host another TF-A Tech Forum this Thursday to continue the live
discussion.
Here is their agenda:
On tech forum this week, we would like to continue discussions on HOB
list design.
The topics which we would like to cover is

Evaluate different proposals of passing information through boot

phases.

If we don't get an agreement on one solution fit for all then we would

try to get consensus for Infra segment platform(to solve original problem
mentioned by Harb)

Try to get an agreement on size of tags and how "hybrid and tag only"

HOB list can co-exist together?
Details of the call are:
======================
TF-A Tech Forum
When    Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time
Calendar              tf-a@lists.trustedfirmware.org
Who      •              Bill Fletcher- creator
•              tf-a@lists.trustedfirmware.org
We run an open technical forum call for anyone to participate and it is
not restricted to Trusted Firmware project members. It will operate under
the guidance of the TF TSC.
Feel free to forward this invite to colleagues. Invites are via the TF-A
mailing list and also published on the Trusted Firmware website. Details
are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/
Trusted Firmware is inviting you to a scheduled Zoom meeting.
Join Zoom Meeting
https://zoom.us/j/9159704974
Meeting ID: 915 970 4974 <(915)%20970-4974>
One tap mobile
+16465588656 <(646)%20558-8656>,,9159704974 <(915)%20970-4974># US (New
York)
+16699009128 <(669)%20900-9128>,,9159704974 <(915)%20970-4974># US (San
Jose)
Dial by your location
    +1 646 558 8656 <(646)%20558-8656> US (New York)

    +1 669 900 9128 <(669)%20900-9128> US (San Jose)

    877 853 5247 <(877)%20853-5247> US Toll-free

    888 788 0099 <(888)%20788-0099> US Toll-free

Meeting ID: 915 970 4974 <(915)%20970-4974>
Find your local number: https://zoom.us/u/ad27hc6t7h
================
Joanna
On 19/05/2021, 03:50, "Madhukar Pappireddy" Madhukar.Pappireddy@arm.com
wrote:
Attached slides presented by Manish in the TF-A tech forum.

-----Original Message-----

From: TF-A <tf-a-bounces@lists.trustedfirmware.org> On Behalf Of

Madhukar Pappireddy via TF-A
Sent: Tuesday, May 18, 2021 8:59 PM

To: Joanna Farley <Joanna.Farley@arm.com>; Okash Khawaja <

okash.khawaja@gmail.com>; Simon Glass sjg@chromium.org
Cc: Harb Abdulhamid OS <abdulhamid@os.amperecomputing.com>; Boot

Architecture Mailman List boot-architecture@lists.linaro.org; Ed
Stuber edstuber@amperecomputing.com; Arjun Khare <
akhare@amperecomputing.com>; U-Boot Mailing List u-boot@lists.denx.de;
tf-a@lists.trustedfirmware.org; Paul Isaac's paul.isaacs@linaro.org;
Ron Minnich rminnich@google.com; Moe Ammar moe@amperecomputing.com
Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs)

for information passing between boot stages
Hi,

I tried to summarize the discussions in the previous TF-A tech forum

regarding the proposal to adopt Hand-off Blocks (HOBs) for passing
information along the boot chain. I am certain I could not capture all
suggestions/concerns brought up during the call. I apologize if I missed
and/or misinterpreted any comments and would appreciate it if everyone
could share their thoughts in response to this email thread.
The idea is to share information to other boot phases:

> Dynamic information: Created during runtime. Shared in the form of

a chain of blobs(built as a linked list of C structure objects i.e., HOB
list).
> Static information: Known at compile time. Historically, shared

through the use of Device Tree/ACPI tables
Both the above requirements are common in many ecosystems and need to

co-exist.
There are broadly 3 problems to solve:

1. Format of HOB structures: It looks like the consensus is that we

could use existing mechanisms for this (BL_AUX_PARAM in TF-A or bloblist in
u-boot).
2. Identification of HOB list entries: There is a debate about

whether tags would suffice or if the HOB list producer and consumer would
depend on UUID/GUIDs for identifying a specific HOB structure. Another
suggestion was to use a hybrid approach. Reserve a single tag ID for
identifying/constructing a HOB structure that further leverages UUID based
identifier. This way, the generic HOB list doesn't need to support UUIDs
and can work with tags.
3. The design contract for the static interface between two boot

phases: The problem at hand is whether to pass a pointer to a HOB list or a
device tree blob through the general-purpose registers for configuration
hand-off between two boot phases. Some proposals that came up:
        > Proposal 1: Always pass a pointer to the device tree blob

through the GP register and capture the pointer to the HOB list as a
property of a node that is uniquely identifiable by the downstream boot
phase. This needs to define a device tree binding such that producer and
consumer agree on the information passed.
        > Proposal 2: Pass a pointer to a generic container through

the GP register that can be interpreted appropriately by both boot
loaders(i.e., producer and consumer of the boot info). This container can
either be a dtb or a HOB list which can be simply inferred by checking for
a magic header that indicates if the buffer appears to be a flattened
device tree.
        > One another concern that was brought up offline is to make

sure we don't break current design contracts between various boot loader
phases in TF-A. Many of the general-purpose registers have a designated
purpose such as to share configurations between BL images( such as firmware
config dtb, SoC config dtb, Non trusted firmware config dtb, memory layout,
entry point info, etc.).
If I am not mistaken, a single design may not fit the needs of every

segment(client, Infra, embedded) and the forum is open to solutions
tailored for individual segments. Joanna will be sending a follow up email
with more information about future TF-A tech forums that serves as a
platform for further discussions.
Thanks,

Madhukar

-----Original Message-----

From: TF-A <tf-a-bounces@lists.trustedfirmware.org> On Behalf Of

Joanna Farley via TF-A
Sent: Sunday, May 16, 2021 5:19 AM

To: Okash Khawaja <okash.khawaja@gmail.com>; Simon Glass <

sjg@chromium.org>
Cc: Harb Abdulhamid OS <abdulhamid@os.amperecomputing.com>; Boot

Architecture Mailman List boot-architecture@lists.linaro.org;
tf-a@lists.trustedfirmware.org; Ed Stuber edstuber@amperecomputing.com;
Arjun Khare akhare@amperecomputing.com; U-Boot Mailing List <
u-boot@lists.denx.de>; Paul Isaac's paul.isaacs@linaro.org; Ron
Minnich rminnich@google.com; Moe Ammar moe@amperecomputing.com
Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs)

for information passing between boot stages
Apologies I failed with the recording. Manish/Madhu will reply early

next week with the slides and some notes to help with a follow up session
which we hope to hold this Thursday. Invite and agenda will also be sent
out early next week.
Thanks

Joanna

On 14/05/2021, 13:30, "TF-A on behalf of Okash Khawaja via TF-A" <

tf-a-bounces@lists.trustedfirmware.org on behalf of
tf-a@lists.trustedfirmware.org> wrote:
   Hi,

    Do we have slides and video from last week's discussion?

    Thanks,

    Okash

    On Wed, May 5, 2021 at 11:52 PM Simon Glass via TF-A

    <tf-a@lists.trustedfirmware.org> wrote:

    >

    > Hi Harb,

    >

    > Thanks for the idea. I am still not completely sure what

benefit UUID provides to an open project. I'd like to propose something
different, more in the spirit of open collaboration. I also worry that the
word 'standard' seems to be a synonym for UUIDs, UEFI, etc., i.e.
enabling/preferring closed-source firmware and the continued decline of
open-source projects. It really should not be.
    >

    > So I suggest: Use simple integer IDs and reserve some area for

'private' use.  If you want to collaborate across projects outside your
company, you either need to allocate a 'public' ID or agree privately
between the parties which private ID to use.
    >

    > This means that the default and easiest option is for

collaboration and a public ID, with private ones (whose purpose may be
secret) reserved just for private use.
    >

    > Regards,

    > Simon

    >

    > On Wed, 5 May 2021 at 11:42, Harb Abdulhamid OS <

abdulhamid@os.amperecomputing.com> wrote:
    >>

    >> Hey Folks,

    >>

    >> We wanted to put out a middle-ground proposal to help guide

the discussion on the call tomorrow.
    >>

    >>

    >>

    >> A proposal that we have been discussing offline involves

reserving a single tag ID for the purpose of construction UEFI PI HOB List
structure, and that tag would be used to identify a HOB-specific structure
that does leverage UUID based identifier.  This will eliminate the burden
of having to support UUID as the tag, and this enables projects that
require UUID based identifiers for the broad range of HOB structures that
need to be produced during the booting of the platform.  Once we have a tag
for a HOB list, this will enable various HOB producers that can add/extend
the HOB list in TF-A code (or even pre-TF-A code), with a HOB consumer for
that UUID/GUID on the other side (i.e. whatever the BL33 image is booting
on that platform).
    >>

    >>

    >>

    >> Essentially, the idea is if someone would like to support HOB

structures in a standard way using TF-A, they would wrap it up in a
BL_AUX_PARAM/BLOB structure (whatever the group decides) and the way we
identify the structure as a HOB list is with this new reserved tag.
    >>

    >>

    >>

    >> Hopefully that makes sense and less contentious.  Look forward

to discuss this further on the call.
    >>

    >>

    >>

    >> Thanks,

    >>

    >> --Harb

    >>

    >>

    >>

    >> From: Manish Pandey2 <Manish.Pandey2@arm.com>

    >> Sent: Friday, April 30, 2021 8:14 AM

    >> To: François Ozog <francois.ozog@linaro.org>

    >> Cc: Simon Glass <sjg@chromium.org>; Julius Werner <

jwerner@chromium.org>; Harb Abdulhamid OS <
abdulhamid@os.amperecomputing.com>; Boot Architecture Mailman List <
boot-architecture@lists.linaro.org>; tf-a@lists.trustedfirmware.org;
U-Boot Mailing List u-boot@lists.denx.de; Paul Isaac's <
paul.isaacs@linaro.org>; Ron Minnich rminnich@google.com
    >> Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks

(HOBs) for information passing between boot stages
    >>

    >>

    >>

    >> Hi All,

    >>

    >>

    >>

    >> Please find invite for next TF-A Tech Forum session to

continue our discussions on HOB implementation, feel free to forward it to
others.
    >>

    >>

    >>

    >> The next TF-A Tech Forum is scheduled for Thu 6th May 2021

16:00 – 17:00 (BST).
    >>

    >>

    >>

    >> Agenda:

    >>

    >> Discussion Session: Static and Dynamic Information Handling in

TF-A
    >>

    >> Lead by Manish Pandey and Madhukar Pappireddy

    >>

    >> ·         There is ongoing mailing lists discussion[1] related

with adopting a mechanism to pass information through boot stages.
    >>

    >> The requirement is two-fold:

    >>

    >> 1.      Passing static information(config files)

    >>

    >> 2.      Passing dynamic information (Hob list)

    >>

    >> In the upcoming TF-A tech forum, we can start with a

discussion on dynamic information passing and if time permits, we can cover
static information passing. The purpose of the call is to have an open
discussion and continue the discussion from the trusted-substrate call[2]
done earlier. We would like to understand the various requirements and
possible ways to implement it in TF-A in a generalized way so that it can
work with other Firmware projects.
    >>

    >>

    >>

    >> The two specific item which we would like to discuss are:

    >>

    >> 1.      HOB format: TF-A/u-boot both has an existing bloblist

implementation, which uses tag values. Question, can this be enhanced to
use hybrid values(Tag and UUID) both?
    >>

    >> 2.      Standardization on Physical register use to pass base

of HoB data structure.
    >>

    >> References:

    >>

    >> [1]

https://lists.trustedfirmware.org/pipermail/tf-a/2021-April/001069.html
    >>

    >> [2]

https://linaro-org.zoom.us/rec/share/zjfHeMIumkJhirLCVQYTHR6ftaqyWvF_0klgQnH...
Passcode: IPn+5q%
    >>

    >>

    >>

    >> Thanks

    >>

    >>

    >>

    >> Joanna

    >>

    >>

    >>

    >> You have been invited to the following event.

    >>

    >> TF-A Tech Forum

    >>

    >> When

    >>

    >> Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom

Time
    >>

    >> Calendar

    >>

    >> tf-a@lists.trustedfirmware.org

    >>

    >> Who

    >>

    >> •

    >>

    >> Bill Fletcher- creator

    >>

    >> •

    >>

    >> tf-a@lists.trustedfirmware.org

    >>

    >> more details »

    >>

    >>

    >>

    >> We run an open technical forum call for anyone to participate

and it is not restricted to Trusted Firmware project members. It will
operate under the guidance of the TF TSC.
    >>

    >>

    >>

    >> Feel free to forward this invite to colleagues. Invites are

via the TF-A mailing list and also published on the Trusted Firmware
website. Details are here:
https://www.trustedfirmware.org/meetings/tf-a-technical-forum/
    >>

    >>

    >>

    >> Trusted Firmware is inviting you to a scheduled Zoom meeting.

    >>

    >>

    >>

    >> Join Zoom Meeting

    >>

    >> https://zoom.us/j/9159704974

    >>

    >>

    >>

    >> Meeting ID: 915 970 4974 <(915)%20970-4974>

    >>

    >>

    >>

    >> One tap mobile

    >>

    >> +16465588656 <(646)%20558-8656>,,9159704974# US (New York)

    >>

    >> +16699009128 <(669)%20900-9128>,,9159704974# US (San Jose)

    >>

    >>

    >>

    >> Dial by your location

    >>

    >>         +1 646 558 8656 <(646)%20558-8656> US (New York)

    >>

    >>         +1 669 900 9128 <(669)%20900-9128> US (San Jose)

    >>

    >>         877 853 5247 <(877)%20853-5247> US Toll-free

    >>

    >>         888 788 0099 <(888)%20788-0099> US Toll-free

    >>

    >> Meeting ID: 915 970 4974 <(915)%20970-4974>

    >>

    >> Find your local number: https://zoom.us/u/ad27hc6t7h

    >>

    >>

    >>

    >> ________________________________

    >>

    >> From: François Ozog <francois.ozog@linaro.org>

    >> Sent: 08 April 2021 16:50

    >> To: Manish Pandey2 <Manish.Pandey2@arm.com>

    >> Cc: Simon Glass <sjg@chromium.org>; Julius Werner <

jwerner@chromium.org>; Harb Abdulhamid OS <
abdulhamid@os.amperecomputing.com>; Boot Architecture Mailman List <
boot-architecture@lists.linaro.org>; tf-a@lists.trustedfirmware.org <
tf-a@lists.trustedfirmware.org>; U-Boot Mailing List <
u-boot@lists.denx.de>; Paul Isaac's paul.isaacs@linaro.org; Ron
Minnich rminnich@google.com
    >> Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks

(HOBs) for information passing between boot stages
    >>

    >>

    >>

    >> Hi

    >>

    >>

    >>

    >> here is the meeting recording:

    >>

    >>

https://linaro-org.zoom.us/rec/share/zjfHeMIumkJhirLCVQYTHR6ftaqyWvF_0klgQnH...
Passcode: IPn+5q%z
    >>

    >>

    >>

    >> I am really sorry about the confusion related to the meeting

time. I have now understood: the Collaborate portal uses a specific
calendar which is tied to US/Chicago timezone while the actual Google
Calendar is tied to Central Europe timezone. I am going to drop the
Collaborate portal and use a shared Google calendar (it should be visible
on the trusted-substrate.org page).
    >>

    >>

    >>

    >> I'll try to summarize what I learnt and highlight my view on

what can be next steps in a future mail.
    >>

    >>

    >>

    >> Cheers

    >>

    >>

    >>

    >> FF

    >>

    >>

    >>

    >> On Thu, 8 Apr 2021 at 13:56, Manish Pandey2 via TF-A <

tf-a@lists.trustedfirmware.org> wrote:
    >>

    >> Hi,

    >>

    >>

    >>

    >> From TF-A project point of view, we prefer to use existing

mechanism to pass parameters across boot stages using linked list of tagged
elements (as suggested by Julius). It has support for both generic and
SiP-specific tags. Having said that, it does not stop partners to introduce
new mechanisms suitable for their usecase in platform port initially and
later move to generic code if its suitable for other platforms.
    >>

    >>

    >>

    >> To start with, Ampere can introduce a platform specific

implementation of memory tag(speed/NUMA topology etc) which can be
evaluated and discussed for generalization in future. The tag will be
populated in BL2 stage and can be forwarded to further stages(and to BL33)
by passing the head of list pointer in one of the registers. Initially any
register can be used but going forward a standardization will be needed.
    >>

    >>

    >>

    >> The U-boot bloblist mentioned by Simon is conceptually similar

to what TF-A is using,  if there is consensus of using bloblist/taglist
then TF-A tag list may be enhanced to take best of both the implementations.
    >>

    >>

    >>

    >> One of the potential problems of having structure used in

different projects is maintainability, this can be avoided by having a
single copy of these structures in TF-A (kept inside "include/export" which
intended to be used by other projects.)
    >>

    >>

    >>

    >> Regarding usage of either UUID or tag, I echo the sentiments

of Simon and Julius to keep it simple and use tag values.
    >>

    >>

    >>

    >> Looking forward to having further discussions on zoom call

today.
    >>

    >>

    >>

    >> Thanks

    >>

    >> Manish P

    >>

    >>

    >>

    >> ________________________________

    >>

    >> From: TF-A <tf-a-bounces@lists.trustedfirmware.org> on behalf

of Julius Werner via TF-A tf-a@lists.trustedfirmware.org
    >> Sent: 25 March 2021 02:43

    >> To: Simon Glass <sjg@chromium.org>

    >> Cc: Harb Abdulhamid OS <abdulhamid@os.amperecomputing.com>;

Boot Architecture Mailman List boot-architecture@lists.linaro.org;
tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org; U-Boot
Mailing List u-boot@lists.denx.de; Paul Isaac's paul.isaacs@linaro.org;
Ron Minnich rminnich@google.com
    >> Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks

(HOBs) for information passing between boot stages
    >>

    >>

    >>

    >> Just want to point out that TF-A currently already supports a

(very simple) mechanism like this:
    >>

    >>

    >>

    >>

https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+...
    >>

    >>

https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+...
    >>

    >>

https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+...
    >>

    >>

    >>

    >> It's just a linked list of tagged elements. The tag space is

split into TF-A-wide generic tags and SiP-specific tags (with plenty of
room to spare if more areas need to be defined -- a 64-bit tag can fit a
lot). This is currently being used by some platforms that run coreboot in
place of BL1/BL2, to pass information from coreboot (BL2) to BL31.
    >>

    >>

    >>

    >> I would echo Simon's sentiment of keeping this as simple as

possible and avoiding complicated and bloated data structures with UUIDs.
You usually want to parse something like this as early as possible in the
passed-to firmware stage, particularly if the structure encodes information
about the debug console (like it does for the platforms I mentioned above).
For example, in BL31 this basically means doing it right after moving from
assembly to C in bl31_early_platform_setup2() to get the console up before
running anything else. At that point in the BL31 initialization, the MMU
and caches are disabled, so data accesses are pretty expensive and you
don't want to spend a lot of parsing effort or calculate complicated
checksums or the like. You just want something extremely simple where you
ideally have to touch every data word only once.
    >>

    >>

    >>

    >> On Wed, Mar 24, 2021 at 5:06 PM Simon Glass via TF-A <

tf-a@lists.trustedfirmware.org> wrote:
    >>

    >> Hi Harb,

    >>

    >>

    >>

    >> On Wed, 24 Mar 2021 at 11:39, Harb Abdulhamid OS <

abdulhamid@os.amperecomputing.com> wrote:
    >>

    >> Hello Folks,

    >>

    >> Appreciate the feedback and replies on this.  Glad to see that

there is interest in this topic.
    >>

    >>

    >>

    >> I try to address the comments/feedback from Francois and Simon

below….
    >>

    >>

    >>

    >> @François Ozog – happy to discuss this on a zoom call.  I will

make that time slot work, and will be available to attend April 8, 4pm CT.
    >>

    >>

    >>

    >> Note that I’m using the term “HOB” here more generically, as

there are typically vendor specific structures beyond the resource
descriptor HOB, which provides only a small subset of the information that
needs to be passed between the boot phases.
    >>

    >>

    >>

    >> The whole point here is to provide mechanism to develop

firmware that we can build ARM Server SoC’s that support *any* BL33 payload
(e.g. EDK2, AptioV, CoreBoot, and maybe even directly boot strapping
LinuxBoot at some point).   In other-words, we are trying to come up with a
TF-A that would be completely agnostic to the implementation of BL33 (i.e.
BL33 is built completely independently by a separate entity – e.g. an
ODM/OEM).
    >>

    >>

    >>

    >> Keep in mind, in the server/datacenter market segment we are

not building vertically integrated systems with a single entity compiling
firmware/software stacks like most folks in TF-A have become use to.  There
are two categories of higher level firmware code blobs in the
server/datacenter model:
    >>

    >> “SoC” or “silicon” firmware – in TF-A this may map to BL1,

BL2, BL31, and *possibly* one or more BL32 instances
    >> “Platform” or “board” firmware – in TF-A this may map to BL33

and *possibly* one or more BL32 instances.
    >>

    >>

    >>

    >> Even the platform firmware stack could be further fragmented

by having multiple entities involved in delivering the entire firmware
stack: IBVs, ODMs, OEMs, CSPs, and possibly even device vendor code.
    >>

    >>

    >>

    >> To support a broad range of platform designs with a broad

range of memory devices, we need a crisp and clear contract between the SoC
firmware that initializes memory (e.g. BL2) and how that platform boot
firmware (e.g. BL33) gathers information about what memory that was
initialized, at what speeds, NUMA topology, and many other relevant
information that needs to be known and comprehended by the platform
firmware and eventually by the platform software.
    >>

    >>

    >>

    >> I understand the versatility of DT, but I see two major

problems with DT:
    >>

    >> DT requires more complicated parsing to get properties, and

even more complex to dynamically set properties – this HOB structures may
need to be generated in boot phases where DDR is not available, and
therefore we will be extremely memory constrained.
    >> DT is probably overkill for this purpose – We really just want

a list of pointers to simple C structures that code cast (e.g. JEDEC SPD
data blob)
    >>

    >>

    >>

    >> I think that we should not mix the efforts around DT/ACPI

specs with what we are doing here, because those specs and concepts were
developed for a completely different purpose (i.e. abstractions needed for
OS / RTOS software, and not necessarily suitable for firmware-to-firmware
hand-offs).
    >>

    >>

    >>

    >> Frankly, I would personally push back pretty hard on defining

SMC’s for something that should be one way information passing.  Every SMC
we add is another attack vector to the secure world and an increased burden
on the folks that have to do security auditing and threat analysis.  I see
no benefit in exposing these boot/HOB/BOB structures at run-time via SMC
calls.
    >>

    >>

    >>

    >> Please do let me know if you disagree and why.  Look forward

to discussing on this thread or on the call.
    >>

    >>

    >>

    >> @Simon Glass   - Thanks for the pointer to bloblist.   I

briefly reviewed and it seems like a good baseline for what we may be
looking for.
    >>

    >>

    >>

    >> That being said, I would say that there is some benefit in

having some kind of unique identifiers (e.g. UUID or some unique signature)
so that we can tie standardized data structures (based on some future TBD
specs) to a particular ID.  For example, if the TPM driver in BL33 is
looking for the TPM structure in the HOB/BOB list, and may not care about
the other data blobs.  The driver needs a way to identify and locate the
blob it cares about.
    >>

    >>

    >>

    >> The tag is intended to serve that purpose, although perhaps it

should switch from an auto-allocating enum to one with explicit values for
each entry and a range for 'local' use.
    >>

    >>

    >>

    >> I guess we can achieve this with the tag, but the problem with

tag when you have eco-system with a lot of parties doing parallel
development, you can end up with tag collisions and folks fighting about
who has rights to what tag values.  We would need some official process for
folks to register tags for whatever new structures we define, or maybe some
tag range for vendor specific structures.  This comes with a lot of pain
and bureaucracy.  On the other hand, UUID has been a proven way to make it
easy to just define your own blobs with *either* standard or vendor
specific structures without worry of ID collisions between vendors.
    >>

    >>

    >>

    >> True. I think the pain is overstated, though. In this case I

think we actually want something that can be shared between projects and
orgs, so some amount of coordination could be considered a benefit. It
could just be a github pull request. I find the UUID unfriendly and not
just to code size and eyesight! Trying to discover what GUIDs mean or are
valid is quite tricky. E.g. see this code:
    >>

    >>

    >>

    >> #define FSP_HOB_RESOURCE_OWNER_TSEG_GUID \

    >> EFI_GUID(0xd038747c, 0xd00c, 0x4980, \

    >> 0xb3, 0x19, 0x49, 0x01, 0x99, 0xa4, 0x7d, 0x55)

    >>

    >> (etc.)

    >>

    >>

    >>

    >> static struct guid_name {

    >>    efi_guid_t guid;

    >>    const char *name;

    >> } guid_name[] = {

    >>    { FSP_HOB_RESOURCE_OWNER_TSEG_GUID, "TSEG" },

    >>    { FSP_HOB_RESOURCE_OWNER_FSP_GUID, "FSP" },

    >>    { FSP_HOB_RESOURCE_OWNER_SMM_PEI_SMRAM_GUID, "SMM PEI

SMRAM" },
    >>    { FSP_NON_VOLATILE_STORAGE_HOB_GUID, "NVS" },

    >>    { FSP_VARIABLE_NV_DATA_HOB_GUID, "Variable NVS" },

    >>    { FSP_GRAPHICS_INFO_HOB_GUID, "Graphics info" },

    >>    { FSP_HOB_RESOURCE_OWNER_PCD_DATABASE_GUID1, "PCD database

ea" },
    >>    { FSP_HOB_RESOURCE_OWNER_PCD_DATABASE_GUID2, "PCD database

9b" },
    >>

    >> (never figured out what those two are)

    >>

    >>

    >>    { FSP_HOB_RESOURCE_OWNER_PEIM_DXE_GUID, "PEIM Init DXE" },

    >>    { FSP_HOB_RESOURCE_OWNER_ALLOC_STACK_GUID, "Alloc stack" },

    >>    { FSP_HOB_RESOURCE_OWNER_SMBIOS_MEMORY_GUID, "SMBIOS

memory" },
    >>    { {}, "zero-guid" },

    >>    {}

    >> };

    >>

    >> static const char *guid_to_name(const efi_guid_t *guid)

    >> {

    >>    struct guid_name *entry;

    >>

    >>    for (entry = guid_name; entry->name; entry++) {

    >>       if (!guidcmp(guid, &entry->guid))

    >>          return entry->name;

    >>    }

    >>

    >>    return NULL;

    >> }

    >>

    >>

    >>

    >> Believe it or not it took a fair bit of effort to find just

that small list, with nearly every one in a separate doc, from memory.
    >>

    >>

    >>

    >>

    >>

    >> We can probably debate whether there is any value in GUID/UUID

or not during the call… but again, boblist seems like a reasonable starting
point as an alternative to HOB.
    >>

    >>

    >>

    >> Indeed. There is certainly value in both approaches.

    >>

    >>

    >>

    >> Regards,

    >>

    >> Simon

    >>

    >>

    >>

    >>

    >>

    >> Thanks,

    >>

    >> --Harb

    >>

    >>

    >>

    >> From: François Ozog <francois.ozog@linaro.org>

    >> Sent: Tuesday, March 23, 2021 10:00 AM

    >> To: François Ozog <francois.ozog@linaro.org>; Ron Minnich <

rminnich@google.com>; Paul Isaac's paul.isaacs@linaro.org
    >> Cc: Simon Glass <sjg@chromium.org>; Harb Abdulhamid OS <

abdulhamid@os.amperecomputing.com>; Boot Architecture Mailman List <
boot-architecture@lists.linaro.org>; tf-a@lists.trustedfirmware.org
    >> Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks

(HOBs) for information passing between boot stages
    >>

    >>

    >>

    >> +Ron Minnich +Paul Isaac's

    >>

    >>

    >>

    >> Adding Ron and Paul because I think this interface should be

also benefiting LinuxBoot efforts.
    >>

    >>

    >>

    >> On Tue, 23 Mar 2021 at 11:17, François Ozog via TF-A <

tf-a@lists.trustedfirmware.org> wrote:
    >>

   >> Hi,

    >>

    >>

    >>

    >> I propose we cover the topic at the next Trusted Substrate

zoom call on April 8th 4pm CET.
    >>

    >>

    >>

    >> The agenda:

    >>

    >> ABI between non-secure firmware and the rest of firmware (EL3,

S-EL1, S-EL2, SCP) to adapt hardware description to some runtime conditions.
    >>

    >> runtime conditions here relates to DRAM size and topology

detection, secure DRAM memory carvings, PSCI and SCMI interface publishing.
    >>

    >>

    >>

    >> For additional background on existing metadata: UEFI Platform

Initialization Specification Version 1.7, 5.5 Resource Descriptor HOB
    >>

    >> Out of the ResourceType we care about is

EFI_RESOURCE_SYSTEM_MEMORY.
    >>

    >> This HOB lacks memory NUMA attachment or something that could

be related to fill SRAT table for ACPI or relevant DT proximity domains.
    >>

    >> HOB is not consistent accros platforms: some platforms (Arm)

lists memory from the booting NUMA node, other platforms (x86) lists all
memory from all NUMA nodes. (At least this is the case on the two platforms
I tested).
    >>

    >>

    >>

    >> There are two proposals to use memory structures from SPL/BLx

up to the handover function (as defined in the Device Tree technical
report) which can be U-boot (BL33 or just U-Boot in case of SPL/U-Boot
scheme) or EDK2.
    >>

    >> I would propose we also discuss possibility of FF-A interface

to actually query information or request actions to be done (this is a
model actually used in some SoCs with proprietary SMC calls).
    >>

    >>

    >>

    >> Requirements (to be validated):

    >>

    >> - ACPI and DT hardware descriptions.

    >>

    >> - agnostic to boot framework (SPL/U-Boot, TF-A/U-Boot,

TF-A/EDK2)
    >>

    >> - agnostic to boot framework (SPL/U-Boot, TF-A/U-Boot,

TF-A/EDK2, TF-A/LinuxBoot)
    >>

    >> - at least allows complete DRAM description and "persistent"

usage (reserved areas for secure world or other usages)
    >>

    >> - support secure world device assignment

    >>

    >>

    >>

    >> Cheers

    >>

    >>

    >>

    >> FF

    >>

    >>

    >>

    >>

    >>

    >> On Mon, 22 Mar 2021 at 19:56, Simon Glass <sjg@chromium.org>

wrote:
    >>

    >> Hi,

    >>

    >> Can I suggest using bloblist for this instead? It is

lightweight,
    >> easier to parse, doesn't have GUIDs and is already used within

U-Boot
    >> for passing info between SPL/U-Boot, etc.

    >>

    >> Docs here:

https://github.com/u-boot/u-boot/blob/master/doc/README.bloblist
    >> Header file describes the format:

    >>

https://github.com/u-boot/u-boot/blob/master/include/bloblist.h
    >>

    >> Full set of unit tests:

    >> https://github.com/u-boot/u-boot/blob/master/test/bloblist.c

    >>

    >> Regards,

    >> Simon

    >>

    >> On Mon, 22 Mar 2021 at 23:58, François Ozog <

francois.ozog@linaro.org> wrote:
    >> >

    >> > +Boot Architecture Mailman List <

boot-architecture@lists.linaro.org>
    >> >

    >> > standardization is very much welcomed here and need to

accommodate a very
    >> > diverse set of situations.

    >> > For example, TEE OS may need to pass memory reservations to

BL33 or
    >> > "capture" a device for the secure world.

    >> >

    >> > I have observed a number of architectures:

    >> > 1) pass information from BLx to BLy in the form of a

specific object
    >> > 2) BLx called by BLy by a platform specific SMC to get

information
    >> > 3) BLx called by BLy by a platform specific SMC to perform

Device Tree
    >> > fixups

    >> >

    >> > I also imagined a standardized "broadcast" FF-A call so that

any firmware
    >> > element can either provide information or "do something".

    >> >

    >> > My understanding of your proposal is about standardizing on

architecture 1)
    >> > with the HOB format.

    >> >

    >> > The advantage of the HOB is simplicity but it may be

difficult to implement
    >> > schemes such as pruning a DT because device assignment in

the secure world.
    >> >

    >> > In any case, it looks feasible to have TF-A and OP-TEE

complement the list
    >> > of HOBs to pass information downstream (the bootflow).

    >> >

    >> > It would be good to start with building the comprehensive

list of
    >> > information that need to be conveyed between firmware

elements:
    >> >

    >> > information.    | authoritative entity | reporting entity |

information
    >> > exchanged:

    >> > dram               | TFA                       |

TFA                   |
    >> > <format to be detailed, NUMA topology to build the SRAT

table or DT
    >> > equivalent?>

    >> > PSCI               | SCP                      |

TFA?                 |
    >> > SCMI              | SCP or TEE-OS    | TFA? TEE-OS?|

    >> > secure SRAM | TFA.                      | TFA.
             |

    >> > secure DRAM | TFA? TEE-OS?    | TFA? TEE-OS? |

    >> > other?             |                               |

    >> >    |

    >> >

    >> > Cheers

    >> >

    >> > FF

    >> >

    >> >

    >> > On Mon, 22 Mar 2021 at 09:34, Harb Abdulhamid OS via TF-A <

    >> > tf-a@lists.trustedfirmware.org> wrote:

    >> >

    >> > > Hello Folks,

    >> > >

    >> > >

    >> > >

    >> > > I'm emailing to start an open discussion about the

adoption of a concept
    >> > > known as "hand-off blocks" or HOB to become a part of the

TF-A Firmware
    >> > > Framework Architecture (FFA).  This is something that is a

pretty major
    >> > > pain point when it comes to the adoption of TF-A in ARM

Server SoC’s
    >> > > designed to enable a broad range of highly configurable

datacenter
    >> > > platforms.

    >> > >

    >> > >

    >> > >

    >> > >

    >> > >

    >> > > What is a HOB (Background)?

    >> > >

    >> > > ---------------------------

    >> > >

    >> > > UEFI PI spec describes a particular definition for how HOB

may be used for
    >> > > transitioning between the PEI and DXE boot phases, which

is a good
    >> > > reference point for this discussion, but not necessarily

the exact solution
    >> > > appropriate for TF-A.

    >> > >

    >> > >

    >> > >

    >> > > A HOB is simply a dynamically generated data structure

passed in between
    >> > > two boot phases.  This is information that was obtained

through discovery
    >> > > and needs to be passed forward to the next boot phase

*once*, with no API
    >> > > needed to call back (e.g. no call back into previous

firmware phase is
    >> > > needed to fetch this information at run-time - it is

simply passed one time
    >> > > during boot).

    >> > >

    >> > >

    >> > >

    >> > > There may be one or more HOBs passed in between boot

phases.  If there are
    >> > > more than one HOB that needs to be passed, this can be in

a form of a "HOB
    >> > > table", which (for example) could be a UUID indexed array

of pointers to
    >> > > HOB structures, used to locate a HOB of interest (based on

UUID).  In such
    >> > > cases, instead of passing a single HOB, the boot phases

may rely on passing
    >> > > the pointer to the HOB table.

    >> > >

    >> > >

    >> > >

    >> > > This has been extremely useful concept to employ on highly

configurable
    >> > > systems that must rely on flexible discovery mechanisms to

initialize and
    >> > > boot the system.  This is especially helpful when you have

multiple
    >> > >

    >> > >

    >> > >

    >> > >

    >> > >

    >> > > Why do we need HOBs in TF-A?:

    >> > >

    >> > > -----------------------------

    >> > >

    >> > > It is desirable that EL3 firmware (e.g. TF-A) built for

ARM Server SoC in
    >> > > a way that is SoC specific *but* platform agnostic.  This

means that a
    >> > > single ARM SoC that a SiP may deliver to customers may

provide a single
    >> > > TF-A binary (e.g. BL1, BL2, BL31) that could be used to

support a broad
    >> > > range of platform designs and configurations in order to

boot a platform
    >> > > specific firmware (e.g. BL33 and possibly even BL32

code).  In order to
    >> > > achieve this, the platform configuration must be

*discovered* instead of
    >> > > statically compiled as it is today in TF-A via device tree

based
    >> > > enumeration.  The mechanisms of discovery may differ

broadly depending on
    >> > > the relevant industry standard, or in some cases may have

rely on SiP
    >> > > specific discovery flows.

    >> > >

    >> > >

    >> > >

    >> > > For example:  On server systems that support a broad range

DIMM memory
    >> > > population/topologies, all the necessary information

required to boot is
    >> > > fully discovered via standard JEDEC Serial Presence Detect

(SPD) over an
    >> > > I2C bus.  Leveraging the SPD bus, may platform variants

could be supported
    >> > > with a single TF-A binary.  Not only is this information

required to
    >> > > initialize memory in early boot phases (e.g. BL2), the

subsequent boot
    >> > > phases will also need this SPD info to construct a system

physical address
    >> > > map and properly initialize the MMU based on the memory

present, and where
    >> > > the memory may be present.  Subsequent boot phases (e.g.

BL33 / UEFI) may
    >> > > need to generate standard firmware tables to the operating

systems, such as
    >> > > SMBIOS tables describing DIMM topology and various ACPI

tables (e.g. SLIT,
    >> > > SRAT, even NFIT if NVDIMM's are present).

    >> > >

    >> > >

    >> > >

    >> > > In short, it all starts with a standardized or vendor

specific discovery
    >> > > flow in an early boot stage (e.g. BL1/BL2), followed by

the passing of
    >> > > information to the next boot stages (e.g. BL31/BL32/BL33).

    >> > >

    >> > >

    >> > >

    >> > > Today, every HOB may be a vendor specific structure, but

in the future
    >> > > there may be benefit of defining standard HOBs.  This may

be useful for
    >> > > memory discovery, passing the system physical address map,

enabling TPM
    >> > > measured boot, and potentially many other common HOB

use-cases.
    >> > >

    >> > >

    >> > >

    >> > > It would be extremely beneficial to the datacenter market

segment if the
    >> > > TF-A community would adopt this concept of information

passing between all
    >> > > boot phases as opposed to rely solely on device tree

enumeration.  This is
    >> > > not intended to replace device tree, rather intended as an

alternative way
    >> > > to describe the info that must be discovered and

dynamically generated.
    >> > >

    >> > >

    >> > >

    >> > >

    >> > >

    >> > > Conclusion:

    >> > >

    >> > > -----------

    >> > >

    >> > > We are proposing that the TF-A community begin pursuing

the adoption of
    >> > > HOBs as a mechanism used for information exchange between

each boot stage
    >> > > (e.g. BL1->BL2, BL2->BL31, BL31->BL32, and BL31->BL33)?

Longer term we
    >> > > want to explore standardizing some HOB structures for the

BL33 phase (e.g.
    >> > > UEFI HOB structures), but initially would like to agree on

this being a
    >> > > useful mechanism used to pass information between each

boot stage.
    >> > >

    >> > >

    >> > >

    >> > > Thanks,

    >> > >

    >> > > --Harb

    >> > >

    >> > >

    >> > >

    >> > >

    >> > >

    >> > >

    >> > > --

    >> > > TF-A mailing list

    >> > > TF-A@lists.trustedfirmware.org

    >> > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

    >> > >

    >> >

    >> >

    >> > --

    >> > François-Frédéric Ozog | *Director Linaro Edge & Fog

Computing Group*
    >> > T: +33.67221.6485

    >> > francois.ozog@linaro.org | Skype: ffozog

    >> > _______________________________________________

    >> > boot-architecture mailing list

    >> > boot-architecture@lists.linaro.org

    >> > https://lists.linaro.org/mailman/listinfo/boot-architecture

    >>

    >>

    >>

    >>

    >> --

    >>

    >> François-Frédéric Ozog | Director Linaro Edge & Fog Computing

Group
    >>

    >> T: +33.67221.6485

    >> francois.ozog@linaro.org | Skype: ffozog

    >>

    >>

    >>

    >> --

    >> TF-A mailing list

    >> TF-A@lists.trustedfirmware.org

    >> https://lists.trustedfirmware.org/mailman/listinfo/tf-a

    >>

    >>

    >>

    >>

    >> --

    >>

    >> François-Frédéric Ozog | Director Linaro Edge & Fog Computing

Group
    >>

    >> T: +33.67221.6485

    >> francois.ozog@linaro.org | Skype: ffozog

    >>

    >>

    >>

    >> --

    >> TF-A mailing list

    >> TF-A@lists.trustedfirmware.org

    >> https://lists.trustedfirmware.org/mailman/listinfo/tf-a

    >>

    >> --

    >> TF-A mailing list

    >> TF-A@lists.trustedfirmware.org

    >> https://lists.trustedfirmware.org/mailman/listinfo/tf-a

    >>

    >>

    >>

    >>

    >> --

    >>

    >> François-Frédéric Ozog | Director Linaro Edge & Fog Computing

Group
    >>

    >> T: +33.67221.6485

    >> francois.ozog@linaro.org | Skype: ffozog

    >>

    >>

    >

    > --

    > TF-A mailing list

    > TF-A@lists.trustedfirmware.org

    > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

    --

    TF-A mailing list

    TF-A@lists.trustedfirmware.org

    https://lists.trustedfirmware.org/mailman/listinfo/tf-a

--

TF-A mailing list

TF-A@lists.trustedfirmware.org

https://lists.trustedfirmware.org/mailman/listinfo/tf-a

--

TF-A mailing list

TF-A@lists.trustedfirmware.org

https://lists.trustedfirmware.org/mailman/listinfo/tf-a

--
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages