What is the easiest way to get PYNQ up and running on a K26 SOM based custom board?
I have some older Zynq 7020 + PYNQ 2.4 based designs that that I would like to migrate over to a K26 SOM based custom board. Example overlays and video are not a concern, I just really use bitstream loading, hwh parsing, and memory mapping/allocation. Jupyter is handy but not required.
Is building the boot components + modules with PetaLinux 2021.1 and using the board agnostic PYNQ 2.6 rootfs a bad idea?
My SOM are at the customs, I am migrating my project to Kria. I cant wait for Pynq to run on it. 
BTW: Thanks to the Pynq team which have been the keystone of my projects since V2.3, including my thesis, and our CubeSat.
My SOM are at the customs, I am migrating my project to Kria. I cant wait for Pynq to run on it.
BTW: Thanks to the Pynq team which have been the keystone of my projects since V2.3, including my thesis, and our CubeSat.
We would really like to hear more about your projects if you can share, especially the CubeSat. I think this would be of interest to a lot of people. You can post in the
PYNQ Community and you can request projects to be added to here: PYNQ - Python productivity for Zynq - Community
Cathal
What is the easiest way to get PYNQ up and running on a K26 SOM based custom board?
There will be an official release of PYNQ to Kria KV260 once the official Ubuntu release is available.
In the meantime, this is the best way to port to a custom board:
Cathal
I ended up building the boot files, kernel, and device tree with Petalinux 2021.1 and using the Pynq 2.6 rootfs prebuilt. This hodgepodge is functional on a KV260 while I wait for my custom board.
Trying to integrate the sdbuild flow with an updated Petalinux/Yocto (for Kria support) did not sound like fun so I did not even try.
For booting on the KV260, I pulled some of the boot mode resistors to change the boot target to SD1-LS. This was a bit tricky since the reference designators are offset in a non-obvious way from the components. The setup for the SD card in Vivado was also a bit confusing and I ended up setting it to SD 2.0 and put a weak pulldown on MIO39.
Using just the SD card for boot let me bypass all the on-SOM storage which is easier for people downstream of me. It seems a shame to not use the QSPI and EMMC, but this works for the short term.
One thing I was proud of was pointing mmcblk0 → SD1 via the device tree. This saved some trouble with bootargs, fstab, and various other scripts after boot. Give this a try if you have a SD card boot device on SD1 and also have SD0 configured.
Testing has been minimal at this point, but I can load a bitstream and access MM devices in the fabric. On the PS side I’ve verified operation of ethernet and the SS USB. Other devices will need to wait until I have application specific hardware available.
Thank you for the proposition.
Currently, we are not using Kria yet, I am currently working on the migration.
Some part will remain closed source., but it would be a honor to contribute and appear there, and we will be able to provide some open-source examples for sub-parts, in particular the acquisition chain for an LVDS image sensor, using Pynq for the DMA.
I will investigate this once we complete this project.
I am also planning to apply for the Xilinx Adapt Challenge.
Mikaël
Ubuntu on Kria was released today !
Today is a great day, Pynq will come soon !
Super good news!
Kria is a super promising board. Lots of projects are possible through it.