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等壓縮后的大?。?/p>

　　優化結果　

　　后續版本的兼容：

　　在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的設計將會給產品帶來巨大的靈活性與可擴展性，大大地方便了客戶與產品開發商。