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 2CA6CC433F5 for ; Wed, 27 Oct 2021 22:39:12 +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 E8845610CB for ; Wed, 27 Oct 2021 22:39:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org E8845610CB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=xs4all.nl Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=nongnu.org Received: from localhost ([::1]:51872 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mfrZf-0006MC-02 for qemu-devel@archiver.kernel.org; Wed, 27 Oct 2021 18:39:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46156) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mfrRF-0004ze-UO for qemu-devel@nongnu.org; Wed, 27 Oct 2021 18:30:36 -0400 Received: from sibelius.xs4all.nl ([83.163.83.176]:54554) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mfrRB-0003HS-IK for qemu-devel@nongnu.org; Wed, 27 Oct 2021 18:30:29 -0400 Received: from localhost (bloch.sibelius.xs4all.nl [local]) by bloch.sibelius.xs4all.nl (OpenSMTPD) with ESMTPA id a1757b28; Thu, 28 Oct 2021 00:30:17 +0200 (CEST) Date: Thu, 28 Oct 2021 00:30:17 +0200 (CEST) From: Mark Kettenis To: Simon Glass In-Reply-To: (message from Simon Glass on Wed, 27 Oct 2021 12:23:21 -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: Received-SPF: softfail client-ip=83.163.83.176; envelope-from=mark.kettenis@xs4all.nl; helo=sibelius.xs4all.nl X-Spam_score_int: -11 X-Spam_score: -1.2 X-Spam_bar: - X-Spam_report: (-1.2 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, UNPARSEABLE_RELAY=0.001 autolearn=no 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@linaro.org, fitzsim@fitzsim.org, qemu-devel@nongnu.org, seanga2@gmail.com, u-boot@lists.denx.de, francois.ozog@linaro.org, swarren@nvidia.com, oleksandr_andrushchenko@epam.com, xypron.glpk@gmx.de, michal.simek@xilinx.com, vanbaren@cideas.com, swarren@wwwdotorg.org, andre.przywara@arm.com, agraf@csgraf.de, anastasiia_lukianenko@epam.com, albert.u.boot@aribaud.net, mbrugger@suse.com, ilias.apalodimas@linaro.org, awilliams@marvell.com, tuomas.tynkkynen@iki.fi, bmeng.cn@gmail.com, trini@konsulko.com Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" > 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. > 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 ;).