Novel Issues: Quick Porting of PYNQ using Pre-built images

Continuing the discussion from Quick Porting of PYNQ using Pre-built Images:

Love your show, Peter! These types of posts are very helpful.
I’ve been trying to build the ZC706 PYNQ 2.7 port by following the instructions in this post to the letter, and can’t find the “board-agnostic rootfs image” for PYNQ 2.7! There is no *.img file, as in this post, only a *.tar.gz file. I would like to use that, but in the full process, the one that uses make, instead of, I run into exactly the same problem described here Package not found when making image - Support - PYNQ – even though I am already using Ubuntu 18.04.6 LTS!

Some clarification would be terrific. Even though I was able to use your post to generate PYNQ 2.5 for the ZC706, I had to look far and wide across the Interwebs to find the file bionic.arm.2.5.img. It should not be this hard! It would be terrific if the Xilinx gang supporting PYNQ would create sticky links that allow recreation of the post, especially since it’s only just over two years later!

Bottom line: I need to be able to perform this procedure for PYNQ 2.7, which seems to indicate I need to find the elusive “focal.arm.2.7.img” file.

Thank you in advance for your assistance!

1 Like

Hi there,

As of v2.7 all board agnostic images are in tarball (tar.gz) form rather than .img. Functionally it makes no difference to the build scripts so the file you use just has a different extension.

In the post you linked, I believe the problem was a tool version incompatibility – since you were able to build a v2.5 image, I presume you were using Vivado 2019.1 and a BSP of the same version? When building for the v2.7 image, are you using a 2020.2 version of the tools and BSP?



In case toy need to setup the environment to build any image under 2.7 revision:
I enclosed a full details on setting up the env:

Don’t try Vagrant as it can result so many variations on different PC and hard drive right etc.

1 Like


Thank you for your speedy reply! Vitis and petalinux are both 2020.2. The problem I am wrestling with is that called out a number of packages that were not installed and/or the incorrect version. (Especially a bunch of packages that are Ubuntu 18.04.06 and not bionic versions–wait, I thought they were the same thing?)

I was hoping that would avoid these requirements, but if it just ends up running a modified “Make” process, I would have the same problems anyway. In any event, forcing installation with aptitude ended up corrupting the kernel, so now this is an Ubuntu problem rather than PYNQ. After I reset my VirtualBox, I will update with another error, or report success.

Thanks again for your response!

@briansune had the answer. Running is the way. It’s well-written, and picks up and installs the correct versions of dependency applications, including in particular qemu and crosstool-ng.

Turns out the problem I had with VirtualBox was that aptitude, in its zeal, had broken xserver. Ubuntu would boot up, but the keyboard and mouse had zero effect. Lesson learned–stay with!

Now I have another show-stopping issue. I am following the instructions at PYNQ SD Card image — Python productivity for Zynq (Pynq), which reads as follows:

To customise the BSP a petalinux_bsp folder can be included in the board directory the contents of which will be added to the provided BSP before the project is created. See the ZCU104 for an example of this in action. This is designed to allow for additional drivers, kernel or boot-file patches and device tree configuration that are helpful to support elements of PYNQ to be added to a pre-existing BSP.

If a suitable PetaLinux BSP is unavailable for the board then BSP_${BOARD} can be left blank; in this case, users have two options:

  1. Place a <design_name>.xsa file in the petalinux_bsp/hardware_project folder. As part of the build flow, a new BSP will be created from this XSA file.
  2. Place a makefile along with tcl files which can generate the hardware design in the petalinux_bsp/hardware_project folder. As part of the build flow, the hardware design along with the XSA file will be generated, then a new BSP will be created from this XSA file.

Note the phrase “two options.” There’s no “or” at the end of item #1 (which is the one I chose), but it’s implied from listing them as “options.” But when I run
make BOARDS=ZC706 PREBUILT=/media/sf_ZC706_shared/focal.arm.2.7.0_2021_11_17.tar.gz

I get the following output (in pertinent part):

vivado -mode batch -source \
zc706.tcl build_bitstream.tcl -notrace

****** Vivado v2020.2 (64-bit)
  **** SW Build 3064766 on Wed Nov 18 09:12:47 MST 2020
  **** IP Build 3064653 on Wed Nov 18 14:17:31 MST 2020
    ** Copyright 1986-2020 Xilinx, Inc. All Rights Reserved.

source zc706.tcl -notrace
couldn't read file "zc706.tcl": no such file or directory
INFO: [Common 17-206] Exiting Vivado at Thu May 26 19:40:07 2022...
makefile:10: recipe for target 'bit' failed
make[1]: *** [bit] Error 1
make[1]: Leaving directory '/home/jim/PYNQ/sdbuild/build/ZC706/petalinux_bsp/hardware_project'
Makefile:343: recipe for target '/home/jim/PYNQ/sdbuild/build/ZC706/petalinux_bsp/xilinx-zc706-2020.2.bsp' failed
make: *** [/home/jim/PYNQ/sdbuild/build/ZC706/petalinux_bsp/xilinx-zc706-2020.2.bsp] Error 2

Seems like the two “options” listed are both requirements! Another post Pynq 2.6 custom board image build method that works - Learn - PYNQ indicates that instead of <design_name>.xsa this file should be named system.xsa, but the same error occurred.

Again, clear direction is requested! If the XSA file and the TCL file are both required, just say that!

So the ENV setup following my steps are working?

From my experience the name of the xsa dont matter as it will rename it if it is unique on the folder.

For this don’t put this is the sharing folder right might lead to issue as well.
Move to location home and rerun again.

$(BUILD_ROOT)/PYNQ/ remove line started @105 to 165
to reduce the build of other unnecessary board and licensing issue.
Try make with the same setting without clean and ensure remove these lines.
Usually check ps -a and ensure there are no background vivado is running.