嵌入式Linux - 部署固件更新的机制？

Question

我正在考虑开发针对嵌入式Linux项目（工业应用程序）的Yocto项目，对于那些具有嵌入式Linux经验的人，我有几个问题 - Yocto体验奖金。只需要了解固件更新中常用的内容。

我有一些要求，即身份验证，安全通信协议，如果更新失败，某种类型的回滚。此外，如果有一种方法可以逐步在整个设备上发布补丁，那么这也很有意思，因为我想避免使用现场的砖块设备。

如何在今天为现场设备部署更新/补丁 - 以及开发它需要多长时间？我还缺少其他考虑因素吗？

Answer 1

虽然您当然可以使用rpm，deb或ipk进行升级，但我的首选方式（至少对于小到合理大小的图像）是将两个图像存储在闪存上，并且只更新完整的rootfs图像。

今天如果我开始使用OpenEmbedded / Yocto Project开始使用嵌入式Linux，我可能会看看meta-swupdate。

我自己和多个客户使用的内容更像是：

• 容器升级文件，它是由另一个tarball（以下称为升级文件），升级文件的md5sum以及gpg签名组成的tarball。
• 存储在运行图像中的更新程序脚本。此脚本负责解压缩升级文件的外部容器，使用md5sum验证升级文件的正确性，并经常验证加密签名（通常基于gpg）。如果更新文件通过了这些测试，则updater脚本会在更新文件中查找升级脚本，并执行此操作。
• 更新文件中的升级脚本执行实际升级，即通常重写非运行映像，提取并重写内核，如果这些步骤成功，则指示引导加载程序使用新编写的内核和映像而不是目前运行的系统。

使用在升级文件中执行实际升级的脚本的好处是，您可以在一个步骤中执行将来需要的任何操作。我已经制作了特殊的升级映像，可以升级附加调制解调器的FW，或者提取一些额外的诊断信息，而不是执行实际的升级。这种灵活性将在未来得到回报。

为了使系统更加可靠，引导加载程序使用一个名为bootcount的功能，该功能可以启动尝试次数，如果此数字超过阈值，例如3，则引导加载程序选择引导另一个映像（如配置为启动的映像被认为是错误的）。这可确保图像完全损坏，另一个存储的图像将自动启动。

此方案的主要风险是您升级到图像，其升级机制已损坏。通常，我们还在引导加载程序中实现某种恢复机制，这样引导加载程序可以重新刷新一个全新的系统;虽然这种救援机制通常意味着数据分区（用于存储配置，数据库等）也将被删除。这部分是为了安全（不泄漏信息），部分是为了确保在此救援行动之后，我们将完全了解系统状态。 （当这是由远方缺乏经验的技术人员执行时，这是一个很大的好处）。

Answer 2

如果您有足够的闪存存储，则可以执行以下操作。制作两个相同的分区，一个用于实时系统，另一个用于更新。让系统通过安全方法提取更新的映像，并将其直接写入另一个分区。它可以像插入闪存驱动器一样简单，USB插槽位于锁定板后面（物理安全性），或者使用带有适当主机和用户密钥的ssh / scp。使用sfdisk交换分区，或者如果正确下载并正确写入图像，则仅编辑引导加载程序 的设置。如果没有，那么没有任何反应，旧固件继续存在，您可以稍后重试。如果需要逐步发布，请让客户端根据其MAC地址的最后一个字节选择一个映像。所有这些都可以在几个小时内通过一些简单的shellcript实现。或者实际测试它的几天：）

Answer 3

@Anders的答案是完整的，非常好的。我可以向你提出的唯一建议就是思考一些事情：

• 您的应用程序是否有互联网连接/ USB / SD卡存储 完成新的rootfs？使用嵌入式Linux并不像在Cortex M3上编写128K固件那样..
• 您的最终用户是否有能力进行更新工作？
• 您的应用程序是否安装在远程控制的可访问区域？

关于您需要开发完整/强大/稳定解决方案的时间并不是一个简单的问题，但请注意应用程序的关键点，它会影响您的应用程序的市场感觉。特别是在第一次部署的早期/月份，通常发送更新以修复小/大青年错误。