1 FSBL介绍

1.1 背景

最近由于在工作中需要做一些底层备份的工作，用的芯片属于ZYNQ UltraScale+ MPSoC系列的，大致看了网上的一些资料，基本都是讲ZYNQ 7000系列，涉及ZYNQMP系列比较少，所以自己也是去了解了一下ZYNQMP系列的FSBL流程。与ZYNQ7000系列FSBL流程基本差别不大，涉及的一些流程可以借鉴。这里主要看的是米联客介绍的FSBL启动流程。

1.2 ZYNQMP启动流程

ZYNQMP的启动步骤，可以大致分为BootRom、FSBL、Uboot、Linux系统几个环节，这四个环节流程图如下：

1.首先，电源管理单元(PMU)执行 PMU ROM 固化程序来初始化系统，重置和唤醒相关的进程。
2.接着，根据拨码开关从相应内存位置将引导加载程序(PS 的 FSBL 代码)加载到芯片 RAM (OCM)中并执行。
3.然后，运行 ATF 之后启动 uboot 第一阶段引导程序初始化内存等基础硬件，将 uboot 第二阶段和kernel 加载到 DDR 中。
4.最后，从内存 DDR 中加载运行 uboot 第二阶段初始化相关设备，配置 kernel 启动的环境并引导kernel 从而启动 rootfs。
BootRom是固化在芯片内部的一段代码，我们不可以进行修改，而通过上图我们知道BootRom主要是用来加载FSBL到OCM中运行，并且将执行权限交给FSBL，关于BootRom怎么找到FSBL，主要是我们利用petalinux-package打包BOON.BIN时，存在一个BOOT.BIN的头部，里面包括了FSBL的大小，偏移地址等等，通过BOOT.BIN头找到FSBL，将执行权限交给FSBL，有兴趣的可以去Xilinx官网下载相关的文档查看，里面对Boot Header，image header table，partition header等介绍的很清楚。
我们主要来看看FSBL启动流程

2 FSBL启动流程

2.1 工程

因为我这边用到的工程主要是在Linux系统下利用Petalinux搭建的，具体xilinx的Vavido或者vitis我不会用，用的是FPGA那边给的配置好的xsa或者hdf文件，在ubuntu环境下搭建的工程，工程搭建完毕后直接利用petalinux-config -c u-boot/kernel/fsbl，就可以在工程中生成FSBL,U-BOOT和kernel的源码，这里我们以工程中生成的FSBL源码进行大致的分析。

2.2 流程

FSBL 的全名为 First Stage Boot Loader，即第一阶段引导加载程序。 FSBL 的任务比较重要，它需要完成以下的工作：

a. 初始化PS端
b. 使用 bit 文件配置 PL 端。
c. 加载 Uboot 到内存中。
d. 移交执行权限给 Uboot。
以下为 fsbl 的启动流程：
这个阶段需要完成一系列的初始化操作，首先会初始化 PS 端的内存与 MIO 接口等，然后读取 bit文件配置好 PL 端，值得注意的是 PL 端需要在 FSBL 的阶段配置好，否则是无法直接配置的。接着加载 Uboot 到内存中，最后 ARM 会跳转到内存中执行 Uboot 程序。

2.3 代码分析

因为 FSBL 的作用是引导 SSBL，所以引导裸机和引导 Uboot 的 FSBL 没有什么区别，因此我们直接从petalinux创建的工程查看 FSBL 的相关源码。
首先我们的平台是ZYNQMP，所以我们需要到***fsbl\lib\sw_apps\zynqmp_fsbl\src***下，里面存在链接脚本文件lscript_a53.ld和lscript.ld，打开如下：
可以看到ENTRY函数，进入初始化向量表_vector_table，这里进行一些初始化操作。
而*_vector_table定义在源码*fsbl\lib\bsp\standalone\src\arm\ARMv8\64bit\gcc\asm_vectors.S里面。

在向量表中可以看到，启动程序会跳转到_boot，为了查看其源码，我们需要找到_boot 的实现， _boot的实现在 boot.S 文件中，打开同目录下的 boot.S 文件：找到_boot，可以看到其首先在初始化处理器的各种模式，初始化 C 语言的执行环境：

这里会使能 I cache、 SP 堆栈、 caches、 MMU，然后跳转至_startup 函数启动

同样的方法，我们需要找到_startup 的实现，这个函数在同目录下的 xil-crt0.S 中，打开 xil-crt0.S文件并找到_startup：

在_startup 函数中，对 bss 进行了一系列的操作，然后清 bss，构造全局结构体，重启定时器之后跳转到 main 函数开始执行。
这里进入main函数，main函数路径：fsbl\lib\sw_apps\zynqmp_fsbl\src\xfsbl_main.c

main 函数会经历以下四个主要阶段：
a.各种初始化。
b.引导设备安装和 image 验证。
c. 加载并验证分区
d. 执行完FSBL，转到uboot，即第二阶段。
各种初始化：
这个函数包括了诸多软硬件的初始化操作，非常清楚地看到在 switch 中属于 XFSBL_STAGE1 也就是第一阶段，在其运行成功后，才会跳转到第二阶段继续执行，其位置为fsbl\lib\sw_apps\zynqmp_fsbl\xfsbl_initialization.c：
这个函数的第一步便是获取复位的原因。
紧接着是系统初始化：
在这个函数的注释中，调用了 psu_init()这个函数，该函数根据 PS 的类型进行 MIO,PLL,CLOCK,DDR一系列参数的设定。

处理器初始化：

DDR 初始化：
板卡初始化：
重置验证：
如果这些初始化操作均成功了，到这里整个初始化工作便可以告一段落了，接下来要运行第二阶段，也就是引导设备安装和 image 验证。
引导设备安装和 image 验证

这一段代码比较有趣，逻辑也比较清晰：首先运行初始化函数，然后根据返回参数来判断启动方式，分为错误、 JTAG 和普通启动模式。其中如果引导发现是 JTAG 模式就会直接跳转到第四步，这是因为第三步的任务是加载分区，而 JTAG 模式是不需要的。了解的初始化函数的返回值，我们再去查看其实现，同样还是在 xfsbl_initialization.c 文件中：

第一步为获取模式开关的参数，查看 XFsbl_PrimaryBootDeviceInit 函数：
其中一段就展示了获取模式开关的代码，注意此处不是读取模式开关，因为读取是由 BootROM完成的， FSBL 只是获取了 BootROM 的参数。这里以 NAND 启动方式为例，在读取到为XFSBL_NAND_BOOT_MODE 这个参数后，会进行如下的操作：
先是初始化设备（这里是 NAND），再从设备中读取 BOOT.bin 文件，最后关闭文件。
上一步完成后，紧接着就是读取验证头：
最后是设置第二启动设备，如果有第二启动设备，还要对其进行初始化操作：
加载并验证分区
部分启动方式可以跳过此部分，比如 JTAG 模式。

第三部分也是如出一辙，先加载分区，分为成功与失败两个情况，成功的情况下会继续验证分区。我们先来看 XFsbl_PartitionLoad 这个函数，它的定义在同目录 xfsbl_partition_load.c 这个文件里：
以上为 XFsbl_PartitionLoad 的核心代码，分为三步，先验证分区头，查验是不是对应的型号，如果是对应的型号则复制分区内容，最后是分区的验证。
回到 xfsbl_main.c 文件中，第三步还会对所有分区进行一次验证，保证所有分区均已加载完成：
这一步完成后，便会跳转至下个阶段。
转移执行权限
在第四阶段中，同样也是先运行移交权限的 XFsbl_Handoff 函数，然后处理各种返回的情况：分为三种情况，为：分区未加载完全，会跳转到第三步继续执行。继续移交权限，主要出现在一个应用执行完，需要运行下一个应用时。失败的情况，移交权限失败。还有一种情况就如同注释写的那样，应该永远也不会被执行。
看完整体的构架，接下来要看看 XFsbl_Handoff 的定义，了解一下移交执行权限究竟经过了哪些步骤，这个函数的定义位于 xfsbl_handoff.c 文件中：
恢复 SD 卡检测信号：
解除PS-PL 隔离以允许 u-boot 和 linux 访问 PL：
刷新 L1 和 L2 数据缓存，禁用数据缓存：
PM 初始化：
保护配置：
切换到 CPU 运行：
到这里， FSBL 阶段的工作全部完成，接下来就由 Uboot 来继续操作。

3 总结

相信大家看了上面的分析以及源代码后，大致可以了解FSBL的启动流程，对于FSBL，汇编阶段我们可以不必过于关注，如果我们需要修改FSBL，也只是修改FSBL的C语言阶段。
当然，如果真的分析了源码，我们可以发现在主函数中的starge3中，会依次加载BOOT.BIN中的几个分区，有几个分区就分别加载几个，但是，在***XFsbl_PartitionLoad***函数中，调用了三个函数，我仔细看了这三个函数，只是在验证每个分区的头部，对于uboot实体，并没有进行验证，如果我们在nand启动时由于bit位翻转，那系统将无法启动，所以后面我增加了对整个uboot实体的crc校验以及增加了备份分区，主分区加载失败，FSBL启动备份分区uboot镜像。
将在下一篇博客分析，后面也还会在uboot中增加kernel备份镜像功能。