Arm-linux Device Tree usage format (Device trees Usage) __linux

Reference:
Http://elinux.org/Device_Tree_Usage
http://blog.csdn.net/sgmenghuo/article/details/45071615 Basic Data Format

The device tree is a simple tree structure that contains nodes and attributes. Properties are described by the form of key-value pairs, a node can contain multiple attributes or child nodes, and a simple. DTS format device tree is shown below.

/dts-v1/;

/{
    Node1 {
        A-string-property = "a string";
        A-string-list-property = "A-string", "second string";
        A-byte-data-property = [0x01 0x23 0x34 0x56];
        child-node1 {
            first-child-property;
            Second-child-property = <1>;
            A-string-property = "Hello, world";
        };
        Child-node2 {
        };
    Node2 {
        an-empty-property;
        A-cell-property = <1 2 3 4>; /* each number (cell) is a uint32 */
        child-node1 {
        };
    };

Obviously, the device tree for the above example is not used at all, because it doesn't describe anything at all, but it can tell us a lot about the nodes and attributes in the tree structure. Specifically as follows:

There is a root node "/"
Has two child nodes: Node1 and Node2
Node1 has two sub nodes: Child-node1 and Child-node2
Some attributes scattered throughout the tree

A property is a simple key-value pair whose value can be either empty or a byte stream of any size. There is no need to include data types in such a data structure, and here are some basic data that can be expressed in a DTS file:
　　
The text string (containing the ' I ' Terminator) is expressed in double quotes:

String-property = "a string";

Cells (32-bit unsigned integer) is indicated by angle brackets:

Cell-property = <0xbeef 123 0xabcd1234>;

Binary data is represented by square brackets:

Binary-property = [0x01 0x23 0x45 0x67];

The combination of different types of data is also possible, but it needs to be separated by commas:

Mixed-property = "A string", [0x01 0x23 0x45 0x67], <0x12345678>;

Commas are also used to create a list of strings:

String-list = "Red Fish", "Blue Fish";

Basic Concepts

To understand exactly how device tree is used, we will take a simple machine as an example to build a device tree that describes it step by step. Demonstration Machine

Suppose there is such a computer (based on ARM versatile) that is manufactured by "ACME" and named "Coyote ' s Revenge":

A 32-bit ARM processor;
Serial port, SPI Bus controller, I2C Bus controller, interrupt controller and some external bus bridges are connected to the processor bus through memory mapping;
256MB SDRAM, base site is 0;
Two serial port, the base address is 0x101f1000 and 0x101f2000 respectively;
GPIO Controller, base site for 0x101f3000;
SPI Controller, the base address is 0x10170000, and the MMC slot is connected (SS pin is connected to Gpio #1);
External bus bridge, which connects the following devices:
① the SMC SMC91111 Ethernet device connected to the external bus, the base site is 0x10100000;
②I2C Controller, base site for 0x10160000, and connected to the Maxim DS1338 real-time clock (device from address 1101000, that is, 0x58);
③64MB NOR Flash, base site is 0x30000000; Initial Structure

First, the basic frame of the machine device tree is built, that is, the minimum structure of an effective device trees. In this step, you want to uniquely identify this computer.

/dts-v1/;

/{
    compatible = "Acme,coyotes-revenge";
};

The Compatible property specifies the name of the system, and its value is a string in the format of "<manufacturer>,<model>". It is necessary to specify the compatible value for a specific device, because containing the manufacturer's name avoids namespace conflicts. The operating system will determine how to run this computer based on the compatible value, so it is important to fill in the correct data in this attribute.
Theoretically, compatible is all the data that the operating system uniquely identifies a machine, and if all machine details are hard-coded, the OS can look for "acme,coyotes-revenge" in the top-level compatible attribute. CPUs

Next, we'll describe each CPU. First add a "CPUs" container node and add each CPU as a child node. In this example, the dual-core Cortex A9 processor is based on ARM.

/dts-v1/;

/{
    compatible = "Acme,coyotes-revenge";

    CPUs {
        Cpu@0 {
            compatible = "arm,cortex-a9";
        };
        cpu@1 {
            compatible = "arm,cortex-a9";};};};

Similar to the top-level compatible property, the compatible attribute in each CPU node is also a "<manufacturer>,<model>" format string that specifies the exact model of the CPU.
More attributes will be added to the CPU node, so we first need to understand some basic concepts first. node naming

It is worthwhile to spend some time talking about naming habits. Each node must have a <NAME>[@<UNIT-ADDRESS>-format name.
<name> is a maximum length of 31 characters of the ASCII string, in general, the name of the node is based on the device it represents. For example, a node that represents a 3com Ethernet adapter should be named Ethernet, not 3com509.
If the device represented by the node has a related device address, you need to include <unit-address> information. <unit-address> is typically used to access the first address of the device and is listed in the node's Reg property. We will also describe the Reg attribute in detail later.
Sibling nodes must be uniquely named, but as long as the addresses are different, it is OK to have multiple nodes using the same name (for example, serial@101f1000 and serial@101f2000).
Refer to the EPAPR Specification 2.2.1 section for full details of the node naming. Equipment

Each device in the system is represented by a node on the device tree, so the next step is to add a device node to each device in the device tree. The new node we are adding now is first set to NULL, followed by the process of addressing and interrupting.

/dts-v1/;

    /{compatible = "acme,coyotes-revenge";
        CPUs {cpu@0 {compatible = "arm,cortex-a9";
        };
        cpu@1 {compatible = "arm,cortex-a9";
    };

    };
    serial@101f0000 {compatible = "arm,pl011";

    };
    serial@101f2000 {compatible = "arm,pl011";

    };
    gpio@101f3000 {compatible = "arm,pl061";

    };
    interrupt-controller@10140000 {compatible = "arm,pl190";

    };
    spi@10115000 {compatible = "arm,pl022";

    };
        External-bus {ethernet@0,0 {compatible = "smc,smc91c111";

        };
            i2c@1,0 {compatible = "Acme,a1234-i2c-bus";
            rtc@58 {compatible = "maxim,ds1338";
        };

        };
        flash@2,0 {compatible = "SAMSUNG,K8F1315EBM", "Cfi-flash";
    };
}; };

In the tree above, nodes have been added to each device in the system, and the hierarchy of the device tree reflects how the device is connected to the system. For example, a device attached to an external bus is a child node of an external bus node, and the I2C device is a child of the I2C Bus controller node. In general, the hierarchy of the device tree is a view of the system from a CPU perspective.
The device tree is still invalid because it lacks the information that describes exactly how the device is connected. We'll add the data to it later.
There are some things to note about this device tree:
Each device node has a compatible attribute;
The Compatible property of the Flash node has two strings; (The next section explains why)
Previously mentioned, node naming should reflect the type of device, not a specific model; (refer to the generic node naming of the EPAPR Specification 2.2.2 section, use these names preferentially) to understand compatible properties

Each node in the device tree requires a compatible attribute, and the operating system determines which device driver should be bound with the device using this compatible value.
The value of the compatible is a list of strings, the first string in the list accurately describes the device in the format "<manufacturer>,<model>", followed by a string representing other compatible devices.
For example, the Freescale MPC8349 Soc has a serial device that implements National Semiconductor ns16550 register interface. Therefore MPC8349 serial device compatible attribute is: compatible = "Fsl,mpc8349-uart", "ns16550". Here, Fsl,mpc8349-uart specifies the exact device, ns16550 indicates that it is register-level compatible with National Semiconductor 16550 UART.
　　
Note: For historical reasons, ns16550 does not have a manufacturer prefix, and all new compatible values should use the manufacturer's prefix. This approach allows existing device drivers to bind to a new device while still uniquely identifying the hardware.

Warning: Do not use wildcard compatible values, such as "Fsl,mpc83xx-uart" and other similar expressions, chip manufacturers will always change and break your wildcard assumptions, then it is too late to change. Instead, you should choose a specific chip to implement and remain compatible with all subsequent chips. How addressing works

Addressable devices use the following properties to encode address information into the device tree:
Reg
#address-cells
#size-cells
　　
Each addressable device gets a reg which are a list of tuples in the form reg =