The new experimental build flow for Vivado 2020.1 is submitted. However, this build process is not yet fully tested on many different host PC configurations and may fail in some circumstances.
Updating to Vivado 2020.1 changes the generated BSP a bit. Some version bumps caused the directory names to be changed and a minor update to the v4l2 driver Makefile solved the problem. One of the major issue is the bitstream format also changed a bit and the fpga-bit2bin.py produces a non-working bin file. Luckily, newer version of bootgen can provide a working bin file from the bitstream. However, this also cause another issue, as the new bin files can no longer be flashed by fpga_manager script included in the old 2019.1 (4.19) kernel. An update to 2020.1 (5.4) kernel is necessary as Xilinx provided a newer version of fpga_manager script with their new kernel which can handle the new bin file.
Updating to a newer kernel means we need to update the driver itself. It now requires a stricter checking on pointer types. The vm_fault struct format was changed from the pre 5 kernel. Older WiFi drivers will also break with this new stricter pointer type checking but beyond the scope of this project.
There are also some other problems related with building a cross compiled kernel. One of the prominent one is the wrong type of binary sometimes is generated in few scripts among hundreds of properly generated one. Actually the original repository already tried to solve this for the 4.19 kernel with the inclusion of the builddeb patch which force the recompilation of some missing script upon package installation. But this patch does not work properly with 5.4 kernel. In order to alleviate this problem, I moved the Linux kernel build process inside the chroot directory, making sure all script are generated for the target architecture. In addition to that, it ensures the exact same gcc version is used for both compiling the kernel and the drivers. However, unfortunately this process sometimes still fails on some host PCs while working on some others. Further test is required, but due to the time constraint, I will halt the process at this stage.
The new experimental build flow for Vivado 2020.1 is submitted. However, this build process is not yet fully tested on many different host PC configurations and may fail in some circumstances.
Updating to Vivado 2020.1 changes the generated BSP a bit. Some version bumps caused the directory names to be changed and a minor update to the v4l2 driver Makefile solved the problem. One of the major issue is the bitstream format also changed a bit and the fpga-bit2bin.py produces a non-working bin file. Luckily, newer version of bootgen can provide a working bin file from the bitstream. However, this also cause another issue, as the new bin files can no longer be flashed by fpga_manager script included in the old 2019.1 (4.19) kernel. An update to 2020.1 (5.4) kernel is necessary as Xilinx provided a newer version of fpga_manager script with their new kernel which can handle the new bin file.
Updating to a newer kernel means we need to update the driver itself. It now requires a stricter checking on pointer types. The vm_fault struct format was changed from the pre 5 kernel. Older WiFi drivers will also break with this new stricter pointer type checking but beyond the scope of this project.
There are also some other problems related with building a cross compiled kernel. One of the prominent one is the wrong type of binary sometimes is generated in few scripts among hundreds of properly generated one. Actually the original repository already tried to solve this for the 4.19 kernel with the inclusion of the builddeb patch which force the recompilation of some missing script upon package installation. But this patch does not work properly with 5.4 kernel. In order to alleviate this problem, I moved the Linux kernel build process inside the chroot directory, making sure all script are generated for the target architecture. In addition to that, it ensures the exact same gcc version is used for both compiling the kernel and the drivers. However, unfortunately this process sometimes still fails on some host PCs while working on some others. Further test is required, but due to the time constraint, I will halt the process at this stage.