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 ADF34C433EF for ; Wed, 27 Oct 2021 19:25:26 +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 A33FD601FC for ; Wed, 27 Oct 2021 19:25:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org A33FD601FC 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 8BC4282F03; Wed, 27 Oct 2021 21:25:23 +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="q5Xz+3EA"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 4CB8D80516; Wed, 27 Oct 2021 21:25:22 +0200 (CEST) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (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 7E3AA82D6F for ; Wed, 27 Oct 2021 21:25:18 +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-qv1-xf2c.google.com with SMTP id t1so2534160qvb.1 for ; Wed, 27 Oct 2021 12:25:18 -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=aCyvoubtqD+aHaW0M4YRN/03kjasobCP35HJ4qiFEv4=; b=q5Xz+3EAwH9YGAIvjoLyiVAg4Om2RiShMyma61nDWJVyshZBf7n7HLQEzLzfn91yhO 8LiF5mgQLCmNjdc/eICZiJ3Ko1t2pr5slak2gvDKGSn/jvCfV2UtXMjaOrD0aMz+Vykc pTI4tj8kyQBxJcg/4E+mZO4qGrcnP+lASG1as= 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=aCyvoubtqD+aHaW0M4YRN/03kjasobCP35HJ4qiFEv4=; b=vWjVZ3blrNldSGyFUcvXC7SJZYOKuWQ+V8u6BzqwBwMOB7ekIJtavJZzxPIbBKf/kW 7SiRSE0dDo0QGHseZsRcjaudQ75wy5lZ9tEoO8qjb5yzqjjya1U9oIXjL9hGKZa2jo0G xL7S8ozUJr5o7RuU79JMZ41w7sUSNPGpXJc4EdgoaGQPsJ+rw5QSxrzdSUdLTtGxMLy0 E37CXSG5KgiJCmqcIM8/lNBTuv/Ue3h34nQbivuPrl5lmsAV6QzSGLEQEYOdilQdIz8j QKayfLJoemJ51d87m+WTXMMSXqA7J83Wcop56eL3G98ROM8eb3ZkzLUHpas198b2mGTW lmOQ== X-Gm-Message-State: AOAM530mSiwZtuO38GQbBIQFXyyoJSrNnpPK1P3KB5q7MJWq3BeCiaIs 1/ihCV557VoiRdF/Foj2FaKdsQ== X-Google-Smtp-Source: ABdhPJyMW+74IsNuc1Cy0/np7IpU0tWEWcLGyunYMJlhA+kNPrzBlJ0C494oDBkVvjaiGmxqjBQ1Xg== X-Received: by 2002:ad4:5b81:: with SMTP id 1mr23363884qvp.52.1635362717290; Wed, 27 Oct 2021 12:25:17 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-0044-6cb5-81ac-bb0c.res6.spectrum.com. [2603:6081:7b01:cbda:44:6cb5:81ac:bb0c]) by smtp.gmail.com with ESMTPSA id z15sm524673qtw.85.2021.10.27.12.25.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Oct 2021 12:25:16 -0700 (PDT) Date: Wed, 27 Oct 2021 15:25:14 -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 , Bin Meng , Heinrich Schuchardt , Ilias Apalodimas , Jerry Van Baren , Linus Walleij , Mark Kettenis , Matthias Brugger , Michal Simek , Oleksandr Andrushchenko , Sean Anderson , Stephen Warren , Stephen Warren , Thomas Fitzsimmons , Tuomas Tynkkynen , U-Boot Mailing List , QEMU Developers Subject: Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option Message-ID: <20211027192514.GL8284@bill-the-cat> References: <20211026002344.405160-1-sjg@chromium.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qE0/TkNoJLLGUzs4" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett 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 --qE0/TkNoJLLGUzs4 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 27, 2021 at 12:23:21PM -0600, Simon Glass wrote: > Hi Fran=E7ois, >=20 > On Wed, 27 Oct 2021 at 09:14, Fran=E7ois Ozog = wrote: > > > > > > > > On Wed, 27 Oct 2021 at 16:08, Simon Glass wrote: > >> > >> Hi Fran=E7ois, > >> > >> On Tue, 26 Oct 2021 at 00:07, Fran=E7ois Ozog wrote: > >> > > >> > Hi Simon > >> > > >> > Position unchanged on this series: adding fake dts for boards that g= enerate their device tree in the dts directory is not good. If you have the= m in documentation the it is acceptable. > >> > >> I think we are going to have to disagree on this one. I actually used > >> the qemu one in testing/development recently. We have to have a way to > >> develop in-tree with U-Boot. It does not impinge on any of your use > >> cases, so far as I know. > > > > I am not the only one in disagreement... You just saw Alex B=E9n=E9e fr= om Qemu saying the same thing. > > I understand the advanced debug/development scenario you mention. > > But locating the DT files in the dts directory is mis-leading the contr= ibutors to think that they need to compile the DT for the targeted platform= s. > > For your advanced scenario, you can still have the dts in the documenta= tion area, or whatever directory (except dts). compile it and supply to U-B= oot. >=20 > We have this situation with rpi 1, 2 and 3 and I don't believe anyone > has noticed. U-Boot handles the build automatically. If you turn off > OF_BOARD, it will use the U-Boot devicetree always so you know what is > going on. That we have to have so many separate rpi build targets, and can't just use rpm_arm64 and add rpi_arm32 is not a good feature. The various rpi configs that use CONFIG_OF_EMBED are on your list of things that need to be cleaned up, yes? > We can add a message to U-Boot indicating where the devicetree came > from, perhaps? That might be useful given everything that is going on. >=20 > As in this case, quite often in these discussions I struggle to > understand what is behind the objection. Is it that your customers are > demanding that devicetrees become private, secret data, not included > in open-source projects? Or is it just the strange case of QEMU that > is informing your thinking? I know of at least one project where the > first-stage bootloader produces a devicetree and no one has the source > for it. I believe TF-A was created for licensing reasons...so can you > be a bit clearer about what the problem actually is? If a board is > in-tree in U-Boot I would like it to have a devicetree there, at least > until we have a better option. At the very least, it MUST be > discoverable and it must be possible to undertake U-Boot development > easily without a lot of messing around. What I don't understand here is why or how U-Boot is supposed to become the source of truth for device trees. The general goal is that the device tree be something that actually comes along on the hardware, because it's stable enough and correct enough that it's not going to be changed from one OS kernel release to the next. That should be where the correct and true tree comes from, the device itself. --=20 Tom --qE0/TkNoJLLGUzs4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmF5p5cACgkQFHw5/5Y0 tywFgQv+MRkY8zca+DzN/PrzoW3Ca5dCrZQYWBbmT6iful/aP+t4HAyvpAIvSxe+ be/F/CP77Jj+mBsj3wFFVyy6OCwI1qPJain3IYzdINVXi/DYeMG9qxWm569t3hJ7 6nLg6sYSdybI+eXxHjOhLhQQypgNLd8BdSCucW8SPO1zu3NROuTnDlOXEp26Mead c7JzgeUIh5kBloFXkKDINSQT6jPxVvQmTC0n0cF6Ky1EVb3kaj3wGtV61ldSUGWA vfnnXNcqPSICW8nhHrx+VwdT58dKCS2s6X+uHhoACaUEENAD94kcQGxY1LFFmw0s 44UspgZyyjnHZR95J3++8vlMBTnYuCkJzJFPMDmSiYvOOR3lftFhosCpL0Z0Hg5T OK9zy7liDbDo0uQ9dOzae8ZUIi6j+fSXtEPpiXIHcu0nDb+f7k8W3abSEoZqlLxW PtgyvWdYATJa6g40ZGyFOY3P/VdxcAE3m1YkXvxoXvJ5TDBkSxMJDCQz2uaPGLze fjDTH+O+ =lRX1 -----END PGP SIGNATURE----- --qE0/TkNoJLLGUzs4-- 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 23D72C433F5 for ; Wed, 27 Oct 2021 19:57:25 +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 B241F60EBD for ; Wed, 27 Oct 2021 19:57:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org B241F60EBD 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]:59734 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mfp35-000276-C2 for qemu-devel@archiver.kernel.org; Wed, 27 Oct 2021 15:57:23 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39450) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mfoYF-0001KT-9T for qemu-devel@nongnu.org; Wed, 27 Oct 2021 15:25:32 -0400 Received: from mail-qv1-xf33.google.com ([2607:f8b0:4864:20::f33]:46609) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mfoY3-0005Zv-FY for qemu-devel@nongnu.org; Wed, 27 Oct 2021 15:25:30 -0400 Received: by mail-qv1-xf33.google.com with SMTP id g25so1508965qvf.13 for ; Wed, 27 Oct 2021 12:25:18 -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=aCyvoubtqD+aHaW0M4YRN/03kjasobCP35HJ4qiFEv4=; b=q5Xz+3EAwH9YGAIvjoLyiVAg4Om2RiShMyma61nDWJVyshZBf7n7HLQEzLzfn91yhO 8LiF5mgQLCmNjdc/eICZiJ3Ko1t2pr5slak2gvDKGSn/jvCfV2UtXMjaOrD0aMz+Vykc pTI4tj8kyQBxJcg/4E+mZO4qGrcnP+lASG1as= 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=aCyvoubtqD+aHaW0M4YRN/03kjasobCP35HJ4qiFEv4=; b=kl8Qcizy3Aa8G9/eVCJIoqip7cPsqeoM0yaD7aR+rI38/7PhXthj3tT4nHnDwSU4K2 zCnFUEdq5VNrejTcbj2WgfNefZxVpRw6vrhSqpB3Aexd8KbOa/SNCDXdUBw0vnEHq142 dJmfuQ5ql7wTkQeZpTTLSIpnpnB9vQs96Gs39wSh7hl17y7Yug2SGx/WZky/2sx/Uvqd JF2NyPU+amR/VB3jZ9PdfpGd//h4lkd7pie7Md8HT/5OuvQZwKTXw6PhCa8oZqt7pLI8 +Ur/BpXltWI4JrUI0rFx+7Sw+9mnf9E3akHA2hP2wJXJTxw/KJUUjvh0yuZdKBHs2j1A cp8A== X-Gm-Message-State: AOAM531P32QKJIoWX9QE95QFIsrzNLu4RsERxdL18FnIL/QIZR45G5DK UoByeYvNJqUsVn15FzP79+nnMg== X-Google-Smtp-Source: ABdhPJyMW+74IsNuc1Cy0/np7IpU0tWEWcLGyunYMJlhA+kNPrzBlJ0C494oDBkVvjaiGmxqjBQ1Xg== X-Received: by 2002:ad4:5b81:: with SMTP id 1mr23363884qvp.52.1635362717290; Wed, 27 Oct 2021 12:25:17 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-0044-6cb5-81ac-bb0c.res6.spectrum.com. [2603:6081:7b01:cbda:44:6cb5:81ac:bb0c]) by smtp.gmail.com with ESMTPSA id z15sm524673qtw.85.2021.10.27.12.25.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Oct 2021 12:25:16 -0700 (PDT) Date: Wed, 27 Oct 2021 15:25:14 -0400 From: Tom Rini To: Simon Glass Subject: Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option Message-ID: <20211027192514.GL8284@bill-the-cat> References: <20211026002344.405160-1-sjg@chromium.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qE0/TkNoJLLGUzs4" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett Received-SPF: pass client-ip=2607:f8b0:4864:20::f33; envelope-from=trini@konsulko.com; helo=mail-qv1-xf33.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: Linus Walleij , Thomas Fitzsimmons , QEMU Developers , Sean Anderson , U-Boot Mailing List , Mark Kettenis , =?iso-8859-1?Q?Fran=E7ois?= Ozog , Stephen Warren , Oleksandr Andrushchenko , Heinrich Schuchardt , Michal Simek , Jerry Van Baren , Stephen Warren , Andre Przywara , Alexander Graf , Anastasiia Lukianenko , Albert Aribaud , Matthias Brugger , Ilias Apalodimas , Aaron Williams , Tuomas Tynkkynen , Bin Meng Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --qE0/TkNoJLLGUzs4 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 27, 2021 at 12:23:21PM -0600, Simon Glass wrote: > Hi Fran=E7ois, >=20 > On Wed, 27 Oct 2021 at 09:14, Fran=E7ois Ozog = wrote: > > > > > > > > On Wed, 27 Oct 2021 at 16:08, Simon Glass wrote: > >> > >> Hi Fran=E7ois, > >> > >> On Tue, 26 Oct 2021 at 00:07, Fran=E7ois Ozog wrote: > >> > > >> > Hi Simon > >> > > >> > Position unchanged on this series: adding fake dts for boards that g= enerate their device tree in the dts directory is not good. If you have the= m in documentation the it is acceptable. > >> > >> I think we are going to have to disagree on this one. I actually used > >> the qemu one in testing/development recently. We have to have a way to > >> develop in-tree with U-Boot. It does not impinge on any of your use > >> cases, so far as I know. > > > > I am not the only one in disagreement... You just saw Alex B=E9n=E9e fr= om Qemu saying the same thing. > > I understand the advanced debug/development scenario you mention. > > But locating the DT files in the dts directory is mis-leading the contr= ibutors to think that they need to compile the DT for the targeted platform= s. > > For your advanced scenario, you can still have the dts in the documenta= tion area, or whatever directory (except dts). compile it and supply to U-B= oot. >=20 > We have this situation with rpi 1, 2 and 3 and I don't believe anyone > has noticed. U-Boot handles the build automatically. If you turn off > OF_BOARD, it will use the U-Boot devicetree always so you know what is > going on. That we have to have so many separate rpi build targets, and can't just use rpm_arm64 and add rpi_arm32 is not a good feature. The various rpi configs that use CONFIG_OF_EMBED are on your list of things that need to be cleaned up, yes? > We can add a message to U-Boot indicating where the devicetree came > from, perhaps? That might be useful given everything that is going on. >=20 > As in this case, quite often in these discussions I struggle to > understand what is behind the objection. Is it that your customers are > demanding that devicetrees become private, secret data, not included > in open-source projects? Or is it just the strange case of QEMU that > is informing your thinking? I know of at least one project where the > first-stage bootloader produces a devicetree and no one has the source > for it. I believe TF-A was created for licensing reasons...so can you > be a bit clearer about what the problem actually is? If a board is > in-tree in U-Boot I would like it to have a devicetree there, at least > until we have a better option. At the very least, it MUST be > discoverable and it must be possible to undertake U-Boot development > easily without a lot of messing around. What I don't understand here is why or how U-Boot is supposed to become the source of truth for device trees. The general goal is that the device tree be something that actually comes along on the hardware, because it's stable enough and correct enough that it's not going to be changed from one OS kernel release to the next. That should be where the correct and true tree comes from, the device itself. --=20 Tom --qE0/TkNoJLLGUzs4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmF5p5cACgkQFHw5/5Y0 tywFgQv+MRkY8zca+DzN/PrzoW3Ca5dCrZQYWBbmT6iful/aP+t4HAyvpAIvSxe+ be/F/CP77Jj+mBsj3wFFVyy6OCwI1qPJain3IYzdINVXi/DYeMG9qxWm569t3hJ7 6nLg6sYSdybI+eXxHjOhLhQQypgNLd8BdSCucW8SPO1zu3NROuTnDlOXEp26Mead c7JzgeUIh5kBloFXkKDINSQT6jPxVvQmTC0n0cF6Ky1EVb3kaj3wGtV61ldSUGWA vfnnXNcqPSICW8nhHrx+VwdT58dKCS2s6X+uHhoACaUEENAD94kcQGxY1LFFmw0s 44UspgZyyjnHZR95J3++8vlMBTnYuCkJzJFPMDmSiYvOOR3lftFhosCpL0Z0Hg5T OK9zy7liDbDo0uQ9dOzae8ZUIi6j+fSXtEPpiXIHcu0nDb+f7k8W3abSEoZqlLxW PtgyvWdYATJa6g40ZGyFOY3P/VdxcAE3m1YkXvxoXvJ5TDBkSxMJDCQz2uaPGLze fjDTH+O+ =lRX1 -----END PGP SIGNATURE----- --qE0/TkNoJLLGUzs4--