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 8FE90C433F5 for ; Wed, 27 Oct 2021 13:39:56 +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 C860C60C51 for ; Wed, 27 Oct 2021 13:39:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org C860C60C51 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org 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 B2F3283230; Wed, 27 Oct 2021 15:39:53 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="fy7IYg1j"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 934E8835A3; Wed, 27 Oct 2021 15:30:45 +0200 (CEST) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 AA571835AD for ; Wed, 27 Oct 2021 15:30:32 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=francois.ozog@linaro.org Received: by mail-ed1-x534.google.com with SMTP id w12so10503828edd.11 for ; Wed, 27 Oct 2021 06:30:32 -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=ivv5e8Ct9EGy+47yL5EN3IlgvgOILbFfdQf07TRahE8=; b=fy7IYg1j81PymoVT9hiTJVFsu7ET+OP6OhKILcaT+NGiWNc4vgbI6H3ajgX/NCQSDj j0cLrtdR1L0kwkrMSbmEoQ71riJyKcGqFmA0v9Rvj9T/Xfcp8AQappktK3QJYp86tYe4 foRIvahbrTpW1zu9syHZvIPmw0UYnT5Muu6q1W4+BvE9mTDCJJ6fXWUUVHEbRGYAjAnH T+WyRXvO+2++YWA1Z+nsPnNCXMW1lt+WHEQNOwc0DBeeumzHP3sfevSwvM2Kkinky4S3 5Leo4zydDS+kRywaM5dKbwHMAB6L/Muv1uJ/K9dVD2ZKb7FSYhzVRYeIQDBzvn6t3bOl wHgg== 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=ivv5e8Ct9EGy+47yL5EN3IlgvgOILbFfdQf07TRahE8=; b=hCKQOQ0rjhhda3fUc8wXwpKNFQqdxGrxdS6LCjSBMJtlLiNIfWAGQ2pJnnIgn1Moc0 OW8XTP5dAnSyBx97VasPNl9gB4wkqQw5RO8b1CZNRtSR8orVtj7C3M/lOmIx2aQdl653 xtuEhlA5w+4qmclAacDQZmOmkQOS/NYx3q34q/S6xPGETYg+sKA91mOFBarWR3O3iAJT 12Ly2OGI8UFAMMYin9BceC709Y2fxXTE5GzkIe5WqXDNlV+X21qu2yPh+BxPQpmXuohu tS5o5ZNK4AN1gX8uxo8z5/Ugx3dZtKZjHOPrJAACnu3eailRpyeRnqnglP7eDKIKlUVU 7s3Q== X-Gm-Message-State: AOAM533DaHzuN2JcAon67Ycm0LrjCwkPCBTQ9FektqocRG3jK25uiS9h kWBPlbB/RU16YBP19yZagE9HLeTkg40rXQU1KK6MZQ== X-Google-Smtp-Source: ABdhPJwHaCtHkstiYOgASWlrjAJPd+XhBqDgF9KhYuSNuYcLpBlMMmhlNg2mumbB08mt7EUKriDwNjs+LoNOWii/GLc= X-Received: by 2002:aa7:dac9:: with SMTP id x9mr41173227eds.180.1635341429806; Wed, 27 Oct 2021 06:30:29 -0700 (PDT) MIME-Version: 1.0 References: <20211013013450.GJ7964@bill-the-cat> <20211014145626.GC7964@bill-the-cat> <20211014152801.GF7964@bill-the-cat> <20211027125916.GS8284@bill-the-cat> In-Reply-To: <20211027125916.GS8284@bill-the-cat> From: =?UTF-8?Q?Fran=C3=A7ois_Ozog?= Date: Wed, 27 Oct 2021 15:30:18 +0200 Message-ID: Subject: Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option To: Tom Rini Cc: Ilias Apalodimas , Simon Glass , 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 , Jagan Teki , Jerry Van Baren , Kever Yang , Leo , Linus Walleij , Liviu Dudau , =?UTF-8?B?TWFyZWsgQmVow7pu?= , Matthias Brugger , Michal Simek , Michal Simek , Neil Armstrong , Niel Fourie , Oleksandr Andrushchenko , Padmarao Begari , =?UTF-8?Q?Pali_Roh=C3=A1r?= , 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" X-Mailman-Approved-At: Wed, 27 Oct 2021 15:39:52 +0200 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 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 Hi Tom, On Wed, 27 Oct 2021 at 14:59, Tom Rini wrote: > On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote: > > Hi Simon, > > > > A bit late to the party, sorry! > > > > [...] > > > > > > > > > > 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 we coul= d > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > I want to see less device trees in U-Boot sources, if they can 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 devic= e > > > > 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 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 th= e > > > different components. Binman was one effort there. I feel that puttin= g > > > 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. > > > > > > If we set things up correctly and agree on the bindings, devicetree > > > can be the unifying configuration mechanism through 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 is coming. > > > > > > Anyway, here are the mental steps that I've gone through over the pas= t > > > two months: > > > > > > Step 1: At present, some people think U-Boot is not even allowed to > > > have its own nodes/properties in the DT. It is an abuse of the > > > devicetree standard, like the /chosen node but with less history. We > > > should sacrifice efficiency, expedience and expandability on the alta= r > > > of 'devicetree is a hardware description'. How do we get over that > > > one? Wel, I just think we need to accept that U-Boot uses devicetree > > > for its own purposes, as well as for booting the OS. I am not saying > > > it always has to have those properties, but with existing features > > > like verified boot, SPL as well as complex firmware images where > > > U-Boot needs to be able to find things in the image, it is essential. > > > So let's just assume that we need this everywhere, since we certainly > > > need it in at least some places. > > > > > > (stop reading here if you disagree, because nothing below will make > > > any sense...you can still use U-Boot v2011.06 which doesn't have > > > OF_CONTROL :-) > > > > Having U-Boot keep it's *internal* config state in DTs is fine. Adding > > that to the DTs that are copied over from linux isn't imho. There are > > various reasons for that. First of all syncing device trees is a huge > pain > > and that's probably one of the main reasons our DTs are out of sync for= a > > large number of boards. > > This re-sync is only a pain because: > 1. Some platforms have been modifying the core dts files LIKE THEY ARE > NOT SUPPOSED TO. > 2. DTS files are getting closer to being the super stable API that has > been promised now that there's validation tools. > > Some SoCs, like stm32 are doing an amazing job and keeping things in > sync, every release. Others like NXP are violating rule #1. With NXP commitment to SystemReady on some IMX8 boards, I think this is changing, at least for the SystemReady boards. > Still > others like some TI platforms get bit by #2 (I solved one of these, and > need to cycle back to the one you and I talked about on IRC a while > back, I bet it's another node name dash changed to underbar). > > > The point is this was fine in 2011 were we had SPL only, but the reali= ty > > today is completely different. There's previous stage boot loaders (an= d > > enough cases were vendors prefer those over SPL). If that bootloader > needs > > to use it's own device tree for whatever reason, imposing restrictions > on > > it wrt to the device tree it has to include, and require them to have > > knowledge of U-Boot and it's internal config mechanism makes no sense n= ot > > to mention it doesn't scale at all. > > If you are passing the full device tree around, a few more > nodes/properties aren't going to make the situation worse. If we're > talking about a 60 kilobyte blob one more kilobyte isn't where we call > the line, especially since if we wait another 6 months it'll be a 62 > kilobyte file coming in from Linux instead. > This is not about size but about firmware supply chain organization. > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > > > there? Well, we have u-boot.dtsi files for that (the 2016 patch > > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we > > > have binman definitions, etc. So we need a way to overlay those thing= s > > > into the DT. We already support this for in-tree DTs, so IMO this is > > > easy. Just require every board to have an in-tree DT. It helps with > > > discoverability and documentation, anyway. That is this series. > > > > Again, the board might decide for it's own reason to provide it's own > DT. > > IMHO U-Boot must be able to cope with that and asking DTs to be include= d > in > > U-Boot source is not the right way to do that, not to mention cases we= re > > that's completely unrealistic (e.g QEMU or a board that reads the DTB > from > > it's flash). > > > > > (I think most of us are at the beginning of step 2, unsure about it > > > and worried about step 3) > > > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular > > > flow only, or boards that sometimes use a flow) which need the DT to > > > come from a prior stage. How to handle that? IMO that is only going t= o > > > grow as every man and his dog get into the write-a-bootloader > > > business. > > > > And that's exactly why we have to come up with something that scales, > without > > having to add a bunch of unusable DTs in U-Boot. > > Both of these are solved by having our bindings reviewed and upstreamed > and then what we need included in the authoritative dts files. > There shall be authoritative System Device Trees as vendors are working on. Those System Device Trees cover all aspects of a board, not just the Cortex-A part that U-Boot cares about. Out of those system device trees, a tool (lopper) is going to carve out the "authoritative dts for the cortex-A". Essentially, that carve out will correspond to what would come out of Linux= . This scheme will not be generalized, just adopted by vendors on some boards. DT for those board become part of the OS ABI (meaning, the driver developper is constrained). > > > > We need a way to provide the U-Boot nodes/properties in a > > > form that the prior stage can consume and integrate with its build > > > system. Is TF-A the only thing being discussed here? If so, let's jus= t > > > do it. We have the u-boot.dtsi and we can use binman to put the image > > > together, for example. Or we can get clever and create some sort of > > > overlay dtb. > > > > > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff > > > then it will need to build it in and use two devicetrees, one interna= l > > > and one from the prior stage....well that is not very efficient and i= t > > > is going to be confusing for people to figure out what U-Boot is > > > actually doing. But we actually already do that in a lot of cases > > > where U-Boot passes a DT to the kernel which is different to the one > > > it uses. So perhaps we have three devicetrees? OMG. > > > > No we don't. That's a moot point. If you separate the DTs U-Boot > > provides the internal one and inherits one 'generic'. Linux will be > able to use > > that. So the only case were you'll need 3 DTs is if the *vendor* break= s > the > > DT across kernel versions, In which case there's not much you can do t= o > > begin with and that's already a case we have to deal with. > > > > > b) Well then > > > U-Boot can have its own small devicetree with its bits and then U-Boo= t > > > can merge the two when it starts. Again that is not very efficient. I= t > > > means that U-Boot cannot be controlled by the prior stage (e.g. to ge= t > > > its public key from there or to enable/disable the console), so > > > unified firmware config is not possible. It will get very confusing, > > > particularly for debugging U-Boot. c) Some other scheme to avoid > > > accepting step 3...please stop! > > > > > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of > > > whole cloth. What about that? Well, we are just going to have to deal > > > with that. We can easily merge in the U-Boot nodes/properties and > > > update the U-Boot CI scripts to do this, as needed, e.g. with > > > qemu-riscv64_spl. It's only one use case, although Xen might do > > > something similar. > > > > > > To my mind, that deals with both the build-time and run-time issues. > > > We have a discoverable DT in U-Boot, which should be considered the > > > source of truth for most boards. We can sync it with Linux > > > automatically with the tooling that I hope Rob Herring will come up > > > with. We can use an empty one where there really is no default, > > > although I'd argue that is making perfect an enemy of the good. > > > > > > Step 5: If we get clever and want to remove them from the U-Boot tree > > > and pick them up from somewhere else, we can do that with sufficient > > > tooling. Perhaps we should set a timeline for that? A year? Two? Six? > > > > We can start slowly migrating boards and see how that works out. > > We could either use 2 device trees as you proposed, or have u-boot merg= e > > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd > prefer > > if linux gets handed a clean device tree without the u-boot internals i= n > > it, so I think 2 discrete DTs is cleaner overall. > > Why does it matter if Linux sees some u-boot, properties? If some huge > stink is going to be thrown, we could probably prune them out at run > time but it's already being passed N disabled nodes, yes? > > -- > Tom > --=20 Fran=C3=A7ois-Fr=C3=A9d=C3=A9ric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog 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 184D3C433EF for ; Wed, 27 Oct 2021 14:19:10 +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 8358A60D42 for ; Wed, 27 Oct 2021 14:19:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8358A60D42 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]:58082 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mfjlk-0006RC-GW for qemu-devel@archiver.kernel.org; Wed, 27 Oct 2021 10:19:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35388) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mfj0u-000785-0t for qemu-devel@nongnu.org; Wed, 27 Oct 2021 09:30:44 -0400 Received: from mail-ed1-x52e.google.com ([2a00:1450:4864:20::52e]:39442) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mfj0n-0008V7-0w for qemu-devel@nongnu.org; Wed, 27 Oct 2021 09:30:40 -0400 Received: by mail-ed1-x52e.google.com with SMTP id r12so10558535edt.6 for ; Wed, 27 Oct 2021 06:30:35 -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=ivv5e8Ct9EGy+47yL5EN3IlgvgOILbFfdQf07TRahE8=; b=fy7IYg1j81PymoVT9hiTJVFsu7ET+OP6OhKILcaT+NGiWNc4vgbI6H3ajgX/NCQSDj j0cLrtdR1L0kwkrMSbmEoQ71riJyKcGqFmA0v9Rvj9T/Xfcp8AQappktK3QJYp86tYe4 foRIvahbrTpW1zu9syHZvIPmw0UYnT5Muu6q1W4+BvE9mTDCJJ6fXWUUVHEbRGYAjAnH T+WyRXvO+2++YWA1Z+nsPnNCXMW1lt+WHEQNOwc0DBeeumzHP3sfevSwvM2Kkinky4S3 5Leo4zydDS+kRywaM5dKbwHMAB6L/Muv1uJ/K9dVD2ZKb7FSYhzVRYeIQDBzvn6t3bOl wHgg== 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=ivv5e8Ct9EGy+47yL5EN3IlgvgOILbFfdQf07TRahE8=; b=ifYVnFuX6zpcxLwnjv+uEoCJEsrNA9IMelLwk8+ZRqGR3z/LwWJOk74Qfc+OkzmX64 661yN2jF56GsKx01NyVp/+TFLNLNMm05oyIrh6cj581N7GaUi9Ik8zyVxQmD4I2Gt607 9Y3sMg5U44UFz4zFRX8pYH8hmGvi7tzqOziCE87wll1oJP/gyJqgyK+taKlSIjsR3+E9 I3epWu7KMna7wLBYPwbGA+74lZpoPp1HiQdUgXfTYoPL+5/WNXUoVmwi8pTvgooe5qF+ t8lTlX97Phe0qks2iWcpPd3x91HLWdp00mKhOQlOrTiPa0HrPcVV5CsKRpQQvqQtNZIF /RBg== X-Gm-Message-State: AOAM532LAmggjVJUDIpzNOgd09JAFpaGm/hJKrr4wLr5WfeQ+t/wrcz9 DuhrJ1l8HgusbLnfFBi6HHik8aQPQ9JYG+EdJJDBXA== X-Google-Smtp-Source: ABdhPJwHaCtHkstiYOgASWlrjAJPd+XhBqDgF9KhYuSNuYcLpBlMMmhlNg2mumbB08mt7EUKriDwNjs+LoNOWii/GLc= X-Received: by 2002:aa7:dac9:: with SMTP id x9mr41173227eds.180.1635341429806; Wed, 27 Oct 2021 06:30:29 -0700 (PDT) MIME-Version: 1.0 References: <20211013013450.GJ7964@bill-the-cat> <20211014145626.GC7964@bill-the-cat> <20211014152801.GF7964@bill-the-cat> <20211027125916.GS8284@bill-the-cat> In-Reply-To: <20211027125916.GS8284@bill-the-cat> From: =?UTF-8?Q?Fran=C3=A7ois_Ozog?= Date: Wed, 27 Oct 2021 15:30:18 +0200 Message-ID: Subject: Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option To: Tom Rini Content-Type: multipart/alternative; boundary="00000000000002b16905cf559980" Received-SPF: pass client-ip=2a00:1450:4864:20::52e; envelope-from=francois.ozog@linaro.org; helo=mail-ed1-x52e.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 , Neil Armstrong , Vladimir Oltean , Linus Walleij , Bin Meng , Kever Yang , Sean Anderson , Atish Patra , Zong Li , Stefan Roese , Fabio Estevam , Rainer Boschung , Stephen Warren , Oleksandr Andrushchenko , Heinrich Schuchardt , Niel Fourie , Michal Simek , =?UTF-8?B?TWFyZWsgQmVow7pu?= , 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 , Simon Glass , Ilias Apalodimas , Christian Hewitt , Aaron Williams , Tuomas Tynkkynen , Heinrich Schuchardt , Tianrui Wei , Bin Meng , =?UTF-8?Q?Pali_Roh=C3=A1r?= , Dimitri John Ledkov , Padmarao Begari Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --00000000000002b16905cf559980 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tom, On Wed, 27 Oct 2021 at 14:59, Tom Rini wrote: > On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote: > > Hi Simon, > > > > A bit late to the party, sorry! > > > > [...] > > > > > > > > > > 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 we coul= d > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > I want to see less device trees in U-Boot sources, if they can 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 devic= e > > > > 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 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 th= e > > > different components. Binman was one effort there. I feel that puttin= g > > > 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. > > > > > > If we set things up correctly and agree on the bindings, devicetree > > > can be the unifying configuration mechanism through 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 is coming. > > > > > > Anyway, here are the mental steps that I've gone through over the pas= t > > > two months: > > > > > > Step 1: At present, some people think U-Boot is not even allowed to > > > have its own nodes/properties in the DT. It is an abuse of the > > > devicetree standard, like the /chosen node but with less history. We > > > should sacrifice efficiency, expedience and expandability on the alta= r > > > of 'devicetree is a hardware description'. How do we get over that > > > one? Wel, I just think we need to accept that U-Boot uses devicetree > > > for its own purposes, as well as for booting the OS. I am not saying > > > it always has to have those properties, but with existing features > > > like verified boot, SPL as well as complex firmware images where > > > U-Boot needs to be able to find things in the image, it is essential. > > > So let's just assume that we need this everywhere, since we certainly > > > need it in at least some places. > > > > > > (stop reading here if you disagree, because nothing below will make > > > any sense...you can still use U-Boot v2011.06 which doesn't have > > > OF_CONTROL :-) > > > > Having U-Boot keep it's *internal* config state in DTs is fine. Adding > > that to the DTs that are copied over from linux isn't imho. There are > > various reasons for that. First of all syncing device trees is a huge > pain > > and that's probably one of the main reasons our DTs are out of sync for= a > > large number of boards. > > This re-sync is only a pain because: > 1. Some platforms have been modifying the core dts files LIKE THEY ARE > NOT SUPPOSED TO. > 2. DTS files are getting closer to being the super stable API that has > been promised now that there's validation tools. > > Some SoCs, like stm32 are doing an amazing job and keeping things in > sync, every release. Others like NXP are violating rule #1. With NXP commitment to SystemReady on some IMX8 boards, I think this is changing, at least for the SystemReady boards. > Still > others like some TI platforms get bit by #2 (I solved one of these, and > need to cycle back to the one you and I talked about on IRC a while > back, I bet it's another node name dash changed to underbar). > > > The point is this was fine in 2011 were we had SPL only, but the reali= ty > > today is completely different. There's previous stage boot loaders (an= d > > enough cases were vendors prefer those over SPL). If that bootloader > needs > > to use it's own device tree for whatever reason, imposing restrictions > on > > it wrt to the device tree it has to include, and require them to have > > knowledge of U-Boot and it's internal config mechanism makes no sense n= ot > > to mention it doesn't scale at all. > > If you are passing the full device tree around, a few more > nodes/properties aren't going to make the situation worse. If we're > talking about a 60 kilobyte blob one more kilobyte isn't where we call > the line, especially since if we wait another 6 months it'll be a 62 > kilobyte file coming in from Linux instead. > This is not about size but about firmware supply chain organization. > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > > > there? Well, we have u-boot.dtsi files for that (the 2016 patch > > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we > > > have binman definitions, etc. So we need a way to overlay those thing= s > > > into the DT. We already support this for in-tree DTs, so IMO this is > > > easy. Just require every board to have an in-tree DT. It helps with > > > discoverability and documentation, anyway. That is this series. > > > > Again, the board might decide for it's own reason to provide it's own > DT. > > IMHO U-Boot must be able to cope with that and asking DTs to be include= d > in > > U-Boot source is not the right way to do that, not to mention cases we= re > > that's completely unrealistic (e.g QEMU or a board that reads the DTB > from > > it's flash). > > > > > (I think most of us are at the beginning of step 2, unsure about it > > > and worried about step 3) > > > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular > > > flow only, or boards that sometimes use a flow) which need the DT to > > > come from a prior stage. How to handle that? IMO that is only going t= o > > > grow as every man and his dog get into the write-a-bootloader > > > business. > > > > And that's exactly why we have to come up with something that scales, > without > > having to add a bunch of unusable DTs in U-Boot. > > Both of these are solved by having our bindings reviewed and upstreamed > and then what we need included in the authoritative dts files. > There shall be authoritative System Device Trees as vendors are working on. Those System Device Trees cover all aspects of a board, not just the Cortex-A part that U-Boot cares about. Out of those system device trees, a tool (lopper) is going to carve out the "authoritative dts for the cortex-A". Essentially, that carve out will correspond to what would come out of Linux= . This scheme will not be generalized, just adopted by vendors on some boards. DT for those board become part of the OS ABI (meaning, the driver developper is constrained). > > > > We need a way to provide the U-Boot nodes/properties in a > > > form that the prior stage can consume and integrate with its build > > > system. Is TF-A the only thing being discussed here? If so, let's jus= t > > > do it. We have the u-boot.dtsi and we can use binman to put the image > > > together, for example. Or we can get clever and create some sort of > > > overlay dtb. > > > > > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff > > > then it will need to build it in and use two devicetrees, one interna= l > > > and one from the prior stage....well that is not very efficient and i= t > > > is going to be confusing for people to figure out what U-Boot is > > > actually doing. But we actually already do that in a lot of cases > > > where U-Boot passes a DT to the kernel which is different to the one > > > it uses. So perhaps we have three devicetrees? OMG. > > > > No we don't. That's a moot point. If you separate the DTs U-Boot > > provides the internal one and inherits one 'generic'. Linux will be > able to use > > that. So the only case were you'll need 3 DTs is if the *vendor* break= s > the > > DT across kernel versions, In which case there's not much you can do t= o > > begin with and that's already a case we have to deal with. > > > > > b) Well then > > > U-Boot can have its own small devicetree with its bits and then U-Boo= t > > > can merge the two when it starts. Again that is not very efficient. I= t > > > means that U-Boot cannot be controlled by the prior stage (e.g. to ge= t > > > its public key from there or to enable/disable the console), so > > > unified firmware config is not possible. It will get very confusing, > > > particularly for debugging U-Boot. c) Some other scheme to avoid > > > accepting step 3...please stop! > > > > > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of > > > whole cloth. What about that? Well, we are just going to have to deal > > > with that. We can easily merge in the U-Boot nodes/properties and > > > update the U-Boot CI scripts to do this, as needed, e.g. with > > > qemu-riscv64_spl. It's only one use case, although Xen might do > > > something similar. > > > > > > To my mind, that deals with both the build-time and run-time issues. > > > We have a discoverable DT in U-Boot, which should be considered the > > > source of truth for most boards. We can sync it with Linux > > > automatically with the tooling that I hope Rob Herring will come up > > > with. We can use an empty one where there really is no default, > > > although I'd argue that is making perfect an enemy of the good. > > > > > > Step 5: If we get clever and want to remove them from the U-Boot tree > > > and pick them up from somewhere else, we can do that with sufficient > > > tooling. Perhaps we should set a timeline for that? A year? Two? Six? > > > > We can start slowly migrating boards and see how that works out. > > We could either use 2 device trees as you proposed, or have u-boot merg= e > > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd > prefer > > if linux gets handed a clean device tree without the u-boot internals i= n > > it, so I think 2 discrete DTs is cleaner overall. > > Why does it matter if Linux sees some u-boot, properties? If some huge > stink is going to be thrown, we could probably prune them out at run > time but it's already being passed N disabled nodes, yes? > > -- > Tom > --=20 Fran=C3=A7ois-Fr=C3=A9d=C3=A9ric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog --00000000000002b16905cf559980 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tom,

On Wed, 27 Oct 2021 at 14:59, Tom Rini <trini@konsulko.com> wrote:
On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalod= imas wrote:
> Hi Simon,
>
> A bit late to the party, sorry!
>
> [...]
>
> > >
> > > I really want to see what the binary case looks like since w= e 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 sources, if they c= an come
> > > functionally correct from the hardware/our caller.
> > >
> > > And I'm not seeing how we make use of "U-Boot /conf= ig" if we also don't
> > > use the device tree from build time at run time, ignoring th= e 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 t= o find
> > the instructions. It doesn't have to be that way, but if we c= arry on
> > as we are, it will continue to be messy and in five years you wil= l
> > need a Ph.D and a lucky charm to boot on any modern board. My
> > objective here is to simplify things, bringing some consistency t= o the
> > different components. Binman was one effort there. I feel that pu= tting
> > 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.
> >
> > If we set things up correctly and agree on the bindings, devicetr= ee
> > can be the unifying configuration mechanism through the whole of<= br> > > firmware (except for very early bits) and into the OS, this will = 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= the past
> > two months:
> >
> > Step 1: At present, some people think U-Boot is not even allowed = to
> > have its own nodes/properties in the DT. It is an abuse of the > > devicetree standard, like the /chosen node but with less history.= We
> > should sacrifice efficiency, expedience and expandability on the = altar
> > of 'devicetree is a hardware description'. How do we get = over that
> > one? Wel, I just think we need to accept that U-Boot uses devicet= ree
> > for its own purposes, as well as for booting the OS. I am not say= ing
> > it always has to have those properties, but with existing feature= s
> > like verified boot, SPL as well as complex firmware images where<= br> > > U-Boot needs to be able to find things in the image, it is essent= ial.
> > So let's just assume that we need this everywhere, since we c= ertainly
> > need it in at least some places.
> >
> > (stop reading here if you disagree, because nothing below will ma= ke
> > any sense...you can still use U-Boot v2011.06 which doesn't h= ave
> > OF_CONTROL :-)
>
> Having U-Boot keep it's *internal* config state in DTs is fine.=C2= =A0 Adding
> that to the DTs that are copied over from linux isn't imho.=C2=A0 = There are
> various reasons for that.=C2=A0 First of all syncing device trees is a= huge pain
> and that's probably one of the main reasons our DTs are out of syn= c for a
> large number of boards.

This re-sync is only a pain because:
1. Some platforms have been modifying the core dts files LIKE THEY ARE
=C2=A0 =C2=A0NOT SUPPOSED TO.
2. DTS files are getting closer to being the super stable API that has
=C2=A0 =C2=A0been promised now that there's validation tools.

Some SoCs, like stm32 are doing an amazing job and keeping things in
sync, every release.=C2=A0 Others like NXP are violating rule #1.=C2=A0
With NXP commitment to SystemReady on some IMX8 boards, I thi= nk this is changing,=C2=A0
at least for the SystemReady boards.
Still
others like some TI platforms get bit by #2 (I solved one of these, and
need to cycle back to the one you and I talked about on IRC a while
back, I bet it's another node name dash changed to underbar).

> The point is this was fine in 2011 were we had SPL only,=C2=A0 but the= reality
> today is completely different.=C2=A0 There's previous stage boot l= oaders (and
> enough cases were vendors prefer those over SPL).=C2=A0 If that bootlo= ader needs
> to use it's own device tree for whatever reason,=C2=A0 imposing re= strictions on
> it wrt to the device tree it has to include,=C2=A0 and require them to= have
> knowledge of U-Boot and it's internal config mechanism makes no se= nse not
> to mention it doesn't scale at all.

If you are passing the full device tree around, a few more
nodes/properties aren't going to make the situation worse.=C2=A0 If we&= #39;re
talking about a 60 kilobyte blob one more kilobyte isn't where we call<= br> the line, especially since if we wait another 6 months it'll be a 62 kilobyte file coming in from Linux instead.
This is no= t about size but about firmware supply chain organization.

> > Step 2: Assume U-Boot has its own nodes/properties. How do they g= et
> > there? Well, we have u-boot.dtsi files for that (the 2016 patch > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi fi= le"), we
> > have binman definitions, etc. So we need a way to overlay those t= hings
> > into the DT. We already support this for in-tree DTs, so IMO this= is
> > easy. Just require every board to have an in-tree DT. It helps wi= th
> > discoverability and documentation, anyway. That is this series. >
> Again, the board might decide for it's own reason to provide it= 9;s own DT.
> IMHO U-Boot must be able to cope with that and asking DTs to be includ= ed in
> U-Boot source is not the right way to do that,=C2=A0 not to mention ca= ses were
> that's completely unrealistic (e.g QEMU or a board that reads the = DTB from
> it's flash).
>
> > (I think most of us are at the beginning of step 2, unsure about = it
> > and worried about step 3)
> >
> > Step 3: Ah, but there are flows (i.e. boards that use a particula= r
> > flow only, or boards that sometimes use a flow) which need the DT= to
> > come from a prior stage. How to handle that? IMO that is only goi= ng to
> > grow as every man and his dog get into the write-a-bootloader
> > business.
>
> And that's exactly why we have to come up with something that scal= es,=C2=A0 without
> having to add a bunch of unusable DTs in U-Boot.

Both of these are solved by having our bindings reviewed and upstreamed
and then what we need included in the authoritative dts files.
There shall be authoritative System Device Trees as vendors are wo= rking on.
Those System Device Trees cover all aspects of a board,= not just the Cortex-A part that U-Boot cares about.
Out of those= system device trees, a tool (lopper) is going to carve out the "autho= ritative dts for the cortex-A".
Essentially, that carve out = will correspond to what would come out of Linux.
This scheme will= not be generalized, just adopted by vendors on some boards.=C2=A0
DT for those board become part of the OS ABI (meaning, the driver develop= per is constrained).

> > We need a way to provide the U-Boot nodes/properties in a
> > form that the prior stage can consume and integrate with its buil= d
> > system. Is TF-A the only thing being discussed here? If so, let&#= 39;s just
> > do it. We have the u-boot.dtsi and we can use binman to put the i= mage
> > together, for example. Or we can get clever and create some sort = of
> > overlay dtb.
> >
> > Step 3a. But I don't want to do that. a) If U-Boot needs this= stuff
> > then it will need to build it in and use two devicetrees, one int= ernal
> > and one from the prior stage....well that is not very efficient a= nd it
> > is going to be confusing for people to figure out what U-Boot is<= br> > > actually doing. But we actually already do that in a lot of cases=
> > where U-Boot passes a DT to the kernel which is different to the = one
> > it uses. So perhaps we have three devicetrees? OMG.
>
> No we don't. That's a moot point. If you separate the DTs U-Bo= ot
> provides the internal one and inherits one 'generic'.=C2=A0 Li= nux will be able to use
> that.=C2=A0 So the only case were you'll need 3 DTs is if the *ven= dor* breaks the
> DT across kernel versions,=C2=A0 In which case there's not much yo= u can do to
> begin with and that's already a case we have to deal with.
>
> > b) Well then
> > U-Boot can have its own small devicetree with its bits and then U= -Boot
> > can merge the two when it starts. Again that is not very efficien= t. It
> > means that U-Boot cannot be controlled by the prior stage (e.g. t= o get
> > its public key from there or to enable/disable the console), so > > unified firmware config is not possible. It will get very confusi= ng,
> > particularly for debugging U-Boot. c) Some other scheme to avoid<= br> > > accepting step 3...please stop!
> >
> > Step 4: Yes, but there is QEMU, which makes the devicetree up out= of
> > whole cloth. What about that? Well, we are just going to have to = deal
> > with that. We can easily merge in the U-Boot nodes/properties and=
> > update the U-Boot CI scripts to do this, as needed, e.g. with
> > qemu-riscv64_spl. It's only one use case, although Xen might = do
> > something similar.
> >
> > To my mind, that deals with both the build-time and run-time issu= es.
> > We have a discoverable DT in U-Boot, which should be considered t= he
> > source of truth for most boards. We can sync it with Linux
> > automatically with the tooling that I hope Rob Herring will come = up
> > with. We can use an empty one where there really is no default, > > although I'd argue that is making perfect an enemy of the goo= d.
> >
> > Step 5: If we get clever and want to remove them from the U-Boot = tree
> > and pick them up from somewhere else, we can do that with suffici= ent
> > tooling. Perhaps we should set a timeline for that? A year? Two? = Six?
>
> We can start slowly migrating boards and see how that works out.
> We could either use 2 device trees as you proposed, or have u-boot mer= ge
> the 'u-boot' DTB and the inherited DTB before DM comes up.=C2= =A0 OTOH I'd prefer
> if linux gets handed a clean device tree without the u-boot internals = in
> it, so I think 2 discrete DTs is cleaner overall.

Why does it matter if Linux sees some u-boot, properties?=C2=A0 If some hug= e
stink is going to be thrown, we could probably prune them out at run
time but it's already being passed N disabled nodes, yes?

--
Tom


--
=
=
Fran=C3=A7ois-Fr=C3= =A9d=C3=A9ric Ozog=C2=A0|=C2=A0Director Business Development
T:=C2=A0+33.67221.6485
francois.ozog@linaro.org=C2=A0|=C2=A0Skype:=C2=A0ffozog

--00000000000002b16905cf559980--