Embedded Device Tree Parsing

              /* Add by Starby */
       name = "Chosen";
       Bootargs = "Root=/dev/ram rw console=ttys0,115200";
       Linux,stdout-path = "/soc8349@e0000000/serial@4500";
   };

};

3.1 Root nodes

The starting point of the device tree is called the root node "/". The property model indicates the name of the target Board platform or module, the attribute compatible value indicates and the target board is the same series of compatible board names. For most 32-bit platforms, the values for properties #address-cells and #size-cells are typically 1.

3.2 CPU Nodes

The/cpus node is the child node of the root node and has a corresponding node for each CPU in the system. The/cpus node does not have a property that must be specified, but indicates that #address-cells = <1> and #size-cells = <0> is a good habit, which indicates the reg attribute format for each CPU node and is convenient for the physical CPU number.
This node should contain the properties of each CPU on the board. CPU names are generally written powerpc,<name> for example, Freescale uses powerpc,8349 to describe the mpc8349e processor in this article. The cell name of the CPU node should be the cpu@0 format, which typically specifies device_type (fixed to "CPU"), primary data/instruction cache table entry size, level of data/instruction cache size, core, bus clock frequency, etc. In the example above, the clock frequency correlation is dynamically filled out through the system boot code.

3.3 System memory Nodes

This node is used to describe the range of physical memory on the target board, commonly referred to as the/memory node, and can have one or more. When there are multiple nodes, it needs to be distinguished by the address of the cell, with only one cell address, the cell address is not written, and the default is 0.
This node contains the properties of the physical memory on the board, typically specifying Device_type (fixed to "memory") and the Reg attribute. Where the property value of Reg is given in the form of < start address space >, as in the example above, the target board memory start address is 0 and the size is 256M bytes.

3.4/chosen node

This node is a bit special. Typically, this is where the Open firmware stores variable environment information, such as parameters, the default input.
the Bootargs and Linux,stdout-path attribute values are typically specified in this node. The Bootargs property is set to the parameter string passed to the kernel command line. Linux,stdout-path is often the node pathname for standard terminal equipment, which is used by the kernel as the default terminal.
U-boot added support for the flat device tree FDT after the 1.3.0 release, u-boot loading the Linux kernel, RAMDisk file system (if used) and the device tree binary image to physical memory, before starting the execution of the Linux kernel, It modifies the device tree binary file. It fills in the necessary information into the device tree, such as the MAC address, the number of PCI buses, and so on. U-boot also fills in the "/chosen" node in the device tree file, which contains information such as the serial port, root device (Ramdisk, hard disk, or NFS boot).
the following code for U-boot source COMMON/CMD_BOOTM.C shows that the Ft_setup function will be called to fill the device tree before executing the kernel code.

If defined (config_of_flat_tree)

   /
    * * Create the/chosen node and modify the BLOB with board specific
    * values as needed.
    *
   /Ft_setup (Of_flat_tree, KBD, Initrd_start, initrd_end);
   /* FT_DUMP_BLOB (Of_flat_tree); */

endif

3.5 on-chip system SOC Nodes

This node is used to describe the on-chip system SOC, which must exist if the processor is a soc. The top-level SOC nodes contain information that is visible to all devices on this soc. The node name should contain the cell address of this SOC, which is the base of this SOC memory-mapped register. The SOC node name is named as/soc<socname>, for example, the SOC nodes of MPC8349 are "soc8349".
attributes such as device_type (fixed to SOC), ranges, bus-frequency should be specified in the properties. The Ranges property value is specified in the form <bus_addr parent_bus_addr size>. The SOC node also contains each SOC device child node used by the target board, and the peripheral devices on this SOC should be described as detailed in the device tree as possible. The following is a sample of the SOC node DTS with a watchdog device.
      soc8349@e0000000 {
          #address-cells = <1>;
          #size-cells = <1>;
          Device_type = "Soc";
          compatible = "Simple-bus";
          ranges = <0 e0000000 100000>;        /* 1MB Size */
          reg = <e0000000 00000200>;
          Bus-frequency = <0>;              /* FROM Bootloader */

           wdt@200 {
              Device_type = "watchdog";
              compatible = "MPC83XX_WDT";
              reg = <200 100>;                    /* offset:0x200 */
         };

3.6 Other Device nodes

The hierarchical node is used to describe the bus and device on the system, similar to the physical bus topology, which can describe the relationship between devices conveniently. For each bus and device on the system, there are nodes in the device tree. For descriptions and definitions of these device properties, refer to IEEE 1275 and Linux kernel document Booting-without-of.txt for details.
the interrupt system for the device tree is slightly more complex, and the device node uses the Interrupt-parent and interrupts properties to describe the interrupt connection to the interrupt controller. Where the Interrupt-parent property value is a pointer to the interrupt controller node, #interrupts属性值描述可触发的中断信号 whose value format is related to the Interrupt-cells property value of the interrupt controller. The general #interrupt-cells property value for the 2,interrupts property corresponds to a pair of hexadecimal values that describe the hardware interrupt number and the interrupt triggering method. Its specific contents are referenced in references [x] (Open Firmware Recommended practice:interrupt Mapping Version 0.9 ".  The document is available at: 
 

4 Device Tree Compilation

 because the kernel only recognizes a flat device tree in binary format, a special device tree compiler "DTC" is required to compile the device tree source file (. dts) binary file (. dtb). The DTC compiler checks the input file for syntax and semantics and checks the nodes and attributes according to the requirements of the Linux kernel, compiling the binary (. dtb) of the device tree source file (. dts) to ensure that the kernel boots up properly. The latest DTC compiler Git repository is located in Www.gdl.com, where you can get the source code using the following command $git the clone http://www.gdl.com/projects/dtc.git DTC compiler is used as follows [6]: DTC [-I <input_fomat>] [-O <ouput_fomat>] [-O output_filename] [-v output_version] Input_filename input_
Format can use the following three parameters: DtB: Indicates that the input file is a DTB file; DTS: represents the input file as a DTS file; fs: represents the input file as the format of the/proc/device-tree file. Output_format can use the following three parameters: DtB: Indicates that the output file is a DTB file; DTS: represents the output file as a DTS file; ASM: Indicates that the output file is an assembly language file; If Output_format is "DTB", Ouput_ Version is used to specify the build number of the generated DTB file, and the current DTB file is available with a version number of 1,2,3,16 or 17,output_format with a default value of 17. -s Specifies the size of the generated DTB file, which needs to be expanded appropriately for u-boot to create/chose nodes. Input_filename and output_filename are input and output filenames, respectively.
As found in the use of the DTC compiler, the DTC compiler can not only implement the conversion of DTS files to DTB files, but also the conversion of DTB files to DTS files. 
 
Linux Source arch/powerpc/boot/dts/directory contains a lot of DTS files, can be used as reference files. In addition the DTC compiler has been included in the kernel source code 2.6.25 version. After the 2.6.26 release, the simple rules for generating blobs have been added to makefile, such as the following command:
$ make Arch=powerpc CANYONLANDS.DTB
 
You can also use the following command to generate the DtB file after modifying the DTS file according to your hardware.
$ dtc-f-I dts-o dtb-r 8-s 0x3000 test.dts  > Mpc836x_mds.dtb
$ mkimage-a ppc-o linux-t flat_dt-c N One-a 0x300000-e 0-d MPC836X_MDS.DTB MPC836X_MDS.DTU
 
Note: The latest u-boot uses the DTB image file. The Freescale U-boot needs to add the image information as above using Mkimage for DTB.
 
5 U-boot Related Settings

To enable U-boot to support the device tree, you need to set up a series of macro variables in the board configuration header file. As this article is ported in the MPC8349E processor target board, the U-boot configuration is as follows:
 
/* Pass Open Firmware flat tree */define CONFIG_OF_LIBFDT 1 undef config_of_flat_tree define Config_of_board_setup 1 Defi NE config_of_has_bd_t 1 define config_of_has_uboot_env 1

Boot code U-boot After completing its work, the Linux kernel is loaded and the address of the flat device tree is passed to the kernel in the following code form: if defined (config_of_flat_tree) | | Defined (CONFIG_OF_LIBFDT)

   if (of_flat_tree) {/* device tree; boot new style
        */* * Linux Kernel Parameters (passing Device tree):
        *
  r3:pointer to the FDT, followed by the Board info data
        *   r4:physical Pointer to the kernel itself
        *   R5 : NULL
        *   r6:null
        *   r7:null * *
       (*kernel) ((bd_t *) Of_flat_tree, (ULONG) kernel, 0, 0, 0); c15/>/* does not return */
   }
endif
There is only one entry for the ARCH/POWERPC kernel, and the entry point is the beginning of the kernel image. This portal supports two invocation modes, one that supports open firmware startup, and one that requires a flat device tree block, such as the example code, for boot code without. The Register R3 holds the physical address pointer to the device tree, the register R4 is saved as the address of the kernel in physical memory, and R5 is null. The implication is that, assuming the MMU is turned on, the MMU mapping is a 1:1 mapping, where the virtual address and physical address are the same.
 
6 Linux kernel parsing of the device.

The flat device tree describes the device tree information in the target Board platform. Each device has a node that describes its information, and each node can have child nodes and their corresponding properties. In the kernel source code include/linux/of.h and drivers/of/base.c and other files provide some open Firmware API, through these APIs, the kernel and device driver can find the corresponding device node, read its property values, Use this information to properly initialize and drive the hardware.
 
Files: fdt100125133436.jpg analysis of the Linux kernel source code, you can see the flat device tree parsing process [7 to be detailed analysis] as follows: (1) The General register R30 and R31 are saved first at the kernel entrance by the image base address and DtB file image base that is passed from U-boot. (2) The Machine_init (), Early_init_devtree () function is called to obtain the system boot parameters such as Bootargs,cmd_line required for pre-initialization of the kernel. (3) According to the Bootargs,cmd_line and other system boot parameters into the Start_kernel () function, the second phase initialization of the kernel. (4) Call the Start_kernel (), Setup_arch (), Unflatten_device_tree () functions to parse the DTB file, construct a single-necklace table that is connected by a DEVICE_NODE structure, and use global variables Allnodes Pointer to hold the head pointer of this linked list. (5) The kernel calls the provided API function to get the allnodes linked list information to initialize other subsystems, devices, etc. of the kernel.


7 Kernel Compromise

The introduction of the device Tree FDT blob, the corresponding will occupy a certain amount of storage space, while introducing the FDT API code, in contrast to the kernel code has increased, but a kernel image can support multiple hardware platforms, between different platforms only need to modify the device tree FDT blob.
 
8 concluding remarks

This paper introduces the origin and advantages of the device tree, then expounds the data storage format of the device tree and the source code description grammar, gives the method of compiling the device tree, and finally brings out the U-boot correlation setting description and the parsing process analysis of the kernel in the transplant process. The device tree is a dynamic interface for the embedded system to pass parameters to the Linux kernel, and it is hoped that this paper will have some reference value to the embedded PowerPC Linux developers, and accelerate the device tree DTS porting process in the embedded PowerPC Linux development.
 
 References [1] Matt Tyrlik. Booting Linux on Embedded POWERPCTM Systems [R]. Embedded Linux Developers Conference, [2] Benjamin Herrenschmidt, Becky Bruce, et al booting the LINUX/PPC kernel WI Thout Open Firmware [Z]. Bootint-without-of.txt from the Linux kernel source tree, 2006 [3] DENX. Flattened Device Tree Blob [Eb/ol]. http://www.denx.de/wiki/view/dulg/linuxfdtblob, [4] Grant likely, Josh Boyer. A Symphony of flavours:using The device tree to describe embedded hardware [R]. Ottawa, Canada:linux Symposium, [5] SUN. The Open Firmware Home Page [Eb/ol].http://playground.sun.com/1275/home.html, 2005 [6] David Gibson, Benjamin Herrenschmi DT, Ozlabs. Device trees everywhere [R]. 2006 [7] Chu Wenhua, Chu Jianjin. startup mode of Linux kernel based on flat device tree [J]. Modern computer, 3rd 2009, 115-118. 2009.3