RFC-0111：初始 Fuchsia 硬件平台规范

摘要

此 RFC 详细介绍了给定硬件平台的一组初始技术规范，这些规范与 Fuchsia 兼容，已贡献给 Fuchsia 项目，并在 Fuchsia 项目中进行分类。本 RFC 旨在编写一组初始硬件规范，并概述向 fuchsia.git 代码库提交与硬件相关的源代码贡献的过程。只能通过 Fuchsia RFC 流程更改硬件规范。

概览

本文档详细介绍了给定硬件平台的初始技术规范，该平台与 Fuchsia 兼容，已贡献给 Fuchsia 项目，并被归类为受支持或实验性硬件。在“支持的硬件”和“实验性硬件”类别中，分别列出了“必需”和“推荐”规范。

虽然与各种硬件和外形规格兼容是理想的，但每个新的硬件目标都会给 Fuchsia 项目带来架构、维护、测试和验证开销。本文档列出了 Fuchsia 的硬件平台规范，并说明了与每种硬件选择相关的理由。

随着 Fuchsia 项目的不断发展，规范可能会更新。对项目有广泛技术影响的规范变更将通过 Fuchsia RFC 流程获得批准或遭拒。

此政策涵盖 Fuchsia 中的不同类型的硬件，包括：

• 架构（例如 ARM、x86、RISC-V），
• 开发板（例如 VIM3、Raspberry Pi、Intel NUC）
• 其他硬件的驱动程序（例如 USB 设备、网络适配器、HID 设备等）。

“初始 Fuchsia 硬件平台规范”政策不涵盖由外部贡献者使用驱动程序 SDK 编写并托管在任何 Fuchsia 源代码树代码库之外的设备驱动程序。开发者可以使用 Driver SDK 编写驱动程序，并在 Fuchsia 开源项目代码库之外分发源代码和二进制文件。

硬件平台类别

Fuchsia 项目在哪些硬件平台上执行 Fuchsia 项目托管的测试，这些硬件平台会被归类为受支持硬件。实验性硬件符合硬件平台与运行 Fuchsia 的兼容性最低要求，但不会执行 Fuchsia 托管的测试。实验性硬件平台不适用于生产环境。相反，Fuchsia 项目将实验性硬件视为探索和了解 Fuchsia 的途径。

本文档定义了与 Fuchsia 兼容的硬件平台的硬件规格，具体如下：

1. “基本硬件规格”- 这是 Fuchsia 在给定硬件平台上运行所需的最低规格。基本硬件规格分为“必需”或“建议”两类。实验性硬件只需符合必需的基本硬件规范。
2. “支持的硬件规格”- 这些是硬件平台可能被归类为“支持的硬件”所需的规格。除了这些规范之外，由于测试要求，此类别的硬件还必须通过 RFC 流程获得批准。

该文档还定义了与“受支持的硬件”和“实验性硬件”相关的可用性预期。最后，该文档定义了向 Fuchsia 源代码添加硬件平台的过程。

外围设备

“Initial Fuchsia hardware platform specifications”（初始 Fuchsia 硬件平台规范）RFC 涵盖了允许外围设备与给定平台搭配使用的基准系统的硬件规范。这包括 USB 存储设备驱动程序和显卡驱动程序（包括永久连接的显卡和可拆卸显卡）。

“初始 Fuchsia 硬件平台规范”不涵盖运行 Fuchsia 的系统直接可观察到的互动以外的外部外围设备操作的详细信息。例如，以下固件的操作详情不在本文档的涵盖范围内：

• 机器学习 (ML) 加速器
• 音频硬件数字信号处理器 (DSP)
• 显卡内部（而非允许与主系统通信的驱动程序）。

“初始 Fuchsia 硬件平台规范”政策也不涵盖不是最终阶段引导加载程序的引导加载程序。

文档定义

本文档中使用了以下术语：

基本硬件规格

以下是 Fuchsia 的基础硬件规范。 基本规范进一步分为两类：必需和推荐。

所需的硬件功能

必须满足以下硬件规格。

必需的规范

必需的规范是 Fuchsia 在给定硬件平台上构建和安装的基本技术要求。

必需：64 位 CPU 和平台

硬件平台 CPU 必须支持 64 位地址空间操作模式。如果平台或 CPU 以非 64 位模式启动，则可以接受，前提是仅在 Zircon 内核启动之前的早期启动期间使用。

理由

需要 64 位地址空间，且空间充足，才能高效且有效地实现地址空间布局随机化 (ASLR) 等功能。

示例

所有 x86-64 硬件平台；所有 ARMv8-A 及更高版本的处理器（A32 除外）。

必需：全功能内存管理单元 (MMU)

硬件平台必须提供功能齐全的新型内存管理单元，以允许创建任意数量的地址空间，将大小适当的页面中的物理内存映射到其中任意一个地址空间，并通过硬件访问控制机制在单独的地址空间之间强制执行保护。

理由

Fuchsia 大量使用虚拟内存对象，因此高效的内存管理对 Fuchsia 硬件平台的运行至关重要。如果没有硬件强制执行的内存访问控制，则无法实现 Fuchsia 的基本安全保证。

示例

ARM v8.0-A 或更高版本；所有新型 x86 CPU（2010 年及之后）。

必需：小端模式

硬件平台必须支持小端字节序 (LE) 字节排序模式。

理由

在代码开发和测试期间，处理任意字节序列的开销很高。从理论上讲，Fuchsia 的代码可以不区分字节序，但 Fuchsia 项目目前还没有准备好投入这项工作。大多数现代架构都是 LE 原生架构，或者支持 LE 模式。

示例

所有 x86；所有新型 ARM 处理器都支持小端字节序。

必需：对于 x86-64，使用 x86-64-v2 指令集架构

基于 x86-64 处理器架构的硬件平台必须支持 x86-64-v2 指令集架构 (ISA)，如 Fuchsia RFC-0073 中所述。这涵盖了所有 Intel Westmere 及更新型号的 CPU，以及所有 AMD Bulldozer 及更新型号的 CPU。

理由

设置最低 ISA 目标后，系统可以进行假定存在某些指令的实用优化。如需了解完整详情，请参阅 RFC-0073：将 x86-64 平台要求提升到 x86-64-v2。

必需：时钟和计时器

时钟和计时器必须：

• 保持不变，这样当系统的其他部分进行频率缩放时，它们不会任意更改频率。
• 宽度至少为 56 位，滚动时间不得少于 40 年。
• 具有明确可知的标称频率，无需任何运行时校准。

所需的工具链和语言支持

必须满足以下工具链和语言支持规范。

必需：LLVM 工具链支持

相关架构、平台和目标开发板必须位于上游 LLVM 完全支持的 LLVM 核心层级。必须确保为给定平台提供最新的 Clang 工具链支持。如需详细了解 LLVM 支持的目标，请参阅 LLVM 项目中的 CMakeLists.txt。

理由

Fuchsia 使用 LLVM 作为其默认编译工具链。

必需：第 2 层级 Rust 语言支持

相关架构、平台和目标板级至少必须达到 Rust 第 2 层级，最好达到 Rust 第 1 层级。

理由

Fuchsia 大量使用 Rust。

必需：支持 Dart 语言

Dart 必须支持相关架构、平台和目标开发板。

理由

Fuchsia 的大部分界面都是使用 Flutter 构建的，而 Flutter 使用 Dart。

必需：Go 语言支持

Go 必须支持相关架构、平台和目标开发板。

理由

Fuchsia 的网络堆栈使用 Go。

推荐的硬件功能

建议使用以下硬件规格。

建议的规格

虽然构建和安装 Fuchsia 时不需要遵循以下规范，但它们是对基本规范的极佳补充，因为它们可以改进 Fuchsia 在给定硬件平台上的功能。

推荐：时钟和计时器

• 具有计时器，当计时器值超过给定的绝对阈值时，可以向核心发送中断。
• 作为架构本身的一部分进行实现，而不是作为目标层中存在的外围设备进行实现。

建议：I/O 内存管理单元 (IOMMU)

Fuchsia 项目建议硬件平台支持硬件 I/O 内存管理单元。如果没有通过 IOMMU 授予执行此类操作的明确权限，IOMMU 必须能够对从系统中具有唯一标识性的硬件单元发起的读取或写入事务发出 NAK。

（可选）IOMMU 还可以包含以下实用功能：

• 能够为硬件 DMA 操作执行地址转换（这将允许 Fuchsia 项目为硬件 DMA 使用固定但不连续的物理内存）。
• 能够检测和调试 IOMMU 页面故障情况（例如，如果某个单元超出边界，最好能够获得异常以及一些上下文，例如哪个单元在哪个位置尝试执行了哪项操作）。

理由

Zircon 驱动程序是用户模式软件组件，其硬件访问权限非常受限。IOMMU 可防范具有对物理内存访问权限的设备带来的 bug 或攻击，并且比审核硬件和软件更可靠。这提高了 Fuchsia 操作系统的整体安全性。

示例

ARM 的 IOMMU 规范：系统内存管理单元 (SMMU)

Intel 的 x86 IOMMU 规范：Intel VT-d、AMD-Vi

推荐：支持硬件加密加速

Fuchsia 项目建议硬件平台为 AES 和 SHA 加密操作提供硬件加速。

理由

Fuchsia 会广泛使用加密操作，因此为了获得可接受的性能，硬件加速非常有用，尤其是在较小的硬件平台上。

示例

ARM v8.0-A (Cortex A-34) 或更高版本：

• AES：AESE、AESD、AESMC、AESIMC、PMULL 和 PMULL2
• SHA2：SHA256H、SHA256H2、SHA256U0、SHA256U1

ARM 8.1 或更高版本（或 ARMv8-A，如果受支持）：

• CRC32

x86 处理器：

• AES-NI：Intel（'Westmere' 及更新型号；'Silvermont' Atom 及更新型号）
• AES-NI：AMD（“Bulldozer”及更新型号；“Jaguar”及更新型号）
• SHA(1, 256)：Intel（“Ice Lake”及更新型号；“Goldmont Plus”Atom 及更新型号）
• SHA(1, 256)：AMD（“Zen”及更新型号）
• CRC32（支持 SSE 4.2 的处理器）

推荐的工具链和语言支持

以下是建议的工具链和语言支持规范，但并非必需。

推荐：GCC 工具链支持

Fuchsia 项目建议 GCC 工具链完全支持给定的架构、平台和目标开发板。对于不特定于平台的纯应用开发，仅支持 LLVM 即可。

理由

使用第二个工具链可以发现更多 bug。

推荐：第 1 层级 Rust 语言支持

Fuchsia 项目建议为任何给定的架构、平台和目标开发板提供 Tier 1 Rust 支持。

理由

Fuchsia 大量使用 Rust。如需详细了解第 1 级支持的优势，请参阅第 1 级目标政策。

支持的硬件规格

以下是受支持的硬件的规格。由 Fuchsia 项目托管的测试会在受支持的硬件上运行，作为 Fuchsia 的持续集成和测试流程的一部分。Fuchsia 项目托管的测试是在受支持的硬件上执行的，外部贡献者可以查看其结果。支持的硬件示例包括 Intel NUC 和 VIM3。如需详细了解受支持的硬件的支持预期，请参阅规范摘要。

受支持的硬件规格进一步分为两类：必需和建议。

如需详细了解必需和推荐的规格，请参阅下表：

必需的规范

除了基本规范之外，受支持的硬件还必须符合以下规范，才能被视为受支持的硬件支持层级。

必需：引导加载程序开放性

最终阶段引导加载程序是加载 Fuchsia 内核的启动过程的软件组件，必须遵循以下要求：

• Fuchsia 项目必须能够更改引导加载程序。
• Fuchsia 项目必须能够构建引导加载程序。
• Fuchsia 项目必须能够分发 Fuchsia 项目对引导加载程序所做的任何更改所产生的源代码和二进制文件。

引导加载程序无需具有与 Fuchsia 兼容的许可。引导加载程序之前的启动流程早期阶段不需要是开源的，但如果可能，最好是开源的。另请参阅文档和支持服务要求。

最好公开开发源代码，源代码项目所有者接受 bug 报告和外部更改以进行集成，并持续为项目提供支持。

理由

可以修改开源引导加载程序，使其直接支持加载 Fuchsia，而不是使用启动补丁。专有 blob 难以调试或审核安全性。早期启动过程的某些部分通常无法以开源形式提供，并且无法替换为开源版本；例如，供应商专有版本的 ARM 可信执行环境 (TEE)，或 x86 平台上的统一可扩展固件接口 (UEFI) 实现。

示例

coreboot、U-boot。

必需：架构必须受 QEMU 支持

最新的 Fuchsia 项目 QEMU 版本必须支持该架构。建议您遵循以下做法，但这并非强制性要求：

• 支持特定平台。
• 该架构在 QEMU 下可虚拟化。
• QEMU 能够在架构相同的主机 QEMU 机器上运行（例如，在 x86 主机上运行 QEMU-kvm x86，或在 arm64 主机上运行 QEMU-kvm arm64）。

如果架构具有目标模式（例如 ARM Trustzone），QEMU 应该能够对其进行模拟。

理由

为了为构建和测试提供可扩展的硬件支持，QEMU 用于持续集成。如果目标架构不受 QEMU 支持，则无法以可扩缩的方式构建或测试代码。

必需：串行控制台访问

硬件平台必须支持某种形式的串行控制台访问，以便进行开发。面向最终用户提供的正式版系统无需提供此信息。串行控制台必须支持中断驱动型 TX 和 RX。

DMA 支持是一项很实用的功能，但使用 DMA 并非必须。

理由

在平台的早期开发阶段，使用简单的串行控制台进行开发和调试是最可靠的方式。

建议的规格

虽然“受支持”硬件层级不需要满足以下规范，但这些规范是对“必需的受支持”规范的极佳补充。

推荐：文档和支持

该平台应提供合理的公开文档，包括：

• 注册映射
• 运作原理
• 有关启动时硬件状态的信息

仅使用 Linux 分支或 Android 开源项目记录开发进度的开发板不符合要求。平台供应商必须愿意亲自或通过电子邮件解答问题。

理由

如果没有准确的文档，编写驱动程序和调试就会沦为对现有软件进行逆向工程，这很容易出错且速度缓慢。如果文档使用的现有源代码的许可与 Fuchsia 的许可不兼容，则可能会意外复制代码。

建议：支持 fastboot 的引导加载程序

Fuchsia 项目建议引导加载程序支持附录中列出的一系列 fastboot 协议命令。Fuchsia 项目建议在非专有传输中进行快速启动。

理由

统一支持快速启动有助于更轻松地处理不同的硬件平台，并在处理包含多台机器的舰队时协助实现自动化。

推荐：虚拟化支持

Fuchsia 项目建议平台和引导加载程序支持完整的虚拟化。

Intel x86

在 Fuchsia 项目中，需要满足以下条件才能在 Intel x86 CPU 上全面支持虚拟化：

• VMX
• EPT
• RDTSCP
• x2APIC
• VPID
• 不受限制的访客
• TPR 虚拟化
• MSR 位图
• 异常位图

Fuchsia 项目建议（可选）：

• INVPCID
• 退出 PAUSE 循环

ARM

在 Fuchsia 项目中，需要满足以下条件才能全面支持 ARM 上的虚拟化：

• ARMv8.0
• EL2 访问
• 主机物理计时器 / 访客虚拟计时器分屏
• GICv2 或 GICv3
• GIC 虚拟化

理由

虚拟化有许多用途。例如，在 ARM64 上，如果 Zircon 在 EL2 上执行，则可以虚拟化 EL1/EL0 以提高隔离性。

示例

ARM：Armv8-A AArch64；x86：Intel VT-x、AMD VT

推荐：硬件辅助跟踪

硬件平台应支持某种形式的硬件控制流跟踪。

理由

低成本跟踪使对发布 build 执行自动反馈导向优化 (AutoFDO) 成为可能。

示例

ARM：CoreSight ETM；x86：Intel 最后分支记录 (LBR)。

硬件平台类别

Fuchsia 项目将与 Fuchsia 兼容的硬件平台分为两类：受支持和实验性。Fuchsia 的硬件规格因类别而异。受支持的硬件和实验性硬件都必须满足其所需的基本规范。虽然并非强制性要求，但 Fuchsia 项目鼓励支持的硬件和实验性硬件都遵循其各自的推荐规范（如硬件平台摘要中所列）。

如需简要了解受支持的硬件和实验性硬件之间的差异，请参阅硬件平台摘要。

支持的硬件

支持的硬件具有以下优势：

• 支持的硬件由 Fuchsia 项目进行测试。
• 任何实验性硬件贡献都不能破坏受支持的硬件。
• Fuchsia 项目致力于回复针对受支持硬件提交的问题跟踪器问题。成员（如 Fuchsia 贡献者角色中所定义）可以提交补丁来添加新的受支持硬件平台或修复现有的受支持硬件平台。

实验性硬件

实验性硬件平台不适用于生产环境。相反，Fuchsia 项目将实验性硬件视为探索和了解 Fuchsia 的途径。实验性硬件是尽最大努力构建的，这意味着 Fuchsia 在给定硬件平台上在任何给定时间点都可能或不可能正常运行。

实验性硬件未经过 Fuchsia 项目的测试，也无法保证能正常运行，但在实验性层级硬件上为 Fuchsia 进行开发的会员可以提交补丁来添加新的实验性硬件或修复现有的实验性硬件。添加新的实验性硬件或更改现有实验性硬件的 Gerrit 更改不得破坏受支持的硬件，也不得在 Zircon 或其他 Fuchsia 项目代码中引入外部代码依赖项。

面向“实验性硬件”类别的硬件开发者只需遵守基本规范。

硬件平台摘要

下表总结了 Fuchsia 的硬件规格类别，以及与“受支持的硬件”和“实验性硬件平台”相关的可用性和测试预期。

向 Fuchsia 源代码添加硬件平台

本部分详细介绍了向 Fuchsia 源代码添加新硬件的流程，以及向 Fuchsia 源代码添加硬件所需承担的相关责任。Fuchsia 项目接受 Gerrit 对“受支持的硬件”和“实验性硬件平台”类别的贡献。

了解贡献准则

Fuchsia 项目鼓励对“受支持”和“实验性”硬件类别做出贡献，但有一个基本前提，即硬件贡献不能破坏受支持的硬件。任何破坏受支持硬件的贡献都不会合并到 Fuchsia 源代码中。

我们鼓励提交修复 Fuchsia 中会阻止实验性硬件的 bug 的更改，并按照提交更改中所述的典型代码审核流程进行审核。不过，如果任何提议的更改会给 Fuchsia 项目中的受支持硬件带来大量新的测试、维护或支持负担，则可能会被拒绝。

贡献流程

向 Fuchsia 源代码添加硬件平台的过程因您要添加的架构、开发板或驱动程序而异。

实验性贡献

处理器架构

没有项目支持的方法可以添加实验性处理器架构。

开发板和驱动程序

如需添加实验性开发板或驱动程序，请使用 Fuchsia 的代码审核流程，并确保您的 Gerrit 更改符合评分标准。

代码管理

在 Gerrit 更改中，请务必在适当的位置创建文件夹。例如，如需添加看板，请在 /src/devices/boards/drivers 中新建一个文件夹。在 Gerrit 更改中添加 OWNERS 文件，其中列出了开发板或驱动程序的每个所有者的电子邮件地址。如需详细了解所有者的责任，请参阅责任。

职责

除了列出的与非硬件相关代码的所有者的责任之外，开发板和驱动程序所有者还必须遵守以下服务等级目标 (SLO)：

• 代码审核服务等级目标 (SLO)：在 3 个日历日内回复对其所拥有的代码库的代码审核请求。代码库的 OWNERS 文件中列出的任何人都可以执行代码审核。
  • 如果未遵守此 SLO，可能会导致以下任一情况：
    • 执行审核的 Fuchsia 项目的任何成员。
    • 从构建系统中暂时停用开发板或驱动程序。
• 重构 SLO：在 5 个日历日内实现推进驱动程序 SDK 所需的重构。如果重构过于复杂，无法在 5 天内完成，Fuchsia 项目可以在重构请求中定义延长期限。重构请求将通过电子邮件发送到相应 OWNERS 文件中列出的地址。
  • 为了推进 Fuchsia 框架，所需的重构可以由 Fuchsia 项目的成员进行审核，而无需特定开发板或驱动程序代码库的所有者进行审核。我们建议在 Gerrit 中对实现此类重构的更改抄送 OWNERS，但这并非强制性要求。如需详细了解 Gerrit 中的 CC 属性，请参阅 Gerrit 文档中的更改属性。
    • 重构包括但不限于：
      • FDF、驱动程序 FIDL [fuchsia.hardware.\*] 和 Banjo 接口、系统调用
    • 如果不符合 SLO，可能会导致开发板或驱动程序在构建系统中被暂时停用。

已停用的开发板和驱动程序

在导致板级和驱动程序被暂时停用的重构或审核解决/完成后，您可以重新启用这些板级和驱动程序。

如果出现 3 次不符合所列 SLO 的情况，我们可能会从 fuchsia.git 中移除相应开发板和驱动程序。遵守这些 SLO 表明所有者明确承诺支持其代码库中的代码。如果您想就从 fuchsia.git 中移除您的驱动程序提出异议，则必须通过 Fuchsia RFC 流程与 Fuchsia 工程委员会协商。

已删除的驱动程序

对于根据此政策移除的驱动程序，/docs/reference/hardware/_driver_epitaphs.yaml 文件将列出所有已删除的驱动程序，并包含以下信息：

• Short_description:提供已删除驱动程序的说明。
• Tracking_bug：一个问题跟踪器问题，用于说明驱动程序被删除的原因。
• Gerrit_change_id:用于删除驱动程序的 Gerrit 更改的 ID。
• Available_in_git:上次已知的仍包含驱动程序的 git SHA。
• Path:已删除的驱动程序的路径。

例如：

- short_description: 'Qualcomm Peripheral Image Loading driver'
  tracking_bug: '123456'
  gerrit_change_id: '506858'
  available_in_git: 'f441460db6b70ba38150c3437f42ff3d045d2b71'
  path: '/src/devices/fw/drivers/qcom-pil'

删除驱动程序的过程包括：

1. 获得驾驶者的至少一位所有者的批准。如果所有 OWNER 都已放弃驱动程序且没有回复，则 Fuchsia 树中更高级别的 OWNER 需要批准执行删除操作的 CL。
2. 在 /docs/reference/hardware/_driver_epitaphs.yaml 文件中为每个被删除的驱动程序添加一个条目，包括在删除之前包含该驱动程序的 fuchsia.git 代码库的 git 哈希。

支持的贡献

处理器架构

如需提议向 Fuchsia 源代码添加新架构，请使用 Fuchsia RFC 流程。添加新架构可能会给 Fuchsia 开发带来大量工作，因此需要通过 RFC 流程解决。

通过 RFC 流程添加的任何处理器都归类为“受支持的硬件”。

代码管理

如果您的 RFC 获得批准，您可以创建包含所提架构的 Gerrit 更改，并使用 Fuchsia 的代码审核流程请求代码审核。在 Gerrit 更改中添加 OWNERS 文件，其中列出了架构的每个所有者的电子邮件地址。如需详细了解所有者的责任，请参阅责任。

开发板和驱动程序

如需添加受支持的硬件开发板或驱动程序，请使用 Fuchsia RFC 流程。一个 RFC 中可以包含多个驱动程序。单个 RFC 还可以同时提议开发开发板和驱动程序。

受支持的硬件需要 Google 托管的测试基础架构，这会显著增加资源使用量。为 RFC 批准的受支持硬件分配资源可能需要进行额外的审核，这不在本文档的讨论范围之内。

为之前通过 RFC 流程获得批准的计算机系统的某个部分添加驱动程序不需要新的 RFC；只需通过代码审核流程添加即可。

代码管理

如果您的 RFC 获得批准，您可以创建包含开发板或驱动程序的 Gerrit 更改，并使用 Fuchsia 的代码审核流程请求代码审核。在 Gerrit 更改中，请务必在适当的位置创建文件夹。例如，如需添加看板，请在 /src/devices/boards 中新建一个文件夹。在 Gerrit 更改中，添加一个 OWNERS 文件，其中列出开发板或驱动程序的每个所有者的电子邮件地址。如需详细了解所有者的责任，请参阅责任。

认证

目前，添加新开发板或驱动程序只需遵循上述评分标准即可。

附录

必需的 fastboot 命令

当收到不受支持的 fastboot 命令时，引导加载程序必须可靠地失败（不会挂起或阻止设备运行）。意外命令应成功或可靠地失败。如需详细了解 fastboot，请参阅 fastboot。

需要使用以下标准 fastboot 命令：

• erase <partition>
• 闪存 <分区> <文件>
• getvar <name>
• 重新启动
• 重新启动引导加载程序
• 重新启动恢复
• set_active {a,b}
• boot <file>

必需的 getvar 变量：

• current-slot
• hw-revision
• max-download-size
• 产品
• serialno
• slot-retry-count:a
• slot-retry-count:b
• slot-successful:a
• slot-successful:b
• slot-unbootable:a
• slot-unbootable:b
• 版本
• 全部

以下命令并非必需，但对开发有帮助：

• oem stage-partition <partition> + get_staged