在嵌入式系统中允许安全软件升级的技术是什么？

Question

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

1. 实现升级机制的最佳实践是什么，以便将设备被“砖”化的可能性降到最低？
2. 有哪些最佳做法可以使升级过程安全，以便从安装软件到闪存时发生的诸如电源故障这样的事件中恢复？

Answer 1

这完全取决于应用程序的重要性。这两种基本方法(备份和引导加载程序)有时也会结合在一起。

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

因此，升级时，正在运行的版本将新加载复制到备份银行，检查校验和，切换引导标志，然后重新启动设备。设备重新启动在新的银行，与新的负载。重新启动后，新加载可以将自己复制到备份库中。

通常还有一个带有硬件重置的看门狗计时器。这样，如果固件发生故障，它将无法启动看门狗，硬件重置将重新启动设备，引导加载程序将寻找一个正常的负载。

Open项目就是这种方法的一个很好的例子。

Answer 2

更具体地说..。

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

如果空间真的是一个问题，你可以做‘默认备份’AKA‘恢复模式’之类的事情，但它是光滑得多，不这样做破坏性。

如果你.真的.您可以对FLASH进行一次写入更新，以指导设备从新代码位置启动。这将在两个完全分开的代码部分之间进行ping/pong。这是你能做到的最安全的方法：

• 总是有一个不可更新的恢复引导程序(Nano)，如果出了问题，可以以某种方式加载新代码。
• 两个独立程序空间
• 每个程序空间都有一个"CRC“字段、一个”刻录号“(高于其他代码页的编号)和一个”无效“字(所有Fs -不需要擦除更新”无效“标记)。
• 下载完成后，验证CRC。如果它是好的，烧掉旧版本的程序空间上的“无效”标记。
• Nano加载程序检查“无效”标记，以知道要引导到哪一个。如果它们都是有效的，请执行CRC检查。如果它们都仍然有效，那么使用更高的刻录编号条目

当人们说支票和..。不要“检查金额”..。做一个适当的CRC。

Answer 3

内部闪存上的校验和，如果CRC/校验和不工作，则使用默认备份。这样，如果设备得到不正确的校验和，那么它就知道升级是不完整的，并且可以重置为存储在另一个设备上的默认/先前固件。

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

编辑：进一步评论其他地方。如果您想检查错误的固件，而不仅仅是损坏的固件，您的检查和/校验数据也可以封装版本信息(以及对该标头的检查)--我认为Linksys路由器会这样做，这会使它们很难用自定义固件进行刷新。