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 https://discuss.pynq.io/t/pynq-2-6-custom-board-image-build-method-that-works/2894 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.
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 build_ip.sh 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.
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 https://discuss.pynq.io/t/stuck-at-extract-yocoto/4134/8 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 https://discuss.pynq.io/t/pynq-3-0-1-virtualbox-install-and-sd-build/4859 nor in this one https://discuss.pynq.io/t/stuck-at-extract-yocoto/4134/8 So, I cannot cooperate with you anymore …
Well 3C is referring to git clone so you are wrongly interpreted (no wonder why you could build fail)
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.
As 3 is not even understand properly no wonder you will described as inconvenient
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.
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.
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.
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.
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.
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.
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.
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.
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?).
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.
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.
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.
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.
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.
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.
