Embedded 嵌入式系统中允许安全软件升级的技术有哪些

为嵌入式设备升级软件通常有可能“阻塞”设备，例如，如果在将软件写入闪存的过程中发生电源故障。两个问题：

为实现升级机制以最大限度地降低设备被“屏蔽”的可能性，有哪些最佳实践

哪些是使升级过程故障安全的最佳实践，以便在将软件安装到闪存时能够恢复电源故障等事件

---

内部闪存上的校验和，如果CRC/校验和不起作用，则使用默认备份。这样，如果设备获得不正确的校验和，则它知道升级未完成，可以重置为另一设备上存储的默认/以前的固件

这需要一些预引导（可能在引导加载程序中）来检查校验和。一段静态代码

---

编辑：进一步查看其他地方的评论。如果您想检查错误的固件，而不仅仅是损坏的固件，那么您的checsum/checkdata也可以封装版本信息（以及检查该标头）。我认为Linksys路由器会这样做，这会使它们在使用自定义固件刷新时出现问题。

校验和很好，但只会避免在损坏的数据中闪烁。如果您在一个图像文件中闪存一个有效的校验和，但对于不同的产品型号，该怎么办。我见过的最好的东西是一个只读的默认引导加载程序，它可以在发生紧急损坏时访问。

这一切都取决于应用程序的关键程度。这两种基本方法（备份和引导加载程序）有时也会结合使用

许多系统都有一个只读引导加载程序（如），然后是两组闪存（通常在同一个芯片上）。然后引导加载程序有一个标志来选择从哪个银行引导。然后，该标志将根据升级（失败或成功）等事件进行更改

因此，升级时，运行版本会将新负载复制到备份库中，检查校验和，切换启动标志，然后重新启动设备。设备在新的存储组上重新启动，并加载新的负载。重新启动后，新负载可以将自身复制到备份库中

通常还有一个带硬件复位的看门狗定时器。这样，如果固件变得疯狂，它无法启动看门狗，硬件重置将重新启动设备，引导加载程序将查找正常负载

开放网格项目就是这种方法的一个很好的例子。

更具体地说

将替换映像下载到内存区域，而不覆盖任何当前程序空间。等待下载完成，然后计算并比较CRC

如果空间真的是个问题，你可以做“默认备份”或者“恢复模式”之类的事情，但是不破坏性地做这件事要巧妙得多

如果你真的很滑。。。您可以对闪存执行一次写入更新，以指示设备从新代码位置启动。这将在两个完全分离的代码段之间进行ping/pong。这是最安全的方法：

• 总是有一个不可更新的恢复引导加载程序（Nano-loader），如果一切都出了问题，它会以某种方式发出加载新代码的信号
• 两个独立的程序空间
• 每个程序空间都有一个“CRC”字段、一个“burn number”（高于另一个代码页的编号）和一个“invalid”字（所有的Fs-不需要擦除来更新“invalid”标记）
• 下载完成后，验证CRC。如果是好的，在旧版本的程序空间中烧掉“无效”标记
• Nano加载程序会检查“无效”标记，以知道要引导到哪个。如果两者都有效，则进行CRC检查。如果两者仍然有效，则采用较高的刻录号条目

哦，当人们说校验和。。。不要“检查总数”。。。做一个正确的CRC

无论发生什么情况，都要在内存中保留只读引导加载程序

在引导加载程序中，允许使用故障保护方法（例如，在重新启动期间按下按钮X）从可用输入源（SD卡、RS232等）重新加载新程序内存

在一些实验室（而不是消费者）设备上，我看到了用编程电路构建的电路板。在最坏的情况下，您可以打开机箱，插入编程器并重新加载默认软件，或者将其发送回去，让您也这样做当然，这要花很多钱

---

我的一些项目中使用的一些定制板有可替换的ROM。这是cheeper，但不太方便。

要回答这两个问题，不管是否有特定的硬件资源：

• 确保在运行任何应用程序代码之前（启动时或下载完成后），引导加载程序对应用程序执行CRC检查。如果无效，引导加载程序将不运行代码

• 如果引导加载程序决定它不能运行应用程序代码，它必须能够向用户发出信号，并再次开始下载

如果处理器没有足够的闪存来存储备份应用程序，或者在完成下载之前没有足够的RAM来存储新应用程序，那么这些显然变得更加重要

---

在这些情况下，下载的文件有一个小的头是有意义的，它允许引导加载程序确定文件是否适合系统。此标头还可以具有CRC。如果标头对此系统有效，并且CRC正确，则引导加载程序可以擦除闪存（但不能擦除闪存本身！），并继续下载。如果没有，它将在不接触现有应用程序代码的情况下中止。

根据我的经验，这取决于您的成本点是什么，如果您能够负担得起设备上两倍的代码/数据空间，并且可以重新启动，这很简单，将新版本存储在所有额外空间中，进行适当的校验和检查