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

[Ilias Apalodimas]

Hi Tom,

> > > > > > > > 
> > > > > > > > This is the part that I too am still unhappy about.  I do not want
> > > > > > > > reference or fake or whatever device trees in the U-Boot source tree.
> > > > > > > > We should be able to _remove_ the ones we have, that are not required,
> > > > > > > > with doc/board/...rst explaining how to get / view one.  Not adding
> > > > > > > > more.
> > > > > > > 
> > > > > > > So this is a key point for me and the reason I completely disagree
> > > > > > > with this approach.  This proposal is working in the *exact* opposite
> > > > > > > direction and we'll never be able to get rid of device trees from
> > > > > > > U-Boot, even if at some point they move out of the kernel to a
> > > > > > > 'common' repo'.  I'll just repeat what I've been saying since v1.
> > > > > > > Personally I'd be way happier if we could figure out were the specific
> > > > > > > U-Boot config nodes are needed and when are they needed.  Based on
> > > > > > > what we figure out we could, pick up the device tree from a previous
> > > > > > > state bootloader and fix it up with our special nodes before we start
> > > > > > > using it, using internal DTS files (compiled to .dtbos or similar)
> > > > > > > that indeed belong in the u-boot tree.
> > 
> > > 
> > > Applying a devicetree overlay can be implemented in common/board_f.c
> > > before the first usage of the devicetree to initialize devices (there
> > > are some that are initialized before relocation).
> > 
> > Thanks for digging this up.  Tbh I misunderstood the original mail from
> > Mark.  When I read pre-reloc I assumed no C environment was up yet.
> > However this raises a few questions.
> > 1. The .dtbos will need to be embedded in the u-boot binary since
> > there's no FS access (or in some cases storage access to begin with)
> > 2. The RAM we have is going to be limited if we want to apply the overlays
> > before consoles etc are up, since it basically has to happen at some point
> > near 'fdtdec_setup'
> > 3.Are we are going to need some logic on how to apply the .dtbos? E.g think of
> > the same hardware with different configuration.  You'll be able to use the
> > same binary, if you can somehow configure which overlays you want to apply.
> 
> This has come up before and the answer has been "doing it this early
> will be too large" where large can mean either of .text space (we have
> many constrained platforms) or memory usage (this is before DRAM
> potentially).  It's also on the flip side one of those places where
> maybe it's less of a problem on arm64 (where prior stages will have
> initialized much already) than arm32 (where we are very early) and other
> platforms.  And we need solutions that work for both cases.


So I have an answer on my (3).a We can use the bloblist for that.

We could do something along the lines of 
1. Include .dtbos in u-boot source
2. Standardize the bloblist handover discussion we had across bootloaders,
so that the bloblist contains information of what .dtbos to apply.  We can
even take it a step further and request specific .dtbos to be applied
before/after DRAM init to save some boards from the DRAM issue.
3. U-Boot applies the .dtbos on the fly. 

What's more interesting is that looking around what we currently have, the
renesas RCAR platform is already doing something *very* similar [1].


[1] board/renesas/rcar-common/common.c -> fdtdec_board_setup

Cheers
/Ilias
> 
> -- 
> Tom