[U-Boot] [PATCH v4 2/6] fdt: Add support for embedded device tree (CONFIG_OF_EMBED)

[Simon Glass]

Hi Dirk,

On Mon, Apr 9, 2012 at 12:52 AM, Dirk Behme <dirk.behme at googlemail.com> wrote:
> Dear Simon,
>
>
> On 15.10.2011 17:48, Simon Glass wrote:
>>
>> This new option allows U-Boot to embed a binary device tree into its image
>> to allow run-time control of peripherals. This device tree is for U-Boot's
>> own use and is not necessarily the same one as is passed to the kernel.
>>
>> The device tree compiler output should be placed in the $(obj)
>> rooted tree. Since $(OBJCOPY) insists on adding the path to the
>> generated symbol names, to ensure consistency it should be
>> invoked from the directory where the .dtb file is located and
>> given the input file name without the path.
>>
>> This commit contains my entry for the ugliest Makefile / shell interaction
>> competition.
>>
>> Signed-off-by: Simon Glass<sjg at chromium.org>
>> ---
>
> ...
>
>> diff --git a/doc/README.fdt-control b/doc/README.fdt-control
>> new file mode 100644
>> index 0000000..3f8bb5a
>> --- /dev/null
>> +++ b/doc/README.fdt-control
>
> ...
>
> Reading your README.fdt-control and browsing the source code a little for
> the CONFIG_OF_* options I found two questions. Sorry if I haven't read
> carefully enough ;)
>
>
>> +Device Tree Control in U-Boot
>> +=============================
>> +
>> +This feature provides for run-time configuration of U-Boot via a flat
>> +device tree (fdt). U-Boot configuration has traditionally been done
>> +using CONFIG options in the board config file. This feature 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.
>> +
>> +The fdt is a convenient vehicle for implementing run-time configuration
>> +for three reasons. Firstly it is easy to use, being a simple text file.
>> +It is extensible since it consists of nodes and properties in a nice
>> +hierarchical format.
>> +
>> +Finally, there is already excellent infrastructure for the fdt: a
>> +compiler checks the text file and converts it to a compact binary
>> +format, and a library is already available in U-Boot (libfdt) for
>> +handling this format.
>> +
>> +The dts directory contains a Makefile for building the device tree blob
>> +and embedding it in your U-Boot image. This is useful since it allows
>> +U-Boot to configure itself according to what it finds there. If you have
>> +a number of similar boards with different peripherals, you can describe
>> +the features of each board in the device tree file, and have a single
>> +generic source base.
>> +
>> +To enable this feature, add CONFIG_OF_CONTROL to your board config file.
>> +
>> +
>
> ...
>
>> +Where do I get an fdt file for my board?
>> +----------------------------------------
>> +
>> +You may find that the Linux kernel has a suitable file. Look in the
>> +kernel source in arch/<arch>/boot/dts.
>> +
>> +If not you might find other boards with suitable files that you can
>> +modify to your needs. Look in the board directories for files with a
>> +.dts extension.
>> +
>> +Failing that, you could write one from scratch yourself!
>> +
>> +
>> +Configuration
>> +-------------
>> +
>> +Use:
>> +
>> +#define CONFIG_DEFAULT_DEVICE_TREE     "<name>"
>> +
>> +to set the filename of the device tree source. Then put your device tree
>> +file into
>> +
>> +       board/<vendor>/dts/<name>.dts
>> +
>> +This should include your CPU or SOC's device tree file, placed in
>> +arch/<arch>/dts, and then make any adjustments required. The name of this
>> +is CONFIG_ARCH_DEVICE_TREE.dts.
>> +
>> +If CONFIG_OF_EMBED is defined, then it will be picked up and built into
>> +the U-Boot image (including u-boot.bin).
>> +
>> +If CONFIG_OF_SEPARATE is defined, then it will be built and placed in
>> +a u-boot.dtb file alongside u-boot.bin. A common approach is then to
>> +join the two:
>> +
>> +       cat u-boot.bin u-boot.dtb>image.bin
>> +
>> +and then flash image.bin onto your board.
>
>
> 1. Above, the README.fdt-control talks about "make it possible for a single
> U-Boot binary to support multiple boards". Now, if I understood correctly,
> the 'Configuration' section above describes how to include/append *one* dtb.
> But wouldn't we need to include *multiple* dtbs to support multiple boards?

The intent is that you build one u-boot.bin (same for all your
boards), and then flash it along with the correct device tree binary
for your board, when you flash your board.

What you ask for isn't necessarily useful for U-Boot in the same way
as it is for the kernel, since there is in general no way for U-Boot
to probe which hardware it has. For the kernel we can do this by
having U-Boot select from the available FDTs and pass one to the
kernel. For U-Boot there would need to be some sort of hardware
register / strapping to select this. This would be a board-specific
thing and one wonders whether it might not be better just to select
the correct hardware/device tree at flashing time.

>
> 2. The section 'Where do I get an fdt file for my board' talks about taking
> the fdt from the Linux kernel. This is fine. Is U-Boot able to pass the
> included/appended (OF_EMBED/OF_SEPARATE) dtb to the Linux kernel, then, too?
> Or is the included/appended dtb only used for the U-Boot configuration? And
> the one passed to the Linux kernel has to be taken from anywhere else,
> additionally?

There is no specific support for passing the appended dtb to the
kernel, although it would not be hard to add. The reason is that is is
common to field-upgrade U-Boot and the kernel at different times. In
fact U-Boot may never change after shipping, yet every kernel may
require a new device tree binary to go with it.

Basically the intent was not to interfere in any way with the way
U-Boot already selects and passes an device tree to the kernel.

>
> Many thanks and best regards
>
> Dirk
>
> P.S.: Any idea about
>
> http://lists.denx.de/pipermail/u-boot/2012-March/120916.html

Will take a look.

>
> ?
>
>

Regards,
Simon