|
十年磨一劍, 霜刃未曾試 |
你可能有興趣的文章:
這個就是目前開發板很常見的 sd card booting, 以前的開發板很少有這樣的功能。
從開發 stm32f407 的程式以來, 每一個小程式都是為了打造 os 而設計的, 終於來到這裡了, 有了sd card, 就可以有大容量的檔案系統。不過 os 還是沒打造出來, 得要加把勁才行。
想了好久的點子能把它實現真是一件美好的事情。現在很多開發板都提供了從 sd 開機的功能, 例如樹莓派, 比起直接操作 flash 簡單很多, 但要自己實作這功能, 就沒那麼容易, 從 fig 0 的金字塔圖就可以看出需要很多知識, 這是集合了之前努力所開的果實, 現在讓我們把之前的努力集合起來。
我在很久之前就有這想法了, 但直到在《
20150117 成功大學 UniDEMO 期末聯合 DEMO 計畫》看到 mp3 player 那組的作品後, 我才對於 sd card 的讀取有點想法, 這是我最難克服的部份, 沒想到成大的學生在專題就把 sd card 搞定了, 真是厲害。直到 20161119 我才完成, 從想法到實現, 應該超過兩年。
為什麼有這樣的想法, 是因為 flash 壽命有限, 如果因為 flash 寫爛了, 這塊開發板就不能用了豈不可惜, 透過 sd card boot 就可以避免這樣的問題, 我再也不用常常改寫 flash 的 boot code 了, 讓開發板生命可以持續更久。
《前一篇 -
在 sd card 上使用 fat 檔案系統》在 linux 下的測試只能把 elf 有關程式碼的部份印出, 而不能真的載入, 這是因為需要載入到 0x20010000, 而這個位址不見得在 os 環境下可以正確要到, 我曾試過 mmap, 不見得可以得到所要的位址。
讀取 elf program header 的程式碼不算太難, 但得先對 elf 有略懂的理解才行, 我不會說明這部份, 因為《
一步步写嵌入式操作系统:ARM编程的方法与实践》chapter 8 裡頭有介紹, 我不可能寫得比他還好了。這本書我已經提過很多次了, 如果你沒有, 應該想辦法搞到它。
elf program header 裡頭的資訊就是在描述這個 elf 的機械碼在 elf 檔案的什麼地方, 是很重要的資訊, 這就是 cpu 可以執行的部份。
|
fig 0 金字塔學習門檻 |
延續《前一篇 -
在 sd card 上使用 fat 檔案系統》的努力, 我「只要」把 elf 的內容複製到某個位址就可以了, spi_sdcard.c L970 - L1013 就是在做這樣的努力。
elf_pheader.p_vaddr 就是這個某個位址, 把 elf 內容複製 elf_pheader.p_vaddr 這個位址, 然後再透過 elf header 找出 elf entry point 就可以執行這個 elf 了。
那這個程式困難在哪裡? 一樣是在微小的記憶體, 這個 myur_168M.elf 有 68848, 128k + 64k ccm 總共只有 192k 的記憶體, 要怎麼載入這個 elf 執行檔而還要執行它呢?
我原本的想法是把 elf 載入到 ccm, 然後再從 ccm 位址 parse 這個 elf 並載入到 0x20010000 的位址, 但不管我怎麼縮, 這個 elf 就是無法在 64k 之內。這時候只好靠進階程式技術了, 以分段讀取的方式, 把所需要的 elf 部份載入到記憶體。這可不是容易的程式技巧, 我曾經栽在其下, 在好久好久之前, 我得完成一個用分段讀取的方式, 解開 firmware 檔案並且更新它, 而因為當時程度太差, 這個分段讀取功能花了好大的除錯時間才搞定。可恥阿!
《
一步步写嵌入式操作系统:ARM编程的方法与实践》chapter 8 的程式碼是將 elf 整個讀到記憶體, 再去 parse elf 並複製到載入位址上, 這樣的方式程式比較好寫。
而分段讀取的方式就不需要花費 64k ccm, 我把 ccm 的 64 k 拿來當 stack 了。這也是為什麼這個程式要先讀 elf header, 再來才是 program header, 然後運用 f_seek 讀出需要的部份。fatfs 幫了大忙, 讓我可以呼叫這些 api 完成這功能。否則要自己讀取 fat, 計算檔案在那個 cluster, 還要考慮小小的記憶體, 這不是簡單幾天就可以完成的, 有經驗的程式員馬上就可以聯想到其中的大工程。
所以很簡單的 copy elf program body 的部份就變成 spi_sdcard.c L917 - 1010 這麼複雜了。
那被載入的 elf 執行檔應該怎麼設計呢? 我把 128k 分成 2 個 64k, 從 sd card 載入的就從 0x20010000 往上的 64 k, 這很容易, 透過 linker script (參考 stm32.sd.ld) 就可以搞定。
0x20010000 + 64k 就是 sd card 上 elf 所能使用的位址空間, 程式一旦超過這個大小, 就會出亂子。
再來的問題是該怎麼執行這個 elf 程式呢? 有幾個方法:
- function call
- goto
- 弄成一個 process
柿子挑軟的吃, 我沒那麼大的野心, 弄成一個 process 太複雜了, 就用 function call 來搞定就好。最簡單的當然是 goto, 直接跳去那裡執行就好了, 也不用返回 loader 了。
被載入的 elf stack 要設計自己的 stack 嗎? 這太麻煩, 就先用 loader 的吧, 反正是以 function call 的方式執行, 並不會破壞原有的 stack 內容。
程式員如果有操作程式碼的能力, 這是一個強力的技術, 什麼是操作程式碼的能力? 就是我要讓程式怎麼跑, 程式就怎麼跑。coroutine, setjmp/longjmp, exception handle, stack unwind, debugger 就是有這樣能力的技術或是程式。
這個功能也需要這樣的能力, 要從目前的 loader 移動到被載入的 elf, 然後還要跳回來, 把那個 elf 當成一個 function, 跳過去去執行它就好了。
spi_sdcard.c L1014 那個恐怖的轉型就是在做這件事情, 取出 elf 的 entry point address, 轉成 function pointer, 然後執行他, 比想像中的還要簡單吧!
這比 c++ 的 exception handle 簡單 100 倍以上 (我絕對沒有誇張)。不相信可以看看《
c++ exception handling (1) - 原理篇》, 絕對沒唬爛。
list 1 是我第一次嘗試, 當然也是一次就成功, 這不是幸運, 是之前努力所結的美麗果實。我做了相當多的驗證, 證明能正常載入 elf 檔案。
list 2 是我第二次嘗試, 有什麼不同呢? 我加入了 bss, data section 的測試。確認 bss, data section 的值是正確的。也更進一步改善程式, 分段將 elf program body 載入到正確的位置。所以很不幸的沒有一次就成功, 我花了一些時間完成她。
todo:
目前還無法處理有 2 個以上的 program body。
myur_168M.c 已經不再需要初始化 usart2, 因為 loader 已經做過了, 直接呼叫 usart output function 即可。
myur_168M.c L101 - 106 是 bss section 測試, 應該是 0, 但我印出 76, 98, CD, AB, 這是因為我改了 bss init 的值, 我用了 0xabcd9876 來初始化 bss, 確認這部份是對的之後就改回 0 了。
有了這功能後, 就不需要寫入 stm32f4discovery 內建 flash, 可以像樹莓派一樣, 將程式寫在 sd card 上執行, 不過沒有樹莓派從開機到載入 sd card 執行檔的黑箱, 這個過程我已經很清楚明瞭。自己完成這些東西, 爽度暴增。
source code:
https://github.com/descent/stm32f4_prog/tree/master/load_from_sd
git commit: dc5daa7151badde8c76dc2af9ae5aa9ed1bb5cff
沒有留言:
張貼留言
使用 google 的 reCAPTCHA 驗證碼, 總算可以輕鬆留言了。
我實在受不了 spam 了, 又不想讓大家的眼睛花掉, 只好放棄匿名留言。這是沒辦法中的辦法了。留言的朋友需要有 google 帳號。