汽车的升级原来是这样子搞的，

今天在网上看到的一篇文章，有一个同学在做汽车的 OTA 升级的时候他是这样子搞的，原文如下

⇢⇢⇢⇢⇢⇢⇢⇢⇢⇢

https://www.zhihu.com/question/571903144/answer/3497542571

我是做汽车的。具体地说我是OEM，其实自己并不需要做代码开发。都是由供应商来做。前几年接手了一项任务，其中涉及到OTA。借此机会就把OTA弄明白了。

今天我不想说太多复杂的技术，只想说点好玩的事情。

具体的，做汽车OTA的人会有经历。升级的时候要提供两个文件:升级包的bin，以及flash driver的bin。为什么要提供一个flash driver呢？这个设计机制确实很精妙。

为了避免错误擦写，这个标准的设计者要求FBL的底层架构与flash driver分开。让整个软件包中没有能够写flash的能力，而是在升级前现下载到内存中现用。用完了重启就又没有内存擦写能力了。

这个机制可以避免在任何时刻意外的擦写内存。

好了。我遇到了另外一个问题。在我们另外一个零部件上，发生了一次故障: 程序出问题了。用JTAG回读发现程序被改写了。我说这怎么可能？机制上就不应该。

这家MCU的供应商，是深圳一家以自主研发而广为闻名的一家企业。掏出自己澄清的报告，说: 他们的芯片中植入了flash driver。我说那这是不规范咯！这个flash driver在意外条件下，被异常激活了。我说那ECC是吃什么的？然后就把内存擦除了。

这问题确实太深了。有些细节超出了我当前的认识。供应商那边的分析报告又写得清清楚楚。手段措施又证实有效。最后我就接受了。

⇢⇢⇢⇢⇢⇢⇢⇢⇢⇢

我们一般升级的时候会使用 A/B 方式，如果 A 分区有问题的话，就使用 B 分区运行，这样的方式几乎是不会让设备变砖。

上面文章中提到的 flash driver 是为了防止别人写 flash，但是我是不明白了，写 flash 并不等于升级呀，升级是一个非常复杂的流程，涉及到校验，如果用户拿不到厂商的固件，根本没有办法通过校验，那 flash driver 存在的意义是什么呢。

不知道有没有大佬做这方面的，想了解下这种奇怪有复杂的升级方式。