1 Device Tree Compiler Manual
2 ===========================
4 I - "dtc", the device tree compiler
6 1.1) Submitting Patches
12 4.3) Labels and References
14 II - The DT block format
16 2) Device tree generalities
17 3) Device tree "structure" block
18 4) Device tree "strings" block
24 1) convert-dtsv0 -- Conversion to Version 1
28 I - "dtc", the device tree compiler
29 ===================================
33 Source code for the Device Tree Compiler can be found at git.kernel.org.
35 The upstream repository is here:
37 git://git.kernel.org/pub/scm/utils/dtc/dtc.git
38 https://git.kernel.org/pub/scm/utils/dtc/dtc.git
40 The gitweb interface for the upstream respository is:
42 https://git.kernel.org/cgit/utils/dtc/dtc.git/
44 1.1) Submitting Patches
46 Patches should be sent to the maintainers:
47 David Gibson <david@gibson.dropbear.id.au>
48 Jon Loeliger <jdl@jdl.com>
49 and CCed to <devicetree-compiler@vger.kernel.org>.
53 The Device Tree Compiler, dtc, takes as input a device-tree in
54 a given format and outputs a device-tree in another format.
55 Typically, the input format is "dts", a human readable source
56 format, and creates a "dtb", or binary format as output.
58 The currently supported Input Formats are:
60 - "dtb": "blob" format. A flattened device-tree block with
61 header in one binary blob.
63 - "dts": "source" format. A text file containing a "source"
66 - "fs" format. A representation equivalent to the output of
67 /proc/device-tree where nodes are directories and
70 The currently supported Output Formats are:
72 - "dtb": "blob" format
74 - "dts": "source" format
76 - "asm": assembly language file. A file that can be sourced
77 by gas to generate a device-tree "blob". That file can
78 then simply be added to your Makefile. Additionally, the
79 assembly file exports some symbols that can be used.
84 The syntax of the dtc command line is:
86 dtc [options] [<input_filename>]
91 The name of the input source file. If no <input_filename>
92 or "-" is given, stdin is used.
95 Set the physical boot cpu.
98 Force. Try to produce output even if the input tree has errors.
101 Emit a brief usage and help message.
104 The source input format, as listed above.
107 The name of the generated output file. Use "-" for stdout.
110 The generated output format, as listed above.
112 -d <dependency_filename>
113 Generate a dependency file during compilation.
116 Quiet: -q suppress warnings, -qq errors, -qqq all
119 Make space for <number> reserve map entries
120 Relevant for dtb and asm output only.
123 Generates a __symbols__ node at the root node of the resulting blob
124 for any node labels used, and for any local references using phandles
125 it also generates a __local_fixups__ node that tracks them.
127 When using the /plugin/ tag all unresolved label references to
128 be tracked in the __fixups__ node, making dynamic resolution possible.
131 Generate automatically aliases for all node labels. This is similar to
132 the -@ option (the __symbols__ node contain identical information) but
133 the semantics are slightly different since no phandles are automatically
134 generated for labeled nodes.
137 Ensure the blob at least <bytes> long, adding additional
141 Print DTC version and exit.
144 Generate output conforming to the given <output_version>.
145 By default the most recent version is generated.
146 Relevant for dtb and asm output only.
149 The <output_version> defines what version of the "blob" format will be
150 generated. Supported versions are 1, 2, 3, 16 and 17. The default is
151 always the most recent version and is likely the highest number.
153 Additionally, dtc performs various sanity checks on the tree.
156 4) Device Tree Source file
160 Here is a very rough overview of the layout of a DTS source file:
163 sourcefile: versioninfo plugindecl list_of_memreserve devicetree
165 memreserve: label 'memreserve' ADDR ADDR ';'
166 | label 'memreserve' ADDR '-' ADDR ';'
168 devicetree: '/' nodedef
170 versioninfo: '/' 'dts-v1' '/' ';'
172 plugindecl: '/' 'plugin' '/' ';'
175 nodedef: '{' list_of_property list_of_subnode '}' ';'
177 property: label PROPNAME '=' propdata ';'
180 | '<' list_of_cells '>'
181 | '[' list_of_bytes ']'
183 subnode: label nodename nodedef
185 That structure forms a hierarchical layout of nodes and properties
186 rooted at an initial node as:
191 Both classic C style and C++ style comments are supported.
193 Source files may be directly included using the syntax:
200 Properties are named, possibly labeled, values. Each value
203 - A null-teminated C-like string,
204 - A numeric value fitting in 32 bits,
205 - A list of 32-bit values
208 Here are some example property definitions:
210 - A property containing a 0 terminated string
212 property1 = "string_value";
214 - A property containing a numerical 32-bit hexadecimal value
216 property2 = <1234abcd>;
218 - A property containing 3 numerical 32-bit hexadecimal values
220 property3 = <12345678 12345678 deadbeef>;
222 - A property whose content is an arbitrary array of bytes
224 property4 = [0a 0b 0c 0d de ea ad be ef];
227 Node may contain sub-nodes to obtain a hierarchical structure.
230 - A child node named "childnode" whose unit name is
231 "childnode at address". It in turn has a string property
235 childprop = "hello\n";
239 By default, all numeric values are hexadecimal. Alternate bases
240 may be specified using a prefix "d#" for decimal, "b#" for binary,
243 Strings support common escape sequences from C: "\n", "\t", "\r",
244 "\(octal value)", "\x(hex value)".
247 4.3) Labels and References
249 Labels may be applied to nodes or properties. Labels appear
250 before a node name, and are referenced using an ampersand: &label.
251 Absolute node path names are also allowed in node references.
253 In this exmaple, a node is labled "mpic" and then referenced:
255 mpic: interrupt-controller@40000 {
260 interrupt-parent = <&mpic>;
264 And used in properties, lables may appear before or after any value:
267 prop: string = data: "mystring\n" data_end: ;
273 II - The DT block format
274 ========================
276 This chapter defines the format of the flattened device-tree
277 passed to the kernel. The actual content of the device tree
278 are described in the kernel documentation in the file
280 linux-2.6/Documentation/powerpc/booting-without-of.txt
282 You can find example of code manipulating that format within
283 the kernel. For example, the file:
285 including arch/powerpc/kernel/prom_init.c
287 will generate a flattened device-tree from the Open Firmware
288 representation. Other utilities such as fs2dt, which is part of
289 the kexec tools, will generate one from a filesystem representation.
290 Some bootloaders such as U-Boot provide a bit more support by
291 using the libfdt code.
293 For booting the kernel, the device tree block has to be in main memory.
294 It has to be accessible in both real mode and virtual mode with no
295 mapping other than main memory. If you are writing a simple flash
296 bootloader, it should copy the block to RAM before passing it to
303 The kernel is entered with r3 pointing to an area of memory that is
304 roughly described in include/asm-powerpc/prom.h by the structure
307 struct boot_param_header {
308 u32 magic; /* magic word OF_DT_HEADER */
309 u32 totalsize; /* total size of DT block */
310 u32 off_dt_struct; /* offset to structure */
311 u32 off_dt_strings; /* offset to strings */
312 u32 off_mem_rsvmap; /* offset to memory reserve map */
313 u32 version; /* format version */
314 u32 last_comp_version; /* last compatible version */
316 /* version 2 fields below */
317 u32 boot_cpuid_phys; /* Which physical CPU id we're
319 /* version 3 fields below */
320 u32 size_dt_strings; /* size of the strings block */
322 /* version 17 fields below */
323 u32 size_dt_struct; /* size of the DT structure block */
326 Along with the constants:
328 /* Definitions used by the flattened device tree */
329 #define OF_DT_HEADER 0xd00dfeed /* 4: version,
331 #define OF_DT_BEGIN_NODE 0x1 /* Start node: full name
333 #define OF_DT_END_NODE 0x2 /* End node */
334 #define OF_DT_PROP 0x3 /* Property: name off,
336 #define OF_DT_END 0x9
338 All values in this header are in big endian format, the various
339 fields in this header are defined more precisely below. All "offset"
340 values are in bytes from the start of the header; that is from the
345 This is a magic value that "marks" the beginning of the
346 device-tree block header. It contains the value 0xd00dfeed and is
347 defined by the constant OF_DT_HEADER
351 This is the total size of the DT block including the header. The
352 "DT" block should enclose all data structures defined in this
353 chapter (who are pointed to by offsets in this header). That is,
354 the device-tree structure, strings, and the memory reserve map.
358 This is an offset from the beginning of the header to the start
359 of the "structure" part the device tree. (see 2) device tree)
363 This is an offset from the beginning of the header to the start
364 of the "strings" part of the device-tree
368 This is an offset from the beginning of the header to the start
369 of the reserved memory map. This map is a list of pairs of 64-
370 bit integers. Each pair is a physical address and a size. The
371 list is terminated by an entry of size 0. This map provides the
372 kernel with a list of physical memory areas that are "reserved"
373 and thus not to be used for memory allocations, especially during
374 early initialization. The kernel needs to allocate memory during
375 boot for things like un-flattening the device-tree, allocating an
376 MMU hash table, etc... Those allocations must be done in such a
377 way to avoid overriding critical things like, on Open Firmware
378 capable machines, the RTAS instance, or on some pSeries, the TCE
379 tables used for the iommu. Typically, the reserve map should
380 contain _at least_ this DT block itself (header,total_size). If
381 you are passing an initrd to the kernel, you should reserve it as
382 well. You do not need to reserve the kernel image itself. The map
383 should be 64-bit aligned.
387 This is the version of this structure. Version 1 stops
388 here. Version 2 adds an additional field boot_cpuid_phys.
389 Version 3 adds the size of the strings block, allowing the kernel
390 to reallocate it easily at boot and free up the unused flattened
391 structure after expansion. Version 16 introduces a new more
392 "compact" format for the tree itself that is however not backward
393 compatible. Version 17 adds an additional field, size_dt_struct,
394 allowing it to be reallocated or moved more easily (this is
395 particularly useful for bootloaders which need to make
396 adjustments to a device tree based on probed information). You
397 should always generate a structure of the highest version defined
398 at the time of your implementation. Currently that is version 17,
399 unless you explicitly aim at being backward compatible.
403 Last compatible version. This indicates down to what version of
404 the DT block you are backward compatible. For example, version 2
405 is backward compatible with version 1 (that is, a kernel build
406 for version 1 will be able to boot with a version 2 format). You
407 should put a 1 in this field if you generate a device tree of
408 version 1 to 3, or 16 if you generate a tree of version 16 or 17
409 using the new unit name format.
413 This field only exist on version 2 headers. It indicate which
414 physical CPU ID is calling the kernel entry point. This is used,
415 among others, by kexec. If you are on an SMP system, this value
416 should match the content of the "reg" property of the CPU node in
417 the device-tree corresponding to the CPU calling the kernel entry
418 point (see further chapters for more informations on the required
419 device-tree contents)
423 This field only exists on version 3 and later headers. It
424 gives the size of the "strings" section of the device tree (which
425 starts at the offset given by off_dt_strings).
429 This field only exists on version 17 and later headers. It gives
430 the size of the "structure" section of the device tree (which
431 starts at the offset given by off_dt_struct).
433 So the typical layout of a DT block (though the various parts don't
434 need to be in that order) looks like this (addresses go from top to
437 ------------------------------
438 r3 -> | struct boot_param_header |
439 ------------------------------
440 | (alignment gap) (*) |
441 ------------------------------
442 | memory reserve map |
443 ------------------------------
445 ------------------------------
447 | device-tree structure |
449 ------------------------------
451 ------------------------------
453 | device-tree strings |
455 -----> ------------------------------
460 (*) The alignment gaps are not necessarily present; their presence
461 and size are dependent on the various alignment requirements of
462 the individual data blocks.
465 2) Device tree generalities
466 ---------------------------
468 This device-tree itself is separated in two different blocks, a
469 structure block and a strings block. Both need to be aligned to a 4
472 First, let's quickly describe the device-tree concept before detailing
473 the storage format. This chapter does _not_ describe the detail of the
474 required types of nodes & properties for the kernel, this is done
475 later in chapter III.
477 The device-tree layout is strongly inherited from the definition of
478 the Open Firmware IEEE 1275 device-tree. It's basically a tree of
479 nodes, each node having two or more named properties. A property can
482 It is a tree, so each node has one and only one parent except for the
483 root node who has no parent.
485 A node has 2 names. The actual node name is generally contained in a
486 property of type "name" in the node property list whose value is a
487 zero terminated string and is mandatory for version 1 to 3 of the
488 format definition (as it is in Open Firmware). Version 16 makes it
489 optional as it can generate it from the unit name defined below.
491 There is also a "unit name" that is used to differentiate nodes with
492 the same name at the same level, it is usually made of the node
493 names, the "@" sign, and a "unit address", which definition is
494 specific to the bus type the node sits on.
496 The unit name doesn't exist as a property per-se but is included in
497 the device-tree structure. It is typically used to represent "path" in
498 the device-tree. More details about the actual format of these will be
501 The kernel powerpc generic code does not make any formal use of the
502 unit address (though some board support code may do) so the only real
503 requirement here for the unit address is to ensure uniqueness of
504 the node unit name at a given level of the tree. Nodes with no notion
505 of address and no possible sibling of the same name (like /memory or
506 /cpus) may omit the unit address in the context of this specification,
507 or use the "@0" default unit address. The unit name is used to define
508 a node "full path", which is the concatenation of all parent node
509 unit names separated with "/".
511 The root node doesn't have a defined name, and isn't required to have
512 a name property either if you are using version 3 or earlier of the
513 format. It also has no unit address (no @ symbol followed by a unit
514 address). The root node unit name is thus an empty string. The full
515 path to the root node is "/".
517 Every node which actually represents an actual device (that is, a node
518 which isn't only a virtual "container" for more nodes, like "/cpus"
519 is) is also required to have a "device_type" property indicating the
522 Finally, every node that can be referenced from a property in another
523 node is required to have a "linux,phandle" property. Real open
524 firmware implementations provide a unique "phandle" value for every
525 node that the "prom_init()" trampoline code turns into
526 "linux,phandle" properties. However, this is made optional if the
527 flattened device tree is used directly. An example of a node
528 referencing another node via "phandle" is when laying out the
529 interrupt tree which will be described in a further version of this
532 This "linux, phandle" property is a 32-bit value that uniquely
533 identifies a node. You are free to use whatever values or system of
534 values, internal pointers, or whatever to generate these, the only
535 requirement is that every node for which you provide that property has
536 a unique value for it.
538 Here is an example of a simple device-tree. In this example, an "o"
539 designates a node followed by the node unit name. Properties are
540 presented with their name followed by their content. "content"
541 represents an ASCII string (zero terminated) value, while <content>
542 represents a 32-bit hexadecimal value. The various nodes in this
543 example will be discussed in a later chapter. At this point, it is
544 only meant to give you a idea of what a device-tree looks like. I have
545 purposefully kept the "name" and "linux,phandle" properties which
546 aren't necessary in order to give you a better idea of what the tree
547 looks like in practice.
550 |- name = "device-tree"
551 |- model = "MyBoardName"
552 |- compatible = "MyBoardFamilyName"
553 |- #address-cells = <2>
555 |- linux,phandle = <0>
559 | | - linux,phandle = <1>
560 | | - #address-cells = <1>
561 | | - #size-cells = <0>
564 | |- name = "PowerPC,970"
565 | |- device_type = "cpu"
567 | |- clock-frequency = <5f5e1000>
569 | |- linux,phandle = <2>
573 | |- device_type = "memory"
574 | |- reg = <00000000 00000000 00000000 20000000>
575 | |- linux,phandle = <3>
579 |- bootargs = "root=/dev/sda2"
580 |- linux,phandle = <4>
582 This tree is almost a minimal tree. It pretty much contains the
583 minimal set of required nodes and properties to boot a linux kernel;
584 that is, some basic model informations at the root, the CPUs, and the
585 physical memory layout. It also includes misc information passed
586 through /chosen, like in this example, the platform type (mandatory)
587 and the kernel command line arguments (optional).
589 The /cpus/PowerPC,970@0/64-bit property is an example of a
590 property without a value. All other properties have a value. The
591 significance of the #address-cells and #size-cells properties will be
592 explained in chapter IV which defines precisely the required nodes and
593 properties and their content.
596 3) Device tree "structure" block
598 The structure of the device tree is a linearized tree structure. The
599 "OF_DT_BEGIN_NODE" token starts a new node, and the "OF_DT_END_NODE"
600 ends that node definition. Child nodes are simply defined before
601 "OF_DT_END_NODE" (that is nodes within the node). A 'token' is a 32
602 bit value. The tree has to be "finished" with a OF_DT_END token
604 Here's the basic structure of a single node:
606 * token OF_DT_BEGIN_NODE (that is 0x00000001)
607 * for version 1 to 3, this is the node full path as a zero
608 terminated string, starting with "/". For version 16 and later,
609 this is the node unit name only (or an empty string for the
611 * [align gap to next 4 bytes boundary]
613 * token OF_DT_PROP (that is 0x00000003)
614 * 32-bit value of property value size in bytes (or 0 if no
616 * 32-bit value of offset in string block of property name
617 * property value data if any
618 * [align gap to next 4 bytes boundary]
619 * [child nodes if any]
620 * token OF_DT_END_NODE (that is 0x00000002)
622 So the node content can be summarized as a start token, a full path,
623 a list of properties, a list of child nodes, and an end token. Every
624 child node is a full node structure itself as defined above.
626 NOTE: The above definition requires that all property definitions for
627 a particular node MUST precede any subnode definitions for that node.
628 Although the structure would not be ambiguous if properties and
629 subnodes were intermingled, the kernel parser requires that the
630 properties come first (up until at least 2.6.22). Any tools
631 manipulating a flattened tree must take care to preserve this
634 4) Device tree "strings" block
636 In order to save space, property names, which are generally redundant,
637 are stored separately in the "strings" block. This block is simply the
638 whole bunch of zero terminated strings for all property names
639 concatenated together. The device-tree property definitions in the
640 structure block will contain offset values from the beginning of the
647 This library should be merged into dtc proper.
648 This library should likely be worked into U-Boot and the kernel.
654 1) convert-dtsv0 -- Conversion to Version 1
656 convert-dtsv0 is a small utility program which converts (DTS)
657 Device Tree Source from the obsolete version 0 to version 1.
659 Version 1 DTS files are marked by line "/dts-v1/;" at the top of the file.
661 The syntax of the convert-dtsv0 command line is:
663 convert-dtsv0 [<input_filename ... >]
665 Each file passed will be converted to the new /dts-v1/ version by creating
666 a new file with a "v1" appended the filename.
668 Comments, empty lines, etc. are preserved.
671 2) fdtdump -- Flat Device Tree dumping utility
673 The fdtdump program prints a readable version of a flat device tree file.
675 The syntax of the fdtdump command line is:
677 fdtdump <DTB-file-name>