[PATCH 00/16] fdt: Make OF_BOARD a boolean option

[Andre Przywara]

On Thu, 14 Oct 2021 09:17:52 -0600
Simon Glass <sjg at chromium.org> wrote:

> Hi Tom,
> 
> On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini at 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.ozog at linaro.org> wrote:  
> > > >
> > > > Hi Simon
> > > >
> > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg at chromium.org> a écrit :  
> > > >>
> > > >> Hi Tom, Bin,François,
> > > >>
> > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini at 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 <sjg at 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-sjg@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.
> 
> >
> > 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 don't understand this: as Tom mentioned this is a platform decision:
either it provides a DT somewhere (flash, EEPROM, prior firmware stage),
or it doesn't. Sure, you can always hack your own DT in, somehow, for
development or experimentation purposes, but that is a separate issue.

Most of those platforms actually utilise some dynamic DTs, btw, where
software amends the DT on the fly:
- Highbank has a stub DT in SPI flash, and the management controller
firmware detects the size and some extra DRAM (DIMMs!) parameters at boot
time, and writes the /memory node accordingly.
- RPi3/4 have DT overlay files on the SD card, and depending on what a
user wrote in config.txt, they get applied to the DT (or not).
- Even for the Allwinner H616 we amend the OF_SEPARATE provided DT copy in
DRAM in TF-A, to carve out the DRAM region TF-A occupies.
- QEMU is the obvious example, where the whole machine is highly dynamic,
and there is no such thing as a fixed DT (how many cores?, how much
memory?, how many virtio devices?, flash?, SCSI?)

> 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.

I have the feeling this is because we abuse DT for this. Conceptually the
DT is not a configuration file, but a hardware description. I see that it
is also a nice and flexible, hierarchical key/value storage, for which we
have code in anyway, so it makes hardcoding data in the code easier to avoid.
But as we see now, this has problems as well.

So shall we separate those use cases? And attach just a tree with /binman
and /config (in DTB format), but treat this separately from the hardware
description? (Admittedly I have still to wrap my head around why we need
/binman at U-Boot runtime in the first place.)

Cheers,
Andre

> 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.
> 
> Regards,
> Simon