Lines Matching refs:of
11 Table of Contents
26 III - Required content of the device tree
44 1) Defining child nodes of an SOC
66 clarifies the fact that a lot of things are
92 "simple" insertion of properties using
97 compiler and the textural representation of
108 - Add some definitions of interrupt tree (simple/complex)
114 - Compare FSL SOC use of PCI to standard and make sure no new
123 During the development of the Linux/ppc64 kernel, and more
124 specifically, the addition of new platform types outside of the old
131 doesn't follow them properly. In addition, since the advent of the
137 the presence of a device-tree whose format is defined after Open
149 drivers to device, without having to hard code all sorts of tables. It
159 of the kernel image. That entry point supports two calling
160 conventions. A summary of the interface is described here. A full
161 description of the boot requirements is documented in
165 to the kernel with a tagged list of predefined parameters.
171 r2 : Physical address of tagged list in system RAM
174 physical address of the flattened device tree block (dtb) into r2,
182 represent a class or family of SoCs.
198 of the kernel image. That entry point supports two calling
203 client interface API (support for "interpret" callback of
210 r3, r4 : address & length of an initrd if any or 0
218 context of the firmware, which is supposed to handle all
225 implement "hot" booting of a new kernel from a previous
247 described in a later revision of this document.
250 arbitrary set of board supports can be built in a single kernel
251 image. The kernel will "know" what set of functions to use for a
252 given platform based on the content of the device-tree. Thus, you
256 arch/powerpc/Kconfig, following the example of PPC_PSERIES,
258 example of a board support to start from.
262 to the Makefile under the condition of your CONFIG_
263 option. This file will define a structure of type "ppc_md"
290 otherwise like interrupt routing or a list of devices behind an I2C bus.
295 Some bootloaders only support a single entry point, at the start of the
309 512MB of the physical address space (0x00000000 - 0x1fffffff),
323 This chapter defines the actual format of the flattened device-tree
324 passed to the kernel. The actual content of it and kernel requirements
325 are described later. You can find example of code manipulating that
328 representation, or the fs2dt utility which is part of the kexec tools
342 The kernel is passed the physical address pointing to an area of memory
348 u32 totalsize; /* total size of DT block */
360 u32 size_dt_strings; /* size of the strings block */
363 u32 size_dt_struct; /* size of the DT structure block */
380 "offset" values are in bytes from the start of the header; that is
381 from the physical base address of the device tree block.
385 This is a magic value that "marks" the beginning of the
391 This is the total size of the DT block including the header. The
398 This is an offset from the beginning of the header to the start
399 of the "structure" part the device tree. (see 2) device tree)
403 This is an offset from the beginning of the header to the start
404 of the "strings" part of the device-tree
408 This is an offset from the beginning of the header to the start
409 of the reserved memory map. This map is a list of pairs of 64-
411 list is terminated by an entry of size 0. This map provides the
412 kernel with a list of physical memory areas that are "reserved"
427 This is the version of this structure. Version 1 stops
429 Version 3 adds the size of the strings block, allowing the kernel
437 should always generate a structure of the highest version defined
438 at the time of your implementation. Currently that is version 17,
443 Last compatible version. This indicates down to what version of
447 should put a 1 in this field if you generate a device tree of
448 version 1 to 3, or 16 if you generate a tree of version 16 or 17
456 should match the content of the "reg" property of the CPU node in
464 gives the size of the "strings" section of the device tree (which
470 the size of the "structure" section of the device tree (which
473 So the typical layout of a DT block (though the various parts don't
502 and size are dependent on the various alignment requirements of
514 the storage format. This chapter does _not_ describe the detail of the
515 required types of nodes & properties for the kernel, this is done
518 The device-tree layout is strongly inherited from the definition of
519 the Open Firmware IEEE 1275 device-tree. It's basically a tree of
527 property of type "name" in the node property list whose value is a
528 zero terminated string and is mandatory for version 1 to 3 of the
533 the same name at the same level, it is usually made of the node
539 the device-tree. More details about the actual format of these will be
542 The kernel generic code does not make any formal use of the
544 requirement here for the unit address is to ensure uniqueness of
545 the node unit name at a given level of the tree. Nodes with no notion
546 of address and no possible sibling of the same name (like /memory or
547 /cpus) may omit the unit address in the context of this specification,
549 a node "full path", which is the concatenation of all parent node
553 a name property either if you are using version 3 or earlier of the
561 specific hardware and an optional list of devices it is fully
569 if the flattened device tree is used directly. An example of a node
571 interrupt tree which will be described in a further version of this
575 identifies a node. You are free to use whatever values or system of
580 Here is an example of a simple device-tree. In this example, an "o"
587 you a idea of what a device-tree looks like. I have purposefully kept
589 order to give you a better idea of what the tree looks like in
626 minimal set of required nodes and properties to boot a linux kernel;
632 The /cpus/PowerPC,970@0/64-bit property is an example of a
634 significance of the #address-cells and #size-cells properties will be
641 The structure of the device tree is a linearized tree structure. The
647 Here's the basic structure of a single node:
657 * 32-bit value of property value size in bytes (or 0 if no
659 * 32-bit value of offset in string block of property name
666 a list of properties, a list of child nodes, and an end token. Every
681 whole bunch of zero terminated strings for all property names
683 structure block will contain offset values from the beginning of the
687 III - Required content of the device tree
692 implementation of Open Firmware or an implementation compatible with
710 In general, the format of an address for a device is defined by the
712 properties. Note that the parent's parent definitions of #address-cells
720 composed of 2 cells, and each is a 64-bit number (cells are
728 "reg" properties are always a tuple of the type "address size" where
729 the number of cells of address and size is specified by the bus
733 bits of the physical address. For example, a PCI physical address is
734 made of 3 cells, the bottom two containing the actual address itself
747 kernel address parsing functions will work out of the box. If you
750 prom_parse.c file of the recent kernels for your bus type.
758 parent bus. The format of the "ranges" property for a bus is a list
759 of:
763 "bus address" is in the format of the bus this bus node is defining,
765 address, size) defines a range of addresses for child devices. "parent
766 bus address" is in the format of the parent bus of this bus. For
769 address in the parent bus where the beginning of that range is mapped.
786 node. The format of a "compatible" property is a list of concatenated
788 compatibility with a family of similar devices, in some cases,
790 of their actual names.
795 While earlier users of Open Firmware like OldWorld macintoshes tended
802 of these chips. However, the kernel doesn't generally put any
809 used to reconstruct the name. That is, the part of the unit name
816 While Open Firmware provides more flexible usage of 8859-1, this
818 be comprised only of ASCII characters 'a' to 'z', '0' to
826 The maximum number of characters for both nodes and property names
827 is 31. In the case of node names, this is only the leftmost part of
854 specific to your board like the serial number if any, that sort of
865 This node is the parent of all individual CPU nodes. It doesn't
874 that format when reading the "reg" properties of a CPU node, see
880 the machine. There is no specific restriction on the name of the
900 - d-cache-size : one cell, size of L1 data cache in bytes
901 - i-cache-size : one cell, size of L1 instruction cache in bytes
911 - timebase-frequency : a cell indicating the frequency of the
936 To define the physical memory layout of your board, you should
940 full path is the address of the first range of memory defined by a
947 - reg : This property contains all the physical memory ranges of
948 your board. It's a list of addresses/sizes concatenated
949 together, with the number of cells of each defined by the
950 #address-cells and #size-cells of the root node. For example,
951 with both of these properties being 2 like in the example given
952 earlier, a 970 based machine with 6Gb of RAM could typically
958 That is a range starting at 0 of 0x80000000 bytes and a range
959 starting at 0x100000000 and of 0x100000000 bytes. You can see
970 This specification makes a few of these mandatory, but also defines
998 of the memory-mapped register set for the SoC. The name of an SoC
999 node should start with "soc", and the remainder of the name should
1006 translation of SoC addresses for memory mapped SoC registers.
1008 Typically, the value of this field is filled in by the boot
1010 - compatible : Exact model of the SoC
1015 - reg : This property defines the address and size of the
1019 "reg" property should match the unit address of the SOC node.
1021 format of this field may vary depending on whether or not the
1023 registers, this field represents the number of cells needed to
1024 represent the address of the registers. For SOCs that do not
1029 - #interrupt-cells : Defines the width of cells used to represent
1039 for more information on how to specify devices that are part of a SOC.
1082 output of /proc/device-tree, that is nodes are directories and
1096 The syntax of the dtc tool is
1102 The "output_version" defines what version of the "blob" format will be
1107 uniqueness of linux, phandle properties, validity of strings, etc...
1109 The format of the .dts "source" file is "C" like, supports C and C++
1134 * an arbitrary array of bytes
1142 childprop = "hello\n"; /* define a property "childprop" of
1149 structure of the tree.
1158 automatic generation of phandles, labels (exported to the asm file so
1160 you link the device-tree with), label or path instead of numeric value
1162 time), export of reserve map address to the asm file, ability to
1165 We may provide a .h include file with common definitions of that
1167 interrupt maps) though it may be better to add a notion of struct
1192 - An example of code for iterating nodes & retrieving properties
1194 file drivers/of/fdt.c. Look at the of_scan_flat_dt() function,
1197 GPL bootloader, and as the author of that code, I would be happy
1199 integrate all or part of this code into a non-GPL bootloader.
1209 exist on a single piece of silicon. For these SOCs, an SOC node
1215 genericization of much of the kernel code.
1218 1) Defining child nodes of an SOC
1221 Each device that is part of an SOC may have its own node entry inside
1228 to the parent SOC address space and the size of the device's
1232 specifications for the format of the device tree node. All SOC child
1244 representation defined as part of the Open Firmware specifications,
1255 The device tree represents the buses and devices of a hardware
1256 system in a form similar to the physical bus topology of the
1260 hierarchy and routing of interrupts in the hardware.
1275 property. The interrupt property value is an arbitrary number of
1276 of 'interrupt specifier' values which describe the interrupt or
1279 The encoding of an interrupt specifier is determined by the
1281 interrupt tree. The root of an interrupt domain specifies in
1282 its #interrupt-cells property the number of 32-bit cells
1284 mapping documentation for a detailed description of domains.
1287 specifies an #interrupt-cells value of 2 to encode the interrupt
1292 The PCI bus binding specifies a #interrupt-cell value of 1 to encode
1300 the interrupt tree. The value of interrupt-parent is the
1301 phandle of the parent node.
1347 The sleep property consists of one or more sleep resources, each of
1348 which consists of a phandle to a sleep controller, followed by a
1349 controller-specific sleep specifier of zero or more cells.
1351 The semantics of what type of low power modes are possible are defined
1352 by the sleep controller. Some examples of the types of low power modes
1362 only be suspended when none of the devices are in use. Where reasonable,
1371 Some devices may have DMA memory range shifted relatively to the beginning of
1372 RAM, or even placed outside of kernel RAM. For example, the Keystone 2 SoC
1376 and DMA range is aliased into first 2G of RAM in HW.
1380 for describing the configuration of such system in DT.
1388 - dma-ranges: <prop-encoded-array> encoded as arbitrary number of triplets of
1392 structure of a memory-mapped bus whose device tree parent can be accessed
1393 from DMA operations originating from the bus. It provides a means of
1394 defining a mapping or translation between the physical address space of
1395 the bus and the physical address space of the parent of the bus.