kernel
/
dtc
mirror of https://git.kernel.org/pub/scm/utils/dtc/dtc.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1031 Commits
2 Branches
23 Tags
1.7 MiB
 
 
 
 
 
 
Tree: 45f3d1a095
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '45f3d1a095'
${ noResults }
dtc/Documentation/manual.txt

762 lines
26 KiB
Raw Blame History

Device Tree Compiler Manual
===========================
I - "dtc", the device tree compiler
1) Obtaining Sources
1.1) Submitting Patches
2) Description
3) Command Line
4) Source File
4.1) Overview
4.2) Properties
4.3) Labels and References
II - The DT block format
1) Header
2) Device tree generalities
3) Device tree "structure" block
4) Device tree "strings" block
III - libfdt
IV - Utility Tools
1) convert-dtsv0 -- Conversion to Version 1
1) fdtdump
I - "dtc", the device tree compiler
===================================
1) Sources
Source code for the Device Tree Compiler can be found at git.kernel.org.
The upstream repository is here:
git://git.kernel.org/pub/scm/utils/dtc/dtc.git
https://git.kernel.org/pub/scm/utils/dtc/dtc.git
The gitweb interface for the upstream repository is:
https://git.kernel.org/cgit/utils/dtc/dtc.git/
1.1) Submitting Patches
Patches should be sent to the maintainers:
David Gibson <david@gibson.dropbear.id.au>
Jon Loeliger <loeliger@gmail.com>
and CCed to <devicetree-compiler@vger.kernel.org>.
2) Description
The Device Tree Compiler, dtc, takes as input a device-tree in
a given format and outputs a device-tree in another format.
Typically, the input format is "dts", a human readable source
format, and creates a "dtb", or binary format as output.
The currently supported Input Formats are:
- "dtb": "blob" format. A flattened device-tree block with
header in one binary blob.
- "dts": "source" format. A text file containing a "source"
for a device-tree.
- "fs" format. A representation equivalent to the output of
/proc/device-tree where nodes are directories and
properties are files.
The currently supported Output Formats are:
- "dtb": "blob" format
- "dts": "source" format
- "asm": assembly language file. A file that can be sourced
by gas to generate a device-tree "blob". That file can
then simply be added to your Makefile. Additionally, the
assembly file exports some symbols that can be used.
- "yaml": DT encoded in YAML format. This representation is an
intermediate format used for validation tools.
3) Command Line
The syntax of the dtc command line is:
dtc [options] [<input_filename>]
Options:
<input_filename>
The name of the input source file. If no <input_filename>
or "-" is given, stdin is used.
-b <number>
Set the physical boot cpu.
-f
Force. Try to produce output even if the input tree has errors.
-h
Emit a brief usage and help message.
-I <input_format>
The source input format, as listed above.
-o <output_filename>
The name of the generated output file. Use "-" for stdout.
-O <output_format>
The generated output format, as listed above.
-d <dependency_filename>
Generate a dependency file during compilation.
-q
Quiet: -q suppress warnings, -qq errors, -qqq all
-R <number>
Make space for <number> reserve map entries
Relevant for dtb and asm output only.
-@
Generates a __symbols__ node at the root node of the resulting blob
for any node labels used, and for any local references using phandles
it also generates a __local_fixups__ node that tracks them.
When using the /plugin/ tag all unresolved label references to
be tracked in the __fixups__ node, making dynamic resolution possible.
-A
Generate automatically aliases for all node labels. This is similar to
the -@ option (the __symbols__ node contain identical information) but
the semantics are slightly different since no phandles are automatically
generated for labeled nodes.
-S <bytes>
Ensure the blob at least <bytes> long, adding additional
space if needed.
-v
Print DTC version and exit.
-V <output_version>
Generate output conforming to the given <output_version>.
By default the most recent version is generated.
Relevant for dtb and asm output only.
The <output_version> defines what version of the "blob" format will be
generated. Supported versions are 1, 2, 3, 16 and 17. The default is
always the most recent version and is likely the highest number.
Additionally, dtc performs various sanity checks on the tree.
4) Device Tree Source file
4.1) Overview
Here is a very rough overview of the layout of a DTS source file:
sourcefile: versioninfo plugindecl list_of_memreserve devicetree
memreserve: label 'memreserve' ADDR ADDR ';'
| label 'memreserve' ADDR '-' ADDR ';'
devicetree: '/' nodedef
versioninfo: '/' 'dts-v1' '/' ';'
plugindecl: '/' 'plugin' '/' ';'
| /* empty */
nodedef: '{' list_of_property list_of_subnode '}' ';'
property: label PROPNAME '=' propdata ';'
propdata: STRING
| '<' list_of_cells '>'
| '[' list_of_bytes ']'
subnode: label nodename nodedef
That structure forms a hierarchical layout of nodes and properties
rooted at an initial node as:
/ {
}
Both classic C style and C++ style comments are supported.
Source files may be directly included using the syntax:
/include/ "filename"
4.2) Properties
Properties are named, possibly labeled, values. Each value
is one of:
- A null-teminated C-like string,
- A numeric value fitting in 32 bits,
- A list of 32-bit values
- A byte sequence
Here are some example property definitions:
- A property containing a 0 terminated string
property1 = "string_value";
- A property containing a numerical 32-bit hexadecimal value
property2 = <1234abcd>;
- A property containing 3 numerical 32-bit hexadecimal values
property3 = <12345678 12345678 deadbeef>;
- A property whose content is an arbitrary array of bytes
property4 = [0a 0b 0c 0d de ea ad be ef];
Node may contain sub-nodes to obtain a hierarchical structure.
For example:
- A child node named "childnode" whose unit name is
"childnode at address". It in turn has a string property
called "childprop".
childnode@address {
childprop = "hello\n";
};
By default, all numeric values are hexadecimal. Alternate bases
may be specified using a prefix "d#" for decimal, "b#" for binary,
and "o#" for octal.
Strings support common escape sequences from C: "\n", "\t", "\r",
"\(octal value)", "\x(hex value)".
4.3) Labels and References
Labels may be applied to nodes or properties. Labels appear
before a node name, and are referenced using an ampersand: &label.
Absolute node path names are also allowed in node references.
In this example, a node is labeled "mpic" and then referenced:
mpic: interrupt-controller@40000 {
...
};
ethernet-phy@3 {
interrupt-parent = <&mpic>;
...
};
And used in properties, labels may appear before or after any value:
randomnode {
prop: string = data: "mystring\n" data_end: ;
...
};
II - The DT block format
========================
This chapter defines the format of the flattened device-tree
passed to the kernel. The actual content of the device tree
are described in the kernel documentation in the file
linux-2.6/Documentation/powerpc/booting-without-of.txt
You can find example of code manipulating that format within
the kernel. For example, the file:
including arch/powerpc/kernel/prom_init.c
will generate a flattened device-tree from the Open Firmware
representation. Other utilities such as fs2dt, which is part of
the kexec tools, will generate one from a filesystem representation.
Some bootloaders such as U-Boot provide a bit more support by
using the libfdt code.
For booting the kernel, the device tree block has to be in main memory.
It has to be accessible in both real mode and virtual mode with no
mapping other than main memory. If you are writing a simple flash
bootloader, it should copy the block to RAM before passing it to
the kernel.
1) Header
---------
The kernel is entered with r3 pointing to an area of memory that is
roughly described in include/asm-powerpc/prom.h by the structure
boot_param_header:
struct boot_param_header {
u32 magic; /* magic word OF_DT_HEADER */
u32 totalsize; /* total size of DT block */
u32 off_dt_struct; /* offset to structure */
u32 off_dt_strings; /* offset to strings */
u32 off_mem_rsvmap; /* offset to memory reserve map */
u32 version; /* format version */
u32 last_comp_version; /* last compatible version */
/* version 2 fields below */
u32 boot_cpuid_phys; /* Which physical CPU id we're
booting on */
/* version 3 fields below */
u32 size_dt_strings; /* size of the strings block */
/* version 17 fields below */
u32 size_dt_struct; /* size of the DT structure block */
};
Along with the constants:
/* Definitions used by the flattened device tree */
#define OF_DT_HEADER 0xd00dfeed /* 4: version,
4: total size */
#define OF_DT_BEGIN_NODE 0x1 /* Start node: full name
*/
#define OF_DT_END_NODE 0x2 /* End node */
#define OF_DT_PROP 0x3 /* Property: name off,
size, content */
#define OF_DT_END 0x9
All values in this header are in big endian format, the various
fields in this header are defined more precisely below. All "offset"
values are in bytes from the start of the header; that is from the
value of r3.
- magic
This is a magic value that "marks" the beginning of the
device-tree block header. It contains the value 0xd00dfeed and is
defined by the constant OF_DT_HEADER
- totalsize
This is the total size of the DT block including the header. The
"DT" block should enclose all data structures defined in this
chapter (who are pointed to by offsets in this header). That is,
the device-tree structure, strings, and the memory reserve map.
- off_dt_struct
This is an offset from the beginning of the header to the start
of the "structure" part the device tree. (see 2) device tree)
- off_dt_strings
This is an offset from the beginning of the header to the start
of the "strings" part of the device-tree
- off_mem_rsvmap
This is an offset from the beginning of the header to the start
of the reserved memory map. This map is a list of pairs of 64-
bit integers. Each pair is a physical address and a size. The
list is terminated by an entry of size 0. This map provides the
kernel with a list of physical memory areas that are "reserved"
and thus not to be used for memory allocations, especially during
early initialization. The kernel needs to allocate memory during
boot for things like un-flattening the device-tree, allocating an
MMU hash table, etc... Those allocations must be done in such a
way to avoid overriding critical things like, on Open Firmware
capable machines, the RTAS instance, or on some pSeries, the TCE
tables used for the iommu. Typically, the reserve map should
contain _at least_ this DT block itself (header,total_size). If
you are passing an initrd to the kernel, you should reserve it as
well. You do not need to reserve the kernel image itself. The map
should be 64-bit aligned.
- version
This is the version of this structure. Version 1 stops
here. Version 2 adds an additional field boot_cpuid_phys.
Version 3 adds the size of the strings block, allowing the kernel
to reallocate it easily at boot and free up the unused flattened
structure after expansion. Version 16 introduces a new more
"compact" format for the tree itself that is however not backward
compatible. Version 17 adds an additional field, size_dt_struct,
allowing it to be reallocated or moved more easily (this is
particularly useful for bootloaders which need to make
adjustments to a device tree based on probed information). You
should always generate a structure of the highest version defined
at the time of your implementation. Currently that is version 17,
unless you explicitly aim at being backward compatible.
- last_comp_version
Last compatible version. This indicates down to what version of
the DT block you are backward compatible. For example, version 2
is backward compatible with version 1 (that is, a kernel build
for version 1 will be able to boot with a version 2 format). You
should put a 1 in this field if you generate a device tree of
version 1 to 3, or 16 if you generate a tree of version 16 or 17
using the new unit name format.
- boot_cpuid_phys
This field only exist on version 2 headers. It indicate which
physical CPU ID is calling the kernel entry point. This is used,
among others, by kexec. If you are on an SMP system, this value
should match the content of the "reg" property of the CPU node in
the device-tree corresponding to the CPU calling the kernel entry
point (see further chapters for more information on the required
device-tree contents)
- size_dt_strings
This field only exists on version 3 and later headers. It
gives the size of the "strings" section of the device tree (which
starts at the offset given by off_dt_strings).
- size_dt_struct
This field only exists on version 17 and later headers. It gives
the size of the "structure" section of the device tree (which
starts at the offset given by off_dt_struct).
So the typical layout of a DT block (though the various parts don't
need to be in that order) looks like this (addresses go from top to
bottom):
------------------------------
r3 -> | struct boot_param_header |
------------------------------
| (alignment gap) (*) |
------------------------------
| memory reserve map |
------------------------------
| (alignment gap) |
------------------------------
| |
| device-tree structure |
| |
------------------------------
| (alignment gap) |
------------------------------
| |
| device-tree strings |
| |
-----> ------------------------------
|
|
--- (r3 + totalsize)
(*) The alignment gaps are not necessarily present; their presence
and size are dependent on the various alignment requirements of
the individual data blocks.
2) Device tree generalities
---------------------------
This device-tree itself is separated in two different blocks, a
structure block and a strings block. Both need to be aligned to a 4
byte boundary.
First, let's quickly describe the device-tree concept before detailing
the storage format. This chapter does _not_ describe the detail of the
required types of nodes & properties for the kernel, this is done
later in chapter III.
The device-tree layout is strongly inherited from the definition of
the Open Firmware IEEE 1275 device-tree. It's basically a tree of
nodes, each node having two or more named properties. A property can
have a value or not.
It is a tree, so each node has one and only one parent except for the
root node who has no parent.
A node has 2 names. The actual node name is generally contained in a
property of type "name" in the node property list whose value is a
zero terminated string and is mandatory for version 1 to 3 of the
format definition (as it is in Open Firmware). Version 16 makes it
optional as it can generate it from the unit name defined below.
There is also a "unit name" that is used to differentiate nodes with
the same name at the same level, it is usually made of the node
names, the "@" sign, and a "unit address", which definition is
specific to the bus type the node sits on.
The unit name doesn't exist as a property per-se but is included in
the device-tree structure. It is typically used to represent "path" in
the device-tree. More details about the actual format of these will be
below.
The kernel powerpc generic code does not make any formal use of the
unit address (though some board support code may do) so the only real
requirement here for the unit address is to ensure uniqueness of
the node unit name at a given level of the tree. Nodes with no notion
of address and no possible sibling of the same name (like /memory or
/cpus) may omit the unit address in the context of this specification,
or use the "@0" default unit address. The unit name is used to define
a node "full path", which is the concatenation of all parent node
unit names separated with "/".
The root node doesn't have a defined name, and isn't required to have
a name property either if you are using version 3 or earlier of the
format. It also has no unit address (no @ symbol followed by a unit
address). The root node unit name is thus an empty string. The full
path to the root node is "/".
Every node which actually represents an actual device (that is, a node
which isn't only a virtual "container" for more nodes, like "/cpus"
is) is also required to have a "device_type" property indicating the
type of node .
Finally, every node that can be referenced from a property in another
node is required to have a "linux,phandle" property. Real open
firmware implementations provide a unique "phandle" value for every
node that the "prom_init()" trampoline code turns into
"linux,phandle" properties. However, this is made optional if the
flattened device tree is used directly. An example of a node
referencing another node via "phandle" is when laying out the
interrupt tree which will be described in a further version of this
document.
This "linux, phandle" property is a 32-bit value that uniquely
identifies a node. You are free to use whatever values or system of
values, internal pointers, or whatever to generate these, the only
requirement is that every node for which you provide that property has
a unique value for it.
Here is an example of a simple device-tree. In this example, an "o"
designates a node followed by the node unit name. Properties are
presented with their name followed by their content. "content"
represents an ASCII string (zero terminated) value, while <content>
represents a 32-bit hexadecimal value. The various nodes in this
example will be discussed in a later chapter. At this point, it is
only meant to give you a idea of what a device-tree looks like. I have
purposefully kept the "name" and "linux,phandle" properties which
aren't necessary in order to give you a better idea of what the tree
looks like in practice.
/ o device-tree
|- name = "device-tree"
|- model = "MyBoardName"
|- compatible = "MyBoardFamilyName"
|- #address-cells = <2>
|- #size-cells = <2>
|- linux,phandle = <0>
|
o cpus
| | - name = "cpus"
| | - linux,phandle = <1>
| | - #address-cells = <1>
| | - #size-cells = <0>
| |
| o PowerPC,970@0
| |- name = "PowerPC,970"
| |- device_type = "cpu"
| |- reg = <0>
| |- clock-frequency = <5f5e1000>
| |- 64-bit
| |- linux,phandle = <2>
|
o memory@0
| |- name = "memory"
| |- device_type = "memory"
| |- reg = <00000000 00000000 00000000 20000000>
| |- linux,phandle = <3>
|
o chosen
|- name = "chosen"
|- bootargs = "root=/dev/sda2"
|- linux,phandle = <4>
This tree is almost a minimal tree. It pretty much contains the
minimal set of required nodes and properties to boot a linux kernel;
that is, some basic model information at the root, the CPUs, and the
physical memory layout. It also includes misc information passed
through /chosen, like in this example, the platform type (mandatory)
and the kernel command line arguments (optional).
The /cpus/PowerPC,970@0/64-bit property is an example of a
property without a value. All other properties have a value. The
significance of the #address-cells and #size-cells properties will be
explained in chapter IV which defines precisely the required nodes and
properties and their content.
3) Device tree "structure" block
The structure of the device tree is a linearized tree structure. The
"OF_DT_BEGIN_NODE" token starts a new node, and the "OF_DT_END_NODE"
ends that node definition. Child nodes are simply defined before
"OF_DT_END_NODE" (that is nodes within the node). A 'token' is a 32
bit value. The tree has to be "finished" with a OF_DT_END token
Here's the basic structure of a single node:
* token OF_DT_BEGIN_NODE (that is 0x00000001)
* for version 1 to 3, this is the node full path as a zero
terminated string, starting with "/". For version 16 and later,
this is the node unit name only (or an empty string for the
root node)
* [align gap to next 4 bytes boundary]
* for each property:
* token OF_DT_PROP (that is 0x00000003)
* 32-bit value of property value size in bytes (or 0 if no
value)
* 32-bit value of offset in string block of property name
* property value data if any
* [align gap to next 4 bytes boundary]
* [child nodes if any]
* token OF_DT_END_NODE (that is 0x00000002)
So the node content can be summarized as a start token, a full path,
a list of properties, a list of child nodes, and an end token. Every
child node is a full node structure itself as defined above.
NOTE: The above definition requires that all property definitions for
a particular node MUST precede any subnode definitions for that node.
Although the structure would not be ambiguous if properties and
subnodes were intermingled, the kernel parser requires that the
properties come first (up until at least 2.6.22). Any tools
manipulating a flattened tree must take care to preserve this
constraint.
4) Device tree "strings" block
In order to save space, property names, which are generally redundant,
are stored separately in the "strings" block. This block is simply the
whole bunch of zero terminated strings for all property names
concatenated together. The device-tree property definitions in the
structure block will contain offset values from the beginning of the
strings block.
III - libfdt
============
This library should be merged into dtc proper.
This library should likely be worked into U-Boot and the kernel.
IV - Utility Tools
==================
1) convert-dtsv0 -- Conversion to Version 1
convert-dtsv0 is a small utility program which converts (DTS)
Device Tree Source from the obsolete version 0 to version 1.
Version 1 DTS files are marked by line "/dts-v1/;" at the top of the file.
The syntax of the convert-dtsv0 command line is:
convert-dtsv0 [<input_filename ... >]
Each file passed will be converted to the new /dts-v1/ version by creating
a new file with a "v1" appended the filename.
Comments, empty lines, etc. are preserved.
2) fdtdump -- Flat Device Tree dumping utility
The fdtdump program prints a readable version of a flat device tree file.
The syntax of the fdtdump command line is:
fdtdump [options] <DTB-file-name>
Where options are:
-d,--debug Dump debug information while decoding the file
-s,--scan Scan for an embedded fdt in given file
3) fdtoverlay -- Flat Device Tree overlay applicator
The fdtoverlay applies an arbitrary number of FDT overlays to a base FDT blob
to a given output file.
The syntax of the fdtoverlay command line is:
fdtoverlay -i <base-blob> -o <output-blob> <overlay-blob0> [<overlay-blob1> ...]
Where options are:
-i, --input Input base DT blob
-o, --output Output DT blob
-v, --verbose Verbose message output
4 ) fdtget -- Read properties from device tree
This command can be used to obtain individual values from the device tree in a
nicely formatted way. You can specify multiple nodes to display (when using -p)
or multiple node/property pairs (when not using -p). For the latter, each
property is displayed on its own line, with a space between each cell within
the property.
The syntax of the fdtget command is:
fdtget <options> <dt file> [<node> <property>]...
fdtget -p <options> <dt file> [<node> ]...
where options are:
<type> s=string, i=int, u=unsigned, x=hex
Optional modifier prefix:
hh or b=byte, h=2 byte, l=4 byte (default)
Options: -[t:pld:hV]
-t, --type <arg> Type of data
-p, --properties List properties for each node
-l, --list List subnodes for each node
-d, --default <arg> Default value to display when the property is missing
-h, --help Print this help and exit
-V, --version Print version and exit
If -t is not provided, fdtget will try to figure out the type, trying to detect
strings, string lists and the size of each value in the property. This is
similar to how fdtdump works, and uses the same heuristics.
5 ) fdtput - Write properties to a device tree
The syntax of the fdtput command is:
fdtput <options> <dt file> <node> <property> [<value>...]
fdtput -c <options> <dt file> [<node>...]
fdtput -r <options> <dt file> [<node>...]
fdtput -d <options> <dt file> <node> [<property>...]
Options are:
<type> s=string, i=int, u=unsigned, x=hex
Optional modifier prefix:
hh or b=byte, h=2 byte, l=4 byte (default)
-c, --create Create nodes if they don't already exist
-r, --remove Delete nodes (and any subnodes) if they already exist
-d, --delete Delete properties if they already exist
-p, --auto-path Automatically create nodes as needed for the node path
-t, --type <arg> Type of data
-v, --verbose Display each value decoded from command line
-h, --help Print this help and exit
-V, --version Print version and exit
The option determines which usage is selected and therefore the operation that
is performed. The first usage adds or updates properties; the rest are used to
create/delete nodes and delete properties.
For the first usage, the command line arguments are joined together into a
single value which is written to the property. The -t option is required so
that fdtput knows how to decode its arguments.