嵌入式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 地址的最后一个字节选择映像。所有这些都可以在几个小时内通过几个简单的 shell 脚本来实现。或者实际测试几天:)