痞子衡嵌入式：飛思卡爾Kinetis系列MCU啓動那些事（10）- KBOOT特性(可靠升級)

---

　　你們好，我是痞子衡，是正經搞技術的痞子。今天痞子衡給你們介紹的是飛思卡爾Kinetis系列MCU的KBOOT之可靠升級（Reliable Update）特性。

　　所謂可靠升級機制，即在更新Application過程當中不論發生任何異常狀況（通訊異常、系統斷電等）都能保證系統中至少有一份可用的Application用於恢復啓動，保證系統的正常運行。可靠升級是任何魯棒的Bootloader架構都應該要有的特性。做爲一個健全的Bootloader架構，KBOOT中固然包含可靠升級特性。今天痞子衡就爲你們介紹KBOOT中的Reliable Update特性：

1、可靠升級基本策略

　　可靠升級基本策略其實很簡單，在Flash裏劃分2個區，主分區用於存放待啓動的Application，備份區用於臨時存放新更新的Application，下載時永遠只往備份區存最新的Application，這樣即便下載過程當中發生意外，也僅致使備份區裏的Application不完整，不影響主分區裏的Application正常運行。僅當備份區裏的Application通過Bootloader驗證是完整的（詳見痞子衡以前寫過的 《KBOOT特性(完整性檢測)》 一文，經過完整性檢測即認爲Application是完整的），Bootloader纔會啓動更新工做，將主分區裏Application擦除，而後將備份區裏的Application拷貝到主分區，最後擦除備份區裏的Application，在這更新過程當中不用擔憂意外，由於任什麼時候候Flash裏都至少有一個Application是完整的。
　　KBOOT裏的可靠升級特性就是按照上述基本策略實現的，可是咱們知道KBOOT架構適用於上百種Kinetis芯片，上百種芯片特性各異，但就可靠升級這一特性而言，Kinetis芯片被分爲三類：

• 第一類：不含ROM，且Flash沒有SWAP特性，如MKL25Z128
• 第二類：不含ROM，但Flash含有SWAP特性，如MK65FN2M
• 第三類：含ROM，不管Flash是否含有SWAP，如MKE18F512

　　KBOOT可靠升級在三類Kinetis芯片上的實現是有區別的。對於第一類，Flash起始地址存放固定的Bootloader，Main/Backup App緊隨其後，這也是最多見的情形；對於第二類，由於Flash有SWAP特性，因此Flash被嚴格分爲兩個大小相等的Block，SWAP特性能夠直接邏輯上交換這兩個Block，所以兩個Block除了各自存放Application以外還分別存放了Bootloader；對於第三類，這就比較簡單了，Bootloader在獨立的ROM區域，不佔用Flash空間，所以Flash直接均分2等份，一份放Main App，另外一份放Backup App就行。

2、可靠升級具體實現

　　上一節講過，根據Kinetis芯片Flash是否含有SWAP特性，可靠升級的實現是不一樣的。若是Flash有SWAP特性，咱們稱之爲硬可靠升級；反之，若是Flash不含SWAP特性，咱們稱之爲軟可靠升級。在介紹可靠升級具體實現邏輯以前，痞子衡先爲你們比較一下軟/硬可靠升級的差別：

比較項目	軟可靠升級	硬可靠升級
適用芯片	全部Kinetis	僅含SWAP特性的Kinetis
Flash內容分佈	Bootloader + Main App + Backup App	Main Bootloader + Main App + Backup Bootloader + Backup App
備份區App存放地址	靈活定義	固定的
可否保留2份App	不能夠	能夠

2.1 觸發方式

　　不論是硬可靠升級仍是軟可靠升級都有兩種觸發方式，一種是上電啓動自觸發，上電Bootloader運行時會嘗試執行一次可靠升級，這種觸發方式是被動地且是一次性的；另外一種是命令式觸發，即用戶經過blhost.exe發送reliable-update命令主動執行可靠升級，這種方式可重複屢次。

2.1.1 命令式觸發

　　命令式觸發是觸發可靠升級操做的第一選擇，備份區下載完最新的Application後應緊跟着發送可靠升級命令完成新舊Application的更新。reliable-update命令格式在輸入blhost -?命令後能夠看到：

　　reliable-update命令僅有一個addr參數，對於硬可靠升級，這個addr參數是swap indicator地址（想了解swap indicator的意義須要查看Kinetis手冊FTFx一節），若是是首次啓動硬可靠升級，swap indicator地址可任意設置，若是已經啓動過硬可靠升級，swap indicator已經存在芯片IFR裏，此時addr必須與已存的swap indicator相一致；對於軟可靠升級，這個addr參數即備份區Application的存放起始地址（若是addr爲0，則使用Bootloader裏預約義的backup app存放地址）。

2.1.2 上電自觸發

　　上電自觸發方式存在的緣由是，用戶在備份區下載完Application以後可能會忘了主動觸發可靠升級，或者在執行主動可靠升級的過程當中發生了異常，那麼系統下一次啓動時應主動作一次可靠升級，確保將備份區最新的Application拷貝到主分區去運行。下圖是自觸發可靠升級在Bootloader啓動流程中的位置：

2.2 主邏輯

　　不管是上電自觸發仍是命令式觸發，在Bootloader裏其實都是調用的以下函數bootloader_reliable_update_as_requested()，命令式觸發傳入的參數值是(kReliableUpdateOption_Swap, addr)，上電自觸發傳入的參數值是(kReliableUpdateOption_Normal, 0)

void bootloader_reliable_update_as_requested(reliable_update_option_t option, uint32_t address)
{
    uint32_t backupApplicationBase;
#if BL_IS_HARDWARE_SWAP_ENABLED
    // 僅對於硬可靠升級，才區分option參數的差別
    uint32_t swapIndicatorAddress = address;
    if (option == kReliableUpdateOption_Normal)
    {
        // 檢測主分區App是否有效，若是有效，則不進行可靠升級
        uint32_t mainApplicationBase = get_application_base(kSpecifiedApplicationType_Main);
        if (is_specified_application_valid(mainApplicationBase))
        {
            update_reliable_update_status(kStatus_ReliableUpdateStillInMainApplication);
            return;
        }
        else
        {
            // 檢測flash swap狀態看其是否處於Ready狀態，若是是，則從IFR裏讀取已存swap indicator值
            status_t result = get_swap_indicator_address_if_system_is_in_ready(&swapIndicatorAddress);
            if (result != kStatus_FLASH_Success)
            {
                update_reliable_update_status(kStatus_ReliableUpdateSwapSystemNotReady);
                return;
            }
        }
    }
    backupApplicationBase = get_application_base(kSpecifiedApplicationType_Backup);
#else
    // 獲取備份區App的存放地址
    backupApplicationBase = (address == 0) ? get_application_base(kSpecifiedApplicationType_Backup) : address;
#endif // BL_IS_HARDWARE_SWAP_ENABLED

    // 檢測備份區App的BCA配置是否有效，BCA有效是進行可靠升級的前提
    if (!is_reliable_update_active(backupApplicationBase))
    {
        update_reliable_update_status(kStatus_ReliableUpdateInacive);
    }
    else
    {
        // 僅當備份區App經過了完整性檢測，纔會進行可靠升級
        if (is_specified_application_valid(backupApplicationBase))
        {
#if BL_IS_HARDWARE_SWAP_ENABLED
            status_t status = hardware_reliable_update(swapIndicatorAddress);
#else
            status_t status = software_reliable_update(backupApplicationBase);
#endif // BL_IS_HARDWARE_SWAP_ENABLED
            update_reliable_update_status(status);
        }
        else
        {
            update_reliable_update_status(kStatus_ReliableUpdateBackupApplicationInvalid);
        }
    }
}

2.2.1 軟可靠升級流程

　　軟可靠升級流程以下，首先根據不一樣觸發方式獲取備份區App的存放地址，而後檢測備份區App是否合法（包含BCA，且經過完整性驗證），一旦備份區App被驗證是合法的，Bootloader會擦除主分區App並將備份區App拷貝到主分區，最後再擦除備份區App。有朋友會疑問，爲什麼最後要擦除備份區App，由於當前的軟可靠升級實如今自觸發方式下第一件事就是去驗證備份區App是否有效，若是備份區App不擦除的話，每次上電都會作一次擦除和更新操做，會損耗Flash壽命。

　　上述流程就是KBOOT 2.0裏的軟可靠升級的實現邏輯。那麼這個流程有沒有改進空間呢？實際上是有的。若是咱們在App的BCA區域增長一個版本號，那麼就能夠作到在Flash裏保留兩份App。此時Bootloader下載App時再也不須要提供存放地址，Bootloader自動解析App的版本號，並用這個最新的App替換Flash裏版本最低的App。而Bootloader啓動時永遠尋找當前Flash裏版本最高的App去執行。

Note: 改進後的軟可靠升級有一個注意點，即Flash裏XIP App並非與位置無關的，所以兩份App的連接文件根據存放位置不一樣，連接起始地址是不一樣的。

2.2.2 硬可靠升級流程

　　硬可靠升級相比軟可靠升級，在流程看起來更復雜，由於硬可靠升級涉及Flash的SWAP特性，不過硬可靠升級不具通用性，所以痞子衡不打算詳細解釋其流程，感興趣的本身研究下面的流圖。

2.3 配置宏和狀態碼

　　對於KBOOT 2.0來講，目前僅有MK65默認使能了可靠升級，若是想要在其餘芯片上也使能這一特性，須要在對應芯片的bootloader_config.h裏修改/增長以下三個宏：

• BL_FEATURE_RELIABLE_UPDATE: 設爲1則使能可靠升級特性
• BL_FEATURE_HARDWARE_SWAP_UPDATE: 設爲1則爲硬可靠升級，0則爲軟可靠升級
• BL_BACKUP_APP_START: 預約義的備份區App存放地址

　　在使用reliable-update命令的過程當中會返回執行結果狀態碼，以及能夠用get-property得到當前可靠升級狀態機的狀態，一共有以下8個狀態碼：

　　至此，飛思卡爾Kinetis系列MCU的KBOOT之可靠升級（Reliable Update）痞子衡便介紹完畢了，掌聲在哪裏~~~