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<s...@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?
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?
Many thanks and best regards
Dirk
P.S.: Any idea about
http://lists.denx.de/pipermail/u-boot/2012-March/120916.html
?
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
