ZYNQ7000 启动流程解析

存放在ZYNQ芯片内部ROM不可更改，用于找到FSBL并启动它（从SD或者QSPI或者NAND），ug585第六章

用于引导U-Boot

用于引导Linux Kernel

petalinux工具可以构建2和3还有内核

BOOT.BIN包括fsbl，bitstream，用户程序(uboot)

image.ub包括了kernel（devicetree DTB和rootfs通过设置可选包不包含在ub内）

主要是分析下FSBL工程的main函数

调用ps7_init函数

主要是对PS端配置信息进行初始化 *** 作，包括MIO,PLL,CLK and DDR

我们在vivado软件中可以通过图形化的方式对ZYNQ PS端外设进行相关配置，那么这些配置信息会写入到hdf文件，SDK（或petalinux）会对hdf文件进行解析并生成对应的寄存器配置表，然后FSBL工程中会通过ps7_init函数将寄存器配置表写入到对应的寄存器中，完成对MIO/PLL/CLK/DDR等外设的硬件配置。

先调用Xil_DCacheFlush函数完成刷DCache缓存的 *** 作，然后再调用Xil_DCacheDisable禁用DCache缓存。

调用RegisterHandlers函数

调用DDRInitCheck函数

调用InitPcap函数

处理器配置访问端口

这个寄存器记录ZYNQ的启动方式（QSPI、SD、NAND、Nor、JTAG）

可以通过MIO3 MIO4  MIO5这三个引脚去配置ZYNQ的启动方式

ZYNQ上电复位的时候，会将这三个引脚的电平状态保存在BOOT_MODE寄存器当中。

每一种启动方式会有不同的处理方式。

第一、先初始化对应的flash设备

第二、再将MoveImage函数指针指向Flash设备的读写函数实体

调用LoadBootImage函数

FSBL的主要工作是启动U-Boot（终极目标），也要将bitstream文件加载到PL端。

找到U-Boot、bitstream

在读取U-Boot拷贝DDR中对应的加载地址，读取bitstream加载到PL端

调用FsblHandoff(HandoffAddress)

启动完U-Boot之后，FSBL的使命的就完成了。

可能是堆栈溢出、数组溢出、访问指向空地址的指针未声明的函数调用跑飞等原因。

1、堆栈溢出：以TI CCS3.3为例，程序运行的堆与栈的空间大小都是由软件设计师自己定义分配大小的。一般出现问题就是为DSP软件运行设置的堆或栈的空间太小，而导致程序不能正常运行。堆或栈空间太小编译生成out文件时，是不会报错的。TI ccs3.3中Stack Size是0x400(即默认的配置)，Heap Size是0x200（即默认配置）。如果程序出现莫名的跑飞情况可以试试改改这两个参数值。

2、数组溢出：数组溢出就是定义数组的空间大小，而通过数组下表访问时，下标超过了数组的边界，这样可能改写其他地址的数据，造成程序跑飞。有可能是使用未初始化的变量作为下标方位数组（这种情况编译器通常会有warning提示）；还有可能是通过计算关系计算下标，而在异常的情况下下标会越界（应用下标前对下标的范围进行判定，正常后再使用）。

3、访问指向空地址的指针：访问未初始化的空指针也可能出现DSP跑飞的情况；或者将指针作为函数参数传递时，指针未指向具体的地址，而在函数中使用，可能出现死机的情况（也可能不会，在ccs3.3下）。这些“指针未初始化”或“指针未指向具体变量”的问题编译器不会提示错误，最多提示警告。而“指针未指向具体变量”作为函数参数传递，在VC2005中，编译时不会报错，但有警告，但是在debug状态下运行时直接就跑死了，也算是暴露问题了。

4、未声明的函数调用跑飞：在TI ccs3.3中一些函数没有显式声明，而直接调用可能达不到函数预期的效果或者就是跑飞。以前写过一个CCS环境下因printf函数跑飞的问题。其实未声明函数调用，在zynq的开发平台vivado的SDK中也出现过，编译不报错，运行就是达不到预期的效果。

在Zynq-7000上编程PL大致有3种方法：1.用FSBL，将bitstream集成到boot.bin中2.用U-BOOT命令3.在Linux下用xdevcfg驱动。步骤：1.去掉bitstream的文件头用FSBL烧写PLImages没有什么好说的，用XilinxSDK的CreateBootImage工具即可完

---