使用SystemReady IR简化嵌入式Linux系统

作为过去 16 年一直在构建嵌入式 Linux 系统的人，我为使用 Linux on Arm 构建的令人惊叹的产品感到自豪。然而，我也很关心每个平台需要付出多少努力。无论如何，嵌入式 Linux 生态系统都是一个健康的生态系统。它被用于各个行业。Linux 的灵活性和功能很容易适应新产品，而开源生态系统使我们所有人能够协作并使 Linux 变得更好。

另一方面，大多数嵌入式设备上的软件堆栈是完全定制的。操作系统与平台绑定，即使是最小的更改也意味着重建整个映像。例如，在产品的生命周期内，硬件设计可能会发生多次变化，以考虑组件可用性、提高可靠性或降低成本。虽然产品的外部功能可能不会改变，但每次迭代都可能需要一个长期支持供应商的新操作系统映像。同样，许多产品使用相同的基本硬件设计，仅在用户空间应用软件上有所不同。然而，在典型的嵌入式开发中，每个变体都有不同的 OS 映像，单独支持且没有任何共享的二进制组件。

这里的问题不是构建嵌入式系统。我们在 Yocto、Buildroot、OpenWRT 等中拥有的优秀工具使构建嵌入式产品变得容易。相反，问题在于每个构建配置都需要额外的努力和成本来支持和维护。通过使用相同的二进制组件来摊销跨多个产品的支持并不是一个好方法。一个例子是安全补丁：通过一个或几个构建配置，您可能能够跟上安全补丁的最新状态，但所需的工作量会随着每个额外的构建而线性扩展。如果您有 100 种产品，那么每次应用安全补丁时，都需要重新构建、测试和部署 100 种不同的内核配置。这种努力很快就会失控。

通过寻找在产品之间共享组件的方法，长期维护多个产品变得更加可行。做到这一点的一种方法是引入组件交互方式的标准，以确保互操作性并允许定制产品在适当的情况下引入通用软件组件。

解决嵌入式问题

在这一点上，很容易说，“台式机和服务器标准已经解决了这个问题。让我们使用这些。” 虽然确实如此，但 PC 平台标准确保任何操作系统都可以在该空间中的任何硬件上启动。然而，它也很简单，既不承认硬件限制，也不承认嵌入式所需的定制级别。我们需要处理自定义硬件接口，并且通常需要修改整个软件堆栈中的许多组件才能在嵌入式设备中工作。它也没有认识到嵌入式生态系统在 U-Boot 和设备树等成熟技术上投入了大量资金，并且存在很大的迁移阻力。为了在嵌入式中有用，引入的任何标准都必须考虑嵌入式生态系统的需求。

了解标准化水平如何影响产品开发方式也很重要。如果几乎没有标准化，就像现在的嵌入式 Linux，它在如何构建嵌入式系统方面提供了高度的灵活性，但随着时间的推移会产生高昂的维护成本来支持定制开发。另一方面，严格的标准将确保高度的互操作性，但可能无法提供嵌入式行业所需的灵活性。如果标准太严格，就会被忽视，也不会为新产品和创新产品做任何事情。标准化和灵活性之间存在平衡，尤其是嵌入式，它支持创新并创造更好的产品。

SystemReady IR 认证计划所要解决的正是嵌入式标准化水平的要求。SystemReady IR 通过选择可以使用当今已经在使用的技术实现的标准，将“Just Works”的承诺扩展到嵌入式 Linux 产品。SystemReady IR 认证可确保平台实现操作系统无需定制即可依赖的标准固件接口，并且该平台的支持已合并到主线 Linux 中。

或者具体来说，SystemReady IR 兼容平台可以使用与 Arm 服务器和笔记本电脑完全相同的映像格式和引导流程来引导通用 Linux 发行版。使用相同的引导流程为嵌入式生态系统打开了各种可能性。仅举几例，这意味着设备供应商无需自己维护所有内容，而是可以使用支持良好的发行版构建产品，这些发行版拥有管理更新和安全修复的资源。这意味着自定义 Yocto 映像可以在部署到真实硬件之前使用云中的虚拟机进行引导和测试。这意味着工程工作不需要专门用于管理每个平台的差异，而且至关重要的是，即使在构建完全自定义的操作系统堆栈时，也可以轻松支持许多硬件设备。

SystemReady IR 是更大的 SystemReady 程序的嵌入式和物联网频段。SystemReady 定义和证明 Arm 系统的硬件和固件标准符合 Arm 生态系统不同部分的频段。每个频段的详细要求在本文末尾链接的 SystemReady 要求规范 (SRS) 中定义。SystemReady IR 认证平台列表可在 SystemReady 网页上找到。第一个 IR 认证于 2021 年 6 月发布，在 2021 年 10 月 Arm DevSummit 之前将发布至少 11 项认证，还有更多认证正在筹备中。

适用于嵌入式的标准

为了使标准与嵌入式相关，它们需要满足两件事：它们必须促进互操作性，并且它们必须与现有的软件堆栈一起工作。大多数嵌入式 Linux 产品都是使用 U-Boot 固件、设备树系统描述和自定义 Linux 内核构建的。U-Boot 和设备树是广泛部署的成熟技术。然而，它们的使用方式使得互操作性变得困难。由于 U-Boot 引导脚本的细微差别，每个平台的部署都不同。操作系统与平台绑定，因为设备树与操作系统紧密耦合。使软件保持最新需要自定义代码，因为没有标准的固件更新界面。因此，尽管组件功能强大且成熟，但缺乏标准却无法确保互操作性。

在设计 SystemReady IR 时，我们确定了可以通过合理的设计更改来解决的主要问题。我们寻找可以在平台（硬件和固件）和操作系统之间创建定义接口的地方，从而简化所需的工程设计。为此，我们专注于嵌入式开发人员面临的具体问题。下表是一个有用的总结：

这些变化；启用 UEFI，默认提供 DT，支持 UpdateCapsule()，在 mainline 中的支持解决了大部分 OS 互操作问题。所有主要的操作系统供应商都期望 UEFI 引导流程，而 U-Boot 已经实现了 UEFI。立即启用它使 U-Boot 兼容。将 U-Boot 配置为默认向操作系统提供设备树意味着平台可以向操作系统描述自身。因此，操作系统不需要携带有关每个硬件平台的详细信息。对于通用发行版，这是一个关键问题，因为它们无法大规模支持每个平台的定制。操作系统是通用的，不能包含特定于机器的详细信息。同样，启用 UpdateCapsule() 为更新系统组件提供了一个标准接口，因此操作系统不需要了解特定于机器的更新机制。最后，供应商内核是嵌入式 Linux 开发中最大的痛点，因为这意味着每个产品都需要不同的内核树，这使得 Linux 发行版无法支持该平台。通过要求在主线 Linux 中支持硬件，发行版可以在其通用映像中提供对硬件的支持。此外，定制的 Linux 构建可以跟踪 Linux 稳定版本，而不是依赖供应商来保持他们的分支是最新的。

今天，U-Boot、Trusted Firmware、Linux、主要发行版和 Yocto 都支持此处列出的所有内容。配置选项很容易打开，一旦启用，它们会在构建产品时打开广泛的操作系统和硬件选项。最重要的是，它不需要更换您已经在使用的任何软件。

SystemReady IR：标准和认证

SystemReady IR 的作用是将前面讨论的标准形式化为硅供应商和 ODM 可以实施的一组特定要求。它建立了一个认证测试程序来验证是否符合规范。在高层次上，IR 波段要求：

固件实现了嵌入式基本引导要求 (EBBR) 中定义的 UEFI 子集

固件默认提供适合引导主线 Linux 的设备树

固件可以使用 UEFI UpdateCapsule() 进行更新

至少两个 Linux 发行版必须能够使用 UEFI 引导流程进行引导和安装

IR 计划提供工具、测试套件和资源，以帮助逐步完成认证过程。最重要的资源是 SystemReady IR：IoT 集成、测试和认证指南 ，其中涵盖了如何启用和测试 SystemReady IR 合规性的所有细节。这些工具是开源的，它们的有用链接在 SystemReady IR 指南中。

原作者：格兰特可能