基于ZYNQ的可靠镜像升级及Multiboot方案实现

相关资料：

https://blog.csdn.net/weixin_41922484/article/details/104037513

https://blog.csdn.net/weixin_43189165/article/details/97761784

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842174/Zynq-7000+AP+SoC+Boot+-+Multiboot+Tech+Tip#Zynq-7000APSoCBoot-MultibootTechTip-DocumentHistory

http://xinzero.com/zynq-boot-bin-file-structure.html

1 概述

        本文介绍了基于ZYNQ平台实现的一种可靠的，用于镜像升级的Multiboot方案。该方案可以有效保证在镜像升级失败的情况下，通过Multiboot功能使芯片从备份镜像启动。

2 Multiboot简介

        Multiboot往往在产品中被用于镜像文件的升级和备份，即IAP（In Application programming）应用。举个最简单的例子，在Flash中存入2个BOOT.bin镜像文件，分别为update image和golden image。镜像升级过程只更新update image，而golden image作为备份不被更新。这样做的目的是当update image出现异常，或update image更新失败导致无法从update image启动时，还可以切换到备份的golden image启动，避免硬件宕机。

        当然，2个镜像只是最简单的例子，实际应用中Multiboot可以用于多镜像的场合。

3 ZYNQ启动镜像BOOT.bin结构

        通过SDK生成的BOOT.bin文件的结构如下，从上到下对应地址由低到高。

        如果在生成bin文件时使能bit文件和elf文件的MD5校验（fsbl.elf无法使用MD5校验功能）。如下图：

        则会在bin文件末尾增加两者的MD5 checksum。此时BOOT.bin文件的结构为：

        MD5 checksum可以让FSBL检查bit文件和elf文件的正确性。这对于镜像升级来说具有很重要的作用。

        关于bin文件中BootROM Header, Image Header Table, Image Header, Partition Header等概念，请查询UG585和UG821这里不作具体介绍。

4 ZYNQ Boot过程

        芯片上电后首先BootROM启动，从Flash中加载运行FSBL。FSBL依次从Flash中读取bitstream，配置到PL端，读取elf文件，加载至DDR。最后FSBL结束运行，PS跳转至elf文件对应程序继续执行。

5 ZYNQ FSBL流程

        BOOT.bin文件中的Partition Header是FSBL加载bit文件和elf文件的重要参数。

6 ZYNQ Multiboot原理

        Multiboot的实现有2个前提条件：

• BootROM具有根据multiboot register连续搜索BootROM Header的能力。

        BootROM Header每次搜索地址增量为32KB，multiboot register的值随之递增1，直到找到有效的BootROM Header为止。如果multiboot register被除BootROM以外的程序（例如FSBL）修改过，则直接跳转到multiboot register对应地址的BootROM Header。

        需要注意BootROM Header搜索范围有一定限制。

• FSBL可以修改multiboot register的值，并使芯片复位再次进入BootROM运行。通过BootROM直接跳转到multiboot register对应地址的BootROM Header。

        在FSBL运行过程中，它会根据multiboot register的值找到Flash对应地址的bit文件和elf文件进行加载，在此过程中出现任何异常和错误而导致加载失败时，会通过FsblFallback函数更新multiboot register，并复位芯片，使BootROM重新运行，直到找到golden image，从而实现启动跳转。

7 ZYNQ Multiboot实现

7.1 基本方案

        通过SDK生成1个BOOT.bin作为update image和另一个作为golden image的BOOT.bin合成1个大的BOOT.bin文件，通过JTAG烧入Flash。注意golden image的首地址要32KB对齐。

        这样便可以实现Multiboot功能。目前，这种方案应用比较多。但是，有个潜在的隐患。如果后续更新update image的过程中，由于某些原因，比如突然断电，使update image的FSBL部分未能被完整的更新，甚至更新了错误的数据，则会导致芯片无法从update image和golden image启动，Multiboot功能失效。

        这是由于BootROM不对BOOT.bin中FSBL部分进行校验。如果BootROM将不完整或者存在错误的FSBL加载运行，异常的FSBL将无法正常加载bit文件和elf文件，也无法通过FsblFallback函数实现Multiboot。这种情况下PS将跑飞在错误的FSBL中，造成系统死锁，芯片无法正常BOOT，只能通过JTAG重烧Flash。对于产品来说这是致命的后果。

        另外，如果镜像的不完整性或错误发生在FSBL以外的部分，则都会被BootROM或FSBL检测出来。

• BootROM Header通过header checksum验证正确性，由BootROM进行校验。错误的header checksum会使BootROM继续往后搜索有效的BootROM Header。
• 在FSBL中，Partition Header通过header checksum验证正确性，bit和elf文件通过MD5 checksum验证正确性。Image Header Table和Image Header一般不被FSBL使用，所以正确性和完整性不重要。FSBL一旦检测出错误，就会通过FsblFallback实现Multiboot使芯片跳转进入golden image启动。

        所以，综上所述，如何保证镜像的FSBL部分在更新过程中的完整性是需要解决的关键问题。保证FSBL的完整性，才能保证Multiboot功能的可靠性。

7.2 可靠方案

        针对上述问题，这里给出一个可行的解决方案。

        将FSBL部分从镜像中独立出来，放在Flash的独立区域内。镜像升级不更新FSBL部分，这样无论在升级过程中出现任何异常状况，FSBL所在区域都不会出现擦除和写入，因此不会出现任何变化，Multiboot功能得以保证。

        要实现这一方案，需要将SDK生成的bin文件进行二次重组。具体方法为：

1. 将BootROM Header和FSBL部分提取出来，一起放在起始位置的地址空间内，需要保证地址范围为Flash sector大小的整数倍，这样可以避免在更新其他sector时被擦除。
2. 将Image Header Table, Image Header, Partition Header，bit文件及其MD5 checksum，elf文件及其MD5 checksum各自提取出来，根据规则前后排列组合到一起，放到BootROM Header和FSBL之后的地址空间内。
3. 由于各部分的地址空间发生了改变，原有BootROM Header, Image Header Table, Image Header, Partition Header不再可用。需要根据实际情况将其中涉及的部分字段值重新计算修改。

        最后，再将重组后的update image和golden image合并为同一个bin文件即可。