root檔案系統的一點經驗(轉)

root檔案系統的一點經驗(轉)[@more@]　　這幾天折騰一個ARM9（s3c2410）的開發板,從bootloader到kernel，共花了一個多星期的時間，在root檔案系統上折騰得最鬱悶，不過總算是跑起來了，把自己的一點理解貼出來，希望有點用處，理解有誤的地方請大俠們指正。

　　基本情況是這樣：買了一個公司的開發板，但是軟體和技術支援非常差，沒辦法，就試著用turbolinux大俠強力推薦的mizi_SDK for s3c2410ttp://www.mizi.com/en/developer/s3c2410x ），果然是比較好用,bootloader（vivi）稍微改改就可以跑了。但是啟動linux的時候，vivi預設的是從NAND flash上啟動，在這個上面需要建立一個bon的檔案系統，用其中一個分割槽存放root檔案系統，而我的開發板用的是4M的NOR flash，不能直接用vivi在上面建立bon分割槽，所以啟動的時候無法mount root檔案系統。後來採用ramdisk 做root檔案系統，成功解決問題。下面是一些理解：

　　1。linux啟動時，經過一系列初始化之後，需要mount 根檔案系統，為最後執行init程式等做準備，mount 根檔案系統有這麼幾種方式：

　　1）檔案系統已經存在於硬碟（或者類似的裝置）的某個分割槽上了，kernel根據啟動的命令列引數（root＝/dev/xxx),直接進行mount。這裡有一個問題，在root檔案系統本身還不存在的情況下，kernel如何根據/dev/xxx來找到對應的裝置呢？原來kernel透過直接解析裝置的名稱來獲得裝置的主、從裝置號，然後就可以訪問對應的裝置驅動了。所以在init/main.c中有很長一串的root_dev_names，透過這個表就可以根據裝置名稱得到裝置號。

　　2）從軟碟機等比較慢的裝置上裝載根檔案系統，如果kernel支援ramdisk，在裝載root檔案系統時，核心判斷到需要從軟盤（fdx）mount，就會自動把檔案系統映象複製到ramdisk，一般對應裝置ram0，然後在ram0上mount 根檔案系統。 從原始碼看，如果kernel編譯時沒有支援ramdisk，而啟動引數又root=/dev/fd0, 系統將直接在軟盤上mount，除了速度比較慢，理論上是可行的（這個我沒試過，不知道是不是樣？）3）啟動時用到initrd來mount根檔案系統。一開始我被ramdisk和initrd這兩個東西弄胡塗了，其實ramdisk只是在ram上實現的塊裝置，initrd可以說是啟動過程中用到的一種機制。就是在裝載linux之前，bootloader可以把一個比較小的根檔案系統的映象裝載在記憶體的某個指定位置，姑且把這段記憶體稱為initrd，然後透過傳遞引數的方式告訴核心initrd的起始地址和大小（也可以把這些引數編譯在核心中），在啟動階段就可以暫時的用initrd來mount根檔案系統。initrd的最初的目的是為了把kernel的啟動分成兩個階段：在kernel中保留最少最基本的啟動程式碼，然後把對各種各樣硬體裝置的支援以模組的方式放在initrd中，這樣就在啟動過程中可以從initrd所mount的根檔案系統中裝載需要的模組。這樣的一個好處就是在保持kernel不變的情況下，透過修改initrd中的內容就可以靈活的支援不同的硬體。在啟動完成的最後階段，根檔案系統可以重新mount到其他裝置上，但是也可以不再重新mount（很多嵌入式系統就是這樣）。 initrd的具體實現過程是這樣的：bootloader把根檔案系統映象裝載到記憶體指定位置，把相關引數傳遞給核心，核心啟動時把initrd中的內容複製到ramdisk中（ram0），把initrd佔用的記憶體釋放掉，在ram0上mount根檔案系統。從這個過程可以看出，核心需要對同時對ramdisk和initrd的支援。

　　2。嵌入式系統根檔案系統的一種實現方法。對於kernel和根檔案系統都儲存在flash中的系統，一般可以利用linux啟動的initrd的機制。具體的過程前面已經比較清楚了，還有一點就是在啟動引數中傳遞
root=/dev/ram0，這樣使得用initrd進行mount的根檔案系統不再切換，因為這個時候實際的裝置就是ram0。還有就是initrd的起始地址引數為虛擬地址，需要和bootloader中用的實體地址對應。

　　3。我原來在mcf5307上跑的uClinux在編譯的時候就生成一個映象檔案，應該是把核心和檔案系統都打包到一起了，沒有仔細看根檔案系統裝載是否也是類似的方法，哪位大俠比較清楚給解釋解釋：）