ZYNQ HLS图像处理加速总结(二)——Processing System软件部分

概述

7010的硬核是两个Cortex-A9，主频666M(233333….)，硬浮点+neon协处理器，性能不是很好，因为xilinx SDK可以生成底层IP的driver，所以PS裸跑起来很简单，通过JTAG调试很方便。初期时考虑到跑linux系统时的HLS IP的driver和VDMA的driver要写内核模块，VDMA虽然在3.17的内核源码已经集成了驱动，但并没有找到详细的相关资料，也在xilinx community上问到有人说这个驱动很坑。于是打算用AMP,一个核跑linux负责上层的相关应用，一个核裸跑+ucosii或FreeRTOS负责操作AXI总线上的外设，然而想法总是很天真的。。。弄了好长时间AMP，把CPU1成功的挂起后，并不能再跑程序，问题始终也没找到。不过在这期间也一直在进行linux下对IP核操作的相关尝试。最终没用AMP也解决了这个驱动的问题，下面简单总结下遇到的部分问题

PS系统搭建简述

参照前一篇文章中github里的那个文档进行操作，文件系统使用的是Linaro，在这推荐下xillybus，xillybus提供了完整的软硬件工程，它提供的xillinux系统精简的非常好的，系统从上电到登陆不到10秒，硬件工程除提供了HDMI/VGA显示、音频的IP（在xillinux系统里已经集成了驱动），还提供了一个优化的HLS接口，可以按照网站上的步骤实现一个简单的硬件加速的例子（然而并不能走AXI4-Stream总线）网站上还有多篇文档介绍devicetree和PCI-E。回到例子里Linaro文件系统，改动了好多地方，首先添加的bash自动补全，这个比较简单不多说，linaro在用户登陆后会执行一个检查软件更新的脚本，这个脚本运行时间巨长，导致每次ssh登陆都要等好长时间，一开始还能忍，后来用Qt Deploy的时候直接超时。。。然后在/etc/update-motd.d路径下找到了罪魁祸首（我不会告诉你我是硬找的）。这个路径下有两个脚本是进行检查更新操作的，直接注释掉就好。然后配了一个smb方便传输文件。最后把交叉编译好的opencv和Qt库拷进去就可以进行下一步了。

分配DDR给PL

这里要注意，vdma进行数据搬运的时候需要确定的物理地址并有一定的预留空间，大家都知道linux是通过mmu将物理地址映射为虚拟地址然后给程序使用的，并且在软件上成功申请一段大的连续的物理地址的内存概率是随着系统运行时间的增加而降低的（内存越来越碎,dma传输要求是连续的），所以要在内存没跑碎之前就留下一块内存不给PS用，uboot可以设置linux运行使用的内存的大小，但和之前我用过的又有些不一样，在早期的uboot里只要设置”mem”env的值就好。（之前的内核没有devicetree机制)，一开始这么试了一下，板子上的DDR为512M，我试了下”mem=510M”给PL预留了2M是可以的，但把mem改的更小的时候，内核就挂啦。。。参见之前写的文章”Zynq Reseving Physical Memory Issue“给出了解决方法，简单的说就是要告诉uboot和内核：devicetree要放哪呀。（顺便说下要想使uboot env的修改永久生效要重新编译遍uboot，官方提供的uboot不带SPI Flash的驱动）。

HLS生成的IP在linux下的操作

HLS在Export IP核的时候是也会“赠”一个软件驱动的，这个驱动给出了查询更改IP核状态、读写功能寄存器的接口，并可以按照一个标准的流程初始化IP核，流程参见之前写的”Vivado HLS —Processor Control“。这个驱动在linux下使用需要对devicetree做些小的更改。
首先要知道这个驱动是通过UIO（userspace I/O）内核模块进行操作的，需要内核配置为：（defconfig就是这个，检查一下就好）

CONFIG_UIO=y
CONFIG_UIO_PDRV_GENIRQ=y

然后需要通过devicetree文件告诉内核：我的外设里有一个uio设备，它在0x某某地址上。具体的操作是在 由SDK创建的devicetree工程中修改”compatible”的值，如在我的pl.dtsi文件中

image_filter_0: image_filter@43c40000 {
            compatible = "xlnx,image-filter-1.1";
            interrupt-parent = <&intc>;
            interrupts = <0 35