On 8/3/08, Wolfgang Denk wd@denx.de wrote:
In message 9e4733910808021858i766307b1q45b5bace59996d03@mail.gmail.com you wrote:
What about creating a tool that parses a device tree and creates (or updates) the board header file? This will retain compatibility with other platforms, clean up the existing header files (they won't need to contain as much information), and reduce the amount of changes to U-Boot itself.
That's a good idea. I have used variation on this concept in the past and they have worked out well.
A much more powerful concept is to have U-Boot read and interpret the DT dynamically - only then can you use the same U-Boot binary image on different board configurations, which is an important feature for many board vendors.
A combination of the two approaches may be best.
During the build process feed uboot all of the DTS files you want it to be able to handle. That will let it figure out the right config flags to set when building the image. This will allow uboot to compile with the minimal set of needed features and make it much easier to get started with. Of course current DTS file will need some more info added like DRAM timings.
Sybase uses this process for cell phone databases. You start with a full feature db engine and develop your code against it. When your code is finished you run all of the commands and the engine tracks which SQL features you used. It then generates a new, smaller db engine that only supports those features.
BTW, how do know which DT to dynamically interpret? If you are installing a universal uboot you still are going to have to install a different DT in each model. If you're installing a different DT you might as well install a different uboot. I guess the intention is to have three pieces - uboot, DT, kernel.