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 B21CDC433EF for ; Mon, 1 Nov 2021 11:06:38 +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 0518360FD9 for ; Mon, 1 Nov 2021 11:06:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 0518360FD9 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]:34762 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mhV9A-0005zZ-Su for qemu-devel@archiver.kernel.org; Mon, 01 Nov 2021 07:06:36 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44738) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mhV7r-000559-3o for qemu-devel@nongnu.org; Mon, 01 Nov 2021 07:05:15 -0400 Received: from mail-yb1-xb2c.google.com ([2607:f8b0:4864:20::b2c]:46974) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mhV7o-0004LX-Ac for qemu-devel@nongnu.org; Mon, 01 Nov 2021 07:05:14 -0400 Received: by mail-yb1-xb2c.google.com with SMTP id t127so43522805ybf.13 for ; Mon, 01 Nov 2021 04:05:11 -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=0cvaNl6QJABpR5+uAxdetn4xXNRMrhcsW8yuKeeI+WM=; b=Ztyn/+NmfXs6o6wETsW+MNgfCD+oRwghHiqSj4Q8gv2+LpOg0WWiWd8c6iSsgKVpkY 7CcADtlAsBWuilzJkoYqQ8FKhVnhfAdzuUve8SIvyXOipj5uim30BQWF4vZbmWnfjwok C7oqm0d2EtpbmnwmuvfM1dDoqoDK1OmeTSQ+y1ReQAz9iftIPHAfIvihbM0JIKBK9wmp R+oWNww+kEja5jDKYUsiz3ipu+gRh0iZm7YbPNikHqurRpbDuu+0GDfPSpp+C4ePFOUt eA2kF72J8qHonbV+0kx4I9Z3owGRdU8RtgfXxM3Ujv9X+rn1+1/Wcvsi1WUAivZ43cCC UXEA== 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=0cvaNl6QJABpR5+uAxdetn4xXNRMrhcsW8yuKeeI+WM=; b=kOfjsXLxboCKG5FFhOvH06dAjXQZ7ZCYV+JbK7qQcxI4RZL/MKzVsP4Upezus73kR5 w5Hc/qeU0MopYFdF6OgKOjr7Uo5Vuj2ebKWz3ehBCUpNHnmVrP32tII1N++2iwdEEaH5 AFvKHf+emdZB2EQBjwHFG6XAdm60k5s0M1O4J48lwG3nji7VGFPKmAQwimGjKHga3vpE gWE68cO7Ld84DZkYABDZiBoGis1Y27L48ImutG9E73hHZ7iSSYM7W/lVPQd/A70axioF oW8+9t7QARnZfSgjeFnPY4V8zMVmJFSxeG67HfjNGgT8nngloZZm6XQ0ryirqER1Y1Q3 fTgQ== X-Gm-Message-State: AOAM533Hu1eireMG+t+8z4n3YMKNbAg3fSqc25bgw56HGQUR4vbskLtP QZ04jwSs0PIJcXHdyN731sogMomNru0i2csVTMYr1w== X-Google-Smtp-Source: ABdhPJz99gJiyDHc2FO8JTrg9VXwkXKoUBnFPGEZieUxVcv6xC0TYp8EyAMIWEOiFLneM9yisMSvY1zOATEBkRBgL8E= X-Received: by 2002:a25:c68a:: with SMTP id k132mr17070225ybf.531.1635764710221; Mon, 01 Nov 2021 04:05:10 -0700 (PDT) MIME-Version: 1.0 References: <20211013010120.96851-1-sjg@chromium.org> <20211013013450.GJ7964@bill-the-cat> <20211014145626.GC7964@bill-the-cat> <20211014152801.GF7964@bill-the-cat> In-Reply-To: From: Ilias Apalodimas Date: Mon, 1 Nov 2021 13:04:33 +0200 Message-ID: Subject: Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option To: Simon Glass Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2607:f8b0:4864:20::b2c; envelope-from=ilias.apalodimas@linaro.org; helo=mail-yb1-xb2c.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.29 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 , Stephen Warren , Stefan Roese , Fabio Estevam , Rainer Boschung , Tom Rini , 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 , =?UTF-8?Q?Fran=C3=A7ois_Ozog?= , "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 , 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" Hi Simon, On Thu, 28 Oct 2021 at 05:51, Simon Glass wrote: > > Hi Ilias, > > On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas > wrote: > > > > Hi Simon, > > > > A bit late to the party, sorry! > > (Did you remember the beer? We'll probably need something stronger to sort this out :) > I am replying to this but I don't think it > is all that helpful for me to reply to a lot of things on this thread, > since I would not be adding much to my cover letter and patches) > > > > > [...] > > > > > > > > > > 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 could > > > > 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 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 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 the > > > different components. Binman was one effort there. I feel that putting > > > 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 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 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. > > The point is this was fine in 2011 were we had SPL only, but the reality > > today is completely different. There's previous stage boot loaders (and > > 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 not > > to mention it doesn't scale at all. > > I think the solution here may be the binman image packer. It works > from a description of the image (i.e. is data-driver) and can collect > all the pieces together. The U-Boot properties (and the ones required > by TF-A, etc.) can be added at package time. I am not sure I am following you here or why binman is relevant to this discussion. If the boot process doesn't require a FIP (e.g SPL + U-Boot proper or SPL -> EL3 -> U-Boot proper or TF-A + U-Boot) then using binman makes a lot of sense. If the boot process is TF-A -> U-Boot and requires a FIP, TF-A has it's own set of tools for preparing that [1] [2] , why would we want to teach binman FIP packaging? And if we do are you willing to keep it up to date with everything they come up with? IOW packaging the firmware is not U-Boot's responsibility, it's the vendors. Why should he not be able to choose FIP? (ST already changed that in u-boot btw). > > If you think about it, it doesn't matter what properties are in the DT > that is put into the firmware image. TF-A, for example, is presumably > reading a devicetree from flash, so what does it care if it has some > U-Boot properties in it? It doesn't, but the point here is entirely different. Today there's a number of U-Boot DTBs that are unable to boot a kernel. The direction we would like to is have the firmware provide a DTB that's usable for the kernel. Yes I know vendors mess things up and there's a correlation of the DTB and the kernel version, but let's set that aside for a moment. If we want to use a 'generic' DT then we have to make sure that whoever packages it knows what to put in there. That's why for me, it's very important to only allow *upstreamed only* DT properties for whoever ends up being responsible for the packaging. In that case you can demand TF-A to bundle U-Boot nodes in the DTB it produces if the board is supposed to use U-Boot. If those are internal only to U-Boot and not upstreamed this makes little sense to me and I don't see why people will agree to that. > > As to syncing, we have solved this using u-boot.dtsi files in U-Boot, > so I think this can be dealt with. > > > > > > > > > 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 things > > > 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 included in > > U-Boot source is not the right way to do that, not to mention cases were > > that's completely unrealistic (e.g QEMU or a board that reads the DTB from > > it's flash). > > I think you are at step 2. See above for my response. > > > > > > (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 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 scales, without > > having to add a bunch of unusable DTs in U-Boot. > > In what way does this not scale? How are the DTs unusable? If there is > a standard binding, we should be fine. The keyword here is the definition of 'standard'. If standard means upstreamed to DT spec, as I said before I don't see any problem. By unusable I was referring to the QEMU DTs you are trying to push into U-Boot or the RPI one. It doesn't scale because you have to maintain and upstream all the DTs in the U-Boot tree. The story so far is merge and forget for a big number of DTs, so I find it hard to believe that everyone will start behaving and sync up their DTs. I'd much rather prefer having a central repo and force people to use that. > > > > > > 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 just > > > 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 internal > > > and one from the prior stage....well that is not very efficient and it > > > 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* breaks the > > DT across kernel versions, In which case there's not much you can do to > > begin with and that's already a case we have to deal with. > > Linux actually doesn't care if the U-Boot properties are in the tree, > so long as we have proper bindings. My point here is we only need > either: > > a. one devicetree, shared with Linux and U-Boot (and TF-A?) > b. two devicetrees, one for use in firmware and one for passing to Linux > > We don't need to separate out the U-Boot properties into a second (or > third) devicetree. There just isn't any point. Again if we are talking about bindings that are upstream in the spec, then we agree. Depending on the SRAM limitation we can even do (a). If the vendor messes up the DT backwards compatibility then we can do (b). If you expect TF-A and FIP to go pick up the special bindings U-Boot needs, then we disagree. > > > > > > 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 efficient. It > > > means that U-Boot cannot be controlled by the prior stage (e.g. to get > > > 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 merge > > 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 in > > it, so I think 2 discrete DTs is cleaner overall. > > I know you would prefer that, but does it really matter in practice? > What is the objection, actually? > > As I mentioned on the call, I think the prior stage should do any > merging or fixing up. Trying to do that sort of thing in 'early' code > in U-Boot (or any other program, including Linux) is such a pain. With > U-Boot, for example, we don't even have any RAM available to do it > with half the time and it would dramatically increase the amount of > memory needed prior to relocation. It just isn't a very good idea to > try to do this in early code. It is also completely unnecessary, once > you get past the philosophical objections. > > If TF-A wants to be in the picture, let it deal with the implications > and responsibility thus incurred. TF-A has no right to tell U-Boot how > to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter > of the size of U-Boot. It duplicates loads of things in there. No one > will even *notice* an FDT merge function, which is actually only 70 > LOC: > Again I am repeating myself so here's a tl;dr of how I view this: 1. All DT bindings u-boot expect become part of the DT spec -- I am fine with whatever, since at this point it makes sense to say "You are booting u-boot go add whatever it expects, it's part of the spec". The prior stage boot loader can then obviously merge the DT fragments and everyone will be happy. 2. For the bindings that are not upstreamed, I'd prefer having u-boot do the fixup. Alternatively, we could provide fragments that are easy for TF-A to merge? By easy I don't mean read U-Boot code, it's .dts files, find the fragments you need and add them manually... [...] [1] https://wiki.st.com/stm32mpu/wiki/How_to_configure_TF-A_FW_CONFIG [2] https://trustedfirmware-a.readthedocs.io/en/latest/design/trusted-board-boot-build.html Regards /Ilias 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 CC7B3C433F5 for ; Mon, 1 Nov 2021 11:13:53 +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 3E63060C40 for ; Mon, 1 Nov 2021 11:13:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3E63060C40 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 75451831C9; Mon, 1 Nov 2021 12:13:50 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (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=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="Ztyn/+Nm"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 214EB835D4; Mon, 1 Nov 2021 12:05:19 +0100 (CET) Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (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 BCC9C8203C for ; Mon, 1 Nov 2021 12:05:11 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=ilias.apalodimas@linaro.org Received: by mail-yb1-xb30.google.com with SMTP id q74so37691608ybq.11 for ; Mon, 01 Nov 2021 04:05:11 -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=0cvaNl6QJABpR5+uAxdetn4xXNRMrhcsW8yuKeeI+WM=; b=Ztyn/+NmfXs6o6wETsW+MNgfCD+oRwghHiqSj4Q8gv2+LpOg0WWiWd8c6iSsgKVpkY 7CcADtlAsBWuilzJkoYqQ8FKhVnhfAdzuUve8SIvyXOipj5uim30BQWF4vZbmWnfjwok C7oqm0d2EtpbmnwmuvfM1dDoqoDK1OmeTSQ+y1ReQAz9iftIPHAfIvihbM0JIKBK9wmp R+oWNww+kEja5jDKYUsiz3ipu+gRh0iZm7YbPNikHqurRpbDuu+0GDfPSpp+C4ePFOUt eA2kF72J8qHonbV+0kx4I9Z3owGRdU8RtgfXxM3Ujv9X+rn1+1/Wcvsi1WUAivZ43cCC UXEA== 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=0cvaNl6QJABpR5+uAxdetn4xXNRMrhcsW8yuKeeI+WM=; b=tGkCjtxySJuWrAjO4V+CL3ATSIXKxWsXHRGpgyblw0QPP7jqQm1gkEvmVdLzAMAYkb X719Jn2YFLceStQOpglmzG3X2KhU/Hp+Ii60OFhT6Zhcd9G8OkklP0nAeq3z1uIVvMI9 AKcEy+wM9iBohvs6V4qKnr1xen2he9CvNn9wzgsbW0KDcBX/19UZD6ZpU4h6tlR76MwZ drtneFpNcAIbUmFt6R4Pw+C2RVgS4KpXMbJ2jVID0zt8vJk4UJJdomgED3wYdS9Ja38L iPAqwEK0L+zS2HhJrTETy2vzqzMD8/SxQQIGPIjYWFZky9D8u6zzrwCtT90Hxwc0C/8p /o1A== X-Gm-Message-State: AOAM5302shoQTAXbNLIOwkpnLufDNdba4rPobUex3mCpSrJd4msGXHzp Db3lXe5B2J2l1hKfpFjtF2JagQhnDGsy1sGD2KMOOQ== X-Google-Smtp-Source: ABdhPJz99gJiyDHc2FO8JTrg9VXwkXKoUBnFPGEZieUxVcv6xC0TYp8EyAMIWEOiFLneM9yisMSvY1zOATEBkRBgL8E= X-Received: by 2002:a25:c68a:: with SMTP id k132mr17070225ybf.531.1635764710221; Mon, 01 Nov 2021 04:05:10 -0700 (PDT) MIME-Version: 1.0 References: <20211013010120.96851-1-sjg@chromium.org> <20211013013450.GJ7964@bill-the-cat> <20211014145626.GC7964@bill-the-cat> <20211014152801.GF7964@bill-the-cat> In-Reply-To: From: Ilias Apalodimas Date: Mon, 1 Nov 2021 13:04:33 +0200 Message-ID: Subject: Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option To: Simon Glass Cc: Tom Rini , =?UTF-8?Q?Fran=C3=A7ois_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 , 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" Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Mon, 01 Nov 2021 12:13:48 +0100 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 Simon, On Thu, 28 Oct 2021 at 05:51, Simon Glass wrote: > > Hi Ilias, > > On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas > wrote: > > > > Hi Simon, > > > > A bit late to the party, sorry! > > (Did you remember the beer? We'll probably need something stronger to sort this out :) > I am replying to this but I don't think it > is all that helpful for me to reply to a lot of things on this thread, > since I would not be adding much to my cover letter and patches) > > > > > [...] > > > > > > > > > > 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 could > > > > 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 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 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 the > > > different components. Binman was one effort there. I feel that putting > > > 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 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 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. > > The point is this was fine in 2011 were we had SPL only, but the reality > > today is completely different. There's previous stage boot loaders (and > > 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 not > > to mention it doesn't scale at all. > > I think the solution here may be the binman image packer. It works > from a description of the image (i.e. is data-driver) and can collect > all the pieces together. The U-Boot properties (and the ones required > by TF-A, etc.) can be added at package time. I am not sure I am following you here or why binman is relevant to this discussion. If the boot process doesn't require a FIP (e.g SPL + U-Boot proper or SPL -> EL3 -> U-Boot proper or TF-A + U-Boot) then using binman makes a lot of sense. If the boot process is TF-A -> U-Boot and requires a FIP, TF-A has it's own set of tools for preparing that [1] [2] , why would we want to teach binman FIP packaging? And if we do are you willing to keep it up to date with everything they come up with? IOW packaging the firmware is not U-Boot's responsibility, it's the vendors. Why should he not be able to choose FIP? (ST already changed that in u-boot btw). > > If you think about it, it doesn't matter what properties are in the DT > that is put into the firmware image. TF-A, for example, is presumably > reading a devicetree from flash, so what does it care if it has some > U-Boot properties in it? It doesn't, but the point here is entirely different. Today there's a number of U-Boot DTBs that are unable to boot a kernel. The direction we would like to is have the firmware provide a DTB that's usable for the kernel. Yes I know vendors mess things up and there's a correlation of the DTB and the kernel version, but let's set that aside for a moment. If we want to use a 'generic' DT then we have to make sure that whoever packages it knows what to put in there. That's why for me, it's very important to only allow *upstreamed only* DT properties for whoever ends up being responsible for the packaging. In that case you can demand TF-A to bundle U-Boot nodes in the DTB it produces if the board is supposed to use U-Boot. If those are internal only to U-Boot and not upstreamed this makes little sense to me and I don't see why people will agree to that. > > As to syncing, we have solved this using u-boot.dtsi files in U-Boot, > so I think this can be dealt with. > > > > > > > > > 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 things > > > 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 included in > > U-Boot source is not the right way to do that, not to mention cases were > > that's completely unrealistic (e.g QEMU or a board that reads the DTB from > > it's flash). > > I think you are at step 2. See above for my response. > > > > > > (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 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 scales, without > > having to add a bunch of unusable DTs in U-Boot. > > In what way does this not scale? How are the DTs unusable? If there is > a standard binding, we should be fine. The keyword here is the definition of 'standard'. If standard means upstreamed to DT spec, as I said before I don't see any problem. By unusable I was referring to the QEMU DTs you are trying to push into U-Boot or the RPI one. It doesn't scale because you have to maintain and upstream all the DTs in the U-Boot tree. The story so far is merge and forget for a big number of DTs, so I find it hard to believe that everyone will start behaving and sync up their DTs. I'd much rather prefer having a central repo and force people to use that. > > > > > > 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 just > > > 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 internal > > > and one from the prior stage....well that is not very efficient and it > > > 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* breaks the > > DT across kernel versions, In which case there's not much you can do to > > begin with and that's already a case we have to deal with. > > Linux actually doesn't care if the U-Boot properties are in the tree, > so long as we have proper bindings. My point here is we only need > either: > > a. one devicetree, shared with Linux and U-Boot (and TF-A?) > b. two devicetrees, one for use in firmware and one for passing to Linux > > We don't need to separate out the U-Boot properties into a second (or > third) devicetree. There just isn't any point. Again if we are talking about bindings that are upstream in the spec, then we agree. Depending on the SRAM limitation we can even do (a). If the vendor messes up the DT backwards compatibility then we can do (b). If you expect TF-A and FIP to go pick up the special bindings U-Boot needs, then we disagree. > > > > > > 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 efficient. It > > > means that U-Boot cannot be controlled by the prior stage (e.g. to get > > > 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 merge > > 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 in > > it, so I think 2 discrete DTs is cleaner overall. > > I know you would prefer that, but does it really matter in practice? > What is the objection, actually? > > As I mentioned on the call, I think the prior stage should do any > merging or fixing up. Trying to do that sort of thing in 'early' code > in U-Boot (or any other program, including Linux) is such a pain. With > U-Boot, for example, we don't even have any RAM available to do it > with half the time and it would dramatically increase the amount of > memory needed prior to relocation. It just isn't a very good idea to > try to do this in early code. It is also completely unnecessary, once > you get past the philosophical objections. > > If TF-A wants to be in the picture, let it deal with the implications > and responsibility thus incurred. TF-A has no right to tell U-Boot how > to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter > of the size of U-Boot. It duplicates loads of things in there. No one > will even *notice* an FDT merge function, which is actually only 70 > LOC: > Again I am repeating myself so here's a tl;dr of how I view this: 1. All DT bindings u-boot expect become part of the DT spec -- I am fine with whatever, since at this point it makes sense to say "You are booting u-boot go add whatever it expects, it's part of the spec". The prior stage boot loader can then obviously merge the DT fragments and everyone will be happy. 2. For the bindings that are not upstreamed, I'd prefer having u-boot do the fixup. Alternatively, we could provide fragments that are easy for TF-A to merge? By easy I don't mean read U-Boot code, it's .dts files, find the fragments you need and add them manually... [...] [1] https://wiki.st.com/stm32mpu/wiki/How_to_configure_TF-A_FW_CONFIG [2] https://trustedfirmware-a.readthedocs.io/en/latest/design/trusted-board-boot-build.html Regards /Ilias