有些事情出错了 ? 许多事情都可能出错，必须保证系统能够再次运行， 并且可能能够重新加载新的软件来修复损坏的映像。 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在开始更新系统时设置一个变量作为标志， 并在完成之后重置同一变量。引导加载程序可以读取此标志， 以检查在上次关机之前是否正在运行更新。 SoftwareUpdateU-Boot 升级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 作者：zqb-all 出处：http://www.cnblogs.com/zqb-all/ 本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利. 欢迎扫描左侧二维码关注微信公众号 QB杂货铺 https://www.cnblogs.com/zqb-all/p/10090280.html