[U-Boot] [RFC PATCH 0/4] Run-time configuration of U-Boot via a flat device tree (fdt)

[Simon Glass]

Hi Jerry,

On Fri, Sep 2, 2011 at 4:42 AM, Jerry Van Baren <gvb.uboot at gmail.com> wrote:
> Hi Simon,
>
> On 09/01/2011 04:49 PM, Simon Glass wrote:
>>
>> At present in U-Boot configuration is mostly done using CONFIG options in
>> the
>> board file. This patch set aims to make it possible for a single U-Boot
>> binary to support multiple boards, with the exact configuration of each
>> board
>> controlled by a flat device tree (fdt). This is the approach recently
>> taken
>> by the ARM Linux kernel and has been used by PowerPC for some time.
>
> Very exciting.  I've thought about doing this for years, but never had the
> ambition (or time).

Thanks for your comments. Yes there was mention of it in the UBML a
few years ago:

http://lists.denx.de/pipermail/u-boot/2008-August/038052.html

where Wolfgang said:

> 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.

This is basically what my patch set sets out to do.

>
> [snip]
>
>> and add some defines to your board (only ARM is currently supported):
>>
>>  #define CONFIG_OF_CONTROL       (to enable run-time config control via
>> fdt)
>>  #define CONFIG_OF_EMBED or CONFIG_OF_SEPARATE
>>      (either build the fdt blob into U-Boot, or create a separate
>> u-boot.dtb)
>>  #define CONFIG_DEFAULT_DEVICE_TREE    "<your name>"
>>      (to specify the name of the device tree file is
>>       board/<vendor>/<board>/<your name>.dts)
>>
>> This patch set does not include any drivers which actually use the fdt. I
>> have
>> some concerns about spreading fdt code around the U-Boot code base so am
>> thinking of having a support file which makes this easier. I can provide a
>> UART driver modified to use fdt if there is interest.
>
> Please.  A concrete reference is very useful, especially for discussion.

I will try to create a driver for something for which we have a device
tree definition in the kernel. Will post to the list as an RFC.

>
>> It is important to understand that the fdt only selects options available
>> in
>> the platform / drivers. It cannot add new drivers (yet). So you must still
>> have the CONFIG option to enable the driver. For example, you need to
>> define
>> CONFIG_SYS_NS16550 to bring in the NS16550 driver, but can use the fdt to
>> specific the UART clock, peripheral address, etc. In very broad terms, the
>> CONFIG options in general control *what* driver files are pulled in, and
>> the
>> fdt controls *how* those files work.
>
> Sounds reasonable and practical.  One of the things u-boot struggles with is
> staying small (but it is nice to be able to make it all inclusive and big if
> you have the flash).

Yes to some extent this is a halfway house, but it is a way of
introducing this feature without changing the way things currently
work. I almost feel as if there are two types of configs, and perhaps
the naming should recognize that (SELECT_ and CONFIG_?). No, I don't
want to modify all the board files...

>
>> While only ARM is supported in this patch series, it should be easy enough
>> to
>> add support for other architectures.
>
> Exercise left for the students.  :-)

Yes - you can pretty-much just copy the ARM board.c code into your
board.c file to try this out.

Regards,
Simon

>
> [snip]
>
> Thanks!
> gvb
>