PYNQ v3.0.1 Build Failure for ZCU104


  • I try to build a custom PYNQ image for ZCU104 board to enable “AXI Quad SPI” interface which resides in my FPGA design by generating the corresponding device-tree-blob. I have followed this tutorial However, the whole task is terminated with an error, eventhough it creates the petalinux project and the related images part including the image.ub, BOOT.BIN, boot.scr as well as the individual system.dtb file. I analyzed the .dtb file by using the dtc and the resulting device-tree was just merely the default one without the amba_pl section. I checked the obtained system.xsa file that is used to generate petalinux project under the PYNQ/sdbuild/build path to verify that it has been taken from Pynq_Custom board section under the PYNQ/boards path and it was correct.

  • Then, I moved on to search for the cause of the error that terminates the make process. I found that somehow the script goes into the Pynq-Z1 board folder and tries to build logictools layer. As I figured out, to construct logictools layer, there are some custom IPs located under PYNQ/boards/ip/hls path which are awating for to be built by Vivado_HLS. Interestingly, some of those IPs are configured to be built against ZCU702 evaluation board. Even I double checked that this board option is available to create a project in Vivado_HLS, the make process terminates itself by complaining that part “xc7z020clg484-1” was not installed.

  • I downloaded the prebuilt board-agnostic root filesystem, and prebuilt source distribution binaries as “PYNQ rootfs aarch64” and “PYNQ source distribution binary v3.0.1” from the official website to the PYNQ/sdbuild/prebuilt folder with the names of pynq_rootfs.aarch64.tar.gz and pynq-3.0.1.tar.gz, respectively. I prepared my Pynq_Custom board folder by using the default ZCU104 Vivado project as it is suggested in the tutorial that I have mentioned above.

I have used the following command to build the custom image.

~$ make REBUILD_PYNQ_ROOTFS=1 REBUILD_PYNQ_SDIST=1 BOARDS=Pynq_Custom | tee Pynq_Custom_build.log

  • If someone investigate the build log, Pynq_Custom_build.log, that I have attached to this post, a warning message as " Warning … setting REBUILD_PYNQ_SDIST will result in several bitstream and bsp builds …please rerun without REBUILD_PYNQ_SDIST set using latest PYNQ source distribution on PYPI at: https:/ /pypi .org/project/pynq/#files" can be found. However, although the warning suggest me to build without setting REBUILD_PYNQ_SDIST, it is impossible for me to run the make command without setting it, otherwise the condition below happens.

~$ make REBUILD_PYNQ_ROOTFS=1 BOARDS=Pynq_Custom | tee Pynq_Custom_build.log
/opt/qemu/bin/qemu-aarch64-static -version | fgrep 5.2.0
qemu-aarch64 version 5.2.0
Makefile:395: *** REBUILD_PYNQ_SDIST not set and PYNQ_SDIST file /home/p260/PYNQ/sdbuild/prebuilt/pynq_sdist.tar.gz does not exist. Stop.

Pynq_Custom_build.log (2.7 MB)

The ultimate failure message is the below from the Pynq_Custom_build.log file.

Makefile:372: recipe for target ‘/home/p260/PYNQ/sdbuild/output/jammy.aarch64.3.0.1.tar.gz’ failed

I do have other questions about this complex building structure of the project but for now, I just want to clarify the reason for this failure.


  • I tried to build the default PYNQ image for ZCU104 by just providing the xilinx-zcu104-v2022.1-final.bsp file to the PYNQ/boards/ZCU104 directory.

I have used the following command to build the default image.

~$ make REBUILD_PYNQ_ROOTFS=1 REBUILD_PYNQ_SDIST=1 BOARDS=ZCU104 | tee ZCU104_default_build.log

ZCU104_default_build.log (2.7 MB)

It generates the same error message as I mentioned above.

1 Like


See build guide:

Thanks for your reply @briansune ; however, I do not think that the problem is about the project environment. My settings can reach out the path of the Xilinx programmes from /tools/Xilinx/ installation directory properly unlike your suggestion to install them into /home/PYNQ/xilinx path. I also do not think that the linux user name would effect the whole process. Moreover, giving the 777 privilege to the PYNQ/* is not a convenient approach. I have already made sudo passwordless. I also want to emphasize that if you go into the PYNQ/boards/ip/hls path, you can find the script. I manually sourced the Vitis_HLS and executed this bash script. The process terminates itself exactly with the same error that I have mentioned above. You can reach out the log file below.

vitis_hls.log (2.0 KB)

So, I am still open for more elaborated help …


I am not sure what are the root causes of such issue.
However, my method do generate both Ultra Scale ZYNQ and ZYNQ Custom Board with no issue.
So I am also delight to learn what are the reason your environment is failing.

Before you had blinded by your perception.

Did you really read the Image environment of 2.7?
Which directory I am trying to change to 777?
What does chmod 777 means?
How could this is not convenient?
How about chown could this also not convenient?



First, I did not claim that I have read anything about the version 2.7 . The tutorial that I have mentioned is written for version 2.6 .
Second, you can easily find the directory name from your own post under the STEPS title as 3C .
Third, chmod 777 means that you press all the buttons to pass the level in a video game unconsciously.
Fourth, I guess my third answer also includes why it is improper without offering a reasonable explanation for that step.
Fifth, I have never seen anything about chown in your posts. Neither in this nor in this one So, I cannot cooperate with you anymore …


  1. So what are you talking about apple to orange?
  2. Well 3C is referring to git clone so you are wrongly interpreted (no wonder why you could build fail)
  3. chmod is far close to the metaphor you are referring, so simply speaking you have no clue on the number and the chmod really does.
  4. As 3 is not even understand properly no wonder you will described as inconvenient :joy:
  5. As you are having trouble on understanding chmod, chown no wonder is also inconvenient.

Long story short the build script had no issue and PYNQ Revision v3.0.1 have not issue as well.
Highly suggest you go to Linux-based forum to ask Linux based question.
This forum is for PYNQ related issue, while yours are more likely about Linux operations.

ENJOY :joy: :joy: :joy:

OK @briansune , you can now leave this post. I still look for friendly people who can read and understand my question to clarify the “make” process and collaborate on this topic.

Hi @kagdila,

Rebuilding the pynq sdist builds the overlays for pynq-z1 and z2 boards (zynq7000 parts), as well as the zcu104, I assume you don’t have the zynq7000 devices installed on your machine which causes the error.

With the 3.0.1 PYNQ sdbuild, if you’ve downloaded the prebuilt sdist and rootfs, you shouldn’t need to use REBUILD_PYNQ_ROOTFS and REBUILD_PYNQ_SDIST flags. The makefile will be looking for them in the prebuilt folder with very specific names, so I think you just need to rename them to pynq_sdist.tar.gz and pynq_rootfs.aarch64.tar.gz, and do make BOARDS=ZCU104. The prebuilt sdist includes the bitstreams for all the base overlays and logictools, so they shouldn’t get triggered in this build.

Hi @briansune, I’m sure your intent was to help, and maybe some of the intent got lost in translation. Please try to be a bit more considerate with new members of the pynq community… This is where people come for support, not arguments.




Well~ I have no intention to argument from first place.
However, when new member(s) like someone not specific to any body feels it is well known on it situation and yet not really finish reading the material (i.e. README of build guide) then response. Remember Shawn there is no place for such people When the cup is full.

I am very sure this is just a simple command and yet the tutorial had mentioned:
make BOARDS=ZCU104
But why brother? He know very well on what he is doing here.
Well try to do a chmod 440 on PYNQ GIT repository and enjoy life.

As it clearly claimed this is not related to environment setup.
Agree that the log have just simple ERROR message at the end:

ERROR: [HLS 200-1023] Part ‘xc7z020clg484-1’ is not installed.
command ‘create_platform’ returned error code
while executing
“source trace_cntrl_32/script.tcl”
(“uplevel” body line 1)
invoked from within
"uplevel #0 [list source $arg] "

And you can also remove all board build process my removing the script couple of lines like in PYNQ 2.7 image build process.

:joy: :joy: :joy: :joy:


Hi @skalade,

As you mentioned, zynq7000 devices were not installed on my machine so installing them just solved the problem that I have mentioned. I also corrected the prebuilt sdist name as you emphasized. Now, I can execute the make command as below.

~$ make BOARDS=Pynq_Custom

From my understanding, this should be enough to generate the custom dtb including the axi-quad-spi node. However, the petalinux project images folder has the default dtb file still without the amba_pl section. I checked the build log, which is attached below, to observe dtb building process. However, I could not figure out if it is proper or not.

Pynq_Custom_Build_v5.log (53.8 KB)

I also share the custom vivado project block design tcl file below. There is an axi_quad_spi_0 at 0x44A0_0000 master base address.

base.tcl (137.5 KB)

Thank you for your concise help and considerate attitude.

1 Like


DTSI is not set properly, aka DTS → DTB would NOT exist any SPI in device tree.
This is pure Linux build issue, nothing to do with PYNQ.
You should able to set the device tree in the PYNQ GIT repository.

And this no longer related to the original topic of PYNQ v3.0.1 build fail.

Open new post to settle different support issue and follow the rule in this forum accordinly.


Just to clarify, you’ve generated your own BSP and placed it in the boards/Pynq_Custom folder? Could you share what your .spec file looks like?

One way we usually append custom nodes into the devicetree is by editing the system-user.dtsi in the meta-user folder for ZCU104. If all you’re looking for is a single device tree change that might be more straightforward.


1 Like

Hi @skalade,

I constructed the Pynq_Custom folder by modifiying the original ZCU104 folder as follows.

ubuntu18:~/PYNQ/boards/Pynq_Custom$ tree
├── base
│ ├── base.bit
│ ├── base.hwh
│ ├──
│ └──
├── packages
│ └── boot_leds
│ ├──
│ └──
├── petalinux_bsp
│ └── hardware_project
│ └── system.xsa
└── Pynq_Custom.spec

5 directories, 8 files

.spec file is below there.

# Copyright (C) 2022 Xilinx, Inc
# SPDX-License-Identifier: BSD-3-Clause

ARCH_Pynq_Custom := aarch64
BSP_Pynq_Custom :=
BITSTREAM_Pynq_Custom := base/base.bit
FPGA_MANAGER_Pynq_Custom := 1

STAGE4_PACKAGES_Pynq_Custom := xrt pynq ethernet sensorconf boot_leds pynq_peripherals

I also note that PYNQ/sdbuild/build/Pynq_Custom directory includes petalinux_bsp and petalinux_project directories. My petalinux_bsp directory is below. It includes exactly the same system.xsa that I have provided in the board folder.

ubuntu18:~/PYNQ/sdbuild/build/Pynq_Custom/petalinux_bsp$ tree -L 3
├── hardware_project
│ └── system.xsa
├── xilinx-pynqcustom-2022.1
│ ├── build
│ │ ├── bitbake-cookerdaemon.log
│ │ ├── cache
│ │ ├── conf
│ │ ├── config.log
│ │ ├── misc
│ │ ├── package.log
│ │ └── tmp
│ ├── components
│ │ ├── plnx_workspace
│ │ └── yocto
│ ├── config.project
│ └── project-spec
│ ├── attributes
│ ├── configs
│ ├── hw-description
│ └── meta-user
└── xilinx-pynqcustom-2022.1.bsp

14 directories, 7 files

As you mentioned the system-user.dtsi file to modify dtb, I want to clarify that petalinux should normally be able to generate the .dtb according to the provided .xsa design by adding the “platform device nodes” of the included IPs. In my case, I just want to see the master node of the axi-quad-spi-0 not the spi device nodes as something spidev. I know that those controller specific device nodes should be added or adjusted later on.

1 Like


Why not simply check it yourself? ls /sys/bus or ls /sys/device/ to check if the required note exist.
Also dmesg | grep related note after boot and check if there are exist note in the kernel.

BTW this no longer related to build failure of ZCU104

@marioruiz Maybe help to split this post to individual issue (like PYNQ QUAD SPI device note question).

So if you know it will auto generate you can also convert the dtb back to dts to verify yourself after the image compiled and check yourself. By in your case you must know very well. :joy:

dtc -I dtb -O dts <your DTB> -o <dts filename>

You got all your answer but yet keep asking and making trouble to modulators (what do you expect?).


1 Like

Oh ok, looks like you don’t specify a .bsp file in your .spec, so pynq sdbuild generates a minimal bsp for you.

You should package up your petalinux project into a .bsp file, instead of fully populating that petalinux_bsp directory, put it in the same folder as the .spec and set BSP_Pynq_Custom := Pynq_Custom.bsp. There’s a section on preparing the bsp on the pynq sdbuild readme PYNQ/sdbuild at master · Xilinx/PYNQ · GitHub.


1 Like


But Shawn does this really referred to what @kagdila asking?
He is asking about XSA should automatically generate all the necessary device tree nodes.
So either the PetaLinux project he is using is default nor custom build one should not related to what XSA will automatically have the necessary information to generate the DTB. :face_with_raised_eyebrow:


1 Like

Hi @skalade ,

Apparently, the default make process establishes a petalinux project with FPGA Manager enabled which causes to an ignorance of the pl.dtsi and pl-custom.dtsi parts to construct the system.dtb . So, even the custom design IPs are recognized by the project, they are not used to build the device-tree. I can easily alter the behaviour of device-tree construction in normal petalinux. However, PYNQ process somehow does not allow me to include pl part for the dtb section. If you can provide me the part where this pl ignorance happen in the configuration or make scripts, it would be helpful to change that part.



Including additional custom dtsi via #include syntax to exist pl.dtsi and extend the dtsi must be hard
:joy: :joy: :joy: :joy: :joy: :joy: :joy: :joy: :joy:


Don’t think FPGA_MANAGER should prevent your BSP device tree from being parsed, but I might be wrong. You could quickly verify it by setting FPGA_MANAGER to 0 and seeing if that changed the resulting dtb. From what I can recall, based on FPGA_MANAGER setting we append different zocl device tree segments to system-top.dts.

The easiest way to go about it for me would be to read out your generated dtb (like you did with dtc decompilation) and add that segment to PYNQ/system-user.dtsi at master · Xilinx/PYNQ · GitHub in the default ZCU104 board folder, I don’t think you’d need to add anything else to that board folder if all you’re after is the dtb modification.

There’s fairly recent posts on the xilinx forums on that SPI interface as well, where it seems like people have needed to manually edit the device tree, might be helpful if you haven’t come across these yet.

Also for debugging, make sure you do a make clean before building new images, just in case. Some artifacts from previous boot_files builds might prevent it from rebuilding.


According to my analysis on the Makefile, there are three petalinux-project settings which are forced to be set during the building process.


Obviously, the first one removes the pl part of the device-tree. I deleted that part of the script from the Makefile, tried again and nothing had been changed. Then, I deleted the part for the FPGA_MANAGER, tried again and “pl.dtbo” was created along with the “system.dtb”. Finally, I deleted the part of the DTB_OVERLAY, tried again and the full “system.dtb” was generated as I wished for. However, the resulting kernel could not be booted while stucking at “rcu_sched detected stalls on cpus/tasks” error messages.

I think that those three settings are deliberately enforced as they are related with other aspects of this project structure, actually the fundemantel ones , so removing them causes unexpected behaviour.

So at this point, I have seperate components to boot PYNQ which are; the kernel (default), the BOOT.BIN (customized), the system.dtb (customized) and the rootfs (default). I’ll try to use this combination. The only question is, even if the spidev is enabled in the default kernel, I’m suspicious if the rootfs supports it. Cuz when I compare the file structure of devices and drivers for spidev with a successfully running petalinux I have found some differences that may prevent the driver to bind the spidev devices.

I am very glad to see your support @skalade , I’ll check the resources that you have provided.


1 Like