嵌入式Linux的safe mode設計與實現

　　目前的各種嵌入式產品已經豐富多彩，它們正改變著我們的生活方式。隨著嵌入式產品功能的增加，如何讓用戶對已購買的產品的升級能安全地、順利地完成，避免升級過程中出現的意外掉電所引起的產品故障，這樣的問題要求嵌入產品設計開發者在設計時就將產品的 safe mode 安全模式考慮進去。這里我們將以一個嵌入式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。