嵌入式Linux – 部署固件更新的机制?

前端之家收集整理的这篇文章主要介绍了嵌入式Linux – 部署固件更新的机制?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我正在考虑开发一个嵌入式 Linux项目(工业应用程序)的Yocto项目,我对那些有嵌入式Linux经验的人有一些问题–Yocto经历了一个奖励.只需要了解固件更新中常见的内容.

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

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

解决方法

在考虑安全通信渠道和回滚机制之前,我认为你应该在以下主题上投入一些时间,从长远来看这将更为重要:

>版本控制:随着时间的推移,您将最终获得嵌入式平台的不同版本,而不是所有版本都具有相同的功能.您的设备需要能够检查它收到的升级是否兼容并且可以应用.
>规划升级路径:您不知道系统在5年后的外观,但您希望今天的系统能够容纳您将要开发的固件.这种升级可能需要多个步骤,应记录下来.
>不要忘记降级:在某些时候你会引入无法降级的变化.你想怎么处理它们?

这里有一些技术细节的想法:

>身份验证和安全通信通道:只要您的设备具有验证其已收到的升级的机制,通信通道的确切属性就变得不那么重要了.该验证需要检查数据是否一致且兼容.
>回滚:可以使用两个等长分区来实现直接机制来保存整个OS.最好安排操作系统以只读方式工作,放置可以在单独分区上更改的数据.

引导加载程序需要一个引导标志来告诉它要引导哪个分区.它总是首先尝试从该分区启动,如果以某种方式失败,则会回退到另一个分区.该boot-flag可以存储在引导加载程序可以访问的任何位置.

升级设备,请将新系统(一旦经过验证)复制到当前不活动的分区,更改引导标志并重新启动.在系统的init脚本中,检查它是否从预期的分区启动.如果没有,出现问题,你可以采取适当的措施.

猜你在找的Linux相关文章