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 63130C433FE for ; Wed, 13 Oct 2021 17:37:03 +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 D2C71610FE for ; Wed, 13 Oct 2021 17:37:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D2C71610FE 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]:41208 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1maiBY-0006Fe-QJ for qemu-devel@archiver.kernel.org; Wed, 13 Oct 2021 13:37:01 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56874) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mai9p-00044V-1W for qemu-devel@nongnu.org; Wed, 13 Oct 2021 13:35:14 -0400 Received: from mail-ed1-x52a.google.com ([2a00:1450:4864:20::52a]:33529) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mai9m-0001Tq-04 for qemu-devel@nongnu.org; Wed, 13 Oct 2021 13:35:12 -0400 Received: by mail-ed1-x52a.google.com with SMTP id p13so13685150edw.0 for ; Wed, 13 Oct 2021 10:35:09 -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=R2WvOoqhbIghO8aKyK2+KSmhyIF+gSA6nIf0bsPVmfs=; b=x1gQXX6UoW7q6hZTeIKMPz/CGbwqSZSdEA6irV/cJPVPWpJaaokfJhzyyZAOgWzZBZ id77jA4HonEbtWkZHwXgaMgyDq7qtD8vgioQStho/A1pUquAv9YfMZldTR9Myp4gSA0O nFIoHUSPGzYFAgqORJx/+Lry9MRXD+av3ZSOsSxebO4a7ahntm/WIDnYehdFvMaXsAlM g/J4QcOssNKdk692Ik3T0sTsToNvcLhYcFcxyO+lOlO9VvkHUlY33yure1tsbyONuaWT fO+om0pKkjoLoqohUMbCcW6x72PopAk7yJBRdqoXBDdCSuW9smBquPdGgKEa/V1rxPcx FDHA== 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=R2WvOoqhbIghO8aKyK2+KSmhyIF+gSA6nIf0bsPVmfs=; b=qn+5SAbm/VtjVXXoGuxekdNvBQT6s3jwThDZYDk3x/C4SdbQXB2GciJYwY4F39eaNG ahn0B6d7no0VMN4xkBQ9Btwon3UfiqcNNmamp4h9BjZrtai/R8kvUzNMhLrEOTK/jvf/ UX8BCkjcZv+ESM/oX+JG1RVaMKHTv0i0aXMojcMl1IgI1yQjT5FVwP6KQuooRetDMkPX ctDZAnTRs/xHgIyGQbbaSaVv3WzxgdY4Qdueysuog3r89H4u3N8VkDTZY3ud3jACDa7c aOYsNa+3eKWI3ChzEQUn3Zr1WK5hkNN3y8OpYLkYodEdATh7drKUdy0vdL3+w8WDPWBt e1Tg== X-Gm-Message-State: AOAM53260Dgk0f9s3a+ZWYCDDGy7BsyMIB8YrkFCxol/a+Ta+hTwq3yc zadcMnGksFt85tYJztQgbjWvPqebjJFMNe1P2W6A+A== X-Google-Smtp-Source: ABdhPJxLF1NIrsRpEvR8jmmqYRkDrsaVaX68h7Q/nMJd66C3gn7wMCU4+K+Sf0BTHhMqjzMOH0owbjxYxS8SeSt2Lmk= X-Received: by 2002:a17:906:94da:: with SMTP id d26mr661557ejy.213.1634146507995; Wed, 13 Oct 2021 10:35:07 -0700 (PDT) MIME-Version: 1.0 References: <20211013010120.96851-1-sjg@chromium.org> <20211013013450.GJ7964@bill-the-cat> In-Reply-To: From: =?UTF-8?Q?Fran=C3=A7ois_Ozog?= Date: Wed, 13 Oct 2021 19:34:57 +0200 Message-ID: Subject: Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option To: Simon Glass Content-Type: multipart/alternative; boundary="0000000000001edcfe05ce3f62a1" Received-SPF: pass client-ip=2a00:1450:4864:20::52a; envelope-from=francois.ozog@linaro.org; helo=mail-ed1-x52a.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.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Liviu Dudau , Neil Armstrong , Vladimir Oltean , Linus Walleij , Bin Meng , Kever Yang , Sean Anderson , Atish Patra , Zong Li , Stefan Roese , Fabio Estevam , Rainer Boschung , Tom Rini , Stephen Warren , Oleksandr Andrushchenko , Heinrich Schuchardt , Niel Fourie , Michal Simek , =?UTF-8?B?TWFyZWsgQmVow7pu?= , Jerry Van Baren , Ramon Fried , Jagan Teki , Valentin Longchamp , Heiko Schocher , Peter Robinson , Sinan Akman , Thomas Fitzsimmons , Wolfgang Denk , Stephen Warren , "qemu-devel@nongnu.org Developers" , Andre Przywara , Tim Harvey , Ashok Reddy Soma , Rick Chen , Alexander Graf , Green Wan , T Karthik Reddy , Anastasiia Lukianenko , Albert Aribaud , Michal Simek , Matthias Brugger , Leo , Tero Kristo , U-Boot Mailing List , David Abdurachmanov , Priyanka Jain , Ilias Apalodimas , Christian Hewitt , Aaron Williams , Tuomas Tynkkynen , Heinrich Schuchardt , Tianrui Wei , Bin Meng , =?UTF-8?Q?Pali_Roh=C3=A1r?= , Dimitri John Ledkov , Padmarao Begari Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --0000000000001edcfe05ce3f62a1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Simon Le mer. 13 oct. 2021 =C3=A0 16:49, Simon Glass a =C3=A9c= rit : > Hi Tom, Bin,Fran=C3=A7ois, > > On Tue, 12 Oct 2021 at 19:34, Tom Rini wrote: > > > > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > Hi Simon, > > > > > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass wrote: > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE = so > > > > there are only three ways to obtain a devicetree: > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built an= d > > > > appended to U-Boot > > > > - OF_EMBED - for development purposes, the devicetree is embedde= d > in > > > > the ELF file (also used for EFI) > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > The last one is currently set up so that no devicetree is needed at > all > > > > in the U-Boot tree. Most boards do provide one, but some don't. Som= e > > > > don't even provide instructions on how to boot on the board. > > > > > > > > The problems with this approach are documented at [1]. > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any > board > > > > can obtain its devicetree at runtime, even it is has a devicetree > built > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader > and its > > > > caller may have a better idea about the hardware available in the > machine. > > > > This is the case with a few QEMU boards, for example. > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be a= n > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > This series makes this change, adding various missing devicetree > files > > > > (and placeholders) to make the build work. > > > > > > Adding device trees that are never used sounds like a hack to me. > > > > > > For QEMU, device tree is dynamically generated on the fly based on > > > command line parameters, and the device tree you put in this series > > > has various hardcoded values which normally do not show up > > > in hand-written dts files. > > > > > > I am not sure I understand the whole point of this. > > > > I am also confused and do not like the idea of adding device trees for > > platforms that are capable of and can / do have a device tree to give u= s > > at run time. > > (I'll just reply to this one email, since the same points applies to > all replies I think) > > I have been thinking about this and discussing it with people for a > few months now. I've been signalling a change like this for over a > month now, on U-Boot contributor calls and in discussions with Linaro > people. I sent a patch (below) to try to explain things. I hope it is > not a surprise! > > The issue here is that we need a devicetree in-tree in U-Boot, to > avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD, > BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between > Ilias' series and this one we can get ourselves on a stronger footing. > There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use. > For more context: > > > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-= sjg@chromium.org/ > > BTW I did suggest to QEMU ARM that they support a way of adding the > u-boot.dtsi but there was not much interest there (in fact the > maintainer would prefer there was no special support even for booting > Linux directly!) i understand their point of view and agree with it. > But in any case it doesn't really help U-Boot. I > think the path forward might be to run QEMU twice, once to get its > generated tree and once to give the 'merged' tree with the U-Boot > properties in it, if people want to use U-Boot features. > > I do strongly believe that OF_BOARD must be a run-time option, not a > build-time one. It creates all sorts of problems and obscurity which > have taken months to unpick. See the above patch for the rationale. > > To add to that rationale, OF_BOARD needs to be an option available to > any board. At some point in the future it may become a common way > things are done, e.g. TF-A calling U-Boot and providing a devicetree > to it. It doesn't make any sense to have people decide whether or not > to set OF_BOARD at build time, thus affecting how the image is put > together. We'll end up with different U-Boot build targets like > capricorn, capricorn_of_board and the like. It should be obvious where > that will lead. Instead, OF_BOARD needs to become a commonly used > option, perhaps enabled by most/all boards, so that this sort of build > explosion is not needed. If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don=E2=80=99t understand how the patch set s= upports it as it puts dts files for those boards to be built. > U-Boot needs to be flexible enough to > function correctly in whatever runtime environment in which it finds > itself. > > Also as binman is pressed into service more and more to build the > complex firmware images that are becoming fashionable, it needs a > definition (in the devicetree) that describes how to create the image. > We can't support that unless we are building a devicetree, nor can the > running program access the image layout without that information. > > Fran=C3=A7ois's point about 'don't use this with any kernel' is > germane...but of course I am not suggesting doing that, since OF_BOARD > is, still, enabled. We already use OF_BOARD for various boards that > include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example > (as I said in the cover letter "Most boards do provide one, but some > don't."). So this series is just completing the picture by enforcing > that *some sort* of devicetree is always present. > That seems inconsistent with the OF_BOARD becomes the default. > > I can't quite pinpoint the patch where U-Boot started allowing the > devicetree to be omitted, but if people are interested I could try a > little harder. It was certainly not my intention (putting on my > device-tree-maintainer hat) to go down that path and it slipped in > somehow in all the confusion. I'm not sure anyone could tell you that > rpi_3 has an in-tree devicetree but rpi_4 does not... > > Anyway this series is very modest. It just adds the requirement that > all in-tree boards have some sort of sample devicetree and preferably > some documentation as to where it might come from at runtime. That=E2=80=99s a very good goal. But adding files in dts make them not samp= les but templates to be used and replace board provided DTB. If you push all your DTS files in documentation, you do what you say: adding sample files. > That > should not be a tough call IMO. Assuming we can get the validation in > place (mentioned by Rob Herring recently) it will be quite natural to > sync them between (presumably) Linux and U-Boot. > > I am also quite happy to discuss what should actually be in these > devicetree files and whether some of them should be essentially empty. > As you probably noticed, some of them are empty since I literally > could not figure out where they come from! But there needs to be at > least some skeleton for U-Boot to progress, since devicetree is > critical to its feature set. absolutely. And thank you for your efforts to make that center stage. This is also Linaro Edge group mist challenging task on the next 6 moths. Knowing that we have lived in a floating situation for over 10 years, I just hope we get consensus across projects and distro providers about the right end goal and migration strategy. > > > It is high time we tidied all this up. I predict it will be much > harder, and much more confusing, in 6 months. > > Regards, > Simon > --=20 Fran=C3=A7ois-Fr=C3=A9d=C3=A9ric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog --0000000000001edcfe05ce3f62a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Simon

Le=C2=A0mer. 13 oct. 2021 =C3=A0 16:49, Simo= n Glass <sjg@chromium.org> a = =C3=A9crit=C2=A0:
Hi Tom, Bin,Fran= =C3=A7ois,

On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > Hi Simon,
> >
> > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote:
> > >
> > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and O= F_HOSTFILE so
> > > there are only three ways to obtain a devicetree:
> > >
> > >=C2=A0 =C2=A0 - OF_SEPARATE - the normal way, where the devic= etree is built and
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0appended to U-Boot
> > >=C2=A0 =C2=A0 - OF_EMBED - for development purposes, the devi= cetree is embedded in
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0the ELF file (also used for EFI) > > >=C2=A0 =C2=A0 - OF_BOARD - the board figures it out on its ow= n
> > >
> > > The last one is currently set up so that no devicetree is ne= eded at all
> > > in the U-Boot tree. Most boards do provide one, but some don= 't. Some
> > > don't even provide instructions on how to boot on the bo= ard.
> > >
> > > The problems with this approach are documented at [1].
> > >
> > > In practice, OF_BOARD is not really distinct from OF_SEPARAT= E. Any board
> > > can obtain its devicetree at runtime, even it is has a devic= etree built
> > > in U-Boot. This is because U-Boot may be a second-stage boot= loader and its
> > > caller may have a better idea about the hardware available i= n the machine.
> > > This is the case with a few QEMU boards, for example.
> > >
> > > So it makes no sense to have OF_BOARD as a 'choice'.= It should be an
> > > option, available with either OF_SEPARATE or OF_EMBED.
> > >
> > > This series makes this change, adding various missing device= tree files
> > > (and placeholders) to make the build work.
> >
> > Adding device trees that are never used sounds like a hack to me.=
> >
> > For QEMU, device tree is dynamically generated on the fly based o= n
> > command line parameters, and the device tree you put in this seri= es
> > has various hardcoded <phandle> values which normally do no= t show up
> > in hand-written dts files.
> >
> > I am not sure I understand the whole point of this.
>
> I am also confused and do not like the idea of adding device trees for=
> platforms that are capable of and can / do have a device tree to give = us
> at run time.

(I'll just reply to this one email, since the same points applies to all replies I think)

I have been thinking about this and discussing it with people for a
few months now. I've been signalling a change like this for over a
month now, on U-Boot contributor calls and in discussions with Linaro
people. I sent a patch (below) to try to explain things. I hope it is
not a surprise!

The issue here is that we need a devicetree in-tree in U-Boot, to
avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
Ilias' series and this one we can get ourselves on a stronger footing.<= br> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
For more context:

http://pat= chwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium= .org/

BTW I did suggest to QEMU ARM that they support a way of adding the
u-boot.dtsi but there was not much interest there (in fact the
maintainer would prefer there was no special support even for booting
Linux directly!)
i understand their point of = view and agree with it.
B= ut in any case it doesn't really help U-Boot. I
think the path forward might be to run QEMU twice, once to get its
generated tree and once to give the 'merged' tree with the U-Boot properties in it, if people want to use U-Boot features.

I do strongly believe that OF_BOARD must be a run-time option, not a
build-time one. It creates all sorts of problems and obscurity which
have taken months to unpick. See the above patch for the rationale.

To add to that rationale, OF_BOARD needs to be an option available to
any board. At some point in the future it may become a common way
things are done, e.g. TF-A calling U-Boot and providing a devicetree
to it. It doesn't make any sense to have people decide whether or not to set OF_BOARD at build time, thus affecting how the image is put
together. We'll end up with different U-Boot build targets like
capricorn, capricorn_of_board and the like. It should be obvious where
that will lead. Instead, OF_BOARD needs to become a commonly used
option, perhaps enabled by most/all boards, so that this sort of build
explosion is not needed.
If you mean that wh= en boards are by construction providing a DTB to U-Boot then I agree very m= uch. But I don=E2=80=99t understand how the patch set =C2=A0supports it as = it puts dts files for those boards to be built.
U-Boot needs to be flexible enough to
function correctly in whatever runtime environment in which it finds
itself.

Also as binman is pressed into service more and more to build the
complex firmware images that are becoming fashionable, it needs a
definition (in the devicetree) that describes how to create the image.
We can't support that unless we are building a devicetree, nor can the<= br> running program access the image layout without that information.

Fran=C3=A7ois's point about 'don't use this with any kernel'= ; is
germane...but of course I am not suggesting doing that, since OF_BOARD
is, still, enabled. We already use OF_BOARD for various boards that
include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example
(as I said in the cover letter "Most boards do provide one, but some don't."). So this series is just completing the picture by enforci= ng
that *some sort* of devicetree is always present.
That seems inconsistent with the OF_BOARD be= comes the default.

I can't quite pinpoint the patch where U-Boot started allowing the
devicetree to be omitted, but if people are interested I could try a
little harder. It was certainly not my intention (putting on my
device-tree-maintainer hat) to go down that path and it slipped in
somehow in all the confusion. I'm not sure anyone could tell you that rpi_3 has an in-tree devicetree but rpi_4 does not...

Anyway this series is very modest. It just adds the requirement that
all in-tree boards have some sort of sample devicetree and preferably
some documentation as to where it might come from at runtime.
=
That=E2=80=99s a very good goal. But adding files in dts = make them not samples but templates to be used and replace board provided D= TB.=C2=A0
If you push all your DTS files in document= ation, you do what you say: adding sample files.
That
should not be a tough call IMO. Assuming we can get the validation in
place (mentioned by Rob Herring recently) it will be quite natural to
sync them between (presumably) Linux and U-Boot.

I am also quite happy to discuss what should actually be in these
devicetree files and whether some of them should be essentially empty.
As you probably noticed, some of them are empty since I literally
could not figure out where they come from! But there needs to be at
least some skeleton for U-Boot to progress, since devicetree is
critical to its feature set.
absolutely. And = thank you for your efforts to make that center stage. This is also Linaro E= dge group mist challenging =C2=A0task on the next 6 moths. Knowing that we = have lived in a floating situation for over 10 years, I just hope we get co= nsensus across projects and distro providers about the right end goal and m= igration strategy.


It is high time we tidied all this up. I predict it will be much
harder, and much more confusing, in 6 months.

Regards,
Simon
--
<= 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

--0000000000001edcfe05ce3f62a1-- 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 95C6DC433F5 for ; Wed, 13 Oct 2021 17:36:42 +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 CCA2A610EA for ; Wed, 13 Oct 2021 17:36:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org CCA2A610EA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 325948360F; Wed, 13 Oct 2021 19:36:40 +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="x1gQXX6U"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 2FFB48357B; Wed, 13 Oct 2021 19:35:25 +0200 (CEST) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 CF5B18360D for ; Wed, 13 Oct 2021 19:35:08 +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-ed1-x52b.google.com with SMTP id w19so13607141edd.2 for ; Wed, 13 Oct 2021 10:35:08 -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=R2WvOoqhbIghO8aKyK2+KSmhyIF+gSA6nIf0bsPVmfs=; b=x1gQXX6UoW7q6hZTeIKMPz/CGbwqSZSdEA6irV/cJPVPWpJaaokfJhzyyZAOgWzZBZ id77jA4HonEbtWkZHwXgaMgyDq7qtD8vgioQStho/A1pUquAv9YfMZldTR9Myp4gSA0O nFIoHUSPGzYFAgqORJx/+Lry9MRXD+av3ZSOsSxebO4a7ahntm/WIDnYehdFvMaXsAlM g/J4QcOssNKdk692Ik3T0sTsToNvcLhYcFcxyO+lOlO9VvkHUlY33yure1tsbyONuaWT fO+om0pKkjoLoqohUMbCcW6x72PopAk7yJBRdqoXBDdCSuW9smBquPdGgKEa/V1rxPcx FDHA== 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=R2WvOoqhbIghO8aKyK2+KSmhyIF+gSA6nIf0bsPVmfs=; b=5lyonIQfMNhGm60a33EE8/KUr3nxSv/UvD1FeTzCkUfxevXfHJ533o9uvZ3E7bA+B/ EyRS24QP2wvc6r5cNxCD9zmQuy+q6VfTP0BpFigMCzg0Eanv5wnCTBK7LvQr9A518xQi 9l3jsOBaC9DSs+wupLQextEpNvJ0gTHOYZWS9W+asciU3y7tUPTyV8m8rrcCxeesUWdt qyAvuhw6RoVPci94FYFcabji2JRci0Yd0nrkPQetQ/A7ydbRE+t0g/xnGKbcwd1y5mTJ oOLUUS93poqr8/RZmO7nOJrtFKM18stzQXkuT2hF+x5oknlKcdJ6q2oMsMeDHLvpd4Rr kwYQ== X-Gm-Message-State: AOAM530vgXLpMv6KJc4lp1h15jClwi+t2b9IVs8NFZzCNIASJ1PQWce3 3kh0+KcICRGSYTGK8G6eoKCvkzGszUGDM4limnHXiQ== X-Google-Smtp-Source: ABdhPJxLF1NIrsRpEvR8jmmqYRkDrsaVaX68h7Q/nMJd66C3gn7wMCU4+K+Sf0BTHhMqjzMOH0owbjxYxS8SeSt2Lmk= X-Received: by 2002:a17:906:94da:: with SMTP id d26mr661557ejy.213.1634146507995; Wed, 13 Oct 2021 10:35:07 -0700 (PDT) MIME-Version: 1.0 References: <20211013010120.96851-1-sjg@chromium.org> <20211013013450.GJ7964@bill-the-cat> In-Reply-To: From: =?UTF-8?Q?Fran=C3=A7ois_Ozog?= Date: Wed, 13 Oct 2021 19:34:57 +0200 Message-ID: Subject: Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option To: Simon Glass Cc: Aaron Williams , Albert Aribaud , Alexander Graf , Anastasiia Lukianenko , Andre Przywara , Ashok Reddy Soma , Atish Patra , Bin Meng , Bin Meng , Christian Hewitt , David Abdurachmanov , Dimitri John Ledkov , Fabio Estevam , Green Wan , Heiko Schocher , Heinrich Schuchardt , Heinrich Schuchardt , Ilias Apalodimas , Jagan Teki , Jerry Van Baren , Kever Yang , Leo , Linus Walleij , Liviu Dudau , =?UTF-8?B?TWFyZWsgQmVow7pu?= , Matthias Brugger , Michal Simek , Michal Simek , Neil Armstrong , Niel Fourie , Oleksandr Andrushchenko , Padmarao Begari , =?UTF-8?Q?Pali_Roh=C3=A1r?= , Peter Robinson , Priyanka Jain , Rainer Boschung , Ramon Fried , Rick Chen , Sean Anderson , Sinan Akman , Stefan Roese , Stephen Warren , Stephen Warren , T Karthik Reddy , Tero Kristo , Thomas Fitzsimmons , Tianrui Wei , Tim Harvey , Tom Rini , Tuomas Tynkkynen , U-Boot Mailing List , Valentin Longchamp , Vladimir Oltean , Wolfgang Denk , Zong Li , "qemu-devel@nongnu.org Developers" X-Mailman-Approved-At: Wed, 13 Oct 2021 19:36:38 +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 Hi Simon Le mer. 13 oct. 2021 =C3=A0 16:49, Simon Glass a =C3=A9c= rit : > Hi Tom, Bin,Fran=C3=A7ois, > > On Tue, 12 Oct 2021 at 19:34, Tom Rini wrote: > > > > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > Hi Simon, > > > > > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass wrote: > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE = so > > > > there are only three ways to obtain a devicetree: > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built an= d > > > > appended to U-Boot > > > > - OF_EMBED - for development purposes, the devicetree is embedde= d > in > > > > the ELF file (also used for EFI) > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > The last one is currently set up so that no devicetree is needed at > all > > > > in the U-Boot tree. Most boards do provide one, but some don't. Som= e > > > > don't even provide instructions on how to boot on the board. > > > > > > > > The problems with this approach are documented at [1]. > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any > board > > > > can obtain its devicetree at runtime, even it is has a devicetree > built > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader > and its > > > > caller may have a better idea about the hardware available in the > machine. > > > > This is the case with a few QEMU boards, for example. > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be a= n > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > This series makes this change, adding various missing devicetree > files > > > > (and placeholders) to make the build work. > > > > > > Adding device trees that are never used sounds like a hack to me. > > > > > > For QEMU, device tree is dynamically generated on the fly based on > > > command line parameters, and the device tree you put in this series > > > has various hardcoded values which normally do not show up > > > in hand-written dts files. > > > > > > I am not sure I understand the whole point of this. > > > > I am also confused and do not like the idea of adding device trees for > > platforms that are capable of and can / do have a device tree to give u= s > > at run time. > > (I'll just reply to this one email, since the same points applies to > all replies I think) > > I have been thinking about this and discussing it with people for a > few months now. I've been signalling a change like this for over a > month now, on U-Boot contributor calls and in discussions with Linaro > people. I sent a patch (below) to try to explain things. I hope it is > not a surprise! > > The issue here is that we need a devicetree in-tree in U-Boot, to > avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD, > BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between > Ilias' series and this one we can get ourselves on a stronger footing. > There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use. > For more context: > > > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-= sjg@chromium.org/ > > BTW I did suggest to QEMU ARM that they support a way of adding the > u-boot.dtsi but there was not much interest there (in fact the > maintainer would prefer there was no special support even for booting > Linux directly!) i understand their point of view and agree with it. > But in any case it doesn't really help U-Boot. I > think the path forward might be to run QEMU twice, once to get its > generated tree and once to give the 'merged' tree with the U-Boot > properties in it, if people want to use U-Boot features. > > I do strongly believe that OF_BOARD must be a run-time option, not a > build-time one. It creates all sorts of problems and obscurity which > have taken months to unpick. See the above patch for the rationale. > > To add to that rationale, OF_BOARD needs to be an option available to > any board. At some point in the future it may become a common way > things are done, e.g. TF-A calling U-Boot and providing a devicetree > to it. It doesn't make any sense to have people decide whether or not > to set OF_BOARD at build time, thus affecting how the image is put > together. We'll end up with different U-Boot build targets like > capricorn, capricorn_of_board and the like. It should be obvious where > that will lead. Instead, OF_BOARD needs to become a commonly used > option, perhaps enabled by most/all boards, so that this sort of build > explosion is not needed. If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don=E2=80=99t understand how the patch set s= upports it as it puts dts files for those boards to be built. > U-Boot needs to be flexible enough to > function correctly in whatever runtime environment in which it finds > itself. > > Also as binman is pressed into service more and more to build the > complex firmware images that are becoming fashionable, it needs a > definition (in the devicetree) that describes how to create the image. > We can't support that unless we are building a devicetree, nor can the > running program access the image layout without that information. > > Fran=C3=A7ois's point about 'don't use this with any kernel' is > germane...but of course I am not suggesting doing that, since OF_BOARD > is, still, enabled. We already use OF_BOARD for various boards that > include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example > (as I said in the cover letter "Most boards do provide one, but some > don't."). So this series is just completing the picture by enforcing > that *some sort* of devicetree is always present. > That seems inconsistent with the OF_BOARD becomes the default. > > I can't quite pinpoint the patch where U-Boot started allowing the > devicetree to be omitted, but if people are interested I could try a > little harder. It was certainly not my intention (putting on my > device-tree-maintainer hat) to go down that path and it slipped in > somehow in all the confusion. I'm not sure anyone could tell you that > rpi_3 has an in-tree devicetree but rpi_4 does not... > > Anyway this series is very modest. It just adds the requirement that > all in-tree boards have some sort of sample devicetree and preferably > some documentation as to where it might come from at runtime. That=E2=80=99s a very good goal. But adding files in dts make them not samp= les but templates to be used and replace board provided DTB. If you push all your DTS files in documentation, you do what you say: adding sample files. > That > should not be a tough call IMO. Assuming we can get the validation in > place (mentioned by Rob Herring recently) it will be quite natural to > sync them between (presumably) Linux and U-Boot. > > I am also quite happy to discuss what should actually be in these > devicetree files and whether some of them should be essentially empty. > As you probably noticed, some of them are empty since I literally > could not figure out where they come from! But there needs to be at > least some skeleton for U-Boot to progress, since devicetree is > critical to its feature set. absolutely. And thank you for your efforts to make that center stage. This is also Linaro Edge group mist challenging task on the next 6 moths. Knowing that we have lived in a floating situation for over 10 years, I just hope we get consensus across projects and distro providers about the right end goal and migration strategy. > > > It is high time we tidied all this up. I predict it will be much > harder, and much more confusing, in 6 months. > > Regards, > Simon > --=20 Fran=C3=A7ois-Fr=C3=A9d=C3=A9ric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog