良许Linux教程网 干货合集 如何实现BootLoader自更新呢?

如何实现BootLoader自更新呢?

汽车软件Boot程序的主要功能是刷新App程序。在某个特定的客户项目中,Boot也是客户需求的一部分,并且与项目一起有软件开发计划(有时为了与其他Boot进行区分,将项目上的Boot称为CB,即Customer Boot)。对于已下线的控制器,不论是在供应商还是客户手上进行测试,只能通过CB来刷新App程序。如果需要CB自动刷新,就需要额外的方法。

规范:

整车厂只对App程序刷新进行规范,没有关于Boot自动刷新的规范。因为规范是针对量产车的,售后只负责App程序的升级,不允许进行Boot升级。因此,Boot的自动刷新只存在于项目开发阶段,并由供应商提供方案。本文将分析五种Boot自动更新方式的优缺点。

方式一,SB更新CB:
如图1-a所示,某些软件架构采用两级Boot:SB+CB,Start Boot只检查CPU的最小系统,与具体项目的外围电路无关,它独立于客户需求,并由供应商自行维护,在Pilot项目的早期就应该完成开发。由于程序的启动顺序是SB->CB->App,因此在SB中增加刷新逻辑可以更新CB。通常情况下,运行CB来更新App程序,在特殊情况下,程序启动后会一直停留在SB中,以更新CB。

优点:

  1. 逻辑结构简单清晰,软件分工明确。
  2. 只需一次刷新,操作简单。

缺点:

  1. 需要较大的Flash空间在SB中存放刷新逻辑,在项目SOP之后又要禁止此刷新方式,造成额外的浪费。
  2. 软件分为三个级别的启动,结构复杂,开发和维护成本较高。对于不需要SB的控制器来说,这是一种负担。
  3. 假如需要更新SB怎么办?按照这种策略,还得做一个SSB?显然是不现实的。
image-20240120200945089
image-20240120200945089

方式二、RAM+Flash Reboot更新

如图2-a,不存在SB情况下,程序启动顺序是CB->App。需要刷新Boot时,首先把Reboot程序下载到不用的RAM里(图2-b),然后在RAM环境下运行ReBoot,下载新的CB(图2-c)

优点:

\1. 不需要额外的Flash空间,Boot程序运行只需要少量的RAM,因此为App设计的RAM临时可以保存Reboot程序。

\2. RAM擦写速度很快,则下载ReBoot的速度会很快。

缺点:

在CB更新过程中万一CPU掉电,重新上电后Reboot内容全无,CB已经破损,程序不能正常启动,控制器瘫痪,只能开盖用JTAG烧写程序。

image-20240120200942918
image-20240120200942918

方式三、RAM+RAM ReBoot更新(对方式二的改进)

首先把ReBoot(蓝色)+NewCB(紫色)一起都下载到RAM里(图3-a),然后运行ReBoot,擦除CB Flash区域,将RAM中NewCB复制到CB Flash区域(这一步内部完成)。最后,重新上电复位,RAM中的ReBoot和NewCB自动丢失,程序从新的CB开始运行。

优点:

1.相比方式二少了一步刷新(因为ReBoot和CB是绑在一起的)。

2.相比方式二CB更新全部在CPU内部执行,不受外界干扰,耗时更短。

缺点:

\1. 相比方式二需要更大的RAM空间存储ReBoot+NewCB。

\2. 和方式二一样存在CB更新阶段掉电后控制器瘫痪的风险 。

image-20240120200939591
image-20240120200939591

方式四、借助App程序Flash空间

刷新分三步:1.图4-b运行CB,擦除App,把ReBoot下载到App区域。2.图4-c运行ReBoot,擦除旧CB,刷入新CB。3.图4-d运行新CB,刷回App。

优点:

1.不需要额外的Flash和RAM资源。

2.稳定可靠,通过优化设计,可以保证在任何一个步骤突然掉电,上电后可以继续操作,控制器不会刷死。(详细设计方法请看附录)

3.对CB做稍微改造就可以成为Reboot程序,开发快速。

缺点:

1.步骤繁多,为了更新CB必须要先擦除App,最后恢复App,至少三次刷新。对不熟悉步骤的操作者容易搞混乱。

2.整体刷新时间会较长,两次Boot+一次App

image-20240120200936504
image-20240120200936504

方式五、借助额外Flash空间

相比方式四,需要一块和CB一样大小的额外Flash空间,刷新分三步:

  1. 图5-b,运行CB,刷入ReBoot到额外Flash。
  2. 图5-c,运行ReBoot,更新CB。
  3. 运行新的CB,破坏ReBoot(全部擦除,或只擦除ReBoot有效性标志)

优点:相比方式四,不需要破坏App程序,也省去了这部分更新时间。

缺点:相比方式四,需要额外的Flash空间,且必须是独立的Block。

image-20240120200933621
image-20240120200933621

小结:

本质上只有三种:

  1. 依赖启动程序SB(方式一),当CPU的Flash资源很富余且项目需要两级Boot时,用该方法最节省时间。
  2. 借助RAM(方式二、三)3.借助Flash(方式四、五)。只需要单级Boot(CB)时,可以容忍因Boot刷新瘫痪必须要给控制器开盖带来时间,人力,物力的成本损耗的情况下用方式二,三较方便。
  3. 只需要单级Boot(CB)时,不允许或不方便控制器开盖,但可以容忍Boot更新步骤繁多时间较长的情况下用方式四、五最可靠。

综上,工程师需要根据整体软件架构,CPU资源,时间人力物料等成本因素综合考虑一种适合自己产品及项目的Boot自刷新方法。

附录:

《Boot自刷新方式四(借助Flash)的具体实现方法》

背景:

对于方式四借助Flash刷新【不存在刷死风险,在任何一个步骤中控制器突然掉电,上电后可以继续操作。】的结论,是有条件的。笔者给出这个结论是从最理想的前提思考的,即只要控制器中至少有一个Boot存在(即使一个是坏的),程序就可以从任何一正常的Boot启动运行。这里就有一个问题,CPU怎么判断哪个Boot是好的,哪个是坏的?现在分析一下存在控制器刷死这种风险的情况和几种对策方案。

两级启动地址介绍:

如下图示,CPU上电后程序按地址顺序,检查BootSector的有效性,如果BOOT_ID合法则从指定的地址开始执行,否则检查下一个BootSector。

image-20240120200930225
image-20240120200930225

考虑CPU至少具备两个启动地址的情况,如图1-a,当且仅当启动地址1有效时(App为空),程序启动后自动进入Boot。如图1-b,当且仅当启动地址2有效时(不带Boot测试),程序启动后自动进入App。如图1-c,当启动地址1,2都有效势,程序优先从地址1启动,在Boot里检查App程序有效时,再靠跳转指令Jump到启动地址2,开始运行App。

image-20240120200927596
image-20240120200927596
image-20240120200924780
image-20240120200924780

方式四控制器刷死情况分析:

如图 2-a,运行Reboot更新CB途中断电。重新上电后,如图2-b,由于启动地址1的内容是在刷新开始就被更新了是有效的,程序会进入CB运行,但是CB不完整,必然运行出错,程序不会跳入ReBoot里,从而不能再刷新(即刷死)。假设从擦除完旧CB开始到刷入新CB完成的时间有10S,在此期间掉电的可能性也不能忽略。

image-20240120200921752
image-20240120200921752

对策一、Boot有效性标志与启动地址重合

考虑最普遍情况,CPU只能整块(Block)的擦出(16K,32K,64K…),可以最少4字节单位写,没有顺序限制,现在CB只用了一个Block。现在调整刷新顺序:擦出成功后,先刷新橙色区域,最后一步刷新启动地址1有效性标志(灰色区域)。这样,即使在更新橙色区域过程中掉电。重新上电后,程序依然从启动地址2开始运行,即重新运行Reboot继续等待刷新CB指令,如图3-a所示。具体操作时也不需要更改下载流程,使用$34,36服务按顺序从上位机传输数据到CPU中,先把启动地址1的有效性标志放到RAM里,当把橙色区域都下载到Flash后,再从RAM里把启动地址1的有效性标志写到Flash里(这一步10ms以内即可完成,完全可以忽略在此时间内掉电的可能性)

如果最后一步启动地址1刷新成功,再重新上电后,程序从启动地址1开始运行新的Boot。即启动地址1起了Boot有效性标志的作用(最先擦,最后写),如图3-b所示。

image-20240120200919041
image-20240120200919041

对策二、Boot有效性标志独立置尾,增加Boot有效性检查逻辑

如图4-a,把Boot分成2个段,Sec1里仅存放少量的启动自检查逻辑,当它检测到置于Sec2末尾的CB_ValidFlg无效时,即认为Boot是不完整的,则程序控制跳转到启动地址2继续运行ReBoot,重新刷新Boot。

如图4-b,当Sec1的逻辑检测到CB_ValidFlg有效时,即认为Boot刷新完成,则程序控制跳转入Sec2里,此时由于App(ReBoot)末尾的App_ValidFlg是无效的,程序并不会跳转入ReBoot里,接下来就可以刷入新的App了。

这种方法只需要对CB的逻辑和段分配做一下调整,不需要更改刷新顺序。Sec1里的启动自检查逻辑可以做的尽量小,则只要保证刷新Sec1段的过程中不掉电,控制器就不会刷死,大大降低风险。但是对量产软件,检查CB_ValidFlg无效就直接跳转入App是不合理的,所以当Boot最终定型后,应该把这个跳转逻辑关闭。

image-20240120200916273
image-20240120200916273

小结:

对策一简单可靠,经过实际测试验证,完全可以满足稳定刷新ECU的要求。

以上就是良许教程网为各位朋友分享的Linu系统相关内容。想要了解更多Linux相关知识记得关注公众号“良许Linux”,或扫描下方二维码进行关注,更多干货等着你 !

137e00002230ad9f26e78-265x300
本文由 良许Linux教程网 发布,可自由转载、引用,但需署名作者且注明文章出处。如转载至微信公众号,请在文末添加作者公众号二维码。
良许

作者: 良许

良许,世界500强企业Linux开发工程师,公众号【良许Linux】的作者,全网拥有超30W粉丝。个人标签:创业者,CSDN学院讲师,副业达人,流量玩家,摄影爱好者。
上一篇
下一篇

发表评论

联系我们

联系我们

公众号:良许Linux

在线咨询: QQ交谈

邮箱: yychuyu@163.com

关注微信
微信扫一扫关注我们

微信扫一扫关注我们

关注微博
返回顶部