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 初始硬體平台規格」政策不涵蓋由外部貢獻者使用 Driver SDK 編寫，且託管於任何 Fuchsia 來源樹狀結構存放區外的裝置驅動程式。開發人員可以使用 Driver SDK 編寫驅動程式，並在 Fuchsia 開放原始碼專案存放區外發布來源和二進位檔。

硬體平台類別

Fuchsia 專案執行 Fuchsia 專案主機測試的硬體平台，會歸類為「支援」硬體。實驗性 硬體符合硬體平台的最低需求，可與 Fuchsia 相容，但不會執行 Fuchsia 主機測試。 實驗性硬體平台不適合用於生產環境。Fuchsia 專案會將實驗性硬體視為探索和瞭解 Fuchsia 的途徑。

本文定義 Fuchsia 相容硬體平台 (具體來說是以下平台) 的硬體規格：

1. 「基本硬體規格」：這是 Fuchsia 在特定硬體平台上執行的最低規格。基本硬體規格分為「必要」或「建議」兩類。實驗性硬體只需符合必要的基本硬體規格。
2. 「支援的硬體規格」：這些是硬體平台可能歸類為支援硬體時的必要規格。除了這些規格外，由於測試要求，這類別的硬體也必須透過 RFC 程序核准。

這份文件也定義了支援硬體和實驗性硬體的可用性期望。最後，這份文件定義了將硬體平台新增至 Fuchsia 來源的程序。

周邊裝置

「Initial Fuchsia hardware platform specifications」RFC 涵蓋基本系統的硬體規格，可讓周邊裝置與特定平台搭配運作。包括 USB 儲存裝置驅動程式和顯示卡驅動程式 (包括永久連接和可拆卸的顯示卡)。

「Initial Fuchsia hardware platform specifications」(初始 Fuchsia 硬體平台規格) 並未涵蓋外部周邊裝置運作的詳細資料，僅限於 Fuchsia 系統直接觀察到的互動。舉例來說，以下裝置的韌體運作詳細資料不在探討範圍內：

• 機器學習 (ML) 加速器
• 音訊硬體數位訊號處理器 (DSP)
• 顯示卡內部 (並非允許與主要系統通訊的驅動程式庫)。

「Fuchsia 初始硬體平台規格」政策也不涵蓋非最終階段的啟動載入程式。

文件定義

本文件使用下列術語：

基本硬體規格

以下是 Fuchsia 的基本硬體規格。 基本規格又可細分為兩類：必要和建議。

必要硬體功能

必須符合下列硬體規格。

必要規格

必要規格是指 Fuchsia 在特定硬體平台上建構及安裝的基本技術需求。

必要條件：64 位元 CPU 和平台

硬體平台 CPU 必須支援 64 位元位址空間作業模式。 只要平台或 CPU 僅在 Zircon 核心啟動前的早期啟動期間使用，以非 64 位元模式啟動是可以接受的。

Rationale

需要 64 位元位址空間，且空間充足，才能有效率地實作位址空間配置隨機載入 (ASLR) 等功能。

範例

所有 x86-64 硬體平台；所有 ARMv8-A 和後續處理器 (A32 除外)。

必要條件：全功能記憶體管理單元 (MMU)

硬體平台必須提供功能齊全的現代記憶體管理單元，允許建立任意數量的位址空間、將合理大小的頁面中的實體記憶體對應至任何這些空間，以及透過硬體存取控制機制，在個別位址空間之間強制執行保護措施。

Rationale

Fuchsia 大量使用虛擬記憶體物件，因此有效率的記憶體管理機制對 Fuchsia 硬體平台的運作至關重要。如果沒有硬體強制執行的記憶體存取控制，Fuchsia 就無法提供基本安全保障。

範例

ARM v8.0-A 以上版本；所有新型 x86 CPU (2010 年以後)。

必要條件：小端序模式

硬體平台必須支援小端序 (LE) 位元組排序模式。

Rationale

在程式碼開發和測試期間，處理任意位元組順序的成本很高。理論上，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。

Rationale

設定最低 ISA 目標可進行實用的最佳化作業，前提是假設存在特定指令。完整詳細資料請參閱 RFC-0073：將 x86-64 平台需求提升至 x86-64-v2。

必要：時鐘和計時器

時鐘和計時器必須符合以下條件：

• 保持不變，這樣系統其他部分進行頻率調整時，它們就不會任意變更頻率。
• 寬度至少為 56 位元，且溢位時間不得少於 40 年。
• 具有名義頻率，可明確得知，無須任何執行階段校準。

必要工具鍊和語言支援

您必須符合下列工具鍊和語言支援規格。

必要條件：支援 LLVM 工具鍊

有問題的架構、平台和目標板必須由上游 LLVM 完全支援，且位於 LLVM 核心層級。特定平台的 Clang 工具鍊支援必須維持最新狀態。如要進一步瞭解 LLVM 支援的目標，請參閱 LLVM 專案中的 CMakeLists.txt。

Rationale

Fuchsia 使用 LLVM 做為預設的編譯工具鍊。

必要條件：第 2 層 Rust 語言支援

有問題的架構、平台和目標板必須至少位於 Rust 層級 2，最好位於 Rust 層級 1。

Rationale

Fuchsia 大量使用 Rust。

必要條件：支援 Dart 語言

有問題的架構、平台和目標開發板必須支援 Dart。

Rationale

Fuchsia 的使用者介面大多是使用 Flutter 建構而成，而 Flutter 採用的是 Dart。

必要條件：支援 Go 語言

有問題的架構、平台和目標開發板必須支援 Go。

Rationale

Fuchsia 的 netstack 使用 Go。

建議的硬體功能

建議採用下列硬體規格。

建議規格

雖然建構及安裝 Fuchsia 時不一定要符合下列規格，但這些規格可大幅提升特定硬體平台上的 Fuchsia 功能，因此建議您盡量滿足這些規格。

建議：時鐘和計時器

• 計時器，可在計時器值超過指定絕對門檻時，將中斷傳送至核心。
• 實作時應做為架構本身的一部分，而非目標層中存在的周邊裝置。

建議：I/O 記憶體管理單元 (IOMMU)

Fuchsia 專案建議硬體平台支援硬體 I/O 記憶體管理單元。如果沒有透過 IOMMU 授予明確權限，IOMMU 必須能夠 NAK 讀取或寫入系統中可唯一識別的硬體單元所啟動的交易。

視需求而定，IOMMU 也可以包含下列實用功能：

• 能夠為硬體 DMA 作業執行位址轉譯 (這可讓 Fuchsia 專案將釘選但中斷的實體記憶體用於硬體 DMA)。
• 能夠偵測及偵錯 IOMMU 頁面錯誤情況 (例如，如果單元超出界限，最好能取得例外狀況，以及一些背景資訊，例如哪個單元在哪個位置嘗試執行哪項作業)。

Rationale

Zircon 驅動程式是使用者模式軟體元件，硬體存取權非常有限。IOMMU 可防範來自可存取實體記憶體的裝置的錯誤或攻擊，且比稽核硬體和軟體更可靠。這項措施可提升 Fuchsia 作業系統的整體安全性。

範例

ARM 的 IOMMU 規格：系統記憶體管理單元 (SMMU)

Intel 的 x86 IOMMU 規格：Intel VT-d、AMD-Vi

建議：支援硬體加密加速

Fuchsia 專案建議硬體平台為 AES 和 SHA 密碼編譯作業提供硬體加速功能。

Rationale

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 即可。

Rationale

使用第二個工具鍊可找出更多錯誤。

建議：第 1 層 Rust 語言支援

Fuchsia 專案建議針對任何架構、平台和目標開發板，提供 Tier 1 Rust 支援。

Rationale

Fuchsia 大量使用 Rust，如要進一步瞭解第 1 層支援的優點，請參閱第 1 層目標政策。

支援的硬體規格

以下是支援的硬體規格。Fuchsia 計畫主辦的測試會在支援的硬體上執行，這是 Fuchsia 持續整合與測試程序的一部分。Fuchsia 專案主機測試會在支援的硬體上執行，外部貢獻者可以查看結果。支援的硬體包括 Intel NUC 和 VIM3。如要進一步瞭解支援硬體的支援服務期望，請參閱「規格摘要」。

支援的硬體規格進一步分為兩類：必要和建議。

如要進一步瞭解必要和建議規格，請參閱下表：

必要規格

除了基本規格外，支援的硬體也必須符合下列規格，才能納入「支援的硬體」支援層級。

必要條件：系統啟動載入程式開放性

最終階段的開機載入程式是開機程序的軟體元件，負責載入 Fuchsia 核心，必須遵守下列規定：

• Fuchsia 專案必須能夠變更系統啟動載入程式。
• Fuchsia 專案必須能夠建構開機載入程式。
• Fuchsia 專案必須能夠發布來源和二進位檔，這些檔案是 Fuchsia 專案對開機載入程式所做的任何變更所產生。

開機載入程式不必具備 Fuchsia 相容授權。系統啟動載入程式之前的啟動程序階段不需要開放原始碼，但如果可以，我們強烈建議您這麼做。另請參閱文件和支援服務的規定。

我們非常希望來源以開放形式開發，來源專案擁有者接受錯誤報告，並整合外部變更，且持續為專案提供支援。

Rationale

您可以修改開放原始碼開機載入程式，直接支援載入 Fuchsia，不必使用開機墊片。專屬 Blob 難以偵錯或稽核安全性。早期啟動程序的部分內容通常不屬於開放原始碼，因此無法以開放版本取代，例如 ARM 信任執行環境的供應商專屬版本，或是 x86 平台上的統一可延伸韌體介面 (UEFI) 實作項目。

範例

coreboot、U-boot。

必要條件：架構必須支援 QEMU

架構必須支援最新版 Fuchsia 專案 QEMU。建議但不必要：

• 支援特定平台。
• 此架構可在 QEMU 下虛擬化。
• QEMU 必須能在架構相同的 QEMU 主機上執行 (也就是在 x86 主機上執行 QEMU-kvm x86，或在 arm64 主機上執行 QEMU-kvm arm64)。

如果架構有目標模式 (例如 ARM Trustzone)，QEMU 應能模擬這些模式。

Rationale

為了提供可擴充的硬體支援，以利建構及測試，QEMU 用於持續整合。如果目標架構沒有 QEMU 支援，就無法以可擴充的方式建構或測試程式碼。

必要條件：序列主控台存取權

硬體平台必須支援某種形式的序列控制台存取權，以供開發用途。交付給使用者的正式版系統不一定要有這項功能。序列控制台必須支援中斷驅動的 TX 和 RX。

DMA 支援功能很實用，但使用 DMA 不得為必要條件。

Rationale

在早期平台開發期間，最可靠的開發和偵錯方式就是使用簡單的序列埠控制台。

建議規格

雖然「支援的硬體」層級並非必要，但下列規格是「必要支援規格」的理想補充。

建議：說明文件和支援

平台應提供合理的公開文件，包括：

• 註冊地圖
• 運作原理
• 啟動時間硬體狀態的相關資訊

如果主機板僅使用 Linux 或 Android 開放原始碼計畫的分支版本記錄，則不符合資格。平台供應商必須願意親自或透過電子郵件回答問題。

Rationale

如果沒有準確的文件，撰寫驅動程式和偵錯就會變成對現有軟體進行反向工程，這不僅容易出錯，而且速度緩慢。如果文件使用的現有原始碼授權與 Fuchsia 的授權不相容，可能會導致程式碼在無意間遭到複製。

建議：支援 Fastboot 的開機載入程式

Fuchsia 專案建議開機載入程式支援附錄中列出的 fastboot 通訊協定指令集。Fuchsia 專案建議在非專有傳輸上執行 Fastboot。

Rationale

統一支援 Fastboot 可簡化不同硬體平台的工作，並在處理多部電腦時協助自動化作業。

建議：支援虛擬化

Fuchsia 專案建議平台和開機載入程式支援完整虛擬化。

Intel x86

在 Fuchsia 專案中，如要完整支援 Intel x86 CPU 的虛擬化功能，需要下列項目：

• VMX
• EPT
• RDTSCP
• x2APIC
• VPID
• 不受限制的訪客
• TPR 虛擬化
• MSR 點陣圖
• 例外狀況點陣圖

Fuchsia 專案建議使用下列選用項目：

• INVPCID
• PAUSE 迴圈即將結束

啟動

在 Fuchsia 專案中，如要全面支援 ARM 上的虛擬化，需要下列項目：

• ARMv8.0
• EL2 存取權
• 主辦人實體計時器 / 來賓虛擬計時器分割畫面
• GICv2 或 GICv3
• GIC 虛擬化

Rationale

虛擬化技術的用途十分廣泛，舉例來說，在 ARM64 上，如果 Zircon 在 EL2 執行，EL1/EL0 就能虛擬化，進而提升隔離效果。

範例

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

建議：硬體輔助追蹤

硬體平台應支援某種形式的硬體控制流程追蹤。

Rationale

低成本追蹤功能可讓您更輕鬆地對發布版本執行自動化回饋導向最佳化 (AutoFDO)。

範例

ARM：CoreSight ETM；x86：Intel 最後分支記錄 (LBR)。

硬體平台類別

Fuchsia 專案將 Fuchsia 相容硬體平台分為兩類：支援和實驗。Fuchsia 的硬體規格會因類別而異。支援和實驗性硬體都必須符合基本規格。雖然並非必要，但 Fuchsia 計畫鼓勵「支援」和「實驗」硬體遵守各自的「建議」規格，如硬體平台摘要中所列。

如要查看「支援」和「實驗」硬體之間的差異摘要，請參閱「硬體平台摘要」。

支援的硬體

支援的硬體具有下列優點：

• Fuchsia 專案會測試支援的硬體。
• 實驗版硬體貢獻內容不會導致支援的硬體故障。
• Fuchsia 專案致力於回應針對支援的硬體提出的 Issue Tracker 問題。成員 (如 Fuchsia 貢獻者角色中所定義) 可以提議修補程式，新增支援的硬體平台或修正現有支援的硬體平台。

實驗性硬體

實驗性硬體平台不適合用於生產環境。Fuchsia 專案會將實驗性硬體視為探索和瞭解 Fuchsia 的途徑。實驗性硬體是盡力而為的成果，也就是說，在特定時間點，Fuchsia 可能無法在特定硬體平台上運作。

實驗性硬體未經過 Fuchsia 專案測試，因此無法保證能正常運作，但如果成員在實驗性層級硬體上為 Fuchsia 開發，可以提議修補程式，新增實驗性硬體或修正現有實驗性硬體。新增實驗性硬體或變更現有實驗性硬體的 Gerrit 變更，可能不會中斷支援的硬體，也不會在 Zircon 或其他 Fuchsia 專案程式碼中導入外部程式碼依附元件。

如果成員開發的硬體屬於「實驗性硬體」類別，只需遵守基本規格。

硬體平台摘要

下表彙整了 Fuchsia 的硬體規格類別，以及與「支援的硬體」和「實驗性硬體」平台相關的可用性和測試期望。

在 Fuchsia 來源中新增硬體平台

本節將詳細說明如何將新硬體新增至 Fuchsia 來源，以及將硬體新增至 Fuchsia 來源的相關責任。Fuchsia 專案接受 Gerrit 對「支援的硬體」和「實驗性硬體平台」類別的貢獻。

瞭解參與規定

Fuchsia 計畫鼓勵使用者為「支援」和「實驗」硬體類別做出貢獻，但前提是瞭解硬體貢獻內容不得破壞「支援」硬體。任何違反支援硬體的貢獻內容都不會併入 Fuchsia 來源。

我們鼓勵您提交修正 Fuchsia 錯誤的變更，否則實驗性硬體可能會遭到封鎖。這類變更會經過「貢獻變更」一文所述的典型程式碼審查程序。不過，如果提案的變更會為 Fuchsia 專案中支援的硬體帶來大量新的測試、維護或支援負擔，則可能會遭到拒絕。

貢獻程序

將硬體平台新增至 Fuchsia 來源的程序，會因您新增的是架構、開發板或驅動程式而異。

實驗性貢獻

處理器架構

目前沒有專案認可的方法，可新增實驗性處理器架構。

開發板和驅動程式

如要新增實驗性開發板或驅動程式庫，請使用 Fuchsia 的程式碼審查程序，並確保 Gerrit 變更符合評量表。

程式碼管理

在 Gerrit 變更中，請務必在適當位置建立資料夾。 舉例來說，如要新增看板，請在 /src/devices/boards/drivers 中建立新資料夾。在 Gerrit 變更中加入 OWNERS 檔案，說明每個主機板或驅動程式庫擁有者的電子郵件地址。如要進一步瞭解 OWNERS 的責任，請參閱「責任」。

職責

除了列出的非硬體相關程式碼擁有者責任外，主機板和驅動程式庫擁有者也必須遵守下列服務等級目標 (SLO)：

• 程式碼審查服務等級目標：在 3 個日曆天內回覆他們擁有的存放區程式碼審查要求。程式碼審查可由存放區 OWNERS 檔案中列出的任何使用者執行。
  • 如未遵守這項 SLO，可能會導致下列任一情況：
    • 執行審查的 Fuchsia 專案成員。
    • 暫時從建構系統中停用主機板或驅動程式庫。
• 重構 SLO：在 5 個日曆天內實作必要重構，以推進驅動程式庫 SDK。如果重構作業過於複雜，無法在 5 天內完成，Fuchsia 專案可以在重構要求中定義延長期限。重構要求會透過電子郵件傳送至各 OWNERS 檔案中列出的地址。
  • 如要推進 Fuchsia 架構，可能需要重構，這時 Fuchsia 專案成員可以審查，不必等待特定主機板或驅動程式庫存放區的 OWNER 審查。建議在實作這類重構的 Gerrit 變更中，將 OWNERS 設為副本收件者，但這並非必要。如要進一步瞭解 Gerrit 中的 CC 屬性，請參閱 Gerrit 說明文件中的「變更屬性」。
    • 重構包括但不限於下列項目：
      • FDF、驅動程式庫 FIDL、[fuchsia.hardware.\*] 和 Banjo 介面、系統呼叫
    • 如未遵守 SLO，可能會導致建構系統暫時停用開發板或驅動程式庫程式。

已停用的開發板和驅動程式

如果因重構或審查而暫時停用開發板和驅動程式，只要解決/完成重構或審查，即可重新啟用。

如果主機板和驅動程式有 3 個執行個體未遵守所列 SLO，可能會從 fuchsia.git 中移除。遵守這些 SLO 代表 OWNERS 明確承諾支援存放區中的程式碼。如要對從 fuchsia.git 移除驅動程式提出爭議，請透過 Fuchsia RFC 程序與 Fuchsia 工程委員會協商。

已刪除的驅動程式

如果司機因違反這項政策而遭移除，/docs/reference/hardware/_driver_epitaphs.yaml檔案會列出所有遭移除的司機，並包含下列資訊：

• Short_description:提供已刪除的驅動程式庫說明。
• Tracking_bug：Issue Tracker 問題，說明刪除驅動程式庫的原因。
• 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 檔案，其中列出架構中每位擁有者的電子郵件地址。如要進一步瞭解 OWNERS 的責任，請參閱「責任」。

開發板和驅動程式

如要新增支援的硬體板或驅動程式庫，請使用 Fuchsia RFC 程序。一個 RFC 可以包含多個驅動程式。單一 RFC 也可以同時提議主機板和驅動程式庫。

支援的硬體需要 Google 代管測試的基礎架構，這會大幅增加資源用量。資源分配給 RFC 核准的支援硬體可能需要額外審查，這不屬於本文的討論範圍。

如果電腦系統的某個部分先前已透過 RFC 程序核准，則新增該部分的驅動程式庫時，不需要新的 RFC，只要透過程式碼審查程序新增即可。

程式碼管理

如果 RFC 獲得接受，您就可以建立 Gerrit 變更，其中包含您的主機板或驅動程式庫，並使用 Fuchsia 的程式碼審查程序要求程式碼審查。在 Gerrit 變更中，請務必在適當位置建立資料夾。 舉例來說，如要新增看板，請在 /src/devices/boards 中建立新資料夾。在 Gerrit 變更中，加入 OWNERS 檔案，當中列出每個主機板或驅動程式庫擁有者的電子郵件地址。如要進一步瞭解 OWNERS 的責任，請參閱「責任」。

認證

目前新增板子或驅動程式僅需遵守上述評量表規定。

附錄

必要的 fastboot 指令

如果收到不支援的 Fastboot 指令，系統啟動載入程式必須確實失敗 (不會停止運作或導致裝置無法運作)。非預期的指令應會成功執行或確實失敗。如要進一步瞭解 fastboot，請參閱「fastboot」。

您必須使用下列標準 Fastboot 指令：

• erase <partition>
• flash <partition> <file>
• 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
• version
• 全部

下列指令為選用項目，但有助於開發：

• oem stage-partition <partition> + get_staged