Hi Jerry, On Fri, Sep 2, 2011 at 4:42 AM, Jerry Van Baren <gvb.ub...@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 > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
