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=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 B6FF6C2B9F4 for ; Thu, 17 Jun 2021 19:54:38 +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 8B30061004 for ; Thu, 17 Jun 2021 19:54:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8B30061004 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 ECD3B82AE4; Thu, 17 Jun 2021 21:54:25 +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="TKePBLs9"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 01142801DE; Thu, 17 Jun 2021 21:47:35 +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 9A9CF801DE for ; Thu, 17 Jun 2021 21:47:24 +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 g13so305207ljj.10 for ; Thu, 17 Jun 2021 12:47:24 -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=U9NKNoZ3S9EntObrISvKVg/nxn+26kmnJm2Lyj0ZtlQ=; b=TKePBLs9Y2mnU8JTgE9q6MDjPMGq7DYRQUl9tpdkLB0He15uTxNnCWqHK3kZgE5iXF vgM6hBVCd2F13hX986PFz+dLjTDayZbRRX8dDx8FFl4Zop7iN43buajWAu92+sfXQM+a ULOjbifG+bZH76DYovfFCYCcEDWyCEPWRPxo9+YF/T2izJchlET6tHQwCwR4pyWik0bF JkXMVAeRb/e1e+KsY1D0/7W0mFLJpVMGY1obJZtzCfJX2ekOJIrAbHWHEYfOdNIfldIR fyH9rp4suhEk0mq/QcIFvGOjYXN/aro5VEpC71r3mTITuzCZZf93vm0eT7K9z2RSl0LL 82Vw== 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=U9NKNoZ3S9EntObrISvKVg/nxn+26kmnJm2Lyj0ZtlQ=; b=WHwezbSs81/kZyald6zHofGqwEnwaHa2tsl0hYY2L/9psxccaOS9yQwLgZHkVBhOp/ KnAa3m/ekcz03EkHCA8+AAOstapiaxAJxbjbpS7VOXDInHVYWZx8CHqL3tpRJ4ai/Lwx 0Vvo9xE/lJZ2zGXX+fZHHFa4I4WVBCWWSSchWaABE37WkQCPqNDxmyAgLKfa3Y7Z7Ly8 j93deZ2jHwo6Vzgriw6YmWhGoRDsGJRVdBnqJRMw4IeT6UiZUlK7TcPnFtxBCM615Qmm m48YeLvJJk1dVwCSkvvQoHLbC7U282UVezctRiKhTFDk9FEb7JLNELJ8nDVI2BSygTje 3YGg== X-Gm-Message-State: AOAM532uzQRJiLDL2uelKqghlcZd/68jsLgM8U0dSvk0D37Xiv2rdJBQ OwgehUG7wEt0SvDOii2ijspAi3qvHOuHXi62Nq239Q== X-Google-Smtp-Source: ABdhPJypFh7mPvor9eftrlOVGqWn0k4FX8kgcIe5RuG0SfUQfGbcjakY8OXPMXpPyL0VXHx8K2qAzCNJGdiwC+IteZE= X-Received: by 2002:a2e:380b:: with SMTP id f11mr6237628lja.269.1623959243349; Thu, 17 Jun 2021 12:47:23 -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: Thu, 17 Jun 2021 21:47:11 +0200 Message-ID: Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages To: Simon Glass Cc: Arjun Khare , Boot Architecture Mailman List , Ed Stuber , Harb Abdulhamid OS , Joanna Farley , Madhukar Pappireddy , Manish Pandey2 , Moe Ammar , Okash Khawaja , "Paul Isaac's" , Ron Minnich , U-Boot Mailing List , "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 Le jeu. 17 juin 2021 =C3=A0 21:38, Simon Glass a =C3=A9c= rit : > 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 com= e 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 passin= g > 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 boo= t, >> 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-ev= ent 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 co= ntext */ >> BLOBLISTT_VBOOT_HANDOFF , /* Chromium OS internal = handoff info */ >> /* * Advanced Configuration and Power Interface Global Non-Volatile *= Sleeping table. This forms part of the ACPI tables passed to Linux. */ >> BLOBLISTT_ACPI_GNVS , >> 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 u= se > 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 op= en. >> So by using this tag, we know exactly the nature of the blob. Negotiatin= g >> 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 t= o a >> DRAM backed bloblist. >> > > It is possible to relocate a bloblist, so I wonder if another approach > would be to allow the bloblist to grow as it progresses through the boot > (e.g. once SDRAM is available). That is what U-Boot does and it makes the > code simpler (although only very slightly). However, it does introduce > copying overhead...? > looks good: just making the problem. > > >> >> Other tags to consider: PSCI interface details, DRAM information, SCMI >> stuff, Secure SRAM and DRAM information... >> >> >> >>> - Going forward we would provide core changes to demonstrate this >>> design on various TF-A boundries, BL1<->BL2, BL2<->BL31 and >>> BL31<->BL33(only BL31 part) >>> >>> >>> Please share your thoughts if you disagree to the proposed solution. >>> >>> Also, refer to attached slide deck which was presented during last tech >>> forum session on 3rd june, it also captures the points discussed during >>> meeting and next steps for implementing it in TF-A. >>> >> > Re devicetree, how about we use bloblist for simple things, but use a > devicetree (perhaps in the bloblist) once SDRAM is available. Blobs that > were created pre-SDRAM can continue to be passed on, but anything created > after SDRAM is available should use devicetree? This would ensure that > complex structures use devicetree rather than C structs, which are of > course harder to extend / describe. > +1 > > Regards, > Simon > > >> >>> Thanks >>> Manish Pandey >>> ------------------------------ >>> *From:* Joanna Farley >>> *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 >>> 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 Ti= me >>> >>> 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 und= er >>> 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. Detail= s >>> 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 foru= m >>> 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 misse= d >>> 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 o= f >>> a chain of blobs(built as a linked list of C structure objects i.e., HO= B >>> 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 bloblis= t 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 wou= ld >>> 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 ba= sed >>> identifier. This way, the generic HOB list doesn't need to support UUID= s >>> 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 configuratio= n >>> 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 an= d >>> 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 c= an >>> either be a dtb or a HOB list which can be simply inferred by checking = for >>> a magic header that indicates if the buffer appears to be a flattened >>> device tree. >>> >>> > One another concern that was brought up offline is to mak= e >>> sure we don't break current design contracts between various boot loade= r >>> phases in TF-A. Many of the general-purpose registers have a designated >>> purpose such as to share configurations between BL images( such as firm= ware >>> config dtb, SoC config dtb, Non trusted firmware config dtb, memory lay= out, >>> entry point info, etc.). >>> >>> >>> >>> If I am not mistaken, a single design may not fit the needs of ever= y >>> segment(client, Infra, embedded) and the forum is open to solutions >>> tailored for individual segments. Joanna will be sending a follow up em= ail >>> 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 earl= y >>> next week with the slides and some notes to help with a follow up sessi= on >>> which we hope to hold this Thursday. Invite and agenda will also be sen= t >>> 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 = 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 fo= r >>> '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 L= ist >>> structure, and that tag would be used to identify a HOB-specific struct= ure >>> that does leverage UUID based identifier. This will eliminate the burd= en >>> of having to support UUID as the tag, and this enables projects that >>> require UUID based identifiers for the broad range of HOB structures th= at >>> 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/ext= end >>> the HOB list in TF-A code (or even pre-TF-A code), with a HOB consumer = for >>> that UUID/GUID on the other side (i.e. whatever the BL33 image is booti= ng >>> on that platform). >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> Essentially, the idea is if someone would like to support HO= B >>> 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 >>> 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 >>> in TF-A >>> >>> >> >>> >>> >> Lead by Manish Pandey and Madhukar Pappireddy >>> >>> >> >>> >>> >> =C2=B7 There is ongoing mailing lists discussion[1] >>> related with adopting a mechanism to pass information through boot stag= es. >>> >>> >> >>> >>> >> 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 c= over >>> 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 c= an >>> 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 bloblis= t >>> implementation, which uses tag values. Question, can this be enhanced t= o >>> use hybrid values(Tag and UUID) both? >>> >>> >> >>> >>> >> 2. Standardization on Physical register use to pass bas= e >>> 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_0k= lgQnHTqzgA5Wav0qOO8n7SAM0yj-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 participat= e >>> 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_0k= lgQnHTqzgA5Wav0qOO8n7SAM0yj-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 visib= le >>> 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 ta= gged >>> elements (as suggested by Julius). It has support for both generic and >>> SiP-specific tags. Having said that, it does not stop partners to intro= duce >>> new mechanisms suitable for their usecase in platform port initially an= d >>> 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 BL= 33) >>> by passing the head of list pointer in one of the registers. Initially = any >>> register can be used but going forward a standardization will be needed= . >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> The U-boot bloblist mentioned by Simon is conceptually >>> similar to what TF-A is using, if there is consensus of using >>> bloblist/taglist then TF-A tag list may be enhanced to take best of bot= h >>> the implementations. >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> One of the potential problems of having structure used in >>> different projects is maintainability, this can be avoided by having a >>> single copy of these structures in TF-A (kept inside "include/export" w= hich >>> 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 < >>> 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 >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> 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-firmwar= e-a/+/refs/heads/master/include/export/lib/bl_aux_params/bl_aux_params_exp.= h >>> >>> >> >>> >>> >> >>> https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmwar= e-a/+/refs/heads/master/lib/bl_aux_params/bl_aux_params.c >>> >>> >> >>> >>> >> >>> https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmwar= e-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 UUID= s. >>> You usually want to parse something like this as early as possible in t= he >>> passed-to firmware stage, particularly if the structure encodes informa= tion >>> about the debug console (like it does for the platforms I mentioned abo= ve). >>> For example, in BL31 this basically means doing it right after moving f= rom >>> assembly to C in bl31_early_platform_setup2() to get the console up bef= ore >>> running anything else. At that point in the BL31 initialization, the MM= U >>> 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 y= ou >>> 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 zoo= m 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 h= ere more generically, as >>> there are typically vendor specific structures beyond the resource >>> descriptor HOB, which provides only a small subset of the information t= hat >>> 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* = BL33 payload >>> (e.g. EDK2, AptioV, CoreBoot, and maybe even directly boot strapping >>> LinuxBoot at some point). In other-words, we are trying to come up wi= th 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 compili= ng >>> firmware/software stacks like most folks in TF-A have become use to. T= here >>> 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 firmwa= re =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 stru= ctures 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. JED= EC >>> 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 wer= e >>> developed for a completely different purpose (i.e. abstractions needed = for >>> OS / RTOS software, and not necessarily suitable for firmware-to-firmwa= re >>> hand-offs). >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> Frankly, I would personally push back pretty hard on definin= g >>> 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 bu= rden >>> on the folks that have to do security auditing and threat analysis. I = see >>> no benefit in exposing these boot/HOB/BOB structures at run-time via SM= C >>> calls. >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> Please do let me know if you disagree and why. Look forward >>> to discussing on this thread or on the call. >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> @Simon Glass - Thanks for the pointer to bloblist. I >>> briefly reviewed and it seems like a goo >>> >> -- Fran=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