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.8 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 C1977C07E99 for ; Fri, 9 Jul 2021 07:05:37 +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 C91B161357 for ; Fri, 9 Jul 2021 07:05:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C91B161357 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 B6380831B2; Fri, 9 Jul 2021 09:05:34 +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="KaWfGw3p"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id F2547831B8; Fri, 9 Jul 2021 09:05:32 +0200 (CEST) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (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 AA06A831AC for ; Fri, 9 Jul 2021 09:05:29 +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-ej1-x62a.google.com with SMTP id c17so14244313ejk.13 for ; Fri, 09 Jul 2021 00:05:29 -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=ml8m8L6o+Ty2q9QwhGwK3qNAmKkly2tgxJ0gDiMV+Ik=; b=KaWfGw3pN5uP+UTxqH2Cfm7YMUrqpMg58aQLKxAhu1X8Xr0b/XjCnk1mi8vVLGqzm3 vot2hqkVFrTr/C+3iMCh/e9R5nU7Mm/buBvuXhdQHQlt+LKEINwYxjAO/9A/lAFTtP92 f8B4QoBQ5dol6/Eh/xSQSHgFOzsbFFYGOmNu4TQhfos3IHe2CmDlEu7woqUGvx7L4IeN 2k7sAZVtNvGfuD3JM+TcD65O1vHKlxuVlYn3ZrFaie0RH+IUvA9aY7QJ5LIR+YnUbuWA Hnth8kIsib7aSGikaSkWkL+RPPxQsCSgWjsJpG1JX5ed4ppb/3mSqObCsN9fd83wovpC yIOg== 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=ml8m8L6o+Ty2q9QwhGwK3qNAmKkly2tgxJ0gDiMV+Ik=; b=fDZceYvkvIt7kMwxT7/3JrHnhe8PUy/U0mkVq+nWTwhzVJ+OHQqA01n7N/1bPBqAXE dCCzzkJUqBclBjYiP/CNHL2tmWdGDKqdtZTU9jwM4907/QPWQTzMxM5Xpsb/12EAzhjJ EB3j7A5cszBNR0GrgaA/eVt7kQRfUMqRj319eS+05bkwkfe+Nvf+EUMoNkJtCStVdxK6 DoXnDDlXDIweDaAAXH34nMWB2MhFru5HiyT86btRZfp5iii4+5eM/zym/lZujaP4TV61 KdxcieLVVooyqmGpu8x90EKSB3q7fYB59MY6WRd/bkhpE6fVtqLYZ2DZowc49frM+2qr I0kw== X-Gm-Message-State: AOAM532YxOoleR70zBFDNWwMOWRMvAOKqIBPD9Y5JHK2BC5TwjCt0+WP Mnbeb2omNu35V7L9Dg87MYYV+X5qGeL4AAoLZU3QiA== X-Google-Smtp-Source: ABdhPJxjnJyIeY0pM9UPjqc3rEXrlI6EWf9YoHOzKFLXuLoem1xAjibX5KhCYjE/Lbg/SKKoVKAG/5EWH8UyUV+bx+Y= X-Received: by 2002:a17:906:5d05:: with SMTP id g5mr34154042ejt.201.1625814328958; Fri, 09 Jul 2021 00:05:28 -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> <0100017a8648f3d5-98a3bce6-b2dc-48cb-84e4-c292bcef5622-000000@email.amazonses.com> In-Reply-To: From: =?UTF-8?Q?Fran=C3=A7ois_Ozog?= Date: Fri, 9 Jul 2021 09:05:09 +0200 Message-ID: Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages To: Julius Werner Cc: Arjun Khare , Boot Architecture Mailman List , Ed Stuber , Harb Abdulhamid OS , Manish Pandey2 , Moe Ammar , "Paul Isaac's" , Ron Minnich , Simon Glass , U-Boot Mailing List , "tf-a@lists.trustedfirmware.org" , undefined 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 ven. 9 juil. 2021 =C3=A0 03:09, Julius Werner a = =C3=A9crit : > > Of course every project would like not to change... > > > > For TF-A I wonder whether it will/should in fact use devicetree if ther= e > is a lot of complex data? TBD, I suppose. > > Okay, sorry, now I'm a bit confused -- I thought the discussion in > this thread was about which parameter hand-off mechanism to use *for > TF-A*? Or did it shift to discuss other projects in the meantime (I > didn't always follow it closely)? I think it started with the UEFI > guys wanting to implement a HOB format to interface with TF-A, and I > think we now concluded that they're okay with using a simple parameter > list instead (and wrapping their custom HOBs into a parameter blob > that contains their UUID and everything else in the data part). > > So for TF-A, if the decision is that we want a parameter list, I think > it makes sense to keep using the format that has already been there > and in use for several years, and define new tags for the UEFI HOB use > case in that. I don't really see a reason to switch TF-A and all other > projects currently interfacing with it that way (e.g. coreboot) to > something only used by U-Boot right now, if they're practically > identical in concept. Looking at bl_au_params: used by 3 SoCs to deal with gpio and serial. Migration may not be that a big effort (handful lines of code?). The key thing is that the biggest consumer of them are BL33 and a little bit by some OS drivers (OS itself shall not be a consumer). U-Boot has an established mechanism which is used in particular on all chrome books in both x86 and Arm environments. I have the impression that U-Boot is the typical BL33 so I would import the mechanism into TFA, not the other way round. EDK2 has typically its own code for TFA matters and may just import BL31, so it does not appear a priority in that decision. But I may be wrong=E2=80= =A6 > > -- Fran=C3=A7ois-Fr=C3=A9d=C3=A9ric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog