作为一个在过去 16 年里一直在构建嵌入式 Linux 系统的人，我既为与 Linux 在 Arm 上构建的了不起的产品感到自豪，也为需要付出多少努力才能打造出每个平台而感到担心。无论如何，嵌入式Linux生态系统是一个健康的生态系统。它适用于每个行业。
Linux 的灵活性和功能很容易适应新产品，开源生态系统使我们所有人能够将Linux 组合在一起，使 Linux 变得更好。
另一方面，大多数嵌入式设备上的软件堆栈完全是自定义的。操作系统与平台相连，即使是最小的改动也意味着重建整个镜像。例如，在产品使用寿命内，硬件设计可能会更改数次，以考虑组件可用性、提高可靠性或降低成本。虽然产品的外在功能可能不会改变，但每次迭代都可能需要新的操作系统镜像，而该镜像必须由供应商长期支持。同样，许多产品将使用相同的基础硬件设计，并且仅在应用软件的用户空间上做差异化，但是在典型的嵌入式开发中，每个变体将具有不同的操作系统镜像，该镜像需单独支持，而没有任何共享的二进制组件。
这里的问题不在于构建嵌入式系统。我们在Yocto、Buildroot、OpenWRT和其他产品中拥有出色的工具，因此可以轻松构建嵌入式产品。 相反，问题在于每个构建配置都需要额外的努力和成本来支持和维护。我们并没有用相同的二进制组件在多个产品上扩展支持的好方法。以安全补丁为例，用一个或几个构建配置，您也许能够跟上安全补丁的最新情况，但每次附加修补时，花费的精力都会线性地缩大。如果你有100个产品，那么每次应用一个安全补丁，那么这是100个不同的内核配置，需要重建，测试，然后部署。这项工作很快失控。
通过找到产品间共享组件的方法，长期维护多个产品变得更加可行。这样做的一种方法是引入组件交互方式的标准，确保互操作性，并允许自定义产品在适当情况下调用通用软件组件。
解决嵌入式问题
在这一点上，吸引人的说法是，“台式机和服务器标准已经解决了这个问题！我们直接用就好了。”虽然是真的，PC平台标准确保，任何操作系统可以在其空间内的任何硬件上启动起来。然而这个认知也是简单化的，没有认知到硬件限制或者嵌入所需的定制水平。我们需要处理自定义硬件接口，而且通常整个软件堆栈中的许多组件需要修改以在嵌入式设备中工作。它也没有认识到嵌入式生态系统已投入了大量资金开发的在诸如U-Boot和设备树等成熟技术，对从这些技术迁移出去具有很高的抵抗力。为了在嵌入式中有所用，引入的任何标准都必须考虑到嵌入式生态系统的需求。
了解标准化水平将如何影响产品的开发方式也很重要。如果没有什么标准化，正如现如今的嵌入式Linux，它在如何建立嵌入式系统上提供了高灵活性，但是，为了支持自定义行为，随着时间推移产生了维护成本。另一方面，严格的标准将确保高度的互操作性，但未必能提供嵌入式行业所需的灵活性。如果标准过于严格，那么它们将被忽略，并且它们不会对支持新的和创新的产品起到任何作用。标准化和灵活性之间有一个平衡，特别对于嵌入式，它能够创新并创造更好的产品。
SystemReady IR 认证计划正是要解决这个问题，以达到正确的嵌入标准化水平。SystemReady IR 通过选择使用目前已经使用的技术可以实施的标准，将"Just Works"的承诺扩展到嵌入式 Linux 产品。SystemReady IR认证保证平台实现的操作系统所依赖的标准固件接口是无需操作系统定制化的。并且该平台的技术支持已合并到主线 Linux 中。
或者具体来说，合规SystemReady IR的平台在通用的Linux 发行版本上启动所用到的镜像格式和启动流程，是和Arm 服务器与笔记本电脑所使用的完全相同。使用相同的启动流程为嵌入式生态系统打开各种可能性。举个例子，这意味着设备供应商可以使用支持良好的发行版来构建产品，这些发行版拥有管理更新和安全修复的资源，而不是自行维护所有内容。这意味着，自定义 Yocto镜像可以在部署到实际硬件之前使用云上的虚拟计算机启动和测试。这意味着工程工作不需要专门管理每个平台的差异，而且，关键是，即使构建一个完全自定义的操作系统堆栈，也很容易支持许多硬件设备。SystemReady IR意味着您可以专注于使您的产品变得出色的功能，而不是单个设备启用问题。
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 引导脚本略有不同，每个平台上的部署都不同。操作系统与平台相连，因为 Devicetree 与操作系统紧密耦合。保持软件最新需要自定义代码，因为没有标准固件更新接口。因此，虽然组件是有能力和成熟的，但如果缺乏标准，也是没有办法确保互操作性。
在设计SystemReady IR的时候，我们确定了可以通过合理的设计改动来解决的重大问题。我们寻找在哪里我们可以在平台（硬件和固件）和操作系统之间创建确定的接口，这将简化所需的工程。这样做，我们专注于嵌入式开发人员面临的具体问题。下表是有用的摘要：
这些变化：启用 UEFI，默认提供 DT，支持UpdateCapsule()，并在主线中支持解决大多数操作系统互操作性问题。所有主要的操作系统供应商期望UEFI启动流, 而U-Boot已经实现UEFI。启用它立即使 U-Boot 兼容。默认情况下配置 U-Boot 以提供设备树给 操作系统意味着平台可以向操作系统描述自己，而操作系统不需要随身携带有关每个硬件平台的详细信息。对于通用操作系统发行版，这是一个关键问题，因为它们无法大规模支持每个平台的自定义。操作系统是通用的，不能包含机器特定详细信息。同样，启用UpdateCapsule()为更新系统组件提供了一个标准接口，以便操作系统无需了解机器特定的更新机制。最后，供应商内核是嵌入式Linux开发中最大的痛点，因为它意味着每个产品都需要不同的内核树，它使平台无法得到Linux发行版的支持。通过要求在主线Linux中支持的硬件，发行版可以为其通用镜像中的硬件提供支持，而自定义 Linux 构建可以跟踪 Linux 稳定版本，而不是依靠供应商来保持其程序是最新状态。
这里列出的一切今天由U-Boot，可信固件，Linux，主要的发行版和Yocto支持。配置选项易于打开，一旦启用，它们就会在构建产品时打开广泛的操作系统和硬件选项。 最重要的是，它不需要更换任何你已经使用的软件。
SystemReady IR：标准和认证
SystemReady IR的引入是将上述标准正式化为硅片供应商和ODM可以实施的一组特定要求，并建立一个认证测试程序来验证是否符合规范。概括地讲，IR档要求在：
- 固件实现嵌入式基础引导要求 （EBBR） 中定义的 UEFI 子集，
- 默认情况下，固件提供了一个适合启动主线Linux的设备树，
- 固件可使用UEFI UpdateCapsule()进行更新，
- 至少两个 Linux 发行版必须能够使用 UEFI 启动流启动和安装。
IR 计划提供工具、测试套件和资源，以帮助完成认证流程。最重要的资源是SystemReady IR - IoT integration, test, and certification guide，涵盖了如何启用和测试系统准备IR合规的所有细节。该工具是开源的，在SystemReady IR guide中可以找到指向它们的链接。
获得认证
认证过程本身是直截了当的。第一步是联系我们，让我们知道您想要认证的平台。我们会问几个问题，以确认您能够运行并通过认证测试程序，然后让您与SystemReady IR测试实验室之一联系。您需要向测试实验室提供您自己的测试结果副本以及硬件样本，以便实验室能够复制和确认您的结果。最后，测试实验室将向 Arm 提供测试结果的完整结果。如果平台符合所有要求并通过测试，Arm 将提供正式的系统认证证书，并在SystemReady IR网页上列出该平台。
接下来呢？
SystemReady IR项目正在积极测试和认证板。如果您有任何问题，或者如果您有产品要认证，那么您可以在 systemready@arm.com联系我们。您可以阅读SystemReady IR集成、测试和认证指南，并尝试在平台上运行IR架构合规套件 （ACS）。所有的项目细节都可以在 www.arm.com/systemready-certification-program找到。最后，您可以通过参与EBBR社区项目来帮助我们定义SystemReady IR的下一次迭代。联系人和会议详情可在 https://github.com/arm-softwa... 的EBBR项目页面上找到。
更多内容请关注全面计算Total Compute专栏
