On Wed, Oct 27, 2021 at 10:17:05AM +0300, Ilias Apalodimas wrote:
Hi Simon,
On Tue, 26 Oct 2021 at 18:27, Simon Glass sjg@chromium.org wrote:
Hi Ilias,
On Tue, 26 Oct 2021 at 07:56, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon,
As I said here [1], this is moving on an entirely different direction I had in mind. I'd much prefer starting the discussions for a solution that allows us to scale.
I am missing the point here. Is there something in the plans that I don't know about?
I have some ideas, but haven't found time to code it and send patches yet.
FWIW I think the current code is still not clean for my taste. Commit 3b595da441cf ("fdtdec: allow board to provide fdt for CONFIG_OF_SEPARATE") allowed this function to be used regardless of the config options. IMHO we should have 2 clear options:
- U-Boot provides the DTB
Supported with: OF_SEPARATE
- It's somehow passed over to U-Boot
Supported with: OF_SEPARATE + OF_BOARD
That's exactly what I don't personally like. In your example OF_BOARD means "U-Boot has a DTB and here's a way to override it". In my head
In some ways this is just highlighting a long standing problem of working with DTB. There's certainly been some places where splitting the data from the driver has helped. But in some other places, my goodness has it made the development cycle worse. Doing this on QEMU probably is on one of the most annoying cases too since yes, you start by dumping the dtb you would get, then iterating the dts outside of the rest of the scope of your build. In the kernel you can "make dtbs" at least and get things spit out. I'm just repeating over here that the development cycle of working on device trees is at times not great.