汽車軟體Boot程式的主要作用是重新整理App程式。在一個具體客戶項目中，Boot也是客戶需求的一部分，跟随項目也有軟體開發計劃（有的為了和其它Boot區分，把項目上的Boot稱作CB, Customer Boot）。
對于已經下線盒蓋的控制器，無論是在供應商或者客戶手裡測試，隻能通過CB重新整理App。如果需要CB自重新整理，就需要額外的方法。
1、規範：
整車廠隻有對App程式重新整理的規範，沒有對Boot自重新整理的規範。因為規範是針對量産車的，售後隻負責App程式的更新，不對Boot更新（也不允許Boot更新）。
是以，Boot的自重新整理隻存在于項目開發階段，且由供應商自行提供方案。本文分析五種Boot自更新方式的優缺點。
方式一，SB更新CB：
如圖1-a，有的軟體架構是兩級Boot：SB+CB，Start Boot隻檢查CPU最小系統，與具體項目的外圍電路無關，它獨立于客戶需求，由供應商自行維護，在Pilot項目早期就應開發完成。
因為程式啟動順序是SB->CB->App,這樣在SB裡增加重新整理邏輯可以更新CB。通常情況下運作CB更新App程式，特殊情況下程式啟動後一直停留在SB裡，更新CB。
優點：
1.邏輯結構簡單清晰，軟體分工明确。
2.一次重新整理，操作簡易。
缺點：
1.需要較大的Flash空間在SB裡存放重新整理邏輯，項目SOP後又要禁止這種重新整理方式，造成額外的浪費。
2.軟體分三級啟動，結構複雜，開發和維護成本較高。對于不需要SB的控制器是一種負擔。
3.萬一SB也需要更新怎麼辦？按照這種政策，還得做個SSB？顯然不現實。
方式二、RAM+Flash Reboot更新
如圖2-a，不存在SB情況下，程式啟動順序是CB->App。需要重新整理Boot時，首先把Reboot程式下載下傳到不用的RAM裡（圖2-b），然後在RAM環境下運作ReBoot,下載下傳新的CB（圖2-c）
優點：
1. 不需要額外的Flash空間，Boot程式運作隻需要少量的RAM，是以為App設計的RAM臨時可以儲存Reboot程式。
2. RAM擦寫速度很快，則下載下傳ReBoot的速度會很快。
缺點：
在CB更新過程中萬一CPU掉電，重新上電後Reboot内容全無，CB已經破損，程式不能正常啟動，控制器癱瘓，隻能開蓋用JTAG燒寫程式。
方式三、RAM+RAM ReBoot更新（對方式二的改進）
首先把ReBoot（藍色）+NewCB（紫色）一起都下載下傳到RAM裡（圖3-a），然後運作ReBoot,擦除CB Flash區域，将RAM中NewCB複制到CB Flash區域（這一步内部完成）。
最後，重新上電複位，RAM中的ReBoot和NewCB自動丢失，程式從新的CB開始運作。
優點：
1.相比方式二少了一步重新整理（因為ReBoot和CB是綁在一起的）。
2.相比方式二CB更新全部在CPU内部執行，不受外界幹擾，耗時更短。
缺點：
1. 相比方式二需要更大的RAM空間存儲ReBoot+NewCB。
2. 和方式二一樣存在CB更新階段掉電後控制器癱瘓的風險 。
方式四、借助App程式Flash空間
重新整理分三步：1.圖4-b運作CB，擦除App，把ReBoot下載下傳到App區域。2.圖4-c運作ReBoot,擦除舊CB，刷入新CB。3.圖4-d運作新CB，刷回App。
優點：
1.不需要額外的Flash和RAM資源。
2.穩定可靠，通過優化設計，可以保證在任何一個步驟突然掉電，上電後可以繼續操作，控制器不會刷死。（詳細設計方法請看附錄）
3.對CB做稍微改造就可以成為Reboot程式，開發快速。
缺點：
1.步驟繁多，為了更新CB必須要先擦除App，最後恢複App，至少三次重新整理。對不熟悉步驟的操作者容易搞混亂。
2.整體重新整理時間會較長，兩次Boot+一次App
方式五、借助額外Flash空間
相比方式四，需要一塊和CB一樣大小的額外Flash空間，重新整理分三步：
1. 圖5-b,運作CB，刷入ReBoot到額外Flash。
2. 圖5-c,運作ReBoot，更新CB。
3. 運作新的CB，破壞ReBoot（全部擦除，或隻擦除ReBoot有效性标志）
優點：相比方式四，不需要破壞App程式，也省去了這部分更新時間。
缺點：相比方式四，需要額外的Flash空間，且必須是獨立的Block。
小結：
本質上隻有三種：
1. 依賴啟動程式SB（方式一），當CPU的Flash資源很富餘且項目需要兩級Boot時，用該方法最節省時間。
2. 借助RAM（方式二、三）3.借助Flash（方式四、五）。隻需要單級Boot（CB）時，可以容忍因Boot重新整理癱瘓必須要給控制器開蓋帶來時間，人力，物力的成本損耗的情況下用方式二，三較友善。
3. 隻需要單級Boot（CB）時，不允許或不友善控制器開蓋，但可以容忍Boot更新步驟繁多時間較長的情況下用方式四、五最可靠。
綜上，工程師需要根據整體軟體架構，CPU資源，時間人力物料等成本因素綜合考慮一種适合自己産品及項目的Boot自重新整理方法。
附錄：
《Boot自重新整理方式四（借助Flash）的具體實作方法》
背景：
對于方式四借助Flash重新整理【不存在刷死風險，在任何一個步驟中控制器突然掉電，上電後可以繼續操作。】的結論，是有條件的。筆者給出這個結論是從最理想的前提思考的，即隻要控制器中至少有一個Boot存在（即使一個是壞的），程式就可以從任何一正常的Boot啟動運作。這裡就有一個問題，CPU怎麼判斷哪個Boot是好的，哪個是壞的？現在分析一下存在控制器刷死這種風險的情況和幾種對策方案。
兩級啟動位址介紹：
如下圖示，CPU上電後程式按位址順序，檢查BootSector的有效性，如果BOOT_ID合法則從指定的位址開始執行，否則檢查下一個BootSector。
考慮CPU至少具備兩個啟動位址的情況，如圖1-a,當且僅當啟動位址1有效時（App為空），程式啟動後自動進入Boot。如圖1-b,當且僅當啟動位址2有效時（不帶Boot測試），程式啟動後自動進入App。
如圖1-c，當啟動位址1，2都有效勢，程式優先從位址1啟動，在Boot裡檢查App程式有效時，再靠跳轉指令Jump到啟動位址2，開始運作App。
方式四控制器刷死情況分析：
如圖 2-a，運作Reboot更新CB途中斷電。重新上電後，如圖2-b，由于啟動位址1的内容是在重新整理開始就被更新了是有效的，程式會進入CB運作，但是CB不完整，必然運作出錯，程式不會跳入ReBoot裡，進而不能再重新整理（即刷死）。
假設從擦除完舊CB開始到刷入新CB完成的時間有10S，在此期間掉電的可能性也不能忽略。
對策一、Boot有效性标志與啟動位址重合
考慮最普遍情況，CPU隻能整塊（Block）的擦出（16K,32K,64K...），可以最少4位元組機關寫，沒有順序限制，現在CB隻用了一個Block。
現在調整重新整理順序：擦出成功後，先重新整理橙色區域，最後一步重新整理啟動位址1有效性标志（灰色區域）。這樣，即使在更新橙色區域過程中掉電。
重新上電後，程式依然從啟動位址2開始運作，即重新運作Reboot繼續等待重新整理CB指令，如圖3-a所示。
具體操作時也不需要更改下載下傳流程，使用$34,36服務按順序從上位機傳輸資料到CPU中，先把啟動位址1的有效性标志放到RAM裡，
當把橙色區域都下載下傳到Flash後，再從RAM裡把啟動位址1的有效性标志寫到Flash裡（這一步10ms以内即可完成，完全可以忽略在此時間内掉電的可能性）
如果最後一步啟動位址1重新整理成功，再重新上電後，程式從啟動位址1開始運作新的Boot。即啟動位址1起了Boot有效性标志的作用（最先擦，最後寫），如圖3-b所示。
對策二、Boot有效性标志獨立置尾，增加Boot有效性檢查邏輯
如圖4-a,把Boot分成2個段，Sec1裡僅存放少量的啟動自檢查邏輯，當它檢測到置于Sec2末尾的CB_ValidFlg無效時，即認為Boot是不完整的，則程式控制跳轉到啟動位址2繼續運作ReBoot，重新重新整理Boot。
如圖4-b,當Sec1的邏輯檢測到CB_ValidFlg有效時，即認為Boot重新整理完成，則程式控制跳轉入Sec2裡，此時由于App(ReBoot)末尾的App_ValidFlg是無效的，程式并不會跳轉入ReBoot裡，接下來就可以刷入新的App了。
這種方法隻需要對CB的邏輯和段配置設定做一下調整，不需要更改重新整理順序。Sec1裡的啟動自檢查邏輯可以做的盡量小，則隻要保證重新整理Sec1段的過程中不掉電，控制器就不會刷死，大大降低風險。
但是對量産軟體，檢查CB_ValidFlg無效就直接跳轉入App是不合理的，是以當Boot最終定型後，應該把這個跳轉邏輯關閉。
小結：
對策一簡單可靠，經過實際測試驗證，完全可以滿足穩定重新整理ECU的要求。