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=-6.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,LOTS_OF_MONEY,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,MONEY_NOHTML,SPF_HELO_NONE,SPF_PASS autolearn=no 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 C9D40C48BD1 for ; Fri, 11 Jun 2021 17:53:32 +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 792AE613D3 for ; Fri, 11 Jun 2021 17:53:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 792AE613D3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.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 38D5380772; Fri, 11 Jun 2021 19:53:29 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=linaro.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" (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="kxkog/LT"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 69EAD8031F; Fri, 11 Jun 2021 13:52:21 +0200 (CEST) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 40C6E800A5 for ; Fri, 11 Jun 2021 13:52:10 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=francois.ozog@linaro.org Received: by mail-lj1-x22e.google.com with SMTP id d2so9223136ljj.11 for ; Fri, 11 Jun 2021 04:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CXUKqIikxJvZm8fr7kUdBhObE2LyaEesWBOoY/5uURE=; b=kxkog/LTS6mLFjGCjF2w3KtMAPeKtDZ1hku0xabfii5Jg3K8p8IsdpNhDrS+hFvnIA aAJMaGS4YM9phCIWeSFNTfHVCSwyijKwypR/csvldRDweDZ+gR+AaUcX9ImKPjFKpSxi q1IaIeMlBKew20m7mijvTH5a68HySolTDHQTatfaPHMXYZ4rET6InTLDOSI/uKzCZjU3 oIvCgntfOPBr9JkgZr0PTb55/i+OllUSYkE750zXGa6AOrsyV52tozPFs3YTVIAqYprN uvfg/J89YvasoZDdZIRQWiL0b5S9v0LQ1ROmTHJEGDUS2gdQPbdeFSRMKQRSuN0iurWB 9xsQ== 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=CXUKqIikxJvZm8fr7kUdBhObE2LyaEesWBOoY/5uURE=; b=imTSOpYX04SGYvvnF/2/HoEEM4gSvY9fKX31D5CD9GBnTNYcDj7vLE23ECprhG1ane +HAR5B2Ji2eeiPX7FEmbtwxg6N1DyVj447Hy4vLLhPf7ZT7MTEpnfbqDHrwgQwOfor3S kKJyoua3quYln4NMevWK+WA7OPQRar5BDebuFBfzbYkuaKS8dykpZw1I+MPdg0Dr1dDw G3lGmr4JxBn26snWarHOHKH+T24Qfu7FeGOxA+2VDe+ginS0JD+tqkCYY9O8m/PDOFlC ZB4NF4n39ISa/t32TkdSmPH6NRynzO/b0kDMLQBkoCH5/GjeALDmsBPKtEkD7TitqpFF IyhQ== X-Gm-Message-State: AOAM533nLBCzOPaIoJ7IxbR/TJ6MkpOudEKoDgC2idPJKgHqhVXxuhhR MN8J1GvoSoS++4D7S/RCZEzSBfQ67zKz+ZXH/5cK1g== X-Google-Smtp-Source: ABdhPJyhAWHqCQTDf4L8Egfk5IlaF7sjdheH7ggmBrC8U/8Z9ht75nKAREoAC9D/INvnP2OESs3eboNGR5QlJp4glgA= X-Received: by 2002:a05:651c:150a:: with SMTP id e10mr2815968ljf.215.1623412328968; Fri, 11 Jun 2021 04:52:08 -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: =?UTF-8?Q?Fran=C3=A7ois_Ozog?= Date: Fri, 11 Jun 2021 13:51:56 +0200 Message-ID: Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages To: Manish Pandey2 Cc: Joanna Farley , Madhukar Pappireddy , Okash Khawaja , Simon Glass , 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: Fri, 11 Jun 2021 19:53:28 +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 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 project= s > 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 o= n > the discussions following design came up as most acceptable solution > > - Use list of pre-defined C data structures(blobs) to pass > information, let's call it bloblist > - Only bootloaders stages will participate > - Blobs will be identified by either tags or UUIDs > - Pass pointer to the bloblist head through x0 > - Existing usage of x0 will be translated into a blob > > After all discussions, I now support Simon proposal to use existing bloblist: it does the job, is already upstream in key projects (core boot, U-Boot), is supported on x86 and Arm. I would think of a few additions on the bloblist_rec: struct bloblist_rec { 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-event mask */ BLOBLISTT_SPL_HANDOFF , /* Hand-off info from SPL */ BLOBLISTT_VBOOT_CTX , /* Chromium OS verified boot context */ BLOBLISTT_VBOOT_HANDOFF , /* Chromium OS internal handoff info */ /* * Advanced Configuration and Power Interface Global Non-Volatile=09 * Sleeping table. This forms part of the ACPI tables passed to Linux.=09 */ 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 */ BLOBLISTT_COUNT }; I would add a BLOBLISTT_UUID for all proprietary things that people want to add. Using private space in a 64 bit field does not make the thing open. So by using this tag, we know exactly the nature of the blob. Negotiating for adding a new tag is a good open governance process. We may have to deal with super small SRAM (256KB) and thus we can assume the bloblist will be a single region of blobs. So I would add a BLOBLISTT_CONTINUATION which would be a pointer from the SRAM bloblist to a DRAM backed bloblist. Other tags to consider: PSCI interface details, DRAM information, SCMI stuff, Secure SRAM and DRAM information... > - Going forward we would provide core changes to demonstrate this > design on various TF-A boundries, BL1<->BL2, BL2<->BL31 and > BL31<->BL33(only BL31 part) > > > Please share your thoughts if you disagree to the proposed solution. > > Also, refer to attached slide deck which was presented during last tech > forum session on 3rd june, it also captures the points discussed during > meeting and next steps for implementing it in TF-A. > > Thanks > Manish Pandey > ------------------------------ > *From:* Joanna Farley > *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 ; > U-Boot Mailing List ; Paul Isaac's < > paul.isaacs@linaro.org>; Ron Minnich ; Moe Ammar < > moe@amperecomputing.com>; 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 , > U-Boot Mailing List , Paul Isaac's < > paul.isaacs@linaro.org>, Ron Minnich , Moe Ammar < > moe@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 t= o > host another TF-A Tech Forum this Thursday to continue the live discussio= n. > > > > Here is their agenda: > > On tech forum this week, we would like to continue discussions on HOB lis= t > design. > > The topics which we would like to cover is > > 1. Evaluate different proposals of passing information through boot phase= s. > > 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: > > > > =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 Time > > 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 under > the guidance of the TF TSC. > > > > Feel free to forward this invite to colleagues. Invites are via the TF-A > mailing list and also published on the Trusted Firmware website. Details > are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ > > > > Trusted Firmware is inviting you to a scheduled Zoom meeting. > > > > Join Zoom Meeting > > https://zoom.us/j/9159704974 > > > > Meeting ID: 915 970 4974 > > > > One tap mobile > > +16465588656,,9159704974# US (New York) > > +16699009128,,9159704974# US (San Jose) > > > > Dial by your location > > +1 646 558 8656 US (New York) > > +1 669 900 9128 US (San Jose) > > 877 853 5247 US Toll-free > > 888 788 0099 US Toll-free > > Meeting ID: 915 970 4974 > > Find your local number: https://zoom.us/u/ad27hc6t7h > > > > > > =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 ; > U-Boot Mailing List ; tf-a@lists.trustedfirmware.or= g; > Paul Isaac's ; Ron Minnich ; > Moe Ammar > > Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) fo= r > 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 whethe= r > tags would suffice or if the HOB list producer and consumer would depend = on > UUID/GUIDs for identifying a specific HOB structure. Another suggestion w= as > to use a hybrid approach. Reserve a single tag ID for > identifying/constructing a HOB structure that further leverages UUID base= d > 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 fo= r > 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 firmwa= re > config dtb, SoC config dtb, Non trusted firmware config dtb, memory layou= t, > 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 emai= l > 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) fo= r > 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@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 benefi= t > 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@os.amperecomputing.com> wrote: > > >> > > >> Hey Folks, > > >> > > >> We wanted to put out a middle-ground proposal to help guide th= e > 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 Lis= t > structure, and that tag would be used to identify a HOB-specific structur= e > 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 t= ag > for a HOB list, this will enable various HOB producers that can add/exten= d > the HOB list in TF-A code (or even pre-TF-A code), with a HOB consumer fo= r > 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 > > >> 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 continu= e > 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 in > TF-A > > >> > > >> Lead by Manish Pandey and Madhukar Pappireddy > > >> > > >> =C2=B7 There is ongoing mailing lists discussion[1] re= lated > 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 discussio= n > on dynamic information passing and if time permits, we can cover static > information passing. The purpose of the call is to have an open discussio= n > and continue the discussion from the trusted-substrate call[2] done > earlier. We would like to understand the various requirements and possibl= e > ways to implement it in TF-A in a generalized way so that it can work wit= h > 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_0klg= QnHTqzgA5Wav0qOO8n7SAM0yj-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 vi= a > the TF-A mailing list and also published on the Trusted Firmware website. > Details are here: > https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ > > >> > > >> > > >> > > >> Trusted Firmware is inviting you to a scheduled Zoom meeting. > > >> > > >> > > >> > > >> Join Zoom Meeting > > >> > > >> https://zoom.us/j/9159704974 > > >> > > >> > > >> > > >> Meeting ID: 915 970 4974 > > >> > > >> > > >> > > >> One tap mobile > > >> > > >> +16465588656,,9159704974# US (New York) > > >> > > >> +16699009128,,9159704974# US (San Jose) > > >> > > >> > > >> > > >> Dial by your location > > >> > > >> +1 646 558 8656 US (New York) > > >> > > >> +1 669 900 9128 US (San Jose) > > >> > > >> 877 853 5247 US Toll-free > > >> > > >> 888 788 0099 US Toll-free > > >> > > >> Meeting ID: 915 970 4974 > > >> > > >> Find your local number: https://zoom.us/u/ad27hc6t7h > > >> > > >> > > >> > > >> ________________________________ > > >> > > >> From: Fran=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 ; > 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_0klg= QnHTqzgA5Wav0qOO8n7SAM0yj-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@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 tagg= ed > elements (as suggested by Julius). It has support for both generic and > SiP-specific tags. Having said that, it does not stop partners to introdu= ce > 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 an= y > 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 implementatio= ns. > > >> > > >> > > >> > > >> 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" whi= ch > intended to be used by other projects.) > > >> > > >> > > >> > > >> Regarding usage of either UUID or tag, I echo the sentiments o= f > 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 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 informati= on > 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 fro= m > assembly to C in bl31_early_platform_setup2() to get the console up befor= e > 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@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 that > there is interest in this topic. > > >> > > >> > > >> > > >> I try to address the comments/feedback from Francois and Simon > 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 CT= . > > >> > > >> > > >> > > >> Note that I=E2=80=99m using the term =E2=80=9CHOB=E2=80=9D her= e more generically, as > there are typically vendor specific structures beyond the resource > descriptor HOB, which provides only a small subset of the information tha= t > 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* BL= 33 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 =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 compiling > firmware/software stacks like most folks in TF-A have become use to. The= re > 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 firmware= =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 b= y > 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 rang= e > 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 struct= ures 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 j= ust 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 spec= s > with what we are doing here, because those specs and concepts were > developed for a completely different purpose (i.e. abstractions needed fo= r > OS / RTOS software, and not necessarily suitable for firmware-to-firmware > 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 burd= en > on the folks that have to do security auditing and threat analysis. I se= e > 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 t= o > 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 signatur= e) > so that we can tie standardized data structures (based on some future TBD > specs) to a particular ID. For example, if the TPM driver in BL33 is > looking for the TPM structure in the HOB/BOB list, and may not care about > the other data blobs. The driver needs a way to identify and locate the > blob it cares about. > > >> > > >> > > >> > > >> The tag is intended to serve that purpose, although perhaps it > should switch from an auto-allocating enum to one with explicit values fo= r > each entry and a range for 'local' use. > > >> > > >> > > >> > > >> I guess we can achieve this with the tag, but the problem with > tag when you have eco-system with a lot of parties doing parallel > development, you can end up with tag collisions and folks fighting about > who has rights to what tag values. We would need some official process f= or > folks to register tags for whatever new structures we define, or maybe so= me > 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 i= t > easy to just define your own blobs with *either* standard or vendor > specific structures without worry of ID collisions between vendors. > > >> > > >> > > >> > > >> True. I think the pain is overstated, though. In this case I > think we actually want something that can be shared between projects and > orgs, so some amount of coordination could be considered a benefit. It > could just be a github pull request. I find the UUID unfriendly and not > just to code size and eyesight! Trying to discover what GUIDs mean or are > valid is quite tricky. E.g. see this code: > > >> > > >> > > >> > > >> #define FSP_HOB_RESOURCE_OWNER_TSEG_GUID \ > > >> EFI_GUID(0xd038747c, 0xd00c, 0x4980, \ > > >> 0xb3, 0x19, 0x49, 0x01, 0x99, 0xa4, 0x7d, 0x55) > > >> > > >> (etc.) > > >> > > >> > > >> > > >> static struct guid_name { > > >> efi_guid_t guid; > > >> const char *name; > > >> } guid_name[] =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/UUID > or not during the call=E2=80=A6 but again, boblist seems like a reasonabl= e 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 Minnich= < > 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 conditio= ns. > > >> > > >> runtime conditions here relates to DRAM size and topology > detection, secure DRAM memory carvings, PSCI and SCMI interface publishin= g. > > >> > > >> > > >> > > >> 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 platfor= ms > 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 within > U-Boot > > >> for passing info between SPL/U-Boot, etc. > > >> > > >> Docs here: > https://github.com/u-boot/u-boot/blob/master/doc/README.bloblist > > >> Header file describes the format: > > >> https://github.com/u-boot/u-boot/blob/master/include/bloblist.= h > > >> > > >> Full set of unit tests: > > >> https://github.com/u-boot/u-boot/blob/master/test/bloblist.c > > >> > > >> Regards, > > >> Simon > > >> > > >> On Mon, 22 Mar 2021 at 23:58, Fran=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 specifi= c > object > > >> > 2) BLx called by BLy by a platform specific SMC to get > information > > >> > 3) BLx called by BLy by a platform specific SMC to perform > Device Tree > > >> > fixups > > >> > > > >> > I also imagined a standardized "broadcast" FF-A call so that > any firmware > > >> > element can either provide information or "do something". > > >> > > > >> > My understanding of your proposal is about standardizing on > architecture 1) > > >> > with the HOB format. > > >> > > > >> > The advantage of the HOB is simplicity but it may be > difficult to implement > > >> > schemes such as pruning a DT because device assignment in th= e > 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 | > > >> > 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 adoptio= n > 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 HOB > may be used for > > >> > > transitioning between the PEI and DXE boot phases, which i= s > 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 simpl= y > passed one time > > >> > > during boot). > > >> > > > > >> > > > > >> > > > > >> > > There may be one or more HOBs passed in between boot > phases. If there are > > >> > > more than one HOB that needs to be passed, this can be in = a > form of a "HOB > > >> > > table", which (for example) could be a UUID indexed array > of pointers to > > >> > > HOB structures, used to locate a HOB of interest (based on > UUID). In such > > >> > > cases, instead of passing a single HOB, the boot phases ma= y > rely on passing > > >> > > the pointer to the HOB table. > > >> > > > > >> > > > > >> > > > > >> > > This has been extremely useful concept to employ on highly > configurable > > >> > > systems that must rely on flexible discovery mechanisms to > initialize and > > >> > > boot the system. This is especially helpful when you have > multiple > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > Why do we need HOBs in TF-A?: > > >> > > > > >> > > ----------------------------- > > >> > > > > >> > > It is desirable that EL3 firmware (e.g. TF-A) built for AR= M > Server SoC in > > >> > > a way that is SoC specific *but* platform agnostic. This > means that a > > >> > > single ARM SoC that a SiP may deliver to customers may > provide a single > > >> > > TF-A binary (e.g. BL1, BL2, BL31) that could be used to > support a broad > > >> > > range of platform designs and configurations in order to > boot a platform > > >> > > specific firmware (e.g. BL33 and possibly even BL32 code). > In order to > > >> > > achieve this, the platform configuration must be > *discovered* instead of > > >> > > statically compiled as it is today in TF-A via device tree > based > > >> > > enumeration. The mechanisms of discovery may differ > broadly depending on > > >> > > the relevant industry standard, or in some cases may have > rely on SiP > > >> > > specific discovery flows. > > >> > > > > >> > > > > >> > > > > >> > > For example: On server systems that support a broad range > DIMM memory > > >> > > population/topologies, all the necessary information > required to boot is > > >> > > fully discovered via standard JEDEC Serial Presence Detect > (SPD) over an > > >> > > I2C bus. Leveraging the SPD bus, may platform variants > could be supported > > >> > > with a single TF-A binary. Not only is this information > required to > > >> > > initialize memory in early boot phases (e.g. BL2), the > subsequent boot > > >> > > phases will also need this SPD info to construct a system > physical address > > >> > > map and properly initialize the MMU based on the memory > present, and where > > >> > > the memory may be present. Subsequent boot phases (e.g. > BL33 / UEFI) may > > >> > > need to generate standard firmware tables to the operating > systems, such as > > >> > > SMBIOS tables describing DIMM topology and various ACPI > tables (e.g. SLIT, > > >> > > SRAT, even NFIT if NVDIMM's are present). > > >> > > > > >> > > > > >> > > > > >> > > In short, it all starts with a standardized or vendor > specific discovery > > >> > > flow in an early boot stage (e.g. BL1/BL2), followed by th= e > passing of > > >> > > information to the next boot stages (e.g. BL31/BL32/BL33). > > >> > > > > >> > > > > >> > > > > >> > > Today, every HOB may be a vendor specific structure, but i= n > the future > > >> > > there may be benefit of defining standard HOBs. This may > be useful for > > >> > > memory discovery, passing the system physical address map, > enabling TPM > > >> > > measured boot, and potentially many other common HOB > use-cases. > > >> > > > > >> > > > > >> > > > > >> > > It would be extremely beneficial to the datacenter market > segment if the > > >> > > TF-A community would adopt this concept of information > passing between all > > >> > > boot phases as opposed to rely solely on device tree > enumeration. This is > > >> > > not intended to replace device tree, rather intended as an > alternative way > > >> > > to describe the info that must be discovered and > dynamically generated. > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > Conclusion: > > >> > > > > >> > > ----------- > > >> > > > > >> > > We are proposing that the TF-A community begin pursuing th= e > adoption of > > >> > > HOBs as a mechanism used for information exchange between > each boot stage > > >> > > (e.g. BL1->BL2, BL2->BL31, BL31->BL32, and BL31->BL33)? > Longer term we > > >> > > want to explore standardizing some HOB structures for the > BL33 phase (e.g. > > >> > > UEFI HOB structures), but initially would like to agree on > this being a > > >> > > useful mechanism used to pass information between each boo= t > 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 Edg= e & 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 > --=20 Fran=C3=A7ois-Fr=C3=A9d=C3=A9ric Ozog | *Director Linaro Edge & Fog Computi= ng Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog