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 A34C4C433F5 for ; Wed, 3 Nov 2021 08:23:10 +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 77D9B61051 for ; Wed, 3 Nov 2021 08:23:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 77D9B61051 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=xs4all.nl 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 40B588314A; Wed, 3 Nov 2021 09:23:07 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=xs4all.nl Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id 10BEC83224; Wed, 3 Nov 2021 09:23:05 +0100 (CET) Received: from sibelius.xs4all.nl (sibelius.xs4all.nl [83.163.83.176]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id D3DD683121 for ; Wed, 3 Nov 2021 09:23:00 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=xs4all.nl Authentication-Results: phobos.denx.de; spf=fail smtp.mailfrom=mark.kettenis@xs4all.nl Received: from localhost (bloch.sibelius.xs4all.nl [local]) by bloch.sibelius.xs4all.nl (OpenSMTPD) with ESMTPA id a18b78b6; Wed, 3 Nov 2021 09:22:58 +0100 (CET) Date: Wed, 3 Nov 2021 09:22:58 +0100 (CET) From: Mark Kettenis To: Simon Glass Cc: francois.ozog@linaro.org, awilliams@marvell.com, albert.u.boot@aribaud.net, agraf@csgraf.de, Anastasiia_Lukianenko@epam.com, andre.przywara@arm.com, bmeng.cn@gmail.com, xypron.glpk@gmx.de, ilias.apalodimas@linaro.org, vanbaren@cideas.com, linus.walleij@linaro.org, mbrugger@suse.com, michal.simek@xilinx.com, Oleksandr_Andrushchenko@epam.com, seanga2@gmail.com, swarren@wwwdotorg.org, swarren@nvidia.com, fitzsim@fitzsim.org, trini@konsulko.com, tuomas.tynkkynen@iki.fi, u-boot@lists.denx.de, qemu-devel@nongnu.org In-Reply-To: (message from Simon Glass on Tue, 2 Nov 2021 19:20:51 -0600) Subject: Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option References: <20211026002344.405160-1-sjg@chromium.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Message-ID: 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 > From: Simon Glass > Date: Tue, 2 Nov 2021 19:20:51 -0600 > > Hi Mark, > > On Wed, 27 Oct 2021 at 16:30, Mark Kettenis wrote: > > > > > From: Simon Glass > > > Date: Wed, 27 Oct 2021 12:23:21 -0600 > > > > > > Hi François, > > > > > > On Wed, 27 Oct 2021 at 09:14, François Ozog wrote: > > > > > > > > > > > > > > > > On Wed, 27 Oct 2021 at 16:08, Simon Glass wrote: > > > >> > > > >> Hi François, > > > >> > > > >> On Tue, 26 Oct 2021 at 00:07, François Ozog wrote: > > > >> > > > > >> > Hi Simon > > > >> > > > > >> > Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them 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énée from 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 contributors to think that they need to compile the DT for the targeted platforms. > > > > For your advanced scenario, you can still have the dts in the documentation area, or whatever directory (except dts). compile it and supply to U-Boot. > > > > > > 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. > > > > Until. The Raspberry Pi foundation releases a new firmware that > > configures the hardware differently such that the addresses in the > > U-Boot devicetree are wrong and nothing works anymore. Can't speak > > for the rpi 1, but this has happened in the past for the rpi 2 and 3 > > as well as more recently on the rpi 4. > > So I update my SD card with a new private-binary bootloader and things > stop working? I think I can narrow that one down :-) > > > > 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. > > > > > > 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. > > > > How many people are there out there that work on U-Boot that don't > > have a Linux source tree checked out? Even I have several of those > > lying around on my development systems and I am an OpenBSD developer ;). > > So it is OK to have the DT in Linux but not in U-Boot? I don't even > know what to say that. How does that square with your point above? Ideally the DT's and DT binding would move out of the Linux tree and into a repository of their own. But until that is the case, the Linux tree is the source of truth. > I am not talking about disabling OF_BOARD, just making it *possible* > to do so. And I don't think it makes sense to do so on most boards that have OF_BOARD in their config.