我正在考虑在 Yocto 项目上开发一个嵌入式 Linux 项目（一个工业应用程序），我有几个问题想问那些有嵌入式 Linux 经验的人——Yocto 经验是额外的好处。只需了解固件更新中常见的操作即可。
我有一些要求，包括身份验证、安全通信协议、更新失败时某种类型的回滚。另外，如果有一种方法可以在设备群中逐步发布补丁，那么这也会很有趣，因为我想避免现场设备变砖。
如今，您如何将更新/补丁部署到现场设备 - 开发它需要多长时间？我还缺少其他考虑因素吗？
虽然您当然可以使用 rpm、deb 或 ipk 进行升级，但我的首选方法（至少对于小到合理大小的映像）是将两个映像存储在闪存上，并且仅更新完整的 rootfs 映像。
今天，如果我要开始使用 OpenEmbedded / Yocto 项目来使用嵌入式 Linux，我可能会考虑 meta-swupdate。
我自己和多个客户使用的更像是这样的：
- 容器升级文件，它是一个 tarball，由另一个 tarball（以下称为升级文件）、升级文件的 md5sum 以及通常的 gpg 签名组成。
- 存储在运行映像中的更新程序脚本。该脚本负责解压升级文件的外部容器，使用 md5sum 验证升级文件的正确性，并经常验证加密签名（通常基于 gpg）。如果更新文件通过了这些测试，更新程序脚本会在更新文件中查找升级脚本，并执行该脚本。
- 更新文件中的升级脚本执行实际升级，即通常重写非运行映像，提取并重写内核，如果这些步骤成功，则指示引导加载程序使用新编写的内核和映像而不是当前运行的系统。
在升级文件中包含执行实际升级的脚本的好处是，您可以通过一个步骤执行将来需要的任何操作。我制作了特殊的升级映像，用于升级连接的调制解调器的固件，或者提取一些额外的诊断信息，而不是执行实际的升级。这种灵活性将在未来得到回报。
为了使系统更加可靠，引导加载程序使用称为引导尝试次数的功能，该功能可以记录引导尝试的次数，如果该数字超过阈值，例如 3，引导加载程序将选择引导另一个映像（因为该映像配置为被引导被认为是有故障的）。这可确保该映像完全损坏，另一个存储的映像将自动启动。
此方案的主要风险是升级到升级机制已损坏的映像。通常，我们也会在bootloader中实现某种恢复机制，使得bootloader可以重新刷新一个全新的系统；尽管这种救援机制通常意味着数据分区（用于存储配置、数据库等）也将被删除。这部分是为了安全（不是泄漏信息），部分是为了确保在这次救援操作之后我们完全了解系统状态。 （当由远方缺乏经验的技术人员执行此操作时，这是一个很大的好处）。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
