一、复位系统
参考文献: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_SRST_B相比,PS_POR_B复位范围更大,参见上流程图)。
PS_SRST_B:复位包括PL在内的整个系统,需要注意的是系统复位不会重新采样启动模式引脚(参见上流程图)。
系统软件复位:效果同PS_SRST_B引脚(All except debug and persistent registers.The PL must be re-programmed),注意下表中的All except debug and persistent registers.The PL must be re-programmed这句话,这里的persistent registers “持续寄存器”需要留意下,因为这类的持续寄存器包括一个MULTIBOOT_ADDR用于多重启动的。
看门狗定时器复位:看门狗定时器复位是看门狗定时器在启动和超时时在内部产生的。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.
各个复位类型影响域见下图:
持续寄存器(Persistent Registers):
当我们使用PS_POR_B复位信号时,所有的寄存器都会被复位重置。在非POR复位信号(指的是非PS_POR_B复位,比如PS_SRST_B、系统软件复位或看门狗等,参见上表)下有几个寄存器或寄存器的位下会保持,这些寄存器称为持续寄存器,(但是重新上电通过PS_POR_B复位会清零)。
下表是相关的持续寄存器和寄存器位:
扩展:我们看下面BootRom更为详细的流程图(启动流程Figure 3-1画的相对简化了),BootRom代码其实和FSBL加载各个分区的代码逻辑是相同的。上电POR复位后是由于MULTIBOOT_ADDR寄存器为0(上电POR复位后BootRom读取的是存储介质如flash基地址的FSBL加载至OCM中运行),实际上软件逻辑是读取MULTIBOOT_ADDR作为加载的存储介质的基地址偏移。我们实现多重启动的原理是更改MULTIBOOT_ADDR寄存器然后软件复位(红色部分1),由于软件复位不改变MULTIBOOT_ADDR中的值,实现软件复位时加载的是MULTIBOOT_ADDR偏移+储介质如flash基地址的FSBL加载至OCM中运行。(注意到没,我们设计多重启动也就是多个镜像文件,上电POR重启加载的是默认flash基地址的FSBL,当然如果你设置的不是flash基地址,那么存放在flash的位置是32K的整数倍也行,看流程图会自增MULTIBOOT_ADDR(红色部分2),我们看FSBL代码实际上也是一样的逻辑,去读取你存放的镜像文件位置,而当配置完MULTIBOOT_ADDR再软件复位后加载的是你的另外一个镜像的FSBL)
我会在后面专门写一篇关于多重启动的博客
二、启动流程
参考文献:
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作为启动设备。
ZYNQ的启动模式是由外部引脚决定的,5个模式引脚MIO[6:2],参见下图:引脚MIO[6:2]用于配置5种启动模式,引脚MIO[8:7]用于配置所有MIO引脚的输入输出电压。
当PS_POR_B复位信号由低到高变化时,zynq-7000 SOC对下述引脚进行连续3个时钟周期采样。复位采样MIO[6:2]并将采样的模式值保存到系统级控制寄存器SLCR内的BOOT_MODE寄存器内。同时将MIO[8:7]值保存在GPIOB_DRVR_BIAS_CTRL寄存器中。(我们查看fsbl代码中确认当前的启动模式就是通过读取BOOT_MODE寄存器来确定不同的启动分支的)。从大的启动模式上来讲,ZYNQ有两大类启动模式,分别为从BootRom主动启动和从JTAG被动启动(这里说的主动还是被动就是说是否是CPU自身主动启动的含义),NAND flash、并行NOR flash、Serial NOR (Quad-SPI)、SD flash为主动启动模式。
在没有外部JTAG的情况下,处理系统(PS)与可编程逻辑(PL)都必须依靠PS来完成芯片的初始化配置。即借助CPU来完成配置,这也是ZYNQ不同系列的不同之处。
1.1 关于JTAG
仿真模式下:我们用仿真器Run as或者Debug as来运行程序,本质上是通过tcl脚本来初始化PS,通过JTAG方式下载比特流文件,然后下载elf文件,然后用JTAG收发信息进行在线调试。
2.启动过程
对zynq-7000的启动过程至少包含两个阶段,通常要求3个阶段(分为两个必选阶段和一个可选阶段)。
阶段0:BootROM,简单来说就是固化到SOC的BootRom中的处理器执行的用户不可更改的代码,该阶段的作用是配置ARM处理器和必要的外设如NAND、 NOR、 SD卡等基本外设,然后从启动设备BOOTROM把FSBL代码复制到OCM中,其中从FSBL加载到OCM的代码在192KB以内。BootROM此过程并不会配置和初始化PL,也**不会使能DDR(DDR是在阶段1或者之后进行初始化)**和SCU。最后一步,跳转到OCM启动地址至此,BootROM任务完成。
BootRom在非加密模式下简化逻辑流程见下图:
注意1:上电后,BOOTROM负责启动CPU1的代码,当上电复位后,BootROM使得CPU1处于复位状态,并且禁止所有东西,并通过修改寄存器使得CPU1处于WFE状态。(这里我是有疑问的,由于BootRom代码我们不可见,关于手册上这段话按照流程如上是没有这个执行操作的,不过我们查看FSBL启动代码确实知道FSBL如果是core0工程配置启动会确实会将CPU1置为WFE状态,是不是手册中将BootRom和FSBL代码在OCM中的执行混为一谈了,我的理解是BoorRom加载FSBL到OCM并执行跳转后BootRom就已经完成任务了)
注意2:OCM地址范围0000_0000 to 0003_FFFF,即OCM中的阶段运行才是有效0地址(FSBL开始运行),而BootROM运行并不在有效地址范围内。
阶段1:FSBL(First Stage Bootloader ),OCM中的FSBL程序开始运行,在FSBL开始执行后,OCM整个256K才全部可用。(FSBL引导代码可以在用户控制之下,被称为用户引导代码)。FSBL可以在SDK中配置生成。需要注意的是,由于PS可以完全独立于PL独立运行,FSBL是否配置PL是非强制的。如果提供了FPGA的比特流文件,则FPGA可完成PL的配置.当然您可以自定义FSBL引导代码,以使用其他PS外设(如以太网、USB或STDIO)来引导或配置PL(比特流文件)。FSBL代码通常存储在flash中,也可以通过JTAG下载到芯片中。
后续博客分析裸核FSBL代码会知道FSBL会将镜像文件中各个分区文件加载到DDR(FPGA的bit文件是临时使用DDR然后通过PACP桥接接口启动FPGA配置),最后一步执行所有PS分区的第一个作为跳转地址(一般我们只有一个PS分区可执行文件)执行跳转
如果不存在操作系统,则FSBL执行完毕之后会把相应裸机环境中的代码加载到DDR内存中并跳转启动。
阶段2:(可选)在这个阶段,通常执行用户自己编写的软件程序。当然也可以是第二级的启动引导程序(second stage boot loader,SSBL)。该阶段是完全在用户的控制下实现。
FSBL的作用:
1)使用Xilinx提供的硬件配置工具(Vivado中的配置)对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会失能L1 指令cache和数据cache。失能MMU,FSBL的初始化顺序请参见SDK自带的FSBL代码
FSBL流程示例见下图
三、创建镜像文件
您使用Bootgen程序将FSBL、bitsteam、应用程序文件拼接在一起。SDK有一个创建引导映像向导选项,如下图所示,用于添加分区镜像并创建一个可引导镜像(BOOT.BIN文件),然后进行烧写flash运行。
总结:**在flash中运行的镜像文件是将FSBL、bitsteam、应用程序一起打包生成的。关于镜像文件的顺序必须是首先FSBL、然后bitsteam(可选,只有在使用PL才需要)、然后应用elf文件。由于FSBL不重映射DDR;
查看内存地址空间分配,低于1Mb的DDR不能被使用(应用程序ELF的执行地址必须大于1Mb)**
注意:bit文件只用来配置PL端,FSPL只是用来配置PS端,划分是很独立的。硬件配置FPGA时对PS端(如DDR和flash)和PL端会分别在FSBL和bit文件中,不会混合在一起文章来源:https://www.toymoban.com/news/detail-461302.html
下一节会对fsbl的代码进行下分析。文章来源地址https://www.toymoban.com/news/detail-461302.html
到了这里,关于Xilinx ZYNQ 7000学习笔记一(复位和启动)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!