一、复位系统
参考文献:Zynq-7000 SoC Technical Reference Manual (UG585)-ch26 Reset System
zynq7000复位信号源包括硬件复位、看门狗定时器、JTAG控制器复位信号和软件复位信号。其中,硬件复位引脚由上电复位信号PS_POR_B和系统复位信号PS_SRST_B驱动。在PS中,有3个看门狗定时器可用来产生复位信号;JTAG控制器产生的复位信号可产生系统级复位信号,或者只用于复位PS的调试部分;软件复位信号可用于单独子模块的复位,或者产生系统级的复位信号。
复位系统执行的是三段式的复位序列:上电——清除内存——系统使能,相关完成的上电流程见下图(RAM清除会被填充0)
复位源和影响域
PS_POR_B:该复位信号复位PS部分,直到所有的PS供电达到了所要求的的电平为止。
PS_SRST_B:复位包括PL在内的整个系统,需要注意的是系统复位不会重新采样启动模式引脚。
系统软件复位:效果同PS_SRST_B引脚(除了REBOOT_STATUS register value being different)
看门狗定时器复位:看门狗定时器复位是看门狗定时器在启动和超时时在内部产生的。PS中有三个不同的看门狗计时器:一个系统级计时器(SWDT)和两个Arm核心(AWDT0和AWDT1)中各有一个私有定时器。系统级定时器复位信号总是重置整个系统,而私有看门狗定时器可以重置它所在的Arm核心,也可以重置整个系统
安全违规锁定(Secure Violation Lock Down):当检测到安全违规时,整个PS复位并锁定。
调试复位:有两种类型的调试复位起源于调试访问端口(DAP)控制器;调试系统复位和调试复位。
Debug system reset is a command from the Arm DAP which is controlled by JTAG. This causes the system to reset, just like the external system reset.
Debug reset resets certain portions of the SoC debug block including the JTAG logic.
各个复位类型影响域见下图:
二、启动流程
参考文献:
Zynq-7000 SoC Technical Reference Manual (UG585)-ch6 Boot and Configuration
Zynq-7000 All Programmable SoC Software Developers Guide (UG821)-ch3 Boot and Configuration
1.启动模式
zynq-7000系列支持NAND flash、并行NOR flash、Serial NOR (Quad-SPI)、SD flash以及JTAG作为启动设备。
2.启动过程
对zynq-7000的启动过程至少包含两个阶段,通常要求3个阶段(分为两个必选阶段和一个可选阶段)。
阶段0:BootROM,简单来说就是固化到SOC的BootRom中的处理器执行的用户不可更改的代码,该阶段的作用是配置ARM处理器和必要的外设,然后从启动设备读取第一阶段Bootloader(FSBL)代码。BootROM并不会配置和初始化PL,也不会使能DDR和SCU。
注意:上电后,BOOTROM负责启动CPU1的代码,当上电复位后,BootROM使得CPU1处于复位状态,并且禁止所有东西,并通过修改寄存器使得CPU1处于WFE状态。
阶段1:FSBL,(First Stage Bootloader )FSBL代码通常存储在flash中,也可以通过JTAG下载到芯片中。BOOTROM把FSBL代码复制到OCM中,其中从FSBL加载到OCM的代码在192KB以内。在FSBL开始执行后,OCM整个256K才全部可用。(FSBL引导代码可以在用户控制之下,被称为用户引导代码)。FSBL可以在SDK中配置生成。需要注意的是,由于PS可以完全独立于PL独立运行,FSBL是否配置PL是非强制的。如果提供了FPGA的比特流文件,则FPGA可完成PL的配置.当然您可以自定义FSBL引导代码,以使用其他PS外设(如以太网、USB或STDIO)来引导或配置PL(比特流文件)。
如果存在阶段2的启动代码,则FSBL执行完毕之后会加载它。
如果不存在操作系统,则FSBL执行完毕之后会把相应裸机环境中的代码加载到DDR内存中。
阶段2:(可选)在这个阶段,通常执行用户自己编写的软件程序。当然也可以是第二级的启动引导程序(second stage boot loader,SSBL)。该阶段是完全在用户的控制下实现。
BootRom在非安全模式下简化逻辑流程见下图:
FSBL的作用:
1)使用Xilinx提供的硬件配置工具对PS配置数据进行初始化。具体而言
使用Zynq-7000 AP SoC配置界面,Xilinx硬件配置工具生成用于初始化DDR、MIO和SLCR寄存器的代码。在工程文件夹下,需要关注的文件的有:
a:ps7_init.c和ps7_init.h,用于初始化CLK、DDR和MIO。(依据Vivado中的配置,完成PS端的初始化)
b:ps7_init.tcl脚本文件,功能和ps7_init.c实现相同。是用来我们通过SDK进行debug是代替FSBL 进行初始化操作的。这样debug时使用该文件将应用程序加载到DDR并进行调试,不需要运行FSBL。(这就是使用SDK debug配置中initization file是ps7_init.tcl原因)
c:Ps7_init.html,它描述初始化数据。2)配置PL使用bitstream文件(假如提供)
3)加载裸核应用程序或者第二级引导程序到DDR中。
4)切换到第二阶段引导加载程序或裸金属应用程序。
注意:在切换到第二阶段引导加载程序或裸金属应用程序之前,FSBL会使指令缓存失效并禁用缓存和MMU,因为U-Boot假定它在启动时是禁用的。FSBL的初始化顺序请参见SDK自带的FSBL代码
FSBL流程示例见下图
三、创建镜像文件
您使用Bootgen程序将FSBL、bitsteam、应用程序文件拼接在一起。SDK有一个创建引导映像向导选项,如下图所示,用于添加分区镜像并创建一个可引导镜像(BOOT.BIN文件),然后进行烧写flash运行。总结:**在flash中运行的镜像文件是将FSBL、bitsteam、应用程序一起打包生成的。关于镜像文件的顺序必须是首先FSBL、然后bitsteam(可选,只有在使用PL才需要)、然后应用elf文件。由于FSBL不重映射DDR;
查看内存地址控件分配,低于1Mb的DDR不能被使用(应用程序ELF的执行地址必须大于1Mb)**文章来源:https://uudwc.com/A/gnYe
注意:bit文件只用来配置PL端,FSPL只是用来配置PS端,划分是很独立的。硬件配置FPGA时对PS端(如DDR和flash)和PL端会分别在FSBL和bit文件中,不会混合在一起文章来源地址https://uudwc.com/A/gnYe