From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2A0BFC49361 for ; Thu, 17 Jun 2021 19:54:26 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0ABFC61004 for ; Thu, 17 Jun 2021 19:54:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0ABFC61004 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 994E7801DE; Thu, 17 Jun 2021 21:54:22 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=chromium.org header.i=@chromium.org header.b="TiUt/EyT"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 7311882AE4; Thu, 17 Jun 2021 21:38:16 +0200 (CEST) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id E0C8C82934 for ; Thu, 17 Jun 2021 21:38:03 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com Received: by mail-wr1-x42b.google.com with SMTP id n7so8048415wri.3 for ; Thu, 17 Jun 2021 12:38:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YnVs3F51YXPexc8567k9pi4IydLjSl6kHPrT+uDjPa0=; b=TiUt/EyTYSwC/waf7JKAb5gTF8YDomXZMD7QfxVP/X4WnDpV0yqVoRr0fPZAHu11FY bjmnrmrZTCCSYg1WAQCyUIOcLeILKb0SncXi7KA2K/MjWGzpmGagomZllel5aNOeTFz3 WKaBg3PQllZjqwX1y2L586M/zVvULdycqqMHo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YnVs3F51YXPexc8567k9pi4IydLjSl6kHPrT+uDjPa0=; b=i4r3XcHUyWcQu51fgC6Ei4u2n/64Sko/jD2v+3CTzJz6IFsBRawjDCTW1FJjergIt4 0cXBbIuaqTAh44ji/YngQpYL40qfa4P3jyf+DPFErFyTVrrvnvLvqn/Pkupbx/BgLd0H E77FuljLD8iUpLQDvrsqnaYGGK5adtqDcJdTVd0LugcSnwfnR1bGKpiimYi4z2ZLAxZE lLPj5EHGMU4QAI9702eDTLd1QXg/99hgkQFQnbuFKboA5ar/myXRX76GP0N3+QbqfjXg yiop25N1gw3m2IIGKzpN+Oz6/fRtxU1pqg221fD53g6Bx0Czl0wtH/po7jCq9UY2ljyS pmQA== X-Gm-Message-State: AOAM531rRLdw7e3OTSI+vGqZk3HkdLcX/YKRBp6H6xLx9B2AGmMs3WuA hdIDbZh/bhirFw8sk8SC1HkcexCYSrDmUm0EZEnOlQ== X-Google-Smtp-Source: ABdhPJwHq0AVyzEgJZWtkIX7VwZH9t/nQHvFwtIphECt1ybI7frcnwBV4qxZ4HL334TLYt2D6XuxRS8yRZ3Ez108+GQ= X-Received: by 2002:adf:d1ec:: with SMTP id g12mr7923621wrd.204.1623958682990; Thu, 17 Jun 2021 12:38:02 -0700 (PDT) MIME-Version: 1.0 References: <010001785912437d-ab3ef3d5-960c-4f85-bd2c-7f7853900e7a-000000@email.amazonses.com> <010001785e96cf83-06ded054-1d8b-47f3-8096-f205a92305f0-000000@email.amazonses.com> <0100017866b46da2-7ac1b1ae-03f2-4048-81f8-bd38fb59b99f-000000@email.amazonses.com> <010001786743a2ac-3d2da6df-c6f2-4e19-acaa-628ff7d466c2-000000@email.amazonses.com> <01000178b1570317-d1af5a40-d575-49ef-9b91-06abe8d04f4b-000000@email.amazonses.com> <010001793ebb08a4-29440b1d-778d-4a80-8def-619c2946e275-000000@email.amazonses.com> <010001796adacdd6-3f239ac5-27bb-4c79-a878-30592929b893-000000@email.amazonses.com> <0100017974aff4fb-0af45782-0b60-4724-b300-822f8fe4b799-000000@email.amazonses.com> <0100017982591630-15bf1d32-8f0b-4b2a-bb4d-a2ba39760820-000000@email.amazonses.com> <10CCF05B-96E6-4C92-942F-1B4C774A813E@arm.com> In-Reply-To: From: Simon Glass Date: Thu, 17 Jun 2021 13:37:50 -0600 Message-ID: Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages To: =?UTF-8?Q?Fran=C3=A7ois_Ozog?= Cc: Manish Pandey2 , Joanna Farley , Madhukar Pappireddy , Okash Khawaja , Harb Abdulhamid OS , Boot Architecture Mailman List , Ed Stuber , Arjun Khare , U-Boot Mailing List , "Paul Isaac's" , Ron Minnich , Moe Ammar , "tf-a@lists.trustedfirmware.org" X-Mailman-Approved-At: Thu, 17 Jun 2021 21:54:20 +0200 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean Hi, On Fri, 11 Jun 2021 at 05:52, Fran=C3=A7ois Ozog wrote: > > > On Thu, 10 Jun 2021 at 23:57, Manish Pandey2 > 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 { > u32 tag ; > u32 hdr_size ; > u32 size; > u32 spare ;}; > > enum bloblist_tag_t { > BLOBLISTT_NONE =3D 0, > > /* Vendor-specific tags are permitted here */ > BLOBLISTT_EC_HOSTEVENT , /* Chromium OS EC host-eve= nt mask */ > > We can give these each a value (=3D1, =3D2) so it is clear. > BLOBLISTT_SPL_HANDOFF , /* Hand-off info from SPL */ > BLOBLISTT_VBOOT_CTX , /* Chromium OS verified boot con= text */ > BLOBLISTT_VBOOT_HANDOFF , /* Chromium OS internal h= andoff info */ > /* * Advanced Configuration and Power Interface Global Non-Volatile * = Sleeping table. This forms part of the ACPI tables passed to Linux. */ > BLOBLISTT_ACPI_GNVS , > BLOBLISTT_INTEL_VBT , /* Intel Video-BIOS table */ > BLOBLISTT_TPM2_TCG_LOG , /* TPM v2 log space */ > BLOBLISTT_TCPA_LOG , /* TPM log space */ > BLOBLISTT_ACPI_TABLES , /* ACPI tables for x86 */ > BLOBLISTT_SMBIOS_TABLES , /* SMBIOS tables for x86 = */ > > How about: BLOBLISTT_LOCAL =3D 0xf0000000u /* values in this space are for local use during development */ > 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 ope= n. > 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 >> *Sent:* 02 June 2021 16:26 >> *To:* Madhukar Pappireddy ; Okash Khawaja < >> okash.khawaja@gmail.com>; Simon Glass >> *Cc:* Harb Abdulhamid OS ; Boot >> Architecture Mailman List ; Ed >> Stuber ; Arjun Khare < >> akhare@amperecomputing.com>; U-Boot Mailing List ; >> Paul Isaac's ; Ron Minnich = ; >> Moe Ammar ; tf-a@lists.trustedfirmware.org < >> tf-a@lists.trustedfirmware.org>; Manish Pandey2 >> *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 >> *Date: *Wednesday, 2 June 2021 at 15:29 >> *To: *Madhukar Pappireddy , Okash Khawaja < >> okash.khawaja@gmail.com>, Simon Glass >> *Cc: *Harb Abdulhamid OS , Boot >> Architecture Mailman List , Ed >> Stuber , Arjun Khare < >> akhare@amperecomputing.com>, U-Boot Mailing List , >> Paul Isaac's , Ron Minnich = , >> Moe Ammar >> *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 woul= d >> try to get consensus for Infra segment platform(to solve original proble= m >> 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: >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> >> >> TF-A Tech Forum >> >> When Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Tim= e >> >> Calendar tf-a@lists.trustedfirmware.org >> >> Who =E2=80=A2 Bill Fletcher- creator >> >> =E2=80=A2 tf-a@lists.trustedfirmware.org >> >> >> >> We run an open technical forum call for anyone to participate and it is >> not restricted to Trusted Firmware project members. It will operate unde= r >> 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 >> >> >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> >> >> Joanna >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On 19/05/2021, 03:50, "Madhukar Pappireddy" >> wrote: >> >> >> >> Attached slides presented by Manish in the TF-A tech forum. >> >> >> >> >> >> -----Original Message----- >> >> From: TF-A On Behalf Of >> Madhukar Pappireddy via TF-A >> >> Sent: Tuesday, May 18, 2021 8:59 PM >> >> To: Joanna Farley ; Okash Khawaja < >> okash.khawaja@gmail.com>; Simon Glass >> >> Cc: Harb Abdulhamid OS ; Boot >> Architecture Mailman List ; Ed >> Stuber ; Arjun Khare < >> akhare@amperecomputing.com>; U-Boot Mailing List ; >> tf-a@lists.trustedfirmware.org; Paul Isaac's ; >> Ron Minnich ; Moe Ammar >> >> 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 t= o >> 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 woul= d >> 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 bas= ed >> 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 o= r 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 ca= n >> either be a dtb or a HOB list which can be simply inferred by checking f= or >> 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 firmw= are >> config dtb, SoC config dtb, Non trusted firmware config dtb, memory layo= ut, >> 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 ema= il >> with more information about future TF-A tech forums that serves as a >> platform for further discussions. >> >> >> >> Thanks, >> >> Madhukar >> >> >> >> -----Original Message----- >> >> From: TF-A On Behalf Of >> Joanna Farley via TF-A >> >> Sent: Sunday, May 16, 2021 5:19 AM >> >> To: Okash Khawaja ; Simon Glass < >> sjg@chromium.org> >> >> Cc: Harb Abdulhamid OS ; Boot >> Architecture Mailman List ; >> tf-a@lists.trustedfirmware.org; Ed Stuber = ; >> Arjun Khare ; U-Boot Mailing List < >> u-boot@lists.denx.de>; Paul Isaac's ; Ron >> Minnich ; Moe Ammar >> >> 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 sessio= n >> which we hope to hold this Thursday. Invite and agenda will also be sent >> out early next week. >> >> >> >> Thanks >> >> >> >> Joanna >> >> >> >> On 14/05/2021, 13:30, "TF-A on behalf of Okash Khawaja via TF-A" < >> tf-a-bounces@lists.trustedfirmware.org on behalf of >> tf-a@lists.trustedfirmware.org> wrote: >> >> >> >> Hi, >> >> >> >> Do we have slides and video from last week's discussion? >> >> >> >> Thanks, >> >> Okash >> >> >> >> >> >> On Wed, May 5, 2021 at 11:52 PM Simon Glass via TF-A >> >> 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 t= he >> word 'standard' seems to be a synonym for UUIDs, UEFI, etc., i.e. >> enabling/preferring closed-source firmware and the continued decline of >> open-source projects. It really should not be. >> >> > >> >> > So I suggest: Use simple integer IDs and reserve some area for >> 'private' use. If you want to collaborate across projects outside your >> company, you either need to allocate a 'public' ID or agree privately >> between the parties which private ID to use. >> >> > >> >> > This means that the default and easiest option is for >> collaboration and a public ID, with private ones (whose purpose may be >> secret) reserved just for private use. >> >> > >> >> > Regards, >> >> > Simon >> >> > >> >> > On Wed, 5 May 2021 at 11:42, Harb Abdulhamid OS < >> abdulhamid@os.amperecomputing.com> wrote: >> >> >> >> >> >> Hey Folks, >> >> >> >> >> >> We wanted to put out a middle-ground proposal to help guide >> the discussion on the call tomorrow. >> >> >> >> >> >> >> >> >> >> >> >> A proposal that we have been discussing offline involves >> reserving a single tag ID for the purpose of construction UEFI PI HOB Li= st >> structure, and that tag would be used to identify a HOB-specific structu= re >> that does leverage UUID based identifier. This will eliminate the burde= n >> of having to support UUID as the tag, and this enables projects that >> require UUID based identifiers for the broad range of HOB structures tha= t >> 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/exte= nd >> the HOB list in TF-A code (or even pre-TF-A code), with a HOB consumer f= or >> that UUID/GUID on the other side (i.e. whatever the BL33 image is bootin= g >> 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 forwar= d >> to discuss this further on the call. >> >> >> >> >> >> >> >> >> >> >> >> Thanks, >> >> >> >> >> >> --Harb >> >> >> >> >> >> >> >> >> >> >> >> From: Manish Pandey2 >> >> >> Sent: Friday, April 30, 2021 8:14 AM >> >> >> To: Fran=C3=A7ois Ozog >> >> >> Cc: Simon Glass ; Julius Werner < >> jwerner@chromium.org>; Harb Abdulhamid OS < >> abdulhamid@os.amperecomputing.com>; Boot Architecture Mailman List < >> boot-architecture@lists.linaro.org>; tf-a@lists.trustedfirmware.org; >> U-Boot Mailing List ; Paul Isaac's < >> paul.isaacs@linaro.org>; Ron Minnich >> >> >> 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 =E2=80=93 17:00 (BST). >> >> >> >> >> >> >> >> >> >> >> >> Agenda: >> >> >> >> >> >> Discussion Session: Static and Dynamic Information Handling i= n >> TF-A >> >> >> >> >> >> Lead by Manish Pandey and Madhukar Pappireddy >> >> >> >> >> >> =C2=B7 There is ongoing mailing lists discussion[1] r= elated >> 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 co= ver >> 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 ca= n >> 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_0kl= gQnHTqzgA5Wav0qOO8n7SAM0yj-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@lists.trustedfirmware.org >> >> >> >> >> >> Who >> >> >> >> >> >> =E2=80=A2 >> >> >> >> >> >> Bill Fletcher- creator >> >> >> >> >> >> =E2=80=A2 >> >> >> >> >> >> tf-a@lists.trustedfirmware.org >> >> >> >> >> >> more details =C2=BB >> >> >> >> >> >> >> >> >> >> >> >> 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=C3=A7ois Ozog >> >> >> Sent: 08 April 2021 16:50 >> >> >> To: Manish Pandey2 >> >> >> Cc: Simon Glass ; Julius Werner < >> jwerner@chromium.org>; Harb Abdulhamid OS < >> abdulhamid@os.amperecomputing.com>; Boot Architecture Mailman List < >> boot-architecture@lists.linaro.org>; tf-a@lists.trustedfirmware.org < >> tf-a@lists.trustedfirmware.org>; U-Boot Mailing List < >> u-boot@lists.denx.de>; Paul Isaac's ; Ron >> Minnich >> >> >> 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_0kl= gQnHTqzgA5Wav0qOO8n7SAM0yj-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 visibl= e >> on the trusted-substrate.org page). >> >> >> >> >> >> >> >> >> >> >> >> I'll try to summarize what I learnt and highlight my view on >> what can be next steps in a future mail. >> >> >> >> >> >> >> >> >> >> >> >> Cheers >> >> >> >> >> >> >> >> >> >> >> >> FF >> >> >> >> >> >> >> >> >> >> >> >> On Thu, 8 Apr 2021 at 13:56, Manish Pandey2 via TF-A < >> tf-a@lists.trustedfirmware.org> wrote: >> >> >> >> >> >> Hi, >> >> >> >> >> >> >> >> >> >> >> >> From TF-A project point of view, we prefer to use existing >> mechanism to pass parameters across boot stages using linked list of tag= ged >> elements (as suggested by Julius). It has support for both generic and >> SiP-specific tags. Having said that, it does not stop partners to introd= uce >> 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 BL3= 3) >> by passing the head of list pointer in one of the registers. Initially a= ny >> register can be used but going forward a standardization will be needed. >> >> >> >> >> >> >> >> >> >> >> >> The U-boot bloblist mentioned by Simon is conceptually simila= r >> 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 implementati= ons. >> >> >> >> >> >> >> >> >> >> >> >> 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" wh= ich >> 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 on behalf >> of Julius Werner via TF-A >> >> >> Sent: 25 March 2021 02:43 >> >> >> To: Simon Glass >> >> >> Cc: Harb Abdulhamid OS ; >> Boot Architecture Mailman List ; >> tf-a@lists.trustedfirmware.org ; U-Boot >> Mailing List ; Paul Isaac's ; >> Ron Minnich >> >> >> 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 i= n >> 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 th= e >> passed-to firmware stage, particularly if the structure encodes informat= ion >> about the debug console (like it does for the platforms I mentioned abov= e). >> For example, in BL31 this basically means doing it right after moving fr= om >> assembly to C in bl31_early_platform_setup2() to get the console up befo= re >> 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 yo= u >> ideally have to touch every data word only once. >> >> >> >> >> >> >> >> >> >> >> >> On Wed, Mar 24, 2021 at 5:06 PM Simon Glass via TF-A < >> tf-a@lists.trustedfirmware.org> wrote: >> >> >> >> >> >> Hi Harb, >> >> >> >> >> >> >> >> >> >> >> >> On Wed, 24 Mar 2021 at 11:39, Harb Abdulhamid OS < >> abdulhamid@os.amperecomputing.com> wrote: >> >> >> >> >> >> Hello Folks, >> >> >> >> >> >> Appreciate the feedback and replies on this. Glad to see tha= t >> there is interest in this topic. >> >> >> >> >> >> >> >> >> >> >> >> I try to address the comments/feedback from Francois and Simo= n >> below=E2=80=A6. >> >> >> >> >> >> >> >> >> >> >> >> @Fran=C3=A7ois Ozog =E2=80=93 happy to discuss this on a zoom= call. I will >> make that time slot work, and will be available to attend April 8, 4pm C= T. >> >> >> >> >> >> >> >> >> >> >> >> Note that I=E2=80=99m using the term =E2=80=9CHOB=E2=80=9D he= re more generically, as >> there are typically vendor specific structures beyond the resource >> descriptor HOB, which provides only a small subset of the information th= at >> 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=E2=80=99s that support *any* B= L33 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 wit= h a >> TF-A that would be completely agnostic to the implementation of BL33 (i.= e. >> BL33 is built completely independently by a separate entity =E2=80=93 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 compilin= g >> firmware/software stacks like most folks in TF-A have become use to. Th= ere >> are two categories of higher level firmware code blobs in the >> server/datacenter model: >> >> >> >> >> >> =E2=80=9CSoC=E2=80=9D or =E2=80=9Csilicon=E2=80=9D firmware = =E2=80=93 in TF-A this may map to BL1, >> BL2, BL31, and *possibly* one or more BL32 instances >> >> >> =E2=80=9CPlatform=E2=80=9D or =E2=80=9Cboard=E2=80=9D firmwar= e =E2=80=93 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 =E2=80=93 this HOB struc= tures 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 =E2=80=93 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 f= or >> OS / RTOS software, and not necessarily suitable for firmware-to-firmwar= e >> hand-offs). >> >> >> >> >> >> >> >> >> >> >> >> Frankly, I would personally push back pretty hard on defining >> SMC=E2=80=99s for something that should be one way information passing. = Every SMC >> we add is another attack vector to the secure world and an increased bur= den >> on the folks that have to do security auditing and threat analysis. I s= ee >> 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 signatu= re) >> so that we can tie standardized data structures (based on some future TB= D >> 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 abou= t >> 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 i= t >> should switch from an auto-allocating enum to one with explicit values f= or >> each entry and a range for 'local' use. >> >> >> >> >> >> >> >> >> >> >> >> I guess we can achieve this with the tag, but the problem wit= h >> 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 s= ome >> 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 ar= e >> 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[] =3D { >> >> >> { 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 =3D 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/UUI= D >> or not during the call=E2=80=A6 but again, boblist seems like a reasonab= le starting >> point as an alternative to HOB. >> >> >> >> >> >> >> >> >> >> >> >> Indeed. There is certainly value in both approaches. >> >> >> >> >> >> >> >> >> >> >> >> Regards, >> >> >> >> >> >> Simon >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Thanks, >> >> >> >> >> >> --Harb >> >> >> >> >> >> >> >> >> >> >> >> From: Fran=C3=A7ois Ozog >> >> >> Sent: Tuesday, March 23, 2021 10:00 AM >> >> >> To: Fran=C3=A7ois Ozog ; Ron Minnic= h < >> rminnich@google.com>; Paul Isaac's >> >> >> Cc: Simon Glass ; Harb Abdulhamid OS < >> abdulhamid@os.amperecomputing.com>; Boot Architecture Mailman List < >> boot-architecture@lists.linaro.org>; tf-a@lists.trustedfirmware.org >> >> >> Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks >> (HOBs) for information passing between boot stages >> >> >> >> >> >> >> >> >> >> >> >> +Ron Minnich +Paul Isaac's >> >> >> >> >> >> >> >> >> >> >> >> Adding Ron and Paul because I think this interface should be >> also benefiting LinuxBoot efforts. >> >> >> >> >> >> >> >> >> >> >> >> On Tue, 23 Mar 2021 at 11:17, Fran=C3=A7ois Ozog via TF-A < >> tf-a@lists.trustedfirmware.org> wrote: >> >> >> >> >> >> Hi, >> >> >> >> >> >> >> >> >> >> >> >> I propose we cover the topic at the next Trusted Substrate >> zoom call on April 8th 4pm CET. >> >> >> >> >> >> >> >> >> >> >> >> The agenda: >> >> >> >> >> >> ABI between non-secure firmware and the rest of firmware (EL3= , >> S-EL1, S-EL2, SCP) to adapt hardware description to some runtime conditi= ons. >> >> >> >> >> >> runtime conditions here relates to DRAM size and topology >> detection, secure DRAM memory carvings, PSCI and SCMI interface publishi= ng. >> >> >> >> >> >> >> >> >> >> >> >> 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 platfo= rms >> 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 >> wrote: >> >> >> >> >> >> Hi, >> >> >> >> >> >> Can I suggest using bloblist for this instead? It is >> lightweight, >> >> >> easier to parse, doesn't have GUIDs and is already used withi= n >> 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=C3=A7ois Ozog < >> francois.ozog@linaro.org> wrote: >> >> >> > >> >> >> > +Boot Architecture Mailman List < >> boot-architecture@lists.linaro.org> >> >> >> > >> >> >> > standardization is very much welcomed here and need to >> accommodate a very >> >> >> > diverse set of situations. >> >> >> > For example, TEE OS may need to pass memory reservations to >> BL33 or >> >> >> > "capture" a device for the secure world. >> >> >> > >> >> >> > I have observed a number of architectures: >> >> >> > 1) pass information from BLx to BLy in the form of a >> specific object >> >> >> > 2) BLx called by BLy by a platform specific SMC to get >> information >> >> >> > 3) BLx called by BLy by a platform specific SMC to perform >> Device Tree >> >> >> > fixups >> >> >> > >> >> >> > I also imagined a standardized "broadcast" FF-A call so tha= t >> 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 | >> >> >> > > table or DT >> >> >> > equivalent?> >> >> >> > PSCI | SCP | >> TFA? | >> >> >> > SCMI | SCP or TEE-OS | TFA? TEE-OS?| >> >> >> > secure SRAM | TFA. | TFA. >> | >> >> >> > secure DRAM | TFA? TEE-OS? | TFA? TEE-OS? | >> >> >> > other? | | >> >> >> > | >> >> >> > >> >> >> > Cheers >> >> >> > >> >> >> > FF >> >> >> > >> >> >> > >> >> >> > On Mon, 22 Mar 2021 at 09:34, Harb Abdulhamid OS via TF-A < >> >> >> > tf-a@lists.trustedfirmware.org> wrote: >> >> >> > >> >> >> > > Hello Folks, >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > I'm emailing to start an open discussion about the >> adoption of a concept >> >> >> > > known as "hand-off blocks" or HOB to become a part of the >> TF-A Firmware >> >> >> > > Framework Architecture (FFA). This is something that is = a >> pretty major >> >> >> > > pain point when it comes to the adoption of TF-A in ARM >> Server SoC=E2=80=99s >> >> >> > > 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 HO= B >> 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 o= n >> 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 highl= y >> configurable >> >> >> > > systems that must rely on flexible discovery mechanisms t= o >> initialize and >> >> >> > > boot the system. This is especially helpful when you hav= e >> 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 tre= e >> 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 rang= e >> DIMM memory >> >> >> > > population/topologies, all the necessary information >> required to boot is >> >> >> > > fully discovered via standard JEDEC Serial Presence Detec= t >> (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 operatin= g >> 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 a= n >> 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 o= n >> this being a >> >> >> > > useful mechanism used to pass information between each >> boot stage. >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > Thanks, >> >> >> > > >> >> >> > > --Harb >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > -- >> >> >> > > TF-A mailing list >> >> >> > > TF-A@lists.trustedfirmware.org >> >> >> > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a >> >> >> > > >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > Fran=C3=A7ois-Fr=C3=A9d=C3=A9ric Ozog | *Director Linaro Ed= ge & Fog >> Computing Group* >> >> >> > T: +33.67221.6485 >> >> >> > francois.ozog@linaro.org | Skype: ffozog >> >> >> > _______________________________________________ >> >> >> > boot-architecture mailing list >> >> >> > boot-architecture@lists.linaro.org >> >> >> > https://lists.linaro.org/mailman/listinfo/boot-architecture >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> >> >> Fran=C3=A7ois-Fr=C3=A9d=C3=A9ric Ozog | Director Linaro Edge = & Fog Computing >> Group >> >> >> >> >> >> T: +33.67221.6485 >> >> >> francois.ozog@linaro.org | Skype: ffozog >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> TF-A mailing list >> >> >> TF-A@lists.trustedfirmware.org >> >> >> https://lists.trustedfirmware.org/mailman/listinfo/tf-a >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> >> >> Fran=C3=A7ois-Fr=C3=A9d=C3=A9ric Ozog | Director Linaro Edge = & Fog Computing >> Group >> >> >> >> >> >> T: +33.67221.6485 >> >> >> francois.ozog@linaro.org | Skype: ffozog >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> TF-A mailing list >> >> >> TF-A@lists.trustedfirmware.org >> >> >> https://lists.trustedfirmware.org/mailman/listinfo/tf-a >> >> >> >> >> >> -- >> >> >> TF-A mailing list >> >> >> TF-A@lists.trustedfirmware.org >> >> >> https://lists.trustedfirmware.org/mailman/listinfo/tf-a >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> >> >> Fran=C3=A7ois-Fr=C3=A9d=C3=A9ric Ozog | Director Linaro Edge = & Fog Computing >> Group >> >> >> >> >> >> T: +33.67221.6485 >> >> >> francois.ozog@linaro.org | Skype: ffozog >> >> >> >> >> >> >> >> > >> >> > -- >> >> > TF-A mailing list >> >> > TF-A@lists.trustedfirmware.org >> >> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a >> >> -- >> >> TF-A mailing list >> >> TF-A@lists.trustedfirmware.org >> >> https://lists.trustedfirmware.org/mailman/listinfo/tf-a >> >> >> >> -- >> >> TF-A mailing list >> >> TF-A@lists.trustedfirmware.org >> >> https://lists.trustedfirmware.org/mailman/listinfo/tf-a >> >> -- >> >> TF-A mailing list >> >> TF-A@lists.trustedfirmware.org >> >> https://lists.trustedfirmware.org/mailman/listinfo/tf-a >> > > > -- > Fran=C3=A7ois-Fr=C3=A9d=C3=A9ric Ozog | *Director Linaro Edge & Fog Compu= ting Group* > T: +33.67221.6485 > francois.ozog@linaro.org | Skype: ffozog > >