嵌入式Linux的safe mode设计与实现02 firmware, master, flash, number, 嵌入式

samwalton

　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库会被编译进来，