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=2.9 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,LOTS_OF_MONEY,MAILING_LIST_MULTI,MONEY_NOHTML, PDS_BAD_THREAD_QP_64,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 9C821C48BE8 for ; Fri, 18 Jun 2021 03:54:21 +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 7D30761369 for ; Fri, 18 Jun 2021 03:54:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7D30761369 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=icloud.com 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 EB86D82AE1; Fri, 18 Jun 2021 05:54:16 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=quarantine dis=none) header.from=icloud.com 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=icloud.com header.i=@icloud.com header.b="mAsTPJCE"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 7BF5282A29; Fri, 18 Jun 2021 01:46:04 +0200 (CEST) Received: from mr85p00im-zteg06012001.me.com (mr85p00im-zteg06012001.me.com [17.58.23.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id BFF2480488 for ; Fri, 18 Jun 2021 01:45:54 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=icloud.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=raghu.ncstate@icloud.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1623973553; bh=HjRmyCyeoszaZ5wLQR4OzTG9ZWZUsRmP12CT3tcsN1A=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=mAsTPJCEyEX7ZsZUVJINK+DaeF0cW+OVcjB9oJyzaFy7vpzemhdJjsZGKCKjQ++XF EnAbxhiOmnF42CgjtBjMIbdtvNGDPjLtDibF9RkQ/wOvdNaCA0aLCKEqxQKHMp30/p UU8Sh5o7IfDPUGr7AJ9qe09l6nDTW1gRJQnaj0e/ciHVrWRrMU5sYduThHulZ06fWC ZDODAsWsTpN5VMzu5+hY6WtrzWmYT5s0tqMRztwzGPojaTFc10/o8v6P//o1ASOv+S ar1ST6sjWCMK6Wv6v3qOvk3AIPs9jkfz5f47jLkCJvGoQqqGbE1Zwb/t9zibMnCvdv pW+0ab8EJAW/Q== Received: from DESKTOPH20GCBV (searspoint.nvidia.com [216.228.112.21]) by mr85p00im-zteg06012001.me.com (Postfix) with ESMTPSA id 64D59A00611; Thu, 17 Jun 2021 23:45:50 +0000 (UTC) From: To: =?utf-8?Q?'Fran=C3=A7ois_Ozog'?= , "'Simon Glass'" Cc: "'Ed Stuber'" , "'Boot Architecture Mailman List'" , "'Harb Abdulhamid OS'" , "'U-Boot Mailing List'" , "'Arjun Khare'" , "'Paul Isaac's'" , "'Ron Minnich'" , "'Moe Ammar'" 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-619c2946e2 75-000000@emai l.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> <0100017a1b8bea04-71a338d9-55ac-4163-80c9-2c350d62d425-000000@email.amazonses.com> In-Reply-To: <0100017a1b8bea04-71a338d9-55ac-4163-80c9-2c350d62d425-000000@email.amazonses.com> Subject: RE: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages Date: Thu, 17 Jun 2021 16:45:48 -0700 Message-ID: <08d801d763d2$e6c52240$b44f66c0$@icloud.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJGzxIdl/ATSepLXcoSPfTnd9cfaQIyd1HnAftOvmEAmqYAsgE2GDQcAohqSL4B19BgvgHttUnFA2czg1kBWL6eugF5/4jMAQwwjTgBrDyaLAHxQHDiAee2koMCcvK1YQKhB0LNAqdi9J8CAYFwVgEHhlikAoSyKKUB6/YtzQJGHEbeqOVMchA= Content-Language: en-us X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?= =?UTF-8?Q?2903e8d5c8f:6.0.391,18.0.790,17.0.607.475.0000000_definitions?= =?UTF-8?Q?=3D2021-06-17=5F15:2021-06-15=5F01,2021-06-17=5F15,2020-04-07?= =?UTF-8?Q?=5F01_signatures=3D0?= X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 spamscore=0 malwarescore=0 bulkscore=0 suspectscore=0 mlxlogscore=999 phishscore=0 mlxscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2106170143 X-Mailman-Approved-At: Fri, 18 Jun 2021 05:54:15 +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 My take: Don=E2=80=99t force device tree on platforms. Lets not make = decisions about whether SDRAM is sufficient to expose device tree, that = is assuming size may be the only problem with device tree. Some = platforms don=E2=80=99t want to use device tree just like some platforms = don=E2=80=99t want to use UUID=E2=80=99s(which b.t.w does not = necessarily mean private use as was explained during the TF-A forums). I support ARM=E2=80=99s proposal that partitions the problem based on = market segments and allows different platforms to choose what is right = for them, that includes the ability to use UUID if a platform so chooses = AND across boundaries. I wouldn=E2=80=99t vote for the proposal below = about using bloblist for simple things and device tree for other complex = things based on SRAM/SDRAM etc. that complicates things further. What if = you need to pass information from the bloblist to later boot stages? Do = we take data from bloblist and patch it into a device tree? =20 I also think it is incorrect to partition platforms into what = u-boot/linux boot/embdedded systems do and what =E2=80=9CUEFI/private = code=E2=80=9D does. UEFI is a huge part of the ARM eco-system and is = being used fairly extensively and supported across different markets and = is not private code. =20 Thanks -Raghu =20 From: TF-A On Behalf Of = Fran=C3=A7ois Ozog via TF-A Sent: Thursday, June 17, 2021 12:57 PM To: Simon Glass Cc: Ed Stuber ; Boot Architecture Mailman = List ; Harb Abdulhamid OS = ; U-Boot Mailing List = ; Arjun Khare ; = 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 =20 =20 =20 Le jeu. 17 juin 2021 =C3=A0 21:38, Simon Glass > a =C3=A9crit : Hi, =20 On Fri, 11 Jun 2021 at 05:52, Fran=C3=A7ois Ozog = > wrote: =20 =20 On Thu, 10 Jun 2021 at 23:57, Manish Pandey2 > wrote: Hi Everyone, =20 I have tried to conclude the discussions we had in two of the TF-A tech = forum sessions and on mailing list. =20 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. * =20 * 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.=20 =20 I would think of a few additions on the bloblist_rec: =20 struct = bloblist_rec { = u32 = tag; = u32 = hdr_size; = u32 size; = u32 = spare; }; enum = bloblist_tag_t { = BLOBLISTT_NONE =3D 0, =20 /* Vendor-specific tags are permitted here */ = BLOBLISTT_EC_HOSTEVENT, /* Chromium OS = EC host-event mask */ =20 We can give these each a value (=3D1, =3D2) so it is clear.=20 = 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 * 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: =20 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 = 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. =20 +1 =20 =20 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. =20 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. =20 =20 Other tags to consider: PSCI interface details, DRAM information, SCMI = stuff, Secure SRAM and DRAM information... =20 =20 * 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) =20 Please share your thoughts if you disagree to the proposed solution. =20 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. =20 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 =20 Regards, Simon =20 =20 Thanks Manish Pandey _____ =20 From: Joanna Farley > Sent: 02 June 2021 16:26 To: Madhukar Pappireddy >; Okash Khawaja = >; Simon Glass = > Cc: 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 = = >; Manish Pandey2 > Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for = information passing between boot stages=20 =20 + TF-A list that got dropped (again)! =20 Joanna =20 From: Joanna Farley < = Joanna.Farley@arm.com> Date: Wednesday, 2 June 2021 at 15:29 To: Madhukar Pappireddy < = Madhukar.Pappireddy@arm.com>, Okash Khawaja < = okash.khawaja@gmail.com>, Simon Glass < = sjg@chromium.org> Cc: Harb Abdulhamid OS < = abdulhamid@os.amperecomputing.com>, Boot Architecture Mailman List < = = boot-architecture@lists.linaro.org>, Ed Stuber < = edstuber@amperecomputing.com>, = Arjun Khare < = akhare@amperecomputing.com>, U-Boot Mailing List < = u-boot@lists.denx.de>, Paul Isaac's < = paul.isaacs@linaro.org>, Ron Minnich < = rminnich@google.com>, Moe Ammar < = moe@amperecomputing.com> Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for = information passing between boot stages =20 Hi Everyone, =20 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. =20 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? =20 Details of the call are: =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 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=20 =20 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.=20 =20 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/ =20 Trusted Firmware is inviting you to a scheduled Zoom meeting. =20 Join Zoom Meeting https://zoom.us/j/9159704974 =20 Meeting ID: 915 970 4974 =20 One tap mobile +16465588656,, = 9159704974# US (New York) +16699009128,, = 9159704974# US (San Jose) =20 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 =20 =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Joanna =20 =20 =20 =20 =20 =20 =20 On 19/05/2021, 03:50, "Madhukar Pappireddy" < = Madhukar.Pappireddy@arm.com> wrote: =20 Attached slides presented by Manish in the TF-A tech forum. =20 =20 -----Original Message----- From: TF-A < = tf-a-bounces@lists.trustedfirmware.org> On Behalf Of Madhukar Pappireddy = via TF-A Sent: Tuesday, May 18, 2021 8:59 PM To: Joanna Farley < = Joanna.Farley@arm.com>; Okash Khawaja < = okash.khawaja@gmail.com>; Simon Glass < = sjg@chromium.org> Cc: Harb Abdulhamid OS < = abdulhamid@os.amperecomputing.com>; Boot Architecture Mailman List < = = boot-architecture@lists.linaro.org>; Ed Stuber < = edstuber@amperecomputing.com>; = Arjun Khare < = akhare@amperecomputing.com>; U-Boot Mailing List < = u-boot@lists.denx.de>; = tf-a@lists.trustedfirmware.org; = Paul Isaac's < paul.isaacs@linaro.org>; = Ron Minnich < rminnich@google.com>; Moe = Ammar < moe@amperecomputing.com> Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) = for information passing between boot stages =20 Hi, =20 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. =20 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 =20 Both the above requirements are common in many ecosystems and need = to co-exist. =20 There are broadly 3 problems to solve: 1. Format of HOB structures: It looks like the consensus is that we = could use existing mechanisms for this (BL_AUX_PARAM in TF-A or bloblist = in u-boot). 2. Identification of HOB list entries: There is a debate about = whether tags would suffice or if the HOB list producer and consumer = would depend on UUID/GUIDs for identifying a specific HOB structure. = Another suggestion was to use a hybrid approach. Reserve a single tag ID = for identifying/constructing a HOB structure that further leverages UUID = based identifier. This way, the generic HOB list doesn't need to support = UUIDs and can work with tags. 3. The design contract for the static interface between two boot = phases: The problem at hand is whether to pass a pointer to a HOB list = or a device tree blob through the general-purpose registers for = configuration hand-off between two boot phases. Some proposals that came = up: > Proposal 1: Always pass a pointer to the device tree blob = through the GP register and capture the pointer to the HOB list as a = property of a node that is uniquely identifiable by the downstream boot = phase. This needs to define a device tree binding such that producer and = consumer agree on the information passed. > Proposal 2: Pass a pointer to a generic container through = the GP register that can be interpreted appropriately by both boot = loaders(i.e., producer and consumer of the boot info). This container = can either be a dtb or a HOB list which can be simply inferred by = checking for a magic header that indicates if the buffer appears to be a = flattened device tree. > One another concern that was brought up offline is to make = sure we don't break current design contracts between various boot loader = phases in TF-A. Many of the general-purpose registers have a designated = purpose such as to share configurations between BL images( such as = firmware config dtb, SoC config dtb, Non trusted firmware config dtb, = memory layout, entry point info, etc.). =20 If I am not mistaken, a single design may not fit the needs of every = segment(client, Infra, embedded) and the forum is open to solutions = tailored for individual segments. Joanna will be sending a follow up = email with more information about future TF-A tech forums that serves as = a platform for further discussions. =20 Thanks, Madhukar =20 -----Original Message----- From: TF-A < = tf-a-bounces@lists.trustedfirmware.org> On Behalf Of Joanna Farley via = TF-A Sent: Sunday, May 16, 2021 5:19 AM To: Okash Khawaja < = okash.khawaja@gmail.com>; Simon Glass < = sjg@chromium.org> Cc: Harb Abdulhamid OS < = abdulhamid@os.amperecomputing.com>; Boot Architecture Mailman List < = = boot-architecture@lists.linaro.org>; = tf-a@lists.trustedfirmware.org; = Ed Stuber < = edstuber@amperecomputing.com>; Arjun Khare < = akhare@amperecomputing.com>; U-Boot = Mailing List < u-boot@lists.denx.de>; Paul = Isaac's < paul.isaacs@linaro.org>; Ron = Minnich < rminnich@google.com>; Moe Ammar < = moe@amperecomputing.com> Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) = for information passing between boot stages =20 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. =20 Thanks =20 Joanna =20 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: =20 Hi, =20 Do we have slides and video from last week's discussion? =20 Thanks, Okash =20 =20 On Wed, May 5, 2021 at 11:52 PM Simon Glass via TF-A < = tf-a@lists.trustedfirmware.org> wrote: > > Hi Harb, > > Thanks for the idea. I am still not completely sure what = benefit UUID provides to an open project. I'd like to propose something = different, more in the spirit of open collaboration. I also worry that = the word 'standard' seems to be a synonym for UUIDs, UEFI, etc., i.e. = enabling/preferring closed-source firmware and the continued decline of = open-source projects. It really should not be. > > So I suggest: Use simple integer IDs and reserve some area for = 'private' use. If you want to collaborate across projects outside your = company, you either need to allocate a 'public' ID or agree privately = between the parties which private ID to use. > > This means that the default and easiest option is for = collaboration and a public ID, with private ones (whose purpose may be = secret) reserved just for private use. > > Regards, > Simon > > On Wed, 5 May 2021 at 11:42, Harb Abdulhamid OS < = = abdulhamid@os.amperecomputing.com> wrote: >> >> Hey Folks, >> >> We wanted to put out a middle-ground proposal to help guide = the discussion on the call tomorrow. >> >> >> >> A proposal that we have been discussing offline involves = reserving a single tag ID for the purpose of construction UEFI PI HOB = List structure, and that tag would be used to identify a HOB-specific = structure that does leverage UUID based identifier. This will eliminate = the burden of having to support UUID as the tag, and this enables = projects that require UUID based identifiers for the broad range of HOB = structures that need to be produced during the booting of the platform. = Once we have a tag for a HOB list, this will enable various HOB = producers that can add/extend the HOB list in TF-A code (or even = pre-TF-A code), with a HOB consumer for that UUID/GUID on the other side = (i.e. whatever the BL33 image is booting on that platform). >> >> >> >> Essentially, the idea is if someone would like to support HOB = structures in a standard way using TF-A, they would wrap it up in a = BL_AUX_PARAM/BLOB structure (whatever the group decides) and the way we = identify the structure as a HOB list is with this new reserved tag. >> >> >> >> Hopefully that makes sense and less contentious. Look = forward to discuss this further on the call. >> >> >> >> Thanks, >> >> --Harb >> >> >> >> From: Manish Pandey2 < = Manish.Pandey2@arm.com> >> Sent: Friday, April 30, 2021 8:14 AM >> To: Fran=C3=A7ois Ozog < = francois.ozog@linaro.org> >> Cc: Simon Glass < = sjg@chromium.org>; 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 < = u-boot@lists.denx.de>; Paul Isaac's < = paul.isaacs@linaro.org>; Ron Minnich < = rminnich@google.com> >> Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks = (HOBs) for information passing between boot stages >> >> >> >> Hi All, >> >> >> >> Please find invite for next TF-A Tech Forum session to = continue our discussions on HOB implementation, feel free to forward it = to others. >> >> >> >> The next TF-A Tech Forum is scheduled for Thu 6th May 2021 = 16:00 =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 = stages. >> >> The requirement is two-fold: >> >> 1. Passing static information(config files) >> >> 2. Passing dynamic information (Hob list) >> >> In the upcoming TF-A tech forum, we can start with a = discussion on dynamic information passing and if time permits, we can = cover static information passing. The purpose of the call is to have an = open discussion and continue the discussion from the trusted-substrate = call[2] done earlier. We would like to understand the various = requirements and possible ways to implement it in TF-A in a generalized = way so that it can work with other Firmware projects. >> >> >> >> The two specific item which we would like to discuss are: >> >> 1. HOB format: TF-A/u-boot both has an existing bloblist = implementation, which uses tag values. Question, can this be enhanced to = use hybrid values(Tag and UUID) both? >> >> 2. Standardization on Physical register use to pass base = of HoB data structure. >> >> References: >> >> [1] = = https://lists.trustedfirmware.org/pipermail/tf-a/2021-April/001069.html >> >> [2] = = https://linaro-org.zoom.us/rec/share/zjfHeMIumkJhirLCVQYTHR6ftaqyWvF_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 = 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 >> >> >> >> ________________________________ >> >> From: Fran=C3=A7ois Ozog < = francois.ozog@linaro.org> >> Sent: 08 April 2021 16:50 >> To: Manish Pandey2 < = Manish.Pandey2@arm.com> >> Cc: Simon Glass < = sjg@chromium.org>; 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 < = paul.isaacs@linaro.org>; Ron Minnich < = rminnich@google.com> >> Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks = (HOBs) for information passing between boot stages >> >> >> >> Hi >> >> >> >> here is the meeting recording: >> >> = = https://linaro-org.zoom.us/rec/share/zjfHeMIumkJhirLCVQYTHR6ftaqyWvF_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 = tagged elements (as suggested by Julius). It has support for both = generic and SiP-specific tags. Having said that, it does not stop = partners to introduce new mechanisms suitable for their usecase in = platform port initially and later move to generic code if its suitable = for other platforms. >> >> >> >> To start with, Ampere can introduce a platform specific = implementation of memory tag(speed/NUMA topology etc) which can be = evaluated and discussed for generalization in future. The tag will be = populated in BL2 stage and can be forwarded to further stages(and to = BL33) by passing the head of list pointer in one of the registers. = Initially any register can be used but going forward a standardization = will be needed. >> >> >> >> The U-boot bloblist mentioned by Simon is conceptually = similar to what TF-A is using, if there is consensus of using = bloblist/taglist then TF-A tag list may be enhanced to take best of both = the implementations. >> >> >> >> One of the potential problems of having structure used in = different projects is maintainability, this can be avoided by having a = single copy of these structures in TF-A (kept inside "include/export" = which intended to be used by other projects.) >> >> >> >> Regarding usage of either UUID or tag, I echo the sentiments = of Simon and Julius to keep it simple and use tag values. >> >> >> >> Looking forward to having further discussions on zoom call = today. >> >> >> >> Thanks >> >> Manish P >> >> >> >> ________________________________ >> >> From: TF-A < = tf-a-bounces@lists.trustedfirmware.org> on behalf of Julius Werner via = TF-A < = tf-a@lists.trustedfirmware.org> >> Sent: 25 March 2021 02:43 >> To: Simon Glass < sjg@chromium.org> >> Cc: 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 < = paul.isaacs@linaro.org>; Ron Minnich < = rminnich@google.com> >> Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks = (HOBs) for information passing between boot stages >> >> >> >> Just want to point out that TF-A currently already supports a = (very simple) mechanism like this: >> >> >> >> = = https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-= a/+/refs/heads/master/include/export/lib/bl_aux_params/bl_aux_params_exp.= h >> >> = = https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-= a/+/refs/heads/master/lib/bl_aux_params/bl_aux_params.c >> >> = = https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-= a/+/refs/heads/master/plat/rockchip/common/params_setup.c >> >> >> >> It's just a linked list of tagged elements. The tag space is = split into TF-A-wide generic tags and SiP-specific tags (with plenty of = room to spare if more areas need to be defined -- a 64-bit tag can fit a = lot). This is currently being used by some platforms that run coreboot = in place of BL1/BL2, to pass information from coreboot (BL2) to BL31. >> >> >> >> I would echo Simon's sentiment of keeping this as simple as = possible and avoiding complicated and bloated data structures with = UUIDs. You usually want to parse something like this as early as = possible in the passed-to firmware stage, particularly if the structure = encodes information about the debug console (like it does for the = platforms I mentioned above). For example, in BL31 this basically means = doing it right after moving from assembly to C in = bl31_early_platform_setup2() to get the console up before running = anything else. At that point in the BL31 initialization, the MMU and = caches are disabled, so data accesses are pretty expensive and you don't = want to spend a lot of parsing effort or calculate complicated checksums = or the like. You just want something extremely simple where you ideally = have to touch every data word only once. >> >> >> >> On Wed, Mar 24, 2021 at 5:06 PM Simon Glass via TF-A < = tf-a@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 = here more generically, as there are typically vendor specific structures = beyond the resource descriptor HOB, which provides only a small subset = of the information that needs to be passed between the boot phases. >> >> >> >> The whole point here is to provide mechanism to develop = firmware that we can build ARM Server SoC=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 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. There 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 = 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 = structures may need to be generated in boot phases where DDR is not = available, and therefore we will be extremely memory constrained. >> DT is probably overkill for this purpose =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 = for OS / RTOS software, and not necessarily suitable for = firmware-to-firmware hand-offs). >> >> >> >> Frankly, I would personally push back pretty hard on defining = SMC=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 burden on the folks that have to do security auditing and = threat analysis. I see no benefit in exposing these boot/HOB/BOB = structures at run-time via SMC calls. >> >> >> >> Please do let me know if you disagree and why. Look forward = to discussing on this thread or on the call. >> >> >> >> @Simon Glass - Thanks for the pointer to bloblist. I = briefly reviewed and it seems like a goo --=20 = =20 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 =20