救援方法（左手）允许为主分区提供更多空间，而双rootfs方法（右手）要求在两个分区之间或多或少均匀地分配空间。如果空间不成问题，则建议使用dual-rootfs方法，因为这将减少停机时间。通过救援方法进行更新需要两次重新引导，一次重新进入救援分区，然后另一次重新进入主分区。dual-rootfs方法仅需要一次重新引导，因为可以随时执行更新。

在这些系统中无法安全更新的是引导加载程序（或实际上是救援分区）。如果您也想更新引导加载程序，则需要两个单独的引导加载程序分区，以及某种Board-Management-Controller来实现两者之间切换的逻辑。

图2.发生故障时的恢复– Board Management Controller

当然，这是一个复杂的解决方案，需要一个额外的微控制器，一套新的固件以及更复杂的硬件设计（例如，在某些设备中使用，例如那些包含单独的智能平台管理接口（IPMI）控制器的设备） 。因此，您应该着眼于构建功能齐全，范围较小且不需要更新的引导加载程序。

U-Boot环境变量

U-boot实现了一个非易失性“环境”，可以在其中存储变量。甚至可以从Linux（可以通过多种方式来访问它们，具体取决于环境的存储方式，如elinux.org上所述）。

这是实现上述“开关”的最明显方法。它也可以用于存储有关先前启动成功或失败的信息，以便在启动失败的情况下可以反转交换机并恢复工作分区。

图3. U-boot环境变量

设置看门狗

处理器的硬件监视程序应该由U-Boot（CONFIG_WATCHDOG）设置，然后在启动完成后由Linux维护。如果整个系统挂起，这将导致重置。

检查启动失败

关键任务应用程序运行后，应在u-boot环境中设置一个变量，指示启动完成。然后，U-boot将能够检查是否在下一次启动时设置了该设置，如果启动失败（有时仅在连续几次失败之后），则可以采取措施。

具体的架构将取决于您的应用程序和产品。您将需要对此进行一些自定义，以适应您的需求。您将要确定所有可能的故障模式，并对所有故障模式实施恢复。

实施更新

正如我们之前所说，更新应以单个加密签名文件的形式出现。私钥签名可确保其源自制造商您。现在，系统只需解压缩它并运行其中的脚本即可自行执行更新。它将覆盖要更新的分区；轻拂所需的任何开关，然后重新启动。这应该尽快发生，以最大程度地减少停机时间。

保护更新

我们要确保提供给设备的更新文件来自制造商而不是其他人。为此，请使用制造商持有的私钥对更新文件进行签名。相应的公钥保留在设备上，它将验证要求使用其进行更新的任何更新文件。如果提供的文件被认为无效，则更新将失败。

获取更新

更新如何到达是另一回事。这里有四种可能性：

最明显和最简单的方法是，该更新是由具有root登录到设备的工程师应用的。他运行更新脚本并更新了设备。这充满了安全隐患，并且可能仅适用于开发中的系统或工程或工业环境中使用的系统。

物理介质已插入包含所需更新的设备（USB记忆棒）中。板上的软件将通过轮询守护程序或udev规则自动检测并安装。

通过某种方法（例如，Web应用程序）将更新文件上传到单个计算机。

空中更新，如下一节所述。

空中更新

空中（OTA）更新通常是指通过安全通道从中央服务器更新的设备。它通常指的是物联网设备，移动电话，汽车ECU等。在本文中，我将描述一种更新类型，该更新可以在连接到互联网的任何设备上运行，并且可以通过Wi-Fi（空中），以太网（铜缆）或其他某种协议。

检查更新

首先要做的是检查更新。设备上运行的守护进程可以将请求发送到预定服务器，提供其当前版本和硬件版本。然后，服务器可以根据该信息，在必要时将签名的更新文件发送到设备进行安装，或者报告没有可用的更新或不需要更新。

可以通过多种方式添加复杂性，从仅基于各种标准向设备子集提供更新，到对更新文件进行完全加密，再到将更新状态或其他信息报告回中央服务器。

现成与内部解决方案

有许多现成的更新机制可以与嵌入式Linux系统集成，而不必如上所述重新发明轮子。可以在yocto项目中找到其中一些的比较。

这些可能需要一些时间和精力才能与您当前的嵌入式Linux构建系统集成，但是它可能比内部开发自定义方法要少一些，并且由于其中一些项目已经花费了数百小时而变得更加强大。进入他们。

为什么您不想要现成的解决方案的原因：

您希望在每个级别上为董事会自定义内容

在使用大型代码库时，您可能会遇到安全问题，而该代码库仍相对较新，并且使用或识别的程度不高

在ByteSnap Design，我们为许多不同的客户提供了完整的硬件和软件解决方案，我们创建了内部自定义更新系统，同时在各种不同的芯片组（例如MTS）上集成了Mender等现成的更新系统。返回搜狐，查看更多