On 04/04/2011 03:22 AM, Somebody in the thread at some point said:
Hi -
In a perfect world, the DT data would be tied to the hardware and provided by the bootloader to the kernel. It would be produced by hardware vendors who would only have to describe their hardware in this OS independent abstraction without having to write any kernel code. And it would allow for an existing kernel binary that was distributed prior the availability of the hardware to boot unmodified on that hardware.
Fair enough, having the DT in EEPROM would indeed be cool although it doesn't get away from the bootloader code to understand certain things on the nod (such as where the EEPROM with the DT code is mapped on that board, how to work the SPI interface on that SoC, how to bring up its SDRAM to have space for this...).
If it knows that much about the board by magic, is it not easier to leave the EEPROM reading to kernel code?
This is a pretty noble goal of course. But I'm skeptical. I'm afraid that the reality is just too messy for this to be achievable, except maybe for the easy cases. And the easy cases are not worth all this trouble.
Yeah.
But I don't care much if this is never achieved. Booting an existing binary on future hardware is not expected to work at the moment either. At least DT do provide the opportunity to force some consolidation and cleanups which is a sufficient reason already to go for it.
Sounds right.
What I fear is the situation where this mechanism designed to make things simpler would actually make them even more complicated. Because the simple fact of distributing knowledge and responsibilities across multiple entities (bootloader, DT representation, kernel) is multiplying the opportunities for bugs, version skews, and interpretation differences. A system that has to rely on externally provided data is always going to be way more vulnerable and error prone than a self contained system.
Absolutely. At least we can decide to avoid having U-Boot environment involved which is the current plan AIUI.
I would like to be proven wrong of course. But in the mean time, I'm making sure that the DT information in the bootloader can be user replaced, or if need be simply overridden with a transparent mechanism which is to simply append the DT of your choice to the kernel image.
I still didn't see why DT and bootloader are so closely associated in peoples' minds.
I can imagine one reason, which is that in the case a kernel supports many boards, you'd have this fat kernel image with many discrete DT tables embedded in it. Maybe the thinking is that casting the tables out of the kernel into what will AIUI be a set of files in a VFAT filesystem, and having the bootloader pick one, gets around that.
Another way to solve it, would be to encode the set of device trees supported in a way that removes redundancy. Then the additional data needed to resolve a generic OMAP3 device table into overo or beagle or any similar board would be a small increment. The encoded table can be initdata and gotten rid of after being rendered into the DT required.
I don't think having it built-in is a good idea either. In sync, yes.
"In sync" would practically mean the DT tables being part of the kernel source tree if I understood it, which I think is the right direction.
-Andy _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
