Zynq FSBL代码导读.doc

FSBL代码导读一、main函数执行之前FSBL模板的代码是跟ISE的版本有关的，我用的是14.3，内容会比14.2版更多一点，但是基本过程是一样的。板子上电之后，最先执行的并不是FSBL中的main函数，因为这个时候板子还没有初始化，不具备执行C语言的能力，此时只能执行汇编代码，所执行的代码是由BSP提供的。我们打开zynq_fsbl_bspps7_cortexa9_0libsrcstandalone_v3_07_asrc文件夹，里面有一个asm_vector.S文件，这个文件声明了一个代码段，位于地址0处。开机之后，PS自动执行地址0处的指令，其第一句话就是一个跳转：B _boot。如下：于是就跳转到boot.S中执行_boot标号下的代码了，_boot会对系统做初始化，当它执行完后，PS将具备执行C代码的能力，接着在_boot的代码中，再次执行了一个跳转：_start标号位于xil.crt0.S中，仍然对系统进行设置，我们看到，第一句话就是跳转到_cpu_init去执行cpu初始化。代码部分截图如下： 在_start的末尾，BSP终于完成了自己的工作，PS将跳转到main函数开始执行。如下：二、main函数执行过程终于系统进入了FSBL阶段。我们打开zynq_fsblsrc文件夹，然后打开main函数：Main函数首先是一些宏定义，接下来就是执行ps7_int（）函数。SDK是一个很智能的工具，图中的灰色阴影部分是SDK判断出了PEEP_CODE这个宏没有定义，所以用灰颜色提示读者这段代码不用执行。ps7_init函数位于ps7_init.c文件中。这个C文件是由XPS根据用户的配置自动生成的。我们进入ps7_init函数看一下，这个函数很短：根据代码，很明显可以猜到，ps7_init函数其实执行了mio,pll,clock,ddr和某些外设的初始化。我们接着看FSBL的main函数，根据XPS自动生成的ps7_init.c执行完初始化之后，FSBL将根据启动状态寄存器判断是采用的哪种启动模式。有四种启动模式，分别是QSPI，NOR，JTAG，SD卡等模式。每种模式都有一段独立的代码，举个例子，我们看SD卡模式的执行代码：可以看到，系统先对SD卡初始化，并且要求SD卡中必须要有BOOT.BIN文件。如果没有，那么从SD卡启动板子就会失败。这也是为什么我们生成启动镜像必须命名为BOOT.BIN的原因。需要注意的是NAND启动模式被禁用了，因为FSBL中有一个宏没有定义，所以处于灰色状态。接下来的代码我们只看一下注释就大概知道干什么了： 在明确了启动模式之后，PS将在相应的flash中去寻找.bit文件和用户程序，通过遍历一些partition（最多15个），如果找到了.bit文件，那么就不重启，直接配置PL，然后再找用户程序。如果没找到.bit就软件复位一下，然后调整地址，接着验证下一个partition。充分体现这个过程的，是这个函数：PartitionMove函数很复杂，我们只看注释：这个注释说的就是找到了.bit文件就配置PL，找到了用户程序就加载到内存。这个函数执行完之后，返回值就是用户程序的执行地址。这个执行地址位于用户文件的文件头中，是由编译器或者ISE自己生成的。找到了用户程序的执行地址，那么FSBL函数就该交接了，完成这个过程的是FsblHandoff函数：这个函数完成交接，并且一去不复返，再也不会返回，从此PS就开始执行了用户代码。那么交接究竟是怎么完成的？其实我们直观上很容易猜到肯定是一个跳转指令。带着猜测，我们深入FsblHandoff函数，最后果然找到了：其中bx lr指令就是跳转到用户代码执行。3、 拓展FSBL事实上，在找到用户程序的执行地址后，FSBL并没有马上执行跳转，而是执行了这个函数：这是一个钩子函数，它只有函数定义，但是没有任何内容，是个空函数。是FSBL提供给用户自己扩展的，你可以在这个函数中填写任何可执行内容。该函数会在交接到用户程序之前执行。类似的函数还有FsblHookAfterHandoff( )。这样在交接到用户代码之后也有钩子函数，同样，在FSBL找到.bit文件配置PL前后，也有两个钩子函数。这几个钩子函数貌似只有14.3版本里面有，14.2里面没有。4、 FSBL的限制FSBL有两个限制，这是写用户程序的时候需要知道的：1,FSBL没有重新映射内存，所以内存的基地址是1M，用户代码只能在1M以上的地址中执行。根据我的理解，只要修改FSBL，定义ECC_ENABLE，让如下代码从被禁止状态恢复成可执行状态就可以破解这个限制：原因在于，很多系统代码都是这样的，将1M以下的地址空间作为函数出错的返回地址。FS