Post Go back to editing

Failure in adding ADRV9009 .dtsi file

Category: Software

Hello All

I am trying to create a Petalinux Image for ADRV9009 on custom board that has Xilinx XCZU9EG. I followed the steps provided at using meta-adi available at and downloaded the linux kernel from I am using the following .dtsi files : adi-adrv9009.dts, zynqmp-zcu102-rev10-adrv9009.dts and zynqmp-zcu102-rev10-adrv9009-jesd204-fsm.dts from and these updates are made in petalinuxbsp.conf file. On building the project, I am receiving an error that adi-adrv9009.dtsi is not available. The screenshot of the error is attached.

Any help on this is highly appreciable.



  • Hi Dheeru,

    I'm looking in to your question, there are multiple ways you can go about doing this. I am, however, unsure of what you are doing or wish to do, specifically.

    Did you take the HDL design for the ADRV9009 with ZCU102 form the ADI github and you ported it to XCZU9EG as is or did you do some changes within the HDL which you want to use with petalinux?

    Do you want to create add your custom dts to the kernel or do you just want to have it used with petalinux and not have it be part of the kernel?

    Do you want to fork meta-adi-xilinx and integrate your changes in your version of the meta layer?

    Depending on your answer I can advise you further. There are multiple ways of doing things and some might be unnecessarily complicated for what you need.


  • Thanks Ciprian for your response.

    The main idea is to have a project that works for our Custom Board which has ADRV9008-2 and ADRV9008-1 interfaced to MPSoC XCZU9EG.

    1. Did you take the HDL design for the ADRV9009 with ZCU102 form the ADI github and you ported it to XCZU9EG as is or did you do some changes within the HDL which you want to use with petalinux?

    Ans. HDL design for ADRV9009-ZCU102 was downloaded from AD Github and it was ported to XCZU9EG with no changes in Block Design. Only .xdc file was changed to meet our board constraints. This modified HDL Project is used with Petalinux.

    2. Do you want to create add your custom dts to the kernel or do you just want to have it used with petalinux and not have it be part of the kernel?

    Ans. Yes. I want to create a custom dts and add the same to the kernel. I am trying to add adi-adrv9009.dtsi as it has a particular profile defined for configuring ADRV9008-2 , ADRV9008-1 and AD9528 and the same shall be reflected in kernel. The idea is, on booting the board, the ADRV9008-1, -2 and AD9528 should be configured in accordance with the configuration set in adrv9009.dtsi. As of now, I have created system-user.dtsi that defines the interfaces other than ADRV9008-1, -2 and AD9528 connected to MPSoC. This system-user.dtsi is also called (#include system-user.dtsi) in the following files : 

    a. zynqmp-zcu102-rev10-adrv9009.dts

    b. zynqmp-zcu102-rev10-adrv9009-jesd204-fsm.dts

    3. Do you want to fork meta-adi-xilinx and integrate your changes in your version of the meta layer?

    Ans. Sorry, I didn't mention about the changes made to meta-adi-xilinx in my previous post. It was observed that meta-adi-xilinx downloaded for 2019 version from didn't support adrv9009.dtsi, so changes to it were made by following this post :  zc706 and AD9136: How to include reference design dtsi file? . The corresponding device-tree.bbappend found in meta-adi-xilinx/recipes-bsp/device-tree was modified by adding  file://pl-delete-nodes-adi-adrv9009.dtsi \ in zynqMP section as a new line and the same is attached:

    FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
    SRC_URI_append_zynq = " \
    		file://pl-delete-nodes-zynq-zed-adv7511-ad9361-fmcomms2-3.dtsi \
    		file://pl-delete-nodes-zynq-zc706-adv7511-ad9434-fmc-500ebz.dtsi \
    		file://pl-delete-nodes-zynq-zc706-adv7511-fmcdaq2.dtsi \
    		file://pl-delete-nodes-zynq-zed-adv7511.dtsi \
    		file://pl-delete-nodes-zynq-zed-adv7511-ad9467-fmc-250ebz.dtsi \
    		file://pl-delete-nodes-zynq-zc706-adv7511.dtsi \
    		file://pl-delete-nodes-zynq-zc706-adv7511-adrv9009.dtsi \
    		file://pl-delete-nodes-zynq-zc706-adv7511-adrv9371.dtsi \
    		file://pl-delete-nodes-zynq-zc706-adv7511-ad6676-fmc.dtsi \
    		file://pl-delete-nodes-zynq-zc706-adv7511-ad9739a-fmc.dtsi \
    		file://pl-delete-nodes-zynq-zc706-adv7511-ad9625-fmcadc2.dtsi \
    		file://pl-delete-nodes-zynq-zc706-adv7511-ad9265-fmc-125ebz.dtsi \
    		file://pl-delete-nodes-zynq-zc706-adv7511-ad9361-fmcomms2-3.dtsi \
    		file://pl-delete-nodes-zynq-zc706-adv7511-ad9361-fmcomms5.dtsi \
    		file://pl-delete-nodes-zynq-zc706-adv7511-fmcomms11.dtsi \
    		file://pl-delete-nodes-zynq-zc706-adv7511-fmcdaq3-revC.dtsi \
    		file://pl-delete-nodes-zynq-zc706-adv7511-fmcjesdadc1.dtsi \
    		file://pl-delete-nodes-zynq-zc706-adv7511-adrv9008-1-jesd204-fsm.dtsi \
    		file://pl-delete-nodes-zynq-zc706-adv7511-adrv9008-2-jesd204-fsm.dtsi \
    		file://pl-delete-nodes-zynq-zc706-adv7511-ad9172-fmc-ebz.dtsi \
    		file://pl-delete-nodes-zynq-zc706-adv7511-adrv9375-jesd204-fsm.dtsi \
    		file://pl-delete-nodes-zynq-zed-imageon.dtsi \
    		file://pl-delete-nodes-zynq-zed-adrv9002.dtsi \
    		file://pl-delete-nodes-zynq-zed-adrv9002-rx2tx2.dtsi \
    		file://pl-delete-nodes-zynq-adrv9361-z7035-bob-cmos.dtsi \
    		file://pl-delete-nodes-zynq-adrv9361-z7035-bob.dtsi \
    		file://pl-delete-nodes-zynq-adrv9361-z7035-fmc.dtsi \
    		file://pl-delete-nodes-zynq-adrv9364-z7020-bob-cmos.dtsi \
    		file://pl-delete-nodes-zynq-adrv9364-z7020-bob.dtsi \
    		file://pl-delete-nodes-zynq-zc702-adv7511-ad9361-fmcomms5.dtsi \
    SRC_URI_append_zynqmp = " \
    		file://pl-zynqmp-zcu102-rev10-ad9361-fmcomms2-3-overlay.dtsi \
    		file://pl-delete-nodes-zynqmp-zcu102-rev10-adrv9009-jesd204-fsm.dtsi \
                    file://pl-delete-nodes-adi-adrv9009.dtsi \
    		file://pl-delete-nodes-zynqmp-zcu102-rev10-fmcdaq2.dtsi \
    		file://pl-delete-nodes-zynqmp-zcu102-rev10-adrv9371-jesd204-fsm.dtsi \
    		file://pl-delete-nodes-zynqmp-zcu102-rev10-ad9361-fmcomms2-3.dtsi \
    		file://pl-delete-nodes-zynqmp-zcu102-rev10-ad9361-fmcomms5.dtsi \
    		file://pl-delete-nodes-zynqmp-zcu102-rev10-fmcdaq3.dtsi \
    		file://pl-delete-nodes-zynqmp-zcu102-hdl-adrv9009.dtsi \
                    file://pl-delete-nodes-zynqmp-zcu102-rev10-adrv9008-1-jesd204-fsm.dtsi \
    		file://pl-delete-nodes-zynqmp-zcu102-rev10-adrv9008-2-jesd204-fsm.dtsi \
    		file://pl-delete-nodes-zynqmp-zcu102-rev10-ad9172-fmc-ebz-mode4.dtsi \
    		file://pl-delete-nodes-zynqmp-zcu102-rev10-ad9081-m8-l4.dtsi \
    		file://pl-delete-nodes-zynqmp-zcu102-rev10-adrv9002.dtsi \
    		file://pl-delete-nodes-zynqmp-zcu102-rev10-adrv9002-rx2tx2.dtsi \
    SRC_URI_append_microblaze = " \
    		file://pl-delete-nodes-fmcdaq2.dtsi \
    		file://pl-delete-nodes-kc705_fmcdaq2.dtsi \
    		file://pl-delete-nodes-kc705_ad9467_fmc.dtsi \
    		file://pl-delete-nodes-kc705_fmcomms2-3.dtsi \
    		file://pl-delete-nodes-kc705_fmcjesdadc1.dtsi \
    		file://pl-delete-nodes-kcu105_fmcdaq2.dtsi \
    		file://pl-delete-nodes-kcu105_adrv9371x.dtsi \
    		file://pl-delete-nodes-kcu105_fmcomms2-3.dtsi \
    		file://pl-delete-nodes-vc707_fmcadc2.dtsi \
    		file://pl-delete-nodes-vc707_fmcomms2-3.dtsi \
    		file://pl-delete-nodes-vc707_fmcjesdadc1.dtsi \
    		file://pl-delete-nodes-vc707_fmcadc5.dtsi \
    python __anonymous() {
        if not d.getVar("KERNEL_DTB"):
            """this is a warn and not fatal because `petalinux-config --get-hw-description` is using
            recipetool to append recipes on the run. With fatal, that process would silently break if
            KERNEL_DTB is not defined at that point which is likely..."""
            bb.warn("KERNEL_DTB is not defined. Your build is likely to fail! \
    Make sure to define it in a conf file...")
    DTB_PL_DELETE ?= "pl-delete-nodes-${KERNEL_DTB}"
    DTS_INCLUDE_PATH_zynq = "${STAGING_KERNEL_DIR}/arch/${ARCH}/boot/dts"
    DTS_INCLUDE_PATH_zynqmp = "${STAGING_KERNEL_DIR}/arch/${ARCH}/boot/dts/xilinx"
    DTS_INCLUDE_PATH_microblaze = "${STAGING_KERNEL_DIR}/arch/${ARCH}/boot/dts"
    # zynq has some corner case where this will be overwritten
    DTB_TAG_FILE ?= "${DT_FILES_PATH}/system-top.dts"
    # zynqMP has some corner cases where this will be overwritten
    DTB_TAG_FILE_zynqmp ?= "${DTS_INCLUDE_PATH}/zynqmp-zcu102-revA.dts"
    # Only used when FPGA_MANAGER is enabled. These are only some defaults. Note that, for example, for Microblaze
    # vc707.dts won't be a good choice if your platform is based on kc705 for instance...
    DTS_BASE_zynq ?= "${DTS_INCLUDE_PATH}/zynq-zc706"
    DTS_BASE_zynqmp ?= "${DTS_INCLUDE_PATH}/zynqmp-zcu102-rev1.0"
    DTS_BASE_microblaze ?= "${DTS_INCLUDE_PATH}/vc707"
    DTS_OVERLAY ?= "pl-${KERNEL_DTB}-overlay.dtsi"
    # Make sure that the kernel sources are available
    do_configure[depends] += "virtual/kernel:do_configure"
    # Important for the pre-processor
    # For dtc
    		-i${DTS_INCLUDE_PATH} \
    # Based on the selected device tree, this function will:
    #	copy the device tree to ${WORKDIR}/system-user.dtsi since it is the one included by the top level device tree.
    #	overwrite the ${DT_FILES_PATH}/system-top.dts with the selected devicetree.
    #	add the pl.dtsi so that IPs added to our reference designs are also included.
    #	Add the /include "pl-delete-nodes-*" to remove all the duplicated labels between ADI device trees and pl.dtsi.
    #	Include system-user.dtsi at the end of the devicetree so users can extend it.
    do_configure_append() {
    	local dtb_tag_file=${DTB_TAG_FILE}
    	[ ! -e "${WORKDIR}/${DTB_PL_DELETE}.dtsi" ] && \
    		{ bbfatal "Error: Could not find \"${DTB_PL_DELETE}.dtsi\" in \"${WORKDIR}\""; }
    	# Used to see if the PL part is being compiled as an overlay! In that case, we cannot apply our normal workflow since it would fail!
    	# We try to keep the approach used by petalinux here, which is, if you build your PL as an overlay, then you should just have a
    	# base devicetree capable of booting the system as if no bitstream is present on the device...
    	if grep -qse "/plugin/;" "${DT_FILES_PATH}/pl.dtsi"; then
    		cp "${DTS_BASE}.dts" "${DT_FILES_PATH}/system-top.dts"
    		if [ ! -e "${DTS_OVERLAY_PATH}/${DTS_OVERLAY}" ]; then
    			bbwarn "PL is being built as an overlay but no user overlay was found! The default one generated by petalinux is being used..."
    			return 0
    		echo "/include/ \"${DTB_PL_DELETE}.dtsi\"" >> "${DT_FILES_PATH}/pl.dtsi"
    		echo "#include \"${DTS_OVERLAY}\"" >> "${DT_FILES_PATH}/pl.dtsi"
    		return 0
    	[ ! -e "${KERNEL_DTB_PATH}/${KERNEL_DTB}.dts" ] && \
    		{ bbfatal "Error: Could not find selected device tree:\"${KERNEL_DTB}.dts\" in:\"${KERNEL_DTB_PATH}\"!!"; }
    	cp "${KERNEL_DTB_PATH}/${KERNEL_DTB}.dts" "${DT_FILES_PATH}/system-top.dts"
    	# corner cases
    	case "${KERNEL_DTB}" in
    	# The only way to make sure that the pl.dtsi + pl-delete-nodes logic is not breaking the selected
    	# devicetree is to include pl.dtsi right after the devicetree tag. Hence, this logic is the first
    	# thing to be included. If there are errors, then [most likely] the problem should be in the pl-delete-nodes
    	# (or in the petalinux logic to autogenerate pl.dtsi).
    	# FIXME: For projects where the top devicetree does not hold the tag, this process will directly change the
    	# files on the fetched kernel tree. We should think of mechanism to avoid this or, at least, to bring the file
    	# to it's default after we are done...
    	if ! grep -qse "pl.dtsi" "${dtb_tag_file}"; then
    		sed -i '0,/\/dts-v1\/;/s//&\n#include "pl.dtsi"/' "${dtb_tag_file}"
    	echo "/include/ \"${DTB_PL_DELETE}.dtsi\"" >> "${DT_FILES_PATH}/pl.dtsi"
    	# As it turns out, system-conf.dtsi has some autogenerated nodes that we can use. Specially, the chosen node since
    	# petalinux automatically generates proper bootargs depending on the project configuration (eg: use initramfs or sdcard as rootfs).
    	# This will make things work out of the box without having to care with uEnv.txt for instance. On the other hand, this file also
    	# defines the qspi partitions which conflicts with our devicetrees. Hence, the next command removes the the &qspi node...
    	# We also need to delete the axi_ethernet node as for some platforms we get nodes with names different from axi_ethernet which is
    	# the one used in our devicetrees. Hence, since all PL nodes are removed, we will get a compilation error if referenced...
    	# sed -i '/&qspi/,/^$/d; /&axi_ethernet/,/^$/d' "${DT_FILES_PATH}/system-conf.dtsi"
    	# add the user dts extension
    	echo "#include \"system-user.dtsi\"" >> "${DT_FILES_PATH}/system-top.dts"

    and a new file with pl-delete-nodes-adi-adrv9009.dtsi was created and added to meta-adi-xilinx/recipes-bsp/device-tree/files (which is attached) :

    /include/ "pl-delete-nodes-zynqmp-zcu102-hdl-adrv9009.dtsi"

    These dtsi files are then specified in petalinuxbsp.conf. On building the project, I am observing an error as adi-adrv9009.dts is not found and the build fails. (The screenshot of error is attached in previous post).

    I hope, I am following the right steps.

    Seeking your guidance.


  • Hello Ciprian, requesting your response.

  • Hi Deepika,

    The issue you presented is pretty tangled and it took me a while understand the root cause of it.

    By using petalinux with our meta-adi we have 3 sources of device trees which all come together in the end.

    Device tree in the kernel

    The kernel has a set of device trees which are device, board and device+board specific. in this case the adi-adrv9009.dtsi (device specific), the zynqmp-zcu102-rev1.0.dts (board specific), the zynqmp-zcu102-rev10-adrv9009.dts (bloard+device; this includes the adi-adrv9009.dtsi and zynqmp-zcu102-rev1.0.dts) and in this case we also have a framework specific device tree: zynqmp-zcu102-rev10-adrv9009-jesd204-fsm.dts (this includes zynqmp-zcu102-rev10-adrv9009.dts and makes some JESD specific configurations).

    This structure allows for mixing and matching boards with devices. Typically you only build the framework device tree which includes all of the previous dtsi and dts files, this is also why in the adi-meta you have support for zynqmp-zcu102-rev10-adrv9009-jesd204-fsm.dts and not for zynqmp-zcu102-rev10-adrv9009.dts.

    Device tree in Petalinux

    There is allot to unpack here and I will not go in to details, you should read ug1144 in the advanced configurations chapter for more details. The important thing to know is that build process reads the hdf/xsa and automatically creates a pl.dtsi which contains all the nodes in the PL. Petalinux is designed in such a way that you can and should override these nodes in the system-user.dtsi which is part of your user defined layer. As you can imagine, the pl.dtsi doesn't know any of the right configurations of the IPs or driver specific params.

    Device tree in meta-adi

    The set of device trees in this layer are all called pl-delete-nodes-<name of the supported board>.dtsi. As the name suggests this will delete nodes, important to note here is that it will delete nodes from the pl.dtsi (previously mentioned). Therefore this a layer on top of the petalinux layer, it will read the pl.dtsi and delete all the nodes specified in the pl-delete-nodes-<name of the supported board>.dtsi from the pl.dtsi.

    Further more meta-adi will import the <name of the supported board>.dts from the kernel and use that one instead.


    This brings us to your initial issue and questions. By adding pl-delete-nodes-adi-adrv9009.dtsi to the meta-adi it will also search for adi-adrv9009.dts in the kernel. Which is not found and it fails. It is also better for your particular design to add zynqmp-zcu102-rev10-adrv9009.dts rather the adi-adrv9009.dtsi as it contains board specific configuration as well.

    Which leaves you with a couple of options:

    Option 1

    Add support only for the zynqmp-zcu102-rev10-adrv9009.dts by following the steps suggested  zc706 and AD9136: How to include reference design dtsi file? and then use the system-user.dtsi (in your petlinux project) for any further changes you want to do.

    Option 2

    Otherwise you can create your own custom dts in the kernel on a fork, replace the kernel path here with your own kernel fork. The you need to create pl-delete-nodes-<name of the custom dts>.dtsi in which you delete the nodes (you can copy this from here as it should be the same). This should then act as if you are using the the meta-adi layer with a custom kernel and custom pl-delete-nodes.

    Option 3 (only in the worst case scenario)

    Do not use meta-adi and import everything manually. Use petalinux-config to set the kernel to the adi github repo, and then use system-user.dtsi to configure your device-tree. This is a bad option because in this case you will have to write everything manually that is specific to the device tree and you have to import the rest of the recipes which you want to have in the build.... its a hassle.

    Hope this helps you with your project.


  • Thanks Ciprian for the elaboration. It has clarified my doubts with respect to various .dtsi files. 

    Will surely try option 1 and 2.


  • hi    ,

    we have the similar mistake. please let me introduce step-by-step.

    we use adrv9009 with zcu106, with baremetal everything is ok.

    clone HDL


    for zcu106 we porting from zcu102 to zcu106 for version 2021,1 we look, Porting ADI's HDL reference designs


    2) check the hardware(zcu106 with EVAL-ADRV9008/9) with  baremetal


    3) for linux OS export xsa, name our_hdl_zcu106.xsa,


    4) with petalinux from

       a) petalinux-create -t project --template zynqMP --name adrv9009adi


      b)git clone
      c)cd adrv9009adi
      d)we running petalinux-config –get-hw-description=../our_hdl_zcu106.xsa
        Go to Yocto Settings->User layers and add the 
        meta-adi-core layers

         e) Adding a new Devicetree

         cd build

      this generate pl.dtsi in components/plnx_workspace/device-tree/device-tree/pl.dtsi


    f) we create the file, pl-delete-nodes-zynqmp-zcu106-hdl-adrv9009.dtsi

       we add from pl.dtsi in pl-delete-node-zynmp-zcu106-hdl-adrv9009.dtsi

    /delete-node/ &axi_adrv9009_rx_clkgen;

    /delete-node/ &misc_clk_0;

    /delete-node/ &axi_adrv9009_rx_dma;

    /delete-node/ &axi_adrv9009_rx_jesd_rx_axi;

    /delete-node/ &axi_adrv9009_rx_os_clkgen;

    /delete-node/ &axi_adrv9009_rx_os_dma;

    /delete-node/ &axi_adrv9009_rx_os_jesd_rx_axi;

    /delete-node/ &axi_adrv9009_rx_os_xcvr;

    /delete-node/ &axi_adrv9009_rx_xcvr;

    /delete-node/ &axi_adrv9009_tx_clkgen;

    /delete-node/ &axi_adrv9009_tx_dma;

    /delete-node/ &axi_adrv9009_tx_jesd_tx_axi;

    /delete-node/ &axi_adrv9009_tx_xcvr;

    /delete-node/ &axi_sysid_0;

    /delete-node/ &rx_adrv9009_tpl_core_adc_tpl_core;

    /delete-node/ &rx_os_adrv9009_tpl_core_adc_tpl_core;

    /delete-node/ &tx_adrv9009_tpl_core_dac_tpl_core;


    g) export dts_to_use=zynqmp-zcu106-hdl-adrv9009


    *zynqmp-zcu106-hdl-adrv9009.dts attached file

    we put in adrv9009adi/project-spec/meta-user/recipes-bsp/device-tree/files

    h)echo "KERNEL_DTB=\"${dts_to_use}\"" >> project-spec/meta-user/conf/petalinuxbsp.conf


    i) we configure in adrv9009adi/project-spec/meta-user/recipes-bsp/device-tree/device-tree.bbappend



    SRC_URI_append = " file://pl-delete-nodes-zynqmp-zcu106-hdl-adrv9009.dtsi file://zynqmp-zcu106-hdl-adrv9009.dts"

    python () {

    if d.getVar("CONFIG_DISABLE"):

    d.setVarFlag("do_configure", "noexec", "1")


    export PETALINUX

    do_configure_append () {



    eval xsct -sdx -nodisp ${script} -c ${WORKDIR}/config \

    -hdf ${DT_FILES_PATH}/hardware_description.${HDF_EXT} -repo ${S} \

    -data ${data} -sw ${DT_FILES_PATH} -o ${DT_FILES_PATH} -a "soc_mapping"



    j) cd build



    please, can you help me?


  • Hi   ,

    Although you the topic is the same as this thread, you tried something else, thus the solution will be different for you. The risk is that if I answer your question here it will be buried in this topic. If somebody else has the exact same issue as you, that person will not have a straight answer.

    Could you please open a new question for this, tag me in the new question, and add a link to it here for people who might be interest in this as well?