Table of Contents
Table of Contents | ||
---|---|---|
|
Introduction
In a general Yocto development, the ASSP on a target board is fixed and the kernel tree provides the device tree blob (dtb
). The device tree can be customized by simply patching the dts
in the kernel tree if needed. In fabric-based devices such as Zynq and Zynq Ultrascale+, the IP targeting the fabric is customized during the design. Because the IP in the PL changes per design, the developer needs a way to generate the device tree for the PL at design time. The Xilinx Device Tree Generator (DTG), can parse a hardware description (HDF) and automatically generate dts
for your design. Because this dts
is regenerated every time you make changes to your PL design, it's difficult to just patch the dts
. This wiki shows how to append the device-tree recipe to add a custom dtsi
that can override device properties or add new nodes that are board specific. The examples shown are for a ZCU102-based design.
Device
...
Tree Recipe
The meta-xilinx
layer includes the device-tree.bb
recipe which provides baseline support for machines that are not included in the kernel tree, such as MicroBlaze and Zed boards. The meta-xilinx-tools
layer extends this recipe, device-tree.bbappend
, to support the DTG. With the DTG, Yocto can generate a custom device tree for your design. However, it is still missing board specific device nodes for your target. By further extending the device-tree, you can include a user dtsi
which can customize the device tree by overriding properties, adding new properties or adding new device nodes. The device-tree.bbappend
listing below provides a simple method for customizing your device tree. You are responsible for writing the system-user.dtsi
and placing it in the files
directory.
Add Custom Device
...
Tree
...
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
FILESEXTRAPATHS_prepend := "${THISDIR}/files:" SYSTEM_USER_DTSI ?= "system-user.dtsi" SRC_URI_append = " \ file://system-user.dtsi${SYSTEM_USER_DTSI} \ " do_configure_append() { cp ${WORKDIR}/system-user.dtsi${SYSTEM_USER_DTSI} ${B}/device-tree echo '"/include/ "system-user.dtsi"'\"${SYSTEM_USER_DTSI}\"" >> ${B}/device-tree/system-top.dts } |
Inside the files
directory you can place your actual system-user.dtsi
or you can just place a dummy system-user.dtsi
and control the actual system-user.dtsi
from your machine configuration as shown in the example-zcu102-zynqmp
listing below. This way if you don't need a system-user.dtsi
, the build will still succeed thanks to the dummy dtsi
,
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
/* system-user.dtsi */ |
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
SYSTEM_USER_DTSI = "/<path-to-actual>/system-user.dtsi" |
Add Existing BSP
...
The above bbappend
allows you to plug your custom device tree nodes into your build. However, you may want to take advantage of work already done for you on an evaluation platform. XSDK and XSCT use YAML to control the build of a BSP. This will pull in a board specific dtsi
to support the BSP of your target. For example, this may include an Ethernet PHY device node and I2C extender nodes for the ZCU102. In order to include this BSP support, you need to set the YAML_DT_BOARD_FLAGS
flag for your target either in a machine configuration or in a device-tree.bbappend
. Note that when specifying in the device-tree.bbappend
, it is a good idea to use the machine override syntax so the build system can still build multiple targets.
...
A list of available BOARD
definitions can be found in meta-xilinx-tools/recipes-bsp/device-tree/device-tree.bbappend
.
Deploy Directory
After a build, your dtb
is in the deploy
directory with the other images. The deploy
directory can get pretty cluttered, however, many of the files are simply links with abbreviated compact names to the most recent file version with a more detailed verbose name.
The deploy listings below shows the dtb
from a zcu102-based build. You may notice multiple deployed dtb
from your build. In the first listing, there are three dtb
files, but note two of them are simply links to the actual dtb
. These dtb
are generated from the kernel-devicetree
class. This is the same dtb
that would be generated from the zcu102-zynqmp.dts
in the from the kernel tree. So this is a fully functional dtb
, but it does not include any device tree nodes from your PL design, This is often a good place to fallback if your kernel hangs when you load a custom device tree supporting your PL design. If your kernel boots with this dtb
, then you can assume you have a device tree issue in the PL.
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
Image--4.14-xilinx-v2018.2+git0+ad4cd988ba-r0-zynqmp-zcu102-rev1.0-<timestamp>.dtb Image-zynqmp-zcu102-rev1.0.dtb -> Image--4.14-xilinx-v2018.2+git0+ad4cd988ba-r0-zynqmp-zcu102-rev1.0-<timestamp>.dtb zynqmp-zcu102-rev1.0.dtb -> Image--4.14-xilinx-v2018.2+git0+ad4cd988ba-r0-zynqmp-zcu102-rev1.0-<timestamp>.dtb |
This listing shows the deployed dtb
generated by the DTG. This is your final dtb
that includes support for your PL design.
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
example-zcu102-zynqmp-system-<timestamp>.dtb example-zcu102-zynqmp-system.dtb -> example-zcu102-zynqmp-system-<timestamp>.dtb |
Device Tree Source
If you want to view the dts
that generated the dtb
, you can either look at the working directory for the device-tree
for your machine or you can reverse the dtb
with the device tree compiler (dtc
). The listing below shows the structure of the build directory for the device-tree. In the build directory you will see the system-top
device tree blob (dtb
), device tree source (dts
) and another file which is the output of the C preprocessor (pp
). Inside of the device-tree
directory you will see the individual files that makeup the final device tree.
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
$ cd tmp/work/example_zcu102_zynqmp-xilinx-linux/device-tree/xilinx+gitAUTOINC+f38738e568-r0/build | [emil@white-out:2018.2 build]$ tree . ├── device-tree │ ├── Base_Zynq_MPSoC_wrapper.bit │ ├── device-tree.mss │ ├── hardware_description.hdf │ ├── pcw.dtsi │ ├── pl.dtsi │ ├── psu_init.c │ ├── psu_init_gpl.c │ ├── psu_init_gpl.h │ ├── psu_init.h │ ├── psu_init.html │ ├── psu_init.tcl │ ├── system-top.dts │ ├── system-user.dtsi │ ├── zcu102-rev1.0.dtsi │ ├── zynqmp-clk-ccf.dtsi │ └── zynqmp.dtsi ├── system-top.dtb ├── system-top.dts └── system-top.dts.pp |
This The listing show below shows how to reverse the final dtb
assuming you have installed the dtc
and it's in your path. The output is system.dts
.
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
$ dtc -I dtb -O dts -o system.dts example-zcu102-zynqmp-system.dtb |
Related Links
Creating a Custom Xilinx Xilinx Yocto Layer
Adding an HDF to a XilinxXilinx Yocto Layer
Xilinx Yocto LayerBuilds without an Internet Connection