記一次nor flash韌體燒錄速度優化
阿新 • • 發佈:2020-03-22
## 背景
某個方案使用的是spinor作為儲存介質,每次燒錄新韌體都耗時數分鐘,為了提高效率,需要對其進行優化。
## 分析流程
### 基本流程
當前燒錄流程,有一個可選步驟,全盤擦除,這個步驟耗時達數分鐘。不過這是可選的。
接下來必經的步驟,就是從PC端接收資料寫入flash了。
### 已有優化
目前倒是已經有一個優化,在收到資料需要寫入時,會先讀出flash中的資料跟這筆要寫入的資料進行比較,如果資料相同就直接跳過,資料不同,才進行擦除和寫入。
這個優化的依據是,相對於一次擦除和寫入的耗時來說,讀出和比較的耗時很少,一旦命中就可節省掉這次寫的開銷。在平時除錯的時候,兩次燒錄的韌體可能有些資料是完全一樣的,這種場景下此處的優化就能發揮作用了。
### 優化點
初步分析,從流程上看沒什麼問題,最大的耗時在擦除上,但畢竟nor的物理特性就是需要先擦除再寫入的。
但仔細分析,其實還是有優化空間的,這個空間還就在於nor的擦除上。
nor擁有多條擦除的命令,可以擦除4k,32k,64k或者整片擦除。這些命令的耗時是不同的。
方案上由於分割槽規劃設定了最小為4k的分割槽,所以nor就被配置為4k sector,則nor驅動使用的擦除命令就是對應的4k擦除的命令。而這是效率最低的一種擦除方式。
當前方案在全盤擦除時,是使用迴圈呼叫4k擦除實現的,在後續寫入資料時也都是以4k為單位進行擦除和寫入,在擦除上耗費了大量時間。
## nor的幾種擦除命令
這幾種擦除方式,差異到底有多大呢?
找兩款16M的norflash規格書看看。
![](https://img2020.cnblogs.com/blog/908492/202003/908492-20200314174654805-896133943.png)
比較表格:
| 擦除大小(Kbytes) | 擦除時間(ms) | 每4k擦除耗時(ms) | 以4k為基準的耗時比例 |
| ---- | ---- | ---- | ---- |
| 4 | 70 | 70 | 100% |
| 32 | 150 | 18.75 | 26% |
| 64 | 200 | 12.5 | 17% |
| 16 * 1024 | 3500 | 0.85 | 1.2% |
另一款:
![](https://img2020.cnblogs.com/blog/908492/202003/908492-20200314175818373-1299968009.png)
比較表格:
| 擦除大小(Kbytes) | 擦除時間(ms) | 每4k擦除耗時(ms) | 以4k為基準的耗時比例 |
| ---- | ---- | ---- | ---- |
| 4 | 25 | 25 | 100% |
| 32 | 140 | 17.5 | 70% |
| 64 | 250 | 15.62 | 62% |
| 16 * 1024 | 2600 | 0.63 | 2.5% |
從以上統計結果看,一次擦除的空間越大,平均速度就越快。
特別是chip擦除的速度高達到4k擦除的幾十倍。
## 優化方案
找到了優化點,結合燒錄流程就有了以下思路
### 方案一
設法將4k擦除改為32k,64k擦除。
這種對於分割槽本身並非4k對齊來說,實現上會比較麻煩,需要程式碼中維護一個緩衝區進行資料的拼接,並處理一些邊界情況。
### 方案二
在燒錄的最開始進行一次chip擦除。並在後續的寫入時,跳過擦除步驟,直接寫入。
這種方案對於燒錄場景來說,非常合適,實現起來也簡單。
最終採用方案二,改動小,效果明顯,燒錄速度從數分鐘降到了1分鐘以內。
但這個只適用於燒錄場景。如果是要對系統執行時的寫效能進行優化,就只能考慮儘量用64k擦除了。
本文地址: [https://www.cnblogs.com/zqb-all/p/12493500.html](https://www.cnblogs.com/zqb-all/p/12493500.html)
公眾號: [https://sourl.cn/rgbq6M](https://sourl.cn