RFC-0111：Fuchsia 初始硬體平台規格

RFC-0111：初始 Fuchsia 硬體平台規格
狀態已接受
領域
  • 管理事宜
說明

為執行 Fuchsia 的硬體平台，訂定初始最低需求、貢獻流程和支援標準。
毛皮變化
作者
審查人員
提交日期 (年-月-日)2021-06-07
審查日期 (年-月-日)2021-07-21

編輯此 RFC

編輯 RFC 中繼資料

摘要

此 RFC 詳細說明指定硬體的初始技術規格 與 Fuchsia 相容的平台，共同完成 Fuchsia 的研究成果。 分類在 Fuchsia 專案中。此 RFC 的作用是 初步的硬體規格，並概述提案流程 對 fuchsia.git 存放區的硬體相關原始碼貢獻。 硬體規格只能透過 Fuchsia RFC 程序。

總覽

本文件詳細說明特定硬體平台的初始技術規格 貢獻一己之力，在 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 託管測試。 實驗硬體平台不應視為適用於 實際工作環境反之，Fchsia 專案採用了實驗功能 探索及瞭解 Fuchsia 的大好機會。

本文件定義 Fuchsia 相容硬體的硬體規格。 具體來說是

  1. 「基本硬體規格」這些是商家 在特定硬體平台上執行 Fuchsia。基本硬體規格 分別是「必要」或「建議」類別實驗性硬體僅需要 必須符合基本硬體規格需求
  2. 「支援的硬體規格」這些都是 硬體平台可能歸類為「支援的硬體」。 除了這些規格外，這個類別中的硬體也必須 未通過 RFC 程序的 1。

本文件也會定義相關的可用性標準 支援的硬體和實驗性硬體。最後，文件會定義 將硬體平台新增至 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 專案建構與整合執行的測試 上傳資料集之後，您可以運用 AutoML 自動完成部分資料準備工作
持續整合/客戶關係管理 持續整合 / 修訂佇列：建構提議的系統 才能整合至主要來源樹狀結構，然後持續測試 整個來源，以找出從 進行多項整合變更

基本硬體規格

以下是 Fuchsia 的基本硬體規格。 基本規格再分為兩類：必要和 (建議使用)

基本規格 定義
必要 如果沒有這項規範，Fchsia 就無法在 指定的硬體平台
推薦方案 此規格極佳，但對 Fuchsia 來說 建構及安裝安裝在指定的硬體平台上如果沒有這項規格 Fuchsia 的功能或效能遭到入侵。

必要的硬體功能

以下硬體規格為必要項目。

必要規格

基本技術規格是 Fuchsia 導入 建構及安裝安裝在指定的硬體平台上

必要：64 位元 CPU 和平台

硬體平台 CPU 必須支援 64 位元位址空間操作模式。 如果平台或 CPU 以非 64 位元模式啟動，只要 只會在 Zircon 核心啟動之前使用。

Rationale

必須要有 64 位元位址空間，且有足夠的空間，才能有效率地 有效實作位址空間配置等功能 隨機挑選 (ASLR)

範例

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

硬體平台必須提供功能完整的新型記憶體管理機制 可讓您建立任意數量的位址空間、對應 適合其中任何空間的合理大小頁面 透過硬體存取，保護不同位址空間 控管機制

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 工具鍊支援 請務必讓指定平台保持最新狀態如要進一步瞭解指定目標 請參閱 CMakeLists.txt 。

Rationale

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

必要：第 2 級 Rust 語言支援

有問題的架構、平台和目標委員會必須至少 (Rust 第 2 級) ，建議使用 在 Rust 級別 1 中的運作方式

Rationale

Fuchsia 廣泛使用 Rust。

必要：Dart 語言支援

相關架構、平台與目標委員會必須遵循 Dart。

Rationale

Fuchsia 大部分的使用者介面都是使用 Flutter 建構而成 也就是使用 Dart

必要：Go 語言支援

相關架構、平台與目標委員會必須遵循 前往。

Rationale

Fuchsia 的網路堆疊使用 Go。

以下是建議硬體規格。

雖然建構及安裝 Fuchsia 不需要，但下列規格 大多是偏好基本規格的補給品 Fuchsia 在特定硬體平台上的功能。

  • 設定計時器，讓計時器可以在超過計時器值時讓核心中斷運作 指定的絕對門檻
  • 導入為架構本身的一部分，而非週邊裝置 指定資料層

Fuchsia 專案建議硬體平台支援 I/O 記憶體管理單位。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 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」Atoms 或更新版本)
  • SHA(1, 256)：AMD (「Zen」以上)
  • CRC32 (支援 SSE 4.2 的處理器)

以下是建議工具鍊和語言支援規格，但 不需要。

Fuchsia 專案建議具體的架構、平台和目標 GCC 工具鍊完全支援 Jamboard。純應用程式開發適用 但不受平台限制 可以只支援 LLVM

Rationale

使用第二個工具鍊會發現更多錯誤。

建議：第 1 級 Rust 語言支援

Fuchsia 專案推薦 階層 1 支援任何特定架構、平台和目標板的 Rust。

Rationale

Fuchsia 廣泛使用 Rust。如要進一步瞭解 第 1 層支援，請參閱 第 1 層目標政策：

支援的硬體規格

以下是支援的硬體規格。代管的測試 Fuchsia 專案會在支援的硬體上執行，做為 Fuchsia 的 持續整合與測試程序Fuchsia 專案的託管測試是 並且可將結果傳送至外部人員查看 貢獻者。支援的硬體示例包括 Intel NUC 和 VIM3。進一步瞭解支援服務的預期事項 支援的硬體，請參閱規格摘要。

支援的硬體規格再細分為兩個 類別：必要和建議。

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

支援的硬體規格 定義
必要 如果沒有這項規格，就無法將這個硬體平台分類 做為支援的硬體
推薦方案 這個規格相當有利，但對 支援的硬體分類。如果沒有這項規範，Fchsia 的 功能或效能也會受到影響

必要規格

除了基本規格外， 支援的硬體也必須符合下列規格 符合支援的硬體支援級別

必要：系統啟動載入程式開啟狀態

最後階段的系統啟動載入程式，這是開機程序的軟體元件 載入 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 的執照可能導致不慎複製程式碼。

Fuchsia 專案建議系統啟動載入程式支援 Fastboot 組合 通訊協定指令列於附錄中。 Fuchsia 專案建議在非專屬情況下進行 Fastboot 例如 1、2 的傳輸方法

Rationale

統一支援 Fastboot 讓您可以更輕鬆地使用 硬體平台，以及在處理大量用戶端時協助自動化作業 您甚至可以設定多部機器

Fuchsia 專案建議平台和系統啟動載入程式允許已滿 虛擬化支援

Intel x86

在 Fuchsia 專案中，需要下列資源才能提供完整支援 Intel x86 CPU 的虛擬化功能：

  • VMX
  • 埃及
  • RDTSCP
  • X2APIC
  • 副總裁 ID
  • 不受限的邀請對象
  • TPR 虛擬化
  • MSR 點陣圖
  • 例外狀況點陣圖

或者，Fchsia 專案建議採取以下做法：

  • 虛擬私有雲 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 貢獻者角色中定義的，可提出修補程式，新增支援的硬體平台 或修正現有的支援的硬體平台

實驗性硬體

實驗硬體平台不應視為適用於 實際工作環境反之，Fchsia 專案採用了實驗功能 探索及瞭解 Fuchsia 的大好機會。實驗功能 我們的硬體在設計上以最佳方式運作，也就是說 Fuchsia 不一定會執行 特定硬體平台的任何時間點

實驗性硬體功能並未由 Fuchsia 專案接受測試，因此我們不保證能保證。 所謂工作，但負責開發 Fuchsia 的成員 實驗層級的硬體可以提出修補程式 來新增實驗性硬體，或修正現有的實驗性硬體。 新增實驗性硬體或變更現有實驗功能的 Genrrit 變更 硬體不得破壞支援的硬體或導入外部程式碼 Zircon 或其他 Fuchsia 專案程式碼中的依附元件。

僅限「實驗性硬體」類別中硬體開發的成員 必須遵守基本規格。

硬體平台摘要

下表統整 Fuchsia 硬體規格類別為 以及支援與測試相關的可用性和測試期望 硬體和實驗性硬體平台

硬體平台類別

功能 接受捐款 預期適用情形

測試期望 必要規格 建議規格
支援的硬體
  • 開發人員可以在支援的硬體上建構及安裝 Fuchsia。
  • 這個硬體不一定會使用任何外部程式碼。
 可以，前提是這些貢獻不會破壞支援的硬體或 在 Zircon 或其他服務中導入實驗性程式碼依附元件 非實驗性質的程式碼
  • Fuchsia 專案針對支援的硬體和區塊進行測試 可能導致支援硬體故障的貢獻。
  • 針對支援硬體層級的硬體提出的 Issue Tracker 問題： 已回應，但沒有服務等級目標 (SLO)。
  • Fuchsia 專案託管測試在支援的硬體上執行。所有語言 貢獻者可以看到這些測試結果。
 所有必要的基本硬體規格，包括： 和 所有必要支援的硬體規格 所有建議的規格
實驗性硬體
  • 開發人員可以預期建構及安裝 Fuchsia 實驗功能 硬體
  • 所有外部貢獻者皆可提出修補程式，以便新增實驗性功能 硬體平台，但這類變更不一定會破壞支援的硬體，或導入 Zircon 或其他常見程式碼中的實驗性程式碼依附元件。
 可以，前提是這些貢獻不會破壞支援的硬體或 在 Zircon 或其他非實驗性程式碼中加入實驗性程式碼依附元件。
  • 實驗性硬體會以最佳方式運作，且不一定會達成 並能隨時處理工作
  • 任何可能破壞支援的硬體的實驗性貢獻 遭到拒絕。
  • 尚未針對實驗執行 Fuchsia 專案託管硬體專屬測試 進行標準測試以外的硬體，才能提交並合併任何 Fuchsia 修訂版本。
 所有必要的基本硬體規格 其中包括： 所有建議的基本硬體規格，包括：

新增硬體平台至 Fuchsia 來源

本節詳述將新硬體新增至 Fuchsia 來源的流程 以及新增硬體至 Fuchsia 來源的相關責任 Fuchsia 專案接受 Gerrit 對支援硬體的貢獻 以及實驗性硬體平台類別

瞭解捐款規範

Fuchsia 專案鼓勵參與者同時投入更多心血與實驗，共同做出貢獻 對硬體類別和硬體類別有基本瞭解 貢獻不會破壞支援的硬體。任何違規的貢獻內容 支援的硬體不會併入 Fuchsia 來源。

修正 Fuchsia 中原本會封鎖實驗功能的變更 建議使用硬體，並完成一般程式碼審查程序 描述 。但可能會拒絕任何提議的變更 帶來大量新的測試、維護或支援負擔 Fuchsia 專案中支援的硬體。

捐款程序

在 Fuchsia 來源中新增硬體平台的程序各有不同 來取決於您新增的架構、主機板或驅動程式。

實驗性貢獻

處理器架構

沒有任何專案推薦方法可以新增實驗性處理器 這個架構的簡短總覽

主面板和驅動程式

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

程式碼管理

變更 Gerrit 時，請務必在適當位置建立資料夾。 舉例來說，如要新增主面板，請建立新資料夾 在「/src/devices/boards/drivers」中。在 Gerrit 變更中包括 OWNERS 檔案 當中註明董事會或驅動程式庫擁有者的電子郵件地址。如要 OWNERS 的資訊請參閱責任。

職責

除了列出非硬體擁有者的責任外 相關代碼、董事會及驅動程式庫 OWNERS 必須遵守下列規範 服務等級目標 (SLO)：

  • 程式碼審查服務等級目標：回覆存放區的程式碼審查要求 事件。存放區 OWNERS 檔案中列出的任何人都能 執行程式碼審查
    • 如未能遵守此服務等級目標，可能會導致下列情形發生： 情境：
      • 執行審查的 Fuchsia 專案成員。
      • 暫時從版本停用主機板或驅動程式庫 有些人會將 Cloud Storage 視為檔案系統 但實際上不是
  • 重構服務等級目標：實作推動驅動程式庫 SDK 所需的重構 5 天內。如果重構對 5 天的服務等級目標太過複雜， 您可以在 Fuchsia 專案的重構要求中定義延長期間。 重構要求會透過電子郵件傳送至 個別 OWNERS 檔案
    • 發展 Fuchsia 架構所需的重構作業，可能會由 可以不必預期 特定主機板或驅動程式庫存放區當 Gerrit 變更時傳送副本給擁有者 建議實作這些類型的重構工作，但不建議 這通常代表交易 不會十分要求關聯語意如要進一步瞭解 Gerrit 中的 CC 屬性，請參閱 變更屬性 。
      • 重構方式包括但不限於下列項目：
        • FDF、 驅動程式庫 FIDL [fuchsia.hardware.\*] 和 Banjo 介面、Syscalls
      • 如未遵守服務等級目標，可能會暫時停用 從建構系統擷取 Pod 或驅動程式庫
，瞭解如何調查及移除這項存取權。
停工板和駕駛

暫時停用的登機證和司機可重新啟用一次 導致停用程序的重構或審查狀態 解決/已完成

如果有 3 個執行個體，fuchsia.git的登機和司機可能會遭到移除 不符合列出的服務等級目標符合這些服務等級目標表示「擁有者」應清楚承諾支援 在存放區中嵌入程式碼如果您想對於移除 來自 fuchsia.git 的驅動程式庫，您必須和 Fuchsia 工程委員會透過 Fuchsia RFC 程序。

已刪除的驅動程式

針對依據這項政策移除的驅動程式，系統會產生 /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. 取得至少一位驅動程式庫擁有者的核准。如果所有擁有者 放棄驅動程式庫且沒有回應，那麼在 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 中建立新資料夾。於 請提供 OWNERS 檔案，並在檔案中註明 每位董事會或驅動程式庫的負責人有關「OWNERS」的詳細資訊 請參閱責任。

認證

目前新增董事會或駕駛時只要遵守 使用評分量表

附錄

必要的 Fastboot 指令

出現不支援的 Fastboot 指令時，系統啟動載入程式必須確實執行失敗 (不會停止運作或造成裝置無法運作)。應有非預期的指令 不論成功或穩定地失敗如要進一步瞭解 Fastboot，請參閱 Fastboot。

所需的標準 Fastboot 指令如下：

  • 清除<partition>
  • 閃光燈 <partition>&lt;file&gt;
  • getvar <名稱>
  • 重開。
  • 重新啟動系統啟動載入程式
  • 重新啟動復原
  • set_active {a,b}
  • 開機 <file>

必要的 getvar 變數：

  • 目前-版位
  • hw-revision
  • max-download-size
  • 產品
  • serialno
  • slot-retry-count:a
  • slot-retry-count:b
  • slot-successful:a
  • 運算單元成功次數：b
  • slot-unbootable:a
  • 無法啟動的運算單元：b
  • version
  • 全部

雖然下列指令為選用項目，但對於開發作業非常實用：

  • 電子階段分區 <partition>+ get_staged