[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
Thu Jun 17 21:47:11 CEST 2021
Le jeu. 17 juin 2021 à 21:38, Simon Glass <sjg at chromium.org> a écrit :
> 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...?
>
looks good: just making the problem.
>
>
>>
>> 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.
>
+1
>
> 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 goo
>>>
>> --
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