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
