新闻中心

EEPW首页 > 嵌入式系统 > 设计应用 > 嵌入式Linux的safe mode设计与实现

嵌入式Linux的safe mode设计与实现

作者:时间:2009-04-01来源:网络收藏

  目前的各种嵌入式产品已经丰富多彩,它们正改变着我们的生活方式。随着嵌入式产品功能的增加,如何让用户对已购买的产品的升级能安全地、顺利地完成,避免升级过程中出现的意外掉电所引起的产品故障,这样的问题要求嵌入产品设计开发者在设计时就将产品的 safe mode 考虑进去。这里我们将以一个 网络播放器为例,来说明 safe mode 的设计与实现。通过本文,我们可以了解到针对一个实际的嵌入式系统,设计中需要注意的技术要点和实现细节。

  为什么需要 safe mode()

  当用户购买一个产品后,在后续的服务中,可能还会发生一些费用,让产品开发商增加成本,如免费电话咨询,产品的维修、寄送。所以说将产品的卖出并不意味着最终的赢利。这样的情况下,产品的设计就需要更加合理,更加优化,来满足用户各种可能的需求。特别是在发生异常故障的时候,如果能引导客户自行完成诊断、修复,那么将大大降低后续的服务成本。正因为如此,产品故障时,就很需要safe mode安全模式来帮助用户完成恢复的工作。

  从节约产品的成本、产品所能提供的功能上来看,safe mode 是大有裨益的。

  大家所熟知的 windows 系统,也提供了 safe mode 安全模式,它就可以帮助用户解决系统不稳定,硬件冲突等诸多故障,让用户在自己可以操作的能力范围内先行对系统进行诊断与修复。在很大程度上, windows 的 safe mode 给用户与 Microsoft 都带来了很大的便利。

  产品与其他IT产品不同的地方,主要是使用flash来存贮运行时的系统。它没有大的内存,没有大的存储空间,但它却也是一个完整的系统。

  在通常情况下,产品的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。


上一页 1 2 下一页

评论


相关推荐

技术专区

关闭