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 F0B15C433F5 for ; Thu, 14 Oct 2021 17:59:50 +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 64C09610EA for ; Thu, 14 Oct 2021 17:59:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 64C09610EA 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]:50988 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mb51B-0000ep-Ie for qemu-devel@archiver.kernel.org; Thu, 14 Oct 2021 13:59:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54652) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mb50T-0008QA-Tf for qemu-devel@nongnu.org; Thu, 14 Oct 2021 13:59:05 -0400 Received: from mail-ed1-x52f.google.com ([2a00:1450:4864:20::52f]:46828) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mb50Q-0004Dx-BT for qemu-devel@nongnu.org; Thu, 14 Oct 2021 13:59:05 -0400 Received: by mail-ed1-x52f.google.com with SMTP id z20so27714648edc.13 for ; Thu, 14 Oct 2021 10:59:01 -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=95/a0RC7F1bdsZXF2H4mPA51a9DbYtwD6fXCeCgva04=; b=x1tXa7Nb3erdErrNirIJhY1ZEvcrPa2MRZbrGg2YvOd/1obJ9BLiGbIB5BEYFq9cZW 1M9HVn0IqSEHt1JXdZJ91vbAxZQ2XYUtTYcOQ4lzU6VdaLzorQzK4aozPbIz3CEC0X/U HmnCX0QaDQsNMhDBu4QSZdinZfaXEWufNeKMUkyDpocbjvEy6DVvR4IZIIDpwxjMpbl3 zXgGA3LGcRVPzlwY4MJsFlT17F4t+qmWeSph3KIF4ZM15rBvCbq2e57cGfOIbLmhH9G/ tRP0U+FProR7XSRy7g2Pcvr7pJDDLjri4Pk4PkRfFXHmCl5/7UKMkeiac4gR2APK1cFA kw3A== 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=95/a0RC7F1bdsZXF2H4mPA51a9DbYtwD6fXCeCgva04=; b=e/1MF02RjRKUoHtibi8j5napHf57o47yTO0Q/+ruIHpTNgwqXe61kH4netpLXoU2Lb SeiQ51/18fn3yX3F/FLMTL/icDnZPg6FZBZ6r49jS24epr4KbFyTyp8+rKL67bXSxWVR SeRt0U8jNCGJf+tnVLc/tTGDIw2nnYtPc61UFqveBes+nnkfQv85COPgIbdO6HsSYD9i D9jYUIyXgM0Wcb5O7uQbdyyMFkV/EBpni+/izsLr9OyFjTWbT7fO8U8OtucuWrO7CH4/ eTuoCMh/879Gib5jGj702Gpyr7YkTeGJHwzFsPabE+PX9/UXh+yZt8X224b5ETvutmLl X1nw== X-Gm-Message-State: AOAM533ucu9xFz8FdfiIcWSIzC3Y1F58PdAVM1SR0A1ERmVXijBlXCq6 /caWFLfcK7xMDUvSEgxG+aDQhSzCSkfYjwDl/k4EYQ== X-Google-Smtp-Source: ABdhPJyU2ptchJ95Y+axeSQdXlBWYB/yUwX7Eqryd3GPzuaB+soixikTn1uYK6e9HAwVVThReas9uobQfXe0kTin5Ic= X-Received: by 2002:a17:906:94da:: with SMTP id d26mr493743ejy.213.1634234340073; Thu, 14 Oct 2021 10:59:00 -0700 (PDT) MIME-Version: 1.0 References: <20211013010120.96851-1-sjg@chromium.org> <20211013013450.GJ7964@bill-the-cat> <20211014145626.GC7964@bill-the-cat> <20211014152801.GF7964@bill-the-cat> In-Reply-To: <20211014152801.GF7964@bill-the-cat> From: =?UTF-8?Q?Fran=C3=A7ois_Ozog?= Date: Thu, 14 Oct 2021 19:58:49 +0200 Message-ID: Subject: Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option To: Tom Rini Content-Type: multipart/alternative; boundary="00000000000051fd6e05ce53d57a" Received-SPF: pass client-ip=2a00:1450:4864:20::52f; envelope-from=francois.ozog@linaro.org; helo=mail-ed1-x52f.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, T_KAM_HTML_FONT_INVALID=0.01 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 , 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 , Simon Glass , 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" --00000000000051fd6e05ce53d57a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le jeu. 14 oct. 2021 =C3=A0 17:28, Tom Rini a =C3=A9cr= it : > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini wrote: > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > Hi Fran=C3=A7ois, > > > > > > > > On Wed, 13 Oct 2021 at 11:35, Fran=C3=A7ois Ozog < > francois.ozog@linaro.org> wrote: > > > > > > > > > > Hi Simon > > > > > > > > > > Le mer. 13 oct. 2021 =C3=A0 16:49, Simon Glass = a > =C3=A9crit : > > > > >> > > > > >> 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 and > > > > >> > > > appended to U-Boot > > > > >> > > > - OF_EMBED - for development purposes, the devicetree i= s > embedded 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. Some > > > > >> > > > don't even provide instructions on how to boot on the boar= d. > > > > >> > > > > > > > >> > > > 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 an > > > > >> > > > 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 t= o > 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 us > > > > >> > at run time. > > > > >> > > > > >> (I'll just reply to this one email, since the same points applie= s > to > > > > >> all replies I think) > > > > >> > > > > >> I have been thinking about this and discussing it with people fo= r > 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, t= o > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD= , > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Betwe= en > > > > >> 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 i= ts > > > > >> generated tree and once to give the 'merged' tree with the U-Boo= t > > > > >> 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 wa= y > > > > >> 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 o= r > not > > > > >> to set OF_BOARD at build time, thus affecting how the image is p= ut > > > > >> 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 use= d > > > > >> 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 > supports 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 th= e > > > > >> 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 think the key point that will get you closer to where I am on thi= s > > > > issue, is that OF_BOARD needs to be a run-time option. At present i= t > > > > has build-time effects and this is quite wrong. If you go through a= ll > > > > the material I have written on this I think I have motivated that > very > > > > clearly. > > > > > > > > Another big issue is that I believe we need ONE devicetree for > U-Boot, > > > > not two that get merged by U-Boot. Again I have gone through that i= n > a > > > > lot of detail. > > > > > > I have a long long reply to your first reply here saved, but, maybe > > > here's the biggest sticking point. To be clear, you agree that U-Boo= t > > > needs to support being passed a device tree to use, at run time, yes? > > > > Yes. The OF_BOARD feature provides this. > > > > > > > > And in that case, would not be using the "fake" tree we built in? > > > > Not at runtime. > > OK. > > > > So is the sticking point here that we really have two classes of > > > devices, one class where we will never ever be given the device tree = at > > > run time (think BeagleBone Black) and one where we will always be giv= en > > > one at run time (think Raspberry Pi) ? > > > > I'm not sure it will be that black and white. I suspect there will be > > (many) boards which can boot happily with the U-Boot devicetree but > > can also accept one at runtime, if provided. For example, you may want > > to boot with or without TF-A or some other, earlier stage. > > I'm not sure I see the value in making this a gray area. There's very > much a class of "never" boards. There's also the class of "can" today. > Maybe as part of a developer iterative flow it would be nice to not have > to re-flash the prior stage to change a DT, and just do it in U-Boot > until things are happy, but I'm not sure what the use case is for > overriding the previous stage. > > Especially since the pushback on this series I think has all been "why > are we copying in a tree to build with? We don't want to use it at run > time!". And then softer push back like "Well, U-Boot says we have to > include the device tree file here, but we won't use it...". > > > I believe we have got unstuck because OF_BOARD (perhaps inadvertently) > > provided a way to entirely omit a devicetree from U-Boot, thus making > > things like binman and U-Boot /config impossible, for example. So I > > want to claw that back, so there is always some sort of devicetree in > > U-Boot, as we have for rpi_3, etc. > > I really want to see what the binary case looks like since we could then > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could > then also do a rpi_arm32_defconfig too. > > I want to see less device trees in U-Boot sources, if they can come > functionally correct from the hardware/our caller. > > And I'm not seeing how we make use of "U-Boot /config" if we also don't > use the device tree from build time at run time, ignoring the device > tree provided to us at run time by the caller. +1 if there is a complex build problem to solve when no DT is needed when OF_BOARD is needed i could agree to temporarily have a void.dts like /dts-v1/; / { /* required to pass build until proper makefike for OF_BOARD */ }; But not pseudo dts for boards that provide a DT to U-Boot. The pseudo dts are good for reference in the documentation part of the tree. > > -- > Tom > --=20 Fran=C3=A7ois-Fr=C3=A9d=C3=A9ric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog --00000000000051fd6e05ce53d57a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Le=C2=A0jeu. 14 oct. 2021 =C3=A0 17:28, Tom Rini <trini@konsulko.com> a =C3=A9crit=C2= =A0:
On Thu, Oct 14, 2021 at 09:17:52AM -0600, Si= mon Glass wrote:
> Hi Tom,
>
> On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > Hi Fran=C3=A7ois,
> > >
> > > On Wed, 13 Oct 2021 at 11:35, Fran=C3=A7ois Ozog <francois.ozog@linaro= .org> wrote:
> > > >
> > > > Hi Simon
> > > >
> > > > Le mer. 13 oct. 2021 =C3=A0 16:49, Simon Glass <sjg@chromium.org> = a =C3=A9crit :
> > > >>
> > > >> 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 Gla= ss <sjg@chromium.o= rg> wrote:
> > > >> > > >
> > > >> > > > With Ilias' efforts we have drop= ped OF_PRIOR_STAGE and OF_HOSTFILE so
> > > >> > > > there are only three ways to obtain = a devicetree:
> > > >> > > >
> > > >> > > >=C2=A0 =C2=A0 - OF_SEPARATE - the nor= mal way, where the devicetree is built and
> > > >> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0appended t= o U-Boot
> > > >> > > >=C2=A0 =C2=A0 - OF_EMBED - for develo= pment purposes, the devicetree is embedded in
> > > >> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0the ELF fi= le (also used for EFI)
> > > >> > > >=C2=A0 =C2=A0 - 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 p= rovide one, but some don't. Some
> > > >> > > > 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 ma= y 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 boa= rds, for example.
> > > >> > > >
> > > >> > > > So it makes no sense to have OF_BOAR= D as a 'choice'. It should be an
> > > >> > > > option, available with either OF_SEP= ARATE or OF_EMBED.
> > > >> > > >
> > > >> > > > This series makes this change, addin= g various missing devicetree files
> > > >> > > > (and placeholders) to make the build= work.
> > > >> > >
> > > >> > > Adding device trees that are never used s= ounds like a hack to me.
> > > >> > >
> > > >> > > For QEMU, device tree is dynamically gene= rated on the fly based on
> > > >> > > command line parameters, and the device t= ree you put in this series
> > > >> > > has various hardcoded <phandle> val= ues which normally do not show up
> > > >> > > in hand-written dts files.
> > > >> > >
> > > >> > > I am not sure I understand the whole poin= t 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 hav= e a device tree to give us
> > > >> > at run time.
> > > >>
> > > >> (I'll just reply to this one email, since the s= ame points applies to
> > > >> all replies I think)
> > > >>
> > > >> I have been thinking about this and discussing it w= ith people for a
> > > >> few months now. I've been signalling a change l= ike this for over a
> > > >> month now, on U-Boot contributor calls and in discu= ssions with Linaro
> > > >> people. I sent a patch (below) to try to explain th= ings. 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_ST= AGE, OF_BOARD,
> > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HO= STFILE. Between
> > > >> Ilias' series and this one we can get ourselves= on a stronger footing.
> > > >> There is just OF_SEPARATE, with OF_EMBED for debugg= ing/ELF use.
> > > >> For more context:
> > > >>
> > > >> http://patchwork.ozlabs.org/project/uboot/patch/2021091921511= 1.3830278-3-sjg@chromium.org/
> > > >>
> > > >> BTW I did suggest to QEMU ARM that they support a w= ay of adding the
> > > >> u-boot.dtsi but there was not much interest there (= in fact the
> > > >> maintainer would prefer there was no special suppor= t 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 feat= ures.
> > > >>
> > > >> I do strongly believe that OF_BOARD must be a run-t= ime option, not a
> > > >> build-time one. It creates all sorts of problems an= d obscurity which
> > > >> have taken months to unpick. See the above patch fo= r the rationale.
> > > >>
> > > >> To add to that rationale, OF_BOARD needs to be an o= ption available to
> > > >> any board. At some point in the future it may becom= e a common way
> > > >> things are done, e.g. TF-A calling U-Boot and provi= ding 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 t= he image is put
> > > >> together. We'll end up with different U-Boot bu= ild targets like
> > > >> capricorn, capricorn_of_board and the like. It shou= ld 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 provid= ing a DTB to U-Boot then I agree very much. But I don=E2=80=99t understand = how the patch set=C2=A0 supports it as it puts dts files for those boards t= o 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 mor= e to build the
> > > >> complex firmware images that are becoming fashionab= le, it needs a
> > > >> definition (in the devicetree) that describes how t= o create the image.
> > > >> We can't support that unless we are building a = devicetree, nor can the
> > > >> running program access the image layout without tha= t information.
> > > >>
> > > >> Fran=C3=A7ois's point about 'don't use = this with any kernel' is
> > > >> germane...but of course I am not suggesting doing t= hat, since OF_BOARD
> > > >> is, still, enabled. We already use OF_BOARD for var= ious boards that
> > > >> include an in-tree devicetree - Raspberry Pi 1, 2 a= nd 3, for example
> > > >> (as I said in the cover letter "Most boards do= provide one, but some
> > > >> don't."). So this series is just completin= g the picture by enforcing
> > > >> that *some sort* of devicetree is always present. > > > >
> > > > That seems inconsistent with the OF_BOARD becomes the d= efault.
> > >
> > > I think the key point that will get you closer to where I am= on this
> > > issue, is that OF_BOARD needs to be a run-time option. At pr= esent it
> > > has build-time effects and this is quite wrong. If you go th= rough all
> > > the material I have written on this I think I have motivated= that very
> > > clearly.
> > >
> > > Another big issue is that I believe we need ONE devicetree f= or U-Boot,
> > > not two that get merged by U-Boot. Again I have gone through= that in a
> > > lot of detail.
> >
> > I have a long long reply to your first reply here saved, but, may= be
> > here's the biggest sticking point.=C2=A0 To be clear, you agr= ee that U-Boot
> > needs to support being passed a device tree to use, at run time, = yes?
>
> Yes. The OF_BOARD feature provides this.
>
> >
> > And in that case, would not be using the "fake" tree we= built in?
>
> Not at runtime.

OK.

> > So is the sticking point here that we really have two classes of<= br> > > devices, one class where we will never ever be given the device t= ree at
> > run time (think BeagleBone Black) and one where we will always be= given
> > one at run time (think Raspberry Pi) ?
>
> I'm not sure it will be that black and white. I suspect there will= be
> (many) boards which can boot happily with the U-Boot devicetree but > can also accept one at runtime, if provided. For example, you may want=
> to boot with or without TF-A or some other, earlier stage.

I'm not sure I see the value in making this a gray area.=C2=A0 There= 9;s very
much a class of "never" boards.=C2=A0 There's also the class = of "can" today.
Maybe as part of a developer iterative flow it would be nice to not have to re-flash the prior stage to change a DT, and just do it in U-Boot
until things are happy, but I'm not sure what the use case is for
overriding the previous stage.

Especially since the pushback on this series I think has all been "why=
are we copying in a tree to build with?=C2=A0 We don't want to use it a= t run
time!".=C2=A0 And then softer push back like "Well, U-Boot says w= e have to
include the device tree file here, but we won't use it...".

> I believe we have got unstuck because OF_BOARD (perhaps inadvertently)=
> provided a way to entirely omit a devicetree from U-Boot, thus making<= br> > things like binman and U-Boot /config impossible, for example. So I > want to claw that back, so there is always some sort of devicetree in<= br> > U-Boot, as we have for rpi_3, etc.

I really want to see what the binary case looks like since we could then kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
then also do a rpi_arm32_defconfig too.

I want to see less device trees in U-Boot sources, if they can come
functionally correct from the hardware/our caller.

And I'm not seeing how we make use of "U-Boot /config" if we = also don't
use the device tree from build time at run time, ignoring the device
tree provided to us at run time by the caller.
+1
if there is a complex build problem to solve wh= en no DT is needed when OF_BOARD is needed i could agree to temporarily hav= e a void.dts like

/dts-v1/= ;
/ {
=
/* required to pass bui= ld until proper makefike for OF_BOARD */
};

But not pseudo dts= for boards that provide a DT to U-Boot. The pseudo dts are good for refere= nce in the documentation part of the tree.



--
Tom
--
<= 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

--00000000000051fd6e05ce53d57a--