FPGA - Zynq - 加载 - BootRom

FPGA - Zynq - 加载 - BootROM

  • 题外话
  • BootROM
    • BootROM Header Definition
    • BootROM Header Searching and Loading
  • 总结

题外话

第一次使用Markdown编写博客,之前都是直接用word或者onenote写好之后复制到博客上,发现文字编排效果很差,不忍翻阅下去。所以转投markdown怀抱。

这里将会新开一个章节,专门更新关于Zynq的一些心得,我希望能够完成以下几个方面:

搞懂Zynq的底层机制
实现Multiboot和Fallback
AXI4接口
PS部分,RTOS,Linux, etc
PL部分, HDL

因此,我希望能够通过Zynq片上强大的FPGA资源和ARM资源,来完成FPGA工程师和ARM工程师的协同工作,一般来说FPGA部分来完成所有高速接口驱动以及一些高速算法(并行独立或者串行复用),然后ARM部分来完成通信协议的实现,不管是私有的(如用户自定义的串口协议的封包和解包)或者标准的(如TCP/IP或者USB等),以及FPGA的流程控制,错误状态控制还有远程更新控制等。

为了完成上述化学反应,一个很重要的方面就是如何协调ARM和FPGA(都是Zynq片上的资源),这个其实很多开发板的学习手册都已经给出了答案,那就是应用AXI4总线。那剩下的问题就是,如何实现Multiboot以及fallback。

因为在S6或者其他7系列的FPGA中,是有一套非常成熟的FPGA加载机制(Xilinx有很详细的指导手册),但是来到Zynq时代,这个方式变了。为什么呢? 因为现在zynq上有ARM了,所有的加载工作实际上可以借由ARM来实现,这无疑也给用户带来了灵活的操作空间,即用户可以自己整一套属于自己的,满足要求的加载方式,这也是本文研究的重点:解析Zynq的加载方式。

这里将通过对比Zynq的TRM和FSBL源码,来一步一步解析Zynq的加载流程,如下所示

POR
BootROM
FSBL
configure then enable PL, if bitstream exist
load Application with/without OS

运行流程简单的说就是:

  1. 触发条件 POR或者non-POR
  2. ARM加载BootROM,这个程序停留在Zynq内部ROM,用户无法修改,用于实现搜索FLASH中的BootROM header,然后根据Header(这个header在整个FLASH中至少需要一个,Xilinx的软件会自动整合出来这哦头文件)信息,将FSBL加载到OCM(on chip memory)
  3. 开始运行FSBL,进一步加载Bitstream(PL用,如果有bit文件在FLASH中的话)或者其他镜像(PS用,裸机或者带系统)
  4. run 上述的其他镜像,裸机或者RTOS的话直接run,linux的话需要先运行u-boot

BootROM

永远问自己,我们的芯片(在这里是Zynq)在POR复位或者non-POR 复位后,ARM是怎么样一步一步最终来到用户的main.c,对FPGA工程师而言,就是FPGA是怎么完成初始化任务的。

这里我们不妨写的详细一点,将所有的技术细节都呈现出来。这就需要我们打开Zynq的TRM:
在这里插入图片描述
可以看到,在non-POR或者POR以后,Zynq会完成:

  1. 锁存配置引脚,如下图所示,FPGA - Zynq - 加载 - BootRom_第1张图片
  2. 初始化PLL(根据复位时锁存的进行选择初始化或者不初始化)
  3. 初始化APU(由两个ARM CPU构成)
  4. ROM CRC check
  5. 初始化boot用的引脚(Q-spi,NOR,SD,NAND等等),根据上一步锁存的配置引脚进行选择。
  6. 出发并等待PL完成初始化,前提是PL部分上电已经完成的话。如果此时PL上电没有完成,这这一步直接跳过
  7. 开始搜索BootROM Header,如果搜索到了一个合法的header,就会基于这个header加载FSBL(加密或不加密)
  8. 被加载的FSBL可能是XIP(execute in place,在存储器里直接运行)或者是被加载到了DDR中,加载完毕后BootROM完成任务,将控制权交给了FSBL。

通过上面的流程描述,我们可以获得一个表观的理解,原来Zynq加载蛮复杂的。因为Zynq里面包含了PS(APU,即两个ARM Cortex-A9 cpu)和PL(根据系列的不同,可能是A7系列,也可能是K7系列)两个部分。

这两个部分的加载,会根据用户选择的不同而不同,如下所示:
FPGA - Zynq - 加载 - BootRom_第2张图片
从上面可以知道,PS的加载和PL的加载并不是完全独立的,如下图所示

BootROM Executes
PS path
PL path
PCAP configure PL
PS POR
Reset All Reg
Sample Mode_pin
initial PLL or not depend on Mode_pin
initial APU, CPU 0 execute and CPU1 just wait
ROM CRC check
initial MIO for boot device, like Qspi
find detail in note 1
PL POR
start-up, hardware power-up sequence
Search BootROM header
load header
load FSBL into OCM or XIP
run FSBL
Configure PL through PCSP, JTAG, or ICAP
load uboot or other ELF......

Note 1: if PL was power-up(needed for JTAG or secure mode), BootROM will initial PL then wait until PL complete initialization

如上流程,就是整个PS和PL加载的过程,基本上我们只需要保证合适的文件被正确的烧写到FLASH中,那么整个加载就会正确的跑下去,这个所谓的合适的文件包括:

  1. BootROM Header, Xilinx的工具自动生成
  2. FSBL,Xilinx由范例工程
  3. BitStream,用户根据项目自定义的PL固件,即ARM固件
  4. Application.elf,用户根据项目自定义的PS固件,即FPGA固件

整个BootROM是写死在Zynq的片上ROM中,其中最重要,同时也会影响后面FSBL执行的,就是BootROM Header的searching 和 loading。

BootROM Header Definition

类似于A7或者S6系列的multiboot过程需要一个header文件,它用于实现:

  1. 同步,FLASH位数自动检测
  2. 指定 Golden所需的Bin在FLASH中的Offset
  3. 指定Function所需的Bin在FLASH中的Offset
  4. 发送PROGRAM-B指令,让FPGA开始加载Bin

在Zynq系列中,这个Header的功能被进一步的扩大,下面我们来看一下这个Header的定义吧:
FPGA - Zynq - 加载 - BootRom_第3张图片FPGA - Zynq - 加载 - BootRom_第4张图片
接下来逐条来解释其作用,同时留下一点伏笔,因为这些最终都会被FSBL所引用。

  1. Interrupt Table for Execution-in-Place — 0x000 to 0x01C
    这些数据用于XIP,这里不讨论

  2. Width Detection — 0x020
    用于检测Qspi的位宽到底是X1,X2,还是X4,如果是X8,还需要下面那个 Image Identification 寄存器

  3. Image Identification — 0x024
    固定为0x584C4E58,‘XLNX’,还可用于X8检测

  4. Encryption Status — 0x028
    配置FSBL/User code到底是加密还是不加密

  5. FSBL/User Defined — 0x02C
    用于保存Header的版本,应该也是xilinx自动生成的

  6. Source Offset — 0x030
    用于保存FSLB/User code image被保存的offset地址,这个Offset是相对于Header的起始位置而言的,这个在FSBL中会有体现,这留个记号

  7. Length of Image — 0x034
    用于保存被加载的FSLB/User code image的大小,<=192KB。 该数据=0时意味着不需要copy,是XIP。

  8. FSB Load Address— 0x038
    FSLB/User code image copy的目标地址,因为该image是存在FLASH中的,需要被复制到其他OCM中去。

  9. Start of Execution — 0x03C
    copy完以后,cpu需要从哪里开始执行第一条代码,<= 0x30000,也即是192KB。这个很重要,会在介绍FSBL源码的时候重新在验证并确认这个功能。 然而这样地址,或者长度之类的,都是通过配置Xilinx提供的工具自动打包生成的。

  10. Total Image Length — 0x040
    load进OCM的总长度,这个长度会大于等于Length of Image — 0x034,因为在加密模式下,还会包含HMAC头文件之类的。

  11. QSPI Config Word — 0x044
    固定为0x01

  12. Header Checksum — 0x048
    0x020 to 0x044的checksum,用于验证Header是否完整,FSBL会应用到

  13. FSBL/User Defined— 0x04C to 0x097
    自定义数据

  14. ???Boot Header Table Offset??? — 0x098
    TRM中这个数据的命名好像有问题

  15. QSPI Config Word — 0x09C
    指向Image Header Table,这个Table里面会记录整个FLASH里面除了FSBL以外,还有几个image,包括Bitstream,elf等等。每一个image会有一个Header(不是这里的BootROM Header,而是专门的Header,FSBL里面在介绍),所有的Header组成一个Table。

  16. Register Initialization Parameters — 0x0A0 to 0x89C
    利用Add+Data的方式,直接对某个地址进行数据写操作,应该非常高效,估计也是xilinx工具自动生成的。

  17. FSBL/User Defined — 0x8A0 - 0x8BF

  18. FSBL Image or User Code Start Address — 0x8C0
    FSBL Image or User Code 实际可以放置的起始地址,也就是上面的Source Offset — 0x030 >= 0x8C0

介绍了这么多,估计一时也不好消化,没有关系,上面黄色标记了的数据,会在FSBL中隆重的重新介绍。

BootROM Header Searching and Loading

回到老话题,BootROM会利用上述BootROM Header把FSBL拷贝到OCM中,然后让FSBL接管CPU开始run。而实际上FSBL也会应用上面的BootROM Header文件去寻找下一步所需的image,包括BitStream等,这个以后再说。

那么BootROM 是如何找到BootROM Header的呢?
FPGA - Zynq - 加载 - BootRom_第5张图片如上说是的Searching方法:

  1. BootROM会首先在FLASH的0x00处寻找Header,依据就是Image Identification parameter – 0x024 是否等于 ‘XLNX’ . 其次就是检查Header Checksum — 0x048
  2. 如果都没有问题,就按照Header内容将FSBL的code加载到OCM的指定位置,然后run。
  3. 如果有问题,将Multiboot reg 加 1 ,然后自动发送non-POR,下一次运行的BootROM下一个32KB来寻找Header ,并重新检查是否满足条件。
  4. Multiboot reg在这个寄存器不会被non-POR清除,会被保留到下一次的Boot中去

因此,BootROM Header 必须放置在32KB的整数倍位置,这个应该是Xilinx的工具自动完成的

这个检查checksum的操作也同样的在FSBL中被执行,以后在介绍

总结

介绍了这么多,总结一下:

  1. 重启后自动执行BootROM
  2. BootROM会自动寻找 BootROM Header
  3. 找到Header后,会将FSBL加载到OCM中
  4. 然后将CPU的PC指针指向目标地址,同时FSBL开始run

后面的章节中将会重点介绍FSBL是如何工作的,毕竟BootROM我们用户无法修改和参与,明白原理和机制即可。

下次再见!

你可能感兴趣的:(FPGA设计)