記一個bootloader的cache問題

問題背景

最近往一個armv7板子的bootloader中移植瞭解壓算法，移植自己還比較順利，但移植完了發現，功能是正常的，但效率大打折扣。解壓一樣的數據，耗時大約是uboot的10倍。

初步定位

從這個10倍的量級上，比較懷疑是Cache相關，但其餘懷疑的因素也要先確認了下。先確認下直接相關的DDR和CPU。

DDR的驅動是徹底同樣的，因此DDR先排除。

CPU的話，芯片上電後時鐘是固化在芯片中的BootROM設定的，默認比較低，但看代碼CPU時鐘是調整過了，已經提升到1G了。爲了確認改動是生效的，嘗試將CPU頻率設定下降了些，發現速度確實隨之變慢了，那就說明CPU時鐘配置確實生效了。退一步講，CPU的設置即便沒成功，也不該該形成十倍的性能差距。

那麼目光就落在了Cache身上。從代碼上看，MMU，DCache和ICache是都打開了的。那麼既然使能了，得想個辦法確認是否確實起做用了，一個簡單的辦法就是，故意不使能它，看性能是否有變化。

修改代碼，分別測試了不使能DCacne和不使能ICache的解壓時間，從結果看出ICache起做用了，而DCache沒起做用，開關DCache對解壓時間沒什麼影響。那問題確定就在DCache上。

Cache設定

到了這一步，我想到以前解決的另外一個Cache不起做用的問題，最終是查到必須設置smp bit，因而加上對應的設置代碼，但加上後問題並沒解決。

繼續google，查閱了一些Cache的資料後，目光轉向了mmu的page table設置。

簡單來講，在啓用mmu時，須要給出一個page table告知mmu，虛擬地址和物理地址如何映射，在這個page table中，每一項還有若干功能位，包括了權限，Cache等設置。
對於一些寄存器相關的地址，通常就不使能Cache，這樣讀寫寄存器不會受Cache影響。而對於其餘正常的地址，通常會啓用Cache以提升效率。而啓用Cache還須要具體配置Cache的模式，能夠配置爲write-through(寫通/寫穿) 或 wrike-back(寫回)。對於write-through，數據會既寫到Cache又寫到主存，Cache和主存的數據老是一致的。對於write-back，數據只寫到Cache，並標記爲dirty，當Cache被換出時才寫到主存。

對照實際的page table，發現設置的是write-through。write-through每次都須要實際寫到主存，速度天然是慢的，趕忙修改成write-back測試下。果真解壓速度得到了質的飛躍。

本次問題中，個人代碼自己是運行在Sram上，而須要解壓的源數據，以及解壓後的數據則是在Dram上。在將Dram對應地址的設置改成write-back以後，速度得到了大約3倍的提高。進一步將Sram對應的地址也設置爲write-back以後，速度再次得到約10倍的提高。累計提高約28倍，使人不只讚歎Cache果真是個好東西。

順便提一句，最開始加的smp bit確實是須要的，各位若是發現DCache沒起做用，能夠檢查下這個設置，以前在另外一個問題上也是坑了我好幾天才從uboot中揪出這個配置。

Cache回刷

改完以後，解壓速度槓槓的，但也帶來了一些其餘的問題，例如個人系統啓動不了了，bootloader跳轉過去就直接掛了。想了下，應該是改成write-back後Cache和主存的數據存在不一致致使的。 若是是在主系統中，那對Cache就得精細化控制，該回刷就回刷該無效就無效，但在這個問題中個人場景比較簡單，bootloader一貧如洗，就簡單些吧，再移植一段刷Cache的代碼，直接刷所有DCache。而後在幾個關鍵的地方調用了下，果真，啓動流程恢復正常了。