嵌入式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。