芯耀
102
痞子衡維護的 NXP-MCUBootUtility 工具距離上一個版本(v2.3)發(fā)布過去 3 個月了，這一次痞子衡為大家?guī)砹诵“姹旧?v2.3.1（第一次做 x.y.z 中 z 級別更新），這個版本主要有兩個比較重要的改動需要跟大家特別說明一下。
一、v2.3.1 更新記錄
二、兩個不可忽視的更新
> 改進: 在使用 Flashloader 里擦除操作時，某些情況下需要先檢查目標區(qū)域是否為空
> 修復: 當連接得到的 flash Page/Sector/Block Size 信息有誤時，無法做進一步下載
2.1 確定指定 Flash 區(qū)域為非空后再擦
我們知道，工具對于 i.MXRT1xxx 系列開發(fā)板的外掛 Flash 擦寫支持是通過加載二級
Flashloader 來實現(xiàn)的，而 Flashloader 來自于 SDK 包中的
boardsevkimxrt1xxxbootloader_examplesflashloader 工程。
Flashloader 中集成了完整的 FlexSPI NOR Flash 驅動，對于擦除操作，我們知道很多 Flash 都同時支持 4KB 和 64KB 擦除粒度，因為 Flashloader 是因 i.MXRT 芯片而異的，每個芯片的
具體 Flashloader 對于擦除的處理不盡相同，目前主要有兩個策略：
策略 1：永遠用 64KB 的粒度去做擦除。
策略 2：混合使用 4KB 和 64KB 的粒度來做擦除，大區(qū)域先用 64KB，到小區(qū)域再用 4KB 細化。
對于工具 v1.1 及之前版本，這兩種策略的 Flashloader 配合工具使用都不會有問題。但是從 v1.2 開始，工具配合使用策略 1 的 Flashloader 會有一些問題。目前已知 RT1050 在 HAB 加密模式下，一鍵下載 App 后去回讀會發(fā)現(xiàn)偏移 0x2000 之后本該是 App 的地方全是 0xFF，沒能正確下載，原因是工具流程里會在下載完 App 之后寫一次 FDCB，而做擦除時因為粒度是 64KB，所以誤擦了已下載的 App。
因此 v2.3.1 里的解決方案是，先判斷 FDCB 區(qū)域是否為全 0xFF，如果是的話，就不做擦除了，直接寫 FDCB。這個不是完美的解決方案，最好的方案還是修改 Flashloader 去使用策略 2 的擦除方法。
2.2 不依賴讀回的 Page/Sector/Block 信息去下載
工具在一鍵下載前首先需要連接上主芯片，在連接過程中會在左下角芯片狀態(tài)窗口顯示 Flash 的 Page/Sector/Block 信息，這個信息是從哪里來的呢？不同的情況下來源不同：
情況 1：如果當前 Flash 是全空的（或者沒有 FDCB），那么 Flashloader 會讀取 Flash 中的 SFDP 表，根據(jù) SFDP 表中的信息（包含 Page/Sector/Block Size）自動生成用于啟動的 512bytes 的 FDCB 寫入 Flash 的起始地址處，并在軟件界面同步顯示。
情況 2：如果 Flash 中已有 FDCB（這個 FDCB 可能來自于 SDK 里的啟動頭，也可能是 Flashloader 讀 SFDP 表生成的），那么 Flashloader 便會復用這個信息，不再重新寫入 FDCB。
對于情況 2 中的 FDCB 來自于 SDK 里的啟動頭，如果啟動頭中沒有填充有效的 Page/Sector/Block Size 信息，那么在工具窗口你會看到 Page/Sector/Block Size = 0x0/0xFFFFFFFF 的情況下，在這種情況下工具無法再進行后續(xù)下載，因為 v2.3 之前工具會用 Page/Sector Size 對擦除或燒寫的長度做對齊，顯然無法用 0x0/0xFFFFFFFF 做有效的對齊。
v2.3.1 做了改進，不再強制用 Page/Sector Size 對擦除或燒寫的長度做對齊，因為 Flashloader 里本身就對傳入的區(qū)域參數(shù)做了對齊處理。
至此，這次更新的主要特性便介紹完了。MCUBootUtility 項目地址為 https://github.com/JayHeng/NXP-MCUBootUtility， 雖然當前版本（v2.3.1）功能已經(jīng)非常完備，你還是可以在此基礎上再添加自己想要的功能。如此神器，還不快快去下載試用？
