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 源代码树库之外的设备驱动程序。开发者可以使用驱动程序 SDK 编写驱动程序，并在 Fuchsia 开源项目代码库之外分发源代码和二进制文件。

硬件平台类别

Fuchsia 项目在其上执行 Fuchsia 项目托管测试的硬件平台归类为受支持的硬件。实验性硬件满足硬件平台与运行 Fuchsia 兼容的最低要求，但未执行任何 Fuchsia 托管的测试。实验性硬件平台不应被视为适合生产环境。相反，Fuchsia 项目将实验性硬件视为探索和了解 Fuchsia 的途径。

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

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

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

外围设备

“初始 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 Tier 2，最好处于 Rust Tier 1。

理由

Fuchsia 大量使用 Rust。

必需：Dart 语言支持

所涉及的架构、平台和目标板必须受 Dart 支持。

理由

Fuchsia 的大部分界面都是使用 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（“推土机”及更高版本；“美洲豹”及更高版本）
• 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，而不是使用启动 shim。专有 blob 很难进行调试或安全审核。早期启动过程的某些部分通常不以开源形式提供，因此无法实际替换为开源版本；例如，ARM 可信执行环境的供应商专有版本，或 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 项目建议在非专有传输上进行 fastboot。

理由

统一支持 fastboot 可让您更轻松地使用不同的硬件平台，并在处理多台机器组成的机群时提供自动化方面的帮助。

建议：虚拟化支持

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

Intel x86

在 Fuchsia 项目中，需要以下内容才能完全支持 Intel x86 CPU 上的虚拟化：

• VMX
• EPT
• RDTSCP
• x2APIC
• VPID
• 不受限制的访客
• TPR 虚拟化
• MSR 位图
• 例外情况位图

（可选）Fuchsia 项目建议：

• INVPCID
• PAUSE-loop exiting

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 文件，其中包含每个主板或驱动程序所有者的电子邮件地址。如需详细了解所有者的责任，请参阅责任。

职责

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

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

已停用的板卡和驱动程序

暂时停用的主板和驱动程序在促使停用的重构或审核问题得到解决/完成之后，可以重新启用。

如果出现 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. 获得至少一位驱动程序所有者的批准。如果所有 OWNERS 都已放弃该驱动程序且不响应，则 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 命令是必需的：

• 擦除 <partition>
• flash <分区> <文件>
• getvar <name>
• 重新启动
• 重新启动到引导加载程序
• 重新启动恢复
• set_active {a,b}
• 启动 <文件>

必需的 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