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

概述我正在考虑开发一个嵌入式 Linux项目(工业应用程序)的Yocto项目,我对那些有嵌入式Linux经验的人有一些问题–Yocto经历了一个奖励.只需要了解固件更新中常见的内容. 我有一些要求,即身份验证,安全通信协议,如果更新失败,某种类型的回滚.此外,如果有一种方法可以逐步在整个设备中释放补丁,那么这也很有意思,因为我想避免在现场使用砖块设备. 如何在今天为现场设备部署更新/补丁 – 以及开发 我正在考虑开发一个嵌入式 Linux项目(工业应用程序)的Yocto项目,我对那些有嵌入式linux经验的人有一些问题–Yocto经历了一个奖励.只需要了解固件更新中常见的内容.

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

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

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

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

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

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

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

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

总结

以上是内存溢出为你收集整理的嵌入式Linux – 部署固件更新的机制？全部内容，希望文章能够帮你解决嵌入式Linux – 部署固件更新的机制？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。