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.0 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 0ABFBC07E99 for ; Fri, 9 Jul 2021 10:07:44 +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 0A72C613D1 for ; Fri, 9 Jul 2021 10:07:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0A72C613D1 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 282BF83124; Fri, 9 Jul 2021 12:07:41 +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=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="Vyh+Ue5i"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 75D9F83124; Fri, 9 Jul 2021 12:07:40 +0200 (CEST) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 363258320D for ; Fri, 9 Jul 2021 12:07:37 +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=daniel.thompson@linaro.org Received: by mail-wr1-x42d.google.com with SMTP id a13so11381658wrf.10 for ; Fri, 09 Jul 2021 03:07:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=LsSleWiVhWHRK3WZfl4c8Q+Z5QMZQI36Dz7uy6roU7I=; b=Vyh+Ue5iGkYC+M+SmRipLzJLweYl4bUJyN946sQiJgCT0Nm0Zzi2HAu2/uiI8Uhsxj k98LvoR72f1kn+UUc8j/BMbWHUWmcRiMMBKn+bENlpZ+WRbOVpEVZSTonW7ckUNsR4UZ T65q3t8EM5rlQpHCwTeVsP+7VuVDcsegvefzWBxVvCIubbKICWm5omOjTo2YbUcF+BEF OJWiPpbzSHOhOBT5RkqFBo1uaEFbEBUYBvDZsOlIow7C2TwHSahlf3o8zEJ9hbAfMGMY YcDpRhNj6h90lx9pccMIAUm/J0F6m6896RLT7nBHk19rtm625okq7lXQ1MwTlfsStUqH UiyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=LsSleWiVhWHRK3WZfl4c8Q+Z5QMZQI36Dz7uy6roU7I=; b=cu+n2BfPKYms9pmXPwZbsSd2iyMa/A4hvx+LUvFNAEWK7RTx6NlxeIT39/x6FGuNDd vnnsypIAPx86epM6iGFPsXInFLSZSoorlyCg/lqD4wtlpwBEU5vnwOaAJuPwNt169xpE sxG7iEEapcn8/CGhiubZRF4lU50HLHDME5N+1NJhSybiDSh1RgCgV6vvg0wmJgxCAc8I TuyfrhtQRIPdOtdaUyJd9F70Owil+qnTo6vJJUS2uj6Br0L+AaFiTBQxwE+PuF/JNeQ9 SNds7fVMdiK6XFRXeoMQRC1aLmaqyNPYGRndSUHhR3ZLDlHgYGjXzAoCdaV1hWYmLyfX JS0A== X-Gm-Message-State: AOAM5304RRcaet+rq1Un1bFQ7DPKOdjyIozlts/jstYTZNGTWAa7aZi4 y9liv1VHd6BmN5G0Gk8v/85MWw== X-Google-Smtp-Source: ABdhPJxRTKobLmS2hpOXWfdR7hGL4oPVEA3laqv4hMkif4764Eq6lAliOsNMmoA4V/rLO1wjcSy5Ug== X-Received: by 2002:adf:df0c:: with SMTP id y12mr10567520wrl.30.1625825256620; Fri, 09 Jul 2021 03:07:36 -0700 (PDT) Received: from maple.lan (cpc141216-aztw34-2-0-cust174.18-1.cable.virginm.net. [80.7.220.175]) by smtp.gmail.com with ESMTPSA id j1sm11331159wms.7.2021.07.09.03.07.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Jul 2021 03:07:34 -0700 (PDT) Date: Fri, 9 Jul 2021 11:07:32 +0100 From: Daniel Thompson To: =?utf-8?B?RnJhbsOnb2lz?= Ozog Cc: Julius Werner , Ed Stuber , Boot Architecture Mailman List , undefined , Harb Abdulhamid OS , Simon Glass , Arjun Khare , U-Boot Mailing List , "tf-a@lists.trustedfirmware.org" , Paul Isaac's , Ron Minnich , Moe Ammar , Manish Pandey2 Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages Message-ID: <20210709100732.zynd3qkwqjamb5qm@maple.lan> References: <10CCF05B-96E6-4C92-942F-1B4C774A813E@arm.com> <0100017a8648f3d5-98a3bce6-b2dc-48cb-84e4-c292bcef5622-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 Fri, Jul 09, 2021 at 09:05:09AM +0200, François Ozog wrote: > Le ven. 9 juil. 2021 à 03:09, Julius Werner a écrit : > > > > Of course every project would like not to change... > > > > > > For TF-A I wonder whether it will/should in fact use devicetree if there > > 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. I presume this analysis only covers those SoCs where someone (vendor, customer, community) has upstreamed their TF-A implementation? It is only relatively recently[1] that the TF-A CLA requirements that inhibited upstreaming were relaxed. Additionally the current silicon supply crunch is forcing board designers to second (third and forth) source critical components which can drive usage of firmware parameter passing. In short are you confident adopting a mantra of "it doesn't exist unless it's upstreamed" is sufficient? Daniel. [1] Perhaps not that recent if measured in years... but certainly recent relative to firmware life cycles! > 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… > > > > > -- > François-Frédéric Ozog | *Director Business Development* 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