Creating Pynq for custom board gives error

Support
1

I followed the instructions to create a new custom board found here:

The board is the Avent Ultrazed-EV. I used the ZCU104 design as the basis for my own design. They have enough similarities that the port should be relatively straightforward.

The makefile in the sdbuild directory runs nearly to completion but I get an error that says:

+ sudo cp dist/pynq-2.5.1.tar.gz /home/nichodd1/Projects/PYNQ/sdbuild/build/bionic.Ultrazed-EV/home/xilinx/pynq_git/dist
cp: error writing '/home/nichodd1/Projects/PYNQ/sdbuild/build/bionic.Ultrazed-EV/home/xilinx/pynq_git/dist/pynq-2.5.1.tar.gz': No space left on device

When I run df -h it confirms that the problem is that the mount is completely full:

/dev/mapper/loop35p2 6.8G 6.8G 0 100% /home/<USERNAME>/Projects/PYNQ/sdbuild/build/bionic.Ultrazed-EV

I tried modifying the line in create_mount_img.sh from this:

truncate --size 7G $image_file

to this:

truncate --size 15G $image_file

This did not help. Originally the mount seems to have the correct size (15G) but later in the build process this gets reduced to ~6G. Then the build fails with the same “No Space Left on Device” error.

2

Changing the truncate size should have been sufficient. Did you clean out the old images from the build directory before restarting?

There is a very final stage that resizes the image back down but that only happens once all of the copying has been completed.

Peter

3

I unmounted the FS and did a ‘sudo make clean’ in sdbuild. Then after a rebuild, I get the same error. Early in the build process this is the output from df -h:

Filesystem            Size  Used Avail Use% Mounted on
udev                   63G     0   63G   0% /dev
tmpfs                  13G  4.3M   13G   1% /run
/dev/sda3             1.9T  499G  1.3T  29% /
tmpfs                  63G     0   63G   0% /dev/shm
tmpfs                 5.0M     0  5.0M   0% /run/lock
tmpfs                  63G     0   63G   0% /sys/fs/cgroup
/dev/loop1            2.3M  2.3M     0 100% /snap/gnome-system-monitor/148
/dev/loop0            256M  256M     0 100% /snap/gnome-3-34-1804/36
/dev/loop2             63M   63M     0 100% /snap/gtk-common-themes/1506
/dev/loop3            2.5M  2.5M     0 100% /snap/gnome-calculator/748
/dev/loop4            141M  141M     0 100% /snap/gnome-3-26-1604/100
/dev/sda1             476M  6.1M  470M   2% /boot/efi
/dev/loop5             98M   98M     0 100% /snap/core/9289
/dev/loop6            1.0M  1.0M     0 100% /snap/gnome-logs/100
/dev/loop7             55M   55M     0 100% /snap/core18/1754
/dev/loop8            384K  384K     0 100% /snap/gnome-characters/550
tmpfs                  13G   28K   13G   1% /run/user/126
tmpfs                  13G     0   13G   0% /run/user/1000
/dev/mapper/loop36p2   15G  930M   13G   7% /home/<UNAME>/Projects/PYNQ/sdbuild/build/bionic.aarch64
/dev/mapper/loop36p1  100M     0  100M   0% /home/<UNAME>/Projects/PYNQ/sdbuild/build/bionic.aarch64/boot

You can see that the truncate command worked as I expected.

4

Are you able to post the full output of make? I don’t understand why you’re seeing this.

Peter

5

That took a few hours to recreate but attached is the full dump of the make process that fails:

output.txt (2.5 MB)

6

It looks like something weird is going on with stale images - that’s the only explanation I have for the loop device numbers being 42 and 43 for the first two stages and then falling back to 35 for last. Can you get the output of losetup -a?

Peter

7

You are correct that there were a bunch of stale loop devices. I was able to clear them with these commands:

dmsetup remove_all
losetup -d <MOUNT_POINT>

I reran make but got the same error. The problem was not the stale mounts. Again I have attached a copy of the output log.

1 Like
8

I can concur that I am having the same issue when using v2.5 as a base for building from source. losetup -a output is empty, I have increased the size limit to 15GB in create_mount_img.sh and I get the same error (insufficient disk space). For reference, I am using an Ultra96v2 board from AVNET.

9

@annapCoug @Joe_Dinius In one of our building steps, the board folder will be copied over to the build area; so make sure you do not have any unnecessary file staying in that board folder (for example, a complete vivado project sitting in the board folder - try to make clean it before you run sdbuild). If you have some large files in the board folder, they can be copied accidentally by our SDbuild flow, which results in insufficient disk space for the rootfs.

10

My build process is quite simple:

  • Unmount dangling drives (as an aside: shouldn’t the build process clean this up automatically, maybe as part of the checkenv target in the Makefile? I know this would require running make checkenv as sudo, which is less than desirable)
  • Run make clean
  • Run make BOARDDIR={path-to-my-board-dir}

But the issue persists nevertheless. Any other thoughts @rock?

11

make clean probably only cleans your SD build folder, but you need to clean your BOARD folder as well. Make sure there is no large file in your board folder (Ultra96 in your case). If you have built a hardware design in your ultra96 folder, clean it and leave only sensor96b.bit and sensors96b.hwh files there.

12

@rock had the right answer in my case. I had a non .bsp version of Petalinux in the board folder and a build version of the Vivado project. I wrongly assumed the tools would be judicious about what files/folders to copy over.

Then again the makefile is the worst kind of makefile. The dependencies are all wrong or incomplete. It doesn’t do necessary cleanup when the build fails. Pynq’s build system is pretty bad. Perhaps it is telling that Xilinx doesn’t support Pynq through its Service Request system.

1 Like
13

We apologize for your frustration. Can you provide some ideas on how we improve it? Or you can just submit pull requests to improve it yourself? I don’t want to make an excuse but we are a small group of roughly 4 people and our hands are pretty tight.