u-boot/doc/README.fdt-control

1 # SPDX-License-Identifier: GPL-2.0+
5 Device Tree Control in U-Boot
8 This feature provides for run-time configuration of U-Boot via a flat
9 device tree (fdt). U-Boot configuration has traditionally been done
11 make it possible for a single U-Boot binary to support multiple boards,
13 tree (fdt). This is the approach recently taken by the ARM Linux kernel
16 The fdt is a convenient vehicle for implementing run-time configuration
21 Finally, there is already excellent infrastructure for the fdt: a
23 format, and a library is already available in U-Boot (libfdt) for
27 and embedding it in your U-Boot image. This is useful since it allows
28 U-Boot to configure itself according to what it finds there. If you have
33 To enable this feature, add CONFIG_OF_CONTROL to your board config file.
37 ---------------------------
39 An fdt can be specified in source format as a text file. To read about
40 the fdt syntax, take a look at the specification here:
47 	Documentation/devicetree/booting-without-of.txt
51 	http://lists.ozlabs.org/listinfo/devicetree-discuss
57 -----
60 provided by U-Boot automatically. If you have a system version of dtc
61 (typically in the 'device-tree-compiler' package), it is currently not used.
76 	$ dtc -v
77 	Version: DTC 1.2.0-g2cb4b51f
92 Where do I get an fdt file for my board?
93 ----------------------------------------
106 -------------
121 the U-Boot image (including u-boot.bin). This is suitable for debugging
125 a u-boot.dtb file alongside u-boot-nodtb.bin. A common approach is then to
128 	cat u-boot-nodtb.bin u-boot.dtb >image.bin
130 and then flash image.bin onto your board. Note that U-Boot creates
131 u-boot-dtb.bin which does the above step for you also. Resulting
132 u-boot.bin is a copy of u-boot-dtb.bin in this case. If you are using
133 CONFIG_SPL_FRAMEWORK, then u-boot.img will be built to include the device
136 If CONFIG_OF_BOARD is defined, a board-specific routine will provide the
138 it and passes it to U-Boot.
141 startup. This is only useful for sandbox. Use the -d flag to U-Boot to
149 	make EXT_DTB=boot/am335x-boneblack-pubkey.dtb
151 Then U-Boot will copy that file to u-boot.dtb, put it in the .img file
152 if used, and u-boot-dtb.bin.
154 If you wish to put the fdt at a different address in memory, you can
156 address of the fdt binary blob, and will override either of the options.
158 when only the compiled-in environment is available. Therefore it is not
161 variable will be set to the address of the newly relocated fdt blob.
162 It is read-only and cannot be changed. It can optionally be used to
171 After board configuration is done, fdt supported u-boot can be build in two ways:
175     $ make DEVICE_TREE=<dts-file-name>
179 -----------------------
181 U-Boot can be divided into three phases: TPL, SPL and U-Boot proper.
183 The full device tree is available to U-Boot proper, but normally only a subset
184 (or none at all) is available to TPL and SPL. See 'Pre-Relocation Support' and
185 'SPL Support' in doc/driver-model/README.txt for more details.
189 ----------------------------------------------------
202 platform may have to re-initiliaze the DM subusystem using dm_uninit() and
207 -----------
209 U-Boot is designed to build with a single architecture type and CPU
211 which runs on your AT91 and OMAP boards, relying on an fdt to configure
217 That said the complexity reduction by using fdt to support variants of
220 It is important to understand that the fdt only selects options
222 you must still have the CONFIG option to enable the driver. For example,
224 but can use the fdt to specific the UART clock, peripheral address, etc.
226 files are pulled in, and the fdt controls *how* those files work.
228 --
230 1-Sep-11