I am working with PYNQ on a custom Zynq board (Avnet’s Mini-ITX - 7z045) for a while now. I have been successful in building a custom PYNQ image using the sdbuild workflow.
For my application, I have a use case which requires adding a custom Linux Driver (has to be built-in with the Kernel, can’t be loaded as a module). In the past, I had a pure PetaLinux + Yocto build workflow and I accomplished this by using a fork of the linux-xlnx repository with changes for the custom driver.
My question is: would it be possible to have the PYNQ sdbuild workflow use an external version/fork of the kernel repository? What would need to change? I believe I would have to change the configuration of the underlying PetaLinux project which PYNQ creates during the sdbuild, but I’m unsure on what the right way of doing this would be.
All suggestions/comments are welcome!
Of cause 100% you can do so, as the SD build of the PYNQ is just a sets of script to automate the build flow like PetaLinux + Yocto. That’s what I understand in PYNQ 2.7 build.
However, I didn’t study much the latest automated script in PYNQ 3.0, which I will highly expect things are almost same as before.
So what you need is just an injection on the script or modify the link of the original repository of the linux-xlnx.
Easiest way I will think is to diff the two repository locally and cross check any thing is not align then push your own repository to Git and fake the auto build script to use that link rather than official one.
But one important thing is that crossing xlnx version will highly make things no longer working especially to PYNQ.
As every Vivado + Vitis + Petalinux come in set so there are no good result unless you know what you are doing.
I see, this makes sense.
I tried looking into what might need to be changed in order to get this to work.
- sdbuild/Makefile - I see
KERNEL_VERSION specified here, but I don’t see how I could edit these to point to a Kernel residing on a custom repository.
- sdbuild/boot/meta-pynq/recipes-kernel/linux - I do not see the kernel version being specified in the BitBake files here.
I guess my question now is: from what file does the sdbuild flow determine which Kernel to use? What am I missing?
For which individual line is related to the pull and build you need to gvim a bit yourself.
As for the version this is predefined in the Petalinux itself which is well know perquisite.
See Git repository of the Xlnx messages:
Just like if you use Windows DOS is the base (just simple analogy).
I think this can help you.
Ultra96 v2 has a Microchip wifi module that is called wilc3000. The chip’s kernel driver worked great on 32-bit ARM systems but not at all on the aarch64 Linux kernel. This required some device tree settings, a kernel patch and driver patch. This was also an out of Linux tree source code driver.
Since PYNQ changes some of the PetaLinux options and features, this can change #defines in the kernel modules headers and more. So you have to recompile your driver in many cases with the same settings as the kernel that PYNQ configures. You can look at GitHub - Avnet/Ultra96-PYNQ: Board files to build Ultra 96 PYNQ image and the wilc3000 package, see pre.sh for an example of how to compile it. I made the driver work and the patches, and the PYNQ team’s legendary Yun Qu (Rock) created the package scripts for U96v2.
The Yocto recipe that integrates the wilc3000 driver into PetaLinux & PYNQ is here: Ultra96-PYNQ/Ultra96/petalinux_bsp_v2/meta-user/recipes-modules/wilc at master · Avnet/Ultra96-PYNQ · GitHub
If you have to apply a kernel patch too, you can look at ./Ultra96/petalinux_bsp_v2/meta-user/recipes-kernel/linux/linux-xlnx/fix_u96v2_pwrseq_simple.patch
The PYNQ-ZU board uses the same wifi module and has the same arrangement, so you can look at its github as well; it is all the same though except for different GPIOs.