Lines Matching full:it

11 make it possible for a single U-Boot binary to support multiple boards,
17 for three reasons. Firstly it is easy to use, being a simple text file.
18 It is extensible since it consists of nodes and properties in a nice
22 compiler checks the text file and converts it to a compact binary
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
61 (typically in the 'device-tree-compiler' package), it is currently not used.
63 If you want to build your own dtc, it is kept here:
120 If CONFIG_OF_EMBED is defined, then it will be picked up and built into
124 If CONFIG_OF_SEPARATE is defined, then it will be built and placed in
138 it and passes it to U-Boot.
140 If CONFIG_OF_HOSTFILE is defined, then it will be read from a file on
151 Then U-Boot will copy that file to u-boot.dtb, put it in the .img file
158 when only the compiled-in environment is available. Therefore it is not
160 environment, for example (it will be ignored). After relocation, this
162 It is read-only and cannot be changed. It can optionally be used to
190 In some rare cases it is desirable to let SPL be able to select one DTB among
194 In this case it is possible to use CONFIG_SPL_MULTI_DTB. This option appends to
199 containing the board ID for example), it possible to start with a generic DTB
210 type. So for example it is not possible to build a single ARM binary
220 It is important to understand that the fdt only selects options
221 available in the platform / drivers. It cannot add new drivers (yet). So