基于嵌入式Linux的safe mode设计与实现
扫描二维码
随时随地手机看文章
目前的各种嵌入式产品已经丰富多彩,它们正改变着我们的生活方式。随着嵌入式产品功能的增加,如何让用户对已购买的产品的升级能安全地、顺利地完成,避免升级过程中出现的意外掉电所引起的产品故障,这样的问题要求嵌入产品设计开发者在设计时就将产品的 mode 安全模式考虑进去。这里我们将以一个嵌入式 网络播放器为例,来说明 mode 安全模式的设计与实现。通过本文,我们可以了解到针对一个实际的嵌入式系统,设计中需要注意的技术要点和实现细节。
为什么需要 mode(安全模式)
当用户购买一个产品后,在后续的服务中,可能还会发生一些费用,让产品开发商增加成本,如免费电话咨询,产品的维修、寄送。所以说将产品的卖出并不意味着最终的赢利。这样的情况下,产品的设计就需要更加合理,更加优化,来满足用户各种可能的需求。特别是在发生异常故障的时候,如果能引导客户自行完成诊断、修复,那么将大大降低后续的服务成本。正因为如此,产品故障时,就很需要safe mode安全模式来帮助用户完成恢复的工作。
从节约产品的成本、产品所能提供的功能上来看,safe mode 是大有裨益的。
大家所熟知的 windows 系统,也提供了 safe mode 安全模式,它就可以帮助用户解决系统不稳定,硬件冲突等诸多故障,让用户在自己可以操作的能力范围内先行对系统进行诊断与修复。在很大程度上, windows 的 safe mode 给用户与 Microsoft 都带来了很大的便利。
嵌入式产品与IT产品不同的地方,主要是使用来存贮运行时的系统。它没有大的内存,没有大的存储空间,但它却也是一个完整的系统。
在通常情况下,嵌入式产品的上的内容是不会被破坏的,也即它们会有着较好的稳定性,不会因为用户的常规使用而导致上的 firmware被破坏。但随着产品的更新升级,用户也需要在自己家中完成对已购买商品的更新换代。而用户大多属于非技术熟悉者,在更新升级中就可能出现种种意想不到的情况。
比如在用户做firmware升级更新时,平时不会出现问题的firmware可能在这个过程中,就面临着巨大的风险,极有可能致使用户的系统无法启动,不能正常工作。这样的情况是我们不愿意看到的,而实际中却的的确确可能会发生。
考虑这样一个场景:当用户对产品进行firmware升级时,如果在烧写flash的过程中,意外掉电,那么用户手中的产品就将无法再次启动,因为 rootfs系统已经被破坏了。用户所能做的,也只能将产品送回产商进行维修。这样来回的过程不仅耗费用户的精力,同样也会增加产品开发商的成本。在产品升级换代很快的当前市场情况下,这样的情况可能会经常发生。
如何避免这样的情况的发生呢?如果我们可以提供一个机制,在进行升级前即往flash中写入一个标记,正常完成后,再写入另一个标记来表示整个过程的正常结束,否则的话,烧写时掉电不会写入第二个标记,只有第一个标记,那么就认为产品故障,这个时候,进入另一个新的提示界面,让用户自己选择从 USB或FTP来重新升级firmware。这样的话,整个过程用户就完全可以在界面的友好提示下自己完成,方便了用户与产品开发商。
系统架构
本文以一个实际的产品为例,来说明safe mode的设计。
系统架构
本系统为一个嵌入式Linux网络播放器,主要的功能为播放家庭网络中的多媒体文件,在家庭客厅等环境中有着大量的应用,它可以给用户提供更方便快捷的媒体文件的播放方式,并能充分利用家庭音响系统的巨大功能,而非PC环境下有限的外部设备,大大改善了媒体文件的播放体验。
本系统的架构如下图:
产品所使用的flash总大小为16M。
系统包括三大部分,即Bootloader,, kernel + rootfs:
另外,/dev/mtd/0,在系统中对应整个flash ,即整个16M空间。
系统启动时,bootloader将kernel和根文件映象从flash上读取到RAM空间中,为内核设置启动参数,调用内核,进入application,进行媒体文件的播放。
这个通常意义上的嵌入式Linux系统,它是不带safe mode安全模式的。
这样的系统,在做系统更新升级时,主要是对kernel+rootfs部分进行升级,以此来增加系统的功能。
升级时,application主要是操作/dev/mtd/3设备文件:
第一步:下载新的firmware到ramfs中,也即ram 中,比如/tmp目录下,采用的更新方式可以是USB或FTP;
第二步: /tmp/firmware文件,并write到设备文件/dev/mtdblock/3上,即对已有的firmware进行了更新。
在升级的过程中,我们会提供友好的界面给用户,来提示下载进度与烧写flash的进度,让用户可以看到正在发生的状况。
最后烧写完成后,重新启动系统,即可进入到新的firmware中。
在通常的更新中,用户的产品配置一般不去修改,保持用户已经做的配置选项,不能破坏。内容对应为/dev/mtdblock/2设备文件。
从USB/FTP 上更新时,所使用的firmware文件需要是一个更加完整的文件,可以包括bootloader, default , kernel+rootfs,并让application可以做到视中的标记来决定是否需要更新bootloader、config等内容,这样会更加灵活。
在更新firmware时,如果掉电,那么kernel + rootfs部分将会出现不完整的情况,也就是说只写入了部分内容,而中途中断了,这样的话,一个不完整的系统将无法正常工作。在这样的情况下就需要safe mode安全模式了。
safe mode架构设计
mode的设计中,对原来的系统增加了两个部分的内容:
kernel + rootfs,即简单的UI界面与功能;
,即烧写flash的标记。
safe mode实际上也是一个kernel + rootfs部分,只是它所具有的功能只包括一些简单的界面,主要是提供网络设置,从USB/FTP下载firmware,完成对flash的烧写。
为了区分,这里,将主功能部分的kernel + rootfs称为。
我们将safe mode存放在的后部,预留的flash大小为4M。
只占用一个字节的大小,是在这4M的最后的部分的一个字节,也即原始系统的15872K的最后一个字节位置处。
在开始烧写flash前,将 设置为0x55,表示烧写的开始。烧写正常结束后,将 number设置为0xAA,表示烧写正常结束。
如果新产品中具备了safe mode模式,那么在以后再次更新升级时,开始烧写flash时,magic number的位置将会有0x55标记,如果烧写中途掉电,在重新启动后,将由Bootloader来检查magic number的值,如果内容为0x55,那么bootloader将从safemode部分读出kernel和根文件映象,再为内核设置启动参数,调用内核,进入safe mode application。
如果bootloader读到magic number为0xAA,那么说明 firmware是正常的,就将直接进入master。
所以涉及到safe mode的地方也包括了对bootloader的修改,需要在系统上电阶段也检查safe mode的magic number,这个过程是必不可少的,只有在启动阶段就检查magic number,才能跳过损坏的master系统,进入安全模式,达到恢复系统的目的。
safe mode架构实现
在safe mode的实现中,需要保持原有master部分的稳定,所以对master系统的building 不做大的改动,也就是保持safe mode的building 与master的building 共存。原则上来说,要避免对master系统带来大的冲突。
building system主要涉及到的编译过程为:
rootfs
这个时候将得到master.bin
safe mode building system和其类似,只是 rootfs部分有所区分:
make
make smrootfs
这个时候将得到safemode.bin
最后再将master与safe
mode部分做一个合并,得到一个整的rootfs
make rootfs
make dist
make
rootfs将调用一个外部的程序make_.c,所做的事情是要得到一个15872K的rootfs。这个rootfs包含的内容为master.bin + safemode.bin。
本系统中一般master.bin的大小约为,再加上safemode.bin的4M,总大小并未达到15872K,那么中间多出的部分,我们需要将其补0填充好。需要补充的0的大小约为15872-4*1024-10000=1776K
make_dual.c就是完成上面的合并,补0的工作。它 master.bin,write rootfs,然后write 1776K个零到rootfs中,接下来 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内容即可。
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里的Linux kernel从总体的角度来说,并没有大的变化。在新做的master与safe mode的image中,它们各自需要包含一个Linux kernel,这两个kernel唯一的不同就是启动时所需要的rootfs在RAM中的映射位置不同。它们都有着相同的partition分区设置,编译选项等。
mode必须包含自己的Linux kernel,因为它是运行在master损坏的情况下,master kernel已经不能启动了。
总结
上面的内容是在实际开发中对safe mode的设计与实现的一个描述。从这个描述中,可以看到safe mode在嵌入式Linux产品扮演着重要的角色,对它的设计涉及到很多方面,要考虑系统的尺寸,与现有buidling环境的的兼容性,对后续版本的升级的兼容性等诸多方面。