1 .. SPDX-License-Identifier: GPL-2.0+
3 Compiled-in Device Tree / Platform Data
4 =======================================
10 Device tree is the standard configuration method in U-Boot. It is used to
11 define what devices are in the system and provide configuration information
14 The overhead of adding device tree access to U-Boot is fairly modest,
15 approximately 3KB on Thumb 2 (plus the size of the DT itself). This means
16 that in most cases it is best to use device tree for configuration.
18 However there are some very constrained environments where U-Boot needs to
19 work. These include SPL with severe memory limitations. For example, some
20 SoCs require a 16KB SPL image which must include a full MMC stack. In this
21 case the overhead of device tree access may be too great.
23 It is possible to create platform data manually by defining C structures
24 for it, and reference that data in a U_BOOT_DEVICE() declaration. This
25 bypasses the use of device tree completely, effectively creating a parallel
26 configuration mechanism. But it is an available option for SPL.
28 As an alternative, a new 'of-platdata' feature is provided. This converts the
29 device tree contents into C code which can be compiled into the SPL binary.
30 This saves the 3KB of code overhead and perhaps a few hundred more bytes due
31 to more efficient storage of the data.
33 Note: Quite a bit of thought has gone into the design of this feature.
34 However it still has many rough edges and comments and suggestions are
35 strongly encouraged! Quite possibly there is a much better approach.
41 There are many problems with this features. It should only be used when
42 strictly necessary. Notable problems include:
44 - Device tree does not describe data types. But the C code must define a
45 type for each property. These are guessed using heuristics which
46 are wrong in several fairly common cases. For example an 8-byte value
47 is considered to be a 2-item integer array, and is byte-swapped. A
48 boolean value that is not present means 'false', but cannot be
49 included in the structures since there is generally no mention of it
50 in the device tree file.
52 - Naming of nodes and properties is automatic. This means that they follow
53 the naming in the device tree, which may result in C identifiers that
56 - It is not possible to find a value given a property name. Code must use
57 the associated C member variable directly in the code. This makes
58 the code less robust in the face of device-tree changes. It also
59 makes it very unlikely that your driver code will be useful for more
60 than one SoC. Even if the code is common, each SoC will end up with
61 a different C struct name, and a likely a different format for the
64 - The platform data is provided to drivers as a C structure. The driver
65 must use the same structure to access the data. Since a driver
66 normally also supports device tree it must use #ifdef to separate
67 out this code, since the structures are only available in SPL.
69 - Correct relations between nodes are not implemented. This means that
70 parent/child relations (like bus device iteration) do not work yet.
71 Some phandles (those that are recognised as such) are converted into
72 a pointer to struct driver_info. This pointer can be used to access
73 the referenced device.
79 The feature is enabled by CONFIG OF_PLATDATA. This is only available in
80 SPL/TPL and should be tested with:
84 #if CONFIG_IS_ENABLED(OF_PLATDATA)
86 A new tool called 'dtoc' converts a device tree file either into a set of
87 struct declarations, one for each compatible node, and a set of
88 U_BOOT_DEVICE() declarations along with the actual platform data for each
89 device. As an example, consider this MMC node:
93 sdmmc: dwmmc@ff0c0000 {
94 compatible = "rockchip,rk3288-dw-mshc";
95 clock-freq-min-max = <400000 150000000>;
96 clocks = <&cru HCLK_SDMMC>, <&cru SCLK_SDMMC>,
97 <&cru SCLK_SDMMC_DRV>, <&cru SCLK_SDMMC_SAMPLE>;
98 clock-names = "biu", "ciu", "ciu_drv", "ciu_sample";
100 interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
101 reg = <0xff0c0000 0x4000>;
105 card-detect-delay = <200>;
108 pinctrl-names = "default";
109 pinctrl-0 = <&sdmmc_clk>, <&sdmmc_cmd>, <&sdmmc_cd>, <&sdmmc_bus4>;
110 vmmc-supply = <&vcc_sd>;
116 Some of these properties are dropped by U-Boot under control of the
117 CONFIG_OF_SPL_REMOVE_PROPS option. The rest are processed. This will produce
118 the following C struct declaration:
122 struct dtd_rockchip_rk3288_dw_mshc {
124 bool cap_mmc_highspeed;
125 bool cap_sd_highspeed;
126 fdt32_t card_detect_delay;
127 fdt32_t clock_freq_min_max[2];
128 struct phandle_1_arg clocks[4];
131 fdt32_t interrupts[3];
137 and the following device declaration:
141 static struct dtd_rockchip_rk3288_dw_mshc dtv_dwmmc_at_ff0c0000 = {
143 .cap_sd_highspeed = true,
144 .interrupts = {0x0, 0x20, 0x4},
145 .clock_freq_min_max = {0x61a80, 0x8f0d180},
148 .clocks = {{NULL, 456},
152 .cap_mmc_highspeed = true,
155 .u_boot_dm_pre_reloc = true,
156 .reg = {0xff0c0000, 0x4000},
157 .card_detect_delay = 0xc8,
160 U_BOOT_DEVICE(dwmmc_at_ff0c0000) = {
161 .name = "rockchip_rk3288_dw_mshc",
162 .platdata = &dtv_dwmmc_at_ff0c0000,
163 .platdata_size = sizeof(dtv_dwmmc_at_ff0c0000),
166 void dm_populate_phandle_data(void) {
167 dtv_dwmmc_at_ff0c0000.clocks[0].node = DM_GET_DEVICE(clock_controller_at_ff760000);
168 dtv_dwmmc_at_ff0c0000.clocks[1].node = DM_GET_DEVICE(clock_controller_at_ff760000);
169 dtv_dwmmc_at_ff0c0000.clocks[2].node = DM_GET_DEVICE(clock_controller_at_ff760000);
170 dtv_dwmmc_at_ff0c0000.clocks[3].node = DM_GET_DEVICE(clock_controller_at_ff760000);
173 The device is then instantiated at run-time and the platform data can be
179 struct dtd_rockchip_rk3288_dw_mshc *plat = dev_get_platdata(dev);
181 This avoids the code overhead of converting the device tree data to
182 platform data in the driver. The ofdata_to_platdata() method should
183 therefore do nothing in such a driver.
185 Note that for the platform data to be matched with a driver, the 'name'
186 property of the U_BOOT_DEVICE() declaration has to match a driver declared
187 via U_BOOT_DRIVER(). This effectively means that a U_BOOT_DRIVER() with a
188 'name' corresponding to the devicetree 'compatible' string (after converting
189 it to a valid name for C) is needed, so a dedicated driver is required for
190 each 'compatible' string.
192 In order to make this a bit more flexible U_BOOT_DRIVER_ALIAS macro can be
193 used to declare an alias for a driver name, typically a 'compatible' string.
194 This macro produces no code, but it is by dtoc tool.
196 During the build process dtoc parses both U_BOOT_DRIVER and U_BOOT_DRIVER_ALIAS
197 to build a list of valid driver names and driver aliases. If the 'compatible'
198 string used for a device does not not match a valid driver name, it will be
199 checked against the list of driver aliases in order to get the right driver
200 name to use. If in this step there is no match found a warning is issued to
201 avoid run-time failures.
203 Where a node has multiple compatible strings, a #define is used to make them
208 #define dtd_rockchip_rk3299_dw_mshc dtd_rockchip_rk3288_dw_mshc
211 Converting of-platdata to a useful form
212 ---------------------------------------
214 Of course it would be possible to use the of-platdata directly in your driver
215 whenever configuration information is required. However this means that the
216 driver will not be able to support device tree, since the of-platdata
217 structure is not available when device tree is used. It would make no sense
218 to use this structure if device tree were available, since the structure has
219 all the limitations metioned in caveats above.
221 Therefore it is recommended that the of-platdata structure should be used
222 only in the probe() method of your driver. It cannot be used in the
223 ofdata_to_platdata() method since this is not called when platform data is
227 How to structure your driver
228 ----------------------------
230 Drivers should always support device tree as an option. The of-platdata
231 feature is intended as a add-on to existing drivers.
233 Your driver should convert the platdata struct in its probe() method. The
234 existing device tree decoding logic should be kept in the
235 ofdata_to_platdata() method and wrapped with #if.
241 #include <dt-structs.h>
243 struct mmc_platdata {
244 #if CONFIG_IS_ENABLED(OF_PLATDATA)
245 /* Put this first since driver model will copy the data here */
246 struct dtd_mmc dtplat;
249 * Other fields can go here, to be filled in by decoding from
250 * the device tree (or the C structures when of-platdata is used).
255 static int mmc_ofdata_to_platdata(struct udevice *dev)
257 #if !CONFIG_IS_ENABLED(OF_PLATDATA)
258 /* Decode the device tree data */
259 struct mmc_platdata *plat = dev_get_platdata(dev);
260 const void *blob = gd->fdt_blob;
261 int node = dev_of_offset(dev);
263 plat->fifo_depth = fdtdec_get_int(blob, node, "fifo-depth", 0);
269 static int mmc_probe(struct udevice *dev)
271 struct mmc_platdata *plat = dev_get_platdata(dev);
273 #if CONFIG_IS_ENABLED(OF_PLATDATA)
274 /* Decode the of-platdata from the C structures */
275 struct dtd_mmc *dtplat = &plat->dtplat;
277 plat->fifo_depth = dtplat->fifo_depth;
279 /* Set up the device from the plat data */
280 writel(plat->fifo_depth, ...)
283 static const struct udevice_id mmc_ids[] = {
284 { .compatible = "vendor,mmc" },
288 U_BOOT_DRIVER(mmc_drv) = {
292 .ofdata_to_platdata = mmc_ofdata_to_platdata,
294 .priv_auto_alloc_size = sizeof(struct mmc_priv),
295 .platdata_auto_alloc_size = sizeof(struct mmc_platdata),
298 U_BOOT_DRIVER_ALIAS(mmc_drv, vendor_mmc) /* matches compatible string */
300 Note that struct mmc_platdata is defined in the C file, not in a header. This
301 is to avoid needing to include dt-structs.h in a header file. The idea is to
302 keep the use of each of-platdata struct to the smallest possible code area.
303 There is just one driver C file for each struct, that can convert from the
304 of-platdata struct to the standard one used by the driver.
306 In the case where SPL_OF_PLATDATA is enabled, platdata_auto_alloc_size is
307 still used to allocate space for the platform data. This is different from
308 the normal behaviour and is triggered by the use of of-platdata (strictly
309 speaking it is a non-zero platdata_size which triggers this).
311 The of-platdata struct contents is copied from the C structure data to the
312 start of the newly allocated area. In the case where device tree is used,
313 the platform data is allocated, and starts zeroed. In this case the
314 ofdata_to_platdata() method should still set up the platform data (and the
315 of-platdata struct will not be present).
317 SPL must use either of-platdata or device tree. Drivers cannot use both at
318 the same time, but they must support device tree. Supporting of-platdata is
321 The device tree becomes in accessible when CONFIG_SPL_OF_PLATDATA is enabled,
322 since the device-tree access code is not compiled in. A corollary is that
323 a board can only move to using of-platdata if all the drivers it uses support
324 it. There would be little point in having some drivers require the device
325 tree data, since then libfdt would still be needed for those drivers and
326 there would be no code-size benefit.
331 The dt-structs.h file includes the generated file
332 (include/generated//dt-structs.h) if CONFIG_SPL_OF_PLATDATA is enabled.
333 Otherwise (such as in U-Boot proper) these structs are not available. This
334 prevents them being used inadvertently. All usage must be bracketed with
335 #if CONFIG_IS_ENABLED(OF_PLATDATA).
337 The dt-platdata.c file contains the device declarations and is is built in
338 spl/dt-platdata.c. It additionally contains the definition of
339 dm_populate_phandle_data() which is responsible of filling the phandle
340 information by adding references to U_BOOT_DEVICE by using DM_GET_DEVICE
342 The beginnings of a libfdt Python module are provided. So far this only
343 implements a subset of the features.
345 The 'swig' tool is needed to build the libfdt Python module. If this is not
346 found then the Python model is not used and a fallback is used instead, which
353 This is an implementation of an idea by Tom Rini <trini@konsulko.com>.
358 - Consider programmatically reading binding files instead of device tree
360 - Complete the phandle feature
361 - Move to using a full Python libfdt module
364 .. Simon Glass <sjg@chromium.org>
367 .. Updated Independence Day 2016