[TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages
Simon Glass
sjg at chromium.org
Thu Jun 17 21:37:50 CEST 2021
Hi,
On Fri, 11 Jun 2021 at 05:52, François Ozog <francois.ozog at linaro.org>
wrote:
>
>
> 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
>>
>> 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 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 <(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 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 <(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 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