Device tree issues with PYNQ on Custom Board

I’m attempting to build a PYNQ image for a HiTech Global board, which is a ZYNQ UltraScale+. What do I do with the device tree file and “recipes-bsp” package I have to get the build flow and PetaLinux to work with them?

For reference, I am building a 2.6.0 image with Xilinx 2020.1 tools and using Ubuntu 18.04.4

Do you have a BSP? If so, can you follow this?:


Hi Cathal,

I don’t have a BSP. I do have an XSA and bitstream generated from Vivado. I’d like to get the make sequence to build the BSP for me.


Here’s an update:

The current file tree I have in PYNQ/boards/HTG-ZRF8 is as shown:

├── htg_zrf8.bit
├── HTG-ZRF8.spec
└── petalinux_bsp
    ├── hardware_project
    │   └── htg_zrf8.xsa
    └── meta-user
        ├── COPYING.MIT
        ├── README
        └── recipes-bsp
            ├── device-tree
            │   ├── device-tree.bbappend
            │   └── files
            │       ├── pl-custom.dtsi
            │       └── system-user.dtsi
            ├── fsbl
            │   ├── files
            │   │   └── 0001-Patch-to-add-1-sec-delay-after-bitstream-download.patch
            │   └── fsbl_%.bbappend
            └── u-boot
                ├── files
                │   └── platform-top.h
                └── u-boot-xlnx_%.bbappend

When I boot, I get a kernel panic about being unable to mount filesystem mmcblk0p2. I checked in U-Boot, and that is the correct device to boot from. When I strip down the bootargs to just root=/dev/mmcblk0p2 then I am able to boot, but only into a read only filesystem with no ethernet.

In what may be a related issue, when I run an lsblk from the read only system I booted, the SD card (which is 32 GB) has 2 partitions. The boot partition is 100 M, but the other filesystem partition is only 6.6GB, and the rest of the device is unallocated.

Have you ever seen this when trying to build PYNQ for a custom board? I feel like I’m close but have something set up for the make sequence slightly wrong.

This issue was resolved. An error was found when generating the Vivado XSA that was causing a kernel panic on boot.

1 Like