目錄
嵌入式Linux系統從內部功能劃分角度主要包含三個核心組成部分：BootLoader（多采用開源源碼的U-Boot）、Kernel（Linux內核）、RootFS（根文件系統）。嵌入式Linux系統啓動過程均是先從BootLoader引導，由BootLoader初始化CPU、DDR、Cache等硬件設備，再對Linux內核進行解壓並拷貝到內存，隨後轉到內核地址執行；Linux內核在完成系統初始化之後將掛載RootFS根文件系統，並加載必要內核模塊，啓動應用程序。
正如我們所熟知的，嵌入式Linux設備在出廠前均會對固件進行首次燒錄保證設備能正常啓動且功能正常，而後續使用過程中大多都是通過在線升級的方式對設備進行固件更新以修正問題或迭代功能。然而固件在線升級時，可能會出現斷電導致固件未完全更新從而引發設備無法正常啓動的異常情況。因此，嵌入式Linux設備升級固件時應具備容錯校驗功能，如果升級失敗，應能自動恢復並正常運行。
對於不同的硬件平臺，升級失敗之後自動恢復的方案也存在着些許差異，下面就對QCA、MTK平臺的雙Image備份方案進行分析總結與對比，期望幫助大家理解鏡像備份原理，或者拓展其他可行方案。
QCA Fail Safe Boot
QCA Fail-safe boot機制正是爲了避免設備固件升級異常斷電而導致無法正常啓動的問題。因Nor Flash售價高，而且相同成本容量比Nand Flash小，出於成本考慮，大多涉及雙Image備份功能的嵌入式Linux系統均採用Nand Flash作爲存儲介質，QCA Fail-safe機制也是在Nand Flash存儲介質下提供支持的。下面將對Fail-safe boot機制進行詳細分析：
1、Fail-safe boot對嵌入式系統所有需要更新的Flash分區創建備選分區；
主要分區作用如下所示：
- SBL1 ：二級引導程序（secondary boot loader），根據系統狀況決定設備是從主分區還是備選分區啓動；
- MIBIB ：系統分區表信息；
- BOOTCONFIG 、 BOOTCONFIG1 ：故障保護分區信息(Failsafe partition information)，存儲主引導標誌、分區名、開始/結束標誌、備份分區數量等信息；
- APPSBLENV ：分區大小512KB，存儲u-boot環境變量；
- APPSBL 、 APPSBL_1 ：分區大小1536KB，U-boot引導程序；
- rootfs 、 rootfs_1 ：Linux Kernel與RootFS分區；
2、Fail-safe boot使用BOOTCONFIG(1)分區記錄各可選分區引導信息；
故障保護分區信息（BOOTCONFIG）主要由如下信息構成：
- start magic、end magic：開始/結束標誌；
- age：使用年限；
- numaltpart：備選分區數量；
- per_part_info[numaltpart]：備選分區信息，包含name分區名和Primary_boot主引導標誌，其中Primary_boot可取值0/1，當1時，表示使用備選分區啓動；當0時，表示使用主分區啓動；
3、Fail-safe boot固件升級寫入備選分區並在升級成功之後更新BOOTCONFIG(1)已升級分區的引導信息；
固件升級之前，BOOTCONFIG(1)分區信息如上所示，APPSBL、rootfs等分區的Primary_boot值均爲0，即表示系統啓動時將從APPSBL、rootfs主分區引導；
rootfs升級成功之後，對BOOTCONFIG(1)存儲的age（疊加）、rootfs分區Primary_boot（取反，即0變爲1、1變爲0）等內容進行更新。若升級失敗（異常斷電或手動中斷），BOOTCONFIG(1)分區存儲信息便不會更新，信息保持不變。
4、Fail-safe boot二級引導程序啓動時會讀取BOOTCONFIG與BOOTCONFIG1分區信息，並根據各分區Primary_boot值選擇主分區還是備選分區啓動；
系統啓動時，會依次讀取BOOTCONFIG和BOOTCONFIG1分區內容，並對存儲信息進行校對，這塊邏輯不作詳細闡述，大家可參考下圖進行理解。其實系統啓動的關鍵在於根據Primary_boot值決定是否“swap offset of the partitions”，即選擇主分區還是分選分區啓動。
“swap offset of the partitions”主要是爲了交換主分區名指向的分區地址，下面以rootfs升級前後啓動對比進行闡述，當升級之前時，rootfs Primary_boot值爲0，則系統從主分區啓動，即rootfs指向根文件系統第一個分區地址處，從此地址啓動；而升級成功之後，rootfs Primary_boot值變爲1，則系統從備選分區啓動，此時rootfs指向根文件系統第二個分區地址處，並從此地址啓動。
- rootfs primaryboot值爲0：
0x000000000000-0x000000180000 : "0:SBL1"
0x000000180000-0x000000280000 : "0:MIBIB"
0x000000280000-0x000000300000 : "0:BOOTCONFIG"
0x000000300000-0x000000380000 : "0:BOOTCONFIG1"
0x000000d80000-0x000000e00000 : "0:APPSBLENV"
0x000000e00000-0x000000f80000 : "0:APPSBL"
0x000000f80000-0x000001100000 : "0:APPSBL_1"
0x000001100000-0x000001180000 : "0:ART"
0x000001180000-0x000003e20000 : "rootfs"
mtd: device 17 (rootfs) set to be root filesystem
mtdsplit: no squashfs found in "rootfs"
0x000003e20000-0x000006ac0000 : "rootfs_1"
0x000006ac0000-0x000006b40000 : "0:ETHPHYFW"
- rootfs primaryboot值爲1：
0x000000000000-0x000000180000 : "0:SBL1"
0x000000180000-0x000000280000 : "0:MIBIB"
0x000000280000-0x000000300000 : "0:BOOTCONFIG"
0x000000300000-0x000000380000 : "0:BOOTCONFIG1"
0x000000d80000-0x000000e00000 : "0:APPSBLENV"
0x000000e00000-0x000000f80000 : "0:APPSBL"
0x000000f80000-0x000001100000 : "0:APPSBL_1"
0x000001100000-0x000001180000 : "0:ART"
0x000001180000-0x000003e20000 : "rootfs_1"
0x000003e20000-0x000006ac0000 : "rootfs"
mtd: device 18 (rootfs) set to be root filesystem
mtdsplit: no squashfs found in "rootfs"
0x000006ac0000-0x000006b40000 : "0:ETHPHYFW"
如上，對QCA Fail-safe boot從備選分區劃分、引導信息存儲、升級失敗或成功後引導信息的處理，以及系統如何根據引導信息選擇主/備選分區啓動的實現進行了詳細分析。QCA Fail-safe boot可對任何場景下升級斷電造成的異常進行自動恢復。
MTK Dual Image Boot
相對QCA Fail-safe boot方案而言，MTK Dual-image boot方案就比較簡單，易理解。MTK Dual-image boot不存在二級引導程序，也不存在引導信息存儲備份，其只是簡單的對rootfs劃分備選分區，啓動時BootLoader會根據mkimage生成的CRC校驗值對Image進行校驗，當校驗失敗時會將備選分區的Image拷貝到主分區中啓動。
1、MTK Dual-image boot只對rootfs鏡像劃分備選分區rootfs_1；
2、MTK Dual-image boot固件升級時統一寫入rootfs鏡像主分區；
3、MTK Dual-image boot系統啓動時，會根據rootfs鏡像的CRC校驗值判斷主分區是否損壞，若損壞則將rootfs_1鏡像備選分區拷貝到rootfs主分區，後續從rootfs主分區啓動；當主分區和備選分區均校驗失敗時，系統啓動異常。
如上，對MTK Dual-image boot進行了簡要分析，從整個方案可知，MTK Dual-image boot並不能對任何場景下升級斷電造成的異常進行自動恢復。因爲MTK Dual-image boot方案只對rootfs鏡像（Linux內核+根文件系統）進行備份恢復，未對BootLoader進行備份，那當對BootLoader進行更新且碰巧異常斷電導致該分區未正常寫完時，BootLoader引導程序便遭到損壞，系統便不能正常引導。此時，Dual-image boot也就失去了效果。
當然，功能開發與更新角度考量，BootLoader相較於rootfs/kernel更新頻率從是比較低的。因此，雖然MTK Dual-image boot不能保證任何場景下的自動恢復，但其還算簡單但實用的雙鏡像備份恢復方案。