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
861 This node is the parent of all individual CPU nodes. It doesn't
870 that format when reading the "reg" properties of a CPU node, see
876 the machine. There is no specific restriction on the name of the
896 - d-cache-size : one cell, size of L1 data cache in bytes
897 - i-cache-size : one cell, size of L1 instruction cache in bytes
907 - timebase-frequency : a cell indicating the frequency of the
932 To define the physical memory layout of your board, you should
936 full path is the address of the first range of memory defined by a
943 - reg : This property contains all the physical memory ranges of
944 your board. It's a list of addresses/sizes concatenated
945 together, with the number of cells of each defined by the
946 #address-cells and #size-cells of the root node. For example,
947 with both of these properties being 2 like in the example given
948 earlier, a 970 based machine with 6Gb of RAM could typically
954 That is a range starting at 0 of 0x80000000 bytes and a range
955 starting at 0x100000000 and of 0x100000000 bytes. You can see
966 This specification makes a few of these mandatory, but also defines
994 of the memory-mapped register set for the SoC. The name of an SoC
995 node should start with "soc", and the remainder of the name should
1002 translation of SoC addresses for memory mapped SoC registers.
1004 Typically, the value of this field is filled in by the boot
1006 - compatible : Exact model of the SoC
1011 - reg : This property defines the address and size of the
1015 "reg" property should match the unit address of the SOC node.
1017 format of this field may vary depending on whether or not the
1019 registers, this field represents the number of cells needed to
1020 represent the address of the registers. For SOCs that do not
1025 - #interrupt-cells : Defines the width of cells used to represent
1035 for more information on how to specify devices that are part of a SOC.
1078 output of /proc/device-tree, that is nodes are directories and
1092 The syntax of the dtc tool is
1098 The "output_version" defines what version of the "blob" format will be
1103 uniqueness of linux, phandle properties, validity of strings, etc...
1105 The format of the .dts "source" file is "C" like, supports C and C++
1130 * an arbitrary array of bytes
1138 childprop = "hello\n"; /* define a property "childprop" of
1145 structure of the tree.
1154 automatic generation of phandles, labels (exported to the asm file so
1156 you link the device-tree with), label or path instead of numeric value
1158 time), export of reserve map address to the asm file, ability to
1161 We may provide a .h include file with common definitions of that
1163 interrupt maps) though it may be better to add a notion of struct
1188 - An example of code for iterating nodes & retrieving properties
1190 file drivers/of/fdt.c. Look at the of_scan_flat_dt() function,
1193 GPL bootloader, and as the author of that code, I would be happy
1195 integrate all or part of this code into a non-GPL bootloader.
1205 exist on a single piece of silicon. For these SOCs, an SOC node
1211 genericization of much of the kernel code.
1214 1) Defining child nodes of an SOC
1217 Each device that is part of an SOC may have its own node entry inside
1224 to the parent SOC address space and the size of the device's
1228 specifications for the format of the device tree node. All SOC child
1240 representation defined as part of the Open Firmware specifications,
1251 The device tree represents the buses and devices of a hardware
1252 system in a form similar to the physical bus topology of the
1256 hierarchy and routing of interrupts in the hardware.
1271 property. The interrupt property value is an arbitrary number of
1272 of 'interrupt specifier' values which describe the interrupt or
1275 The encoding of an interrupt specifier is determined by the
1277 interrupt tree. The root of an interrupt domain specifies in
1278 its #interrupt-cells property the number of 32-bit cells
1280 mapping documentation for a detailed description of domains.
1283 specifies an #interrupt-cells value of 2 to encode the interrupt
1288 The PCI bus binding specifies a #interrupt-cell value of 1 to encode
1296 the interrupt tree. The value of interrupt-parent is the
1297 phandle of the parent node.
1343 The sleep property consists of one or more sleep resources, each of
1344 which consists of a phandle to a sleep controller, followed by a
1345 controller-specific sleep specifier of zero or more cells.
1347 The semantics of what type of low power modes are possible are defined
1348 by the sleep controller. Some examples of the types of low power modes
1358 only be suspended when none of the devices are in use. Where reasonable,
1367 Some devices may have DMA memory range shifted relatively to the beginning of
1368 RAM, or even placed outside of kernel RAM. For example, the Keystone 2 SoC
1372 and DMA range is aliased into first 2G of RAM in HW.
1376 for describing the configuration of such system in DT.
1384 - dma-ranges: <prop-encoded-array> encoded as arbitrary number of triplets of
1388 structure of a memory-mapped bus whose device tree parent can be accessed
1389 from DMA operations originating from the bus. It provides a means of
1390 defining a mapping or translation between the physical address space of
1391 the bus and the physical address space of the parent of the bus.