Versions Compared

Old Version 1

changes.mady.by.user Emil Lenchak

Saved on

compared with

New Version 2

changes.mady.by.user Emil Lenchak

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Table of Contents
excludeTable 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
languagebash
themeMidnight
titledevice-tree.bbappend
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
languagebash
themeMidnight
titlesystem-user.dtsi (dummy)
/* system-user.dtsi */


Code Block
languagebash
themeMidnight
titleexample-zcu102-zynqmp
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
languagebash
themeMidnight
titledeploy (dtb from kernel dtb)
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
languagebash
themeMidnight
titledeploy (dtb from DTG)
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
languagetext
themeMidnight
titlebuild/device-tree
$ 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
languagebash
themeMidnight
titledtc
$ dtc -I dtb -O dts -o system.dts example-zcu102-zynqmp-system.dtb

Creating a Custom Xilinx Xilinx Yocto Layer

Adding an HDF to a XilinxXilinx Yocto Layer

Xilinx Yocto LayerBuilds without an Internet Connection