Custom PYNQ board/image won't configure (PL?) properly

Support
1

Hi.
I’m porting PYNQ to a custom board from board agnostic rootfs. I’m using PYNQ 2.5.4 (but similar results with 2.5.1). Vivado/Petalinux 2019.1 (last SDK edition). The board has Ethernet on EIO interface, one GPIO LED that should light on startup, and an LED on done_0.

I have successfully built Petalinux, and generated a boot image that boots fine (ethernet functional, LED and done_0 fine). I used the Petalinux config to create a BSP archive successfully.

I used this to generate a PYNQ image.
I created under ~/PYNQ/boards my custom board tree:
/myboard
myboard.bsp
myboard.spec

ARCH_ebaz_new = arm
BSP_ebaz_new = ebaz_new.bsp
STAGE4_PACKAGES_ebaz_new = pynq ethernet

Build commands:

export PATH=“/opt/crosstool-ng/bin:/opt/qemu/bin:$PATH”
source /tools/Xilinx/Vivado/2019.1/settings64.sh
source /tools/Xilinx/SDK/2019.1/settings64.sh
source ~/petalinux/2019.1/settings.sh
petalinux-util --webtalk off
make PREBUILT=~/Downloads/bionic.arm.2.5.img PYNQ_SDIST=~/Downloads/pynq-2.5.tar.gz BOARDS=myboard BOARDDOR=~/PYNQ/boards/

The build completes successfully. I copy the image to an SDcard with win32discimager successfully, and the image boots to PYNQ linux. However, I have no eth hardware identified, no gpio LED, and worst, done_0 LED remains off.

What went wrong? surely, if petalinux knows to configure the Zynq, some definition is over-ridden in PYNQ, but i have no idea where to find it.

Any help will be much appreciated!

Cheers.

1 Like
2

You must manually program FPGA in PYNQ via overlay. (If fpga manager is on)
from pynq import Overlay
ol = Overlay(“…/folder/mybitstream.bit”)
and in is → /folder/mybitstream.bit and /folder/mybitstream.hdf

If you have EMIO ethernet you could have problems with runtime reconfiguration and drivers detecting a new ethernet port. You could try to create device-tree overlay (Eclypse-Z7 PYNQ porting guide - Hackster.io - creating device-tree-overlay with pynq-prio) as I said ZMOD drivers doesn’t work with reconfiguration, and they got detected, but driver itself wouldn’t work.

In pynq 2020.1 there is an option to disable FPGA-Manager (and by it reconfiguration) so FPGA would be programmed on start and all drivers should work without an issue.

There is also another way… to create custom boot.bin with fpga bitstream in it.

1 Like
3

Thanks. This is useful information. Assuming I’m going the PYNQ 2.6 route and disabling the FPGA manager, is there implication on adding and loading overlays later?
Tnx

4

You can’t switch bitstream runtime e.g. No reconfiguration.

I don’t know options regards device-tree overlays.
You could check meta-pynq and see what is changed in petalinux project.

5

I see. I’m probably OK with not being able to switch bitstreams runtime. This wouldn’t hurt my ability to load overlays runtime, right? i.e. use the my PYNQ build to load for e.g. LEDs, buttons, Microblaze core etc. without needing to rebuild PYNQ image.

6

Yes you don’t need to rebuild whole image just change bitstream in boot.bin.

Pynq 2.6 has an option to load bitstream at system start, so you will need to change it.
You will need to read about this option somewhere in Pynq documentation.

So how overlay works? It gets metadata from Vivado about memory mapped IP’s so for example.
You would have loaded bitstream A and load .hdf of Bitstream A all will work properly.

Now you are trying to change design and load .hdf for Bitstream B, while Bitstream A is loaded at startup, overlay won’t load/work because of wrong bitstream.

From 2020.1 all metadata (with bitstream) is integrated in .XCLBIN
If you are using Vitis sdsoc/accel flow and use wrong .XCLBIN to program accelerators system will crash :slight_smile:

7

Hi, thanks again for the info. I just found out that the FPGA manager can be disabled in PYNQ 2.5.4 as well: For v2.5 is there a way to have it load a bitstream during power-up like it did in prior versions of PYNQ? - Support - PYNQ. Since my design is in Vivado 2019.1 I might stick to it.

So… I read the overlays section and now I’m a bit confused. Let’s say that I have a base design. Now, I design two different overlays. One with LED control IP, and a second with Button sense IP. Just to clarify: at any given moment only ONE of overlays (LED)/(Button) can be loaded?

The way I now understand it then is: if I wanted to use the buttons to control the LEDs I’d need to either write a single overlay with both IPs or perform (rather slow) online bitstream runtime reconfiguration. Correct? The manual is a bit obscure about this point.

1 Like
8

By initializing an overlay (and thus downloading it to fpga) you will reprogram the whole system. Reconfiguration takes like 80ms and in this time drivers for ethernet could crash (or not).

If you have a base design and add extra IP, full reconfiguration will still occur, so we are back to square one.

You could use partial reconfiguration and manage these reprogrammable block independently of the system (I didn’t do that before). Pynq doesn’t care what you change is just reprograms and map IP’s in memory. Your best solution is to use partial reconfiguration and put there Button and LED IP.

at any given moment only ONE of overlays (LED)/(Button) can be loaded?
Depends… you can have them in system memory and reprogram full FPGA on the go that means only one active overlay at the time Or use 2 or more Pblocks and use them independent.

1 Like
9

Understood. Thanks for the clear explanation.
So… it appears that specifically for boards that use PL lines for ethernet there may be some pitfalls regarding ethernet interface connectivity due to the (possible) reprogramming of PL on overlay load.
For my use case this is probably not important, and possibly can be overcome by doing partial reconfiguration, but users should be aware.

Please feel free to comment/correct if I got it wrong.
Thanks!