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 裝置等)。

「Initial Fuchsia hardware platform specifications」政策不適用於外部貢獻者使用 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)
• 顯示卡內部 (不是允許與主系統通訊的驅動程式庫)。

「Initial Fuchsia hardware platform specifications」政策也不涵蓋非最終階段的啟動載入程式。

文件定義

本文件使用以下術語：

基本硬體規格

以下是 Fuchsia 的基本硬體規格。基本規格進一步細分為「必要」和「建議」兩個類別。

必要的硬體功能

以下為必要的硬體規格。

必要規格

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

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

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

Rationale

您需要具備足夠空間的 64 位元位址空間，才能有效實作位址空間配置隨機載入 (ASLR) 等功能。

範例

所有 x86-64 硬體平台；所有 ARMv8-A 和更新版本的處理器 (A32 除外)。

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

硬體平台必須提供功能齊全的新型記憶體管理單元，以便建立任意數量的位址空間、將大小適中的頁面中的實體記憶體對應至任何位址空間，並透過硬體存取控制機制，在不同位址空間之間強制執行保護措施。

Rationale

Fuchsia 大量使用虛擬記憶體物件，因此有效的記憶體管理對 Fuchsia 硬體平台的運作至關重要。如要確保 Fuchsia 的基本安全性保證，就必須使用硬體強制執行的記憶體存取控制項。

範例

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

必要條件：小端模式

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

Rationale

處理任意字節序的成本，會影響程式碼開發和測試時間。理論上，Fuchsia 的程式碼可以不受字節序影響，但 Fuchsia 專案目前尚未準備好投入這項工作。大多數現代架構都是 LE 原生或支援 LE 模式。

範例

所有 x86；所有新型 ARM 處理器皆可支援 little-endian。

必要條件：如果是 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 的網路堆疊會使用 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 (「Bulldozer」及更新版本；「Jaguar」及更新版本)
• 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 專案建議針對任何指定架構、平台和目標板，提供 第 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，就無法以可擴充的方式建構或測試程式碼。

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

硬體平台必須支援某種形式的序列主控台存取權，以利開發作業。但對於向最終使用者提供的正式發布系統而言，則不一定需要。序列主控台必須支援中斷驅動的傳送和接收。

雖然 DMA 支援功能不是必要，但建議您使用 DMA。

Rationale

在平台開發初期，最可靠的方法就是使用簡單的序列主控台進行開發和偵錯。

建議規格

雖然支援的硬體層級並未要求，但下列規格是「必須支援」規格的絕佳補充項目。

建議：說明文件和支援

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

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

我們不接受僅使用 Linux 或 Android 開放原始碼計畫的衍生版本進行說明的電路板。平台供應商必須願意親自或透過電子郵件回答問題。

Rationale

如果沒有正確的說明文件，編寫驅動程式和偵錯作業就會變成逆向工程現有軟體，這類作業容易出錯且速度緩慢。如果說明文件使用的現有原始碼，其授權與 Fuchsia 的授權不相容，可能會導致不小心複製程式碼。

建議：Fastboot 的引導程式支援

Fuchsia 專案建議啟動載入器支援附錄中列出的 fastboot 通訊協定指令集。Fuchsia 專案建議在非專屬傳輸上執行快速啟動。

Rationale

統一支援快速啟動功能，可讓您更輕鬆地使用不同硬體平台，並在處理多台機器的機群時協助自動化。

建議：支援虛擬化

Fuchsia 專案建議平台和啟動載入程式允許完整的虛擬化支援。

Intel x86

在 Fuchsia 專案中，您需要完成下列事項，才能全面支援 Intel x86 CPU 上的虛擬化：

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

您可以選擇採用 Fuchsia 專案建議的做法：

• INVPCID
• PAUSE-loop 退出

啟動

在 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 檔案，其中列出板卡或驅動程式庫的每位擁有者的電子郵件地址。如要進一步瞭解擁有者的工作職責，請參閱「職責」。

職責

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

• Code Review SLO：在 3 個日曆日內回覆所屬存放區的程式碼審查要求。只要是存放區的 OWNERS 檔案中列出的使用者，都可以執行程式碼審查。
  • 如果違反這項 SLO，可能會導致下列任一情況：
    • 任何執行審查的 Fuchsia 專案成員。
    • 從建構系統中暫時停用板子或驅動程式庫。
• 重構 SLO：在 5 個日曆日內，實作進階驅動程式庫 SDK 所需的重構。如果重構作業太複雜，無法在 5 天內完成，Fuchsia 專案可在重構要求中定義延長期限。重構要求會透過電子郵件傳送至相應的 OWNERS 檔案中列出的地址。
  • 為了進步 Fuchsia 架構，需要進行的修整作業可以由 Fuchsia 專案成員審查，而不需要特定主機板或驅動程式庫存放區的擁有者進行審查。我們建議在實作這類重構的 Gerrit 變更中加上「CC」擁有者，但這並非必要。如要進一步瞭解 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：說明刪除驅動程式庫的原因的 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. 取得驅動程式庫至少一位擁有者的核准。如果所有 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 檔案，其中列出板卡或驅動程式庫的每位擁有者的電子郵件地址。如要進一步瞭解 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
• 運算單元無法啟動：a
• slot-unbootable:b
• version
• 全部

以下指令為選用指令，但有助於開發：

• oem stage-partition <partition> + get_staged