欢迎来到皮皮网网首页

【天相指标源码】【立德图源码】【java源码spi】zynq 驱动源码_zynq驱动开发

来源:strcmp源码 时间:2024-11-24 22:41:40

1.ZYNQ+linux网口调试笔记(3)PL-ETH
2.Zynq SDK 驱动探求(五)软件动态重配置硬件比特流
3.Linux的驱动驱动以太网驱动(基于Zynq XC7Z020)
4.如何在Zynq-7000上烧写PL Image
5.sdr开发篇 3. ZYNQ_DEV开发板linux的helloworld
6.zynq平台 Linux系统 phy 88e1512驱动配置

zynq 驱动源码_zynq驱动开发

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

       _device,对相关变量与函数进行赋值,源码并完成net_device的驱动驱动注册。

       在接收数据时,源码Linux采用NAPI(Network I/O)方式,驱动驱动先关闭中断,源码天相指标源码循环读取缓存区中的驱动驱动数据。此阶段需要编写poll函数,源码并在probe函数中初始化该函数。驱动驱动最大循环次数设置为,源码值将传递给xx_poll函数。驱动驱动在中断中关闭接收中断并启用NAPI调度。源码

       发送数据则通过上层协议将数据保存在sk_buff中,驱动驱动然后通过eth_start_xmit函数进行传输。源码在该函数中,驱动驱动需将sk_buff中的立德图源码有效数据放入缓冲区,并将缓冲区数据通过MAC发送出去。

       以太网MAC数据驱动主要依赖以太网描述符进行数据收发控制。描述符由两个位寄存器组成,包含地址和状态控制器。描述符数量可多,通过寄存器写入首地址与数量,数据自动通过DMA存入描述符地址中。当一个描述符地址写满,处理器自动继续写入下一个地址。

       发送数据时,数据地址保存在sk_buff中,根据其数量将数据分块,每块大小与描述符缓存大小一致。然后,将描述符对应状态位标记(置1或置0),java源码spi即可实现数据发送。

       以太网PHY驱动包括初始化PHY设备与读取网络状态两部分。初始化过程中,设置PHY工作模式、电压等参数。读取网络状态时,通过特定寄存器获取PHY运行状态、链路状态等信息。

如何在Zynq-上烧写PL Image

       åœ¨Zynq-上编程PL大致有3种方法:

       1. 用FSBL,将bitstream集成到boot.bin中

       2. 用U-BOOT命令

       3. 在Linux下用xdevcfg驱动。

       æ­¥éª¤ï¼š

       1. 去掉bitstream的文件头

       ç”¨FSBL烧写PL Images没有什么好说的,用Xilinx SDK的Create Boot Image工具即可完成,不再赘述。用后两种方法需要把bitstream文件的文件头用bootgen工具去掉。

       ä¸€ä¸ªå…¸åž‹çš„bif文件如下所示:

       the_ROM_image:

       {

       [bootloader]<fsbl_name>.elf

       <pl_bitstream_name>.bit

       <u-boot_name>.elf

       }

       bif文件可以用文本编辑器写,也可以用Xilinx SDK的Create Boot Image工具生成。然后在命令行下用以下命令即可去掉bitstream文件的文件头。

       bootgen -image <bootimage>.bif -split bin -o i BOOT.BIN

       "-split”参数可以生成以下文件:

       <pl_bitstream_name>.bit.bin

       2. 在U-BOOT下烧写PL Image

       å‘½ä»¤â€fpga load”和”fpga loadb”都可以。区别是前一个命令接受去掉了文件头的bitstream文件,后一个命令接受含有文件头的bitstream文件。

       åœ¨OSL .2上,缺省编译就可以完整支持写入PL Image的功能。但是在Petalinux .下,尽管可以在U-BOOT下看到命令”fpga”,还需要在文件

       <PROJ>/subsystems/linux/configs/u-boot/platform-top.h 中增加以下内容后重新编译才可以支持具体的功能。

       /* Enable the PL to be downloaded */

       #define CONFIG_FPGA

       #define CONFIG_FPGA_XILINX

       #define CONFIG_FPGA_ZYNQPL

       #define CONFIG_CMD_FPGA

       #define CONFIG_FPGA_LOADFS

       åœ¨OSL .2 U-BOOT中,具体的功能是在zynqpl.c的zynq_load()中实现的。

       3. 在Linux下烧写PL Image

       OSL Linux .2.中已经含有xdevcfg驱动了(之前就有,不过本文是在这个版本上验证的),直接用以下命令就可以完成PL Image写入。

       cat <path_to_storage_media>/<pl_bitstream_name>.bit.bin > /dev/xdevcfg

       Linux驱动的源代码在xilinx_devcfg.c中。因为驱动的编号是通过alloc_chrdev_region()动态分配的,所以不需要手工用mknod命令手动建立设备节点。

       åœ¨Linux驱动中,每次往DevCfg中写入字节,直到全部写完。

       4. 在用户程序中烧写PL Image

       ç›®å‰æ²¡æœ‰çŽ°æˆçš„源码来完成这个功能,不过可以用mmap()把DevCfg的寄存器映射到用户程序的虚地址中,然后参考一些现成的软件代码来完成这个功能:

        * FSBL中的pcap.c

        * U-BOOT中的zynqpl.c

        * Linux中的xilinx_devcfg.c

        * Xilinx SDK中的例子。例子位于以下位置,随SDK的版本会有变化。

        C:\Xilinx\SDK\.1\data\embeddedsw\XilinxProcessorIPLib\drivers\devcfg_v3_0\examples\index.html

       å°ç»“:

       DevCfg外设内部有自己的DMA,只需要简单的配置PL Image的基地址和长度到DevCfg寄存器,就可以完成Zynq- PL Image的加载。Xilinx已经提供了灵活的解决方案,如果开发者要把这个功能集成在自己的应用程序中,也有很多的代码可以参考,并不是很困难的任务。

sdr开发篇 3. ZYNQ_DEV开发板linux的helloworld

       创建Vivado工程并添加ZYNQ核心,设置DDR功能包括GPIO、ETH0、SD0、UART0、USB0。通过Block Automation进行配置,源码修改网站连接处理系统7_0的FCLK_CLK0到M_AXI_GPO_ACLK。创建HDL wrapper,选择图形界面配置或编辑文件的方式进行I/O端口的分配。进行编译,包含合成、实施、生成比特流等步骤。导出HDF文件,使用Petalinux进行Ubuntu命令行操作,创建工程,拷贝HDF文件,配置硬件信息,检查接口和配置SD卡,启动。配置内核和设备树,海城网站源码跳过根文件系统的配置,进行编译前的多点CPU核心分配。打包boot.bin。制作SD卡文件系统,包含分区操作,EXT分区和FAT分区的直接拷贝。启动测试,进行默认登录账号密码验证,GPIO、以太网、USB host的测试,包含脚本的创建和测试过程,处理USB相关的驱动问题。确保设备管理器中正确显示RNDIS,并完成IP配置,进行电脑ping测试。

zynq平台 Linux系统 phy e驱动配置

       在Zynq平台上配置Linux系统中的PHY E驱动,遵循以下步骤。

       确保硬件连接正确并识别为网络设备,可通过`ifconfig -a`查看。

       内核配置中启用Ethernet PHY支持,检查设备树(DTS)或内核配置文件,确保相关配置被定义。

       在设备树(DTS)文件中添加PHY E描述,指定兼容性与地址,可能还需添加其他属性。

       编译内核并加载设备树(DTB)文件至系统中,确保在系统启动后,驱动自动加载。

       使用`ethtool -i eth0`检查驱动加载情况及PHY信息。

       此步骤适用于Zynq平台配置Linux系统中的PHY E驱动。具体配置可能因平台和内核版本不同而有所差异。

ZYNQ XC7Z的PL PS中断驱动程序编写测试(linux4.版本下)

       设计目的旨在实现ARM与FPGA的高效交互,特别聚焦于PL与PS间的中断驱动通信。通过使用BRAM存储数据并触发外部PL端中断,通知PS端进行数据读写操作,本文将详细阐述这一过程。程序设计逻辑围绕按键触发中断,通过按键直接连接至PL端,驱动产生异步通知。应用开始向BRAM写入数据,随后阻塞等待读取数据,读取后进行比较。

       Vivado平台中,增加BRAM控制器与BRAM配置,以及中断机制的集成。本文重点介绍了在中断系统中使用第个中断,连接至IRQ_F2P接口。此外,需在Linux设备树中添加相应的中断配置,明确中断号为,通过计算得出实际中断号为,并设置为上升沿触发模式。

       中断程序设计包含驱动注册、字符驱动注册以及中断注册,考虑到数据交换量可能较大,本文提出使用mmap函数优化数据读写效率。中断处理函数中,首先产生异步通知信号,随后清除阻塞等待队列信号。

       应用程序测试阶段,接收中断触发信号后,通过mmap功能将数据写入BRAM,接着执行阻塞等待读取数据,直至唤醒后读取并打印数据。通过 printk 功能,直观展示了中断触发的数据处理流程,具体步骤如下:

       中断处理函数 plps_handler 触发。

       先前阻塞状态的 plpsirq_read 函数被激活,用于处理异步通知信号。

       应用层的异步通知函数 my_signal_fun 被调用。

       最终执行完成阻塞读取操作,read(fd, str, )完成数据读取。

       综上,本文详细介绍了ZYNQ XC7Z芯片下中断驱动程序的编写与测试过程,特别关注了Linux环境下的设备树配置、中断机制实现,以及程序的高效数据交换逻辑。通过实证分析,验证了设计方法的有效性,为后续FPGA与ARM交互应用提供了参考依据。