421 lines · plain
1.. SPDX-License-Identifier: GPL-2.02 3========================4Linux and the Devicetree5========================6 7The Linux usage model for device tree data8 9:Author: Grant Likely <grant.likely@secretlab.ca>10 11This article describes how Linux uses the device tree. An overview of12the device tree data format can be found on the device tree usage page13at devicetree.org\ [1]_.14 15.. [1] https://www.devicetree.org/specifications/16 17The "Open Firmware Device Tree", or simply Devicetree (DT), is a data18structure and language for describing hardware. More specifically, it19is a description of hardware that is readable by an operating system20so that the operating system doesn't need to hard code details of the21machine.22 23Structurally, the DT is a tree, or acyclic graph with named nodes, and24nodes may have an arbitrary number of named properties encapsulating25arbitrary data. A mechanism also exists to create arbitrary26links from one node to another outside of the natural tree structure.27 28Conceptually, a common set of usage conventions, called 'bindings',29is defined for how data should appear in the tree to describe typical30hardware characteristics including data busses, interrupt lines, GPIO31connections, and peripheral devices.32 33As much as possible, hardware is described using existing bindings to34maximize use of existing support code, but since property and node35names are simply text strings, it is easy to extend existing bindings36or create new ones by defining new nodes and properties. Be wary,37however, of creating a new binding without first doing some homework38about what already exists. There are currently two different,39incompatible, bindings for i2c busses that came about because the new40binding was created without first investigating how i2c devices were41already being enumerated in existing systems.42 431. History44----------45The DT was originally created by Open Firmware as part of the46communication method for passing data from Open Firmware to a client47program (like to an operating system). An operating system used the48Device Tree to discover the topology of the hardware at runtime, and49thereby support a majority of available hardware without hard coded50information (assuming drivers were available for all devices).51 52Since Open Firmware is commonly used on PowerPC and SPARC platforms,53the Linux support for those architectures has for a long time used the54Device Tree.55 56In 2005, when PowerPC Linux began a major cleanup and to merge 32-bit57and 64-bit support, the decision was made to require DT support on all58powerpc platforms, regardless of whether or not they used Open59Firmware. To do this, a DT representation called the Flattened Device60Tree (FDT) was created which could be passed to the kernel as a binary61blob without requiring a real Open Firmware implementation. U-Boot,62kexec, and other bootloaders were modified to support both passing a63Device Tree Binary (dtb) and to modify a dtb at boot time. DT was64also added to the PowerPC boot wrapper (``arch/powerpc/boot/*``) so that65a dtb could be wrapped up with the kernel image to support booting66existing non-DT aware firmware.67 68Some time later, FDT infrastructure was generalized to be usable by69all architectures. At the time of this writing, 6 mainlined70architectures (arm, microblaze, mips, powerpc, sparc, and x86) and 171out of mainline (nios) have some level of DT support.72 732. Data Model74-------------75If you haven't already read the Device Tree Usage\ [1]_ page,76then go read it now. It's okay, I'll wait....77 782.1 High Level View79-------------------80The most important thing to understand is that the DT is simply a data81structure that describes the hardware. There is nothing magical about82it, and it doesn't magically make all hardware configuration problems83go away. What it does do is provide a language for decoupling the84hardware configuration from the board and device driver support in the85Linux kernel (or any other operating system for that matter). Using86it allows board and device support to become data driven; to make87setup decisions based on data passed into the kernel instead of on88per-machine hard coded selections.89 90Ideally, data driven platform setup should result in less code91duplication and make it easier to support a wide range of hardware92with a single kernel image.93 94Linux uses DT data for three major purposes:95 961) platform identification,972) runtime configuration, and983) device population.99 1002.2 Platform Identification101---------------------------102First and foremost, the kernel will use data in the DT to identify the103specific machine. In a perfect world, the specific platform shouldn't104matter to the kernel because all platform details would be described105perfectly by the device tree in a consistent and reliable manner.106Hardware is not perfect though, and so the kernel must identify the107machine during early boot so that it has the opportunity to run108machine-specific fixups.109 110In the majority of cases, the machine identity is irrelevant, and the111kernel will instead select setup code based on the machine's core112CPU or SoC. On ARM for example, setup_arch() in113arch/arm/kernel/setup.c will call setup_machine_fdt() in114arch/arm/kernel/devtree.c which searches through the machine_desc115table and selects the machine_desc which best matches the device tree116data. It determines the best match by looking at the 'compatible'117property in the root device tree node, and comparing it with the118dt_compat list in struct machine_desc (which is defined in119arch/arm/include/asm/mach/arch.h if you're curious).120 121The 'compatible' property contains a sorted list of strings starting122with the exact name of the machine, followed by an optional list of123boards it is compatible with sorted from most compatible to least. For124example, the root compatible properties for the TI BeagleBoard and its125successor, the BeagleBoard xM board might look like, respectively::126 127 compatible = "ti,omap3-beagleboard", "ti,omap3450", "ti,omap3";128 compatible = "ti,omap3-beagleboard-xm", "ti,omap3450", "ti,omap3";129 130Where "ti,omap3-beagleboard-xm" specifies the exact model, it also131claims that it compatible with the OMAP 3450 SoC, and the omap3 family132of SoCs in general. You'll notice that the list is sorted from most133specific (exact board) to least specific (SoC family).134 135Astute readers might point out that the Beagle xM could also claim136compatibility with the original Beagle board. However, one should be137cautioned about doing so at the board level since there is typically a138high level of change from one board to another, even within the same139product line, and it is hard to nail down exactly what is meant when one140board claims to be compatible with another. For the top level, it is141better to err on the side of caution and not claim one board is142compatible with another. The notable exception would be when one143board is a carrier for another, such as a CPU module attached to a144carrier board.145 146One more note on compatible values. Any string used in a compatible147property must be documented as to what it indicates. Add148documentation for compatible strings in Documentation/devicetree/bindings.149 150Again on ARM, for each machine_desc, the kernel looks to see if151any of the dt_compat list entries appear in the compatible property.152If one does, then that machine_desc is a candidate for driving the153machine. After searching the entire table of machine_descs,154setup_machine_fdt() returns the 'most compatible' machine_desc based155on which entry in the compatible property each machine_desc matches156against. If no matching machine_desc is found, then it returns NULL.157 158The reasoning behind this scheme is the observation that in the majority159of cases, a single machine_desc can support a large number of boards160if they all use the same SoC, or same family of SoCs. However,161invariably there will be some exceptions where a specific board will162require special setup code that is not useful in the generic case.163Special cases could be handled by explicitly checking for the164troublesome board(s) in generic setup code, but doing so very quickly165becomes ugly and/or unmaintainable if it is more than just a couple of166cases.167 168Instead, the compatible list allows a generic machine_desc to provide169support for a wide common set of boards by specifying "less170compatible" values in the dt_compat list. In the example above,171generic board support can claim compatibility with "ti,omap3" or172"ti,omap3450". If a bug was discovered on the original beagleboard173that required special workaround code during early boot, then a new174machine_desc could be added which implements the workarounds and only175matches on "ti,omap3-beagleboard".176 177PowerPC uses a slightly different scheme where it calls the .probe()178hook from each machine_desc, and the first one returning TRUE is used.179However, this approach does not take into account the priority of the180compatible list, and probably should be avoided for new architecture181support.182 1832.3 Runtime configuration184-------------------------185In most cases, a DT will be the sole method of communicating data from186firmware to the kernel, so also gets used to pass in runtime and187configuration data like the kernel parameters string and the location188of an initrd image.189 190Most of this data is contained in the /chosen node, and when booting191Linux it will look something like this::192 193 chosen {194 bootargs = "console=ttyS0,115200 loglevel=8";195 initrd-start = <0xc8000000>;196 initrd-end = <0xc8200000>;197 };198 199The bootargs property contains the kernel arguments, and the initrd-*200properties define the address and size of an initrd blob. Note that201initrd-end is the first address after the initrd image, so this doesn't202match the usual semantic of struct resource. The chosen node may also203optionally contain an arbitrary number of additional properties for204platform-specific configuration data.205 206During early boot, the architecture setup code calls of_scan_flat_dt()207several times with different helper callbacks to parse device tree208data before paging is setup. The of_scan_flat_dt() code scans through209the device tree and uses the helpers to extract information required210during early boot. Typically the early_init_dt_scan_chosen() helper211is used to parse the chosen node including kernel parameters,212early_init_dt_scan_root() to initialize the DT address space model,213and early_init_dt_scan_memory() to determine the size and214location of usable RAM.215 216On ARM, the function setup_machine_fdt() is responsible for early217scanning of the device tree after selecting the correct machine_desc218that supports the board.219 2202.4 Device population221---------------------222After the board has been identified, and after the early configuration data223has been parsed, then kernel initialization can proceed in the normal224way. At some point in this process, unflatten_device_tree() is called225to convert the data into a more efficient runtime representation.226This is also when machine-specific setup hooks will get called, like227the machine_desc .init_early(), .init_irq() and .init_machine() hooks228on ARM. The remainder of this section uses examples from the ARM229implementation, but all architectures will do pretty much the same230thing when using a DT.231 232As can be guessed by the names, .init_early() is used for any machine-233specific setup that needs to be executed early in the boot process,234and .init_irq() is used to set up interrupt handling. Using a DT235doesn't materially change the behaviour of either of these functions.236If a DT is provided, then both .init_early() and .init_irq() are able237to call any of the DT query functions (of_* in include/linux/of*.h) to238get additional data about the platform.239 240The most interesting hook in the DT context is .init_machine() which241is primarily responsible for populating the Linux device model with242data about the platform. Historically this has been implemented on243embedded platforms by defining a set of static clock structures,244platform_devices, and other data in the board support .c file, and245registering it en-masse in .init_machine(). When DT is used, then246instead of hard coding static devices for each platform, the list of247devices can be obtained by parsing the DT, and allocating device248structures dynamically.249 250The simplest case is when .init_machine() is only responsible for251registering a block of platform_devices. A platform_device is a concept252used by Linux for memory or I/O mapped devices which cannot be detected253by hardware, and for 'composite' or 'virtual' devices (more on those254later). While there is no 'platform device' terminology for the DT,255platform devices roughly correspond to device nodes at the root of the256tree and children of simple memory mapped bus nodes.257 258About now is a good time to lay out an example. Here is part of the259device tree for the NVIDIA Tegra board::260 261 /{262 compatible = "nvidia,harmony", "nvidia,tegra20";263 #address-cells = <1>;264 #size-cells = <1>;265 interrupt-parent = <&intc>;266 267 chosen { };268 aliases { };269 270 memory {271 device_type = "memory";272 reg = <0x00000000 0x40000000>;273 };274 275 soc {276 compatible = "nvidia,tegra20-soc", "simple-bus";277 #address-cells = <1>;278 #size-cells = <1>;279 ranges;280 281 intc: interrupt-controller@50041000 {282 compatible = "nvidia,tegra20-gic";283 interrupt-controller;284 #interrupt-cells = <1>;285 reg = <0x50041000 0x1000>, < 0x50040100 0x0100 >;286 };287 288 serial@70006300 {289 compatible = "nvidia,tegra20-uart";290 reg = <0x70006300 0x100>;291 interrupts = <122>;292 };293 294 i2s1: i2s@70002800 {295 compatible = "nvidia,tegra20-i2s";296 reg = <0x70002800 0x100>;297 interrupts = <77>;298 codec = <&wm8903>;299 };300 301 i2c@7000c000 {302 compatible = "nvidia,tegra20-i2c";303 #address-cells = <1>;304 #size-cells = <0>;305 reg = <0x7000c000 0x100>;306 interrupts = <70>;307 308 wm8903: codec@1a {309 compatible = "wlf,wm8903";310 reg = <0x1a>;311 interrupts = <347>;312 };313 };314 };315 316 sound {317 compatible = "nvidia,harmony-sound";318 i2s-controller = <&i2s1>;319 i2s-codec = <&wm8903>;320 };321 };322 323At .init_machine() time, Tegra board support code will need to look at324this DT and decide which nodes to create platform_devices for.325However, looking at the tree, it is not immediately obvious what kind326of device each node represents, or even if a node represents a device327at all. The /chosen, /aliases, and /memory nodes are informational328nodes that don't describe devices (although arguably memory could be329considered a device). The children of the /soc node are memory mapped330devices, but the codec@1a is an i2c device, and the sound node331represents not a device, but rather how other devices are connected332together to create the audio subsystem. I know what each device is333because I'm familiar with the board design, but how does the kernel334know what to do with each node?335 336The trick is that the kernel starts at the root of the tree and looks337for nodes that have a 'compatible' property. First, it is generally338assumed that any node with a 'compatible' property represents a device339of some kind, and second, it can be assumed that any node at the root340of the tree is either directly attached to the processor bus, or is a341miscellaneous system device that cannot be described any other way.342For each of these nodes, Linux allocates and registers a343platform_device, which in turn may get bound to a platform_driver.344 345Why is using a platform_device for these nodes a safe assumption?346Well, for the way that Linux models devices, just about all bus_types347assume that its devices are children of a bus controller. For348example, each i2c_client is a child of an i2c_master. Each spi_device349is a child of an SPI bus. Similarly for USB, PCI, MDIO, etc. The350same hierarchy is also found in the DT, where I2C device nodes only351ever appear as children of an I2C bus node. Ditto for SPI, MDIO, USB,352etc. The only devices which do not require a specific type of parent353device are platform_devices (and amba_devices, but more on that354later), which will happily live at the base of the Linux /sys/devices355tree. Therefore, if a DT node is at the root of the tree, then it356really probably is best registered as a platform_device.357 358Linux board support code calls of_platform_populate(NULL, NULL, NULL, NULL)359to kick off discovery of devices at the root of the tree. The360parameters are all NULL because when starting from the root of the361tree, there is no need to provide a starting node (the first NULL), a362parent struct device (the last NULL), and we're not using a match363table (yet). For a board that only needs to register devices,364.init_machine() can be completely empty except for the365of_platform_populate() call.366 367In the Tegra example, this accounts for the /soc and /sound nodes, but368what about the children of the SoC node? Shouldn't they be registered369as platform devices too? For Linux DT support, the generic behaviour370is for child devices to be registered by the parent's device driver at371driver .probe() time. So, an i2c bus device driver will register a372i2c_client for each child node, an SPI bus driver will register373its spi_device children, and similarly for other bus_types.374According to that model, a driver could be written that binds to the375SoC node and simply registers platform_devices for each of its376children. The board support code would allocate and register an SoC377device, a (theoretical) SoC device driver could bind to the SoC device,378and register platform_devices for /soc/interrupt-controller, /soc/serial,379/soc/i2s, and /soc/i2c in its .probe() hook. Easy, right?380 381Actually, it turns out that registering children of some382platform_devices as more platform_devices is a common pattern, and the383device tree support code reflects that and makes the above example384simpler. The second argument to of_platform_populate() is an385of_device_id table, and any node that matches an entry in that table386will also get its child nodes registered. In the Tegra case, the code387can look something like this::388 389 static void __init harmony_init_machine(void)390 {391 /* ... */392 of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);393 }394 395"simple-bus" is defined in the Devicetree Specification as a property396meaning a simple memory mapped bus, so the of_platform_populate() code397could be written to just assume simple-bus compatible nodes will398always be traversed. However, we pass it in as an argument so that399board support code can always override the default behaviour.400 401[Need to add discussion of adding i2c/spi/etc child devices]402 403Appendix A: AMBA devices404------------------------405 406ARM Primecells are a certain kind of device attached to the ARM AMBA407bus which include some support for hardware detection and power408management. In Linux, struct amba_device and the amba_bus_type is409used to represent Primecell devices. However, the fiddly bit is that410not all devices on an AMBA bus are Primecells, and for Linux it is411typical for both amba_device and platform_device instances to be412siblings of the same bus segment.413 414When using the DT, this creates problems for of_platform_populate()415because it must decide whether to register each node as either a416platform_device or an amba_device. This unfortunately complicates the417device creation model a little bit, but the solution turns out not to418be too invasive. If a node is compatible with "arm,primecell", then419of_platform_populate() will register it as an amba_device instead of a420platform_device.421