Compiling the Zedboard DEVICETREE.DTB

A device tree is a data structure that describes the hardware that describes the CPU and describes any existing drive devices, such as clocks, interrupt controllers, IO controllers, SPI Bus controllers, I2C controllers, storage devices, and so on. The kernel can recognize this tree, and according to it to expand the Linux kernel in the Platform_device, I2c_client, Spi_device and other devices, and these devices used in memory, IRQ and other resources, also passed to the kernel, The kernel binds these resources to the appropriate device that is being expanded.

The hardware details of the ARM architecture are too hard coded in arch/arm/plat-xxx and arch/arm/mach-xxx, and after the device tree, many details of the hardware can be passed directly to Linux, It is no longer necessary to do a lot of redundant coding in kernel.

The compiler for the device tree is scripts/dtc/in the Linux source directory. Note: To use the device tree, the kernel needs to be configured to open the device tree compiler at compile time.

There are two ways to build a device tree: One is to build a device tree from a device tree source in Linux source, and the other is to build a device tree using the Xilinx SDK2014.2 software.

method One:

1, in the Linux source directory under the Arch/arm/boot/dts directory has a device tree source files, Zedboard the corresponding device tree source file name is Zynq-zed.dts (if you need an excuse to include the PL section, you will need to manually add the corresponding device description in Zynq-zed.dts)

2, compile the device tree: In the Linux source root directory run the following command, you can generate DEVICETREE.DTB files.

Scripts/dtc/dtc–i dts–o dtb–o DEVICETREE.DTB Arch/arm/boot/dts/zynq-zed.dts

Note:DTB's decompile command:

Scripts/dtc/dtc–i dtb–o dts–o My_devicetree.dts DEVICETREE.DTB

Method Two:

Since version 2014.1, the software and hardware management mechanism in the SDK has changed, and the DTS file cannot be generated on 2014.1. To solve this problem, Xilinx has provided a new BSP package in the 2014.2 version of the SDK. The download location has also changed to isolate from previous versions: Https://github.com/Xilinx/device-tree-xlnx/releases

The 2014.2 corresponding GZ files are downloaded, after decompression found and compared to the previous changes are very large:

The following is the contents of the 2013.4 SDK generated Devicetree's BSP package after decompression

And the 2014.2 version of the SDK generated Devicetree BSP package after the contents of the following:

Randomly enter one of the directories to view folder contents: In the 2014.2 version, each interface is put into a separate folder to describe.

We can refer to Http://www.wiki.xilinx.com/Build+Device+Tree+Blob before making DTS steps. In version 2014.2 It is also a step to refer to the link.

Will download the file device-tree-xlnx-xilinx-v2014.2.tar.gz decompression to get a call device-tree-xlnx-xilinx-v2014.2 directory, the same name in the directory DEVICE-TREE-XLNX-XILINX-V20 The 14.2 directory is renamed to Device-tree_v0_00_a, then the device-tree_v0_00_a is copied to a directory called BSP, and the path to the top level of the BSP will be the path added to the repo.

For example, the path to my Device-tree_v0_00_a folder is D:\Xilinx-doc\Code\targz_devicetree\devicetree_repo\bsp, where D:\Xilinx-doc\Code\ Targz_devicetree\devicetree_repo is the path that is added to the repo:

After adding the repo path, create a DTS BSP by File->new->board Support package:

Select Device tree in the pop-up interface

Then click the Finish button:

Here you can directly click OK, of course, you can add your own Bootargs, if you have more than one serial port hardware project, you may have to configure the Console_device, that is, the Linux boot after the print serial port.

Click OK, in the Project window will generate a device_tree_bsp_0 directory, this directory contains Ps.dtsi and System.dts two files is what we need.

The Ps.dtsi contains the contents of your peripheral interface information, but it is not a complete DTS, and I in the suffix indicates that it resembles the header file in C language. It is contained in the System.dts by/include/"Ps.dtsi".

The contents of System.dts are relatively simple, with chosen, aliases, and memory information:

/*

* Caution:this file is automatically generated by Xilinx.

* Version:

* Today Is:mon June 07 16:24:07 2014

*/

/dts-v1/;

/include/"Ps.dtsi"

/{

Chosen {

Bootargs = "console=ttyps0,115200";

Linux,stdout-path = &ps7_uart_1;

} ;

aliases {

Ethernet0 = &ps7_ethernet_0;

Serial0 = &ps7_uart_1;

Spi0 = &ps7_qspi_0;

} ;

ps7_ddr_0:memory@00100000 {

Device_type = "Memory";

Reg = <0x0 0x20000000>;

} ;

};

What if the interface of PL is included in the hardware project? In fact, if you have the information of PL in your hardware project, a Pl.dtsi file will be generated.

Copy the Ps.dtsi and System.dts files to the virtual machine, and you can consider putting them in the 2014.2 kernel Arch/arm/boot/dts directory or somewhere else.

If you put the above two files into the Arch/arm/boot/dts directory, make SYSTEM.DTB directly in the Linux directory to generate DTB files.

If you are in a different directory, you can also generate System.dts files in the corresponding directory to perform dtc-i dts-o dtb-o system.dtb dtb.

The point that needs to be pointed out is that the Ps.dtsi file generated in the SDK will add all the ZYNQ interfaces, for example, you do not have a choice of UART0, in Ps.dtsi there will be UART0 information:

ps7_uart_0:ps7-uart@0xe0000000 {

Clock-names = "Ref_clk", "APER_CLK";

clocks = <&clkc 23>, <&CLKC 40>;

compatible = "xlnx,ps7-uart-1.00.a";

Interrupt-parent = <&ps7_scugic_0>;

Interrupts = <0 4>;

Reg = <0xe0000000 0x1000>;

Status = "Disabled";

} ;

However, compared to the interfaces included in your hardware project, there is a status = "disabled" field in the description of the nonexistent interface, and the user can delete the unwanted interface according to this field.