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 F003AC433F5 for ; Wed, 27 Oct 2021 22:03:23 +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 41F1E60551 for ; Wed, 27 Oct 2021 22:03:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 41F1E60551 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]:47664 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mfr10-00083d-6G for qemu-devel@archiver.kernel.org; Wed, 27 Oct 2021 18:03:22 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41684) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mfqyl-0007H0-Lv for qemu-devel@nongnu.org; Wed, 27 Oct 2021 18:01:03 -0400 Received: from mail-ed1-x530.google.com ([2a00:1450:4864:20::530]:42919) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mfqyf-0005m6-SN for qemu-devel@nongnu.org; Wed, 27 Oct 2021 18:01:02 -0400 Received: by mail-ed1-x530.google.com with SMTP id w15so16326599edc.9 for ; Wed, 27 Oct 2021 15:00:56 -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=YHpK71gIOBFZpc15eR1qwmXIBAm9KU/tZNN2DGq2T5k=; b=tuVRuVdahPtKqHGRSvxYF/m1uD8oTBSYfVJK8FAlf79zgaJVdmmMXje/1U+v9cvprP nPgYl97Fhpbr8muU0PiPhEVIPTfoDzsfi6lELahqxkYw5pdW+/lTFBnCpneAdjJlPANJ 10q8SwvHOOg+570TPAahAAsCsAKk7K0bsKn5m7WukuAEXm5uO0rlvmd3DlerKuh/FCyB 38cs+EpWr62zD38dhMS+EVzHaTkCCy9gtOwvGfCBxJZPAmLzWvACxebBx8JT3xKyUpzt c4Y3Oc7gqVhkfXzn9FB7V9nC+RgKnTYCfX4fac+yxzBwFFv1u2g4dRvazFSqXrUTx5PA 2D7g== 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=YHpK71gIOBFZpc15eR1qwmXIBAm9KU/tZNN2DGq2T5k=; b=VRRcSAPrvY+frkdfuyqljFWV2+/lXU1Z5zWpPDHBYxvgrkQCv3CxigupIJbsjJdVXd F3+Qix2H0ovwoB7RRIg8GMxQqZfIodzWQImRqZWMUfzcJIvXCefvOBs5sOtvE3AG+t5m +cIPp/MZuoi353GWaDKoMf8CnYr3gLMFlUFYy67nkuR6BQogvYMs1f+sCf7IY7tLF/h6 Dzw1pxLzlmnNMhilcE1zUVKgw8CLwb7os5IKpIxTa8ofIjxLcNMoHzPOXSsHSKjTKsCj tQWwboFowiYOeaG8b7V8eMKN+CGpEDa8nlgOJe+mZEWnQ6mQkYsMKPYnCDvVQFmf5Iqd ppTw== X-Gm-Message-State: AOAM530x9080cR3iasMb3I/JaO2Pivita9tVgU3AO2OlWcYOv3Vj683F /tzfkACSQG4rz8oolkpY7tdscVk2uuBdqtasJR1c5A== X-Google-Smtp-Source: ABdhPJyHQfCNLlktIEd5sQoPuERGNCRBojUjDX/9IBnWvZjC6yGdh4q0u3IpFv7OQEj4ZmqUu2k6LBMo8sfgxDdwMrk= X-Received: by 2002:a17:906:c102:: with SMTP id do2mr263368ejc.111.1635372055576; Wed, 27 Oct 2021 15:00:55 -0700 (PDT) MIME-Version: 1.0 References: <20211014145626.GC7964@bill-the-cat> <20211014152801.GF7964@bill-the-cat> <20211027124840.GR8284@bill-the-cat> <20211027190649.GI8284@bill-the-cat> In-Reply-To: <20211027190649.GI8284@bill-the-cat> From: =?UTF-8?Q?Fran=C3=A7ois_Ozog?= Date: Thu, 28 Oct 2021 00:00:44 +0200 Message-ID: Subject: Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option To: Tom Rini Content-Type: multipart/alternative; boundary="00000000000072ddf305cf5cba64" Received-SPF: pass client-ip=2a00:1450:4864:20::530; envelope-from=francois.ozog@linaro.org; helo=mail-ed1-x530.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@foss.arm.com, narmstrong@baylibre.com, rick@andestech.com, vladimir.oltean@nxp.com, linus.walleij@linaro.org, fitzsim@fitzsim.org, kever.yang@rock-chips.com, seanga2@gmail.com, atish.patra@wdc.com, zong.li@sifive.com, sr@denx.de, festevam@gmail.com, rainer.boschung@hitachi-powergrids.com, Mark Kettenis , swarren@nvidia.com, oleksandr_andrushchenko@epam.com, xypron.glpk@gmx.de, lusus@denx.de, michal.simek@xilinx.com, marek.behun@nic.cz, vanbaren@cideas.com, rfried.dev@gmail.com, jagan@amarulasolutions.com, valentin.longchamp@hitachi-powergrids.com, hs@denx.de, pbrobinson@gmail.com, sinan@writeme.com, bin.meng@windriver.com, wd@denx.de, swarren@wwwdotorg.org, andre.przywara@arm.com, tharvey@gateworks.com, ashok.reddy.soma@xilinx.com, qemu-devel@nongnu.org, agraf@csgraf.de, green.wan@sifive.com, t.karthik.reddy@xilinx.com, anastasiia_lukianenko@epam.com, albert.u.boot@aribaud.net, monstr@monstr.eu, mbrugger@suse.com, ycliang@andestech.com, kristo@kernel.org, u-boot@lists.denx.de, david.abdurachmanov@sifive.com, priyanka.jain@nxp.com, sjg@chromium.org, ilias.apalodimas@linaro.org, christianshewitt@gmail.com, awilliams@marvell.com, tuomas.tynkkynen@iki.fi, heinrich.schuchardt@canonical.com, tianrui-wei@outlook.com, bmeng.cn@gmail.com, pali@kernel.org, dimitri.ledkov@canonical.com, padmarao.begari@microchip.com Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --00000000000072ddf305cf5cba64 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tom Le mer. 27 oct. 2021 =C3=A0 21:06, Tom Rini a =C3=A9cr= it : > On Wed, Oct 27, 2021 at 06:02:19PM +0200, Fran=C3=A7ois Ozog wrote: > > Hi Mark, > > > > On Wed, 27 Oct 2021 at 17:10, Mark Kettenis > wrote: > > > > > > From: Fran=C3=A7ois Ozog > > > > Date: Wed, 27 Oct 2021 15:15:01 +0200 > > > > > > > > Hi, > > > > > > > > On Wed, 27 Oct 2021 at 14:48, Tom Rini wrote: > > > > > > > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > > > > > > Hi all, > > > > > > > > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini > wrote: > > > > > > > > > > > > > > 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 < > > > 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 Glass < > > > > > sjg@chromium.org> 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 is embedded in > > > > > > > > > > >> > > > the ELF file (also used for EFI) > > > > > > > > > > >> > > > - OF_BOARD - the board figures it out on it= s > 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 > > > > > 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 hardwa= re > > > > > 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 to me. > > > > > > > > > > >> > > > > > > > > > > > > >> > > For QEMU, device tree is dynamically generated o= n > 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 > > > > > applies to > > > > > > > > > > >> all replies I think) > > > > > > > > > > >> > > > > > > > > > > >> I have been thinking about this and discussing it wi= th > > > 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 wa= y > of > > > > > adding the > > > > > > > > > > >> u-boot.dtsi but there was not much interest there (i= n > > > 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-ti= me > > > > > 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 deci= de > > > > > whether or not > > > > > > > > > > >> to set OF_BOARD at build time, thus affecting how th= e > > > image > > > > > is put > > > > > > > > > > >> together. We'll end up with different U-Boot build > targets > > > > > like > > > > > > > > > > >> capricorn, capricorn_of_board and the like. It shoul= d > 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 underst= and how > the > > > patch > > > > > set supports it as it puts dts files for those boards to be buil= t. > > > > > > > > > > >> > > > > > > > > > > >> U-Boot needs to be flexible enough to > > > > > > > > > > >> function correctly in whatever runtime environment i= n > > > 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 an= d > 3, > > > for > > > > > example > > > > > > > > > > >> (as I said in the cover letter "Most boards do provi= de > > > 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 > > > > > this > > > > > > > > > > issue, is that OF_BOARD needs to be a run-time option. = At > > > > > present it > > > > > > > > > > has build-time effects and this is quite wrong. If you = go > > > > > through 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 > > > for > > > > > 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, > > > maybe > > > > > > > > > here's the biggest sticking point. To be clear, you agre= e > that > > > > > U-Boot > > > > > > > > > needs to support being passed a device tree to use, at ru= n > > > 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 > > > > > given > > > > > > > > > one at run time (think Raspberry Pi) ? > > > > > > > > > > > > > > > > I'm not sure it will be that black and white. I suspect the= re > > > 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...". > > > > > > > > > > > > See below. > > > > > > > > > > > > > > > > > > > > > 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 w= e > > > could > > > > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > > > > > > > I want to see less device trees in U-Boot sources, if they ca= n > 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. > > > > > > > > > > > > Firstly I should say that I find building firmware very messy a= nd > > > > > > confusing these days. Lots of things to build and it's hard to > find > > > > > > the instructions. It doesn't have to be that way, but if we > carry on > > > > > > as we are, it will continue to be messy and in five years you > will > > > > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > > > > objective here is to simplify things, bringing some consistency > to > > > the > > > > > > different components. Binman was one effort there. I feel that > > > putting > > > > > > at least the U-Boot house in order, in my role as devicetree > > > > > > maintainer (and as author of devicetree support in U-Boot back = in > > > > > > 2011), is the next step. > > > > > > > > > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh > scripts > > > > > that know where to grab other known-good binaries of varying > licenses > > > > > that are needed to assemble something that boots. > > > > > > > > > > > If we set things up correctly and agree on the bindings, > devicetree > > > > > > can be the unifying configuration mechanism through the whole o= f > > > > > > firmware (except for very early bits) and into the OS, this wil= l > set > > > > > > us up very well to deal with the complexity that is coming. > > > > > > > > > > > > Anyway, here are the mental steps that I've gone through over t= he > > > past > > > > > > two months: > > > > > > > > > > > > Step 1: At present, some people think U-Boot is not even allowe= d > to > > > > > > have its own nodes/properties in the DT. > > > > > > > > In my view U-Boot shall be able to leverage device tree format > (source > > > and > > > > binary) to store its own data. > > > > When you say "the" DT, I always think this is "the" DT that is > passed to > > > OS > > > > and in "that" DT, there should be no U-Boot entries. > > > > > > Why not? As long as the device tree validates, it is perfectly fine > > > to have additional nodes and properties present. The propertiesand > > > nodes will be simply ignored by the OS. > > > > Because of the way we want to organize the firmware supply chain: when > the > > board is built, it is "attached" a device tree. > > At that moment, we don't know what "non trusted firmware" will be used. > It > > could be U-Boot or LinuxBoot (https://www.linuxboot.org) or even EDK2 > (yes > > it works with DT). > > And we aim at keeping device tree as close to the original intent: > hardware > > description only. It's not because we can stuff anything in the DT and > that > > it is simple to do that we should. > > Driver parameters shall be in the OS facility built for that purpose. > Using > > device tree has been an ugly habit. > > So we're going to continue to re-litigate what does and doesn't live in > the device tree for forever, aren't we? To continue to be clear, I'm > not saying that non-upstream bindings should be present. But for > example, Simon is working on the "U-Boot config node" binding, which is > going to get re-spun next as /options/ as I read the thread right. > Populate it and anyone can read it, and probably be getting information > that's useful to U-Boot or LinuxBoot or EDK2 or anyone else. That's why > I keep repeating that projects need to push bindings upstream. I'll > repeat my comment about > > https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index= .html > and the binman node both noting a common problem to solve. i think you are right. Now tfa is comfortable being its own upstream for the binding specifications. Could U-Boot community be comfortable doing so? Now I also recognize that DT specification state is far from clean. If you want full story on PCI ECAM you need Linux/documentation and IEEE text (kind of hosted on DT.org but not easily browasable to). In the long run it may be much better to have all bindings (including U-Boot ones) in DT.org. We should also have information from Qemu about the DT it generates for all its devices and how it is associated to command line . > > > In so far as there's objections to "U-Boot" nodes, it seems to me like > it comes down to "shouldn't need U-Boot internals expressed in DT nor > added to the DTB by someone else". And I've not objected to that > either. But I think we do have a subset of "how do we express ..." > issues that have come down to "well, we buried the bodies over at ... > before". And it's time to dig them up and give them a proper burial > perhaps now :) > > -- > Tom > --=20 Fran=C3=A7ois-Fr=C3=A9d=C3=A9ric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog --00000000000072ddf305cf5cba64 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tom

Le=C2=A0mer. 27 oct. 2021 =C3=A0 21:06, Tom R= ini <trini@konsulko.com> a = =C3=A9crit=C2=A0:
On Wed, Oct 27, 2= 021 at 06:02:19PM +0200, Fran=C3=A7ois Ozog wrote:
> Hi Mark,
>
> On Wed, 27 Oct 2021 at 17:10, Mark Kettenis <mark.kettenis@xs4all.nl> wrot= e:
>
> > > From: Fran=C3=A7ois Ozog <francois.ozog@linaro.org>
> > > Date: Wed, 27 Oct 2021 15:15:01 +0200
> > >
> > > Hi,
> > >
> > > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote: > > >
> > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass w= rote:
> > > > > Hi all,
> > > > >
> > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com>= wrote:
> > > > > >
> > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Sim= on Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini &= lt;trini@konsulko.c= om>
> > 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@chromiu= m.org>
> > > > a =C3=A9crit :
> > > > > > > > > >>
> > > > > > > > > >> Hi Tom, Bin,Fran=C3= =A7ois,
> > > > > > > > > >>
> > > > > > > > > >> On Tue, 12 Oct 2021 a= t 19:34, Tom Rini <
> > trini@kon= sulko.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 <
> > > > s= jg@chromium.org> wrote:
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > With I= lias' efforts we have dropped OF_PRIOR_STAGE
> > and
> > > > OF_HOSTFILE so
> > > > > > > > > >> > > > there = are only three ways to obtain a devicetree:
> > > > > > > > > >> > > >
> > > > > > > > > >> > > >=C2=A0 = =C2=A0 - OF_SEPARATE - the normal way, where the
> > devicetree
> > > > is built and
> > > > > > > > > >> > > >=C2=A0 = =C2=A0 =C2=A0 =C2=A0appended to U-Boot
> > > > > > > > > >> > > >=C2=A0 = =C2=A0 - OF_EMBED - for development purposes, the
> > > > devicetree 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 own
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > The la= st 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= 9;t even provide instructions on how to boot on
> > the
> > > > board.
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > The pr= oblems with this approach are documented at
> > [1].
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > In pra= ctice, OF_BOARD is not really distinct from
> > > > OF_SEPARATE. Any board
> > > > > > > > > >> > > > can ob= tain its devicetree at runtime, even it is
> > has a
> > > > devicetree built
> > > > > > > > > >> > > > in U-B= oot. 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 i= s 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 s= eries makes this change, adding various
> > missing
> > > > devicetree files
> > > > > > > > > >> > > > (and p= laceholders) to make the build work.
> > > > > > > > > >> > >
> > > > > > > > > >> > > Adding devi= ce trees that are never used sounds like a
> > > > hack to me.
> > > > > > > > > >> > >
> > > > > > > > > >> > > For QEMU, d= evice tree is dynamically generated on the
> > fly
> > > > based on
> > > > > > > > > >> > > command lin= e parameters, and the device tree you put
> > in
> > > > this series
> > > > > > > > > >> > > has various= hardcoded <phandle> values which normally
> > do
> > > > not show up
> > > > > > > > > >> > > in hand-wri= tten dts files.
> > > > > > > > > >> > >
> > > > > > > > > >> > > I am not su= re I understand the whole point of this.
> > > > > > > > > >> >
> > > > > > > > > >> > I am also confus= ed and do not like the idea of adding
> > > > device trees for
> > > > > > > > > >> > platforms that a= re 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)<= br> > > > > > > > > > >>
> > > > > > > > > >> 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 patc= h (below) to try to explain things. I
> > > > hope it is
> > > > > > > > > >> not a surprise!
> > > > > > > > > >>
> > > > > > > > > >> The issue here is tha= t we need a devicetree in-tree in
> > > > U-Boot, to
> > > > > > > > > >> avoid the mess that h= as 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_SEPA= RATE, with OF_EMBED for debugging/ELF
> > > > use.
> > > > > > > > > >> For more context:
> > > > > > > > > >>
> > > > > > > > > >>
> > > >
> > = http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sj= g@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 pref= er 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 do= esn't really help U-Boot. I
> > > > > > > > > >> think the path forwar= d might be to run QEMU twice, once to
> > > > get its
> > > > > > > > > >> generated tree and on= ce 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 cr= eates all sorts of problems and
> > > > obscurity which
> > > > > > > > > >> have taken months to = unpick. See the above patch for the
> > > > rationale.
> > > > > > > > > >>
> > > > > > > > > >> To add to that ration= ale, OF_BOARD needs to be an option
> > > > available to
> > > > > > > > > >> any board. At some po= int 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 bu= ild time, thus affecting how the
> > image
> > > > is put
> > > > > > > > > >> together. We'll e= nd up with different U-Boot build targets
> > > > like
> > > > > > > > > >> capricorn, capricorn_= of_board and the like. It should be
> > > > obvious where
> > > > > > > > > >> that will lead. Inste= ad, OF_BOARD needs to become a
> > commonly
> > > > used
> > > > > > > > > >> option, perhaps enabl= ed by most/all boards, so that this
> > sort
> > > > of build
> > > > > > > > > >> explosion is not need= ed.
> > > > > > > > > >
> > > > > > > > > > If you mean that when boa= rds 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=C2=A0 supports it as it puts dts files for those bo= ards to be built.
> > > > > > > > > >>
> > > > > > > > > >> U-Boot needs to be fl= exible enough to
> > > > > > > > > >> function correctly in= whatever runtime environment in
> > which
> > > > it finds
> > > > > > > > > >> itself.
> > > > > > > > > >>
> > > > > > > > > >> Also as binman is pre= ssed into service more and more to
> > build
> > > > the
> > > > > > > > > >> complex firmware imag= es that are becoming fashionable, it
> > > > needs a
> > > > > > > > > >> definition (in the de= vicetree) that describes how to
> > create
> > > > the image.
> > > > > > > > > >> We can't support = that unless we are building a devicetree,
> > > > nor can the
> > > > > > > > > >> running program acces= s the image layout without that
> > > > information.
> > > > > > > > > >>
> > > > > > > > > >> Fran=C3=A7ois's p= oint about 'don't use this with any kernel' is
> > > > > > > > > >> germane...but of cour= se I am not suggesting doing that,
> > since
> > > > OF_BOARD
> > > > > > > > > >> is, still, enabled. W= e already use OF_BOARD for various
> > > > boards that
> > > > > > > > > >> include an in-tree de= vicetree - Raspberry Pi 1, 2 and 3,
> > for
> > > > example
> > > > > > > > > >> (as I said in the cov= er letter "Most boards do provide
> > one,
> > > > but some
> > > > > > > > > >> don't."). So= this series is just completing the picture by
> > > > enforcing
> > > > > > > > > >> that *some sort* of d= evicetree is always present.
> > > > > > > > > >
> > > > > > > > > > That seems inconsistent w= ith the OF_BOARD becomes the
> > default.
> > > > > > > > >
> > > > > > > > > I think the key point that wil= l get you closer to where I am
> > on
> > > > this
> > > > > > > > > issue, is that OF_BOARD needs = to be a run-time option. At
> > > > present it
> > > > > > > > > has build-time effects and thi= s is quite wrong. If you go
> > > > through all
> > > > > > > > > the material I have written on= this I think I have motivated
> > > > that very
> > > > > > > > > clearly.
> > > > > > > > >
> > > > > > > > > Another big issue is that I be= lieve we need ONE devicetree
> > for
> > > > U-Boot,
> > > > > > > > > not two that get merged by U-B= oot. Again I have gone through
> > > > that in a
> > > > > > > > > lot of detail.
> > > > > > > >
> > > > > > > > I have a long long reply to your fi= rst reply here saved, but,
> > maybe
> > > > > > > > here's the biggest sticking poi= nt.=C2=A0 To be clear, you agree that
> > > > U-Boot
> > > > > > > > needs to support being passed a dev= ice tree to use, at run
> > time,
> > > > yes?
> > > > > > >
> > > > > > > Yes. The OF_BOARD feature provides this.=
> > > > > > >
> > > > > > > >
> > > > > > > > And in that case, would not be usin= g 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 ne= ver ever be given the device
> > > > tree at
> > > > > > > > run time (think BeagleBone Black) a= nd one where we will always
> > be
> > > > given
> > > > > > > > one at run time (think Raspberry Pi= ) ?
> > > > > > >
> > > > > > > I'm not sure it will be that black a= nd white. I suspect there
> > will be
> > > > > > > (many) boards which can boot happily wit= h the U-Boot devicetree
> > but
> > > > > > > can also accept one at runtime, if provi= ded. For example, you may
> > > > want
> > > > > > > to boot with or without TF-A or some oth= er, earlier stage.
> > > > > >
> > > > > > I'm not sure I see the value in making th= is a gray area.=C2=A0 There'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 i= t would be nice to not
> > > > have
> > > > > > to re-flash the prior stage to change a DT, a= nd 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
> > at run
> > > > > > time!".=C2=A0 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...".
> > > > >
> > > > > See below.
> > > > >
> > > > > >
> > > > > > > I believe we have got unstuck because OF= _BOARD (perhaps
> > > > inadvertently)
> > > > > > > provided a way to entirely omit a device= tree from U-Boot, thus
> > making
> > > > > > > things like binman and U-Boot /config im= possible, for example.
> > So I
> > > > > > > want to claw that back, so there is alwa= ys some sort of
> > devicetree in
> > > > > > > U-Boot, as we have for rpi_3, etc.
> > > > > >
> > > > > > I really want to see what the binary case loo= ks 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 sou= rces, if they can come
> > > > > > functionally correct from the hardware/our ca= ller.
> > > > > >
> > > > > > And I'm not seeing how we make use of &qu= ot;U-Boot /config" if we also
> > don't
> > > > > > use the device tree from build time at run ti= me, ignoring the
> > device
> > > > > > tree provided to us at run time by the caller= .
> > > > >
> > > > > Firstly I should say that I find building firmware= very messy and
> > > > > confusing these days. Lots of things to build and = it's hard to find
> > > > > the instructions. It doesn't have to be that w= ay, but if we carry on
> > > > > as we are, it will continue to be messy and in fiv= e years you will
> > > > > need a Ph.D and a lucky charm to boot on any moder= n board. My
> > > > > objective here is to simplify things, bringing som= e consistency to
> > the
> > > > > different components. Binman was one effort there.= I feel that
> > putting
> > > > > at least the U-Boot house in order, in my role as = devicetree
> > > > > maintainer (and as author of devicetree support in= U-Boot back in
> > > > > 2011), is the next step.
> > > >
> > > > Yes, it's Not Great.=C2=A0 I don't like my hand= ful of build-BOARD.sh scripts
> > > > that know where to grab other known-good binaries of va= rying licenses
> > > > that are needed to assemble something that boots.
> > > >
> > > > > If we set things up correctly and agree on the bin= dings, devicetree
> > > > > can be the unifying configuration mechanism throug= h the whole of
> > > > > firmware (except for very early bits) and into the= OS, this will set
> > > > > us up very well to deal with the complexity that i= s coming.
> > > > >
> > > > > Anyway, here are the mental steps that I've go= ne through over the
> > past
> > > > > two months:
> > > > >
> > > > > Step 1: At present, some people think U-Boot is no= t even allowed to
> > > > > have its own nodes/properties in the DT.
> > >
> > > In my view U-Boot shall be able to leverage device tree form= at (source
> > and
> > > binary) to store its own data.
> > > When you say "the" DT, I always think this is &quo= t;the" DT that is passed to
> > OS
> > > and in "that" DT, there should be no U-Boot entrie= s.
> >
> > Why not?=C2=A0 As long as the device tree validates, it is perfec= tly fine
> > to have additional nodes and properties present.=C2=A0 The proper= tiesand
> > nodes will be simply ignored by the OS.
>
> Because of the way we want to organize the firmware supply chain: when= the
> board is built, it is "attached" a device tree.
> At that moment, we don't know what "non trusted firmware"= ; will be used. It
> could be U-Boot or LinuxBoot (https://www.linuxboot.org) or even E= DK2 (yes
> it works with DT).
> And we aim at keeping device tree as close to the original intent: har= dware
> description only. It's not because we can stuff anything in the DT= and that
> it is simple to do that we should.
> Driver parameters shall be in the OS facility built for that purpose. = Using
> device tree has been an ugly habit.

So we're going to continue to re-litigate what does and doesn't liv= e in
the device tree for forever, aren't we?=C2=A0 To continue to be clear, = I'm
not saying that non-upstream bindings should be present.=C2=A0 But for
example, Simon is working on the "U-Boot config node" binding, wh= ich is
going to get re-spun next as /options/ as I read the thread right.
Populate it and anyone can read it, and probably be getting information
that's useful to U-Boot or LinuxBoot or EDK2 or anyone else.=C2=A0 That= 's why
I keep repeating that projects need to push bindings upstream.=C2=A0 I'= ll
repeat my comment about
https://trustedfirmwar= e-a.readthedocs.io/en/latest/components/fconf/index.html
and the binman node both noting a common problem to solve.
i think you are right. Now tfa is comfortable being its own u= pstream for the binding specifications. Could U-Boot community be comfortab= le doing so?
Now I also recognize that DT specificat= ion state is far from clean. If you want full story on PCI ECAM you need Li= nux/documentation and IEEE text (kind of hosted on DT.org but not easily br= owasable to). In the long run it may be much better to have all bindings (i= ncluding U-Boot ones) in DT.org.=C2=A0
We should als= o have information from Qemu about the DT it generates for all its devices = and how it is associated to command line .


In so far as there's objections to "U-Boot" nodes, it seems t= o me like
it comes down to "shouldn't need U-Boot internals expressed in DT = nor
added to the DTB by someone else".=C2=A0 And I've not objected to = that
either.=C2=A0 But I think we do have a subset of "how do we express ..= ."
issues that have come down to "well, we buried the bodies over at ...<= br> before".=C2=A0 And it's time to dig them up and give them a proper= burial
perhaps now :)

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

--00000000000072ddf305cf5cba64--