Lines Matching refs:tree
11 Traditionally U-Boot has used a 'flat' device tree. This means that it
12 reads directly from the device tree binary structure. It is called a flat
13 device tree because nodes are listed one after the other, with the
16 This document describes U-Boot's support for a 'live' device tree, meaning
17 that the tree is loaded into a hierarchical data structure within U-Boot.
23 The flat device tree has several advantages:
25 - it is the format produced by the device tree compiler, so no translation
33 However the flat device tree does have some limitations. Adding new
35 The overall tree has a fixed maximum size so sometimes the tree must be
37 properties or nodes, scanning the tree can be slow. For example, finding
41 Driver model scans the entire device tree sequentially on start-up which
42 avoids the worst of the flat tree's limitations. But if the tree is to be
43 modified at run-time, a live tree is much faster. Even if no modification
44 is necessary, parsing the tree once and using a live tree from then on
51 In U-Boot a live device tree ('livetree') is currently supported only
53 tree node regardless of whether it is in the flat tree or livetree.
55 The 'ofnode' type provides this. An ofnode can point to either a flat tree
56 node (when the live tree node is not yet set up) or a livetree node. The
59 The main users of the information in a device tree are drivers. These have
60 a 'struct udevice \*' which is attached to a device tree node. Therefore it
61 makes sense to be able to read device tree properties using the
65 easily read from the device tree using only a device pointer. Under the
73 tree will be used in SPL and before relocation in U-Boot proper. Just
85 Many existing drivers use the fdtdec interface to read device tree
86 properties. This only works with a flat device tree. The drivers should be
142 :struct device_node: holds information about a device tree node
147 tree.
155 code to work with a flat tree also.
159 For example it is invalid to call ofnode_to_no() when a flat tree is being
177 returns true if livetree is in use, false if flat tree
191 There is full phandle support for live tree. All functions make use of
193 livetree and flat tree transparently. See for example
200 You should use dev_read_addr() and friends to read addresses from device-tree
218 allocated for the whole tree. When writing new properties, these are
224 freed. Then the tree can be scanned for these 'separately allocated' nodes and
227 The ofnode_write\_...() functions also support writing to the flat tree. Care
229 properties in the flat tree, thus affecting the live tree. Generally this does
230 not matter, since when we fire up the live tree we don't ever use the flat tree
234 tree either present or absent. This is to make sure that the flat tree functions
236 device tree, then the live tree can become invalid. Any live tree tests that run
237 after that point will use a corrupted tree, e.g. with an incorrect property name
238 or worse. To deal with this we take a copy of the device tree and restore it
248 a flat tree.
259 causes a flat device tree to be 'registered' such that it can be used by the
270 is disabled, just falling back to flat tree code.
290 With a flat device tree, libfdt errors are returned (e.g. -FDT_ERR_NOTFOUND).
300 Adding a new function for device-tree access involves the following steps:
311 whether a livetree or flat tree is used. For the livetree it should
312 call an of\_...() function. For the flat tree it should call an
324 Live tree support was introduced in U-Boot 2017.07. Some possible enhancements