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