[TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages
François Ozog
francois.ozog at linaro.org
Fri Jun 11 13:51:56 CEST 2021
On Thu, 10 Jun 2021 at 23:57, Manish Pandey2 <Manish.Pandey2 at 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
> - 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 */
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 */
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.
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.
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.
>
> Thanks
> Manish Pandey
> ------------------------------
> *From:* Joanna Farley <Joanna.Farley at arm.com>
> *Sent:* 02 June 2021 16:26
> *To:* Madhukar Pappireddy <Madhukar.Pappireddy at arm.com>; Okash Khawaja <
> okash.khawaja at gmail.com>; Simon Glass <sjg at chromium.org>
> *Cc:* Harb Abdulhamid OS <abdulhamid at os.amperecomputing.com>; Boot
> Architecture Mailman List <boot-architecture at lists.linaro.org>; Ed Stuber
> <edstuber at amperecomputing.com>; Arjun Khare <akhare at amperecomputing.com>;
> U-Boot Mailing List <u-boot at lists.denx.de>; Paul Isaac's <
> paul.isaacs at linaro.org>; Ron Minnich <rminnich at google.com>; Moe Ammar <
> moe at amperecomputing.com>; tf-a at lists.trustedfirmware.org <
> tf-a at lists.trustedfirmware.org>; Manish Pandey2 <Manish.Pandey2 at 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 at arm.com>
> *Date: *Wednesday, 2 June 2021 at 15:29
> *To: *Madhukar Pappireddy <Madhukar.Pappireddy at arm.com>, Okash Khawaja <
> okash.khawaja at gmail.com>, Simon Glass <sjg at chromium.org>
> *Cc: *Harb Abdulhamid OS <abdulhamid at os.amperecomputing.com>, Boot
> Architecture Mailman List <boot-architecture at lists.linaro.org>, Ed Stuber
> <edstuber at amperecomputing.com>, Arjun Khare <akhare at amperecomputing.com>,
> U-Boot Mailing List <u-boot at lists.denx.de>, Paul Isaac's <
> paul.isaacs at linaro.org>, Ron Minnich <rminnich at google.com>, Moe Ammar <
> moe at 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
>
> 1. Evaluate different proposals of passing information through boot phases.
>
> 2. 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)
>
> 3. 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 at lists.trustedfirmware.org
>
> Who • Bill Fletcher- creator
>
> • tf-a at 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
>
>
>
> One tap mobile
>
> +16465588656,,9159704974# US (New York)
>
> +16699009128,,9159704974# US (San Jose)
>
>
>
> Dial by your location
>
> +1 646 558 8656 US (New York)
>
> +1 669 900 9128 US (San Jose)
>
> 877 853 5247 US Toll-free
>
> 888 788 0099 US Toll-free
>
> Meeting ID: 915 970 4974
>
> Find your local number: https://zoom.us/u/ad27hc6t7h
>
>
>
>
>
> ================
>
>
>
> Joanna
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On 19/05/2021, 03:50, "Madhukar Pappireddy" <Madhukar.Pappireddy at arm.com>
> wrote:
>
>
>
> Attached slides presented by Manish in the TF-A tech forum.
>
>
>
>
>
> -----Original Message-----
>
> From: TF-A <tf-a-bounces at lists.trustedfirmware.org> On Behalf Of
> Madhukar Pappireddy via TF-A
>
> Sent: Tuesday, May 18, 2021 8:59 PM
>
> To: Joanna Farley <Joanna.Farley at arm.com>; Okash Khawaja <
> okash.khawaja at gmail.com>; Simon Glass <sjg at chromium.org>
>
> Cc: Harb Abdulhamid OS <abdulhamid at os.amperecomputing.com>; Boot
> Architecture Mailman List <boot-architecture at lists.linaro.org>; Ed Stuber
> <edstuber at amperecomputing.com>; Arjun Khare <akhare at amperecomputing.com>;
> U-Boot Mailing List <u-boot at lists.denx.de>; tf-a at lists.trustedfirmware.org;
> Paul Isaac's <paul.isaacs at linaro.org>; Ron Minnich <rminnich at google.com>;
> Moe Ammar <moe at 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 at lists.trustedfirmware.org> On Behalf Of
> Joanna Farley via TF-A
>
> Sent: Sunday, May 16, 2021 5:19 AM
>
> To: Okash Khawaja <okash.khawaja at gmail.com>; Simon Glass <
> sjg at chromium.org>
>
> Cc: Harb Abdulhamid OS <abdulhamid at os.amperecomputing.com>; Boot
> Architecture Mailman List <boot-architecture at lists.linaro.org>;
> tf-a at lists.trustedfirmware.org; Ed Stuber <edstuber at amperecomputing.com>;
> Arjun Khare <akhare at amperecomputing.com>; U-Boot Mailing List <
> u-boot at lists.denx.de>; Paul Isaac's <paul.isaacs at linaro.org>; Ron Minnich
> <rminnich at google.com>; Moe Ammar <moe at 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 at lists.trustedfirmware.org on behalf of
> tf-a at 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 at 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 at 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 at arm.com>
>
> >> Sent: Friday, April 30, 2021 8:14 AM
>
> >> To: François Ozog <francois.ozog at linaro.org>
>
> >> Cc: Simon Glass <sjg at chromium.org>; Julius Werner <
> jwerner at chromium.org>; Harb Abdulhamid OS <
> abdulhamid at os.amperecomputing.com>; Boot Architecture Mailman List <
> boot-architecture at lists.linaro.org>; tf-a at lists.trustedfirmware.org;
> U-Boot Mailing List <u-boot at lists.denx.de>; Paul Isaac's <
> paul.isaacs at linaro.org>; Ron Minnich <rminnich at 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_0klgQnHTqzgA5Wav0qOO8n7SAM0yj-Hg.mLyFkVJNB1vDKqw_
> 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 at lists.trustedfirmware.org
>
> >>
>
> >> Who
>
> >>
>
> >> •
>
> >>
>
> >> Bill Fletcher- creator
>
> >>
>
> >> •
>
> >>
>
> >> tf-a at 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
>
> >>
>
> >>
>
> >>
>
> >> One tap mobile
>
> >>
>
> >> +16465588656,,9159704974# US (New York)
>
> >>
>
> >> +16699009128,,9159704974# US (San Jose)
>
> >>
>
> >>
>
> >>
>
> >> Dial by your location
>
> >>
>
> >> +1 646 558 8656 US (New York)
>
> >>
>
> >> +1 669 900 9128 US (San Jose)
>
> >>
>
> >> 877 853 5247 US Toll-free
>
> >>
>
> >> 888 788 0099 US Toll-free
>
> >>
>
> >> Meeting ID: 915 970 4974
>
> >>
>
> >> Find your local number: https://zoom.us/u/ad27hc6t7h
>
> >>
>
> >>
>
> >>
>
> >> ________________________________
>
> >>
>
> >> From: François Ozog <francois.ozog at linaro.org>
>
> >> Sent: 08 April 2021 16:50
>
> >> To: Manish Pandey2 <Manish.Pandey2 at arm.com>
>
> >> Cc: Simon Glass <sjg at chromium.org>; Julius Werner <
> jwerner at chromium.org>; Harb Abdulhamid OS <
> abdulhamid at os.amperecomputing.com>; Boot Architecture Mailman List <
> boot-architecture at lists.linaro.org>; tf-a at lists.trustedfirmware.org <
> tf-a at lists.trustedfirmware.org>; U-Boot Mailing List <u-boot at lists.denx.de>;
> Paul Isaac's <paul.isaacs at linaro.org>; Ron Minnich <rminnich at 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_0klgQnHTqzgA5Wav0qOO8n7SAM0yj-Hg.mLyFkVJNB1vDKqw_
> 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 at 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 at lists.trustedfirmware.org> on behalf
> of Julius Werner via TF-A <tf-a at lists.trustedfirmware.org>
>
> >> Sent: 25 March 2021 02:43
>
> >> To: Simon Glass <sjg at chromium.org>
>
> >> Cc: Harb Abdulhamid OS <abdulhamid at os.amperecomputing.com>;
> Boot Architecture Mailman List <boot-architecture at lists.linaro.org>;
> tf-a at lists.trustedfirmware.org <tf-a at lists.trustedfirmware.org>; U-Boot
> Mailing List <u-boot at lists.denx.de>; Paul Isaac's <paul.isaacs at linaro.org>;
> Ron Minnich <rminnich at 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/+/refs/heads/master/include/export/lib/bl_aux_params/bl_aux_params_exp.h
>
> >>
>
> >>
> https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/refs/heads/master/lib/bl_aux_params/bl_aux_params.c
>
> >>
>
> >>
> https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/refs/heads/master/plat/rockchip/common/params_setup.c
>
> >>
>
> >>
>
> >>
>
> >> 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 at lists.trustedfirmware.org> wrote:
>
> >>
>
> >> Hi Harb,
>
> >>
>
> >>
>
> >>
>
> >> On Wed, 24 Mar 2021 at 11:39, Harb Abdulhamid OS <
> abdulhamid at 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 at linaro.org>
>
> >> Sent: Tuesday, March 23, 2021 10:00 AM
>
> >> To: François Ozog <francois.ozog at linaro.org>; Ron Minnich <
> rminnich at google.com>; Paul Isaac's <paul.isaacs at linaro.org>
>
> >> Cc: Simon Glass <sjg at chromium.org>; Harb Abdulhamid OS <
> abdulhamid at os.amperecomputing.com>; Boot Architecture Mailman List <
> boot-architecture at lists.linaro.org>; tf-a at 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 at 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 at 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 at linaro.org> wrote:
>
> >> >
>
> >> > +Boot Architecture Mailman List <
> boot-architecture at 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 at 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 at 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 at linaro.org | Skype: ffozog
>
> >> > _______________________________________________
>
> >> > boot-architecture mailing list
>
> >> > boot-architecture at 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 at linaro.org | Skype: ffozog
>
> >>
>
> >>
>
> >>
>
> >> --
>
> >> TF-A mailing list
>
> >> TF-A at 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 at linaro.org | Skype: ffozog
>
> >>
>
> >>
>
> >>
>
> >> --
>
> >> TF-A mailing list
>
> >> TF-A at lists.trustedfirmware.org
>
> >> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
>
> >>
>
> >> --
>
> >> TF-A mailing list
>
> >> TF-A at 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 at linaro.org | Skype: ffozog
>
> >>
>
> >>
>
> >
>
> > --
>
> > TF-A mailing list
>
> > TF-A at lists.trustedfirmware.org
>
> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a
>
> --
>
> TF-A mailing list
>
> TF-A at lists.trustedfirmware.org
>
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
>
>
>
> --
>
> TF-A mailing list
>
> TF-A at lists.trustedfirmware.org
>
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
>
> --
>
> TF-A mailing list
>
> TF-A at 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 at linaro.org | Skype: ffozog
More information about the U-Boot
mailing list