Kumar Gala wrote:
Let's say we have to support such situations, too.
- dts owned by u-boot??
I'm not sure about this. I tend to believe the dts belongs to the kernel.
Some questions/issues:
- ownership of .dts is problematic. I hate having a file duplicated
by both u-boot and kernel. However it also seems bad to make the build of either depend on the user grabbing a dts from some third party. Ideas? A concrete example would be the MPC8349 ADS/SYS/MDS port. Boards ship with an "old" u-boot, thus we need a kernel wrapper with .dts. However, newer u-boot's can (hopefully will) have a dts in them
Can we provide the dts as a separate blob that gets built with the kernel image? From U-Boot's point of view, this could be a multi-file image which combines the dts and the kernel into a single file so that users don't have to care much about this.
The problem is that there are somethings that u-boot knows that needs to go into the blob (memory size, boot args, initrd info, frequencies, etc.)
[snip]
- kumar
A thought that keeps recurring (but I've suppressed because I don't have time to play...) is that it would be Really Cool[tm] to store the u-boot env variables in a flat tree and then pass the env/tree to linux. It also sounds like a major change & disruption to u-boot :-(. I haven't looked at what it would do to code size either.
U-boot could then be a better OpenBoot than OpenBoot ;-)
gvb