| blob | 7b4e8a70882c2ff4fb4d61e4bc12a4987a7d06eb |
1 Booting the Linux/ppc kernel without Open Firmware
2 --------------------------------------------------
4 (c) 2005 Benjamin Herrenschmidt <benh at kernel.crashing.org>,
5 IBM Corp.
6 (c) 2005 Becky Bruce <becky.bruce at freescale.com>,
7 Freescale Semiconductor, FSL SOC and 32-bit additions
8 (c) 2006 MontaVista Software, Inc.
9 Flash chip node definition
11 Table of Contents
12 =================
14 I - Introduction
15 1) Entry point for arch/powerpc
16 2) Board support
18 II - The DT block format
19 1) Header
20 2) Device tree generalities
21 3) Device tree "structure" block
22 4) Device tree "strings" block
24 III - Required content of the device tree
25 1) Note about cells and address representation
26 2) Note about "compatible" properties
27 3) Note about "name" properties
28 4) Note about node and property names and character set
29 5) Required nodes and properties
30 a) The root node
31 b) The /cpus node
32 c) The /cpus/* nodes
33 d) the /memory node(s)
34 e) The /chosen node
35 f) the /soc<SOCname> node
37 IV - "dtc", the device tree compiler
39 V - Recommendations for a bootloader
41 VI - System-on-a-chip devices and nodes
42 1) Defining child nodes of an SOC
43 2) Representing devices without a current OF specification
44 a) MDIO IO device
45 b) Gianfar-compatible ethernet nodes
46 c) PHY nodes
47 d) Interrupt controllers
48 e) I2C
49 f) Freescale SOC USB controllers
50 g) Freescale SOC SEC Security Engines
51 h) Board Control and Status (BCSR)
52 i) Freescale QUICC Engine module (QE)
53 j) CFI or JEDEC memory-mapped NOR flash
54 k) Global Utilities Block
55 l) Freescale Communications Processor Module
56 m) Chipselect/Local Bus
57 n) 4xx/Axon EMAC ethernet nodes
58 o) Xilinx IP cores
59 p) Freescale Synchronous Serial Interface
60 q) USB EHCI controllers
62 VII - Specifying interrupt information for devices
63 1) interrupts property
64 2) interrupt-parent property
65 3) OpenPIC Interrupt Controllers
66 4) ISA Interrupt Controllers
68 Appendix A - Sample SOC node for MPC8540
71 Revision Information
72 ====================
74 May 18, 2005: Rev 0.1 - Initial draft, no chapter III yet.
76 May 19, 2005: Rev 0.2 - Add chapter III and bits & pieces here or
77 clarifies the fact that a lot of things are
78 optional, the kernel only requires a very
79 small device tree, though it is encouraged
80 to provide an as complete one as possible.
82 May 24, 2005: Rev 0.3 - Precise that DT block has to be in RAM
83 - Misc fixes
84 - Define version 3 and new format version 16
85 for the DT block (version 16 needs kernel
86 patches, will be fwd separately).
87 String block now has a size, and full path
88 is replaced by unit name for more
89 compactness.
90 linux,phandle is made optional, only nodes
91 that are referenced by other nodes need it.
92 "name" property is now automatically
93 deduced from the unit name
95 June 1, 2005: Rev 0.4 - Correct confusion between OF_DT_END and
96 OF_DT_END_NODE in structure definition.
97 - Change version 16 format to always align
98 property data to 4 bytes. Since tokens are
99 already aligned, that means no specific
100 required alignment between property size
101 and property data. The old style variable
102 alignment would make it impossible to do
103 "simple" insertion of properties using
104 memmove (thanks Milton for
105 noticing). Updated kernel patch as well
106 - Correct a few more alignment constraints
107 - Add a chapter about the device-tree
108 compiler and the textural representation of
109 the tree that can be "compiled" by dtc.
111 November 21, 2005: Rev 0.5
112 - Additions/generalizations for 32-bit
113 - Changed to reflect the new arch/powerpc
114 structure
115 - Added chapter VI
118 ToDo:
119 - Add some definitions of interrupt tree (simple/complex)
120 - Add some definitions for PCI host bridges
121 - Add some common address format examples
122 - Add definitions for standard properties and "compatible"
123 names for cells that are not already defined by the existing
124 OF spec.
125 - Compare FSL SOC use of PCI to standard and make sure no new
126 node definition required.
127 - Add more information about node definitions for SOC devices
128 that currently have no standard, like the FSL CPM.
131 I - Introduction
132 ================
134 During the recent development of the Linux/ppc64 kernel, and more
135 specifically, the addition of new platform types outside of the old
136 IBM pSeries/iSeries pair, it was decided to enforce some strict rules
137 regarding the kernel entry and bootloader <-> kernel interfaces, in
138 order to avoid the degeneration that had become the ppc32 kernel entry
139 point and the way a new platform should be added to the kernel. The
140 legacy iSeries platform breaks those rules as it predates this scheme,
141 but no new board support will be accepted in the main tree that
142 doesn't follows them properly. In addition, since the advent of the
143 arch/powerpc merged architecture for ppc32 and ppc64, new 32-bit
144 platforms and 32-bit platforms which move into arch/powerpc will be
145 required to use these rules as well.
147 The main requirement that will be defined in more detail below is
148 the presence of a device-tree whose format is defined after Open
149 Firmware specification. However, in order to make life easier
150 to embedded board vendors, the kernel doesn't require the device-tree
151 to represent every device in the system and only requires some nodes
152 and properties to be present. This will be described in detail in
153 section III, but, for example, the kernel does not require you to
154 create a node for every PCI device in the system. It is a requirement
155 to have a node for PCI host bridges in order to provide interrupt
156 routing informations and memory/IO ranges, among others. It is also
157 recommended to define nodes for on chip devices and other busses that
158 don't specifically fit in an existing OF specification. This creates a
159 great flexibility in the way the kernel can then probe those and match
160 drivers to device, without having to hard code all sorts of tables. It
161 also makes it more flexible for board vendors to do minor hardware
162 upgrades without significantly impacting the kernel code or cluttering
163 it with special cases.
166 1) Entry point for arch/powerpc
167 -------------------------------
169 There is one and one single entry point to the kernel, at the start
170 of the kernel image. That entry point supports two calling
171 conventions:
173 a) Boot from Open Firmware. If your firmware is compatible
174 with Open Firmware (IEEE 1275) or provides an OF compatible
175 client interface API (support for "interpret" callback of
176 forth words isn't required), you can enter the kernel with:
178 r5 : OF callback pointer as defined by IEEE 1275
179 bindings to powerpc. Only the 32-bit client interface
180 is currently supported
182 r3, r4 : address & length of an initrd if any or 0
184 The MMU is either on or off; the kernel will run the
185 trampoline located in arch/powerpc/kernel/prom_init.c to
186 extract the device-tree and other information from open
187 firmware and build a flattened device-tree as described
188 in b). prom_init() will then re-enter the kernel using
189 the second method. This trampoline code runs in the
190 context of the firmware, which is supposed to handle all
191 exceptions during that time.
193 b) Direct entry with a flattened device-tree block. This entry
194 point is called by a) after the OF trampoline and can also be
195 called directly by a bootloader that does not support the Open
196 Firmware client interface. It is also used by "kexec" to
197 implement "hot" booting of a new kernel from a previous
198 running one. This method is what I will describe in more
199 details in this document, as method a) is simply standard Open
200 Firmware, and thus should be implemented according to the
201 various standard documents defining it and its binding to the
202 PowerPC platform. The entry point definition then becomes:
204 r3 : physical pointer to the device-tree block
205 (defined in chapter II) in RAM
207 r4 : physical pointer to the kernel itself. This is
208 used by the assembly code to properly disable the MMU
209 in case you are entering the kernel with MMU enabled
210 and a non-1:1 mapping.
212 r5 : NULL (as to differentiate with method a)
214 Note about SMP entry: Either your firmware puts your other
215 CPUs in some sleep loop or spin loop in ROM where you can get
216 them out via a soft reset or some other means, in which case
217 you don't need to care, or you'll have to enter the kernel
218 with all CPUs. The way to do that with method b) will be
219 described in a later revision of this document.
222 2) Board support
223 ----------------
225 64-bit kernels:
227 Board supports (platforms) are not exclusive config options. An
228 arbitrary set of board supports can be built in a single kernel
229 image. The kernel will "know" what set of functions to use for a
230 given platform based on the content of the device-tree. Thus, you
231 should:
233 a) add your platform support as a _boolean_ option in
234 arch/powerpc/Kconfig, following the example of PPC_PSERIES,
235 PPC_PMAC and PPC_MAPLE. The later is probably a good
236 example of a board support to start from.
238 b) create your main platform file as
239 "arch/powerpc/platforms/myplatform/myboard_setup.c" and add it
240 to the Makefile under the condition of your CONFIG_
241 option. This file will define a structure of type "ppc_md"
242 containing the various callbacks that the generic code will
243 use to get to your platform specific code
245 c) Add a reference to your "ppc_md" structure in the
246 "machines" table in arch/powerpc/kernel/setup_64.c if you are
247 a 64-bit platform.
249 d) request and get assigned a platform number (see PLATFORM_*
250 constants in include/asm-powerpc/processor.h
252 32-bit embedded kernels:
254 Currently, board support is essentially an exclusive config option.
255 The kernel is configured for a single platform. Part of the reason
256 for this is to keep kernels on embedded systems small and efficient;
257 part of this is due to the fact the code is already that way. In the
258 future, a kernel may support multiple platforms, but only if the
259 platforms feature the same core architecture. A single kernel build
260 cannot support both configurations with Book E and configurations
261 with classic Powerpc architectures.
263 32-bit embedded platforms that are moved into arch/powerpc using a
264 flattened device tree should adopt the merged tree practice of
265 setting ppc_md up dynamically, even though the kernel is currently
266 built with support for only a single platform at a time. This allows
267 unification of the setup code, and will make it easier to go to a
268 multiple-platform-support model in the future.
270 NOTE: I believe the above will be true once Ben's done with the merge
271 of the boot sequences.... someone speak up if this is wrong!
273 To add a 32-bit embedded platform support, follow the instructions
274 for 64-bit platforms above, with the exception that the Kconfig
275 option should be set up such that the kernel builds exclusively for
276 the platform selected. The processor type for the platform should
277 enable another config option to select the specific board
278 supported.
280 NOTE: If Ben doesn't merge the setup files, may need to change this to
281 point to setup_32.c
284 I will describe later the boot process and various callbacks that
285 your platform should implement.
288 II - The DT block format
289 ========================
292 This chapter defines the actual format of the flattened device-tree
293 passed to the kernel. The actual content of it and kernel requirements
294 are described later. You can find example of code manipulating that
295 format in various places, including arch/powerpc/kernel/prom_init.c
296 which will generate a flattened device-tree from the Open Firmware
297 representation, or the fs2dt utility which is part of the kexec tools
298 which will generate one from a filesystem representation. It is
299 expected that a bootloader like uboot provides a bit more support,
300 that will be discussed later as well.
302 Note: The block has to be in main memory. It has to be accessible in
303 both real mode and virtual mode with no mapping other than main
304 memory. If you are writing a simple flash bootloader, it should copy
305 the block to RAM before passing it to the kernel.
308 1) Header
309 ---------
311 The kernel is entered with r3 pointing to an area of memory that is
312 roughly described in include/asm-powerpc/prom.h by the structure
313 boot_param_header:
315 struct boot_param_header {
316 u32 magic; /* magic word OF_DT_HEADER */
317 u32 totalsize; /* total size of DT block */
318 u32 off_dt_struct; /* offset to structure */
319 u32 off_dt_strings; /* offset to strings */
320 u32 off_mem_rsvmap; /* offset to memory reserve map
321 */
322 u32 version; /* format version */
323 u32 last_comp_version; /* last compatible version */
325 /* version 2 fields below */
326 u32 boot_cpuid_phys; /* Which physical CPU id we're
327 booting on */
328 /* version 3 fields below */
329 u32 size_dt_strings; /* size of the strings block */
331 /* version 17 fields below */
332 u32 size_dt_struct; /* size of the DT structure block */
333 };
335 Along with the constants:
337 /* Definitions used by the flattened device tree */
338 #define OF_DT_HEADER 0xd00dfeed /* 4: version,
339 4: total size */
340 #define OF_DT_BEGIN_NODE 0x1 /* Start node: full name
341 */
342 #define OF_DT_END_NODE 0x2 /* End node */
343 #define OF_DT_PROP 0x3 /* Property: name off,
344 size, content */
345 #define OF_DT_END 0x9
347 All values in this header are in big endian format, the various
348 fields in this header are defined more precisely below. All
349 "offset" values are in bytes from the start of the header; that is
350 from the value of r3.
352 - magic
354 This is a magic value that "marks" the beginning of the
355 device-tree block header. It contains the value 0xd00dfeed and is
356 defined by the constant OF_DT_HEADER
358 - totalsize
360 This is the total size of the DT block including the header. The
361 "DT" block should enclose all data structures defined in this
362 chapter (who are pointed to by offsets in this header). That is,
363 the device-tree structure, strings, and the memory reserve map.
365 - off_dt_struct
367 This is an offset from the beginning of the header to the start
368 of the "structure" part the device tree. (see 2) device tree)
370 - off_dt_strings
372 This is an offset from the beginning of the header to the start
373 of the "strings" part of the device-tree
375 - off_mem_rsvmap
377 This is an offset from the beginning of the header to the start
378 of the reserved memory map. This map is a list of pairs of 64-
379 bit integers. Each pair is a physical address and a size. The
380 list is terminated by an entry of size 0. This map provides the
381 kernel with a list of physical memory areas that are "reserved"
382 and thus not to be used for memory allocations, especially during
383 early initialization. The kernel needs to allocate memory during
384 boot for things like un-flattening the device-tree, allocating an
385 MMU hash table, etc... Those allocations must be done in such a
386 way to avoid overriding critical things like, on Open Firmware
387 capable machines, the RTAS instance, or on some pSeries, the TCE
388 tables used for the iommu. Typically, the reserve map should
389 contain _at least_ this DT block itself (header,total_size). If
390 you are passing an initrd to the kernel, you should reserve it as
391 well. You do not need to reserve the kernel image itself. The map
392 should be 64-bit aligned.
394 - version
396 This is the version of this structure. Version 1 stops
397 here. Version 2 adds an additional field boot_cpuid_phys.
398 Version 3 adds the size of the strings block, allowing the kernel
399 to reallocate it easily at boot and free up the unused flattened
400 structure after expansion. Version 16 introduces a new more
401 "compact" format for the tree itself that is however not backward
402 compatible. Version 17 adds an additional field, size_dt_struct,
403 allowing it to be reallocated or moved more easily (this is
404 particularly useful for bootloaders which need to make
405 adjustments to a device tree based on probed information). You
406 should always generate a structure of the highest version defined
407 at the time of your implementation. Currently that is version 17,
408 unless you explicitly aim at being backward compatible.
410 - last_comp_version
412 Last compatible version. This indicates down to what version of
413 the DT block you are backward compatible. For example, version 2
414 is backward compatible with version 1 (that is, a kernel build
415 for version 1 will be able to boot with a version 2 format). You
416 should put a 1 in this field if you generate a device tree of
417 version 1 to 3, or 16 if you generate a tree of version 16 or 17
418 using the new unit name format.
420 - boot_cpuid_phys
422 This field only exist on version 2 headers. It indicate which
423 physical CPU ID is calling the kernel entry point. This is used,
424 among others, by kexec. If you are on an SMP system, this value
425 should match the content of the "reg" property of the CPU node in
426 the device-tree corresponding to the CPU calling the kernel entry
427 point (see further chapters for more informations on the required
428 device-tree contents)
430 - size_dt_strings
432 This field only exists on version 3 and later headers. It
433 gives the size of the "strings" section of the device tree (which
434 starts at the offset given by off_dt_strings).
436 - size_dt_struct
438 This field only exists on version 17 and later headers. It gives
439 the size of the "structure" section of the device tree (which
440 starts at the offset given by off_dt_struct).
442 So the typical layout of a DT block (though the various parts don't
443 need to be in that order) looks like this (addresses go from top to
444 bottom):
447 ------------------------------
448 r3 -> | struct boot_param_header |
449 ------------------------------
450 | (alignment gap) (*) |
451 ------------------------------
452 | memory reserve map |
453 ------------------------------
454 | (alignment gap) |
455 ------------------------------
456 | |
457 | device-tree structure |
458 | |
459 ------------------------------
460 | (alignment gap) |
461 ------------------------------
462 | |
463 | device-tree strings |
464 | |
465 -----> ------------------------------
466 |
467 |
468 --- (r3 + totalsize)
470 (*) The alignment gaps are not necessarily present; their presence
471 and size are dependent on the various alignment requirements of
472 the individual data blocks.
475 2) Device tree generalities
476 ---------------------------
478 This device-tree itself is separated in two different blocks, a
479 structure block and a strings block. Both need to be aligned to a 4
480 byte boundary.
482 First, let's quickly describe the device-tree concept before detailing
483 the storage format. This chapter does _not_ describe the detail of the
484 required types of nodes & properties for the kernel, this is done
485 later in chapter III.
487 The device-tree layout is strongly inherited from the definition of
488 the Open Firmware IEEE 1275 device-tree. It's basically a tree of
489 nodes, each node having two or more named properties. A property can
490 have a value or not.
492 It is a tree, so each node has one and only one parent except for the
493 root node who has no parent.
495 A node has 2 names. The actual node name is generally contained in a
496 property of type "name" in the node property list whose value is a
497 zero terminated string and is mandatory for version 1 to 3 of the
498 format definition (as it is in Open Firmware). Version 16 makes it
499 optional as it can generate it from the unit name defined below.
501 There is also a "unit name" that is used to differentiate nodes with
502 the same name at the same level, it is usually made of the node
503 names, the "@" sign, and a "unit address", which definition is
504 specific to the bus type the node sits on.
506 The unit name doesn't exist as a property per-se but is included in
507 the device-tree structure. It is typically used to represent "path" in
508 the device-tree. More details about the actual format of these will be
509 below.
511 The kernel powerpc generic code does not make any formal use of the
512 unit address (though some board support code may do) so the only real
513 requirement here for the unit address is to ensure uniqueness of
514 the node unit name at a given level of the tree. Nodes with no notion
515 of address and no possible sibling of the same name (like /memory or
516 /cpus) may omit the unit address in the context of this specification,
517 or use the "@0" default unit address. The unit name is used to define
518 a node "full path", which is the concatenation of all parent node
519 unit names separated with "/".
521 The root node doesn't have a defined name, and isn't required to have
522 a name property either if you are using version 3 or earlier of the
523 format. It also has no unit address (no @ symbol followed by a unit
524 address). The root node unit name is thus an empty string. The full
525 path to the root node is "/".
527 Every node which actually represents an actual device (that is, a node
528 which isn't only a virtual "container" for more nodes, like "/cpus"
529 is) is also required to have a "device_type" property indicating the
530 type of node .
532 Finally, every node that can be referenced from a property in another
533 node is required to have a "linux,phandle" property. Real open
534 firmware implementations provide a unique "phandle" value for every
535 node that the "prom_init()" trampoline code turns into
536 "linux,phandle" properties. However, this is made optional if the
537 flattened device tree is used directly. An example of a node
538 referencing another node via "phandle" is when laying out the
539 interrupt tree which will be described in a further version of this
540 document.
542 This "linux, phandle" property is a 32-bit value that uniquely
543 identifies a node. You are free to use whatever values or system of
544 values, internal pointers, or whatever to generate these, the only
545 requirement is that every node for which you provide that property has
546 a unique value for it.
548 Here is an example of a simple device-tree. In this example, an "o"
549 designates a node followed by the node unit name. Properties are
550 presented with their name followed by their content. "content"
551 represents an ASCII string (zero terminated) value, while <content>
552 represents a 32-bit hexadecimal value. The various nodes in this
553 example will be discussed in a later chapter. At this point, it is
554 only meant to give you a idea of what a device-tree looks like. I have
555 purposefully kept the "name" and "linux,phandle" properties which
556 aren't necessary in order to give you a better idea of what the tree
557 looks like in practice.
559 / o device-tree
560 |- name = "device-tree"
561 |- model = "MyBoardName"
562 |- compatible = "MyBoardFamilyName"
563 |- #address-cells = <2>
564 |- #size-cells = <2>
565 |- linux,phandle = <0>
566 |
567 o cpus
568 | | - name = "cpus"
569 | | - linux,phandle = <1>
570 | | - #address-cells = <1>
571 | | - #size-cells = <0>
572 | |
573 | o PowerPC,970@0
574 | |- name = "PowerPC,970"
575 | |- device_type = "cpu"
576 | |- reg = <0>
577 | |- clock-frequency = <5f5e1000>
578 | |- 64-bit
579 | |- linux,phandle = <2>
580 |
581 o memory@0
582 | |- name = "memory"
583 | |- device_type = "memory"
584 | |- reg = <00000000 00000000 00000000 20000000>
585 | |- linux,phandle = <3>
586 |
587 o chosen
588 |- name = "chosen"
589 |- bootargs = "root=/dev/sda2"
590 |- linux,phandle = <4>
592 This tree is almost a minimal tree. It pretty much contains the
593 minimal set of required nodes and properties to boot a linux kernel;
594 that is, some basic model informations at the root, the CPUs, and the
595 physical memory layout. It also includes misc information passed
596 through /chosen, like in this example, the platform type (mandatory)
597 and the kernel command line arguments (optional).
599 The /cpus/PowerPC,970@0/64-bit property is an example of a
600 property without a value. All other properties have a value. The
601 significance of the #address-cells and #size-cells properties will be
602 explained in chapter IV which defines precisely the required nodes and
603 properties and their content.
606 3) Device tree "structure" block
608 The structure of the device tree is a linearized tree structure. The
609 "OF_DT_BEGIN_NODE" token starts a new node, and the "OF_DT_END_NODE"
610 ends that node definition. Child nodes are simply defined before
611 "OF_DT_END_NODE" (that is nodes within the node). A 'token' is a 32
612 bit value. The tree has to be "finished" with a OF_DT_END token
614 Here's the basic structure of a single node:
616 * token OF_DT_BEGIN_NODE (that is 0x00000001)
617 * for version 1 to 3, this is the node full path as a zero
618 terminated string, starting with "/". For version 16 and later,
619 this is the node unit name only (or an empty string for the
620 root node)
621 * [align gap to next 4 bytes boundary]
622 * for each property:
623 * token OF_DT_PROP (that is 0x00000003)
624 * 32-bit value of property value size in bytes (or 0 if no
625 value)
626 * 32-bit value of offset in string block of property name
627 * property value data if any
628 * [align gap to next 4 bytes boundary]
629 * [child nodes if any]
630 * token OF_DT_END_NODE (that is 0x00000002)
632 So the node content can be summarized as a start token, a full path,
633 a list of properties, a list of child nodes, and an end token. Every
634 child node is a full node structure itself as defined above.
636 NOTE: The above definition requires that all property definitions for
637 a particular node MUST precede any subnode definitions for that node.
638 Although the structure would not be ambiguous if properties and
639 subnodes were intermingled, the kernel parser requires that the
640 properties come first (up until at least 2.6.22). Any tools
641 manipulating a flattened tree must take care to preserve this
642 constraint.
644 4) Device tree "strings" block
646 In order to save space, property names, which are generally redundant,
647 are stored separately in the "strings" block. This block is simply the
648 whole bunch of zero terminated strings for all property names
649 concatenated together. The device-tree property definitions in the
650 structure block will contain offset values from the beginning of the
651 strings block.
654 III - Required content of the device tree
655 =========================================
657 WARNING: All "linux,*" properties defined in this document apply only
658 to a flattened device-tree. If your platform uses a real
659 implementation of Open Firmware or an implementation compatible with
660 the Open Firmware client interface, those properties will be created
661 by the trampoline code in the kernel's prom_init() file. For example,
662 that's where you'll have to add code to detect your board model and
663 set the platform number. However, when using the flattened device-tree
664 entry point, there is no prom_init() pass, and thus you have to
665 provide those properties yourself.
668 1) Note about cells and address representation
669 ----------------------------------------------
671 The general rule is documented in the various Open Firmware
672 documentations. If you choose to describe a bus with the device-tree
673 and there exist an OF bus binding, then you should follow the
674 specification. However, the kernel does not require every single
675 device or bus to be described by the device tree.
677 In general, the format of an address for a device is defined by the
678 parent bus type, based on the #address-cells and #size-cells
679 properties. Note that the parent's parent definitions of #address-cells
680 and #size-cells are not inhereted so every node with children must specify
681 them. The kernel requires the root node to have those properties defining
682 addresses format for devices directly mapped on the processor bus.
684 Those 2 properties define 'cells' for representing an address and a
685 size. A "cell" is a 32-bit number. For example, if both contain 2
686 like the example tree given above, then an address and a size are both
687 composed of 2 cells, and each is a 64-bit number (cells are
688 concatenated and expected to be in big endian format). Another example
689 is the way Apple firmware defines them, with 2 cells for an address
690 and one cell for a size. Most 32-bit implementations should define
691 #address-cells and #size-cells to 1, which represents a 32-bit value.
692 Some 32-bit processors allow for physical addresses greater than 32
693 bits; these processors should define #address-cells as 2.
695 "reg" properties are always a tuple of the type "address size" where
696 the number of cells of address and size is specified by the bus
697 #address-cells and #size-cells. When a bus supports various address
698 spaces and other flags relative to a given address allocation (like
699 prefetchable, etc...) those flags are usually added to the top level
700 bits of the physical address. For example, a PCI physical address is
701 made of 3 cells, the bottom two containing the actual address itself
702 while the top cell contains address space indication, flags, and pci
703 bus & device numbers.
705 For busses that support dynamic allocation, it's the accepted practice
706 to then not provide the address in "reg" (keep it 0) though while
707 providing a flag indicating the address is dynamically allocated, and
708 then, to provide a separate "assigned-addresses" property that
709 contains the fully allocated addresses. See the PCI OF bindings for
710 details.
712 In general, a simple bus with no address space bits and no dynamic
713 allocation is preferred if it reflects your hardware, as the existing
714 kernel address parsing functions will work out of the box. If you
715 define a bus type with a more complex address format, including things
716 like address space bits, you'll have to add a bus translator to the
717 prom_parse.c file of the recent kernels for your bus type.
719 The "reg" property only defines addresses and sizes (if #size-cells is
720 non-0) within a given bus. In order to translate addresses upward
721 (that is into parent bus addresses, and possibly into CPU physical
722 addresses), all busses must contain a "ranges" property. If the
723 "ranges" property is missing at a given level, it's assumed that
724 translation isn't possible, i.e., the registers are not visible on the
725 parent bus. The format of the "ranges" property for a bus is a list
726 of:
728 bus address, parent bus address, size
730 "bus address" is in the format of the bus this bus node is defining,
731 that is, for a PCI bridge, it would be a PCI address. Thus, (bus
732 address, size) defines a range of addresses for child devices. "parent
733 bus address" is in the format of the parent bus of this bus. For
734 example, for a PCI host controller, that would be a CPU address. For a
735 PCI<->ISA bridge, that would be a PCI address. It defines the base
736 address in the parent bus where the beginning of that range is mapped.
738 For a new 64-bit powerpc board, I recommend either the 2/2 format or
739 Apple's 2/1 format which is slightly more compact since sizes usually
740 fit in a single 32-bit word. New 32-bit powerpc boards should use a
741 1/1 format, unless the processor supports physical addresses greater
742 than 32-bits, in which case a 2/1 format is recommended.
744 Alternatively, the "ranges" property may be empty, indicating that the
745 registers are visible on the parent bus using an identity mapping
746 translation. In other words, the parent bus address space is the same
747 as the child bus address space.
749 2) Note about "compatible" properties
750 -------------------------------------
752 These properties are optional, but recommended in devices and the root
753 node. The format of a "compatible" property is a list of concatenated
754 zero terminated strings. They allow a device to express its
755 compatibility with a family of similar devices, in some cases,
756 allowing a single driver to match against several devices regardless
757 of their actual names.
759 3) Note about "name" properties
760 -------------------------------
762 While earlier users of Open Firmware like OldWorld macintoshes tended
763 to use the actual device name for the "name" property, it's nowadays
764 considered a good practice to use a name that is closer to the device
765 class (often equal to device_type). For example, nowadays, ethernet
766 controllers are named "ethernet", an additional "model" property
767 defining precisely the chip type/model, and "compatible" property
768 defining the family in case a single driver can driver more than one
769 of these chips. However, the kernel doesn't generally put any
770 restriction on the "name" property; it is simply considered good
771 practice to follow the standard and its evolutions as closely as
772 possible.
774 Note also that the new format version 16 makes the "name" property
775 optional. If it's absent for a node, then the node's unit name is then
776 used to reconstruct the name. That is, the part of the unit name
777 before the "@" sign is used (or the entire unit name if no "@" sign
778 is present).
780 4) Note about node and property names and character set
781 -------------------------------------------------------
783 While open firmware provides more flexible usage of 8859-1, this
784 specification enforces more strict rules. Nodes and properties should
785 be comprised only of ASCII characters 'a' to 'z', '0' to
786 '9', ',', '.', '_', '+', '#', '?', and '-'. Node names additionally
787 allow uppercase characters 'A' to 'Z' (property names should be
788 lowercase. The fact that vendors like Apple don't respect this rule is
789 irrelevant here). Additionally, node and property names should always
790 begin with a character in the range 'a' to 'z' (or 'A' to 'Z' for node
791 names).
793 The maximum number of characters for both nodes and property names
794 is 31. In the case of node names, this is only the leftmost part of
795 a unit name (the pure "name" property), it doesn't include the unit
796 address which can extend beyond that limit.
799 5) Required nodes and properties
800 --------------------------------
801 These are all that are currently required. However, it is strongly
802 recommended that you expose PCI host bridges as documented in the
803 PCI binding to open firmware, and your interrupt tree as documented
804 in OF interrupt tree specification.
806 a) The root node
808 The root node requires some properties to be present:
810 - model : this is your board name/model
811 - #address-cells : address representation for "root" devices
812 - #size-cells: the size representation for "root" devices
813 - device_type : This property shouldn't be necessary. However, if
814 you decide to create a device_type for your root node, make sure it
815 is _not_ "chrp" unless your platform is a pSeries or PAPR compliant
816 one for 64-bit, or a CHRP-type machine for 32-bit as this will
817 matched by the kernel this way.
819 Additionally, some recommended properties are:
821 - compatible : the board "family" generally finds its way here,
822 for example, if you have 2 board models with a similar layout,
823 that typically get driven by the same platform code in the
824 kernel, you would use a different "model" property but put a
825 value in "compatible". The kernel doesn't directly use that
826 value but it is generally useful.
828 The root node is also generally where you add additional properties
829 specific to your board like the serial number if any, that sort of
830 thing. It is recommended that if you add any "custom" property whose
831 name may clash with standard defined ones, you prefix them with your
832 vendor name and a comma.
834 b) The /cpus node
836 This node is the parent of all individual CPU nodes. It doesn't
837 have any specific requirements, though it's generally good practice
838 to have at least:
840 #address-cells = <00000001>
841 #size-cells = <00000000>
843 This defines that the "address" for a CPU is a single cell, and has
844 no meaningful size. This is not necessary but the kernel will assume
845 that format when reading the "reg" properties of a CPU node, see
846 below
848 c) The /cpus/* nodes
850 So under /cpus, you are supposed to create a node for every CPU on
851 the machine. There is no specific restriction on the name of the
852 CPU, though It's common practice to call it PowerPC,<name>. For
853 example, Apple uses PowerPC,G5 while IBM uses PowerPC,970FX.
855 Required properties:
857 - device_type : has to be "cpu"
858 - reg : This is the physical CPU number, it's a single 32-bit cell
859 and is also used as-is as the unit number for constructing the
860 unit name in the full path. For example, with 2 CPUs, you would
861 have the full path:
862 /cpus/PowerPC,970FX@0
863 /cpus/PowerPC,970FX@1
864 (unit addresses do not require leading zeroes)
865 - d-cache-block-size : one cell, L1 data cache block size in bytes (*)
866 - i-cache-block-size : one cell, L1 instruction cache block size in
867 bytes
868 - d-cache-size : one cell, size of L1 data cache in bytes
869 - i-cache-size : one cell, size of L1 instruction cache in bytes
871 (*) The cache "block" size is the size on which the cache management
872 instructions operate. Historically, this document used the cache
873 "line" size here which is incorrect. The kernel will prefer the cache
874 block size and will fallback to cache line size for backward
875 compatibility.
877 Recommended properties:
879 - timebase-frequency : a cell indicating the frequency of the
880 timebase in Hz. This is not directly used by the generic code,
881 but you are welcome to copy/paste the pSeries code for setting
882 the kernel timebase/decrementer calibration based on this
883 value.
884 - clock-frequency : a cell indicating the CPU core clock frequency
885 in Hz. A new property will be defined for 64-bit values, but if
886 your frequency is < 4Ghz, one cell is enough. Here as well as
887 for the above, the common code doesn't use that property, but
888 you are welcome to re-use the pSeries or Maple one. A future
889 kernel version might provide a common function for this.
890 - d-cache-line-size : one cell, L1 data cache line size in bytes
891 if different from the block size
892 - i-cache-line-size : one cell, L1 instruction cache line size in
893 bytes if different from the block size
895 You are welcome to add any property you find relevant to your board,
896 like some information about the mechanism used to soft-reset the
897 CPUs. For example, Apple puts the GPIO number for CPU soft reset
898 lines in there as a "soft-reset" property since they start secondary
899 CPUs by soft-resetting them.
902 d) the /memory node(s)
904 To define the physical memory layout of your board, you should
905 create one or more memory node(s). You can either create a single
906 node with all memory ranges in its reg property, or you can create
907 several nodes, as you wish. The unit address (@ part) used for the
908 full path is the address of the first range of memory defined by a
909 given node. If you use a single memory node, this will typically be
910 @0.
912 Required properties:
914 - device_type : has to be "memory"
915 - reg : This property contains all the physical memory ranges of
916 your board. It's a list of addresses/sizes concatenated
917 together, with the number of cells of each defined by the
918 #address-cells and #size-cells of the root node. For example,
919 with both of these properties being 2 like in the example given
920 earlier, a 970 based machine with 6Gb of RAM could typically
921 have a "reg" property here that looks like:
923 00000000 00000000 00000000 80000000
924 00000001 00000000 00000001 00000000
926 That is a range starting at 0 of 0x80000000 bytes and a range
927 starting at 0x100000000 and of 0x100000000 bytes. You can see
928 that there is no memory covering the IO hole between 2Gb and
929 4Gb. Some vendors prefer splitting those ranges into smaller
930 segments, but the kernel doesn't care.
932 e) The /chosen node
934 This node is a bit "special". Normally, that's where open firmware
935 puts some variable environment information, like the arguments, or
936 the default input/output devices.
938 This specification makes a few of these mandatory, but also defines
939 some linux-specific properties that would be normally constructed by
940 the prom_init() trampoline when booting with an OF client interface,
941 but that you have to provide yourself when using the flattened format.
943 Recommended properties:
945 - bootargs : This zero-terminated string is passed as the kernel
946 command line
947 - linux,stdout-path : This is the full path to your standard
948 console device if any. Typically, if you have serial devices on
949 your board, you may want to put the full path to the one set as
950 the default console in the firmware here, for the kernel to pick
951 it up as its own default console. If you look at the function
952 set_preferred_console() in arch/ppc64/kernel/setup.c, you'll see
953 that the kernel tries to find out the default console and has
954 knowledge of various types like 8250 serial ports. You may want
955 to extend this function to add your own.
957 Note that u-boot creates and fills in the chosen node for platforms
958 that use it.
960 (Note: a practice that is now obsolete was to include a property
961 under /chosen called interrupt-controller which had a phandle value
962 that pointed to the main interrupt controller)
964 f) the /soc<SOCname> node
966 This node is used to represent a system-on-a-chip (SOC) and must be
967 present if the processor is a SOC. The top-level soc node contains
968 information that is global to all devices on the SOC. The node name
969 should contain a unit address for the SOC, which is the base address
970 of the memory-mapped register set for the SOC. The name of an soc
971 node should start with "soc", and the remainder of the name should
972 represent the part number for the soc. For example, the MPC8540's
973 soc node would be called "soc8540".
975 Required properties:
977 - device_type : Should be "soc"
978 - ranges : Should be defined as specified in 1) to describe the
979 translation of SOC addresses for memory mapped SOC registers.
980 - bus-frequency: Contains the bus frequency for the SOC node.
981 Typically, the value of this field is filled in by the boot
982 loader.
985 Recommended properties:
987 - reg : This property defines the address and size of the
988 memory-mapped registers that are used for the SOC node itself.
989 It does not include the child device registers - these will be
990 defined inside each child node. The address specified in the
991 "reg" property should match the unit address of the SOC node.
992 - #address-cells : Address representation for "soc" devices. The
993 format of this field may vary depending on whether or not the
994 device registers are memory mapped. For memory mapped
995 registers, this field represents the number of cells needed to
996 represent the address of the registers. For SOCs that do not
997 use MMIO, a special address format should be defined that
998 contains enough cells to represent the required information.
999 See 1) above for more details on defining #address-cells.
1000 - #size-cells : Size representation for "soc" devices
1001 - #interrupt-cells : Defines the width of cells used to represent
1002 interrupts. Typically this value is <2>, which includes a
1003 32-bit number that represents the interrupt number, and a
1004 32-bit number that represents the interrupt sense and level.
1005 This field is only needed if the SOC contains an interrupt
1006 controller.
1008 The SOC node may contain child nodes for each SOC device that the
1009 platform uses. Nodes should not be created for devices which exist
1010 on the SOC but are not used by a particular platform. See chapter VI
1011 for more information on how to specify devices that are part of a SOC.
1013 Example SOC node for the MPC8540:
1015 soc8540@e0000000 {
1016 #address-cells = <1>;
1017 #size-cells = <1>;
1018 #interrupt-cells = <2>;
1019 device_type = "soc";
1020 ranges = <00000000 e0000000 00100000>
1021 reg = <e0000000 00003000>;
1022 bus-frequency = <0>;
1023 }
1027 IV - "dtc", the device tree compiler
1028 ====================================
1031 dtc source code can be found at
1032 <http://ozlabs.org/~dgibson/dtc/dtc.tar.gz>
1034 WARNING: This version is still in early development stage; the
1035 resulting device-tree "blobs" have not yet been validated with the
1036 kernel. The current generated bloc lacks a useful reserve map (it will
1037 be fixed to generate an empty one, it's up to the bootloader to fill
1038 it up) among others. The error handling needs work, bugs are lurking,
1039 etc...
1041 dtc basically takes a device-tree in a given format and outputs a
1042 device-tree in another format. The currently supported formats are:
1044 Input formats:
1045 -------------
1047 - "dtb": "blob" format, that is a flattened device-tree block
1048 with
1049 header all in a binary blob.
1050 - "dts": "source" format. This is a text file containing a
1051 "source" for a device-tree. The format is defined later in this
1052 chapter.
1053 - "fs" format. This is a representation equivalent to the
1054 output of /proc/device-tree, that is nodes are directories and
1055 properties are files
1057 Output formats:
1058 ---------------
1060 - "dtb": "blob" format
1061 - "dts": "source" format
1062 - "asm": assembly language file. This is a file that can be
1063 sourced by gas to generate a device-tree "blob". That file can
1064 then simply be added to your Makefile. Additionally, the
1065 assembly file exports some symbols that can be used.
1068 The syntax of the dtc tool is
1070 dtc [-I <input-format>] [-O <output-format>]
1071 [-o output-filename] [-V output_version] input_filename
1074 The "output_version" defines what version of the "blob" format will be
1075 generated. Supported versions are 1,2,3 and 16. The default is
1076 currently version 3 but that may change in the future to version 16.
1078 Additionally, dtc performs various sanity checks on the tree, like the
1079 uniqueness of linux, phandle properties, validity of strings, etc...
1081 The format of the .dts "source" file is "C" like, supports C and C++
1082 style comments.
1084 / {
1085 }
1087 The above is the "device-tree" definition. It's the only statement
1088 supported currently at the toplevel.
1090 / {
1091 property1 = "string_value"; /* define a property containing a 0
1092 * terminated string
1093 */
1095 property2 = <1234abcd>; /* define a property containing a
1096 * numerical 32-bit value (hexadecimal)
1097 */
1099 property3 = <12345678 12345678 deadbeef>;
1100 /* define a property containing 3
1101 * numerical 32-bit values (cells) in
1102 * hexadecimal
1103 */
1104 property4 = [0a 0b 0c 0d de ea ad be ef];
1105 /* define a property whose content is
1106 * an arbitrary array of bytes
1107 */
1109 childnode@addresss { /* define a child node named "childnode"
1110 * whose unit name is "childnode at
1111 * address"
1112 */
1114 childprop = "hello\n"; /* define a property "childprop" of
1115 * childnode (in this case, a string)
1116 */
1117 };
1118 };
1120 Nodes can contain other nodes etc... thus defining the hierarchical
1121 structure of the tree.
1123 Strings support common escape sequences from C: "\n", "\t", "\r",
1124 "\(octal value)", "\x(hex value)".
1126 It is also suggested that you pipe your source file through cpp (gcc
1127 preprocessor) so you can use #include's, #define for constants, etc...
1129 Finally, various options are planned but not yet implemented, like
1130 automatic generation of phandles, labels (exported to the asm file so
1131 you can point to a property content and change it easily from whatever
1132 you link the device-tree with), label or path instead of numeric value
1133 in some cells to "point" to a node (replaced by a phandle at compile
1134 time), export of reserve map address to the asm file, ability to
1135 specify reserve map content at compile time, etc...
1137 We may provide a .h include file with common definitions of that
1138 proves useful for some properties (like building PCI properties or
1139 interrupt maps) though it may be better to add a notion of struct
1140 definitions to the compiler...
1143 V - Recommendations for a bootloader
1144 ====================================
1147 Here are some various ideas/recommendations that have been proposed
1148 while all this has been defined and implemented.
1150 - The bootloader may want to be able to use the device-tree itself
1151 and may want to manipulate it (to add/edit some properties,
1152 like physical memory size or kernel arguments). At this point, 2
1153 choices can be made. Either the bootloader works directly on the
1154 flattened format, or the bootloader has its own internal tree
1155 representation with pointers (similar to the kernel one) and
1156 re-flattens the tree when booting the kernel. The former is a bit
1157 more difficult to edit/modify, the later requires probably a bit
1158 more code to handle the tree structure. Note that the structure
1159 format has been designed so it's relatively easy to "insert"
1160 properties or nodes or delete them by just memmoving things
1161 around. It contains no internal offsets or pointers for this
1162 purpose.
1164 - An example of code for iterating nodes & retrieving properties
1165 directly from the flattened tree format can be found in the kernel
1166 file arch/ppc64/kernel/prom.c, look at scan_flat_dt() function,
1167 its usage in early_init_devtree(), and the corresponding various
1168 early_init_dt_scan_*() callbacks. That code can be re-used in a
1169 GPL bootloader, and as the author of that code, I would be happy
1170 to discuss possible free licensing to any vendor who wishes to
1171 integrate all or part of this code into a non-GPL bootloader.
1175 VI - System-on-a-chip devices and nodes
1176 =======================================
1178 Many companies are now starting to develop system-on-a-chip
1179 processors, where the processor core (CPU) and many peripheral devices
1180 exist on a single piece of silicon. For these SOCs, an SOC node
1181 should be used that defines child nodes for the devices that make
1182 up the SOC. While platforms are not required to use this model in
1183 order to boot the kernel, it is highly encouraged that all SOC
1184 implementations define as complete a flat-device-tree as possible to
1185 describe the devices on the SOC. This will allow for the
1186 genericization of much of the kernel code.
1189 1) Defining child nodes of an SOC
1190 ---------------------------------
1192 Each device that is part of an SOC may have its own node entry inside
1193 the SOC node. For each device that is included in the SOC, the unit
1194 address property represents the address offset for this device's
1195 memory-mapped registers in the parent's address space. The parent's
1196 address space is defined by the "ranges" property in the top-level soc
1197 node. The "reg" property for each node that exists directly under the
1198 SOC node should contain the address mapping from the child address space
1199 to the parent SOC address space and the size of the device's
1200 memory-mapped register file.
1202 For many devices that may exist inside an SOC, there are predefined
1203 specifications for the format of the device tree node. All SOC child
1204 nodes should follow these specifications, except where noted in this
1205 document.
1207 See appendix A for an example partial SOC node definition for the
1208 MPC8540.
1211 2) Representing devices without a current OF specification
1212 ----------------------------------------------------------
1214 Currently, there are many devices on SOCs that do not have a standard
1215 representation pre-defined as part of the open firmware
1216 specifications, mainly because the boards that contain these SOCs are
1217 not currently booted using open firmware. This section contains
1218 descriptions for the SOC devices for which new nodes have been
1219 defined; this list will expand as more and more SOC-containing
1220 platforms are moved over to use the flattened-device-tree model.
1222 a) MDIO IO device
1224 The MDIO is a bus to which the PHY devices are connected. For each
1225 device that exists on this bus, a child node should be created. See
1226 the definition of the PHY node below for an example of how to define
1227 a PHY.
1229 Required properties:
1230 - reg : Offset and length of the register set for the device
1231 - compatible : Should define the compatible device type for the
1232 mdio. Currently, this is most likely to be "fsl,gianfar-mdio"
1234 Example:
1236 mdio@24520 {
1237 reg = <24520 20>;
1238 compatible = "fsl,gianfar-mdio";
1240 ethernet-phy@0 {
1241 ......
1242 };
1243 };
1246 b) Gianfar-compatible ethernet nodes
1248 Required properties:
1250 - device_type : Should be "network"
1251 - model : Model of the device. Can be "TSEC", "eTSEC", or "FEC"
1252 - compatible : Should be "gianfar"
1253 - reg : Offset and length of the register set for the device
1254 - mac-address : List of bytes representing the ethernet address of
1255 this controller
1256 - interrupts : <a b> where a is the interrupt number and b is a
1257 field that represents an encoding of the sense and level
1258 information for the interrupt. This should be encoded based on
1259 the information in section 2) depending on the type of interrupt
1260 controller you have.
1261 - interrupt-parent : the phandle for the interrupt controller that
1262 services interrupts for this device.
1263 - phy-handle : The phandle for the PHY connected to this ethernet
1264 controller.
1265 - fixed-link : <a b c d e> where a is emulated phy id - choose any,
1266 but unique to the all specified fixed-links, b is duplex - 0 half,
1267 1 full, c is link speed - d#10/d#100/d#1000, d is pause - 0 no
1268 pause, 1 pause, e is asym_pause - 0 no asym_pause, 1 asym_pause.
1270 Recommended properties:
1272 - linux,network-index : This is the intended "index" of this
1273 network device. This is used by the bootwrapper to interpret
1274 MAC addresses passed by the firmware when no information other
1275 than indices is available to associate an address with a device.
1276 - phy-connection-type : a string naming the controller/PHY interface type,
1277 i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id", "sgmii",
1278 "tbi", or "rtbi". This property is only really needed if the connection
1279 is of type "rgmii-id", as all other connection types are detected by
1280 hardware.
1283 Example:
1285 ethernet@24000 {
1286 #size-cells = <0>;
1287 device_type = "network";
1288 model = "TSEC";
1289 compatible = "gianfar";
1290 reg = <24000 1000>;
1291 mac-address = [ 00 E0 0C 00 73 00 ];
1292 interrupts = <d 3 e 3 12 3>;
1293 interrupt-parent = <40000>;
1294 phy-handle = <2452000>
1295 };
1299 c) PHY nodes
1301 Required properties:
1303 - device_type : Should be "ethernet-phy"
1304 - interrupts : <a b> where a is the interrupt number and b is a
1305 field that represents an encoding of the sense and level
1306 information for the interrupt. This should be encoded based on
1307 the information in section 2) depending on the type of interrupt
1308 controller you have.
1309 - interrupt-parent : the phandle for the interrupt controller that
1310 services interrupts for this device.
1311 - reg : The ID number for the phy, usually a small integer
1312 - linux,phandle : phandle for this node; likely referenced by an
1313 ethernet controller node.
1316 Example:
1318 ethernet-phy@0 {
1319 linux,phandle = <2452000>
1320 interrupt-parent = <40000>;
1321 interrupts = <35 1>;
1322 reg = <0>;
1323 device_type = "ethernet-phy";
1324 };
1327 d) Interrupt controllers
1329 Some SOC devices contain interrupt controllers that are different
1330 from the standard Open PIC specification. The SOC device nodes for
1331 these types of controllers should be specified just like a standard
1332 OpenPIC controller. Sense and level information should be encoded
1333 as specified in section 2) of this chapter for each device that
1334 specifies an interrupt.
1336 Example :
1338 pic@40000 {
1339 linux,phandle = <40000>;
1340 clock-frequency = <0>;
1341 interrupt-controller;
1342 #address-cells = <0>;
1343 reg = <40000 40000>;
1344 built-in;
1345 compatible = "chrp,open-pic";
1346 device_type = "open-pic";
1347 big-endian;
1348 };
1351 e) I2C
1353 Required properties :
1355 - device_type : Should be "i2c"
1356 - reg : Offset and length of the register set for the device
1358 Recommended properties :
1360 - compatible : Should be "fsl-i2c" for parts compatible with
1361 Freescale I2C specifications.
1362 - interrupts : <a b> where a is the interrupt number and b is a
1363 field that represents an encoding of the sense and level
1364 information for the interrupt. This should be encoded based on
1365 the information in section 2) depending on the type of interrupt
1366 controller you have.
1367 - interrupt-parent : the phandle for the interrupt controller that
1368 services interrupts for this device.
1369 - dfsrr : boolean; if defined, indicates that this I2C device has
1370 a digital filter sampling rate register
1371 - fsl5200-clocking : boolean; if defined, indicated that this device
1372 uses the FSL 5200 clocking mechanism.
1374 Example :
1376 i2c@3000 {
1377 interrupt-parent = <40000>;
1378 interrupts = <1b 3>;
1379 reg = <3000 18>;
1380 device_type = "i2c";
1381 compatible = "fsl-i2c";
1382 dfsrr;
1383 };
1386 f) Freescale SOC USB controllers
1388 The device node for a USB controller that is part of a Freescale
1389 SOC is as described in the document "Open Firmware Recommended
1390 Practice : Universal Serial Bus" with the following modifications
1391 and additions :
1393 Required properties :
1394 - compatible : Should be "fsl-usb2-mph" for multi port host USB
1395 controllers, or "fsl-usb2-dr" for dual role USB controllers
1396 - phy_type : For multi port host USB controllers, should be one of
1397 "ulpi", or "serial". For dual role USB controllers, should be
1398 one of "ulpi", "utmi", "utmi_wide", or "serial".
1399 - reg : Offset and length of the register set for the device
1400 - port0 : boolean; if defined, indicates port0 is connected for
1401 fsl-usb2-mph compatible controllers. Either this property or
1402 "port1" (or both) must be defined for "fsl-usb2-mph" compatible
1403 controllers.
1404 - port1 : boolean; if defined, indicates port1 is connected for
1405 fsl-usb2-mph compatible controllers. Either this property or
1406 "port0" (or both) must be defined for "fsl-usb2-mph" compatible
1407 controllers.
1408 - dr_mode : indicates the working mode for "fsl-usb2-dr" compatible
1409 controllers. Can be "host", "peripheral", or "otg". Default to
1410 "host" if not defined for backward compatibility.
1412 Recommended properties :
1413 - interrupts : <a b> where a is the interrupt number and b is a
1414 field that represents an encoding of the sense and level
1415 information for the interrupt. This should be encoded based on
1416 the information in section 2) depending on the type of interrupt
1417 controller you have.
1418 - interrupt-parent : the phandle for the interrupt controller that
1419 services interrupts for this device.
1421 Example multi port host USB controller device node :
1422 usb@22000 {
1423 compatible = "fsl-usb2-mph";
1424 reg = <22000 1000>;
1425 #address-cells = <1>;
1426 #size-cells = <0>;
1427 interrupt-parent = <700>;
1428 interrupts = <27 1>;
1429 phy_type = "ulpi";
1430 port0;
1431 port1;
1432 };
1434 Example dual role USB controller device node :
1435 usb@23000 {
1436 compatible = "fsl-usb2-dr";
1437 reg = <23000 1000>;
1438 #address-cells = <1>;
1439 #size-cells = <0>;
1440 interrupt-parent = <700>;
1441 interrupts = <26 1>;
1442 dr_mode = "otg";
1443 phy = "ulpi";
1444 };
1447 g) Freescale SOC SEC Security Engines
1449 Required properties:
1451 - device_type : Should be "crypto"
1452 - model : Model of the device. Should be "SEC1" or "SEC2"
1453 - compatible : Should be "talitos"
1454 - reg : Offset and length of the register set for the device
1455 - interrupts : <a b> where a is the interrupt number and b is a
1456 field that represents an encoding of the sense and level
1457 information for the interrupt. This should be encoded based on
1458 the information in section 2) depending on the type of interrupt
1459 controller you have.
1460 - interrupt-parent : the phandle for the interrupt controller that
1461 services interrupts for this device.
1462 - num-channels : An integer representing the number of channels
1463 available.
1464 - channel-fifo-len : An integer representing the number of
1465 descriptor pointers each channel fetch fifo can hold.
1466 - exec-units-mask : The bitmask representing what execution units
1467 (EUs) are available. It's a single 32-bit cell. EU information
1468 should be encoded following the SEC's Descriptor Header Dword
1469 EU_SEL0 field documentation, i.e. as follows:
1471 bit 0 = reserved - should be 0
1472 bit 1 = set if SEC has the ARC4 EU (AFEU)
1473 bit 2 = set if SEC has the DES/3DES EU (DEU)
1474 bit 3 = set if SEC has the message digest EU (MDEU)
1475 bit 4 = set if SEC has the random number generator EU (RNG)
1476 bit 5 = set if SEC has the public key EU (PKEU)
1477 bit 6 = set if SEC has the AES EU (AESU)
1478 bit 7 = set if SEC has the Kasumi EU (KEU)
1480 bits 8 through 31 are reserved for future SEC EUs.
1482 - descriptor-types-mask : The bitmask representing what descriptors
1483 are available. It's a single 32-bit cell. Descriptor type
1484 information should be encoded following the SEC's Descriptor
1485 Header Dword DESC_TYPE field documentation, i.e. as follows:
1487 bit 0 = set if SEC supports the aesu_ctr_nonsnoop desc. type
1488 bit 1 = set if SEC supports the ipsec_esp descriptor type
1489 bit 2 = set if SEC supports the common_nonsnoop desc. type
1490 bit 3 = set if SEC supports the 802.11i AES ccmp desc. type
1491 bit 4 = set if SEC supports the hmac_snoop_no_afeu desc. type
1492 bit 5 = set if SEC supports the srtp descriptor type
1493 bit 6 = set if SEC supports the non_hmac_snoop_no_afeu desc.type
1494 bit 7 = set if SEC supports the pkeu_assemble descriptor type
1495 bit 8 = set if SEC supports the aesu_key_expand_output desc.type
1496 bit 9 = set if SEC supports the pkeu_ptmul descriptor type
1497 bit 10 = set if SEC supports the common_nonsnoop_afeu desc. type
1498 bit 11 = set if SEC supports the pkeu_ptadd_dbl descriptor type
1500 ..and so on and so forth.
1502 Example:
1504 /* MPC8548E */
1505 crypto@30000 {
1506 device_type = "crypto";
1507 model = "SEC2";
1508 compatible = "talitos";
1509 reg = <30000 10000>;
1510 interrupts = <1d 3>;
1511 interrupt-parent = <40000>;
1512 num-channels = <4>;
1513 channel-fifo-len = <18>;
1514 exec-units-mask = <000000fe>;
1515 descriptor-types-mask = <012b0ebf>;
1516 };
1518 h) Board Control and Status (BCSR)
1520 Required properties:
1522 - device_type : Should be "board-control"
1523 - reg : Offset and length of the register set for the device
1525 Example:
1527 bcsr@f8000000 {
1528 device_type = "board-control";
1529 reg = <f8000000 8000>;
1530 };
1532 i) Freescale QUICC Engine module (QE)
1533 This represents qe module that is installed on PowerQUICC II Pro.
1535 NOTE: This is an interim binding; it should be updated to fit
1536 in with the CPM binding later in this document.
1538 Basically, it is a bus of devices, that could act more or less
1539 as a complete entity (UCC, USB etc ). All of them should be siblings on
1540 the "root" qe node, using the common properties from there.
1541 The description below applies to the qe of MPC8360 and
1542 more nodes and properties would be extended in the future.
1544 i) Root QE device
1546 Required properties:
1547 - compatible : should be "fsl,qe";
1548 - model : precise model of the QE, Can be "QE", "CPM", or "CPM2"
1549 - reg : offset and length of the device registers.
1550 - bus-frequency : the clock frequency for QUICC Engine.
1552 Recommended properties
1553 - brg-frequency : the internal clock source frequency for baud-rate
1554 generators in Hz.
1556 Example:
1557 qe@e0100000 {
1558 #address-cells = <1>;
1559 #size-cells = <1>;
1560 #interrupt-cells = <2>;
1561 compatible = "fsl,qe";
1562 ranges = <0 e0100000 00100000>;
1563 reg = <e0100000 480>;
1564 brg-frequency = <0>;
1565 bus-frequency = <179A7B00>;
1566 }
1569 ii) SPI (Serial Peripheral Interface)
1571 Required properties:
1572 - cell-index : SPI controller index.
1573 - compatible : should be "fsl,spi".
1574 - mode : the SPI operation mode, it can be "cpu" or "cpu-qe".
1575 - reg : Offset and length of the register set for the device
1576 - interrupts : <a b> where a is the interrupt number and b is a
1577 field that represents an encoding of the sense and level
1578 information for the interrupt. This should be encoded based on
1579 the information in section 2) depending on the type of interrupt
1580 controller you have.
1581 - interrupt-parent : the phandle for the interrupt controller that
1582 services interrupts for this device.
1584 Example:
1585 spi@4c0 {
1586 cell-index = <0>;
1587 compatible = "fsl,spi";
1588 reg = <4c0 40>;
1589 interrupts = <82 0>;
1590 interrupt-parent = <700>;
1591 mode = "cpu";
1592 };
1595 iii) USB (Universal Serial Bus Controller)
1597 Required properties:
1598 - compatible : could be "qe_udc" or "fhci-hcd".
1599 - mode : the could be "host" or "slave".
1600 - reg : Offset and length of the register set for the device
1601 - interrupts : <a b> where a is the interrupt number and b is a
1602 field that represents an encoding of the sense and level
1603 information for the interrupt. This should be encoded based on
1604 the information in section 2) depending on the type of interrupt
1605 controller you have.
1606 - interrupt-parent : the phandle for the interrupt controller that
1607 services interrupts for this device.
1609 Example(slave):
1610 usb@6c0 {
1611 compatible = "qe_udc";
1612 reg = <6c0 40>;
1613 interrupts = <8b 0>;
1614 interrupt-parent = <700>;
1615 mode = "slave";
1616 };
1619 iv) UCC (Unified Communications Controllers)
1621 Required properties:
1622 - device_type : should be "network", "hldc", "uart", "transparent"
1623 "bisync", "atm", or "serial".
1624 - compatible : could be "ucc_geth" or "fsl_atm" and so on.
1625 - model : should be "UCC".
1626 - device-id : the ucc number(1-8), corresponding to UCCx in UM.
1627 - reg : Offset and length of the register set for the device
1628 - interrupts : <a b> where a is the interrupt number and b is a
1629 field that represents an encoding of the sense and level
1630 information for the interrupt. This should be encoded based on
1631 the information in section 2) depending on the type of interrupt
1632 controller you have.
1633 - interrupt-parent : the phandle for the interrupt controller that
1634 services interrupts for this device.
1635 - pio-handle : The phandle for the Parallel I/O port configuration.
1636 - port-number : for UART drivers, the port number to use, between 0 and 3.
1637 This usually corresponds to the /dev/ttyQE device, e.g. <0> = /dev/ttyQE0.
1638 The port number is added to the minor number of the device. Unlike the
1639 CPM UART driver, the port-number is required for the QE UART driver.
1640 - soft-uart : for UART drivers, if specified this means the QE UART device
1641 driver should use "Soft-UART" mode, which is needed on some SOCs that have
1642 broken UART hardware. Soft-UART is provided via a microcode upload.
1643 - rx-clock-name: the UCC receive clock source
1644 "none": clock source is disabled
1645 "brg1" through "brg16": clock source is BRG1-BRG16, respectively
1646 "clk1" through "clk24": clock source is CLK1-CLK24, respectively
1647 - tx-clock-name: the UCC transmit clock source
1648 "none": clock source is disabled
1649 "brg1" through "brg16": clock source is BRG1-BRG16, respectively
1650 "clk1" through "clk24": clock source is CLK1-CLK24, respectively
1651 The following two properties are deprecated. rx-clock has been replaced
1652 with rx-clock-name, and tx-clock has been replaced with tx-clock-name.
1653 Drivers that currently use the deprecated properties should continue to
1654 do so, in order to support older device trees, but they should be updated
1655 to check for the new properties first.
1656 - rx-clock : represents the UCC receive clock source.
1657 0x00 : clock source is disabled;
1658 0x1~0x10 : clock source is BRG1~BRG16 respectively;
1659 0x11~0x28: clock source is QE_CLK1~QE_CLK24 respectively.
1660 - tx-clock: represents the UCC transmit clock source;
1661 0x00 : clock source is disabled;
1662 0x1~0x10 : clock source is BRG1~BRG16 respectively;
1663 0x11~0x28: clock source is QE_CLK1~QE_CLK24 respectively.
1665 Required properties for network device_type:
1666 - mac-address : list of bytes representing the ethernet address.
1667 - phy-handle : The phandle for the PHY connected to this controller.
1669 Recommended properties:
1670 - linux,network-index : This is the intended "index" of this
1671 network device. This is used by the bootwrapper to interpret
1672 MAC addresses passed by the firmware when no information other
1673 than indices is available to associate an address with a device.
1674 - phy-connection-type : a string naming the controller/PHY interface type,
1675 i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id" (Internal
1676 Delay), "rgmii-txid" (delay on TX only), "rgmii-rxid" (delay on RX only),
1677 "tbi", or "rtbi".
1679 Example:
1680 ucc@2000 {
1681 device_type = "network";
1682 compatible = "ucc_geth";
1683 model = "UCC";
1684 device-id = <1>;
1685 reg = <2000 200>;
1686 interrupts = <a0 0>;
1687 interrupt-parent = <700>;
1688 mac-address = [ 00 04 9f 00 23 23 ];
1689 rx-clock = "none";
1690 tx-clock = "clk9";
1691 phy-handle = <212000>;
1692 phy-connection-type = "gmii";
1693 pio-handle = <140001>;
1694 };
1697 v) Parallel I/O Ports
1699 This node configures Parallel I/O ports for CPUs with QE support.
1700 The node should reside in the "soc" node of the tree. For each
1701 device that using parallel I/O ports, a child node should be created.
1702 See the definition of the Pin configuration nodes below for more
1703 information.
1705 Required properties:
1706 - device_type : should be "par_io".
1707 - reg : offset to the register set and its length.
1708 - num-ports : number of Parallel I/O ports
1710 Example:
1711 par_io@1400 {
1712 reg = <1400 100>;
1713 #address-cells = <1>;
1714 #size-cells = <0>;
1715 device_type = "par_io";
1716 num-ports = <7>;
1717 ucc_pin@01 {
1718 ......
1719 };
1722 vi) Pin configuration nodes
1724 Required properties:
1725 - linux,phandle : phandle of this node; likely referenced by a QE
1726 device.
1727 - pio-map : array of pin configurations. Each pin is defined by 6
1728 integers. The six numbers are respectively: port, pin, dir,
1729 open_drain, assignment, has_irq.
1730 - port : port number of the pin; 0-6 represent port A-G in UM.
1731 - pin : pin number in the port.
1732 - dir : direction of the pin, should encode as follows:
1734 0 = The pin is disabled
1735 1 = The pin is an output
1736 2 = The pin is an input
1737 3 = The pin is I/O
1739 - open_drain : indicates the pin is normal or wired-OR:
1741 0 = The pin is actively driven as an output
1742 1 = The pin is an open-drain driver. As an output, the pin is
1743 driven active-low, otherwise it is three-stated.
1745 - assignment : function number of the pin according to the Pin Assignment
1746 tables in User Manual. Each pin can have up to 4 possible functions in
1747 QE and two options for CPM.
1748 - has_irq : indicates if the pin is used as source of external
1749 interrupts.
1751 Example:
1752 ucc_pin@01 {
1753 linux,phandle = <140001>;
1754 pio-map = <
1755 /* port pin dir open_drain assignment has_irq */
1756 0 3 1 0 1 0 /* TxD0 */
1757 0 4 1 0 1 0 /* TxD1 */
1758 0 5 1 0 1 0 /* TxD2 */
1759 0 6 1 0 1 0 /* TxD3 */
1760 1 6 1 0 3 0 /* TxD4 */
1761 1 7 1 0 1 0 /* TxD5 */
1762 1 9 1 0 2 0 /* TxD6 */
1763 1 a 1 0 2 0 /* TxD7 */
1764 0 9 2 0 1 0 /* RxD0 */
1765 0 a 2 0 1 0 /* RxD1 */
1766 0 b 2 0 1 0 /* RxD2 */
1767 0 c 2 0 1 0 /* RxD3 */
1768 0 d 2 0 1 0 /* RxD4 */
1769 1 1 2 0 2 0 /* RxD5 */
1770 1 0 2 0 2 0 /* RxD6 */
1771 1 4 2 0 2 0 /* RxD7 */
1772 0 7 1 0 1 0 /* TX_EN */
1773 0 8 1 0 1 0 /* TX_ER */
1774 0 f 2 0 1 0 /* RX_DV */
1775 0 10 2 0 1 0 /* RX_ER */
1776 0 0 2 0 1 0 /* RX_CLK */
1777 2 9 1 0 3 0 /* GTX_CLK - CLK10 */
1778 2 8 2 0 1 0>; /* GTX125 - CLK9 */
1779 };
1781 vii) Multi-User RAM (MURAM)
1783 Required properties:
1784 - compatible : should be "fsl,qe-muram", "fsl,cpm-muram".
1785 - mode : the could be "host" or "slave".
1786 - ranges : Should be defined as specified in 1) to describe the
1787 translation of MURAM addresses.
1788 - data-only : sub-node which defines the address area under MURAM
1789 bus that can be allocated as data/parameter
1791 Example:
1793 muram@10000 {
1794 compatible = "fsl,qe-muram", "fsl,cpm-muram";
1795 ranges = <0 00010000 0000c000>;
1797 data-only@0{
1798 compatible = "fsl,qe-muram-data",
1799 "fsl,cpm-muram-data";
1800 reg = <0 c000>;
1801 };
1802 };
1804 viii) Uploaded QE firmware
1806 If a new firwmare has been uploaded to the QE (usually by the
1807 boot loader), then a 'firmware' child node should be added to the QE
1808 node. This node provides information on the uploaded firmware that
1809 device drivers may need.
1811 Required properties:
1812 - id: The string name of the firmware. This is taken from the 'id'
1813 member of the qe_firmware structure of the uploaded firmware.
1814 Device drivers can search this string to determine if the
1815 firmware they want is already present.
1816 - extended-modes: The Extended Modes bitfield, taken from the
1817 firmware binary. It is a 64-bit number represented
1818 as an array of two 32-bit numbers.
1819 - virtual-traps: The virtual traps, taken from the firmware binary.
1820 It is an array of 8 32-bit numbers.
1822 Example:
1824 firmware {
1825 id = "Soft-UART";
1826 extended-modes = <0 0>;
1827 virtual-traps = <0 0 0 0 0 0 0 0>;
1828 }
1830 j) CFI or JEDEC memory-mapped NOR flash
1832 Flash chips (Memory Technology Devices) are often used for solid state
1833 file systems on embedded devices.
1835 - compatible : should contain the specific model of flash chip(s)
1836 used, if known, followed by either "cfi-flash" or "jedec-flash"
1837 - reg : Address range of the flash chip
1838 - bank-width : Width (in bytes) of the flash bank. Equal to the
1839 device width times the number of interleaved chips.
1840 - device-width : (optional) Width of a single flash chip. If
1841 omitted, assumed to be equal to 'bank-width'.
1842 - #address-cells, #size-cells : Must be present if the flash has
1843 sub-nodes representing partitions (see below). In this case
1844 both #address-cells and #size-cells must be equal to 1.
1846 For JEDEC compatible devices, the following additional properties
1847 are defined:
1849 - vendor-id : Contains the flash chip's vendor id (1 byte).
1850 - device-id : Contains the flash chip's device id (1 byte).
1852 In addition to the information on the flash bank itself, the
1853 device tree may optionally contain additional information
1854 describing partitions of the flash address space. This can be
1855 used on platforms which have strong conventions about which
1856 portions of the flash are used for what purposes, but which don't
1857 use an on-flash partition table such as RedBoot.
1859 Each partition is represented as a sub-node of the flash device.
1860 Each node's name represents the name of the corresponding
1861 partition of the flash device.
1863 Flash partitions
1864 - reg : The partition's offset and size within the flash bank.
1865 - label : (optional) The label / name for this flash partition.
1866 If omitted, the label is taken from the node name (excluding
1867 the unit address).
1868 - read-only : (optional) This parameter, if present, is a hint to
1869 Linux that this flash partition should only be mounted
1870 read-only. This is usually used for flash partitions
1871 containing early-boot firmware images or data which should not
1872 be clobbered.
1874 Example:
1876 flash@ff000000 {
1877 compatible = "amd,am29lv128ml", "cfi-flash";
1878 reg = <ff000000 01000000>;
1879 bank-width = <4>;
1880 device-width = <1>;
1881 #address-cells = <1>;
1882 #size-cells = <1>;
1883 fs@0 {
1884 label = "fs";
1885 reg = <0 f80000>;
1886 };
1887 firmware@f80000 {
1888 label ="firmware";
1889 reg = <f80000 80000>;
1890 read-only;
1891 };
1892 };
1894 k) Global Utilities Block
1896 The global utilities block controls power management, I/O device
1897 enabling, power-on-reset configuration monitoring, general-purpose
1898 I/O signal configuration, alternate function selection for multiplexed
1899 signals, and clock control.
1901 Required properties:
1903 - compatible : Should define the compatible device type for
1904 global-utilities.
1905 - reg : Offset and length of the register set for the device.
1907 Recommended properties:
1909 - fsl,has-rstcr : Indicates that the global utilities register set
1910 contains a functioning "reset control register" (i.e. the board
1911 is wired to reset upon setting the HRESET_REQ bit in this register).
1913 Example:
1915 global-utilities@e0000 { /* global utilities block */
1916 compatible = "fsl,mpc8548-guts";
1917 reg = <e0000 1000>;
1918 fsl,has-rstcr;
1919 };
1921 l) Freescale Communications Processor Module
1923 NOTE: This is an interim binding, and will likely change slightly,
1924 as more devices are supported. The QE bindings especially are
1925 incomplete.
1927 i) Root CPM node
1929 Properties:
1930 - compatible : "fsl,cpm1", "fsl,cpm2", or "fsl,qe".
1931 - reg : A 48-byte region beginning with CPCR.
1933 Example:
1934 cpm@119c0 {
1935 #address-cells = <1>;
1936 #size-cells = <1>;
1937 #interrupt-cells = <2>;
1938 compatible = "fsl,mpc8272-cpm", "fsl,cpm2";
1939 reg = <119c0 30>;
1940 }
1942 ii) Properties common to mulitple CPM/QE devices
1944 - fsl,cpm-command : This value is ORed with the opcode and command flag
1945 to specify the device on which a CPM command operates.
1947 - fsl,cpm-brg : Indicates which baud rate generator the device
1948 is associated with. If absent, an unused BRG
1949 should be dynamically allocated. If zero, the
1950 device uses an external clock rather than a BRG.
1952 - reg : Unless otherwise specified, the first resource represents the
1953 scc/fcc/ucc registers, and the second represents the device's
1954 parameter RAM region (if it has one).
1956 iii) Serial
1958 Currently defined compatibles:
1959 - fsl,cpm1-smc-uart
1960 - fsl,cpm2-smc-uart
1961 - fsl,cpm1-scc-uart
1962 - fsl,cpm2-scc-uart
1963 - fsl,qe-uart
1965 Example:
1967 serial@11a00 {
1968 device_type = "serial";
1969 compatible = "fsl,mpc8272-scc-uart",
1970 "fsl,cpm2-scc-uart";
1971 reg = <11a00 20 8000 100>;
1972 interrupts = <28 8>;
1973 interrupt-parent = <&PIC>;
1974 fsl,cpm-brg = <1>;
1975 fsl,cpm-command = <00800000>;
1976 };
1978 iii) Network
1980 Currently defined compatibles:
1981 - fsl,cpm1-scc-enet
1982 - fsl,cpm2-scc-enet
1983 - fsl,cpm1-fec-enet
1984 - fsl,cpm2-fcc-enet (third resource is GFEMR)
1985 - fsl,qe-enet
1987 Example:
1989 ethernet@11300 {
1990 device_type = "network";
1991 compatible = "fsl,mpc8272-fcc-enet",
1992 "fsl,cpm2-fcc-enet";
1993 reg = <11300 20 8400 100 11390 1>;
1994 local-mac-address = [ 00 00 00 00 00 00 ];
1995 interrupts = <20 8>;
1996 interrupt-parent = <&PIC>;
1997 phy-handle = <&PHY0>;
1998 linux,network-index = <0>;
1999 fsl,cpm-command = <12000300>;
2000 };
2002 iv) MDIO
2004 Currently defined compatibles:
2005 fsl,pq1-fec-mdio (reg is same as first resource of FEC device)
2006 fsl,cpm2-mdio-bitbang (reg is port C registers)
2008 Properties for fsl,cpm2-mdio-bitbang:
2009 fsl,mdio-pin : pin of port C controlling mdio data
2010 fsl,mdc-pin : pin of port C controlling mdio clock
2012 Example:
2014 mdio@10d40 {
2015 device_type = "mdio";
2016 compatible = "fsl,mpc8272ads-mdio-bitbang",
2017 "fsl,mpc8272-mdio-bitbang",
2018 "fsl,cpm2-mdio-bitbang";
2019 reg = <10d40 14>;
2020 #address-cells = <1>;
2021 #size-cells = <0>;
2022 fsl,mdio-pin = <12>;
2023 fsl,mdc-pin = <13>;
2024 };
2026 v) Baud Rate Generators
2028 Currently defined compatibles:
2029 fsl,cpm-brg
2030 fsl,cpm1-brg
2031 fsl,cpm2-brg
2033 Properties:
2034 - reg : There may be an arbitrary number of reg resources; BRG
2035 numbers are assigned to these in order.
2036 - clock-frequency : Specifies the base frequency driving
2037 the BRG.
2039 Example:
2041 brg@119f0 {
2042 compatible = "fsl,mpc8272-brg",
2043 "fsl,cpm2-brg",
2044 "fsl,cpm-brg";
2045 reg = <119f0 10 115f0 10>;
2046 clock-frequency = <d#25000000>;
2047 };
2049 vi) Interrupt Controllers
2051 Currently defined compatibles:
2052 - fsl,cpm1-pic
2053 - only one interrupt cell
2054 - fsl,pq1-pic
2055 - fsl,cpm2-pic
2056 - second interrupt cell is level/sense:
2057 - 2 is falling edge
2058 - 8 is active low
2060 Example:
2062 interrupt-controller@10c00 {
2063 #interrupt-cells = <2>;
2064 interrupt-controller;
2065 reg = <10c00 80>;
2066 compatible = "mpc8272-pic", "fsl,cpm2-pic";
2067 };
2069 vii) USB (Universal Serial Bus Controller)
2071 Properties:
2072 - compatible : "fsl,cpm1-usb", "fsl,cpm2-usb", "fsl,qe-usb"
2074 Example:
2075 usb@11bc0 {
2076 #address-cells = <1>;
2077 #size-cells = <0>;
2078 compatible = "fsl,cpm2-usb";
2079 reg = <11b60 18 8b00 100>;
2080 interrupts = <b 8>;
2081 interrupt-parent = <&PIC>;
2082 fsl,cpm-command = <2e600000>;
2083 };
2085 viii) Multi-User RAM (MURAM)
2087 The multi-user/dual-ported RAM is expressed as a bus under the CPM node.
2089 Ranges must be set up subject to the following restrictions:
2091 - Children's reg nodes must be offsets from the start of all muram, even
2092 if the user-data area does not begin at zero.
2093 - If multiple range entries are used, the difference between the parent
2094 address and the child address must be the same in all, so that a single
2095 mapping can cover them all while maintaining the ability to determine
2096 CPM-side offsets with pointer subtraction. It is recommended that
2097 multiple range entries not be used.
2098 - A child address of zero must be translatable, even if no reg resources
2099 contain it.
2101 A child "data" node must exist, compatible with "fsl,cpm-muram-data", to
2102 indicate the portion of muram that is usable by the OS for arbitrary
2103 purposes. The data node may have an arbitrary number of reg resources,
2104 all of which contribute to the allocatable muram pool.
2106 Example, based on mpc8272:
2108 muram@0 {
2109 #address-cells = <1>;
2110 #size-cells = <1>;
2111 ranges = <0 0 10000>;
2113 data@0 {
2114 compatible = "fsl,cpm-muram-data";
2115 reg = <0 2000 9800 800>;
2116 };
2117 };
2119 m) Chipselect/Local Bus
2121 Properties:
2122 - name : Should be localbus
2123 - #address-cells : Should be either two or three. The first cell is the
2124 chipselect number, and the remaining cells are the
2125 offset into the chipselect.
2126 - #size-cells : Either one or two, depending on how large each chipselect
2127 can be.
2128 - ranges : Each range corresponds to a single chipselect, and cover
2129 the entire access window as configured.
2131 Example:
2132 localbus@f0010100 {
2133 compatible = "fsl,mpc8272-localbus",
2134 "fsl,pq2-localbus";
2135 #address-cells = <2>;
2136 #size-cells = <1>;
2137 reg = <f0010100 40>;
2139 ranges = <0 0 fe000000 02000000
2140 1 0 f4500000 00008000>;
2142 flash@0,0 {
2143 compatible = "jedec-flash";
2144 reg = <0 0 2000000>;
2145 bank-width = <4>;
2146 device-width = <1>;
2147 };
2149 board-control@1,0 {
2150 reg = <1 0 20>;
2151 compatible = "fsl,mpc8272ads-bcsr";
2152 };
2153 };
2156 n) 4xx/Axon EMAC ethernet nodes
2158 The EMAC ethernet controller in IBM and AMCC 4xx chips, and also
2159 the Axon bridge. To operate this needs to interact with a ths
2160 special McMAL DMA controller, and sometimes an RGMII or ZMII
2161 interface. In addition to the nodes and properties described
2162 below, the node for the OPB bus on which the EMAC sits must have a
2163 correct clock-frequency property.
2165 i) The EMAC node itself
2167 Required properties:
2168 - device_type : "network"
2170 - compatible : compatible list, contains 2 entries, first is
2171 "ibm,emac-CHIP" where CHIP is the host ASIC (440gx,
2172 405gp, Axon) and second is either "ibm,emac" or
2173 "ibm,emac4". For Axon, thus, we have: "ibm,emac-axon",
2174 "ibm,emac4"
2175 - interrupts : <interrupt mapping for EMAC IRQ and WOL IRQ>
2176 - interrupt-parent : optional, if needed for interrupt mapping
2177 - reg : <registers mapping>
2178 - local-mac-address : 6 bytes, MAC address
2179 - mal-device : phandle of the associated McMAL node
2180 - mal-tx-channel : 1 cell, index of the tx channel on McMAL associated
2181 with this EMAC
2182 - mal-rx-channel : 1 cell, index of the rx channel on McMAL associated
2183 with this EMAC
2184 - cell-index : 1 cell, hardware index of the EMAC cell on a given
2185 ASIC (typically 0x0 and 0x1 for EMAC0 and EMAC1 on
2186 each Axon chip)
2187 - max-frame-size : 1 cell, maximum frame size supported in bytes
2188 - rx-fifo-size : 1 cell, Rx fifo size in bytes for 10 and 100 Mb/sec
2189 operations.
2190 For Axon, 2048
2191 - tx-fifo-size : 1 cell, Tx fifo size in bytes for 10 and 100 Mb/sec
2192 operations.
2193 For Axon, 2048.
2194 - fifo-entry-size : 1 cell, size of a fifo entry (used to calculate
2195 thresholds).
2196 For Axon, 0x00000010
2197 - mal-burst-size : 1 cell, MAL burst size (used to calculate thresholds)
2198 in bytes.
2199 For Axon, 0x00000100 (I think ...)
2200 - phy-mode : string, mode of operations of the PHY interface.
2201 Supported values are: "mii", "rmii", "smii", "rgmii",
2202 "tbi", "gmii", rtbi", "sgmii".
2203 For Axon on CAB, it is "rgmii"
2204 - mdio-device : 1 cell, required iff using shared MDIO registers
2205 (440EP). phandle of the EMAC to use to drive the
2206 MDIO lines for the PHY used by this EMAC.
2207 - zmii-device : 1 cell, required iff connected to a ZMII. phandle of
2208 the ZMII device node
2209 - zmii-channel : 1 cell, required iff connected to a ZMII. Which ZMII
2210 channel or 0xffffffff if ZMII is only used for MDIO.
2211 - rgmii-device : 1 cell, required iff connected to an RGMII. phandle
2212 of the RGMII device node.
2213 For Axon: phandle of plb5/plb4/opb/rgmii
2214 - rgmii-channel : 1 cell, required iff connected to an RGMII. Which
2215 RGMII channel is used by this EMAC.
2216 Fox Axon: present, whatever value is appropriate for each
2217 EMAC, that is the content of the current (bogus) "phy-port"
2218 property.
2220 Recommended properties:
2221 - linux,network-index : This is the intended "index" of this
2222 network device. This is used by the bootwrapper to interpret
2223 MAC addresses passed by the firmware when no information other
2224 than indices is available to associate an address with a device.
2226 Optional properties:
2227 - phy-address : 1 cell, optional, MDIO address of the PHY. If absent,
2228 a search is performed.
2229 - phy-map : 1 cell, optional, bitmap of addresses to probe the PHY
2230 for, used if phy-address is absent. bit 0x00000001 is
2231 MDIO address 0.
2232 For Axon it can be absent, thouugh my current driver
2233 doesn't handle phy-address yet so for now, keep
2234 0x00ffffff in it.
2235 - rx-fifo-size-gige : 1 cell, Rx fifo size in bytes for 1000 Mb/sec
2236 operations (if absent the value is the same as
2237 rx-fifo-size). For Axon, either absent or 2048.
2238 - tx-fifo-size-gige : 1 cell, Tx fifo size in bytes for 1000 Mb/sec
2239 operations (if absent the value is the same as
2240 tx-fifo-size). For Axon, either absent or 2048.
2241 - tah-device : 1 cell, optional. If connected to a TAH engine for
2242 offload, phandle of the TAH device node.
2243 - tah-channel : 1 cell, optional. If appropriate, channel used on the
2244 TAH engine.
2246 Example:
2248 EMAC0: ethernet@40000800 {
2249 linux,network-index = <0>;
2250 device_type = "network";
2251 compatible = "ibm,emac-440gp", "ibm,emac";
2252 interrupt-parent = <&UIC1>;
2253 interrupts = <1c 4 1d 4>;
2254 reg = <40000800 70>;
2255 local-mac-address = [00 04 AC E3 1B 1E];
2256 mal-device = <&MAL0>;
2257 mal-tx-channel = <0 1>;
2258 mal-rx-channel = <0>;
2259 cell-index = <0>;
2260 max-frame-size = <5dc>;
2261 rx-fifo-size = <1000>;
2262 tx-fifo-size = <800>;
2263 phy-mode = "rmii";
2264 phy-map = <00000001>;
2265 zmii-device = <&ZMII0>;
2266 zmii-channel = <0>;
2267 };
2269 ii) McMAL node
2271 Required properties:
2272 - device_type : "dma-controller"
2273 - compatible : compatible list, containing 2 entries, first is
2274 "ibm,mcmal-CHIP" where CHIP is the host ASIC (like
2275 emac) and the second is either "ibm,mcmal" or
2276 "ibm,mcmal2".
2277 For Axon, "ibm,mcmal-axon","ibm,mcmal2"
2278 - interrupts : <interrupt mapping for the MAL interrupts sources:
2279 5 sources: tx_eob, rx_eob, serr, txde, rxde>.
2280 For Axon: This is _different_ from the current
2281 firmware. We use the "delayed" interrupts for txeob
2282 and rxeob. Thus we end up with mapping those 5 MPIC
2283 interrupts, all level positive sensitive: 10, 11, 32,
2284 33, 34 (in decimal)
2285 - dcr-reg : < DCR registers range >
2286 - dcr-parent : if needed for dcr-reg
2287 - num-tx-chans : 1 cell, number of Tx channels
2288 - num-rx-chans : 1 cell, number of Rx channels
2290 iii) ZMII node
2292 Required properties:
2293 - compatible : compatible list, containing 2 entries, first is
2294 "ibm,zmii-CHIP" where CHIP is the host ASIC (like
2295 EMAC) and the second is "ibm,zmii".
2296 For Axon, there is no ZMII node.
2297 - reg : <registers mapping>
2299 iv) RGMII node
2301 Required properties:
2302 - compatible : compatible list, containing 2 entries, first is
2303 "ibm,rgmii-CHIP" where CHIP is the host ASIC (like
2304 EMAC) and the second is "ibm,rgmii".
2305 For Axon, "ibm,rgmii-axon","ibm,rgmii"
2306 - reg : <registers mapping>
2307 - revision : as provided by the RGMII new version register if
2308 available.
2309 For Axon: 0x0000012a
2311 o) Xilinx IP cores
2313 The Xilinx EDK toolchain ships with a set of IP cores (devices) for use
2314 in Xilinx Spartan and Virtex FPGAs. The devices cover the whole range
2315 of standard device types (network, serial, etc.) and miscellanious
2316 devices (gpio, LCD, spi, etc). Also, since these devices are
2317 implemented within the fpga fabric every instance of the device can be
2318 synthesised with different options that change the behaviour.
2320 Each IP-core has a set of parameters which the FPGA designer can use to
2321 control how the core is synthesized. Historically, the EDK tool would
2322 extract the device parameters relevant to device drivers and copy them
2323 into an 'xparameters.h' in the form of #define symbols. This tells the
2324 device drivers how the IP cores are configured, but it requres the kernel
2325 to be recompiled every time the FPGA bitstream is resynthesized.
2327 The new approach is to export the parameters into the device tree and
2328 generate a new device tree each time the FPGA bitstream changes. The
2329 parameters which used to be exported as #defines will now become
2330 properties of the device node. In general, device nodes for IP-cores
2331 will take the following form:
2333 (name): (generic-name)@(base-address) {
2334 compatible = "xlnx,(ip-core-name)-(HW_VER)"
2335 [, (list of compatible devices), ...];
2336 reg = <(baseaddr) (size)>;
2337 interrupt-parent = <&interrupt-controller-phandle>;
2338 interrupts = < ... >;
2339 xlnx,(parameter1) = "(string-value)";
2340 xlnx,(parameter2) = <(int-value)>;
2341 };
2343 (generic-name): an open firmware-style name that describes the
2344 generic class of device. Preferably, this is one word, such
2345 as 'serial' or 'ethernet'.
2346 (ip-core-name): the name of the ip block (given after the BEGIN
2347 directive in system.mhs). Should be in lowercase
2348 and all underscores '_' converted to dashes '-'.
2349 (name): is derived from the "PARAMETER INSTANCE" value.
2350 (parameter#): C_* parameters from system.mhs. The C_ prefix is
2351 dropped from the parameter name, the name is converted
2352 to lowercase and all underscore '_' characters are
2353 converted to dashes '-'.
2354 (baseaddr): the baseaddr parameter value (often named C_BASEADDR).
2355 (HW_VER): from the HW_VER parameter.
2356 (size): the address range size (often C_HIGHADDR - C_BASEADDR + 1).
2358 Typically, the compatible list will include the exact IP core version
2359 followed by an older IP core version which implements the same
2360 interface or any other device with the same interface.
2362 'reg', 'interrupt-parent' and 'interrupts' are all optional properties.
2364 For example, the following block from system.mhs:
2366 BEGIN opb_uartlite
2367 PARAMETER INSTANCE = opb_uartlite_0
2368 PARAMETER HW_VER = 1.00.b
2369 PARAMETER C_BAUDRATE = 115200
2370 PARAMETER C_DATA_BITS = 8
2371 PARAMETER C_ODD_PARITY = 0
2372 PARAMETER C_USE_PARITY = 0
2373 PARAMETER C_CLK_FREQ = 50000000
2374 PARAMETER C_BASEADDR = 0xEC100000
2375 PARAMETER C_HIGHADDR = 0xEC10FFFF
2376 BUS_INTERFACE SOPB = opb_7
2377 PORT OPB_Clk = CLK_50MHz
2378 PORT Interrupt = opb_uartlite_0_Interrupt
2379 PORT RX = opb_uartlite_0_RX
2380 PORT TX = opb_uartlite_0_TX
2381 PORT OPB_Rst = sys_bus_reset_0
2382 END
2384 becomes the following device tree node:
2386 opb_uartlite_0: serial@ec100000 {
2387 device_type = "serial";
2388 compatible = "xlnx,opb-uartlite-1.00.b";
2389 reg = <ec100000 10000>;
2390 interrupt-parent = <&opb_intc_0>;
2391 interrupts = <1 0>; // got this from the opb_intc parameters
2392 current-speed = <d#115200>; // standard serial device prop
2393 clock-frequency = <d#50000000>; // standard serial device prop
2394 xlnx,data-bits = <8>;
2395 xlnx,odd-parity = <0>;
2396 xlnx,use-parity = <0>;
2397 };
2399 Some IP cores actually implement 2 or more logical devices. In
2400 this case, the device should still describe the whole IP core with
2401 a single node and add a child node for each logical device. The
2402 ranges property can be used to translate from parent IP-core to the
2403 registers of each device. In addition, the parent node should be
2404 compatible with the bus type 'xlnx,compound', and should contain
2405 #address-cells and #size-cells, as with any other bus. (Note: this
2406 makes the assumption that both logical devices have the same bus
2407 binding. If this is not true, then separate nodes should be used
2408 for each logical device). The 'cell-index' property can be used to
2409 enumerate logical devices within an IP core. For example, the
2410 following is the system.mhs entry for the dual ps2 controller found
2411 on the ml403 reference design.
2413 BEGIN opb_ps2_dual_ref
2414 PARAMETER INSTANCE = opb_ps2_dual_ref_0
2415 PARAMETER HW_VER = 1.00.a
2416 PARAMETER C_BASEADDR = 0xA9000000
2417 PARAMETER C_HIGHADDR = 0xA9001FFF
2418 BUS_INTERFACE SOPB = opb_v20_0
2419 PORT Sys_Intr1 = ps2_1_intr
2420 PORT Sys_Intr2 = ps2_2_intr
2421 PORT Clkin1 = ps2_clk_rx_1
2422 PORT Clkin2 = ps2_clk_rx_2
2423 PORT Clkpd1 = ps2_clk_tx_1
2424 PORT Clkpd2 = ps2_clk_tx_2
2425 PORT Rx1 = ps2_d_rx_1
2426 PORT Rx2 = ps2_d_rx_2
2427 PORT Txpd1 = ps2_d_tx_1
2428 PORT Txpd2 = ps2_d_tx_2
2429 END
2431 It would result in the following device tree nodes:
2433 opb_ps2_dual_ref_0: opb-ps2-dual-ref@a9000000 {
2434 #address-cells = <1>;
2435 #size-cells = <1>;
2436 compatible = "xlnx,compound";
2437 ranges = <0 a9000000 2000>;
2438 // If this device had extra parameters, then they would
2439 // go here.
2440 ps2@0 {
2441 compatible = "xlnx,opb-ps2-dual-ref-1.00.a";
2442 reg = <0 40>;
2443 interrupt-parent = <&opb_intc_0>;
2444 interrupts = <3 0>;
2445 cell-index = <0>;
2446 };
2447 ps2@1000 {
2448 compatible = "xlnx,opb-ps2-dual-ref-1.00.a";
2449 reg = <1000 40>;
2450 interrupt-parent = <&opb_intc_0>;
2451 interrupts = <3 0>;
2452 cell-index = <0>;
2453 };
2454 };
2456 Also, the system.mhs file defines bus attachments from the processor
2457 to the devices. The device tree structure should reflect the bus
2458 attachments. Again an example; this system.mhs fragment:
2460 BEGIN ppc405_virtex4
2461 PARAMETER INSTANCE = ppc405_0
2462 PARAMETER HW_VER = 1.01.a
2463 BUS_INTERFACE DPLB = plb_v34_0
2464 BUS_INTERFACE IPLB = plb_v34_0
2465 END
2467 BEGIN opb_intc
2468 PARAMETER INSTANCE = opb_intc_0
2469 PARAMETER HW_VER = 1.00.c
2470 PARAMETER C_BASEADDR = 0xD1000FC0
2471 PARAMETER C_HIGHADDR = 0xD1000FDF
2472 BUS_INTERFACE SOPB = opb_v20_0
2473 END
2475 BEGIN opb_uart16550
2476 PARAMETER INSTANCE = opb_uart16550_0
2477 PARAMETER HW_VER = 1.00.d
2478 PARAMETER C_BASEADDR = 0xa0000000
2479 PARAMETER C_HIGHADDR = 0xa0001FFF
2480 BUS_INTERFACE SOPB = opb_v20_0
2481 END
2483 BEGIN plb_v34
2484 PARAMETER INSTANCE = plb_v34_0
2485 PARAMETER HW_VER = 1.02.a
2486 END
2488 BEGIN plb_bram_if_cntlr
2489 PARAMETER INSTANCE = plb_bram_if_cntlr_0
2490 PARAMETER HW_VER = 1.00.b
2491 PARAMETER C_BASEADDR = 0xFFFF0000
2492 PARAMETER C_HIGHADDR = 0xFFFFFFFF
2493 BUS_INTERFACE SPLB = plb_v34_0
2494 END
2496 BEGIN plb2opb_bridge
2497 PARAMETER INSTANCE = plb2opb_bridge_0
2498 PARAMETER HW_VER = 1.01.a
2499 PARAMETER C_RNG0_BASEADDR = 0x20000000
2500 PARAMETER C_RNG0_HIGHADDR = 0x3FFFFFFF
2501 PARAMETER C_RNG1_BASEADDR = 0x60000000
2502 PARAMETER C_RNG1_HIGHADDR = 0x7FFFFFFF
2503 PARAMETER C_RNG2_BASEADDR = 0x80000000
2504 PARAMETER C_RNG2_HIGHADDR = 0xBFFFFFFF
2505 PARAMETER C_RNG3_BASEADDR = 0xC0000000
2506 PARAMETER C_RNG3_HIGHADDR = 0xDFFFFFFF
2507 BUS_INTERFACE SPLB = plb_v34_0
2508 BUS_INTERFACE MOPB = opb_v20_0
2509 END
2511 Gives this device tree (some properties removed for clarity):
2513 plb@0 {
2514 #address-cells = <1>;
2515 #size-cells = <1>;
2516 compatible = "xlnx,plb-v34-1.02.a";
2517 device_type = "ibm,plb";
2518 ranges; // 1:1 translation
2520 plb_bram_if_cntrl_0: bram@ffff0000 {
2521 reg = <ffff0000 10000>;
2522 }
2524 opb@20000000 {
2525 #address-cells = <1>;
2526 #size-cells = <1>;
2527 ranges = <20000000 20000000 20000000
2528 60000000 60000000 20000000
2529 80000000 80000000 40000000
2530 c0000000 c0000000 20000000>;
2532 opb_uart16550_0: serial@a0000000 {
2533 reg = <a00000000 2000>;
2534 };
2536 opb_intc_0: interrupt-controller@d1000fc0 {
2537 reg = <d1000fc0 20>;
2538 };
2539 };
2540 };
2542 That covers the general approach to binding xilinx IP cores into the
2543 device tree. The following are bindings for specific devices:
2545 i) Xilinx ML300 Framebuffer
2547 Simple framebuffer device from the ML300 reference design (also on the
2548 ML403 reference design as well as others).
2550 Optional properties:
2551 - resolution = <xres yres> : pixel resolution of framebuffer. Some
2552 implementations use a different resolution.
2553 Default is <d#640 d#480>
2554 - virt-resolution = <xvirt yvirt> : Size of framebuffer in memory.
2555 Default is <d#1024 d#480>.
2556 - rotate-display (empty) : rotate display 180 degrees.
2558 ii) Xilinx SystemACE
2560 The Xilinx SystemACE device is used to program FPGAs from an FPGA
2561 bitstream stored on a CF card. It can also be used as a generic CF
2562 interface device.
2564 Optional properties:
2565 - 8-bit (empty) : Set this property for SystemACE in 8 bit mode
2567 iii) Xilinx EMAC and Xilinx TEMAC
2569 Xilinx Ethernet devices. In addition to general xilinx properties
2570 listed above, nodes for these devices should include a phy-handle
2571 property, and may include other common network device properties
2572 like local-mac-address.
2574 iv) Xilinx Uartlite
2576 Xilinx uartlite devices are simple fixed speed serial ports.
2578 Requred properties:
2579 - current-speed : Baud rate of uartlite
2581 v) Xilinx hwicap
2583 Xilinx hwicap devices provide access to the configuration logic
2584 of the FPGA through the Internal Configuration Access Port
2585 (ICAP). The ICAP enables partial reconfiguration of the FPGA,
2586 readback of the configuration information, and some control over
2587 'warm boots' of the FPGA fabric.
2589 Required properties:
2590 - xlnx,family : The family of the FPGA, necessary since the
2591 capabilities of the underlying ICAP hardware
2592 differ between different families. May be
2593 'virtex2p', 'virtex4', or 'virtex5'.
2595 p) Freescale Synchronous Serial Interface
2597 The SSI is a serial device that communicates with audio codecs. It can
2598 be programmed in AC97, I2S, left-justified, or right-justified modes.
2600 Required properties:
2601 - compatible : compatible list, containing "fsl,ssi"
2602 - cell-index : the SSI, <0> = SSI1, <1> = SSI2, and so on
2603 - reg : offset and length of the register set for the device
2604 - interrupts : <a b> where a is the interrupt number and b is a
2605 field that represents an encoding of the sense and
2606 level information for the interrupt. This should be
2607 encoded based on the information in section 2)
2608 depending on the type of interrupt controller you
2609 have.
2610 - interrupt-parent : the phandle for the interrupt controller that
2611 services interrupts for this device.
2612 - fsl,mode : the operating mode for the SSI interface
2613 "i2s-slave" - I2S mode, SSI is clock slave
2614 "i2s-master" - I2S mode, SSI is clock master
2615 "lj-slave" - left-justified mode, SSI is clock slave
2616 "lj-master" - l.j. mode, SSI is clock master
2617 "rj-slave" - right-justified mode, SSI is clock slave
2618 "rj-master" - r.j., SSI is clock master
2619 "ac97-slave" - AC97 mode, SSI is clock slave
2620 "ac97-master" - AC97 mode, SSI is clock master
2622 Optional properties:
2623 - codec-handle : phandle to a 'codec' node that defines an audio
2624 codec connected to this SSI. This node is typically
2625 a child of an I2C or other control node.
2627 Child 'codec' node required properties:
2628 - compatible : compatible list, contains the name of the codec
2630 Child 'codec' node optional properties:
2631 - clock-frequency : The frequency of the input clock, which typically
2632 comes from an on-board dedicated oscillator.
2634 * Freescale 83xx DMA Controller
2636 Freescale PowerPC 83xx have on chip general purpose DMA controllers.
2638 Required properties:
2640 - compatible : compatible list, contains 2 entries, first is
2641 "fsl,CHIP-dma", where CHIP is the processor
2642 (mpc8349, mpc8360, etc.) and the second is
2643 "fsl,elo-dma"
2644 - reg : <registers mapping for DMA general status reg>
2645 - ranges : Should be defined as specified in 1) to describe the
2646 DMA controller channels.
2647 - cell-index : controller index. 0 for controller @ 0x8100
2648 - interrupts : <interrupt mapping for DMA IRQ>
2649 - interrupt-parent : optional, if needed for interrupt mapping
2652 - DMA channel nodes:
2653 - compatible : compatible list, contains 2 entries, first is
2654 "fsl,CHIP-dma-channel", where CHIP is the processor
2655 (mpc8349, mpc8350, etc.) and the second is
2656 "fsl,elo-dma-channel"
2657 - reg : <registers mapping for channel>
2658 - cell-index : dma channel index starts at 0.
2660 Optional properties:
2661 - interrupts : <interrupt mapping for DMA channel IRQ>
2662 (on 83xx this is expected to be identical to
2663 the interrupts property of the parent node)
2664 - interrupt-parent : optional, if needed for interrupt mapping
2666 Example:
2667 dma@82a8 {
2668 #address-cells = <1>;
2669 #size-cells = <1>;
2670 compatible = "fsl,mpc8349-dma", "fsl,elo-dma";
2671 reg = <82a8 4>;
2672 ranges = <0 8100 1a4>;
2673 interrupt-parent = <&ipic>;
2674 interrupts = <47 8>;
2675 cell-index = <0>;
2676 dma-channel@0 {
2677 compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
2678 cell-index = <0>;
2679 reg = <0 80>;
2680 };
2681 dma-channel@80 {
2682 compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
2683 cell-index = <1>;
2684 reg = <80 80>;
2685 };
2686 dma-channel@100 {
2687 compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
2688 cell-index = <2>;
2689 reg = <100 80>;
2690 };
2691 dma-channel@180 {
2692 compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
2693 cell-index = <3>;
2694 reg = <180 80>;
2695 };
2696 };
2698 * Freescale 85xx/86xx DMA Controller
2700 Freescale PowerPC 85xx/86xx have on chip general purpose DMA controllers.
2702 Required properties:
2704 - compatible : compatible list, contains 2 entries, first is
2705 "fsl,CHIP-dma", where CHIP is the processor
2706 (mpc8540, mpc8540, etc.) and the second is
2707 "fsl,eloplus-dma"
2708 - reg : <registers mapping for DMA general status reg>
2709 - cell-index : controller index. 0 for controller @ 0x21000,
2710 1 for controller @ 0xc000
2711 - ranges : Should be defined as specified in 1) to describe the
2712 DMA controller channels.
2714 - DMA channel nodes:
2715 - compatible : compatible list, contains 2 entries, first is
2716 "fsl,CHIP-dma-channel", where CHIP is the processor
2717 (mpc8540, mpc8560, etc.) and the second is
2718 "fsl,eloplus-dma-channel"
2719 - cell-index : dma channel index starts at 0.
2720 - reg : <registers mapping for channel>
2721 - interrupts : <interrupt mapping for DMA channel IRQ>
2722 - interrupt-parent : optional, if needed for interrupt mapping
2724 Example:
2725 dma@21300 {
2726 #address-cells = <1>;
2727 #size-cells = <1>;
2728 compatible = "fsl,mpc8540-dma", "fsl,eloplus-dma";
2729 reg = <21300 4>;
2730 ranges = <0 21100 200>;
2731 cell-index = <0>;
2732 dma-channel@0 {
2733 compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
2734 reg = <0 80>;
2735 cell-index = <0>;
2736 interrupt-parent = <&mpic>;
2737 interrupts = <14 2>;
2738 };
2739 dma-channel@80 {
2740 compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
2741 reg = <80 80>;
2742 cell-index = <1>;
2743 interrupt-parent = <&mpic>;
2744 interrupts = <15 2>;
2745 };
2746 dma-channel@100 {
2747 compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
2748 reg = <100 80>;
2749 cell-index = <2>;
2750 interrupt-parent = <&mpic>;
2751 interrupts = <16 2>;
2752 };
2753 dma-channel@180 {
2754 compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
2755 reg = <180 80>;
2756 cell-index = <3>;
2757 interrupt-parent = <&mpic>;
2758 interrupts = <17 2>;
2759 };
2760 };
2762 * Freescale 8xxx/3.0 Gb/s SATA nodes
2764 SATA nodes are defined to describe on-chip Serial ATA controllers.
2765 Each SATA port should have its own node.
2767 Required properties:
2768 - compatible : compatible list, contains 2 entries, first is
2769 "fsl,CHIP-sata", where CHIP is the processor
2770 (mpc8315, mpc8379, etc.) and the second is
2771 "fsl,pq-sata"
2772 - interrupts : <interrupt mapping for SATA IRQ>
2773 - cell-index : controller index.
2774 1 for controller @ 0x18000
2775 2 for controller @ 0x19000
2776 3 for controller @ 0x1a000
2777 4 for controller @ 0x1b000
2779 Optional properties:
2780 - interrupt-parent : optional, if needed for interrupt mapping
2781 - reg : <registers mapping>
2783 Example:
2785 sata@18000 {
2786 compatible = "fsl,mpc8379-sata", "fsl,pq-sata";
2787 reg = <0x18000 0x1000>;
2788 cell-index = <1>;
2789 interrupts = <2c 8>;
2790 interrupt-parent = < &ipic >;
2791 };
2793 q) USB EHCI controllers
2795 Required properties:
2796 - compatible : should be "usb-ehci".
2797 - reg : should contain at least address and length of the standard EHCI
2798 register set for the device. Optional platform-dependent registers
2799 (debug-port or other) can be also specified here, but only after
2800 definition of standard EHCI registers.
2801 - interrupts : one EHCI interrupt should be described here.
2802 If device registers are implemented in big endian mode, the device
2803 node should have "big-endian-regs" property.
2804 If controller implementation operates with big endian descriptors,
2805 "big-endian-desc" property should be specified.
2806 If both big endian registers and descriptors are used by the controller
2807 implementation, "big-endian" property can be specified instead of having
2808 both "big-endian-regs" and "big-endian-desc".
2810 Example (Sequoia 440EPx):
2811 ehci@e0000300 {
2812 compatible = "ibm,usb-ehci-440epx", "usb-ehci";
2813 interrupt-parent = <&UIC0>;
2814 interrupts = <1a 4>;
2815 reg = <0 e0000300 90 0 e0000390 70>;
2816 big-endian;
2817 };
2820 More devices will be defined as this spec matures.
2822 VII - Specifying interrupt information for devices
2823 ===================================================
2825 The device tree represents the busses and devices of a hardware
2826 system in a form similar to the physical bus topology of the
2827 hardware.
2829 In addition, a logical 'interrupt tree' exists which represents the
2830 hierarchy and routing of interrupts in the hardware.
2832 The interrupt tree model is fully described in the
2833 document "Open Firmware Recommended Practice: Interrupt
2834 Mapping Version 0.9". The document is available at:
2835 <http://playground.sun.com/1275/practice>.
2837 1) interrupts property
2838 ----------------------
2840 Devices that generate interrupts to a single interrupt controller
2841 should use the conventional OF representation described in the
2842 OF interrupt mapping documentation.
2844 Each device which generates interrupts must have an 'interrupt'
2845 property. The interrupt property value is an arbitrary number of
2846 of 'interrupt specifier' values which describe the interrupt or
2847 interrupts for the device.
2849 The encoding of an interrupt specifier is determined by the
2850 interrupt domain in which the device is located in the
2851 interrupt tree. The root of an interrupt domain specifies in
2852 its #interrupt-cells property the number of 32-bit cells
2853 required to encode an interrupt specifier. See the OF interrupt
2854 mapping documentation for a detailed description of domains.
2856 For example, the binding for the OpenPIC interrupt controller
2857 specifies an #interrupt-cells value of 2 to encode the interrupt
2858 number and level/sense information. All interrupt children in an
2859 OpenPIC interrupt domain use 2 cells per interrupt in their interrupts
2860 property.
2862 The PCI bus binding specifies a #interrupt-cell value of 1 to encode
2863 which interrupt pin (INTA,INTB,INTC,INTD) is used.
2865 2) interrupt-parent property
2866 ----------------------------
2868 The interrupt-parent property is specified to define an explicit
2869 link between a device node and its interrupt parent in
2870 the interrupt tree. The value of interrupt-parent is the
2871 phandle of the parent node.
2873 If the interrupt-parent property is not defined for a node, it's
2874 interrupt parent is assumed to be an ancestor in the node's
2875 _device tree_ hierarchy.
2877 3) OpenPIC Interrupt Controllers
2878 --------------------------------
2880 OpenPIC interrupt controllers require 2 cells to encode
2881 interrupt information. The first cell defines the interrupt
2882 number. The second cell defines the sense and level
2883 information.
2885 Sense and level information should be encoded as follows:
2887 0 = low to high edge sensitive type enabled
2888 1 = active low level sensitive type enabled
2889 2 = active high level sensitive type enabled
2890 3 = high to low edge sensitive type enabled
2892 4) ISA Interrupt Controllers
2893 ----------------------------
2895 ISA PIC interrupt controllers require 2 cells to encode
2896 interrupt information. The first cell defines the interrupt
2897 number. The second cell defines the sense and level
2898 information.
2900 ISA PIC interrupt controllers should adhere to the ISA PIC
2901 encodings listed below:
2903 0 = active low level sensitive type enabled
2904 1 = active high level sensitive type enabled
2905 2 = high to low edge sensitive type enabled
2906 3 = low to high edge sensitive type enabled
2909 Appendix A - Sample SOC node for MPC8540
2910 ========================================
2912 Note that the #address-cells and #size-cells for the SoC node
2913 in this example have been explicitly listed; these are likely
2914 not necessary as they are usually the same as the root node.
2916 soc8540@e0000000 {
2917 #address-cells = <1>;
2918 #size-cells = <1>;
2919 #interrupt-cells = <2>;
2920 device_type = "soc";
2921 ranges = <00000000 e0000000 00100000>
2922 reg = <e0000000 00003000>;
2923 bus-frequency = <0>;
2925 mdio@24520 {
2926 reg = <24520 20>;
2927 device_type = "mdio";
2928 compatible = "gianfar";
2930 ethernet-phy@0 {
2931 linux,phandle = <2452000>
2932 interrupt-parent = <40000>;
2933 interrupts = <35 1>;
2934 reg = <0>;
2935 device_type = "ethernet-phy";
2936 };
2938 ethernet-phy@1 {
2939 linux,phandle = <2452001>
2940 interrupt-parent = <40000>;
2941 interrupts = <35 1>;
2942 reg = <1>;
2943 device_type = "ethernet-phy";
2944 };
2946 ethernet-phy@3 {
2947 linux,phandle = <2452002>
2948 interrupt-parent = <40000>;
2949 interrupts = <35 1>;
2950 reg = <3>;
2951 device_type = "ethernet-phy";
2952 };
2954 };
2956 ethernet@24000 {
2957 #size-cells = <0>;
2958 device_type = "network";
2959 model = "TSEC";
2960 compatible = "gianfar";
2961 reg = <24000 1000>;
2962 mac-address = [ 00 E0 0C 00 73 00 ];
2963 interrupts = <d 3 e 3 12 3>;
2964 interrupt-parent = <40000>;
2965 phy-handle = <2452000>;
2966 };
2968 ethernet@25000 {
2969 #address-cells = <1>;
2970 #size-cells = <0>;
2971 device_type = "network";
2972 model = "TSEC";
2973 compatible = "gianfar";
2974 reg = <25000 1000>;
2975 mac-address = [ 00 E0 0C 00 73 01 ];
2976 interrupts = <13 3 14 3 18 3>;
2977 interrupt-parent = <40000>;
2978 phy-handle = <2452001>;
2979 };
2981 ethernet@26000 {
2982 #address-cells = <1>;
2983 #size-cells = <0>;
2984 device_type = "network";
2985 model = "FEC";
2986 compatible = "gianfar";
2987 reg = <26000 1000>;
2988 mac-address = [ 00 E0 0C 00 73 02 ];
2989 interrupts = <19 3>;
2990 interrupt-parent = <40000>;
2991 phy-handle = <2452002>;
2992 };
2994 serial@4500 {
2995 device_type = "serial";
2996 compatible = "ns16550";
2997 reg = <4500 100>;
2998 clock-frequency = <0>;
2999 interrupts = <1a 3>;
3000 interrupt-parent = <40000>;
3001 };
3003 pic@40000 {
3004 linux,phandle = <40000>;
3005 clock-frequency = <0>;
3006 interrupt-controller;
3007 #address-cells = <0>;
3008 reg = <40000 40000>;
3009 built-in;
3010 compatible = "chrp,open-pic";
3011 device_type = "open-pic";
3012 big-endian;
3013 };
3015 i2c@3000 {
3016 interrupt-parent = <40000>;
3017 interrupts = <1b 3>;
3018 reg = <3000 18>;
3019 device_type = "i2c";
3020 compatible = "fsl-i2c";
3021 dfsrr;
3022 };
3024 };