[U-Boot-Users] using a flat device tree to drive u-boot config

[Jon Smirl]

On 8/3/08, Wolfgang Denk <wd at denx.de> wrote:
> In message <9e4733910808021858i766307b1q45b5bace59996d03 at 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.

-- 
Jon Smirl
jonsmirl at gmail.com