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 1F219C433FE for ; Thu, 14 Oct 2021 14:57:49 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A71C261151 for ; Thu, 14 Oct 2021 14:57:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org A71C261151 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=nongnu.org Received: from localhost ([::1]:43872 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mb2B1-0004rV-Dl for qemu-devel@archiver.kernel.org; Thu, 14 Oct 2021 10:57:47 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34482) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mb29u-00046M-Te for qemu-devel@nongnu.org; Thu, 14 Oct 2021 10:56:39 -0400 Received: from mail-qk1-x72c.google.com ([2607:f8b0:4864:20::72c]:37415) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mb29p-0007jM-3W for qemu-devel@nongnu.org; Thu, 14 Oct 2021 10:56:38 -0400 Received: by mail-qk1-x72c.google.com with SMTP id bl14so5675650qkb.4 for ; Thu, 14 Oct 2021 07:56:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=JJlJlWnWHPEHuZhLZDrvVcK4s/9t1luNJh3IAjIpxm4=; b=f2uNOAp0lDh6xKZx7YL2Qqg0+qTLCPxQLx60V5kLepCStQIYTEUrSUNIY5fdkpKUN3 9HFPFYYRdeg9Q0m3Fin1CBlulszn8hKAAtp2/ZDhHdQajf5agPsRFUt7A2CJ39mVc6Gl OzMP6/xqZP2Gakg5FTJvpiSMK4E6HHhwptVJY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=JJlJlWnWHPEHuZhLZDrvVcK4s/9t1luNJh3IAjIpxm4=; b=gouWyeED0mvezVusvBZDTdCuJzhgs1V23k8OnEKzY/+TE7vjcjQXigNzd6C3Kv5Nev L905R0xtqXTEMQ2iDonoZM1e1C5ubfXngQ6yr1AK8hdyHAQTD/7xr3rXtzC7Q5rr143g Z2wek970rbgk6v2+SqZrE9KPhDHLJpnaVyfrCR32yA+hhEeLRw5iYlFHa+0dBS6+KuN/ 3rWpu4cgQyJ2EfkW9LMXgpl+03YmebbyIASC6XljYqkhNi/ZyrZiY+NJWULmXGwu8L+a VUwh55LJ6/oppJcGV6bQKp8NjcB0jm5dpHbUnMOF45TIDJchb2cRmcpgytx9qBH/I8Dm FNow== X-Gm-Message-State: AOAM5323g0ZhpSafbWQHaiNQB/mwTEX9RmBMCugB+TOBoQ7JK5tVpDY4 B0J1k1bnqiC4q4nCi70eZWDSyw== X-Google-Smtp-Source: ABdhPJzKl0DSbAlOjgSnu0aJrlMhcaEd95cggkaq2tIJqVT3Q0fAhq9xoe+aztXq8eP2anQ5Tq3eBQ== X-Received: by 2002:a37:a546:: with SMTP id o67mr5135251qke.24.1634223391344; Thu, 14 Oct 2021 07:56:31 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-0d65-5385-0e85-d408.res6.spectrum.com. [2603:6081:7b01:cbda:d65:5385:e85:d408]) by smtp.gmail.com with ESMTPSA id f29sm1470027qtg.42.2021.10.14.07.56.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Oct 2021 07:56:30 -0700 (PDT) Date: Thu, 14 Oct 2021 10:56:26 -0400 From: Tom Rini To: Simon Glass Subject: Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option Message-ID: <20211014145626.GC7964@bill-the-cat> References: <20211013010120.96851-1-sjg@chromium.org> <20211013013450.GJ7964@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="JdGOiFbZO3d8tZZp" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Received-SPF: pass client-ip=2607:f8b0:4864:20::72c; envelope-from=trini@konsulko.com; helo=mail-qk1-x72c.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, 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 , =?iso-8859-1?Q?Fran=E7ois?= Ozog , Stephen Warren , Oleksandr Andrushchenko , Heinrich Schuchardt , Niel Fourie , Michal Simek , Marek =?iso-8859-1?Q?Beh=FAn?= , 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 , Pali =?iso-8859-1?Q?Roh=E1r?= , Dimitri John Ledkov , Padmarao Begari Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --JdGOiFbZO3d8tZZp Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > Hi Fran=C3=A7ois, >=20 > On Wed, 13 Oct 2021 at 11:35, Fran=C3=A7ois Ozog 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 wro= te: > >> > > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFI= LE 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 embe= dded 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 board. > >> > > > > >> > > > The problems with this approach are documented at [1]. > >> > > > > >> > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. A= ny board > >> > > > can obtain its devicetree at runtime, even it is has a devicetre= e built > >> > > > in U-Boot. This is because U-Boot may be a second-stage bootload= er and its > >> > > > caller may have a better idea about the hardware available in th= e 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 b= e 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 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 f= or > >> > platforms that are capable of and can / do have a device tree to giv= e 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. > >> 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-B= oot then I agree very much. But I don=E2=80=99t understand how the patch se= t 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 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. >=20 > 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. >=20 > 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 agree that U-Boot needs to support being passed a device tree to use, at run time, yes? And in that case, would not be using the "fake" tree we built in? 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) ? --=20 Tom --JdGOiFbZO3d8tZZp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmFoRRcACgkQFHw5/5Y0 tyzyyAv+INQAZi12/ac0LgpOevOWMVAmr3LSuI1B2Jaf1WPkMx9r4JwghNykRrug 4FuAhp2JzuqlKV77jtnee7DnGeyvTysmyK9FdYmBtPuWhGGI2EH3LL8zK5mtXQEf p71vsvsMI93oPRwXGztEZvpdDqFVvVmoaEdbeq3ngg4B1g6pL100dCsjunkuFFU0 cfJhoeJwczceujgkCl64yMyeYswybIeSpEiKGdvZyMIi0c1iXTpt6hqChw13VV7d yzxTflhQg3iLzuxaHSyWHVTAD8NAfePbOZLWkA6eibcRpFtAq0SUlLB9FlB5Fd1k y4ubPVG7rTxxD9rf/napygxLTBq2PVnQOx9wPqTFA5lpeE3EP2obxxN1tqTjQE5N n6WdGbZoknH/MszZWXtou7gCi5ia1PvVxW/6sOqclpxgOpxxHV/IXdtos525wKWV fPPCUfSa5JrDAS9PaILh9oXgrjVblFoV09gWsHaTF7TV1p7r0uA/PzVbJUQDrupb RLJx/tik =/IDy -----END PGP SIGNATURE----- --JdGOiFbZO3d8tZZp-- 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 1CAB1C433EF for ; Thu, 14 Oct 2021 14:57:55 +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 6D84160F4A for ; Thu, 14 Oct 2021 14:57:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 6D84160F4A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=konsulko.com 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 0941782FE7; Thu, 14 Oct 2021 16:57:52 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=konsulko.com header.i=@konsulko.com header.b="f2uNOAp0"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 4E24B8377A; Thu, 14 Oct 2021 16:56:44 +0200 (CEST) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 EB8978378E for ; Thu, 14 Oct 2021 16:56:32 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qk1-x734.google.com with SMTP id l7so5730626qkk.0 for ; Thu, 14 Oct 2021 07:56:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=JJlJlWnWHPEHuZhLZDrvVcK4s/9t1luNJh3IAjIpxm4=; b=f2uNOAp0lDh6xKZx7YL2Qqg0+qTLCPxQLx60V5kLepCStQIYTEUrSUNIY5fdkpKUN3 9HFPFYYRdeg9Q0m3Fin1CBlulszn8hKAAtp2/ZDhHdQajf5agPsRFUt7A2CJ39mVc6Gl OzMP6/xqZP2Gakg5FTJvpiSMK4E6HHhwptVJY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=JJlJlWnWHPEHuZhLZDrvVcK4s/9t1luNJh3IAjIpxm4=; b=zdYkGvGMNMsPc/vAJHX0APc7eKb++Q/s77h2rgKQR5ueV91xcp2rwK5w3jk21Ulc+6 GeRuyhhfT1M7Gj+yrcoCty90HJKS8SFDB9RTHgVlv6egqYLuASn/XxQoxYm1ZgXb4E5v EhBUN6dlUAuC41w+I0IkMvXuVUORvYbA1IEeje9y4FXAHI1lWCsz32mGCYPfU37Wuoyu 5XO11N8NRILQsjotk7nkplRl/EMQgVK1ioxIA9LUtV0Sj7jFkHdxU2zrUwNYJUJBbpkt J8KWKJHeTP7BVv0loBaaUcE5AHUlZEJbxsr+H1YcNTNAjHno5pPWZW9RFcnQ0IZNFBet ad0w== X-Gm-Message-State: AOAM533m5Cz/GbDjNa98x4XevjhopfETAdR0+mWWL1L9LctzG8xi6g67 upCR+VzWWyjiJKRdou0CCVZ0WA== X-Google-Smtp-Source: ABdhPJzKl0DSbAlOjgSnu0aJrlMhcaEd95cggkaq2tIJqVT3Q0fAhq9xoe+aztXq8eP2anQ5Tq3eBQ== X-Received: by 2002:a37:a546:: with SMTP id o67mr5135251qke.24.1634223391344; Thu, 14 Oct 2021 07:56:31 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-0d65-5385-0e85-d408.res6.spectrum.com. [2603:6081:7b01:cbda:d65:5385:e85:d408]) by smtp.gmail.com with ESMTPSA id f29sm1470027qtg.42.2021.10.14.07.56.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Oct 2021 07:56:30 -0700 (PDT) Date: Thu, 14 Oct 2021 10:56:26 -0400 From: Tom Rini To: Simon Glass Cc: =?iso-8859-1?Q?Fran=E7ois?= Ozog , 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 , Marek =?iso-8859-1?Q?Beh=FAn?= , Matthias Brugger , Michal Simek , Michal Simek , Neil Armstrong , Niel Fourie , Oleksandr Andrushchenko , Padmarao Begari , Pali =?iso-8859-1?Q?Roh=E1r?= , 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 , Tuomas Tynkkynen , U-Boot Mailing List , Valentin Longchamp , Vladimir Oltean , Wolfgang Denk , Zong Li , "qemu-devel@nongnu.org Developers" Subject: Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option Message-ID: <20211014145626.GC7964@bill-the-cat> References: <20211013010120.96851-1-sjg@chromium.org> <20211013013450.GJ7964@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="JdGOiFbZO3d8tZZp" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett X-Mailman-Approved-At: Thu, 14 Oct 2021 16:57:49 +0200 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 --JdGOiFbZO3d8tZZp Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > Hi Fran=C3=A7ois, >=20 > On Wed, 13 Oct 2021 at 11:35, Fran=C3=A7ois Ozog 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 wro= te: > >> > > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFI= LE 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 embe= dded 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 board. > >> > > > > >> > > > The problems with this approach are documented at [1]. > >> > > > > >> > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. A= ny board > >> > > > can obtain its devicetree at runtime, even it is has a devicetre= e built > >> > > > in U-Boot. This is because U-Boot may be a second-stage bootload= er and its > >> > > > caller may have a better idea about the hardware available in th= e 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 b= e 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 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 f= or > >> > platforms that are capable of and can / do have a device tree to giv= e 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. > >> 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-B= oot then I agree very much. But I don=E2=80=99t understand how the patch se= t 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 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. >=20 > 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. >=20 > 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 agree that U-Boot needs to support being passed a device tree to use, at run time, yes? And in that case, would not be using the "fake" tree we built in? 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) ? --=20 Tom --JdGOiFbZO3d8tZZp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmFoRRcACgkQFHw5/5Y0 tyzyyAv+INQAZi12/ac0LgpOevOWMVAmr3LSuI1B2Jaf1WPkMx9r4JwghNykRrug 4FuAhp2JzuqlKV77jtnee7DnGeyvTysmyK9FdYmBtPuWhGGI2EH3LL8zK5mtXQEf p71vsvsMI93oPRwXGztEZvpdDqFVvVmoaEdbeq3ngg4B1g6pL100dCsjunkuFFU0 cfJhoeJwczceujgkCl64yMyeYswybIeSpEiKGdvZyMIi0c1iXTpt6hqChw13VV7d yzxTflhQg3iLzuxaHSyWHVTAD8NAfePbOZLWkA6eibcRpFtAq0SUlLB9FlB5Fd1k y4ubPVG7rTxxD9rf/napygxLTBq2PVnQOx9wPqTFA5lpeE3EP2obxxN1tqTjQE5N n6WdGbZoknH/MszZWXtou7gCi5ia1PvVxW/6sOqclpxgOpxxHV/IXdtos525wKWV fPPCUfSa5JrDAS9PaILh9oXgrjVblFoV09gWsHaTF7TV1p7r0uA/PzVbJUQDrupb RLJx/tik =/IDy -----END PGP SIGNATURE----- --JdGOiFbZO3d8tZZp--