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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 80E1EC433F5 for ; Thu, 4 Nov 2021 11:23:49 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E9DF061166 for ; Thu, 4 Nov 2021 11:23:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org E9DF061166 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=nongnu.org Received: from localhost ([::1]:50950 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1miaqR-0003wU-PO for qemu-devel@archiver.kernel.org; Thu, 04 Nov 2021 07:23:47 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46094) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1miapO-0002QU-UC for qemu-devel@nongnu.org; Thu, 04 Nov 2021 07:22:42 -0400 Received: from mail-ed1-x52c.google.com ([2a00:1450:4864:20::52c]:43565) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1miapL-0008Ic-Ie for qemu-devel@nongnu.org; Thu, 04 Nov 2021 07:22:42 -0400 Received: by mail-ed1-x52c.google.com with SMTP id w1so20228621edd.10 for ; Thu, 04 Nov 2021 04:22:38 -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=zsfY9y4eme+dp5ysAplQ2qUaEQlvqhJGj9hVQcV/nr4=; b=wVnDeCxAlN/4f/T55eApLt+ASqPQxzmz9YcXoi9eR1RXbFvjKzvvZhVrmqhuapbxV9 i/6ClSLA4R5kjAyKR6P7SmTGrQueVijQNJt5cKJT3NMRnVbIkdwelwA68XQJsqd1wYtD PIGdUe3gClVaZ51yQ7Hi+98W65mlIe05YL9Az4MWAvltDq6WlclvohGG82EWD59pxQhh CwqHtI1YkJUEpdir58Fs0W/K0owKoTdj5fZGIvl+y1Dzf+vvXe4by4VOTw529gYyO2pD +qpgEJWS1gGosBOuD8uwG/K/bSfihLNUIJny2E6bgNLaTnh5zui7WfarSIvrMKbYO2Up Mwvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zsfY9y4eme+dp5ysAplQ2qUaEQlvqhJGj9hVQcV/nr4=; b=t8R0XHy5TkwJWp+8ipZ6/NIm5C/fyvbH6qiuyac82859xaJLkL+I0ev6ZibBnXGxMJ 3g4WsEBmfOTcHjwhgmBz1qJ4v0glLD+C8bY3rcGyzL3TAnQESJ3xqlgO2o3DCqqo+Owz lhaDfvRp/7oiz7nzWFMjO7JY4u4obTBadYPoR1oShgFSIfS122uFk/Ji961Eif5YLN24 /SG7tSP0qOESsPlW7yuxY5nGEAkbV9kbIWKGQI+0nQak8KBrDPSQ4gDCGD644+kyEgKX LgIPr7wG0u+3nhGcr2VAlOab4OXcIaNfhLUHXXGqYh1ReiJ6jzRBcK18X74DcqiCg7cD jmfA== X-Gm-Message-State: AOAM531V1wwS25TSfI3HqyC5cTFdA5dd/tO9uGSMB/b1bBFmO/QZLxJO +F9if5jq/avf4F5Fzim6iB1Kf4Pk0iauk+oNifmotg== X-Google-Smtp-Source: ABdhPJxHCwKLhS4ioEDYOPZ15dNzLjb91NT2cCro60zhzk8s4/bMheTGa6b3XBtjG1X5lYVW2XoVTUG2gQ2wPJvromA= X-Received: by 2002:a17:906:b209:: with SMTP id p9mr11889997ejz.66.1636024956690; Thu, 04 Nov 2021 04:22:36 -0700 (PDT) MIME-Version: 1.0 References: <20211026002344.405160-1-sjg@chromium.org> <20211026002344.405160-7-sjg@chromium.org> <20211101180707.GJ24579@bill-the-cat> <20211102172833.GS24579@bill-the-cat> <20211103144125.GZ24579@bill-the-cat> In-Reply-To: From: =?UTF-8?Q?Fran=C3=A7ois_Ozog?= Date: Thu, 4 Nov 2021 12:22:25 +0100 Message-ID: Subject: Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64 To: Peter Maydell Content-Type: multipart/alternative; boundary="000000000000637c1d05cff4bed8" Received-SPF: pass client-ip=2a00:1450:4864:20::52c; envelope-from=francois.ozog@linaro.org; helo=mail-ed1-x52c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Albert Aribaud , Tom Rini , U-Boot Mailing List , Heinrich Schuchardt , Simon Glass , Ilias Apalodimas , QEMU Developers , Sean Anderson , Tuomas Tynkkynen , Mark Kettenis Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --000000000000637c1d05cff4bed8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable hi Peter Le jeu. 4 nov. 2021 =C3=A0 12:09, Peter Maydell = a =C3=A9crit : > On Wed, 3 Nov 2021 at 14:41, Tom Rini wrote: > > > > On Wed, Nov 03, 2021 at 06:29:20AM +0100, Fran=C3=A7ois Ozog wrote: > > [snip] > > > > 3. Anything else? > > > > > > > > For qemu_arm_spl, it *does not boot* unless the U-Boot SPL properti= es > > > > are present. There is no easy way to fix this. > > > > > > one clean and easy way would be to upstream a Qemu change to merge a > > > supplied overlay to the generated one. This the same idea as applying > the > > > NT_FW_COnFIG overlay in the TFA world. In both cases previous loaders > do > > > their job properly for U-Boot : setting up the stage as needed. > > > > For the record, I believe Simon did propose this and the QEMU response > > was that no, you should dumpdtb, combine externally and pass that > > directly. > > Well, our recommendation really was that the ideal thing would > be "you take the dtb that QEMU passes you at runtime, and at > runtime combine that with whatever extra information you want". That looks just reasonable this way. Runtime merging may need to be done before control is actually transferred. We have that problem on real board where we need to inject a TPM device for measured boot and it is not =C3=A9numerable and pluggable. With TFA we have the option to add the TPM description in the NT_FW_CONFIG and merge it at run time. So we need a =C2=AB -mergedtb =C2=BB option for Qemu to have the same capab= ility. This would merge the QEMU generated one with the command line provided. > > The dumpdtb option is primarily intended as a debug feature, > so you can have a look at the dtb QEMU created to see why your > OS isn't booting; although you can script stuff up that does > a dumpdtb-modify-pass-to-QEMU that is pretty clunky given the > need to invoke QEMU twice with matching arguments both times. > > -- PMM > --=20 Fran=C3=A7ois-Fr=C3=A9d=C3=A9ric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog --000000000000637c1d05cff4bed8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
hi Peter=C2=A0

<= div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0jeu. 4 nov. 2021 =C3=A0 12:09,= Peter Maydell <peter.maydel= l@linaro.org> a =C3=A9crit=C2=A0:
On Wed, 3 Nov 2021 at 14:41, Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, Nov 03, 2021 at 06:29:20AM +0100, Fran=C3=A7ois Ozog wrote: > [snip]
> > > 3. Anything else?
> > >
> > > For qemu_arm_spl, it *does not boot* unless the U-Boot SPL p= roperties
> > > are present. There is no easy way to fix this.
> >
> > one clean and easy way would be to upstream a Qemu change to merg= e a
> > supplied overlay to the generated one. This the same idea as appl= ying the
> > NT_FW_COnFIG overlay in the TFA world. In both cases previous loa= ders do
> > their job properly for U-Boot : setting up the stage as needed. >
> For the record, I believe Simon did propose this and the QEMU response=
> was that no, you should dumpdtb, combine externally and pass that
> directly.

Well, our recommendation really was that the ideal thing would
be "you take the dtb that QEMU passes you at runtime, and at
runtime combine that with whatever extra information you want".
That looks just reasonable this way. Runtime mergin= g may need to be done before control is actually transferred. We have that = problem on real board where we need to inject a TPM device for measured boo= t and it is not =C3=A9numerable and pluggable. With TFA we have the option = to add the TPM description in the NT_FW_CONFIG and merge it at run time.
So we need a =C2=AB -mergedtb =C2=BB option for Qemu t= o have the same capability. This would merge the QEMU generated one with th= e command line provided.
<= br> The dumpdtb option is primarily intended as a debug feature,

so you can have a look at the dtb QEMU created to see why your
OS isn't booting; although you can script stuff up that does
a dumpdtb-modify-pass-to-QEMU that is pretty clunky given the
need to invoke QEMU twice with matching arguments both times.

-- PMM
--
<= div>
Fran=C3=A7oi= s-Fr=C3=A9d=C3=A9ric Ozog=C2=A0|=C2=A0Director Business Development
T:=C2=A0+33.67221.6485<= br>francois.ozog@linaro.org=C2=A0= |=C2=A0Skype:=C2=A0ffozog

--000000000000637c1d05cff4bed8--