Zynq xc7z020适配复旦微FM25F32 QSPI Flash启动与烧写实战

简介在Zynq-7000系列FPGA国产化替代场景中Xilinx官方SDK烧写工具无法识别复旦微FM25F32 QSPI Flash常导致启动镜像无法固化。围绕XC7Z020搭配FM25F32的验证平台这套程序实现了uboot与FSBL的成功烧写与上电启动加载为同类国产Nor Flash适配提供完整参考。压缩包共438个文件以C/H源码、Makefile工程文件为主辅以编译生成的O/A库文件及BIN/ELF烧写镜像整体仅2.27MB结构紧凑、便于直接移植。同时包含SDK工程配置、链接脚本与说明文档可帮助读者快速复用自研烧写流程规避官方工具对国产Flash不支持的问题。已有2473人学习下载适合正在从事Zynq国产化硬件平台开发或Flash启动适配的工程师参考。 做Zynq xc7z020批量产品的同学应该都有体会Boot配置介质选型这件事看着简单真碰到非主流Flash的时候会非常折腾。最近我在一块板子上接的就是复旦微的FM25F3232Mbit容量的QSPI NOR Flash整条链路从Vivado生成烧写文件、FSBL适配、JTAG/QSPI烧写到上电从Flash启动前后调了一周多才完全跑通。这篇就把关键步骤和踩过的坑完整记录下来给正在做Zynq xc7z020 国产QSPI Flash方案的朋友做个参考。这个项目核心其实就一件事让Zynq xc7z020跳过SD卡和JTAG上电后直接从板载的FM25F32读配置程序并启动。听起来简单但FM25F32不是Xilinx默认支持的Flash型号FSBL如果不做适配烧写环节都过不去。下面按我实际操作的顺序讲。1. 项目背景与方案选型为啥单挑FM25F321.1 FM25F32是什么、基本参数FM25F32是复旦微电子推出的一款SPI NOR Flash容量32Mbit也就是4MB供电电压2.7V到3.6V工作在标准SPI、Dual SPI和Quad SPI模式下页面大小256字节扇区大小4KB整个芯片被划分为1024个扇区也就是32个块每个块128KB。这个结构和市面上主流的W25Q32、GD25Q32非常接近时序上也是标准的SPI协议理论上只要驱动里识别了它的ID读写擦除逻辑可以直接复用。选它来做Zynq启动介质核心原因无非两个成本控制和国产化率要求。同一容量下FM25F32的单价通常比美系主流品牌便宜一些而且交期更稳定。另一个现实因素是QSPI NOR Flash作为Zynq的启动介质对性能要求不算苛刻——FSBL加bitstream加应用整个BOOT.bin一般也就两三MB4MB容量够用QSPI的读取速度也完全满足启动时间要求。1.2 QSPI启动与SD卡、TFTP方案的取舍Zynq xc7z020支持多种启动方式JTAG、QSPI、SD卡、NAND等。SD卡方案好处是容量大、随便换文件但在批量产品里问题也很明显SD卡座增加BOM成本卡座可靠性在振动环境下堪忧而且SD卡启动需要FSBL里带文件系统镜像不可控TFTP更是只适合调试阶段产品不可能依赖网络启动。QSPI方案的优点就是芯片直焊板子上没有机械结构数据掉电不丢失上电后BootROM自动从QSPI把FSBL读进OCM执行无需任何外部介质。整条产品链路最简洁。代价是Flash容量有限、烧写不像SD卡拷文件那么简单需要专门的烧写路径。FM25F32 4MB在这个项目里放FSBL加一个中等规模的带DDR初始化的bitstream是够的但如果是逻辑资源占用极多的大工程4MB会非常紧张选型的时候必须提前估算BOOT.bin大小。2. BOOT.bin生成与FSBL的隐藏门槛2.1 生成BOOT.bin的标准流程不管用什么FlashZynq要能从QSPI启动Flash里必须先有BOOT.bin。BOOT.bin通常包含三个阶段内容FSBLFirst Stage Boot Loader、bitstreamFPGA配置文件、应用软件裸机或U-Boot等。生成流程在Vivado里比较固定先在Vivado里完成硬件工程导出硬件产物XSA文件。打开Vitis版本比较老的是XSDK基于XSA创建FSBL工程编译得到fsbl.elf。创建应用工程编译得到app.elf如果跑Linux则替换为U-Boot的u-boot.elf。使用Vitis的Create Boot Image功能分区顺序依次添加FSBL、bitstream、app生成BOOT.bin。这个流程大多数用过Zynq的人都不陌生真正的坎不在生成BOOT.bin这一步而在于FSBL在初始化QSPI控制器时能不能正确识别FM25F32这颗Flash。2.2 让FSBL认识FM25F32关键Zynq的FSBL代码里QSPI驱动维护着一张Flash参数表每颗受支持的Flash都有一个条目包含制造商ID、存储类型ID、容量ID以及扇区大小、总容量等参数。Xilinx默认支持的是Winbond、Micron、Spansion这些主流厂家的常见型号复旦微FM25F32的JEDEC ID和这些默认型号对不上烧写Flash时FSBL就会因为识别不了Flash而中止。解决思路有两个。第一个思路是改FSBL源码在Flash参数表里新增FM25F32的条目然后重新编译FSBL、重新生成BOOT.bin。第二个思路是用间接方式先让FSBL走一个已知型号的参数绕过ID检查但这样有风险Flash容量和扇区参数如果对不上擦除和写入会出错治标不治本。我当时选的是第一个思路正确做法是找到FSBL工程中的Flash配置表老版本Vivado里一般在 image_mover.c 中通过 Board_Flash_DeviceList 数组维护新版本路径可能不同可以直接全局搜索“FlashDeviceList”或者“IndustryStandardFlashList”。数组里每个条目结构类似以下形式用Winbond W25Q256作为对照组就能看出来字段含义static const XPS_XferSpiFlash_Config Board_Flash_DeviceList[] { { /* Winbond W25Q256JV */ SPIS_FLASH_DEVICE_MANUFACTURER_ID, 0x40, /* 存储类型ID不同厂家有不同编码 */ 0x19, /* 容量密度ID0x19表示256Mbit */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 扇区大小如果是统一扇区则填对应值 */ 0x8000000, /* 总容量bit根据芯片实际填写 */ { 0x00, 0x00, 0x00, 0x00 }, ... }, };把FM25F32的实际ID和容量参数填进去。ID不要靠猜板子上电后用SF指令读一下最直接的方式是在U-Boot里执行sf probe 0 0 0它会直接打印出FM25F32的JEDEC ID或者用逻辑分析仪抓一下Read ID0x9F命令的返回数据。然后把读到的三个字节分别填入制造商ID、类型ID、容量ID字段。容量参数对照FM25F32数据手册填总容量写成32Mbit对应的值扇区大小按4KB填页大小256字节。重新编译FSBL重新Create Boot Image生成BOOT.bin。这一步做完FSBL在QSPI初始化阶段就能正确识别FM25F32后续Program Flash和上电启动才走得通。这是整个项目里隐藏最深、最容易被忽略的一步也是我认为整个烧写配置链路中最重要的知识点。2.3 关于BOOT.bin容量和分区的一点提醒FM25F32只有4MB而Zynq xc7z020的bitstream本身就不小。常规工程下FSBL约200到300KBxc7z020的完整bitstream普遍在3MB到5MB之间取决于逻辑资源占用和配置选项应用再占几百KB一个BOOT.bin很容易逼近甚至超过4MB。这个项目里我就遇到过BOOT.bin编译出来4.2MB的情况烧写Flash时直接报容量不足。处理办法有两个方向。一是优化bitstreamVivado综合时打开Bitstream Compression选项压缩率通常有20%到40%xc7z020压缩后能省不少空间。二是裁剪FSBL和应用把不必要的驱动和调试信息去掉。如果还是放不下那就只能换更大容量的Flash或者改双镜像/QSPISD混合启动方案Flash里只放最小FSBLbitstream和app放SD卡。我的建议是选型阶段就按工程实际资源占用去估算别想当然觉得4MB一定够。3. 两种烧写路径实测Vitis图形化与U-Boot命令行3.1 路径一Vitis/XSDK的Program FlashVitis自带的Program Flash功能是最直观的烧写方式适合在调试阶段快速把BOOT.bin烧进FM25F32。操作流程如下开发板连接JTAGVivado Hardware Manager能正常识别xc7z020确认设备列表里能看到ARM DAP和FPGA。打开Vitis菜单选择 Xilinx - Program Flash。Image File选择之前生成的BOOT.binFlash Type选 qspi-x4-singleOffset保持0x0点击Program。等待进度条走完Program Flash工具会先通过JTAG把一段小的烧写代理程序加载到Zynq的OCM里运行由它在PS侧驱动QSPI控制器完成擦除和写入。实际使用中这个工具烧写FM25F32成功的前提就是FSBL已经集成了FM25F32的Flash ID否则Program Flash阶段会报Flash ID mismatch之类的错误。另外注意Program Flash时Vivado工具会使用FSBL作为烧写代理Vitis工程里如果找不到可用的FSBL会要求指定一个所以工程里要有编译通过的FSBL。整个烧写过程我实测用时大概两到三分钟4MB数据速度不算快但胜在稳定。如果校验失败优先怀疑SPI时钟频率把Program Flash的时钟频率从默认值降下来比如调整到10000kHz10MHz再试一次多数能解决。3.2 路径二U-Boot方式救砖利器图形化工具在开发阶段好用但在产线批量烧写或者板子出问题需要救砖时U-Boot命令行往往更灵活。前提是板子上已经有一套能启动到U-Boot的镜像——无论是从SD卡启动还是从QSPI启动都行。进入U-Boot后先加载BOOT.bin到DDR通常用TFTP或SD卡读取然后依次执行三条核心命令# 探测并初始化QSPI Flash0号控制器工作频率0使用默认CS片选0 sf probe 0 0 0 # 全片擦除FM25F32是4MB从0x0擦到0x400000 sf erase 0x0 0x400000 # 把DDR地址0x1000000处的BOOT.bin写入Flash起始地址0x0长度按实际文件大小 sf write 0x1000000 0x0 0x400000这里要注意sf erase和sf write的长度参数讲究。sf probe成功后会打印出Flash的JEDEC ID和容量确认识别到了FM25F32再继续操作。写完后可以用sf read 0x2000000 0x0 0x400000把Flash内容读回DDR再用cmp.b 0x1000000 0x2000000 0x400000比较验证确认烧写无误。这个方法同样依赖U-Boot驱动里对FM25F32的支持如果U-Boot的SPI Flash表里也没有这个ID同样需要自己添加。4. 启动模式设置与上电验证4.1 Boot Mode引脚设置烧写成功只是第一步真正验证成果的是让板子脱离JTAG上电从FM25F32启动。Zynq的启动模式由Boot Mode引脚决定也就是MIO[6:2]的电平组合具体对应关系在UG585里有表可查不同开发板设计不同有的还用拨码开关、有的用跳线帽。我这里用的板卡QSPI启动对应 MIO[6:2]0b00010实际项目里务必以原理图和UG585为准别直接抄别人的配置。拨到QSPI模式后板子断电重新上电Zynq的BootROM会自动通过QSPI控制器读取Flash起始地址的数据把FSBL加载到OCM并跳转执行。如果FM25F32的ID没有被FSBL识别BootROM阶段可能看不出异常但FSBL一旦开始初始化QSPI就会卡住。4.2 串口日志怎么看FSBL在正常工作时会通过UART0输出启动日志。上电后串口能看到类似下面的输出Xilinx Zynq First Stage Boot Loader Release 2023.1 ... Silicon version 3.1 Boot mode: QSPI ...出现Boot mode: QSPI说明BootROM已经从QSPI启动路径读取了FSBL接下来FSBL开始加载bitstream初始化DDR然后把应用或U-Boot交出去。如果卡在某一行不动比如停在Boot mode: QSPI后没有后续输出大概率是FSBL的QSPI初始化失败——此时优先检查FM25F32的ID配置是否正确。如果压根没有任何串口输出先查Boot Mode引脚电平、UART连接和电源别急着怀疑Flash。bitstream加载完成后FSBL会把执行权交给应用程序或U-Boot看到U-Boot版本号或者自己的应用程序打印信息就说明整个QSPI启动链路完全跑通了。5. 常见问题与排查技巧实录这里把我实际踩过的坑和同事常遇到的问题整理成一张速查表每一条都对应具体的检查方向。故障现象可能原因排查与解决Program Flash时报Flash ID mismatchFM25F32的JEDEC ID不在FSBL的Flash设备表中读实际ID在FSBL的Board_Flash_DeviceList里新增条目重新生成BOOT.bin烧写校验失败SPI时钟频率过高导致时序不稳把Program Flash或U-Boot里的QSPI时钟降到10MHz再试烧写成功但上电无任何输出Boot Mode引脚不在QSPI模式或BOOT.bin偏移错误核对MIO[6:2]电平确认烧写偏移是0x0上电后串口只有Boot mode: QSPI没有后续FSBL的QSPI初始化失败大概率还是Flash ID不匹配检查FSBL里FM25F32的容量字段包括扇区大小和总容量bit数能识别FM25F32但擦除特别慢驱动用了全片擦除而非扇区擦除全片擦除4MB大约需要几秒到十几秒正常如果一次擦写就卡死查WP引脚状态Flash读回内容全为0xFFFlash实际没写入或写保护生效检查FM25F32的WP#引脚是否被拉低以及芯片内部状态寄存器是否有保护位写入了数据但启动后校验失败写入期间掉电或Flash质量问题重新擦除再烧写批量项目建议增加烧写后回读校验环节BOOT.bin超过4MB工程太大放不下开启bitstream压缩、裁剪FSBL和应用必要时换更大Flash或混合启动方案几个具体的避坑心得一并说下。FM25F32这种国产Flash不同批次或者不同封装的电气特性可能存在细微差异批量烧写前一定要抽几片做完整的擦写回读测试不要只从供应商规格书看一眼就觉得没问题。调试阶段强烈建议保留一套可用的SD卡启动镜像万一QSPI侧把板子搞到无法启动还能用SD卡把板子拉起来重新烧写不至于变砖后只能依赖JTAG和仿真器的低级恢复流程。另外U-Boot的sf probe输出信息是非常好的诊断工具甚至不用进完整系统直接从SD卡启动U-Boot就能验证硬件链路和Flash ID比反复插拔JTAG高效得多。最后再说一个我自己习惯的做法每次项目切换Flash型号我都先在空板上只烧一个最小的FSBL加空bitstream做启动验证确认FSBL对Flash的识别和读取没有问题后再烧完整的BOOT.bin。这样做的好处是排查范围小出了问题能很快定位是Flash适配问题还是工程内容问题。Zynq加复旦微FM25F32这套组合只要把FSBL的Flash参数表填对、烧写时钟控制住整个链路其实非常稳定后面批量生产基本没有再出过启动相关的问题。本文还有配套的精品资源点击获取