Hi Dirk,
On Mon, Apr 9, 2012 at 12:52 AM, Dirk Behme dirk.behme@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 Glasssjg@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.
- 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.
- 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