Lines Matching defs:of
28 \newcommand{\of}{Open Firmware\xspace}
31 \newcommand{\dtbeginnode}{\texttt{OF\_DT\_BEGIN\_NODE\xspace}}
32 \newcommand{\dtendnode}{\texttt{OF\_DT\_END\_NODE\xspace}}
33 \newcommand{\dtprop}{\texttt{OF\_DT\_PROP\xspace}}
34 \newcommand{\dtend}{\texttt{OF\_DT\_END\xspace}}
44 flattened-tree representation of the system's hardware based on the
50 representation of the tree into the compact representation used by
55 This flattened-tree approach is now the only supported method of
63 \subsection{OF and the device tree}
65 Historically, ``everyday'' \ppc machines have booted with the help of
66 \of (OF), a firmware environment defined by IEEE1275 \cite{IEEE1275}.
67 Among other boot-time services, OF maintains a device tree that
68 describes all of the system's hardware devices and how they're
69 connected. During boot, before taking control of memory management,
70 the Linux kernel uses OF calls to scan the device tree and transfer it
74 The device tree consists of nodes representing devices or
84 might supply a few vital system parameters (size of RAM and the like),
85 but nothing as detailed or complete as the OF device tree. This has
87 variety of hacks spread across the kernel to deal with the lack of
91 hardcoded addresses for a particular board. As well as being ugly of
95 Until relatively recently, the only 64-bit \ppc machines without OF
98 around the lack of a device tree. Even so, the lack means the iSeries
103 the kernel boots, it takes over full control of the system from OF,
104 even re-using OF's memory. So, when \kexec comes to boot another
105 kernel, OF is no longer around for the second kernel to query.
110 tree that addresses all these problems. When booting on OF systems,
111 the first thing the kernel runs is a small piece of code in
112 \texttt{prom\_init.c}, which executes in the context of OF. This code
113 walks the device tree using OF calls, and transcribes it into a
117 \texttt{prom\_init.c} bootstrap and the rest of the kernel.
119 When OF isn't available, either because the machine doesn't have it at
123 by part of the kernel from OF. For \kexec, the userland
127 version of the \texttt{zImage} wrapper for the system in question.
129 \subsection{Properties of the flattened tree}
144 practice this means limiting the use of internal offsets in the blob
147 \item \emph{compact}: embedded systems are frequently short of
152 \subsection{Format of the device tree blob}
206 included as part of the \dtc (see \S\ref{sec:dtc}) git tree,
209 Figure \ref{fig:blob-layout} shows the layout of the blob of data
210 containing the device tree. It has three sections of variable size:
213 version and the locations of the three sections, plus a handful of
216 The memory reserve map section gives a list of regions of memory that
219 kernel.}. The list is represented as a simple array of (address,
220 size) pairs of 64 bit values, terminated by a zero size entry. The
221 strings block is similarly simple, consisting of a number of
228 follows all of the properties of the node, each introduced with a
229 \dtprop tag, then all of the node's subnodes, each introduced with
232 the end of the whole tree\footnote{This is redundant, but included for
233 ease of parsing.}. The structure block starts with the \dtbeginnode
234 introducing the description of the root node (named \texttt{/}).
237 from the beginning of the strings block at which the property name is
240 of the blob. The name offset is followed by the length of the
244 \subsection{Contents of the tree}
249 same as an OF tree''. On OF systems, the flattened tree is
250 transcribed directly from the OF device tree, so for simplicity we
251 also use OF conventions for the tree on other systems.
253 In many cases a flat tree can be simpler than a typical OF provided
257 For example, an OF device tree would normally include nodes for each
272 with the general conventions of IEEE1275 (a simple such binding for a
273 System-on-Chip bus was included in \cite{noof5} a revision of
277 tree. In OF, each node in the tree has an associated phandle, a
279 usually implemented as a pointer or offset within OF memory.}. This
280 handle is used by the various OF calls to query and traverse the tree.
284 phandle of the interrupt controller that handles interrupts from this
286 the kernel to build a complete representation of the system's
287 interrupt tree, which can be quite different from the tree of bus
292 OF, it adds a \phandle property to each node, containing the phandle
293 retrieved from OF. When the tree is generated without OF, however,
297 Another complication arises because nodes in an OF tree have two
299 referred to in an OF path. The unit name generally consists of a
301 address}. For example \texttt{/memory@0} is the full path of a memory
302 node at address 0, \texttt{/ht@0,f2000000/pci@1} is the path of a PCI
303 bus node, which is under a HyperTransport\tm bus node. The form of
306 \texttt{name}, whose value is usually equal to the first path of the
309 respectively. To save space in the blob, the current version of the
372 way of communicating device tree information to the kernel. It's
374 manipulate. On OF systems, it's easy to generate the flattened tree
375 by walking the OF maintained tree. However, for embedded systems, the
380 and include it in the bootloader image. For minor revisions of the
388 tree blobs easier by converting a text representation of the tree
393 As well as the normal mode of compiling a device tree blob from text
394 source, \dtc can convert a device tree between a number of
395 representations. It can take its input in one of three different
404 layout of \texttt{/proc/device-tree} (roughly, a directory for each
410 In addition, \dtc can output the tree in one of three different
414 straightforward use of \dtc is to compile from ``source'' to
420 device tree blob, with symbols giving the beginning of the blob and
425 For maximum applicability, \dtc can both read and write any of the
426 existing revisions of the blob format. When reading, \dtc takes the
438 The ``source'' format for \dtc is a text description of the device
444 Nodes of the tree are introduced with the node name, followed by a
448 of three forms:
454 property value is made up of a list of 32-bit ``cells'', each given
460 Cell properties can also contain \emph{references}. Instead of a hex
466 output tree, the value of the referenced node's phandle is included in
475 label ``\texttt{memreg}'' on the \texttt{reg} property of the node
478 addressing the part of the blob with the node or property in question.
481 the size of memory. The bootloader for such a board can have a device
489 format, \dtc performs a number of checks on the tree:
517 boot a \texttt{ppc64} kernel on an embedded system. With the merge of
528 While it is already quite usable, there are a number of extra features
532 number of checks on the device tree, they are rather haphazard. In
540 tree to incorporate as a property a block of binary data for some
541 board-specific purpose. For example, many of Apple's device trees
546 sort of macros so that a tree containing a number of similar devices
559 David Gibson has been a member of the IBM Linux Technology Center,
575 among others things. He's a member of the ppc64 development ``team''
576 and one of his current goals is to make the integration of embedded
582 This work represents the view of the author and does not necessarily
583 represent the view of IBM.
586 trademarks or registered trademarks of International Business Machines
589 Apple and Power Macintosh are a registered trademarks of Apple
592 Linux is a registered trademark of Linus Torvalds.
595 marks of others.
