Google is committed to advancing racial equity for Black communities. See how.
本頁面由 Cloud Translation API 翻譯而成。
Switch to English

實施DTO

實施DTO涉及劃分設備樹,構建,分區和運行。實施可行之後,還必須保持兩個DT之間的兼容性,並確定確保每個DT分區安全的策略。

分割DT

首先將設備樹分為兩(2)部分:

  • 主DT 。 SoC供應商提供的僅SoC部分和默認配置。
  • 疊加DT 。設備特定的配置,由ODM / OEM提供。

劃分設備樹之後,必須確保主DT和覆蓋DT之間的兼容性,以便合併主DT和覆蓋DT可以得出設備的完整DT。有關DTO格式和規則的詳細信息,請參見DTO語法 。有關多個設備樹的詳細信息,請參閱多個DT

構建主要和覆蓋DT

要構建主要DT:

  1. 將主DT .dts編譯為.dtb文件。
  2. .dtb文件閃存到引導加載程序運行時可訪問的分區中(詳細信息如下)。

要構建疊加層DT:

  1. 將覆蓋DT .dts編譯為.dtbo文件。雖然此文件格式與格式為展平的設備樹的.dtb文件相同,但不同的文件擴展.dtb其與主DT區別開來。
  2. .dtbo文件閃存到引導加載程序運行時可訪問的分區中(如下所述)。

有關在主機上使用DTC進行編譯和驗證DTO結果的詳細信息,請參見《 編譯和驗證》

分區DT

確定閃存中的引導程序運行時可訪問且受信任的位置,以放置.dtb.dtbo

主DT的示例位置:

  • 引導分區的一部分,附加到內核( image.gz )。
  • 分離DT斑點( .dtb )在專用分區( dtb )。

覆蓋DT的示例位置:

唯一分區
圖1..dtbo放入唯一的分區,例如dtbo分區。
ODM分區
圖2..dtbo放入odm分區(僅當引導加載程序具有從odm分區的文件系統加載數據的功能時,才執行此操作)。

注意:覆蓋DT分區的大小取決於設備以及主DT Blob頂部所需的更改量。通常,8 MB綽綽有餘,如果需要,可以在將來增加空間。

對於支持無縫(A / B)更新 ,A / B的主DT和覆蓋DT分區:

例子1
圖3. DTBO分區A / B,示例1。
例子2
圖4. DTBO分區A / B,示例2。

在引導程序中運行

跑步:

圖5. Bootloader中設備樹覆蓋的典型運行時實現。
  1. 從存儲.dtb加載到內存中。
  2. 從存儲.dtbo加載到內存中。
  3. .dtbo覆蓋.dtb以成為合併的DT。
  4. 給定合併的DT的內存地址,啟動內核。

保持兼容性

主DTB(來自SoC供應商)被視為DTBO的API表面。將設備樹分為SoC公用部分和特定於設備的部分之後,將來必須使這兩個部分相互兼容,包括:

  • 主DT中的DT定義 (例如,節點,屬性,標籤) 。主DT中的任何定義更改都可能觸發覆蓋DT中的更改。例如,要更正主DT中的節點名稱,請定義一個映射到原始節點名稱的“別名”標籤(以避免更改覆蓋DT)。
  • 覆蓋DT存儲位置 (例如分區名稱,存儲格式)

確保安全

引導加載程序必須確保DTB / DTBO是安全的,未經修改的且未損壞。您可以使用任何解決方案來保護DTB / DTBO的安全,例如,VBoot 1.0中的啟動映像簽名AVB HASH頁腳 (VBoot 2.0)。

  • 如果DTB / DTBO在唯一的分區中,則可以將該分區添加到AVB的信任鏈中。信任鏈從受硬件保護的信任根開始,並進入引導加載程序,該引導加載程序驗證DTB / DTBO分區的完整性和真實性。
  • 如果DTB / DTBO在現有分區(例如odm分區)中,則該分區應在AVB的信任鏈中。 (DTBO分區可以與odm分區共享一個公鑰)。

有關詳細信息,請參閱“ 驗證啟動”