這里我們將以一個嵌入式Linux 網絡播放器為例，來說明 safe mode 安全模式的設計與實現(xiàn)。通過本文，我們可以了解到針對一個實際的嵌入式系統(tǒng)，設計中需要注意的技術要點和實現(xiàn)細節(jié)。
為什么需要 safe mode(安全模式)
當用戶購買一個產品后，在后續(xù)的服務中，可能還會發(fā)生一些費用，讓產品開發(fā)商增加成本，如免費電話咨詢，產品的維修、寄送。所以說將產品的賣出并不意味著最終的贏利。這樣的情況下，產品的設計就需要更加合理，更加優(yōu)化，來滿足用戶各種可能的需求。特別是在發(fā)生異常故障的時候，如果能引導客戶自行完成診斷、修復，那么將大大降低后續(xù)的服務成本。正因為如此，產品故障時，就很需要safe mode安全模式來幫助用戶完成恢復的工作。
從節(jié)約產品的成本、產品所能提供的功能上來看，safe mode 是大有裨益的。
大家所熟知的 windows 系統(tǒng)，也提供了 safe mode 安全模式，它就可以幫助用戶解決系統(tǒng)不穩(wěn)定，硬件沖突等諸多故障，讓用戶在自己可以操作的能力范圍內先行對系統(tǒng)進行診斷與修復。在很大程度上， windows 的 safe mode 給用戶與 Microsoft 都帶來了很大的便利。
嵌入式Linux產品與其他IT產品不同的地方，主要是使用flash來存貯運行時的系統(tǒng)。它沒有大的內存，沒有大的存儲空間，但它卻也是一個完整的系統(tǒng)。
在通常情況下，嵌入式Linux產品的flash上的內容是不會被破壞的，也即它們會有著較好的穩(wěn)定性，不會因為用戶的常規(guī)使用而導致flash上的 firmware被破壞。但隨著產品的更新升級，用戶也需要在自己家中完成對已購買商品的更新?lián)Q代。而用戶大多屬于非技術熟悉者，在更新升級中就可能出現(xiàn)種種意想不到的情況。
比如在用戶做firmware升級更新時，平時不會出現(xiàn)問題的firmware可能在這個過程中，就面臨著巨大的風險，極有可能致使用戶的系統(tǒng)無法啟動，不能正常工作。這樣的情況是我們不愿意看到的，而實際中卻的的確確可能會發(fā)生。
考慮這樣一個場景：當用戶對產品進行firmware升級時，如果在燒寫flash的過程中，意外掉電，那么用戶手中的產品就將無法再次啟動，因為 rootfs系統(tǒng)已經被破壞了。用戶所能做的，也只能將產品送回產商進行維修。這樣來回的過程不僅耗費用戶的精力，同樣也會增加產品開發(fā)商的成本。在產品升級換代很快的當前市場情況下，這樣的情況可能會經常發(fā)生。
如何避免這樣的情況的發(fā)生呢?如果我們可以提供一個機制，在進行升級前即往flash中寫入一個標記，正常完成后，再寫入另一個標記來表示整個過程的正常結束，否則的話，燒寫時掉電不會寫入第二個標記，只有第一個標記，那么就認為產品故障，這個時候，進入另一個新的提示界面，讓用戶自己選擇從 USB或FTP來重新升級firmware。這樣的話，整個過程用戶就完全可以在界面的友好提示下自己完成，方便了用戶與產品開發(fā)商。
系統(tǒng)架構
本文以一個實際的產品為例，來說明safe mode的設計。
系統(tǒng)架構
本系統(tǒng)為一個嵌入式Linux網絡播放器，主要的功能為播放家庭網絡中的多媒體文件，在家庭客廳等環(huán)境中有著大量的應用，它可以給用戶提供更方便快捷的媒體文件的播放方式，并能充分利用家庭音響系統(tǒng)的巨大功能，而非PC環(huán)境下有限的外部設備，大大改善了媒體文件的播放體驗。本系統(tǒng)的架構如下圖：
產品所使用的flash總大小為16M。
系統(tǒng)包括三大部分，即Bootloader，config, kernel + rootfs：
另外，/dev/mtdblock/0，在系統(tǒng)中對應整個flash block，即整個16M空間。
系統(tǒng)啟動時，bootloader將kernel和根文件映象從flash上讀取到RAM空間中，為內核設置啟動參數(shù)，調用內核，進入application，進行媒體文件的播放。
這個通常意義上的嵌入式Linux系統(tǒng)，它是不帶safe mode安全模式的。
這樣的系統(tǒng)，在做系統(tǒng)更新升級時，主要是對kernel+rootfs部分進行升級，以此來增加系統(tǒng)的功能。
升級時，application主要是操作/dev/mtdblock/3設備文件：
第一步：下載新的firmware到ramfs中，也即ram disk中，比如/tmp目錄下，采用的更新方式可以是USB或FTP;
第二步：read /tmp/firmware文件，并write到設備文件/dev/mtdblock/3上，即對已有的firmware進行了更新。
在升級的過程中，我們會提供友好的界面給用戶，來提示下載進度與燒寫flash的進度，讓用戶可以看到正在發(fā)生的狀況。
最后燒寫完成后，重新啟動系統(tǒng)，即可進入到新的firmware中。
在通常的更新中，用戶的產品配置config一般不去修改，保持用戶已經做的配置選項，不能破壞。Config內容對應為/dev/mtdblock/2設備文件。
從USB/FTP 上更新時，所使用的firmware文件需要是一個更加完整的image文件，可以包括bootloader, default config, kernel+rootfs，并讓application可以做到視image中的標記來決定是否需要更新bootloader、config等內容，這樣會更加靈活。
在更新firmware時，如果掉電，那么kernel + rootfs部分將會出現(xiàn)不完整的情況，也就是說只寫入了部分內容，而中途中斷了，這樣的話，一個不完整的系統(tǒng)將無法正常工作。在這樣的情況下就需要safe mode安全模式了。
safe mode架構設計
Safe mode的設計中，對原來的系統(tǒng)增加了兩個部分的內容：
kernel + rootfs，即簡單的UI界面與功能;
magic number，即燒寫flash的標記。
safe mode實際上也是一個kernel + rootfs部分，只是它所具有的功能只包括一些簡單的界面，主要是提供網絡設置，從USB/FTP下載firmware，完成對flash的燒寫。
為了區(qū)分，這里，將主功能部分的kernel + rootfs稱為master。
我們將safe mode存放在master的后部，預留的flash大小為4M。
Magic number只占用一個字節(jié)的大小，是在這4M的最后的部分的一個字節(jié)，也即原始系統(tǒng)的15872K的最后一個字節(jié)位置處。
在開始燒寫flash前，將magic number設置為0x55，表示燒寫的開始。燒寫正常結束后，將magic number設置為0xAA，表示燒寫正常結束。
如果新產品中具備了safe mode模式，那么在以后再次更新升級時，開始燒寫flash時，magic number的位置將會有0x55標記，如果燒寫中途掉電，在重新啟動后，將由Bootloader來檢查magic number的值，如果內容為0x55，那么bootloader將從safemode部分讀出kernel和根文件映象，再為內核設置啟動參數(shù)，調用內核，進入safe mode application。
如果bootloader讀到magic number為0xAA，那么說明master firmware是正常的，就將直接進入master。
所以涉及到safe mode的地方也包括了對bootloader的修改，需要在系統(tǒng)上電階段也檢查safe mode的magic number，這個過程是必不可少的，只有在啟動階段就檢查magic number，才能跳過損壞的master系統(tǒng)，進入安全模式，達到恢復系統(tǒng)的目的。safe mode架構實現(xiàn)
在safe mode的實現(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
這個時候將得到master.bin
safe mode building system和其類似，只是make rootfs部分有所區(qū)分：
make
make smrootfs
這個時候將得到safemode.bin
最后再將master與safe
mode部分做一個合并，得到一個整的rootfs
make dualrootfs
make dist
make
dualrootfs將調用一個外部的程序make_dual.c，所做的事情是要得到一個15872K的rootfs。這個rootfs包含的內容為master.bin + safemode.bin。
本系統(tǒng)中一般master.bin的大小約為10000K，再加上safemode.bin的4M，總大小并未達到15872K，那么中間多出的部分，我們需要將其補0填充好。需要補充的0的大小約為15872-4*1024-10000=1776K
make_dual.c就是完成上面的合并，補0的工作。它read master.bin，write rootfs，然后write 1776K個零到rootfs中，接下來read safemode.bin，再繼續(xù)write 到rootfs中。
這樣就得到了完整的、帶master與safe mode的rootfs。
safe mode實現(xiàn)中遇到的問題及其解決
體積限制：
在safe mode的開發(fā)中，首先遇到的一個問題就是如何從已有的系統(tǒng)中簡化出一個safe mode的application環(huán)境。
對master原有系統(tǒng)的裁剪來得到safe mode，將會比較容易，如果從頭另寫一套，將會花費較大精力，穩(wěn)定性也無法得到確實的保障，所以最終采用的是精簡master的系統(tǒng)來得到safe mode的大框架。
在實現(xiàn)safe mode時，要做的工作的原則是做到safe mode的rootfs盡量小，低于4M，并且保持與master外圍特性的一致，這樣可以避免重復開發(fā)，同時代碼的共用可以減少維護的不便，提高整個系統(tǒng)的靈活度、穩(wěn)定度。
就一個能運行的嵌入系統(tǒng)來說，最基本的內容應該包括Linux kernel，busybox工具包、圖形驅動等內容。
在本系統(tǒng)中，為了支持FTP下載，需要有network的支持，也即需要包括wired/wireless的支持。
為了支持USB下載方式，就需要USB monitor管理進程的支持，這個主要是保持了與master系統(tǒng)的一致，而沒有另外去寫一個體積更小的USB管理模塊。
wireless模塊：
本來在設計時，可以考慮不加入wireless的支持，但為了更加方便用戶，保持用戶的使用習慣，我們還是加入了對wireless的支持，這樣也保持了與master系統(tǒng)的一致，但支持的代價是，safe mode的體積增大了大約250K。
在wireless module中，做了一個優(yōu)化，master系統(tǒng)中wireless module在insmod時，是使用的rootfs中的/lib/module/wireless/XXX.o，這些未壓縮的.o文件在rootfs系統(tǒng)中將占用較大空間，這樣一來，對應的safe mode的內容將會超出4M的大小。為了解決這個問題，我們將這些wireless module壓縮成wireless.tar.gz文件，放置到safemode.bin中，在Linux啟動時，在/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在顯示界面方面沒有過高的要求，能讓用戶看到基本的圖形界面就已經達到目的了，所以在safe mode中需要將freetype去掉。但由于master模式與safe mode都使用相同的圖形引擎，這樣就導致了，如果在safe mode中去掉freetype，那么就需要再次重新build基礎的圖形庫，這樣在master與safe mode的單獨編譯過程中就需要反復去make clean這些庫。這會給每次的編譯帶來很大的不便，每次make clean等操作會占用大量的時間，耗時耗力。
基于這個考慮，我們決定master與safe mode在編譯過程中都使用相同的圖形庫，即都編譯生成freetype庫。但在運行時，safe mode不去使用freetype。也就是說，freetype庫會被編譯進來，但字體文件不需要加到safe mode中，這樣做的代價就是編譯出來的safe mode的application比完全無freetype庫的情況要大100K左右，但卻保持了與master相同的庫結構，而freetype字體就不再需要了，也就節(jié)約出了大約280K的空間。
最終優(yōu)化的結果，safe mode的4M，包括Linux kernel, buzybox, safe mode application等壓縮后的大?。?/p>
優(yōu)化結果
后續(xù)版本的兼容：
在safe mode的設計中，對后續(xù)多個版本升級的支持也是一個需要仔細考慮的地方。因為后續(xù)版本會存在很多的不確定性，如果發(fā)出的版本不能很好地兼容后續(xù)版本，那么將會給產品帶來巨大的風險。
后續(xù)版本的可能情況，主要分兩種：結構分區(qū)變化不大，結構分區(qū)變化巨大。
對后續(xù)版本中變化不大的情況，也即類似master + safe mode的情況，當再次更新時，只需要操作/dev/mtdblock/3對應master，/dev/mtdblock/4對應safe mode，即可。
但如果后續(xù)版本變化非常大，那么就需要特別注意了。
可以考慮這樣一個情況：如果后續(xù)的版本，需求發(fā)生了大的變化，比如需要將原來master所在的分區(qū)再分成多個分區(qū)：
后續(xù)版本需求變化
那么從老版本升級到新版本時，這些分區(qū)的內容如何保證燒寫后能正常工作呢?
解決的辦法就是在老版本中，將后續(xù)的rootfs部分作為一個整體來操作，也就是說燒寫時，是將master + part1 + part2+ safe mode作為一個整體來對待。在老版本看來，新版本中的這15872K的內容，不管它其中有多少個不同的分區(qū)，還是master + safe mode。在燒寫時，還是按/dev/mtdblock/3對應master，/dev/mtdblock/4對應safe mode的方式來燒寫，完成將15872K的內容完整燒寫進flash即可。
為了做到這一點，在燒寫中，我們將全部的15872K的內容分成兩段，第一段為15872-4*1024=11776K，需要將其write到/dev/mtdblock/3中，第二段為4M，需要將其write到/dev/mtdblock/4中。這樣全部的15872K的內容就完整地燒寫完，而再次啟動后的kernel會分辨出 master + part1 + part2 + safe mode，它們的總大小依然保持15872K不變。這整個過程中，都不用去理會新版本中到底包括哪些內容，哪些分區(qū)，只要保證是將15872K的內容全部完整地燒寫進去就可以了。
整體rootfs的設計思想在這里幫了一個大忙，簡化了升級更新時所需要考慮的復雜度，使設計變得更加靈活與易于維護。
這樣才新發(fā)布的firmware里，如果分為多個分區(qū)，那么就保證再次升級時，將15872K的內容分成多段，寫到類似/dev/mtdblock/3、4、5、6這樣的設備文件里就可以了，只要保證這些區(qū)域是連續(xù)的、并且燒寫的內容是全部的那15872K內容即可。
Magic number：
值得注意的是，隨著不同的版本的變化，magic number的位置還是應該保持在15872K的最后一個字節(jié)的位置。但這就出現(xiàn)一個問題，在不同的版本中，這個magic number的位置會是在不同的partition的最后一個字節(jié)。比如某個版本可能是在/dev/mtdblock/4的最后，但再后續(xù)的版本它會變成了/dev/mtdblock/7的最后面，這樣就會存在很大的不確定性。所以在一個各個版本中，寫magic number標記位時，需要一個統(tǒ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的有關函數(shù)。
Booloader：
Bootloader的修改，也涉及到對magic number的讀取，它的讀取就相對簡單一些，直接使用magic number在RAM中映射的絕對地址即可。
Bootloader檢查完magic number后，需要將相對地址為0xBC0000的safe mode的kernel + rootfs讀入到RAM，然后設置啟動參數(shù)，調用內核，進入safe mode提示界面。
Linux kernel：
與老的、不帶safe mode的image相比，新的image里的Linux kernel從總體的角度來說，并沒有大的變化。在新做的master與safe mode的image中，它們各自需要包含一個Linux kernel，這兩個kernel唯一的不同就是啟動時所需要的rootfs在RAM中的映射位置不同。它們都有著相同的partition分區(qū)設置，編譯選項等。
Safe mode必須包含自己的Linux kernel，因為它是運行在master損壞的情況下，master kernel已經不能啟動了。
總結
上面的內容是在實際開發(fā)中對safe mode的設計與實現(xiàn)的一個描述。從這個描述中，可以看到safe mode在嵌入式Linux產品扮演著重要的角色，對它的設計涉及到很多方面，要考慮系統(tǒng)的尺寸，與現(xiàn)有buidling環(huán)境的的兼容性，對后續(xù)版本的升級的兼容性等諸多方面。
從某種意義上來說，safe mode的設計關系到產品的成敗，一個好的safe mode的設計將會給產品帶來巨大的靈活性與可擴展性，大大地方便了客戶與產品開發(fā)商。