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

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

硬件平台运行 Fuchsia 的一系列初始最低要求、贡献流程和支持标准。
Gerrit 更改
作者
审核人
提交日期（年-月-日）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 托管的测试。 实验性硬件平台不应被视为适合 生产环境相反， Fuchsia 项目将实验性 作为探索和了解 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 内核启动之前的前期启动期间使用。

理由

需要 64 位地址空间有足够的空间 可有效实现地址空间布局等功能 随机化 (ASLR)。

示例

所有 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 工具链支持 指定的平台必须保持最新状态如需详细了解这些目标 请参阅 CMakeLists.txt LLVM 项目中的资源。

理由

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

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

相关的架构、平台和目标板必须至少 在 Rust 第 2 层级中 ，最好是 。

理由

Fuchsia 广泛使用了 Rust。

必需：Dart 语言支持

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

理由

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

必需：Go 语言支持

相关架构、平台和目标开发板必须由 前往。

理由

Fuchsia 的 netstack 使用 Go。

建议使用以下硬件规格。

以下规范并不是构建和安装 Fuchsia 的必要条件 是非常理想的基本规格补充剂，因为它们可以 Fuchsia 在指定硬件平台上的功能。

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

Fuchsia 项目建议让硬件平台支持 I/O 内存管理单元。IOMMU 必须能够进行 NAK 读取或写入 从系统中可唯一标识的硬件单元发起的事务 。

（可选）IOMU 还可以包括以下实用功能：

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

Zircon 驱动程序是用户模式软件组件，其硬件非常有限 访问权限。IOMMU 可防范来自具有以下访问权限的设备的错误或攻击： 物理内存，而且比审核硬件和软件更可靠。 这提高了 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。如需详细了解 Tier 1 支持，请参阅 Tier 1 Target Policy。

支持的硬件规格

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

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

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

支持的硬件规格 定义
必需 如果没有此规范，系统就无法对该硬件平台进行分类 作为支持的硬件
推荐 此规范非常可取，但对于 支持的硬件分类。如果没有此规范，Fucsia 的 功能或性能都会受到影响

要求的规格

除了基本规范之外， 支持的硬件还必须遵循以下规范， 属于受支持的硬件支持层级。

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

最后一个阶段的引导加载程序，这是启动过程的软件组件 必须满足以下要求：

  • 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，并且 接收

DMA 支持是一项很实用的功能，不过不一定非要使用 DMA。

理由

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

虽然支持的硬件层级不要求提供以下规格， 是对“必需支持”规范的有益补充。

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

  • 注册地图
  • 运行理论
  • 有关启动时硬件状态的信息

仅使用 Linux 或 Android 开源分支进行记录的开发板 不接受此项目。平台供应商必须愿意回答 当面或通过电子邮件提出问题。

理由

如果没有准确的文档，编写驱动程序和调试工作将缩减至 对现有软件进行逆向工程，该软件容易出错且运行缓慢。使用 与许可不兼容的文档的现有源代码 Fuchsia 的许可可能存在无意中复制代码的风险。

Fuchsia 项目建议引导加载程序支持一系列 fastboot 请参阅附录中列出的所有协议命令。 Fuchsia 项目建议在非专有机上发生 fastboot 传输。

理由

统一支持 fastboot 可让您更轻松地使用 并协助自动化 虚拟机

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

Intel x86

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

  • VMX
  • EPT
  • RDTSCP
  • 2APIC
  • VPID
  • 不受限制的邀请对象
  • TPR 虚拟化
  • MSR 位图
  • 异常位图

（可选）Fuchsia 项目建议：

  • INVPCID
  • 暂停循环退出
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 开发应用的会员 可以提议补丁 添加新的实验性硬件或修复现有的实验性硬件。 会添加新的实验性硬件或更改现有实验性设备的 Gerrit 变更 硬件不得损坏支持的硬件或引入外部代码 Zircon 或其他 Fuchsia 项目代码中的依赖项。

仅限开发实验性硬件类别的硬件的成员 需符合基本规范。

硬件平台摘要

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

硬件平台类别

功能 接受投稿 可用性预期

测试预期 必要规范 推荐规格
支持的硬件
  • 开发者可以在受支持的硬件上构建和安装 Fuchsia。
  • 此硬件不得依赖于任何外部代码。
 可以，但前提是这些贡献不破坏受支持的硬件或 在 Zircon 或其他 非实验性代码。
  • Fuchsia 项目针对支持的硬件和块进行测试 可能会导致受支持硬件损坏的贡献
  • 针对受支持硬件层级中的硬件提交的问题跟踪器问题包括 但没有服务等级目标 (SLO)。
  • 在受支持的硬件上执行 Fuchsia 项目托管测试。全部 贡献者可以看到这些测试的结果。
 所有必需的基本硬件规格，其中包括： <ph type="x-smartling-placeholder">和 所有必需的支持硬件规格 所有推荐支持的规格
实验性硬件
  • 开发者可以在 Experimental 中构建和安装 Fuchsia 硬件。
  • 任何外部贡献者都可以提议补丁以添加新的实验性版本 更改可能会破坏支持的硬件， Zircon 或其他通用代码中的实验性代码依赖项。
 可以，但前提是这些贡献不破坏受支持的硬件或 在 Zircon 或其他非实验性代码中引入实验性代码依赖项。
  • 实验性硬件是系统尽最大努力构建的，不一定 在任何给定时间点都有效。
  • 任何可能会破坏受支持硬件的实验性贡献 已被拒绝。
  • 没有为实验性版本完成 Fuchsia 项目托管的硬件专用测试 提交和合并任何 Fuchsia 所需的超出标准测试范围的硬件 commit。
 所有必需的基本硬件规格 其中包括： <ph type="x-smartling-placeholder"> 所有推荐的基本硬件规格，其中包括： <ph type="x-smartling-placeholder">

向 Fuchsia 源代码添加硬件平台

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

了解贡献准则

Fuchsia 项目鼓励用户为“受支持”和“实验性”做出贡献 并且了解了硬件 贡献的内容不会破坏支持的硬件。任何违反规则的贡献 受支持的硬件不会合并到 Fuchsia 源代码中。

进行了相应更改，修复了 Fuchsia 中会妨碍实验性功能的错误 鼓励硬件，并通过常规的代码审核流程 描述 贡献更改部分。不过，如果更改 将给客户带来巨大的新测试、维护或支持负担 Fuchsia 项目中支持的硬件。

贡献过程

向 Fuchsia 源程序添加硬件平台的过程各不相同 具体取决于您要添加架构、开发板还是驱动程序。

实验性贡献

处理器架构

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

开发板和驱动程序

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

代码管理

在 Gerrit 更改中，请务必在适当的位置创建一个文件夹。 例如，如需添加面板，请创建一个新文件夹 在 /src/devices/boards/drivers 中。在您的 Gerrit 更改中添加一个 OWNERS 文件 指明了董事会或驱动程序中每位所有者的电子邮件地址。有关 有关 OWNERS 的信息请参阅责任。

职责

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

  • 代码审核 SLO：回复其代码库的代码审核请求 在 3 个日历日内拥有所有权。代码库的 OWNERS 文件中列出的任何人都可以 执行代码审核
    • 不遵守此 SLO 可能会导致以下任何一种情况 场景： <ph type="x-smartling-placeholder">
        </ph>
      • 执行审核的 Fuchsia 项目的任何成员。
      • 在 build 中暂时禁用开发板或驱动程序 系统。
  • 重构 SLO：实现推进驱动程序 SDK 所需的重构 。如果重构对于 5 天的 SLO 来说过于复杂， 延长期限可以在 Fuchsia 项目的重构请求中定义。 重构请求将通过电子邮件发送到 相应的 OWNERS 文件。
    • 推进 Fuchsia 框架所需的重构可能由 但并不期望获得 特定主板或驱动程序存储库就 Gerrit 更改抄送 OWNERS 建议实现这些类型的重构 必填字段。如需详细了解 Gerrit 中的 CC 属性，请参阅 更改属性 。
      • 重构包括但不限于以下内容： <ph type="x-smartling-placeholder">
          </ph>
        • FDF、 驱动程序 FIDL [fuchsia.hardware.\*] 和 Banjo 接口、系统调用
      • 不遵守 SLO 可能会导致账号被暂时停用 主板或驱动程序的位置
。
已停用的开发板和驱动程序

已暂时停用的开发板和驱动程序可以重新启用 导致停用的重构或审核 已解决/已完成。

如果有 3 个实例，板级和驱动程序可能会从“fuchsia.git”中移除 列出的 SLO 非常有用遵守这些 SLO 表明所有者明确承诺支持 自己的代码库中如果您想对移除您的 来自fuchsia.git的司机，您必须与 通过 Fuchsia RFC 流程。

已删除的驱动程序

对于根据此政策移除的驱动程序，系统将创建一个 /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 树需要批准执行删除操作的 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”文件，以说明 董事会或司机的每一位所有者关于“OWNERS”的详细信息 请参阅责任。

认证

目前，添加新开发板或驱动程序只需遵守 。

附录

必需的 fastboot 命令

如果收到不支持的 fastboot 命令，引导加载程序必须可靠地失败 （不要挂起或阻止设备工作）。意外的命令应该 无论成功还是失败如需详细了解 fastboot，请参阅 fastboot。

必须提供以下标准 fastboot 命令：

  • 清空 <分区>
  • 刷写 <分区>&lt;file&gt;
  • getvar <名称>
  • 重新启动
  • 重新启动引导加载程序
  • 重新启动 recovery
  • set_active {a,b}
  • 启动 <文件>

必需的 getvar 变量：

  • 当前槽位
  • hw-revision
  • max-download-size
  • 产品
  • 序列号
  • slot-retry-count:a
  • slot-retry-count:b
  • slot-successful:a
  • 槽成功:b
  • slot-unbootable:a
  • slot-unbootable:b
  • 版本
  • 全部

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

  • oem 阶段分区 <分区>+ get_staged