嵌入式Linux的safe mode设计与实现
本系统中一般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的有关函数。
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的设计将会给产品带来巨大的灵活性与可扩展性，大大地方便了客户与产品开发商。
评论