blob: c29f29b205b379f082d4728fffd0f6adc8b82490 [file] [log] [blame]
Bin Meng5a593472019-07-18 00:33:54 -07001.. SPDX-License-Identifier: GPL-2.0+
2.. sectionauthor:: Simon Glass <sjg@chromium.org>
Simon Glassa7e7e082017-08-31 05:59:55 -06003
Bin Meng5a593472019-07-18 00:33:54 -07004Live Device Tree
5================
6
Simon Glassa7e7e082017-08-31 05:59:55 -06007
8Introduction
9------------
10
11Traditionally U-Boot has used a 'flat' device tree. This means that it
12reads directly from the device tree binary structure. It is called a flat
13device tree because nodes are listed one after the other, with the
14hierarchy detected by tags in the format.
15
16This document describes U-Boot's support for a 'live' device tree, meaning
17that the tree is loaded into a hierarchical data structure within U-Boot.
18
19
20Motivation
21----------
22
23The flat device tree has several advantages:
24
25- it is the format produced by the device tree compiler, so no translation
Bin Meng5a593472019-07-18 00:33:54 -070026 is needed
Simon Glassa7e7e082017-08-31 05:59:55 -060027
28- it is fairly compact (e.g. there is no need for pointers)
29
30- it is accessed by the libfdt library, which is well tested and stable
31
32
33However the flat device tree does have some limitations. Adding new
34properties can involve copying large amounts of data around to make room.
35The overall tree has a fixed maximum size so sometimes the tree must be
36rebuilt in a new location to create more space. Even if not adding new
37properties or nodes, scanning the tree can be slow. For example, finding
38the parent of a node is a slow process. Reading from nodes involves a
39small amount parsing which takes a little time.
40
41Driver model scans the entire device tree sequentially on start-up which
42avoids the worst of the flat tree's limitations. But if the tree is to be
43modified at run-time, a live tree is much faster. Even if no modification
44is necessary, parsing the tree once and using a live tree from then on
45seems to save a little time.
46
47
48Implementation
49--------------
50
51In U-Boot a live device tree ('livetree') is currently supported only
52after relocation. Therefore we need a mechanism to specify a device
53tree node regardless of whether it is in the flat tree or livetree.
54
55The 'ofnode' type provides this. An ofnode can point to either a flat tree
56node (when the live tree node is not yet set up) or a livetree node. The
57caller of an ofnode function does not need to worry about these details.
58
Bin Meng5a593472019-07-18 00:33:54 -070059The main users of the information in a device tree are drivers. These have
60a 'struct udevice \*' which is attached to a device tree node. Therefore it
Simon Glassa7e7e082017-08-31 05:59:55 -060061makes sense to be able to read device tree properties using the
Bin Meng5a593472019-07-18 00:33:54 -070062'struct udevice \*', rather than having to obtain the ofnode first.
Simon Glassa7e7e082017-08-31 05:59:55 -060063
Bin Meng5a593472019-07-18 00:33:54 -070064The 'dev_read\_...()' interface provides this. It allows properties to be
Simon Glassa7e7e082017-08-31 05:59:55 -060065easily read from the device tree using only a device pointer. Under the
66hood it uses ofnode so it works with both flat and live device trees.
67
68
69Enabling livetree
70-----------------
71
72CONFIG_OF_LIVE enables livetree. When this option is enabled, the flat
73tree will be used in SPL and before relocation in U-Boot proper. Just
74before relocation a livetree is built, and this is used for U-Boot proper
75after relocation.
76
77Most checks for livetree use CONFIG_IS_ENABLED(OF_LIVE). This means that
78for SPL, the CONFIG_SPL_OF_LIVE option is checked. At present this does
79not exist, since SPL does not support livetree.
80
81
82Porting drivers
83---------------
84
85Many existing drivers use the fdtdec interface to read device tree
86properties. This only works with a flat device tree. The drivers should be
87converted to use the dev_read_() interface.
88
89For example, the old code may be like this:
90
Bin Meng5a593472019-07-18 00:33:54 -070091.. code-block:: c
92
Simon Glassa7e7e082017-08-31 05:59:55 -060093 struct udevice *bus;
94 const void *blob = gd->fdt_blob;
95 int node = dev_of_offset(bus);
96
97 i2c_bus->regs = (struct i2c_ctlr *)devfdt_get_addr(dev);
98 plat->frequency = fdtdec_get_int(blob, node, "spi-max-frequency", 500000);
99
100The new code is:
101
Bin Meng5a593472019-07-18 00:33:54 -0700102.. code-block:: c
103
Simon Glassa7e7e082017-08-31 05:59:55 -0600104 struct udevice *bus;
105
106 i2c_bus->regs = (struct i2c_ctlr *)dev_read_addr(dev);
107 plat->frequency = dev_read_u32_default(bus, "spi-max-frequency", 500000);
108
Bin Meng5a593472019-07-18 00:33:54 -0700109The dev_read\_...() interface is more convenient and works with both the
Simon Glassa7e7e082017-08-31 05:59:55 -0600110flat and live device trees. See include/dm/read.h for a list of functions.
111
112Where properties must be read from sub-nodes or other nodes, you must fall
113back to using ofnode. For example, for old code like this:
114
Bin Meng5a593472019-07-18 00:33:54 -0700115.. code-block:: c
116
Simon Glassa7e7e082017-08-31 05:59:55 -0600117 const void *blob = gd->fdt_blob;
118 int subnode;
119
120 fdt_for_each_subnode(subnode, blob, dev_of_offset(dev)) {
121 freq = fdtdec_get_int(blob, node, "spi-max-frequency", 500000);
122 ...
123 }
124
125you should use:
126
Bin Meng5a593472019-07-18 00:33:54 -0700127.. code-block:: c
128
Simon Glassa7e7e082017-08-31 05:59:55 -0600129 ofnode subnode;
130
131 ofnode_for_each_subnode(subnode, dev_ofnode(dev)) {
132 freq = ofnode_read_u32(node, "spi-max-frequency", 500000);
133 ...
134 }
135
136
137Useful ofnode functions
138-----------------------
139
140The internal data structures of the livetree are defined in include/dm/of.h :
141
Bin Meng5a593472019-07-18 00:33:54 -0700142 :struct device_node: holds information about a device tree node
143 :struct property: holds information about a property within a node
Simon Glassa7e7e082017-08-31 05:59:55 -0600144
145Nodes have pointers to their first property, their parent, their first child
146and their sibling. This allows nodes to be linked together in a hierarchical
147tree.
148
149Properties have pointers to the next property. This allows all properties of
150a node to be linked together in a chain.
151
152It should not be necessary to use these data structures in normal code. In
153particular, you should refrain from using functions which access the livetree
154directly, such as of_read_u32(). Use ofnode functions instead, to allow your
155code to work with a flat tree also.
156
157Some conversion functions are used internally. Generally these are not needed
158for driver code. Note that they will not work if called in the wrong context.
159For example it is invalid to call ofnode_to_no() when a flat tree is being
160used. Similarly it is not possible to call ofnode_to_offset() on a livetree
161node.
162
Bin Meng5a593472019-07-18 00:33:54 -0700163ofnode_to_np():
164 converts ofnode to struct device_node *
165ofnode_to_offset():
166 converts ofnode to offset
Simon Glassa7e7e082017-08-31 05:59:55 -0600167
Bin Meng5a593472019-07-18 00:33:54 -0700168no_to_ofnode():
169 converts node pointer to ofnode
170offset_to_ofnode():
171 converts offset to ofnode
Simon Glassa7e7e082017-08-31 05:59:55 -0600172
173
174Other useful functions:
175
Bin Meng5a593472019-07-18 00:33:54 -0700176of_live_active():
177 returns true if livetree is in use, false if flat tree
178ofnode_valid():
179 return true if a given node is valid
180ofnode_is_np():
181 returns true if a given node is a livetree node
182ofnode_equal():
183 compares two ofnodes
184ofnode_null():
185 returns a null ofnode (for which ofnode_valid() returns false)
Simon Glassa7e7e082017-08-31 05:59:55 -0600186
187
188Phandles
189--------
190
191There is full phandle support for live tree. All functions make use of
192struct ofnode_phandle_args, which has an ofnode within it. This supports both
193livetree and flat tree transparently. See for example
194ofnode_parse_phandle_with_args().
195
196
197Reading addresses
198-----------------
199
200You should use dev_read_addr() and friends to read addresses from device-tree
201nodes.
202
203
204fdtdec
205------
206
207The existing fdtdec interface will eventually be retired. Please try to avoid
208using it in new code.
209
210
211Modifying the livetree
212----------------------
213
Simon Glass1817f712022-07-30 15:52:07 -0600214This is supported in a limited way, with ofnode_write_prop() and related
215functions.
Simon Glassa7e7e082017-08-31 05:59:55 -0600216
Simon Glass1817f712022-07-30 15:52:07 -0600217The unflattening algorithm results in a single block of memory being
218allocated for the whole tree. When writing new properties, these are
219allocated new memory outside that block. When the block is freed, the
220allocated properties remain. This can result in a memory leak.
221
222The solution to this leak would be to add a flag for properties (and nodes when
223support is provided for adding those) that indicates that they should be
224freed. Then the tree can be scanned for these 'separately allocated' nodes and
225properties before freeing the memory block.
226
Simon Glassa7e7e082017-08-31 05:59:55 -0600227
Simon Glassef75c592022-07-30 15:52:08 -0600228Multiple livetrees
229------------------
230
231The livetree implementation was originally designed for use with the control
232FDT. This means that the FDT fix-ups (ft_board_setup() and the like, must use
233a flat tree.
234
235It would be helpful to use livetree for fixups, since adding a lot of nodes and
236properties would involve less memory copying and be more efficient. As a step
237towards this, an `oftree` type has been introduced. It is normally set to
238oftree_default() but can be set to other values. Eventually this should allow
239the use of FDT fixups using the ofnode interface, instead of the low-level
240libfdt one.
241
242See dm_test_ofnode_root() for some examples.
243
244
Simon Glassa7e7e082017-08-31 05:59:55 -0600245Internal implementation
246-----------------------
247
Bin Meng5a593472019-07-18 00:33:54 -0700248The dev_read\_...() functions have two implementations. When
Simon Glassa7e7e082017-08-31 05:59:55 -0600249CONFIG_DM_DEV_READ_INLINE is enabled, these functions simply call the ofnode
250functions directly. This is useful when livetree is not enabled. The ofnode
251functions call ofnode_is_np(node) which will always return false if livetree
252is disabled, just falling back to flat tree code.
253
Bin Meng5a593472019-07-18 00:33:54 -0700254This optimisation means that without livetree enabled, the dev_read\_...() and
Simon Glassa7e7e082017-08-31 05:59:55 -0600255ofnode interfaces do not noticeably add to code size.
256
257The CONFIG_DM_DEV_READ_INLINE option defaults to enabled when livetree is
258disabled.
259
260Most livetree code comes directly from Linux and is modified as little as
261possible. This is deliberate since this code is fairly stable and does what
262we want. Some features (such as get/put) are not supported. Internal macros
263take care of removing these features silently.
264
265Within the of_access.c file there are pointers to the alias node, the chosen
266node and the stdout-path alias.
267
268
269Errors
270------
271
272With a flat device tree, libfdt errors are returned (e.g. -FDT_ERR_NOTFOUND).
273For livetree normal 'errno' errors are returned (e.g. -ENOTFOUND). At present
Bin Meng5a593472019-07-18 00:33:54 -0700274the ofnode and dev_read\_...() functions return either one or other type of
Simon Glassa7e7e082017-08-31 05:59:55 -0600275error. This is clearly not desirable. Once tests are added for all the
276functions this can be tidied up.
277
278
279Adding new access functions
280---------------------------
281
282Adding a new function for device-tree access involves the following steps:
283
284 - Add two dev_read() functions:
Bin Meng5a593472019-07-18 00:33:54 -0700285 - inline version in the read.h header file, which calls an ofnode function
286 - standard version in the read.c file (or perhaps another file), which
287 also calls an ofnode function
Simon Glassa7e7e082017-08-31 05:59:55 -0600288
Bin Meng5a593472019-07-18 00:33:54 -0700289 The implementations of these functions can be the same. The purpose
290 of the inline version is purely to reduce code size impact.
Simon Glassa7e7e082017-08-31 05:59:55 -0600291
292 - Add an ofnode function. This should call ofnode_is_np() to work out
Bin Meng5a593472019-07-18 00:33:54 -0700293 whether a livetree or flat tree is used. For the livetree it should
294 call an of\_...() function. For the flat tree it should call an
295 fdt\_...() function. The livetree version will be optimised out at
296 compile time if livetree is not enabled.
Simon Glassa7e7e082017-08-31 05:59:55 -0600297
Bin Meng5a593472019-07-18 00:33:54 -0700298 - Add an of\_...() function for the livetree implementation. If a similar
299 function is available in Linux, the implementation should be taken
300 from there and modified as little as possible (generally not at all).
Simon Glassa7e7e082017-08-31 05:59:55 -0600301
302
303Future work
304-----------
305
306Live tree support was introduced in U-Boot 2017.07. There is still quite a bit
307of work to do to flesh this out:
308
309- tests for all access functions
Simon Glass1817f712022-07-30 15:52:07 -0600310- more support for livetree modification
Simon Glassa7e7e082017-08-31 05:59:55 -0600311- addition of more access functions as needed
312- support for livetree in SPL and before relocation (if desired)