1.ZYNQ+linux网口调试笔记（3）PL-ETH
2.正点原子FPGA连载第一章Hello World实验--领航者 ZYNQ 之嵌入式开发指南
3.正点原子FPGA连载第九章基于OV5640的源码字符叠加实验--领航者ZYNQ之HLS 开发指南
4.Xilinx Zynq-7000系列FPGA多路视频处理：图像缩放+视频拼接显示，提供工程源码和技术支持
5.Linux 应用案例开发手册——基于Xilinx Zynq-7010/7020工业开发板
6.Zynq GTX全网最细讲解，源码aurora 8b/10b协议，源码OV5640板对板视频传输，源码提供2套工程源码和技术支持

ZYNQ+linux网口调试笔记（3）PL-ETH

       åœ¨ZYNQ上使用gigE Vision协议的网络接口相机。

        第一步：调通PS侧网口GEM0（Xilinx BSP默认配好）。

        第二步：调通PS侧网口GEM1（见前一篇文档：开发笔记(1)）。

        第三步：调通PL侧网口（本文阐述）。

        第四步：在PL侧网口上验证Jumbo Frame特性，并在应用层适配gigE Vision协议。

        根据《xapp》可知，PL侧的PHY支持Base-X和SGMII两种配置，这两种配置对应两种不同的PHY引脚接口（连接到MAC）。而我们的hdf文件使用的是Base-X的配置。

        关于网口的Linux驱动，我们在官网找到一份资料： Xilinx Wiki - Zynq PL Ethernet 。资料很长，我们只看与我们相关的2.4.1 PL Ethernet BSP installation for Base-X”这一章节就可以了。

        首先导入FPGA设计同事提供的hdf文件：

        在弹出的图形界面里，进入Subsystem AUTO Hardware Settings——Ethernet Settings——Primary Ethernet，确认可以看到PL侧网络设备axi_ethernet_0，说明hdf文件里已包含了必要的网口硬件信息：

        上图中被选中的网口将成为Linux上的设备eth0。这里我们默认选择ps7_ethernet_0，即使用GEM0作为首选网口。

        启用Xilinx AXI Ethernet驱动

        进入Device Drivers -- Network device support – 选中Xilinx AXI Ethernet（以及Xilinx Ethernet GEM，这是PS侧网口的驱动）

        进入Networking support – 选中 Random ethaddr if unset

        进入Device Drivers -- Network device support -- PHY Device support and infrastructure – 启用Drivers for xilinx PHYs

        进入~~~~Device Drivers -- DMA Engine Support -– 禁用~~~~Xilinx AXI DMAS Engine~~~ （对应的配置项名为 ~~ CONFIG_XILINX_DMA ~~~）

        注意： Xilinx Wiki里对设备树节点的引用有误（&axi_ethernet），导致编译报错，应改为&axi_ethernet_0。

        注：PL-ETH驱动所在路径：<project>/build/tmp/work-shared/plnx_arm/kernel-source/drivers/net/ethernet/xilinx/xilinx_axienet_main.c和xilinx_axienet_mdio.c。对应的内核配置项为CONFIG_NET_VENDOR_XILINX和CONFIG_XILINX_AXI_EMAC。

        启用ethtool和tcpdump（调试用，非必须）：

        然后将生成的BOOT.BIN和image.ub拷贝到SD卡根目录下，将SD卡插入板子上，上电运行。

        上电后，使用ifconfig eth1查看网口信息，观察MAC地址与设置的一致，且ifconfig eth1 ..1. up没有报错。

        测试网络通路：ping PC是通的。说明网口工作正常。

        Linux下eth1（即PL-ETH）的MAC地址有误

        问题描述：

        开机打印：

        注意：

        MAC地址是错的，驱动里解析出的是GEM0的MAC地址。

        试验发现，即使在system-user.dtsi里不写local-mac-address，也照样解析出的是GEM0的MAC。

        而将system-user.dtsi里的local-mac-address改名为pl-mac-address，并将驱动里解析的字符串也对应更改为pl-mac-address，则可以正确解析出来：

        Passing MAC address to kernel via Device Tree Blob and U-Boot：

       /support/answers/.html

        U-Boot里的环境变量ethaddr会覆盖掉设备树里pl-eth的local-mac-addr字段，从而影响Linux启动后的网卡MAC地址；

        但U-Boot里的环境变量ipaddr不会对Linux启动后的配置产生任何影响。因为设备树里根本就没有关于IP地址的配置。

        phy-mode怎么会是sgmii？查了下官方的提供的BSP里，也是“sgmii”。说明这个没问题。具体原因不清楚。

        @TODO: 设备树里的中断号的顺序如何影响功能？

        为何读出来的IRQ号不对呢？这是因为这里读到的不是硬件的中断号，而是经过系统映射之后的软件IRQ number。两者不具有线性关系。

        关于中断号的疑问：

        Linux上的网口eth0、eth1的顺序，似乎是按照phy地址从小到大来排布的。

        Xilinx xapp-zynq-eth.pdf (v5.0) July ,源码

       /support/documentation/application_notes/xapp-zynq-eth.pdf

        Xilinx Wiki - Zynq PL Ethernet:

       /wiki/spaces/A/pages//Zynq+PL+Ethernet

        Xilinx Wiki - Linux Drivers:

       /wiki/spaces/A/pages//Linux+Drivers

        Xilinx Wiki - Linux Drivers - Macb Driver:

       /wiki/spaces/A/pages//Macb+Driver

        Xilinx Wiki - Zynq Ethernet Performance:

       /wiki/spaces/A/pages//Zynq+Ethernet+Performance

        查到关于Jumbo frame MTU的定义，当前值为，可否改大一些？

        驱动源码里关于jumbo frame的说明：

        设置MTU为，发现ping包最大长度只能设为ping ..1. -s

       https://lore.kernel.org/patchwork/patch//

        【完】

正点原子FPGA连载第一章Hello World实验--领航者 ZYNQ 之嵌入式开发指南

       实验平台：正点原子领航者ZYNQ开发板

       第一章Hello World实验

       实验目标：在ZYNQ嵌入式系统上实现串口打印“Hello World”。

       开发流程：硬件设计（Vivado软件）、源码爱情公寓源码软件设计（SDK软件）、源码下载验证。源码

       硬件设计包括：

       创建Vivado工程

       选择工程路径，源码确保路径名和工程名符合命名规则（仅英文字母、源码数字和下划线）。源码

       选择工程类型为“RTL Project”，源码不添加源文件和约束文件。源码

       选择ZYNQ器件型号（根据核心板上ZYNQ芯片型号）。源码

       添加PS模块

       使用IP Integrator创建。源码

       配置PS模块，包括UART、DDR、时钟等。

       移除与PL端交互的接口信号。

       软件设计包括：

       创建SDK应用工程

       新建工程，选择工程名“hello_world”。

       选择“Hello World”工程模版。

       编写源代码

       主函数包含初始化、打印“Hello World”和清理平台的函数。

       使用Xilinx定义的print()函数打印字符串。

       下载验证步骤：

       连接下载器和开发板

       安装USB串口驱动。

       设置SDK Terminal

       连接串口，设置波特率、数据位和停止位。

       下载并运行程序

       右键运行程序到硬件。

       验证结果：在开发板的串口上成功打印“Hello World”，证明实验在ZYNQ嵌入式系统上成功执行。

正点原子FPGA连载第九章基于OV的字符叠加实验--领航者ZYNQ之HLS 开发指南

       领航者ZYNQ的HLS开发教程中，我们详细介绍了基于OV的字符叠加实验。首先，实验目标是Python源码打包在视频图像上叠加字符，以实现监控系统中的实时信息显示。这个过程包括了从视频字符的概念理解，到使用PCtoLCD工具提取汉字“正点原子”的字模，以及如何通过HLS设计生成字符叠加的IP核。

       在实验步骤中，我们演示了如何通过软件获取字符的点阵表示，通过配置字符格式，将四个汉字合并成一个大字模，并将其保存为BMP格式。接着，使用Vivado HLS工具创建工程，编写源代码，利用hls_video.h库进行字符叠加的逻辑实现。综合并导出IP核后，验证阶段将生成的IP添加到Block Design中，并连接至OV和VDMA模块，确保正确显示字符叠加后的图像。

       在下载验证阶段，通过Vivado SDK将程序下载到领航者开发板，将字符叠加的IP应用到实际的摄像头监控系统中，最终在LCD屏幕上看到摄像头捕获的图像与字符叠加的效果。这个实验不仅锻炼了HLS编程技能，还展示了字符叠加技术在实际应用中的价值。

Xilinx Zynq-系列FPGA多路视频处理：图像缩放+视频拼接显示，提供工程源码和技术支持

       本文介绍如何利用Xilinx Zynq-系列FPGA Zynq进行多路视频处理，包括图像缩放和视频拼接显示。首先，通过CSDN大佬的经验，我们利用OV摄像头模组作为输入，配置其为x@Hz分辨率。接着，通过Zynq的软核i2c控制器配置摄像头，采集视频并将其转换为RGB格式。自定义IP负责图像缩放，通过SDK软件配置任意尺寸缩放，实质上是python 名片 源码AXI_Lite寄存器配置。VDMA IP实现视频到DDR3的帧缓存，Video Mixer IP则进行视频拼接，支持不同位置显示，同样通过SDK配置。最后，通过HDMI发送IP将RGB视频转换为TMDS信号，显示在显示器上。

       提供了vivado.1版本的完整工程源码和技术支持，可以实现三种不同的缩放拼接方案，只需修改SDK软件即可调整。设计思路详细描述了各个IP的使用和配置，包括HLS图像缩放IP的最大分辨率、输入输出格式，以及Video Mixer IP的视频处理能力。工程适用于在校学生和在职工程师的项目开发，特别适合于医疗、军工等领域。

       代码获取方式位于文章末尾，但请注意，该工程源码包含部分网络公开资源，仅限个人学习研究，禁止商业使用，且需注意FPGA和嵌入式C语言的基础知识要求。此外，文章还提供了相关FPGA图像处理方案的链接，包括图像缩放、视频拼接等不同功能的方案。

Linux 应用案例开发手册——基于Xilinx Zynq-/工业开发板

       开发案例说明

       开发案例位于产品资料“4-软件资料\Demo\tl-linux-application\”路径下的 base-demos 和 python-demos 目录。base-demos目录提供Linux常用开发案例，案例bin目录存放可执行文件，案例src目录存放源码。python-demos目录提供Python开发案例，脚本文件无需编译，可直接运行。测试板卡是基于Xilinx Zynq-系列XC7Z/XC7Z高性能低功耗处理器设计的异构多核SoC工业级核心板。

       若需重新编译Linux常用开发案例，春风麻将源码请将对应案例src目录复制到Ubuntu工作目录下，进入src目录执行命令加载PetaLinux环境变量，并执行make命令进行案例编译。编译完成后，将在当前目录下生成可执行文件。

       Linux常用开发案例包括tl_led_flash、tl_key_test和tl_can_echo等。

       tl_led_flash案例功能是通过向评估底板用户指示灯LED设备节点反复交替写入1、0数值，实现LED闪烁效果。LED点亮与熄灭时间均为0.5s。程序流程示意图显示LED设备节点为“/sys/class/leds/user-ledX/”目录下的brightness。

       操作说明包括将案例bin目录下的可执行程序tl_led_flash复制到评估板文件系统，并在可执行程序所在目录执行命令运行程序，即可看到评估底板LED1以0.5s的时间间隔进行闪烁。同时，串口终端打印系统全部LED设备信息和程序当前控制的LED设备信息。

       关键代码包括预定义LED数组、LED亮灭操作和时间间隔。

       tl_key_test案例功能是通过监听用户按键设备节点状态，检测按键事件。程序流程示意图显示用户按键设备节点为“/dev/input/event0”。操作说明包括将案例bin目录下的可执行程序tl_key_test复制到评估板文件系统，在可执行程序所在目录执行命令运行程序，串口终端将打印提示信息。再按下评估板用户按键KEY1，程序将检测到按键事件，并打印按键状态信息。

       关键代码包括定义按键、监听按键事件和循环监听。

       tl_can_echo案例功能使用canutils工具包的canecho程序实现CAN接口数据接收并重发功能。canutils工具包内含5个独立程序，包括canconfig、candump、canecho、cansend、账号之家源码cansequence等。本案例仅使用canecho功能，如需实现其他功能，可自行下载canutils工具包并从中获取对应功能程序源码。操作说明包括使用USB转CAN模块连接评估板CAN接口和PC机USB接口，参照调试工具安装文档安装USB转CAN驱动和ECAN Tools调试软件，双击打开ECAN Tools软件，选择设备类型，然后点击“打开设备”。打开ECAN Tools界面，将案例bin目录下的PL端.bin格式可执行文件复制到评估板文件系统"/lib/firmware/"目录下，并执行命令加载PL端可执行文件。进入评估板文件系统使用文件系统自带的canconfig工具设置波特率，并启动CAN接口。将案例bin目录下的可执行程序tl_can_echo复制到评估板文件系统，执行命令查看程序参数信息，绑定CAN接口并接收由ECAN Tools发出的数据，然后将接收到的数据重新发送出去。

       关键代码包括使用socket监听CAN接口和将从CAN接口接收到的数据重新发送出去。

       tcp_udp_demos案例主要实现客户端(client)与服务端(server)的文本数据相互收发功能。案例包含4个程序，包括tl_tcp_server、tl_tcp_client、tl_udp_server和tl_udp_client。操作说明包括将案例bin目录下的4个可执行程序复制到评估板文件系统，在Ubuntu中执行命令使用OpenSSH登陆评估板文件系统，并在可执行程序所在目录执行命令运行TCP和UDP服务端和客户端程序。程序执行后，客户端将会连接服务端或服务端和客户端程序均在评估板上运行时，可进行本地回环测试。关键代码以TCP通信程序为例，包括注意源码中的数据结构和系统调用的使用。

       Python开发案例包括tl_led_flash和tl_key_test两个简单案例。操作说明包括将案例目录下的脚本文件拷贝到评估板文件系统，并在脚本文件所在目录执行命令查看程序参数信息，执行命令运行脚本程序，即可看到评估底板上的LED闪烁或检测按键事件。关键代码包括查找所有LED设备和控制LED亮灭，以及打开按键设备和监听按键事件。

       以上内容为Linux应用案例开发手册——基于Xilinx Zynq-/工业开发板中的详细开发案例和操作说明。更多关于嵌入式开发的内容分享，欢迎关注Tronlong创龙科技~

Zynq GTX全网最细讲解，aurora 8b/b协议，OV板对板视频传输，提供2套工程源码和技术支持

       没玩过GT资源都不好意思说自己玩儿过FPGA，这是CSDN某大佬说过的一句话，鄙人深信不疑。

       GT资源是Xilinx系列FPGA的重要卖点，也是做高速接口的基础，不管是PCIE、SATA、MAC等，都需要用到GT资源来做数据高速串化和解串处理，Xilinx不同的FPGA系列拥有不同的GT资源类型，低端的A7由GTP，K7有GTX，V7有GTH，更高端的U+系列还有GTY等，他们的速度越来越高，应用场景也越来越高端。

       本文使用Xilinx的Zynq FPGA的GTX资源做板对板的视频传输实验，视频源有两种，分别对应开发者手里有没有摄像头的情况，一种是使用廉价的OV摄像头模组；如果你得手里没有摄像头，或者你得开发板没有摄像头接口，则可使用代码内部生成的动态彩条模拟摄像头视频；视频源的选择通过代码顶层的`define宏定义进行，默认使用ov作为视频源，调用GTX IP核，用verilog编写视频数据的编解码模块和数据对齐模块，使用2块开发板硬件上的2个SFP光口实现数据的收发；本博客提供2套vivado工程源码，2套工程的不同点在于一套是GTX发送，另一套是GTX接收；本博客详细描述了FPGA GTX 视频传输的设计方案，工程代码可综合编译上板调试，可直接项目移植，适用于在校学生、研究生项目开发，也适用于在职工程师做学习提升，可应用于医疗、军工等行业的高速接口或图像处理领域；

       提供完整的、跑通的工程源码和技术支持；

       工程源码和技术支持的获取方式放在了文章末尾，请耐心看到最后。

       免责声明：本工程及其源码即有自己写的一部分，也有网络公开渠道获取的一部分(包括CSDN、Xilinx官网、Altera官网等等)，若大佬们觉得有所冒犯，请私信批评教育；基于此，本工程及其源码仅限于读者或粉丝个人学习和研究，禁止用于商业用途，若由于读者或粉丝自身原因用于商业用途所导致的法律问题，与本博客及博主无关，请谨慎使用。

       我这里已有的 GT 高速接口解决方案：我的主页有FPGA GT 高速接口专栏，该专栏有 GTP 、 GTX 、 GTH 、 GTY 等GT 资源的视频传输例程和PCIE传输例程，其中 GTP基于A7系列FPGA开发板搭建，GTX基于K7或者ZYNQ系列FPGA开发板搭建，GTH基于KU或者V7系列FPGA开发板搭建，GTY基于KU+系列FPGA开发板搭建。

       GTX 全网最细解读：关于GTX介绍最详细的肯定是Xilinx官方的《ug_7Series_Transceivers》，我们以此来解读；我用到的开发板FPGA型号为Xilinx Kintex7 xc7ktffg-2；带有8路GTX资源，其中2路连接到了2个SFP光口，每通道的收发速度为 Mb/s 到 . Gb/s 之间。GTX收发器支持不同的串行传输接口或协议，比如 PCIE 1.1/2.0 接口、万兆网 XUAI 接口、OC-、串行 RapidIO 接口、 SATA(Serial ATA) 接口、数字分量串行接口(SDI)等等；GTX 基本结构：Xilinx 以 Quad 来对串行高速收发器进行分组，四个串行高速收发器和一个 COMMOM（QPLL）组成一个 Quad，每一个串行高速收发器称为一个 Channel(通道）。GTX 的具体内部逻辑框图：GTX 的发送和接收处理流程：首先用户逻辑数据经过 8B/B 编码后，进入一个发送缓存区（Phase Adjust FIFO），最后经过高速 Serdes 进行并串转换(PISO)。GTX 的参考时钟：GTX 模块有两个差分参考时钟输入管脚(MGTREFCLK0P/N 和 MGTREFCLK1P/N），作为 GTX 模块的参考时钟源，用户可以自行选择。

       GTX 发送接口：用户只需要关心发送接口的时钟和数据即可，GTX例化模块的这部分接口如下：在代码中我已为你们重新绑定并做到了模块的顶层，代码部分如下。GTX 接收接口：用户只需要关心接收接口的时钟和数据即可，GTX例化模块的这部分接口如下：在代码中我已为你们重新绑定并做到了模块的顶层，代码部分如下。

       GTX IP核调用和使用：有别于网上其他博主的教程，我个人喜欢用如下图的共享逻辑：这样选择的好处有两个，一是方便DRP变速，二是便于IP核的修改，修改完IP核后直接编译即可。

       设计思路框架：本博客提供2套vivado工程源码，2组工程的不同点在于一套是GTX发送，另一套是GTX接收。第1套vivado工程源码：GTX作为发送端，Zynq开发板1采集视频，然后数据组包，通过GTX做8b/b编码后，通过板载的SFP光口的TX端发送出去。视频源有两种，分别对应开发者手里有没有摄像头的情况，一种是使用廉价的OV摄像头模组；如果你得手里没有摄像头，或者你得开发板没有摄像头接口，则可使用代码内部生成的动态彩条模拟摄像头视频；默认使用ov作为视频源。第2套vivado工程源码：Zynq开发板2的SFP RX端口接收数据，经过GTX做8b/b解码、数据对齐、数据解包的操作后就得到了有效的视频数据，再用我常用的FDMA方案做视频缓存，最后输出HDMI视频显示。

       视频源选择：视频源有两种，分别对应开发者手里有没有摄像头的情况，如果你的手里有摄像头，或者你的开发板有摄像头接口，则使用摄像头作为视频输入源，我这里用到的是廉价的OV摄像头模组；如果你得手里没有摄像头，或者你得开发板没有摄像头接口，则可使用代码内部生成的动态彩条模拟摄像头视频，动态彩条是移动的画面，完全可以模拟视频；默认使用ov作为视频源；视频源的选择通过代码顶层的`define COLOR_IN 宏定义进行。

       视频源配置及采集：OV摄像头需要i2c配置才能使用，需要将DVP接口的视频数据采集为RGB或者RGB格式的视频数据。选择逻辑如下：当(注释) define COLOR_IN时，输入源视频是动态彩条；当(不注释) define COLOR_IN时，输入源视频是ov摄像头。

       视频数据组包：由于视频需要在GTX中通过aurora 8b/b协议收发，所以数据必须进行组包，以适应aurora 8b/b协议标准。视频数据组包模块代码位置如下：首先，我们将bit的视频存入FIFO中，存满一行时就从FIFO读出送入GTX发送；在此之前，需要对一帧视频进行编号，也叫作指令，GTX组包时根据固定的指令进行数据发送，GTX解包时根据固定的指令恢复视频的场同步信号和视频有效信号。

       GTX aurora 8b/b：这个就是调用GTX做aurora 8b/b协议的数据编解码。数据对齐：由于GT资源的aurora 8b/b数据收发天然有着数据错位的情况，所以需要对接受到的解码数据进行数据对齐处理。视频数据解包：数据解包是数据组包的逆过程。图像缓存：我用到了Zynq开发板，用FDMA取代VDMA具有以下优势：不需要将输入视频转为AXI4-Stream流；节约资源，开发难度低；不需要SDK配置，不要要会嵌入式C，纯FPGA开发者的福音；看得到的源码，不存在黑箱操作问题。

       视频输出：视频从FDMA读出后，经过VGA时序模块和HDMI发送模块后输出显示器。

       第1套vivado工程详解：开发板FPGA型号：Xilinx--Zynq--xc7zffg-2；开发环境：Vivado.1；输入：ov摄像头或者动态彩条，分辨率x@Hz；输出：开发板1的SFP光口的TX接口；应用：GTX板对板视频传输；工程Block Design如下：工程代码架构如下：综合编译完成后的FPGA资源消耗和功耗预估如下。

       第2套vivado工程详解：开发板FPGA型号：Xilinx--Zynq--xc7zffg-2；开发环境：Vivado.1；输入：开发板2的SFP光口的RX接口；输出：开发板2的HDMI输出接口，分辨率为X@Hz；应用：GTX板对板视频传输；工程Block Design如下：工程代码架构如下：综合编译完成后的FPGA资源消耗和功耗预估如下。

       上板调试验证光纤连接：两块板子的光纤接法如下。静态演示：下面以第1组vivado工程的两块板子为例展示输出效果。当GTX运行4G线速率时输出如下。

       福利：工程代码的获取：代码太大，无法邮箱发送，以某度网盘链接方式发送，资料获取方式：私。网盘资料如下：

Ebaz Zynq memcpy性能

       eba 板卡在Linux环境下的DDR测试结果显示，在SDK源码环境NonOS中进行ZYNQ pdk自带的memcpy性能测试。

       针对ZYNQ测量时间代码，通过获取全局定时器的时间值，基准为系统主频二分频。

       定义COUNTS_PER_SECOND，表示每秒计数值（基于CPU频率除以2）。

       在测试中添加内存拷贝代码，使用MB大小进行操作。

       经过计算，得出memcpy的运行速度。

       通过反汇编ELF代码，可以进一步分析和理解memcpy的具体执行过程和性能表现。