汽车控制器的BootLoader(下文简称Boot)主要作用是更新App程序。以往在不打开控制器的情况下，是无法更新Boot。随着主机厂对车上各控制器要求实现OTA功能，App备份、Boot自更新的需求也随之到来。
App备份和Boot自更新是两个重要的功能，接下来主要先来梳理一下Boot自更新。方案一：Supplier Boot(SB) + Customer Boot(CB)通常情况下，供应商都有自己的平台软件，包括Boot和Appl。而各主机厂都有自己不同的软件升级规范，为了适配主机厂的需求，通常的做法是加一层Customer Boot来实现客户的需求。那软件的运行顺序就是SB->CB->Appl，如图1所示。这种做法可以简单、快速的满足CB也可以更新。不过这种方式，通常情况下通过SB更新CB是通过供应商自己定义的升级流程，并且通过自己的上位机来实现升级。也就意味着这种方式只适应项目开发阶段，因为供应商的升级流程无法接入到整车的OTA流程。这种方式的优点就是简单，能很快地适配客户的需求，而且即使面向不同的客户，只需要简单的更改CB就可以满足需求，适应性比较好。但是缺点就是会浪费Flash空间。将Boot先放到RAM中运行，然后更新Boot的Flash区域这种方式只需要一份Boot，其具体方案是，在Boot的链接文件中，将程序和数据映射到特性的RAM空间，然后在控制器上电时，首先将Boot的代码和数据搬运到RAM中，程序运行在RAM中，当收到更新Boot的需求时(这里需要上位机在发送更新指令的时候，区别是更新Boot还是App，比如通过在0x31服务写入不同的标志位进行区分)，通过RAM中的程序以及上位机下载的Flash Driver，将Boot的Flash区域进行更新。
这种方式的优点就是节省Flash空间，而且如果客户想把Boot自更新的功能保留到量产之后，也是可以的，因此控制器的升级是完全遵循主机厂的要求的。不过这种方式有个缺点，就是在更新过程中，不能断电，一旦断电，控制器就会变成板砖，需要换件。另外程序运行在RAM中，对踩内存这种行为更加敏感。不过在整车上，出现意外断电的情况应该很少。首先升级之前会检查低压蓄电池的电压水平，甚至对新能源车来说，可以启动DCDC，来保证12V的稳定供应。这种方案下，有两个CB和一个miniBoot，miniBoot的作用很简单，就是根据引导区的标志位来决定切换到哪个Boot。
其具体的运行方式是，当软件收到Boot更新指令时，软件复位，首先跳转到miniBoot，在miniBoot中，根据引导区标记（标记所需运行的Boot号，比如1代表Boot1,2代表Boot2）跳转到相应的Boot，假设当前运行是Boot1，在Boot1中根据刷新指令，将Boot2的Flash区域进行更新，更新完之后，将引导区标记写为2，然后软件复位，那么下次运行的时候就会切换到Boot2运行了。图3 2个CB+miniBoot方案
种方案的优势就是可以保证刷新过程中断电不会导致控制器变成板砖，而且也可以在SOP之后继续使用。缺点也很明显，空间占用率比较大，软件复杂，需要三个Boot。
三种方案中，简单来说分为两类，其中一类是依赖一个启动Boot来切换到CB的，方案一和方案三都是这种思路，只不过方案三将Supplier Boot进行了简化，作用仅仅是一个跳转。第二类是将Boot放到RAM中运行，然后更新自己的Flash区域，这种的致命缺陷就是更新过程中不能断电。
另外三种方案中都需要对现有的Boot方案进行改进，共同点就是必须增加一个流程，来确定是更新Boot，还是更新App，这里就需要在升级流程中增加一个步骤，比如是0x2E服务，写入升级的标志位，在跳转到Boot后，再识别该标志位来确定是更新Boot还是App。
对于方案三而言，还需增加切换引导区标志位，用来确定当前当前所需运行的Boot，另外由于这些参数很敏感，增加一些安全校验手段，来保护敏感数据也是必须的。
本站仅提供存储服务，所有内容均由用户发布，如发现有害或侵权内容，请
点击举报。
