嵌入式Linux 的safe mode 設(shè)計(jì)與實(shí)現(xiàn)

　　在safe mode的實(shí)現(xiàn)中，需要保持原有master部分的穩(wěn)定，所以對master系統(tǒng)的building system不做大的改動，也就是保持safe mode的building system與master的building system共存。原則上來說，要避免對master系統(tǒng)帶來大的沖突。

　　Master building system主要涉及到的編譯過程為：

　　make

　　make rootfs

　　這個時(shí)候?qū)⒌玫絤aster.bin

　　safe mode building system和其類似，只是make rootfs部分有所區(qū)分：

　　make

　　make smrootfs

　　這個時(shí)候?qū)⒌玫絪afemode.bin

　　最后再將master與safe

　　mode部分做一個合并，得到一個整的rootfs

　　make dualrootfs

　　make dist

　　make

　　dualrootfs將調(diào)用一個外部的程序make_dual.c，所做的事情是要得到一個15872K的rootfs。這個rootfs包含的內(nèi)容為master.bin + safemode.bin。

　　本系統(tǒng)中一般master.bin的大小約為10000K，再加上safemode.bin的4M，總大小并未達(dá)到15872K，那么中間多出的部分，我們需要將其補(bǔ)0填充好。需要補(bǔ)充的0的大小約為15872-4*1024-10000=1776K

make_dual.c就是完成上面的合并，補(bǔ)0的工作。它read master.bin，write rootfs，然后write　1776K個零到rootfs中，接下來read safemode.bin，再繼續(xù)write 到rootfs中。

　　這樣就得到了完整的、帶master與safe mode的rootfs。

　　safe mode實(shí)現(xiàn)中遇到的問題及其解決

　　體積限制：

　　在safe mode的開發(fā)中，首先遇到的一個問題就是如何從已有的系統(tǒng)中簡化出一個safe mode的application環(huán)境。

　　對master原有系統(tǒng)的裁剪來得到safe mode，將會比較容易，如果從頭另寫一套，將會花費(fèi)較大精力，穩(wěn)定性也無法得到確實(shí)的保障，所以最終采用的是精簡master的系統(tǒng)來得到safe mode的大框架。

　　在實(shí)現(xiàn)safe mode時(shí)，要做的工作的原則是做到safe mode的rootfs盡量小，低于4M，并且保持與master外圍特性的一致，這樣可以避免重復(fù)開發(fā)，同時(shí)代碼的共用可以減少維護(hù)的不便，提高整個系統(tǒng)的靈活度、穩(wěn)定度。

　　就一個能運(yùn)行的嵌入系統(tǒng)來說，最基本的內(nèi)容應(yīng)該包括Linux kernel，busybox工具包、圖形驅(qū)動等內(nèi)容。

　　在本系統(tǒng)中，為了支持FTP下載，需要有network的支持，也即需要包括wired/wireless的支持。

　　為了支持USB下載方式，就需要USB monitor管理進(jìn)程的支持，這個主要是保持了與master系統(tǒng)的一致，而沒有另外去寫一個體積更小的USB管理模塊。

　　wireless模塊：

　　本來在設(shè)計(jì)時(shí)，可以考慮不加入wireless的支持，但為了更加方便用戶，保持用戶的使用習(xí)慣，我們還是加入了對wireless的支持，這樣也保持了與master系統(tǒng)的一致，但支持的代價(jià)是，safe mode的體積增大了大約250K。

　　在wireless module中，做了一個優(yōu)化，master系統(tǒng)中wireless module在insmod時(shí)，是使用的rootfs中的/lib/module/wireless/XXX.o，這些未壓縮的.o文件在rootfs系統(tǒng)中將占用較大空間，這樣一來，對應(yīng)的safe mode的內(nèi)容將會超出4M的大小。為了解決這個問題，我們將這些wireless module壓縮成wireless.tar.gz文件，放置到safemode.bin中，在Linux啟動時(shí)，在/etc/rc腳本中將 wireless.tar.gz解壓縮到ramfs中即/tmp/lib/module/wireless下，然后再從這里insmod安裝 wireless模塊。這樣所做的努力，wireless module從原來的790K，縮減到了250K，而功能保持了一致。

　　字體：

　　master 系統(tǒng)的字體使用的是freetype2，字體文件arialbd.ttf大約為280K，這也將占用大量的空間。由于safe mode在顯示界面方面沒有過高的要求，能讓用戶看到基本的圖形界面就已經(jīng)達(dá)到目的了，所以在safe mode中需要將freetype去掉。但由于master模式與safe mode都使用相同的圖形引擎，這樣就導(dǎo)致了，如果在safe mode中去掉freetype，那么就需要再次重新build基礎(chǔ)的圖形庫，這樣在master與safe mode的單獨(dú)編譯過程中就需要反復(fù)去make clean這些庫。這會給每次的編譯帶來很大的不便，每次make clean等操作會占用大量的時(shí)間，耗時(shí)耗力。

　　基于這個考慮，我們決定master與safe mode在編譯過程中都使用相同的圖形庫，即都編譯生成freetype庫。但在運(yùn)行時(shí)，safe mode不去使用freetype。也就是說，freetype庫會被編譯進(jìn)來，但字體文件不需要加到safe mode中，這樣做的代價(jià)就是編譯出來的safe mode的application比完全無freetype庫的情況要大100K左右，但卻保持了與master相同的庫結(jié)構(gòu)，而freetype字體就不再需要了，也就節(jié)約出了大約280K的空間。

　　最終優(yōu)化的結(jié)果，safe mode的4M，包括Linux kernel, buzybox, safe mode application等壓縮后的大?。?p>　　優(yōu)化結(jié)果　

后續(xù)版本的兼容：

　　在safe mode的設(shè)計(jì)中，對后續(xù)多個版本升級的支持也是一個需要仔細(xì)考慮的地方。因?yàn)楹罄m(xù)版本會存在很多的不確定性，如果發(fā)出的版本不能很好地兼容后續(xù)版本，那么將會給產(chǎn)品帶來巨大的風(fēng)險(xiǎn)。

　　后續(xù)版本的可能情況，主要分兩種：結(jié)構(gòu)分區(qū)變化不大，結(jié)構(gòu)分區(qū)變化巨大。

　　對后續(xù)版本中變化不大的情況，也即類似master + safe mode的情況，當(dāng)再次更新時(shí)，只需要操作/dev/mtdblock/3對應(yīng)master，/dev/mtdblock/4對應(yīng)safe mode，即可。

　　但如果后續(xù)版本變化非常大，那么就需要特別注意了。

　　可以考慮這樣一個情況：如果后續(xù)的版本，需求發(fā)生了大的變化，比如需要將原來master所在的分區(qū)再分成多個分區(qū)：

　　后續(xù)版本需求變化

那么從老版本升級到新版本時(shí)，這些分區(qū)的內(nèi)容如何保證燒寫后能正常工作呢?

　　解決的辦法就是在老版本中，將后續(xù)的rootfs部分作為一個整體來操作，也就是說燒寫時(shí)，是將master + part1 + part2+ safe mode作為一個整體來對待。在老版本看來，新版本中的這15872K的內(nèi)容，不管它其中有多少個不同的分區(qū)，還是master + safe mode。在燒寫時(shí)，還是按/dev/mtdblock/3對應(yīng)master，/dev/mtdblock/4對應(yīng)safe mode的方式來燒寫，完成將15872K的內(nèi)容完整燒寫進(jìn)flash即可。

　　為了做到這一點(diǎn)，在燒寫中，我們將全部的15872K的內(nèi)容分成兩段，第一段為15872-4*1024=11776K，需要將其write到/dev/mtdblock/3中，第二段為4M，需要將其write到/dev/mtdblock/4中。這樣全部的15872K的內(nèi)容就完整地?zé)龑懲辏俅螁雍蟮膋ernel會分辨出 master + part1 + part2 + safe mode，它們的總大小依然保持15872K不變。這整個過程中，都不用去理會新版本中到底包括哪些內(nèi)容，哪些分區(qū)，只要保證是將15872K的內(nèi)容全部完整地?zé)龑戇M(jìn)去就可以了。

　　整體rootfs的設(shè)計(jì)思想在這里幫了一個大忙，簡化了升級更新時(shí)所需要考慮的復(fù)雜度，使設(shè)計(jì)變得更加靈活與易于維護(hù)。

　　這樣才新發(fā)布的firmware里，如果分為多個分區(qū)，那么就保證再次升級時(shí)，將15872K的內(nèi)容分成多段，寫到類似/dev/mtdblock/3、4、5、6這樣的設(shè)備文件里就可以了，只要保證這些區(qū)域是連續(xù)的、并且燒寫的內(nèi)容是全部的那15872K內(nèi)容即可。

　　Magic number：

　　值得注意的是，隨著不同的版本的變化，magic number的位置還是應(yīng)該保持在15872K的最后一個字節(jié)的位置。但這就出現(xiàn)一個問題，在不同的版本中，這個magic number的位置會是在不同的partition的最后一個字節(jié)。比如某個版本可能是在/dev/mtdblock/4的最后，但再后續(xù)的版本它會變成了/dev/mtdblock/7的最后面，這樣就會存在很大的不確定性。所以在一個各個版本中，寫magic number標(biāo)記位時(shí)，需要一個統(tǒng)一的方法來做到這件事。最容易想到的辦法當(dāng)然就是magic number這個位置相對起始位置0是不變的。而前面提到過的/dev/mtdblock/0就剛好是代表了可以操作的整個flash分區(qū)。

　　有了/dev/mtdblock/0，這樣我們就可以open 它，seek到magic number的位置，然后write下0x55或0xAA，這樣就保持了寫magic number的代碼的一致性，不需要根據(jù)不同的分區(qū)，多次修改操作magic number的有關(guān)函數(shù)。

　　Booloader：

　　Bootloader的修改，也涉及到對magic number的讀取，它的讀取就相對簡單一些，直接使用magic number在RAM中映射的絕對地址即可。

　　Bootloader檢查完magic number后，需要將相對地址為0xBC0000的safe mode的kernel + rootfs讀入到RAM，然后設(shè)置啟動參數(shù)，調(diào)用內(nèi)核，進(jìn)入safe mode提示界面。

　　Linux kernel：

　　與老的、不帶safe mode的image相比，新的image里的Linux kernel從總體的角度來說，并沒有大的變化。在新做的master與safe mode的image中，它們各自需要包含一個Linux kernel，這兩個kernel唯一的不同就是啟動時(shí)所需要的rootfs在RAM中的映射位置不同。它們都有著相同的partition分區(qū)設(shè)置，編譯選項(xiàng)等。

　　Safe mode必須包含自己的Linux kernel，因?yàn)樗沁\(yùn)行在master損壞的情況下，master kernel已經(jīng)不能啟動了。

　　總結(jié)

　　上面的內(nèi)容是在實(shí)際開發(fā)中對safe mode的設(shè)計(jì)與實(shí)現(xiàn)的一個描述。從這個描述中，可以看到safe mode在嵌入式Linux產(chǎn)品扮演著重要的角色，對它的設(shè)計(jì)涉及到很多方面，要考慮系統(tǒng)的尺寸，與現(xiàn)有buidling環(huán)境的的兼容性，對后續(xù)版本的升級的兼容性等諸多方面。

　　從某種意義上來說，safe mode的設(shè)計(jì)關(guān)系到產(chǎn)品的成敗，一個好的safe mode的設(shè)計(jì)將會給產(chǎn)品帶來巨大的靈活性與可擴(kuò)展性，大大地方便了客戶與產(chǎn)品開發(fā)商。