| RFC-0111：初始 Fuchsia 硬體平台規格 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 針對執行 Fuchsia 的硬體平台初始最低需求、捐款流程和支援標準。 |
| 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年/月) | 2021-06-07 |
| 審查日期 (年/月) | 2021-07-21 |
摘要
本 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 來源樹狀結構存放區以外。開發人員可使用驅動程式 SDK 編寫驅動程式，並在 Fuchsia 開放原始碼專案存放區以外的位置發布來源和二進位檔。
硬體平台類別
在 Fuchsia 專案中，執行 Fuchsia 專案託管測試的硬體平台，歸類為「支援的」硬體。實驗功能硬體符合與執行 Fuchsia 相容的硬體平台最低需求，但並未執行 Fuchsia 託管測試。實驗性硬體平台不應將其視為實際工作環境。相反地，Fuchsia 專案會將實驗性硬體做為探索及瞭解 Fuchsia 的方式。
本文件定義了與 Fuchsia 相容硬體平台的硬體規格，具體說明：
- 「基本硬體規格」：這是 Fuchsia 在特定硬體平台上執行的最低規格。基本硬體規格分為「必要」或「建議」兩種。實驗性硬體只需要符合必要的基本硬體規格。
- 「支援的硬體規格」：這是將硬體平台歸類為支援的硬體所需的規格。除了這些規格外，由於產生的測試需求，這個類別中的硬體也必須透過 RFC 程序核准。
本文件也會定義與支援硬體和實驗功能硬體相關的可用性期望。最後，本文件定義了將硬體平台新增至 Fuchsia 來源的程序。
周邊裝置
「初始 Fuchsia 硬體平台規格」RFC 涵蓋基本系統的硬體規格，允許週邊裝置與特定平台搭配使用。包括 USB 儲存體驅動程式和圖形卡驅動程式 (永久連接及可拆卸顯示卡)。
「初始 Fuchsia 硬體平台規格」並未涵蓋外部周邊裝置的運作作業，除了可由執行基礎架構直接觀察的互動外，例如，下列項目不會涵蓋韌體的作業詳細資料：
- 機器學習 (ML) 加速器
- 音訊硬體數位訊號處理器 (DSP)
- 圖形卡內部 (並非允許與主要系統通訊的驅動程式庫)。
「初始 Fuchsia 硬體平台規格」政策也不會涵蓋非最終階段系統啟動載入程式的系統啟動載入程式。
文件定義
本文件使用的字詞如下：
| 字詞 | 定義 |
| 架構 | 例如 x86 或 ARM 的處理器架構。 |
| 系統 | 具備 CPU、記憶體、週邊裝置等的完整電腦硬體平台，通常稱為「主機板」。 |
| 硬體平台 | 晶片系統 (SoC) (例如 ARM 型 SoC) 或中央處理器 (CPU) 和晶片組 (例如許多 x86 系統) 的組合。 |
| SoC | 晶片系統中的系統，通常由處理器中已整合的周邊裝置組成，並採用同一個晶片套件 (通常做為電腦系統的核心)。通常有多個 CPU 核心。 |
| CPU | 中央處理器。 |
| 變更 | Fuchsia 專案使用 Gerrit 的網頁式 UI 來管理程式碼和說明文件審查。將修訂版本上傳到 Gerrit 時，即稱為變更。請注意，基礎修訂版本控制系統為 git。 |
| Fuchsia-project 代管測試 | 透過 Fuchsia 專案建構與整合程序進行的測試。 |
| CI/CQ | 持續整合 / 修訂佇列：這類系統會先建構提議的變更，然後再整合至主要來源樹狀結構，並持續測試整個來源，找出因多項整合式變更的互動而導致的迴歸問題。 |
基本硬體規格
以下是 Fuchsia 的基本硬體規格。基本規格可進一步分為兩類：必要和建議。
| 基本規格 | 定義 |
| 必要 | 如果沒有這項規格，Fuchsia 就無法在特定硬體平台上建構和安裝。 |
| 建議 | 這個規格非常受歡迎，但 Fuchsia 在特定硬體平台上建構及安裝不需要。如果沒有這項規格， Fuchsia 的功能或效能就會降低。 |
必要的硬體功能
下列硬體規格為必填欄位。
必要規格
所需規格是 Fuchsia 在特定硬體平台上建構及安裝的基本技術需求。
必要：64 位元 CPU 和平台
硬體平台 CPU 必須支援 64 位元位址空間作業模式。如果平台或 CPU 是在非 64 位元模式下啟動，但只在 Zircon 核心啟動前的早期啟動期間使用，則可接受。
Rationale
需具有足夠空間的 64 位元位址空間，才能有效率地有效實作位址空間版面配置隨機化 (ASLR) 等功能。
範例
所有 x86-64 硬體平台；所有 ARMv8-A 及以上處理器 (A32 除外)。
必要：完整功能的記憶體管理單位 (MMU)
硬體平台必須提供功能齊全的現代記憶體管理單元，以便建立任意數量的位址空間、將大小合理頁面的實體記憶體對應至其中任何空間，以及透過硬體存取權控管機制，在個別位址空間之間強制執行保護。
Rationale
Fuchsia 大量使用虛擬記憶體物件，因此高效率記憶體管理是 Fuchsia 硬體平台運作的關鍵。如果沒有硬體強制執行記憶體存取權控管機制，就無法達成 Fuchsia 的基本安全性保證。
範例
ARM 8.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 大部分的使用者介面是透過使用 Dart 建構的 Flutter 建構而成。
必要：支援 Go 語言
有問題的架構、平台和目標主面板都必須由 Go 支援。
Rationale
Fuchsia 的網路堆疊使用 Go。
建議硬體功能
建議採用下列硬體規格。
建議規格
雖然不需要建構及安裝 Fuchsia，但下列規格非常建議使用基礎規格的補充作業，因為這些規格能改善了特定硬體平台上的功能。
建議：時鐘與計時器
- 設定計時器，當計時器值超過某個絕對門檻時，就可以向核心發出中斷。
- 而是當做架構本身的一部分進行實作，而非做為目標層中的周邊裝置。
建議：I/O 記憶體管理單位 (IOMMU)
Fuchsia 專案建議硬體平台支援硬體 I/O 記憶體管理單元。在未透過 IOMMU 明確授權的情況下，IOMMU 必須能夠 NAK 從系統中可明確識別的硬體單元進行讀取或寫入交易。
您可以視需要為 IOMMU 加入下列提供可改善的功能：
- 可進行硬體 DMA 作業的轉譯處理 (此功能可讓 Fuchsia 專案針對 HW DMA 使用固定但不連續的實體記憶體)。
- 能夠偵測及偵錯 IOMMU 網頁錯誤的情況 (例如，如果單位踏出邊界，就能夠取得例外狀況，以及一些背景資訊，像是在哪個位置嘗試執行的作業)。
Rationale
Zircon 驅動程式是使用者模式軟體元件，對硬體的存取權相當有限。IOMMU 能針對可存取實體記憶體的裝置來防範錯誤或攻擊，而且比稽核軟硬體更可靠。這樣可以提升 Fuchsia 作業系統的整體安全性。
範例
ARM 的 IOMMU 規格：系統記憶體管理單元 (SMMU)
Intel 的 x86 IOMMU 規格：Intel VT-d、AMD-Vi
建議：支援硬體加密編譯加速功能
Fuchsia 專案建議硬體平台可以同時為 AES 和 SHA 加密編譯作業提供硬體加速。
Rationale
Fuchsia 會大量使用加密編譯作業，因此硬體加速功能極有利於可接受的效能，特別是在較小的硬體平台上。
範例
ARM 8.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-project 代管測試是在支援的硬體上執行，外部貢獻者可查看其結果。支援的硬體範例包括 Intel NUC 和 VIM3。如要進一步瞭解支援硬體的支援期望，請參閱規格摘要。
支援的硬體規格進一步分為兩類：必要和建議類別。
如要進一步瞭解必要和建議規格，請參閱下表：
| 支援的硬體規格 | 定義 |
| 必要 | 如果沒有此規格，就無法將這個硬體平台歸類為支援的硬體。 |
| 建議 | 這個規格非常理想，但支援的硬體分類並非必要條件。如果沒有這個規格， Fuchsia 的功能或效能就會降低。 |
必要規格
除了基本規格外，支援的硬體也必須符合下列規格，才能納入支援的硬體支援級別。
必要程序：系統啟動載入程式開放性
最終階段系統啟動載入程式 (用於載入 Fuchsia 核心的啟動程序軟體元件) 必須符合下列規定：
- Fuchsia 專案必須能變更系統啟動載入程式。
- Fuchsia 專案必須能夠建構系統啟動載入程式。
- Fuchsia 專案必須能將 Fuchsia 專案任何變更所帶來的來源和二進位檔發布至系統啟動載入程式。
系統啟動載入程式不需要與 Fuchsia 相容的授權。在系統啟動載入程式之前的啟動程序中，較早的階段不需要使用開放原始碼，但最好盡量採用。另請參閱說明文件與支援的需求條件。
您非常希望在開放式環境中開發原始碼，來源專案擁有者會接受錯誤報告和外部變更加以整合，並為專案提供持續支援。
Rationale
您可以修改開放原始碼系統啟動載入程式，直接支援載入 Fuchsia，而不使用系統啟動輔助程式。為了確保安全性，專屬 blob 難以偵錯或稽核。早期啟動程序的某些部分通常是以開放原始碼的形式無法使用，且無法替換為開放版本；例如廠商專屬版本 ARM 受信任執行環境，或 x86 平台上的統一可執行韌體介面 (UEFI) 實作。
範例
必要：QEMU 必須支援架構
必須採用最新的 Fuchsia 專案 QEMU 版本支援這個架構。建議做法：
- 該平台支援特定平台。
- 這個架構可透過 QEMU 進行虛擬化。
- QEMU 可以在相同架構的主機 QEMU 機器上執行 (即 x86 主機上的 QEMU-kvm x86，或在 arm64 主機上的 QEMU-kvm arm64)。
如果架構有指定的模式 (例如 ARM Trustzone)，則應可模擬 QEMU。
Rationale
為了提供可擴充的硬體支援，用於建構和測試，QEMU 適用於持續整合。如果沒有支援目標架構的 QEMU，就無法以可擴充的方式建構或測試程式碼。
必要：序列控制台存取權
基於開發目的，硬體平台必須支援特定形式的序列主控台存取權。提供給使用者的實際工作環境系統則不需要。序列主控台必須支援中斷驅動的 TX 和 RX。
指定行銷區域支援這項功能很實用，但不一定要使用指定行銷區域。
Rationale
在早期平台開發期間，簡單的序列主控台是最可靠的開發及偵錯方式。
建議規格
雖然「支援的硬體層級」不需要這麼做，但下列規格對於所需支援的規格非常偏好的補充項目。
建議：說明文件與支援
該平台應提供合理的公開說明文件，包括：
- 註冊地圖
- 運算理論
- 啟動時間硬體狀態的相關資訊
我們不接受只使用 Linux 分支或 Android 開放原始碼計畫記錄的主面板。平台廠商必須願意親自或透過電子郵件回答問題。
Rationale
如果沒有準確的文件，編寫驅動程式和偵錯時，可減少為錯誤而造成錯誤的現有軟體反向工程。如果說明文件中的授權與 Fuchsia 授權不相容，則可能導致無意間複製程式碼。
建議：系統啟動載入程式支援 Fastboot
Fuchsia 專案建議系統啟動載入程式支援附錄中列出的一組 Quickboot 通訊協定指令。Fuchsia 專案建議在非專屬傳輸過程中，快速啟動。
Rationale
統一支援 Fastboot，使其更容易使用不同的硬體平台，且可在處理多部機器機群時協助自動化。
建議：虛擬化支援
Fuchsia 專案建議平台和系統啟動載入程式允許完整虛擬化支援。
Intel x86
在 Fuchsia 專案中，需要下列項目才能完整支援 Intel x86 CPU 的虛擬化功能：
- VMX
- 埃及
- RDTSCP
- 2APIC
- VPID
- 無限制的邀請對象
- TPR 虛擬化
- MSR 點陣圖
- 例外狀況點陣圖
Fuchsia 專案建議：
- 內部 ID
- 暫停循環播放
啟動
在 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 在實驗性層級硬體上開發的成員可提出修補程式，以新增實驗性硬體或修正現有的實驗性硬體。變更新增實驗性硬體或修改現有實驗性硬體，可能無法破壞支援的硬體，也無法在 Zircon 或其他 Fuchsia 專案程式碼中導入外部程式碼依附元件。
在實驗功能硬體類別中開發硬體的成員，只需要符合基本規格。
硬體平台摘要
下表摘要說明 Fuchsia 的硬體規格類別，以及「支援的硬體和實驗性硬體平台」的可用性和測試期望。
| 硬體平台類別
|
功能 | 接受捐款 | 可用性期望
|
測試期望 | 必要規格 | 建議規格 |
| 支援的硬體 |
|
是，前提是這些貢獻不會破壞支援的硬體，或是在 Zircon 或其他非實驗功能程式碼中導入實驗性程式碼依附元件。 |
|
|
所有必要的基本硬體規格，包括： 和所有必要的支援的硬體規格 | 所有建議支援的規格 |
| 實驗性硬體 |
|
是，前提是這些貢獻不會破壞支援的硬體，或是在 Zircon 或其他非實驗功能程式碼中導入實驗性程式碼依附元件。 |
|
|
所有必要的基本硬體規格，包括： | 所有建議的基本硬體規格，包括： |
將硬體平台新增至 Fuchsia 來源
本節詳細說明將新硬體新增至 Fuchsia 來源的程序，以及將硬體新增至 Fuchsia 來源的相關責任。Fuchsia 專案接受 Gerrit 對「支援的硬體」和「實驗性硬體平台」類別做出的貢獻。
瞭解捐款規範
Fuchsia 專案透過「支援」和「實驗性硬體」類別鼓勵各方面貢獻心力，其中奠定了硬體的貢獻無法破壞支援的硬體。任何會破壞支援硬體的貢獻都不會合併至 Fuchsia 來源。
我們建議修正 Fuchsia 中會封鎖實驗功能硬體的錯誤，並按照「貢獻變更」中所述的一般程式碼審查程序。但是，如果提議的變更會對 Fuchsia 專案中的支援硬體進行大量新的測試、維護或支援負擔，則可能會遭到拒絕。
捐款程序
將硬體平台新增至 Fuchsia 來源的程序，會因新增架構、主機板或驅動程式而異。
實驗性貢獻
處理器架構
目前沒有任何專案認可方法可以新增實驗性處理器架構。
董事會和驅動程式
如要新增實驗性板或驅動程式庫，請使用 Fuchsia 的程式碼審查程序，並確保 Gerrit 變更符合評分量表。
程式碼管理
變更 Gerrit 後，請務必在適當位置建立資料夾。
例如，如要新增主面板，請在 /src/devices/boards/drivers 中建立新資料夾。在 Gerrit 變更中，有 OWNERS 檔案，會註明白板或驅動程式庫的電子郵件地址。如要進一步瞭解 OWNERS 的責任，請參閱責任。
責任感
除了列出非硬體相關程式碼的「擁有者」所負責的責任外，主面板和驅動程式庫 OWNERS 還必須遵守下列服務等級目標 (SLO)：
- 程式碼審查服務等級目標：在 3 天內回覆自有存放區的程式碼審查要求。存放區的 OWNERS 檔案中列出的任何人都能執行程式碼審查。
- 如果未能遵守這項服務等級目標，可能會導致下列情況：
- 任何執行審核的 Fuchsia 專案成員。
- 從建構系統暫時停用主面板或驅動程式庫。
- 如果未能遵守這項服務等級目標，可能會導致下列情況：
- 重構 SLO：在 5 天內實作驅動程式庫程式 SDK 所需的重構。如果 5 天的服務等級目標重構太複雜，您可以在 Fuchsia 專案的重構要求中定義延長期間。系統會透過電子郵件傳送重構要求，傳送至個別 OWNERS 檔案中列出的地址。
停用的主面板和驅動程式
主面板和驅動程式暫時停用後，只要經過重構或審查提示停用/完成，就可以重新啟用。
如果 3 個執行個體不符合列出的服務等級目標，系統可能會從 fuchsia.git 中移除主面板和驅動程式。符合這些服務等級目標可表示 OWNERS 明確表示支援其存放區中的程式碼。如果您想對移除 fuchsia.git 的驅動程式庫提出異議，必須透過 Fuchsia RFC 程序與 Fuuchsia Engineering Council 合作。
已刪除的驅動程式
如果驅動程式已依據這項政策移除，/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'
刪除驅動程式庫的程序包括：
- 獲得至少一位驅動程式庫的核准。如果所有 OWNERS 已放棄驅動程式庫且沒有回應，那麼 Fuchsia 樹狀結構中的「OWNER」(擁有者) 必須核准執行刪除動作的 CL。
- 在刪除的每個驅動程式庫的
/docs/reference/hardware/_driver_epitaphs.yaml檔案中新增項目，包括刪除前包含驅動程式庫的 fuchsia.git 存放區 Git 雜湊。
支援的貢獻
處理器架構
如要提議在 Fuchsia 來源中新增架構，請使用 Fuchsia RFC 程序。新增架構可能會大幅增加 Fuchsia 開發作業的工作，因此需要透過 RFC 程序來解決。
透過 RFC 程序新增的所有處理器都會歸類為支援的硬體。
程式碼管理
如果 RFC 接受，您就可以建立包含所提議架構的 Gerrit 變更，並使用 Fuuchsia 的程式碼審查程序提出程式碼審查要求。在 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 指令：
- 清除 <分區>
- Flash <partition> <file>
- getvar <name>
- 重開。
- 重新啟動系統啟動載入程式
- 重新開機復原。
- set_active {a,b}
- 啟動 <file>
必要的 getvar 變數：
- 目前版位
- Hw 修訂版本
- 最大下載大小
- 產品
- 序列
- slot-retry-count:a
- slot-retry-count:b
- 運算單元成功:a
- 運算單元成功:b
- 無法啟動運算單元：a
- 無法啟動運算單元：b
- version
- 全部
下列指令為選用，但有助於進行開發作業：
- Oem 階段分區 <partition> + get_staged