From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dirk Behme Date: Mon, 09 Apr 2012 09:52:15 +0200 Subject: [U-Boot] [PATCH v4 2/6] fdt: Add support for embedded device tree (CONFIG_OF_EMBED) In-Reply-To: <1318693706-3381-3-git-send-email-sjg@chromium.org> References: <1318693706-3381-1-git-send-email-sjg@chromium.org> <1318693706-3381-3-git-send-email-sjg@chromium.org> Message-ID: <4F82952F.6040105@googlemail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 > --- ... > 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//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 "" > + > +to set the filename of the device tree source. Then put your device tree > +file into > + > + board//dts/.dts > + > +This should include your CPU or SOC's device tree file, placed in > +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 ?