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
1

Hi,

For v2.5 PYNQ during OS boot a bitstream/Overlay is no longer loaded into the PL. But what if I wanted to have it load one? Is there a non-volatile script or service that can be enabled to restore the old (prior to v2.5) behavior?

Thank you

1 Like
2

There are many ways to do that. Image v2.5 refrains from loading bitstreams because it uses FPGA manager framework and device tree overlay, which does not load bitstream during boot.

I think the best practice for users is to have a systemctl service which calls out to customized script, which you can enable during boot time. This time your overlay is loaded during linux boot but not first stage boot (unless you really want to do that; in most cases, loading bitstreams in linux boot is enough).

Is there a reason why you would want to bitstream to load during boot?

1 Like
3

Hi Rock,

Thanks for the reply. One use case would be to simply power up a design or demo that can start running without any user input. Another related one would be: perhaps there is a mezzanine attached that won’t operate correctly without some PL pins being pulled to the right state and the sooner after boot / power-up that occurs the better.

Kind regards

1 Like
4

I’m using a SnickerdoodleBlack/piSmasher board that uses Peripherals ENET0 and ENET1 with EMIO. The PHY layer connects to the EMIO through Gmii to Rgmii IP. I need the FPGA loaded for U-BOOT to see the ethernet ports so that it can TFTPBOOT images (mostly for testing). Additionally, if the FPGA is not loaded during power up then will the Linux OS be able to load the FPGA before the OS probes for the Ethernet interfaces or will it just fail to find the ethernet MAC ?

1 Like
5

If you really need bitstream to be loaded during boot, like the normal ways, you can comment out line 139,140, and 141 of:

However, you will need to make sure the fsbl, device tree, bitstreams, etc. are all consistent; otherwise it is prone to hanging.

1 Like
6

Hi Rock,

Commenting out lines 139-141 of the sdbuild/Makefile did the job. So far I can use the ethernet interfaces in both uboot and Linux without any hanging (though I have not used it a lot yet).

I do not know if I really need the bitstream loaded during the first stage boot (only needed that for testing via tftpboot). Do you think its possible to load the bitstream only during the linux boot and have the ethernets detected and functional with the snickerdoodle/pismasher board ?? Note: the board uses the GMII to RGMII IP in the FPGA to join the PHY to the EMIO ports.

regards

1 Like
7

I think you have verified the bitstream is working, which is good. I am not quite familiar with that board, but it is possible to just load bitstream as a service (like the boot_leds.service) during OS booting. In that case you don’t have to comment out line 139-141. Also, if your ethernet depends on some IPs in FPGA (e.g. some device tree entries required), you can load the bitstream along with the device tree segment; PYNQ supports that kind of operation. After bistream is loaded, you can try restart your ethernet service / or ifdown + ifup to see if it works.

1 Like
8

I should be able to figure out how to load the bitstream as a service, but I do not understand what you mean by “along with the device tree segment” ? Is there any documentation on that kind of operation.

1 Like
9

Right now there is not, but I can try to add it in next release. If you look at the overlay Python API, you can do something like:

ol = Overlay('your_overlay.bit', dtbo="your_overlay.dtb")

Then the dtbo file, compiled from dts, can be inserted to your system device tree. After that you can probably see some new devices in your linux system.

1 Like