【swupdate文档 一】嵌入式系统的软件管理
嵌入式系统的软件管理
嵌入式系统变得越来越复杂, 它们的软件也反映了这种复杂性的增加。
为了支持新的特性和修复,很有必要让嵌入式系统上的软件
能够以绝对可靠的方式更新。
在基于linux的系统上,我们可以在大多数情况下找到以下元素:
- 引导装载程序
- 内核和设备树
- 根文件系统
- 其他在后续挂载的文件系统
- 用户资料,以裸数据格式存在或者保存在文件系统中
- 特定用途的软件. 如,用于下载到相连接的微控制器的固件等
一般来说,在大多数情况下是需要更新
内核和根文件系统,保存用户数据-但实际情况各不相同。
仅在少数情况下,还需要更新引导加载程序,
事实上,更新引导加载程序总是很危险的, 因为更新中的失败会破坏设备。
在某些情况下,从损坏状态中恢复是可能的,
但这通常无法由最终用户完成,即设备需要返厂维修。
关于软件更新有很多不同的概念。我将解释其中的一些概念,
然后解释为什么我实施了这个项目。
通过引导加载程序完成更新
引导加载程序所做的工作远不止启动内核那么简单。
它们有自己的shell,且可以使用处理器的外围设备
进行管理,在大多数情况下是通过串行通讯。 它们通常是可执行脚本的,这使得
实现某种软件更新机制成为了可能。
然而,我发现这种方法有一些缺点,
这让我另行寻找基于运行在Linux上的应用程序的解决方案。
引导加载程序对外围设备的使用有局限性
并不是所有内核中支持的设备都可以在引导加载程序使用。
向内核添加设备支持是有意义的,因为这可以让外围设备对主应用程序可用,
但将驱动程序移植到引导加载程序中,就并不总是有意义的了。
引导加载程序的驱动程序不会被更新
引导加载程序的驱动程序大多是从Linux内核移植过来的,
但是由于经过调整的原因,它们以后不会被修复或与内核同步,
而bug修复则会定期在Linux内核中进行。
一些外围设备可能以不可靠的方式工作,
并且修复问题可能并不容易。引导加载程序中的驱动程序
或多或少是内核中相应驱动程序的复刻(fork)。
例如,用于NAND设备的UBI/UBIFS在内核中包含
了许多修复程序,这些修复程序并没有移植回引导加载程序。
USB协议栈也可以找到相同的情况。支持新外围设备或协议的工作,
在内核中进行得更好,而不是在引导加载程序中。
简化版的文件系统
支持的文件系统的数量是有限的。
将文件系统支持移植到引导加载程序需要付出很大的努力。
网络支持有限
网络协议栈是有限的,通常通过一个更新只能通过 UDP但不能通过TCP完成。
与操作人员交互
很难将接口暴露给操作员, 比如浏览器中的GUI或显示器上的GUI。
比起在引导加载程序中,复杂的逻辑可以在应用程序内部更容易实现。
扩展引导加载程序是复杂的,因为所有的服务和库都不可用。
引导加载程序更新的优点
然而,这种方法也有一些优点:
-更新软件通常更简单。
-占用空间更小:即使是一个仅用于软件管理的独立应用程序
也需要自己的内核和根文件系统。即使它们的大小能够被裁剪,
将更新软件不需要的部分去掉,它们的大小也是不可忽略的。
通过包管理器更新
所有的Linux发行版都使用包管理器做更新, 为什么这不适用于嵌入式系统?
我不能说它不能被使用,但是使用这种方法有一个重要的缺点。
嵌入式系统是使用特定的软件进行过良好测试的。
使用包管理器可能会让人觉得奇怪,因为软件本身不再是 原子的 ,
而是分裂成一系列包。
我们怎样才能保证一个能基于库版本x.y正常工作的应用程序,
同样也能基于同一个库的不同版本工作呢?如何才能成功地做好测试?
对于制造商来说,通常更好的说法是发布了一个新的软件版本
(经过测试工程师的良好测试),并且可以更新新的软件(或固件)。
对测试人员来说,在包中进行拆分可能会产生噩梦和巨大的工作量。
简单地替换单个文件可以加快开发速度,
但是对于客户站点来说,这是一个软件版本的噩梦。
如果客户报告了一个bug,那么在之前已经向客户发送过
一些文件的补丁时,软件怎么可能还算是“2.5版本”呢?
原子更新通常是嵌入式系统的必备特性。
应用程序进行软件升级的策略
应用程序也可以用于升级系统,而不是使用引导加载程序。
应用程序可以使用操作系统提供的所有服务。
建议的解决方案是一个独立的软件,
它遵循客户规则,执行检查以确定软件是否可安装,
然后将软件安装到所需的存储上。
应用程序可以检测所提供的新软件是否适合硬件,
也可以检查软件是否由经过验证的权威机构发布。
支持的特性范围可以从小型系统扩展到复杂系统,
包括安装前和安装后脚本等等。
根据系统的资源,可以使用不同的策略。 下面我将列出其中一些。
双备份系统 - 支持回退
如果存储空间足够保存整个软件的两个副本,
那么即使软件更新被中断或断电,也可以保证始终有一个可用的副本。
每个副本必须包含内核、根文件系统和每个可以更新的组件。
需要一种机制来识别正在运行的版本。
SWUpdate应该集成到应用程序软件中, 当需要更新时,应用程序软件将触发它。
SWUpdate的职责是更新备用副本, 不修改正在运行的软件副本。
与引导加载程序的协作通常是必要的,
因为引导加载程序必须决定应该启动哪个副本。
同样,必须能够在两个副本之间进行切换。
重新启动后,引导加载程序决定应该运行哪个副本。
请参阅有关引导加载程序的章节,
了解可以实现哪些机制来确保更新后目标不会被破坏。
最明显的缺点是所需的空间量。 每个副本的可用空间小于存储空间的一半。
然而,即使在断电的情况下,更新也总是安全的。
这个项目支持这个策略。
作为该项目一部分的应用程序应该安装在根文件系统中,
并根据需要启动或触发。不需要额外的内核,
因为这两个副本保证总是可以升级不运行的副本。
SWUpdate将设置bootloader变量以通知新映像已成功安装。
单系统 - 以独立镜像形式运行
软件升级应用程序由内核(可裁剪掉不必要的驱动等)
和一个小的根文件系统以及应用程序及其库组成。
整个大小远远小于系统软件的一个副本。
根据设置,这个独立根文件系统的大小从 2.5MB 到 8MB 不等。
如果说大小对于小型系统非常重要,
那么对于具有大量存储或大容量NAND的系统, 其大小则可以忽略不计。
系统可以进入 "升级" 模式,只需向引导加载程序发出必须启动升级软件的信号。
具体方法可能有所不同,例如设置引导加载程序环境或使用和外部GPIO。
引导加载程序启动“SWUpdate”,
引导SWUpdate内核并将initrd映像作为根文件系统。
因为它在RAM中运行,所以可以升级整个存储。
与双拷贝策略不同,系统必须重新启动以将其自身置于更新模式。
这个方案比起使用两个副本,占用的存储空间更少,
但是它不能保证在不再次更新软件的情况下进行回退。
不过,至少它可以保证,当主应用不存在或损坏时,
以及当升级过程由于某种原因而中断时,系统自动进入升级模式。
事实上,可以将升级过程视为事务,
只有成功升级后,新软件才设置为“可引导”。
考虑到这些因素,使用此策略进行升级是安全的: 如果旧软件损坏或无法运行,
始终确保系统启动并准备好获得新软件。
使用U-Boot作为引导加载程序, SWUpdate能够管理U-Boot的环境设置变量,
以指示事务的开始和结束,以及包含有效的软件的存储区域。
针对GRUB环境块修改和EFI引导保护的类似特性也已被引入。
SWUpdate主要以如下配置的方式使用。
Yocto生成包含SWUpdate应用程序的initrd映像,
该映像在挂载根文件系统之后自动启动。
有些事情出错了 ?
许多事情都可能出错,必须保证系统能够再次运行,
并且可能能够重新加载新的软件来修复损坏的映像。
SWUpdate与引导加载程序一起工作,以识别失败的可能原因。
目前支持U-Boot、GRUB和EFI引导保护。
我们至少可以列出一些常见的原因:
- -安装过程中镜像损坏。
- SWUpdate能够识别它,并且更新过程会被中止。
旧的软件被保存下来,没有任何东西被真正复制到目标的存储中
- 存储(flash)中损坏的镜像
- 远程更新由于通信问题而中断
- 意外掉电
SWUpdate的工作流程是事务性的。引导加载程序的环境变量“recovery_status”
被设置为向引导加载程序发出更新状态的信号。
当然,还可以添加更多变量,用于微调和报告错误原因。
recovery_status可以取值为“progress”,“failed”,或者它也可以被取消设置。
当SWUpdate启动时,它将recovery_status设置为“progress”。
更新成功完成后,变量将被删除。如果更新以错误结束,
recovery_status的值为“failed”。
当更新被中断时,不管什么原因,引导加载程序都能识别到,
因为recovery_status变量处于“progress”或“failed”状态。
然后,引导加载程序可以再次启动SWUpdate,以再次
加载软件(单副本情况)或运行应用程序的旧副本(双副本情况)。
意外掉电
如果发生断电,必须保证系统能够再次工作 —— 重新
启动SWUpdate或恢复软件的旧副本。
一般情况下,行为可以根据所选择的场景进行划分:
-
单拷贝:SWUpdate被中断,更新事务没有以成功结束。
引导加载程序能够再次启动SWUpdate,从而有可能再次更新软件。 -
双拷贝:SWUpdate没有在备份系统和当前系统之间做切换。
当前版本的软件,并没有被更新触及到,会再次启动。
为了完全安全,SWUpdate和引导加载程序需要交换一些信息。
引导加载程序必须检测更新是否由于断电而中断,
并重新启动SWUpdate,直到更新成功。
SWUpdate支持U-Boot、GRUB和EFI Boot Guard引导加载程序。 U-Boot和EFI Boot
Guard有用于保证掉电安全的环境变量,
SWUpdate能够读取和更改这些变量,以此与引导加载程序通信。
对于GRUB,则使用固定的1024字节环境变量块文件。
SWUpdate在开始更新系统时设置一个变量作为标志,
并在完成之后重置同一变量。引导加载程序可以读取此标志,
以检查在上次关机之前是否正在运行更新。
升级SWUpdate本身会如何?
SWUpdate被认为用于整个开发过程,代替定制过程以在开发过程中更新软件。
在投产前,SWUpdate被针对这个项目进行过很好的测试。
如果SWUpdate本身应该被更新,那么当存储中只有一个SWUpdate副本时,
更新就不是安全的。只有当SWUpdate拥有两个副本时,才能保证安全更新。
如果SWUpdate是升级映像的一部分,则有一些方法可以避免这个问题:
- 有两份SWUpdate
- 承担风险,但准备一个在引导加载程序中可使用的救援程序。
升级引导加载程序会如何?
更新引导加载程序在大多数情况下无法做到的。
在大多数SOC上,不存在多个引导加载程序的副本,
当引导加载程序被破坏时,板子就无法引导启动了。
一些soc允许拥有多个引导加载程序副本。
但同样,没有通用的解决方案,因为它是 非常 特定于硬件的。
根据我的经验,大多数产品不允许更新引导加载程序。
当产品准备好量产时,还必须要更新引导加载程序,这种情况是非常少见的。
以上结论不适用于更新U-Boot环境变量,这是一种常见的情况。
U-Boot提供整个环境变量的两个副本,从SWUpdate中更新环境是
掉电安全的。其他引导加载程序则不一定具有此功能。
注:
本文地址 https://www.cnblogs.com/zqb-all/p/10090280.html
译自 swupdate 文档 https://sbabic.github.io/swupdate/overview.html
有更新会在github上发布 https://zqb-all.github.io/swupdate/overview.html