我试图考虑对正在开发的嵌入式系统进行软件升级的最佳方法。 运行该系统的产品可以部署在远程位置，因此必须具有某种机制来处理软件升级过程中的故障。
我将解释引导过程的第一阶段。我认为此阶段的良好设计也与后续阶段有关。
mmc的布局如下： 系统从具有4个“ preloader”副本和一个u-boot的分区的分区开始运行。系统会尝试验证第一个预加载器，如果它合法，它将开始运行它。预加载器会对硬件进行一些校准，然后跳转到u-boot所在的预定义地址。从这一刻起，u-boot开始控制，他负责加载硬件设计和linux内核。
就像我提到的那样，预加载器具有芯片制造商设计的机制来测试有效性和处理故障（如果第一个预加载器损坏，系统将尝试验证下一个预加载器...）。
我需要某种机制来处理损坏的u-boot。更精确地说，完整的软件升级包括升级U-boot，并且如果在复制新的u-boot时系统突然关闭，则...“休斯顿，我们有问题”。
我想也许可以在U靴中添加页眉和页脚。页眉将保留U-boot大小，而页脚将保留一些验证字。 我还将添加一个简单的代码，将其称为“验证代码”，该代码读取u-boot标头并检查页脚是否包含正确的验证字。此代码永远不会更改。 我还将向从未更改过的分区添加“紧急u-boot”。
新流程将是： 预加载器从与以前相同的地址加载下一阶段，但这一次它正在加载新的“验证码” 验证代码根据页眉计算u-boot页脚的位置，然后检查验证字。如果一切顺利，则开始加载u-boot，否则，则加载“紧急u-boot”。
我从来没有设计过这样的机制，所以我不知道我的想法是好是坏。
谢谢。