On Fri, Dec 03, 2021 at 04:30:40PM +0200, Ilias Apalodimas wrote: > Hi Heinrich, > > On Fri, Dec 03, 2021 at 02:59:44PM +0100, Heinrich Schuchardt wrote: > > On 12/3/21 11:27, Mark Kettenis wrote: > > > > Date: Fri, 3 Dec 2021 09:50:44 +0200 > > > > From: Ilias Apalodimas <ilias.apalodi...@linaro.org> > > > > > > > > Hi Mark, > > > > > > > > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > Changes in v6: > > > > > > > > > - Fix description of OF_BOARD so it refers just to the > > > > > > > > > current state > > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > > > > > devicetrees > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > > > > > > list.so I am > > > > > > > > not in favor of this new version either. > > > > > > > > If you make a version without « fake DTs » as you name them, > > > > > > > > there are good > > > > > > > > advances in the documentation and other areas that would be > > > > > > > > better in > > > > > > > > mainline…. > > > > > > > > If I am the only one thinking this way and the patch can be > > > > > > > > accepted, I > > > > > > > > would love there is a warning in capital letters at the top of > > > > > > > > the DTS fake > > > > > > > > files that explains the intent of this fake DT, the possible > > > > > > > > outcomes of > > > > > > > > not using the one provided by the platform and the right way of > > > > > > > > dealing > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > 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. -- Tom
signature.asc
Description: PGP signature
