Le jeu. 17 juin 2021 à 21:38, Simon Glass <s...@chromium.org> a écrit :
> Hi, > > On Fri, 11 Jun 2021 at 05:52, François Ozog <francois.o...@linaro.org> > wrote: > >> >> >> On Thu, 10 Jun 2021 at 23:57, Manish Pandey2 <manish.pand...@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.far...@arm.com> >>> *Sent:* 02 June 2021 16:26 >>> *To:* Madhukar Pappireddy <madhukar.pappire...@arm.com>; Okash Khawaja < >>> okash.khaw...@gmail.com>; Simon Glass <s...@chromium.org> >>> *Cc:* Harb Abdulhamid OS <abdulha...@os.amperecomputing.com>; Boot >>> Architecture Mailman List <boot-architect...@lists.linaro.org>; Ed >>> Stuber <edstu...@amperecomputing.com>; Arjun Khare < >>> akh...@amperecomputing.com>; U-Boot Mailing List <u-boot@lists.denx.de>; >>> Paul Isaac's <paul.isa...@linaro.org>; Ron Minnich <rminn...@google.com>; >>> Moe Ammar <m...@amperecomputing.com>; t...@lists.trustedfirmware.org < >>> t...@lists.trustedfirmware.org>; Manish Pandey2 <manish.pand...@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.far...@arm.com> >>> *Date: *Wednesday, 2 June 2021 at 15:29 >>> *To: *Madhukar Pappireddy <madhukar.pappire...@arm.com>, Okash Khawaja < >>> okash.khaw...@gmail.com>, Simon Glass <s...@chromium.org> >>> *Cc: *Harb Abdulhamid OS <abdulha...@os.amperecomputing.com>, Boot >>> Architecture Mailman List <boot-architect...@lists.linaro.org>, Ed >>> Stuber <edstu...@amperecomputing.com>, Arjun Khare < >>> akh...@amperecomputing.com>, U-Boot Mailing List <u-boot@lists.denx.de>, >>> Paul Isaac's <paul.isa...@linaro.org>, Ron Minnich <rminn...@google.com>, >>> Moe Ammar <m...@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 t...@lists.trustedfirmware.org >>> >>> Who • Bill Fletcher- creator >>> >>> • t...@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.pappire...@arm.com> >>> wrote: >>> >>> >>> >>> Attached slides presented by Manish in the TF-A tech forum. >>> >>> >>> >>> >>> >>> -----Original Message----- >>> >>> From: TF-A <tf-a-boun...@lists.trustedfirmware.org> On Behalf Of >>> Madhukar Pappireddy via TF-A >>> >>> Sent: Tuesday, May 18, 2021 8:59 PM >>> >>> To: Joanna Farley <joanna.far...@arm.com>; Okash Khawaja < >>> okash.khaw...@gmail.com>; Simon Glass <s...@chromium.org> >>> >>> Cc: Harb Abdulhamid OS <abdulha...@os.amperecomputing.com>; Boot >>> Architecture Mailman List <boot-architect...@lists.linaro.org>; Ed >>> Stuber <edstu...@amperecomputing.com>; Arjun Khare < >>> akh...@amperecomputing.com>; U-Boot Mailing List <u-boot@lists.denx.de>; >>> t...@lists.trustedfirmware.org; Paul Isaac's <paul.isa...@linaro.org>; >>> Ron Minnich <rminn...@google.com>; Moe Ammar <m...@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-boun...@lists.trustedfirmware.org> On Behalf Of >>> Joanna Farley via TF-A >>> >>> Sent: Sunday, May 16, 2021 5:19 AM >>> >>> To: Okash Khawaja <okash.khaw...@gmail.com>; Simon Glass < >>> s...@chromium.org> >>> >>> Cc: Harb Abdulhamid OS <abdulha...@os.amperecomputing.com>; Boot >>> Architecture Mailman List <boot-architect...@lists.linaro.org>; >>> t...@lists.trustedfirmware.org; Ed Stuber <edstu...@amperecomputing.com>; >>> Arjun Khare <akh...@amperecomputing.com>; U-Boot Mailing List < >>> u-boot@lists.denx.de>; Paul Isaac's <paul.isa...@linaro.org>; Ron >>> Minnich <rminn...@google.com>; Moe Ammar <m...@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-boun...@lists.trustedfirmware.org on behalf of >>> t...@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 >>> >>> <t...@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 < >>> abdulha...@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.pand...@arm.com> >>> >>> >> Sent: Friday, April 30, 2021 8:14 AM >>> >>> >> To: François Ozog <francois.o...@linaro.org> >>> >>> >> Cc: Simon Glass <s...@chromium.org>; Julius Werner < >>> jwer...@chromium.org>; Harb Abdulhamid OS < >>> abdulha...@os.amperecomputing.com>; Boot Architecture Mailman List < >>> boot-architect...@lists.linaro.org>; t...@lists.trustedfirmware.org; >>> U-Boot Mailing List <u-boot@lists.denx.de>; Paul Isaac's < >>> paul.isa...@linaro.org>; Ron Minnich <rminn...@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 >>> >>> >> >>> >>> >> t...@lists.trustedfirmware.org >>> >>> >> >>> >>> >> Who >>> >>> >> >>> >>> >> • >>> >>> >> >>> >>> >> Bill Fletcher- creator >>> >>> >> >>> >>> >> • >>> >>> >> >>> >>> >> t...@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.o...@linaro.org> >>> >>> >> Sent: 08 April 2021 16:50 >>> >>> >> To: Manish Pandey2 <manish.pand...@arm.com> >>> >>> >> Cc: Simon Glass <s...@chromium.org>; Julius Werner < >>> jwer...@chromium.org>; Harb Abdulhamid OS < >>> abdulha...@os.amperecomputing.com>; Boot Architecture Mailman List < >>> boot-architect...@lists.linaro.org>; t...@lists.trustedfirmware.org < >>> t...@lists.trustedfirmware.org>; U-Boot Mailing List < >>> u-boot@lists.denx.de>; Paul Isaac's <paul.isa...@linaro.org>; Ron >>> Minnich <rminn...@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 < >>> t...@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-boun...@lists.trustedfirmware.org> on >>> behalf of Julius Werner via TF-A <t...@lists.trustedfirmware.org> >>> >>> >> Sent: 25 March 2021 02:43 >>> >>> >> To: Simon Glass <s...@chromium.org> >>> >>> >> Cc: Harb Abdulhamid OS <abdulha...@os.amperecomputing.com>; >>> Boot Architecture Mailman List <boot-architect...@lists.linaro.org>; >>> t...@lists.trustedfirmware.org <t...@lists.trustedfirmware.org>; U-Boot >>> Mailing List <u-boot@lists.denx.de>; Paul Isaac's < >>> paul.isa...@linaro.org>; Ron Minnich <rminn...@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 < >>> t...@lists.trustedfirmware.org> wrote: >>> >>> >> >>> >>> >> Hi Harb, >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> On Wed, 24 Mar 2021 at 11:39, Harb Abdulhamid OS < >>> abdulha...@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.o...@linaro.org | Skype: ffozog
