Hi Tom Le mer. 27 oct. 2021 à 20:06, Tom Rini <tr...@konsulko.com> a écrit :
> On Wed, Oct 27, 2021 at 09:24:25AM -0600, Simon Glass wrote: > > Hi Mark, > > > > On Wed, 27 Oct 2021 at 09:11, Mark Kettenis <mark.kette...@xs4all.nl> > wrote: > > > > > > > From: François Ozog <francois.o...@linaro.org> > > > > Date: Wed, 27 Oct 2021 15:15:01 +0200 > > > > > > > > Hi, > > > > > > > > On Wed, 27 Oct 2021 at 14:48, Tom Rini <tr...@konsulko.com> wrote: > > > > > > > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > > > > > > Hi all, > > > > > > > > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <tr...@konsulko.com> > wrote: > > > > > > > > > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <tr...@konsulko.com> > wrote: > > > > > > > > > > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass > wrote: > > > > > > > > > > Hi François, > > > > > > > > > > > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > > > > > francois.o...@linaro.org> wrote: > > > > > > > > > > > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass < > s...@chromium.org> > > > > > a écrit : > > > > > > > > > > >> > > > > > > > > > > >> Hi Tom, Bin,François, > > > > > > > > > > >> > > > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini < > tr...@konsulko.com> > > > > > wrote: > > > > > > > > > > >> > > > > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng > wrote: > > > > > > > > > > >> > > Hi Simon, > > > > > > > > > > >> > > > > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass < > > > > > s...@chromium.org> wrote: > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > With Ilias' efforts we have dropped > OF_PRIOR_STAGE and > > > > > OF_HOSTFILE so > > > > > > > > > > >> > > > there are only three ways to obtain a > devicetree: > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > - OF_SEPARATE - the normal way, where the > devicetree > > > > > is built and > > > > > > > > > > >> > > > appended to U-Boot > > > > > > > > > > >> > > > - OF_EMBED - for development purposes, the > > > > > devicetree is embedded in > > > > > > > > > > >> > > > the ELF file (also used for EFI) > > > > > > > > > > >> > > > - OF_BOARD - the board figures it out on its > own > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > The last one is currently set up so that no > devicetree > > > > > is needed at all > > > > > > > > > > >> > > > in the U-Boot tree. Most boards do provide one, > but > > > > > some don't. Some > > > > > > > > > > >> > > > don't even provide instructions on how to boot > on the > > > > > board. > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > The problems with this approach are documented > at [1]. > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > In practice, OF_BOARD is not really distinct > from > > > > > OF_SEPARATE. Any board > > > > > > > > > > >> > > > can obtain its devicetree at runtime, even it > is has a > > > > > devicetree built > > > > > > > > > > >> > > > in U-Boot. This is because U-Boot may be a > second-stage > > > > > bootloader and its > > > > > > > > > > >> > > > caller may have a better idea about the hardware > > > > > available in the machine. > > > > > > > > > > >> > > > This is the case with a few QEMU boards, for > example. > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > So it makes no sense to have OF_BOARD as a > 'choice'. It > > > > > should be an > > > > > > > > > > >> > > > option, available with either OF_SEPARATE or > OF_EMBED. > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > This series makes this change, adding various > missing > > > > > devicetree files > > > > > > > > > > >> > > > (and placeholders) to make the build work. > > > > > > > > > > >> > > > > > > > > > > > > >> > > Adding device trees that are never used sounds > like a > > > > > hack to me. > > > > > > > > > > >> > > > > > > > > > > > > >> > > For QEMU, device tree is dynamically generated on > the fly > > > > > based on > > > > > > > > > > >> > > command line parameters, and the device tree you > put in > > > > > this series > > > > > > > > > > >> > > has various hardcoded <phandle> values which > normally do > > > > > not show up > > > > > > > > > > >> > > in hand-written dts files. > > > > > > > > > > >> > > > > > > > > > > > > >> > > I am not sure I understand the whole point of > this. > > > > > > > > > > >> > > > > > > > > > > > >> > I am also confused and do not like the idea of > adding > > > > > device trees for > > > > > > > > > > >> > platforms that are capable of and can / do have a > device > > > > > tree to give us > > > > > > > > > > >> > at run time. > > > > > > > > > > >> > > > > > > > > > > >> (I'll just reply to this one email, since the same > points > > > > > applies to > > > > > > > > > > >> all replies I think) > > > > > > > > > > >> > > > > > > > > > > >> I have been thinking about this and discussing it > with people > > > > > for a > > > > > > > > > > >> few months now. I've been signalling a change like > this for > > > > > over a > > > > > > > > > > >> month now, on U-Boot contributor calls and in > discussions > > > > > with Linaro > > > > > > > > > > >> people. I sent a patch (below) to try to explain > things. I > > > > > hope it is > > > > > > > > > > >> not a surprise! > > > > > > > > > > >> > > > > > > > > > > >> The issue here is that we need a devicetree in-tree in > > > > > U-Boot, to > > > > > > > > > > >> avoid the mess that has been created by > OF_PRIOR_STAGE, > > > > > OF_BOARD, > > > > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, > OF_HOSTFILE. > > > > > Between > > > > > > > > > > >> Ilias' series and this one we can get ourselves on a > stronger > > > > > footing. > > > > > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for > debugging/ELF > > > > > use. > > > > > > > > > > >> For more context: > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > >> > > > > > > > > > > >> BTW I did suggest to QEMU ARM that they support a way > of > > > > > adding the > > > > > > > > > > >> u-boot.dtsi but there was not much interest there (in > fact the > > > > > > > > > > >> maintainer would prefer there was no special support > even for > > > > > booting > > > > > > > > > > >> Linux directly!) > > > > > > > > > > > > > > > > > > > > > > i understand their point of view and agree with it. > > > > > > > > > > >> > > > > > > > > > > >> But in any case it doesn't really help U-Boot. I > > > > > > > > > > >> think the path forward might be to run QEMU twice, > once to > > > > > get its > > > > > > > > > > >> generated tree and once to give the 'merged' tree > with the > > > > > U-Boot > > > > > > > > > > >> properties in it, if people want to use U-Boot > features. > > > > > > > > > > >> > > > > > > > > > > >> I do strongly believe that OF_BOARD must be a run-time > > > > > option, not a > > > > > > > > > > >> build-time one. It creates all sorts of problems and > > > > > obscurity which > > > > > > > > > > >> have taken months to unpick. See the above patch for > the > > > > > rationale. > > > > > > > > > > >> > > > > > > > > > > >> To add to that rationale, OF_BOARD needs to be an > option > > > > > available to > > > > > > > > > > >> any board. At some point in the future it may become > a common > > > > > way > > > > > > > > > > >> things are done, e.g. TF-A calling U-Boot and > providing a > > > > > devicetree > > > > > > > > > > >> to it. It doesn't make any sense to have people decide > > > > > whether or not > > > > > > > > > > >> to set OF_BOARD at build time, thus affecting how the > image > > > > > is put > > > > > > > > > > >> together. We'll end up with different U-Boot build > targets > > > > > like > > > > > > > > > > >> capricorn, capricorn_of_board and the like. It should > be > > > > > obvious where > > > > > > > > > > >> that will lead. Instead, OF_BOARD needs to become a > commonly > > > > > used > > > > > > > > > > >> option, perhaps enabled by most/all boards, so that > this sort > > > > > of build > > > > > > > > > > >> explosion is not needed. > > > > > > > > > > > > > > > > > > > > > > If you mean that when boards are by construction > providing a > > > > > DTB to U-Boot then I agree very much. But I don’t understand how > the patch > > > > > set supports it as it puts dts files for those boards to be built. > > > > > > > > > > >> > > > > > > > > > > >> U-Boot needs to be flexible enough to > > > > > > > > > > >> function correctly in whatever runtime environment in > which > > > > > it finds > > > > > > > > > > >> itself. > > > > > > > > > > >> > > > > > > > > > > >> Also as binman is pressed into service more and more > to build > > > > > the > > > > > > > > > > >> complex firmware images that are becoming > fashionable, it > > > > > needs a > > > > > > > > > > >> definition (in the devicetree) that describes how to > create > > > > > the image. > > > > > > > > > > >> We can't support that unless we are building a > devicetree, > > > > > nor can the > > > > > > > > > > >> running program access the image layout without that > > > > > information. > > > > > > > > > > >> > > > > > > > > > > >> François's point about 'don't use this with any > kernel' is > > > > > > > > > > >> germane...but of course I am not suggesting doing > that, since > > > > > OF_BOARD > > > > > > > > > > >> is, still, enabled. We already use OF_BOARD for > various > > > > > boards that > > > > > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and > 3, for > > > > > example > > > > > > > > > > >> (as I said in the cover letter "Most boards do > provide one, > > > > > but some > > > > > > > > > > >> don't."). So this series is just completing the > picture by > > > > > enforcing > > > > > > > > > > >> that *some sort* of devicetree is always present. > > > > > > > > > > > > > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the > default. > > > > > > > > > > > > > > > > > > > > I think the key point that will get you closer to where > I am on > > > > > this > > > > > > > > > > issue, is that OF_BOARD needs to be a run-time option. At > > > > > present it > > > > > > > > > > has build-time effects and this is quite wrong. If you go > > > > > through all > > > > > > > > > > the material I have written on this I think I have > motivated > > > > > that very > > > > > > > > > > clearly. > > > > > > > > > > > > > > > > > > > > Another big issue is that I believe we need ONE > devicetree for > > > > > U-Boot, > > > > > > > > > > not two that get merged by U-Boot. Again I have gone > through > > > > > that in a > > > > > > > > > > lot of detail. > > > > > > > > > > > > > > > > > > I have a long long reply to your first reply here saved, > but, maybe > > > > > > > > > here's the biggest sticking point. To be clear, you agree > that > > > > > U-Boot > > > > > > > > > needs to support being passed a device tree to use, at run > time, > > > > > yes? > > > > > > > > > > > > > > > > Yes. The OF_BOARD feature provides this. > > > > > > > > > > > > > > > > > > > > > > > > > > And in that case, would not be using the "fake" tree we > built in? > > > > > > > > > > > > > > > > Not at runtime. > > > > > > > > > > > > > > OK. > > > > > > > > > > > > > > > > So is the sticking point here that we really have two > classes of > > > > > > > > > devices, one class where we will never ever be given the > device > > > > > tree at > > > > > > > > > run time (think BeagleBone Black) and one where we will > always be > > > > > given > > > > > > > > > one at run time (think Raspberry Pi) ? > > > > > > > > > > > > > > > > I'm not sure it will be that black and white. I suspect > there will be > > > > > > > > (many) boards which can boot happily with the U-Boot > devicetree but > > > > > > > > can also accept one at runtime, if provided. For example, > you may > > > > > want > > > > > > > > to boot with or without TF-A or some other, earlier stage. > > > > > > > > > > > > > > I'm not sure I see the value in making this a gray area. > There's very > > > > > > > much a class of "never" boards. There's also the class of > "can" today. > > > > > > > Maybe as part of a developer iterative flow it would be nice > to not > > > > > have > > > > > > > to re-flash the prior stage to change a DT, and just do it in > U-Boot > > > > > > > until things are happy, but I'm not sure what the use case is > for > > > > > > > overriding the previous stage. > > > > > > > > > > > > > > Especially since the pushback on this series I think has all > been "why > > > > > > > are we copying in a tree to build with? We don't want to use > it at run > > > > > > > time!". And then softer push back like "Well, U-Boot says we > have to > > > > > > > include the device tree file here, but we won't use it...". > > > > > > > > > > > > See below. > > > > > > > > > > > > > > > > > > > > > I believe we have got unstuck because OF_BOARD (perhaps > > > > > inadvertently) > > > > > > > > provided a way to entirely omit a devicetree from U-Boot, > thus making > > > > > > > > things like binman and U-Boot /config impossible, for > example. So I > > > > > > > > want to claw that back, so there is always some sort of > devicetree in > > > > > > > > U-Boot, as we have for rpi_3, etc. > > > > > > > > > > > > > > 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. > > > > > > > > > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh > scripts > > > > > that know where to grab other known-good binaries of varying > licenses > > > > > that are needed to assemble something that boots. > > > > > > > > > > > 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. > > > > > > > > In my view U-Boot shall be able to leverage device tree format > (source and > > > > binary) to store its own data. > > > > When you say "the" DT, I always think this is "the" DT that is > passed to OS > > > > and in "that" DT, there should be no U-Boot entries. > > > > > > Why not? As long as the device tree validates, it is perfectly fine > > > to have additional nodes and properties present. The propertiesand > > > nodes will be simply ignored by the OS. > > > > > > OpenBSD will print: > > > > > > "binman" not configured > > > > > > for the binman node that some of the U-Boot board targets now have, > > > but it doesn't really make a difference. If there is a proper binding > > > for that node, I could simply filter it out. Or we have U-Boot filter > > > it out before the DT gets passed along like Tom suggests. > > > > Just on that point, I believe the binman falls into the same bucket > > that Tom is talking about here, in that it should be a standard > > binding. Ideally I would like this to become a standard format so that > > anything in firmware can use it to find stuff. I believe it is a good > > and extensible way to describe the structure of firmware across all > > projects. > > And at the risk of getting lost on specific details, if we look at: > > https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html > it says "In the future, it may be provided as part of a device blob, > along with the rest of the information about images to load." which is > one of the things the binman node solves, so we should probably solve > this problem once, for everyone rather than per-project. > i wish we could. We need RISC-V input here. > > -- > Tom > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
