嵌入式系统那些事-xilinx multiboot番外篇

0、背景

1、文件的升级和运行过程

        下面的的这张图中，我们的嵌入式c语言文件或者汇编文件，经过一系列的编译和链接后，就变成了可以在设备上跑的可执行bin文件。与那种纯软的执行软件不同，二进制bin文件需要通过上位机传到嵌入式设备上，然后再由设备加载运行。这个过程是怎样的，在这个过程中又会遇到哪些异常情况呢。

 1.1 嵌入式设备升级过程

         如下图所示是嵌入式设备的一种常见的升级方式，可执行的bin文件通过tftp/ftp/sftp的方式下载到嵌入式设备的内存中，然后再将其烧录到flash中规划的位置；设备启动后，就会将每个组件的bin文件依次从flash中加载到ddr中运行。这是升级和启动的全流程，看起来很简单，但是在我们的实际工作中，经常会遇到板子变砖或者启动不起来的情况。如果只是裸板还好说，但是如果遇到已经装配好的设备，就要拆机，要是发生在生产阶段，那这将是一个致命的问题，如果流向了客户，问题就会变得更加棘手。通常情况下，我们要保证在各种升级异常的场景如断电，或者软件本身的bug导致系统起不来时，设备不会变砖，还可以救活，这就需要对关键的组件进行双备份。

2、基于xilinx multiboot的双区备份实现案例

        在xilinx的zynqmp版本中有这样一个特性multiboot，支持备份多个boot文件，当其中的一个boot起不来时，可以自动跳转到另外一个boot启动，其基本的原理如下图所示。初始时，都是从0地址开始加载有效的boot，在加载前首先会检查头部是否正常，如果发现头部异常或者是在交接给uboot前的某个阶段发生了错误，就会让multiboot寄存器的值加1，注意每加1，就移动32KB的位置，依次循环，直到找到另外一个备份的boot头部为止，就把这个boot开始的信息搬移到ddr中运行。

        借助于上面的这个特性，我们就可以实现一个最简单的boot双区备份，首先是我们在升级的时候，每次只固定的升级一个boot，如从0开始的boot，在flash 1M的位置处放置一个可以起来的boot，但是不会去动它，就在异常的情况下从这个boot启动。接下来，当我们检测到异常情况时可以直接给multiboot赋值为0x20，即1M的位置，一次就可以跳转到备区部分。

        如何验证上述方案的可行性呢，笔者提供了两条uboot下的命令，如上图所示的uboot bios命令行，其中一个可以读取multiboot寄存器的值，另一个可以改变multiboot的值，我们可以试验在1M的位置放置一个boot，然后直接修改multiboot的值为0x20，然后复位，看是否可以找到想要的boot。感兴趣的读者可以自己实验一下。

3、小结