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

RFC-0111：初始 Fuchsia 硬件平台规格
状态已接受
领域
  • 治理
说明

运行 Fuchsia 的硬件平台的初始最低要求、贡献流程和支持标准。
Gerrit 更改
  • 540102
作者
审核人
提交日期（年-月-日）2021-06-07
审核日期（年-月-日）2021-07-21

修改此 RFC

修改 RFC 元数据

总结

此 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 托管的测试。不应将实验性硬件平台视为适合生产环境。相反，Fucsia 项目将实验性硬件视为探索和了解 Fuchsia 的途径。

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

  1. “基本硬件规格”- 是指 Fuchsia 在给定硬件平台上运行时的最低规格。基本硬件规格分为“必需”或“推荐”两类。实验性硬件只需遵循“要求的基础”硬件规格。
  2. “支持的硬件规格”- 这些规格是让硬件平台可能被归类为“受支持的硬件”所需的规格。除了这些规范之外，根据相应的测试要求，此类硬件还必须通过 RFC 流程获得批准。

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

外围设备

“初始 Fuchsia 硬件平台规范”RFC 介绍了基本系统的硬件规范，这些规范可让外围设备与给定平台搭配使用。包括 USB 存储驱动程序和显卡驱动程序（包括永久连接和可移除的显卡）。

除了可通过运行紫红色的系统直接观察到的互动之外，“初始 Fuchsia 硬件平台规格”未涵盖外部外围设备的操作细节。例如，以下各项中固件的操作详情不涵盖在内：

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

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

文档定义

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

术语 定义
架构 x86 或 ARM 等处理器架构。
系统 具有 CPU、内存、外围设备等的完整计算机硬件平台。通常也称为“开发板”。
硬件平台 系统芯片 (SoC)（例如基于 ARM 的 SoC）或中央处理器 (CPU) 和芯片组的组合（例如许多基于 x86 的系统）。
SoC 系统芯片；通常由处理器（通常作为计算机系统的核心）组成，并在同一芯片内集成了外围设备。通常具有多个 CPU 核心。
CPU 中央处理器。
更改 Fuchsia 项目使用 Gerrit 基于网络的界面来管理代码和文档的审核。当提交上传到 Gerrit 时，我们称之为更改。请注意，底层修订版本控制系统是 git。
Fuchsia 项目托管的测试 通过 Fuchsia 项目构建和集成流程进行的测试。
CI/CQ 持续集成 / 提交队列：此类系统用于在集成到主源代码树之前构建建议的更改，并持续测试整个源代码，以发现多项集成更改相互作用导致的回归问题。

基本硬件规格

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

基本规范 定义
必需 如果没有此规范，Fucsia 将无法在给定的硬件平台上进行构建和安装。
推荐 此规范非常可取，但 Fuchsia 在给定硬件平台上构建和安装时并不需要此规范。如果没有此规范， Fuchsia 的功能或性能会受到影响。

必需的硬件功能

以下是必须提供的硬件规格。

规格要求

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

必需：64 位 CPU 和平台

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

理由

为了高效且有效地实现地址空间布局随机化 (ASLR) 等功能，系统需要一个具有足够空间的 64 位地址空间。

示例

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

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

理由

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 的 netstack 使用 Go。

建议采用以下硬件规格。

虽然以下规范不是构建和安装 Fuchsia 的必要条件，但以下规范是对基本规范的补充，非常可取，因为它们可以改进 Fuchsia 在给定硬件平台上的功能。

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

Fuchsia 项目建议硬件平台支持硬件 I/O 内存管理单元。如果没有通过 IOMMU 授予的明确权限，IOM 必须能够对从系统中可唯一标识的硬件单元发起的 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”Atoms 及更高版本）
  • AES-NI：AMD（“Bulldozer”及更高版本；“Jaguar”及更高版本）
  • SHA(1, 256)：Intel（“Ice Lake”及更高版本；“Goldmont Plus”Atoms 及更高版本）
  • SHA(1, 256)：AMD（“Zen”及更高版本）
  • CRC32（支持 SSE 4.2 的处理器）

建议采用以下工具链和语言支持规范，但这并非强制性要求。

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

理由

创建第二个工具链可发现更多 bug。

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

Fuchsia 项目建议为任何给定架构、平台和目标板提供第 1 层级 Rust 支持。

理由

Fuchsia 广泛使用 Rust。如需详细了解第 1 层级支持带来的好处，请参阅第 1 层级目标政策。

支持的硬件规格

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

支持的硬件规格可进一步分为两类：必需和推荐。

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

支持的硬件规范 定义
必需 如果没有此规范，该硬件平台将无法归类为“受支持的硬件”。
推荐 我们非常希望使用该规范，但对于支持的硬件分类而言，该规范并非硬性要求。如果没有此规范， Fuchsia 的功能或性能会受到影响。

规格要求

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

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

最后一阶段的引导加载程序（即加载 Fuchsia 内核的启动过程中的软件组件）必须遵循以下要求：

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

引导加载程序无需拥有与 Fuchsia 兼容的许可。在启动过程中，引导加载程序之前的早期阶段不需要是开源的，但如果可以的话，强烈建议您这样做。另请参阅关于文档和支持的要求。

强烈建议您在开源环境中开发源代码，源代码项目所有者接受集成 bug 报告和外部更改，并且为项目提供持续支持。

理由

您可以修改开源引导加载程序，使其直接支持加载 Fuchsia（而不是使用 boot 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 许可不兼容，则使用现有源代码可能会造成意外复制代码的风险。

Fuchsia 项目建议引导加载程序支持附录中列出的一组 fastboot 协议命令。 Fuchsia 项目建议在非专有传输上运行 fastboot。

理由

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

Fuchsia 项目建议平台和引导加载程序提供全面的虚拟化支持。

Intel x86

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

  • VMX
  • 电子时间
  • 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 贡献者角色定义的成员可以提出补丁，以添加新的受支持硬件平台或修复现有的受支持硬件平台。

实验性硬件

不应将实验性硬件平台视为适合生产环境。相反，Fucsia 项目将实验性硬件视为探索和了解 Fuchsia 的途径。实验性硬件是系统尽最大努力构建的，也就是说，Fuchsia 在任意给定时间都不一定能在特定硬件平台上运行。

实验性硬件未经过 Fuchsia 项目测试，也不保证能够正常运行，但针对实验性层级硬件为 Fuchsia 开发的成员可以提出补丁，以添加新的实验性硬件，或修复现有的实验性硬件。如果 Gerrit 更改会添加新的实验性硬件或更改现有的实验性硬件，则相应更改可能不会破坏受支持的硬件，也不会在 Zircon 或其他 Fuchsia 项目代码中引入外部代码依赖项。

针对实验性硬件类别的硬件开发的成员只需遵循基本规范。

硬件平台摘要

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

硬件平台类别

功能 接受贡献 可用性预期

测试预期 必需规范 建议的规范
支持的硬件
  • 开发者可以在受支持的硬件上构建和安装 Fuchsia。
  • 此硬件可能不依赖于任何外部代码。
 可以，前提是这些贡献不会破坏支持的硬件，也不会在 Zircon 或其他非实验性代码中引入实验性代码依赖项。
  • Fuchsia 项目针对受支持的硬件进行测试，并阻止可能导致受支持硬件损坏的贡献内容。
  • 针对“受支持硬件层级”中的硬件提交的问题跟踪器问题会得到回复，但没有服务等级目标 (SLO)。
  • Fuchsia 项目托管的测试在受支持的硬件上执行。所有贡献者都可以查看这些测试的结果。
 所有要求的基本硬件规格，其中包括： 和所有必需的受支持硬件规格 所有建议支持的规范
实验性硬件
  • 开发者可以在实验性硬件上构建和安装 Fuchsia。
  • 任何外部贡献者都可能会提议添加补丁，以添加新的实验性硬件平台，但变更可能不会破坏受支持的硬件，也不会在 Zircon 或其他通用代码中引入实验性代码依赖项。
 可以，前提是这些贡献不会破坏支持的硬件，也不会在 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 天的 SLO 来说过于复杂，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 Engineering Council 商讨。

已删除的驱动程序

对于根据此政策移除的驱动程序，/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. 获得驾驶员至少一位所有者的批准。如果所有所有者都放弃了该驱动程序，并且没有响应，则紫红色树中更高层级的所有者需要批准执行删除的 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 命令：

  • 擦除 <分区>
  • 刷写 <分区> <文件>
  • getvar <名称>
  • 重新启动
  • 重新启动引导加载程序
  • 重新启动 recovery
  • set_active {a,b}
  • boot <file>

必需的 getvar 变量：

  • 当前槽位
  • hw-revision
  • 下载大小上限
  • 产品
  • Serialno
  • slot-retry-count:a
  • slot-retry-count:b
  • 槽成功：a
  • 槽成功：b
  • slot-unbootable:a
  • slot-unbootable:b
  • version
  • 全部

以下命令是可选的，但可能有助于开发：

  • oemstage-partition <分区> + get_staged