ZYNQ 7000系统在出场时需要将固件从eMMC启动,原因有2:
需要注意,ZYNQ7000 系列不支持eMMC作为BOOT 启动盘。那么我们需要用QSPI FLASH + eMMC的方式启动系统,QSPI FLASH存放BOOT文件,eMMC存放内核文件+文件系统或者只存放文件系统;
“The eMMC memory can only be used as secondary storage since the Zynq BOOTROM only recognizes QSPI, NAND, NOR or SD card as a primary boot medium.”
图 1‑1 工作流程
建立vivado工程,导出hdf描述文件,这里只需要根据原理图给出一个最简单的即可。
图 2‑1 ZYNQ7000最小系统
编译后,导出hdf文件。
首先你得有一个ubuntu的petalinux环境,这里不做说明。
图 2‑2 准备进入配置选项
图 2‑3 进行高级启动项设置,其它保持默认即可(如何SD有2个,可以手动选择一个)
图 2‑4 boot image, u-boot, kernel均选择从FLASH启动
图 2‑5 boot从FLASH启动,其它2项不再截图说明
图 2‑6 返回首页,选择Image打包设置
图 2‑7 选择ROOTFS为INITRAMFS(掉电不保存数据)
以上设置完成后,保存退出
由于需要用QSPI启动的系统对eMMC进行分盘操作,需要用到如下命令
fdisk, mkfs, mount, umount
需要在ROOTFS设置中把这些库包含进来。
petalinux-config -c rootfs
图 2‑8 设置filesytem package
需要包含下列package
Inside base > util-linux, check util-linux, util-umount, util-mount, util-mkfs, util-fdisk
图 2‑9
Inside base > e2fsprogs, check e2fsprogs-mke2fs
图 2‑10 e2fsprogs-mke2fs
设置号之后,保存退出,编译
petalinux-build
编译完成后,将uboot, kernel, fpga(bit stream 这里没有bit)全部打包到BOOT.bin
petalinux-package --boot --fsbl ./images/linux/zynq_fsbl.elf –fpga --u-boot --kernel –force
图 2‑11 打包BOOT.BIN
然后用SDK或者VIVADO烧录BOOT.bin到FLASH,为了简单还是用VIVADO烧录吧,这个烧录也可以用脚本实现,这里不多讨论。
图 2‑12 烧录BOOT.BIN到QSPI FLASH
然后设置为QSPI启动,上电观察UART输出
图 2‑13 启动成功后观察存储设备
首先查看disk信息,可以用fdisk -l,其中mmcblk0是eMMC,mmcblk0p1/2是之前已经分配好的分区。
图 3‑1 eMMC状态
删除已有分区,重新来一遍
图 3‑2 卸载disk
Fdisk删除已有分区, d 是删除指令
图 3‑3 删除已有分区
在fdisk交互模式下,按照以下步骤进行操作:
a. 输入 n 创建新分区。
b. 选择主分区或扩展分区。
c. 设置分区起始扇区(例如:默认值为 2048)。
d. 设置分区结束扇区(根据您想要的分区大小设置,64MB 对应 131072 扇区)。
e. 重复上述步骤创建第二个分区。
图 3‑4 建立1个primary分区,64MB
图 3‑5 建立第二个分区
指定第一个分区为FAT32
mkdosfs -F 32 /dev/mmcblk0p1
指定第二个分区为EXT4,默认是ext4。注意,第二个分区也分成primary即可。
图 3‑6 分区分配完成,并且自动mount 了
相对与QSPI启动盘制作,只需要改动启动设置、文件系统设置即可。
boot.img和uboot 还是从FLASH启动,kernel和文件系统选择SD启动。
图 4‑1 kernel存放在SD
图 4‑2 文件系统存放于SD卡
然后保存退出,编译打包即可,打包时无需打包kernel。
文件有多个copy方式,比如U盘镜像、网络copy,这里为了简单,我就用的U盘copy
图 5‑1 U盘COPY,推荐用winscp 简单直观
如果是不包含fpga bit 文件的BOOT.bin,大小大约500KB,而FPGA bit 文件无论你是否有逻辑在里面,尺寸都不会减小(因为FPGA的逻辑门是固定的,约束文件启用压缩选项会适当减小)。BOOT.bin尺寸打了以后,下载速度很慢,并且每次更新bit后有需要重新打包下载到FLASH,因此最好把bit放到eMMC里面,这样就方便多了。
“Zynq devices are hardwired in BOOTROM code to boot only from NAND, NOR, SD or QSPI persistent memory devices. However, it is possible to reduce the size of the primary boot image by moving the bitstream, normally the largest component by far, to secondary persistent storage. In this configuration, the primary boot image consists only of the first and second stage bootloaders, to create an image that is often less than 500K bytes. The second stage loader, u-boot in this case, is responsible for loading the Programmable Logic in the device via PCAP. The procedure can be demonstrated using a PicoZed module and carrier combination, where the boot image is stored in QSPI, and the bitstream and PetaLinux image is stored in eMMC.”
在Xilinx的FPGA中,有三个常见的用于部分重配置的模块,它们分别是ICAP、PCAP和MCAP。
ICAP代表Internal Configuration Access Port(内部配置访问端口),PCAP代表Processor Configuration Access Port(处理器配置访问端口),MCAP代表Media Configuration Access Port(媒体配置访问端口)。
在Xilinx的FPGA中,有三个常见的用于部分重配置的模块,它们分别是ICAP、PCAP和MCAP。
ICAP代表Internal Configuration Access Port(内部配置访问端口),PCAP代表Processor Configuration Access Port(处理器配置访问端口),MCAP代表Media Configuration Access Port(媒体配置访问端口)。
关于为什么MCAP被称为Media-CAP以及它的命名由来,我推测可能是因为无法使用PCIe-CAP,所以选择了Media作为命名的一种替代。
xCAP是指在FPGA完成配置后,从FPGA逻辑访问FPGA配置功能的模块。
ICAP是实现在FPGA区域内的模块。当在仅使用FPGA设备进行部分重配置时,FPGA逻辑可以使用ICAP来修改重配置区域。
相反,在运行处理器的设备上,例如Zynq系列的设备,实现了PCAP模块,ARM处理器可以通过PCAP访问FPGA的配置功能。
例如Vitis等框架在Linux环境中使用名为XRT的运行时来通过PCAP修改PL区域。
MCAP是从UltraScale开始引入的模块,它附加在PCIe硬件宏上。
例如,对于在PCIe总线上已被识别的FPGA设备,可以直接将FPGA重配置为"PCIe->重配置区域",而不是通过"PCIe->运行中的FPGA逻辑->ICAP->重配置区域"这样的路径。
对于不带有处理器且UltraScale中没有PCIe的设备(例如Virtex、Kintex和UltraScale+中没有PCIe的设备,是否有UltraScale中没有PCIe的设备我不确定),只存在ICAP模块。
由于ICAP是从FPGA逻辑访问的,因此存在类似于ICAPE3的模块,但PCAP和MCAP无法直接从FPGA逻辑访问,因此不存在相应的模块。
最近,我已经很少使用ICAP,但经常使用PCAP和MCAP,尤其是在与FPGA中的某些硬件宏(如MMCM、PCIe和GTY等)相结合时,我认为xCAP是最常用的模块。
关于为什么MCAP被称为Media-CAP以及它的命名由来,我推测可能是因为无法使用PCIe-CAP,所以选择了Media作为命名的一种替代。
xCAP是指在FPGA完成配置后,从FPGA逻辑访问FPGA配置功能的模块。
ICAP是实现在FPGA区域内的模块。当在仅使用FPGA设备进行部分重配置时,FPGA逻辑可以使用ICAP来修改重配置区域。
相反,在运行处理器的设备上,例如Zynq系列的设备,实现了PCAP模块,ARM处理器可以通过PCAP访问FPGA的配置功能。
例如Vitis等框架在Linux环境中使用名为XRT的运行时来通过PCAP修改PL区域。
MCAP是从UltraScale开始引入的模块,它附加在PCIe硬件宏上。
例如,对于在PCIe总线上已被识别的FPGA设备,可以直接将FPGA重配置为"PCIe->重配置区域",而不是通过"PCIe->运行中的FPGA逻辑->ICAP->重配置区域"这样的路径。
对于不带有处理器且UltraScale中没有PCIe的设备(例如Virtex、Kintex和UltraScale+中没有PCIe的设备,是否有UltraScale中没有PCIe的设备我不确定),只存在ICAP模块。
由于ICAP是从FPGA逻辑访问的,因此存在类似于ICAPE3的模块,但PCAP和MCAP无法直接从FPGA逻辑访问,因此不存在相应的模块。
The second stage loader, u-boot in this case, is responsible for loading the Programmable Logic in the device via PCAP. The procedure can be demonstrated using a PicoZed module and carrier combination, where the boot image is stored in QSPI, and the bitstream and PetaLinux image is stored in eMMC.
这里已经说了U-boot负责PCAP的调用工作,所以如果需要使用细节,可以查看u-boot代码。
The following tasks are required to move the bitstream to eMMC.
1. Modify the u-boot configuration to add bitstream loading from eMMC memory.
2. Use the PetaLinux toolchain to create a boot image with only the first stage loader and u-boot.
3. Use the write_cfgmem TCL command in Vivado to modify the bitstream by performing byteswapping, required to load via the PCAP interface. This creates a new binary format file.
4. Write the new binary file to the eMMC and boot the target from QSPI/eMMC.
图 6‑1 首先找到platform-auto.h
然后进行修改,增加如下内容:
然后编译:
Petalinux-build -c u-boot
编译完成后,打包固件
petalinux-package - -boot - - fsbl images/linux/images/zynq_fsbl.elf - -uboot - - force
只需要打包boot,uboot即可
然后对FPGA bit文件放到image.ub同级目录即可,这里bit文件需要用VIVADO的脚本进行修改为bin文件:
cd [get_property DIRECTORY [current_project]]/[current_project].runs/impl_1
write_cfgmem -format bin -interface spix1 -loadbit "up 0x0 [get_property top [current_fileset]].bit" -file [get_property DIRECTORY [current_project]]/system.bit.bin -force
上电启动,观察串口输出和板卡加了bit之后的变化(我在之前和之后用了不同的LED显示状态用于观察)
手机扫一扫
移动阅读更方便
你可能感兴趣的文章