ตั้งแต่วันที่ 27 มีนาคม 2025 เป็นต้นไป เราขอแนะนำให้ใช้ android-latest-release
แทน aosp-main
เพื่อสร้างและมีส่วนร่วมใน AOSP โปรดดูข้อมูลเพิ่มเติมที่หัวข้อการเปลี่ยนแปลงใน AOSP
ใช้ DTO
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
การใช้การวางซ้อนบน Device Tree (DTO) เกี่ยวข้องกับการแบ่ง Device Tree (DT) การสร้าง การแบ่งพาร์ติชัน และการเรียกใช้ หลังจากติดตั้งใช้งานที่ใช้งานได้แล้ว คุณต้องรักษาความเข้ากันได้ระหว่าง DT 2 รายการและกำหนดกลยุทธ์เพื่อรักษาความปลอดภัยของพาร์ติชัน DT แต่ละรายการ
หาร DT
เริ่มต้นด้วยการแบ่ง DT ออกเป็น 2 ส่วน ดังนี้
- DT หลัก ชิ้นส่วน SoC เท่านั้นและการกำหนดค่าเริ่มต้นที่ได้จากผู้ให้บริการ SoC
- DT การวางซ้อน การกําหนดค่าเฉพาะอุปกรณ์ที่ระบุโดย ODM/OEM
หลังจากแบ่ง DT แล้ว คุณต้องตรวจสอบความเข้ากันได้ระหว่าง DT หลักและ DT การวางซ้อนเพื่อให้การผสาน DT หลักและ DT การวางซ้อนกลายเป็น DT ที่สมบูรณ์สำหรับอุปกรณ์ ดูรายละเอียดเกี่ยวกับรูปแบบและกฎของ DTO ได้ที่ไวยากรณ์ DTO โปรดดูรายละเอียดเกี่ยวกับ DT หลายรายการที่หัวข้อใช้ DT หลายรายการ
สร้าง DT หลักและ DT วางซ้อน
วิธีสร้าง DT หลัก
- คอมไพล์ DT หลัก
.dts
เป็นไฟล์ .dtb
- แฟลชไฟล์
.dtb
ลงในพาร์ติชันที่บูตโหลดเดอร์เข้าถึงได้เมื่อรันไทม์ (ดูรายละเอียดใน [Partition DTs](#partition))
วิธีสร้าง DT การวางซ้อน
- คอมไพล์ DT
.dts
วางซ้อนเป็นไฟล์ .dtbo
แม้ว่ารูปแบบไฟล์นี้จะเหมือนกับไฟล์ .dtb
ที่ฟอร์แมตเป็น DT แบบแบน แต่นามสกุลไฟล์ที่แตกต่างกันจะแยกไฟล์นี้ออกจาก DT หลัก
- แฟลชไฟล์
.dtbo
ลงในพาร์ติชันที่บูตโหลดเดอร์เข้าถึงได้เมื่อรันไทม์ (ดูรายละเอียดใน [Partition DTs](#partition))
ดูรายละเอียดเกี่ยวกับการคอมไพล์ด้วย DTC และการยืนยันผลลัพธ์ DTO ในโฮสต์ได้ที่หัวข้อคอมไพล์และยืนยัน
DT ของพาร์ติชัน
ระบุตำแหน่งที่เชื่อถือได้และเข้าถึงได้แบบรันไทม์ในหน่วยความจำแฟลชสำหรับบูตโหลดเดอร์เพื่อใส่ .dtb
และ .dtbo
ตัวอย่างตำแหน่งสำหรับ DT หลัก
- เป็นส่วนหนึ่งของพาร์ติชันสำหรับบูตต่อท้ายเคอร์เนล (
image.gz
)
- แยก Blob DT (
.dtb
) ไว้ในพาร์ติชันเฉพาะ (dtb
)
ตัวอย่างตำแหน่งของ DT การวางซ้อน

รูปที่ 1 ใส่ .dtbo ลงในพาร์ติชัน odm (ทําเช่นนี้เฉพาะในกรณีที่โปรแกรมโหลดบูตมีความสามารถในการโหลดข้อมูลจากระบบไฟล์ของพาร์ติชัน odm เท่านั้น)

รูปที่ 2 ใส่ .dtbo ลงในพาร์ติชันที่ไม่ซ้ำกัน เช่น พาร์ติชัน dtbo
หมายเหตุ: ขนาดของพาร์ติชัน DT ที่วางซ้อนจะขึ้นอยู่กับอุปกรณ์และจำนวนการเปลี่ยนแปลงที่จำเป็นบนด้านบนของ Blob DT หลัก โดยทั่วไปแล้ว 8 MB ถือว่าเพียงพอแล้วและยังช่วยให้มีที่ว่างสำหรับเติบโตในอนาคตได้หากจำเป็น
สำหรับอุปกรณ์ที่รองรับการอัปเดต (A/B) ที่ราบรื่น ให้ทดสอบ A/B ของพาร์ติชัน DT หลักและพาร์ติชัน DT ที่ซ้อนทับ ดังนี้

รูปที่ 3 พาร์ติชัน DTBO A/B ตัวอย่างที่ 1

รูปที่ 4 พาร์ติชัน DTBO A/B ตัวอย่างที่ 2
ทำงานใน Bootloader
วิธีเรียกใช้

รูปที่ 5 การใช้งานรันไทม์ทั่วไปสําหรับ DTO ใน Bootloader
- โหลด
.dtb
จากพื้นที่เก็บข้อมูลลงในหน่วยความจำ
- โหลด
.dtbo
จากพื้นที่เก็บข้อมูลลงในหน่วยความจำ
- วางซ้อน
.dtb
กับ .dtbo
เพื่อสร้าง DT ที่ผสาน
- เริ่มเคอร์เนลโดยระบุที่อยู่หน่วยความจำของ DT ที่ผสาน
รักษาความเข้ากันได้
ระบบจะถือว่า DTB หลัก (จากผู้ให้บริการ SoC) เป็นแพลตฟอร์ม API สำหรับ DTBO หลังจากแยก DT ออกเป็นส่วนที่ใช้ได้กับ SoC ทั่วไปและส่วนที่ใช้ได้กับอุปกรณ์โดยเฉพาะแล้ว คุณจะต้องทำให้ 2 ส่วนนี้เข้ากันได้ในอนาคต ซึ่งรวมถึง
- คําจํากัดความ DT ใน DT หลัก เช่น โหนด พร็อพเพอร์ตี้ ป้ายกำกับ การเปลี่ยนแปลงคำจำกัดความใน DT หลักอาจทริกเกอร์การเปลี่ยนแปลงใน DT วางซ้อน เช่น หากต้องการแก้ไขชื่อโหนดใน DT หลัก ให้กําหนดป้ายกํากับ "ชื่อแทน" ที่เชื่อมโยงกับชื่อโหนดเดิม (เพื่อหลีกเลี่ยงการเปลี่ยนแปลง DT การวางซ้อน)
- วางซ้อนตำแหน่งร้านค้า DT เช่น ชื่อพาร์ติชัน รูปแบบร้านค้า
ตรวจสอบความปลอดภัย
Bootloader ต้องตรวจสอบว่า DTB หรือ DTBO นั้นปลอดภัย ไม่มีการแก้ไข และไม่มีการขัดข้อง
คุณสามารถใช้โซลูชันใดก็ได้เพื่อรักษาความปลอดภัยให้กับ DTB หรือ DTBO เช่น ลายเซ็นภาพบูตใน VBoot 1.0 หรือส่วนท้าย HASH ของ AVB (VBoot 2.0)
- หาก DTB หรือ DTBO อยู่ในพาร์ติชันที่ไม่ซ้ำกัน คุณสามารถเพิ่มพาร์ติชันนั้นลงในเชนความน่าเชื่อถือของ AVB ได้ เชนความน่าเชื่อถือเริ่มต้นจากรูทของความน่าเชื่อถือที่ได้รับการปกป้องด้วยฮาร์ดแวร์และไปยัง Bootloader ซึ่งจะยืนยันความสมบูรณ์และความถูกต้องของพาร์ติชัน DTB หรือ DTBO
- หาก DTB หรือ DTBO อยู่ในพาร์ติชันที่มีอยู่ (เช่น พาร์ติชัน
odm
) พาร์ติชันนั้นควรอยู่ในเชนความน่าเชื่อถือของ AVB (พาร์ติชัน DTBO อาจแชร์คีย์สาธารณะกับพาร์ติชัน odm
ได้)
โปรดดูรายละเอียดที่หัวข้อVerified
Boot
ตัวอย่างเนื้อหาและโค้ดในหน้าเว็บนี้ขึ้นอยู่กับใบอนุญาตที่อธิบายไว้ในใบอนุญาตการใช้เนื้อหา Java และ OpenJDK เป็นเครื่องหมายการค้าหรือเครื่องหมายการค้าจดทะเบียนของ Oracle และ/หรือบริษัทในเครือ
อัปเดตล่าสุด 2025-07-26 UTC
[[["เข้าใจง่าย","easyToUnderstand","thumb-up"],["แก้ปัญหาของฉันได้","solvedMyProblem","thumb-up"],["อื่นๆ","otherUp","thumb-up"]],[["ไม่มีข้อมูลที่ฉันต้องการ","missingTheInformationINeed","thumb-down"],["ซับซ้อนเกินไป/มีหลายขั้นตอนมากเกินไป","tooComplicatedTooManySteps","thumb-down"],["ล้าสมัย","outOfDate","thumb-down"],["ปัญหาเกี่ยวกับการแปล","translationIssue","thumb-down"],["ตัวอย่าง/ปัญหาเกี่ยวกับโค้ด","samplesCodeIssue","thumb-down"],["อื่นๆ","otherDown","thumb-down"]],["อัปเดตล่าสุด 2025-07-26 UTC"],[],[],null,["# Implement DTOs\n\nImplementing device tree overlays (DTOs) involves dividing the device tree (DT), building,\npartitioning, and running. After you have a working implementation, you must also maintain\ncompatibility between the two DTs and determine a strategy for ensuring the\nsecurity of each DT partition.\n\nDivide the DT\n-------------\n\nStart by dividing the DT into two parts:\n\n- **Main DT**. The SoC-only part and the default configurations, provided by SoC vendor.\n- **Overlay DT**. The device-specific configurations, provided by ODM/OEM.\n\nAfter dividing the DTs, you must ensure compatibility between main\nDT and overlay DT so that merging main DT and overlay DT results in a complete\nDT for the device. For details on DTO format and rules, see\n[DTO syntax](/docs/core/architecture/dto/syntax). For details on\nmultiple DTs, see\n[Use multiple DTs](/docs/core/architecture/dto/multiple).\n\nBuild main and overlay DTs\n--------------------------\n\nTo build the main DT:\n\n1. Compile the main DT `.dts` into a `.dtb` file.\n2. Flash the `.dtb` file into a bootloader runtime-accessible partition (detailed in \\[Partition DTs\\](#partition)).\n\nTo build the overlay DT:\n\n1. Compile the overlay DT `.dts` into a `.dtbo` file. While this file format is the same as the `.dtb` file formatted as a flattened DT, the different file extension distinguishes it from the main DT.\n2. Flash the `.dtbo` file into a bootloader runtime-accessible partition (detailed in \\[Partition DTs\\](#partition)).\n\nFor details on compiling with DTC and verifying DTO results on the host, see\n[Compile and verify](/docs/core/architecture/dto/compile).\n\nPartition DTs\n-------------\n\nDetermine a bootloader runtime-accessible and trusted location in flash\nmemory to put `.dtb` and `.dtbo`.\n\nExample locations for the main DT:\n\n- Part of boot partition, appended to the kernel (`image.gz`)\n- Separate DT blobs (`.dtb`) in dedicated partition (`dtb`)\n\nExample locations for the overlay DT: \n\n**Figure 1.** Put .dtbo into an odm partition (do this only if your bootloader has\nthe capability to load data from the filesystem of an odm partition). \n\n**Figure 2.** Put .dtbo into a unique partition, such as a dtbo partition.\n\n**Note:** The size of the\noverlay DT partition depends on the device and the amount of changes needed on\ntop of the main DT blob. Typically, 8 MB is more than enough and allows room to\ngrow in the future if required.\n\nFor devices that support\n[seamless (A/B) updates](/docs/core/ota/ab_updates), A/B the\nmain DT and overlay DT partitions: \n\n**Figure 3.** DTBO partition A/B, example 1. \n\n**Figure 4.** DTBO partition A/B, example 2.\n\nRun in bootloader\n-----------------\n\nTo run:\n\n**Figure 5.** Typical runtime implementation for DTO in bootloader.\n\n1. Load `.dtb` from storage into memory.\n2. Load `.dtbo` from storage into memory.\n3. Overlay `.dtb` with `.dtbo` to be a merged DT.\n4. Start kernel given the memory address of the merged DT.\n\nMaintain compatibility\n----------------------\n\nThe main DTB (from SoC vendor) is treated as an API surface for DTBOs. After\nseparating the DT into a SoC-common part and a device-specific part,\nyou must keep the two parts mutually compatible in the future, including:\n\n- **DT definition in main DT.** For example, nodes, properties, labels. Any definition change in main DT could trigger changes in overlay DT. For example, to correct a node name in main DT, define an \"alias\" label that maps to the original node name (to avoid the change of overlay DT).\n- **Overlay DT store location.** For example, partition name, store format.\n\nEnsure security\n---------------\n\nBootloader must ensure the DTB or DTBO is secure, unmodified, and uncorrupted.\nYou could use any solution to secure DTB or DTBO, for example,\n[Boot image\nsignature](/docs/security/features/verifiedboot/verified-boot#signature_format) in VBoot 1.0 or\n[AVB\nHASH footer](https://android.googlesource.com/platform/external/avb/+/android16-release/README.md#The-VBMeta-struct) (VBoot 2.0).\n\n- If DTB or DTBO is in a unique partition, you can add that partition to the trust chain of AVB. The trust chain starts from a hardware-protected root of trust and goes to the bootloader, which verifies the integrity and authenticity of DTB or DTBO partition.\n- If DTB or DTBO is in an existing partition (such as the `odm` partition), that partition should be in the trust chain of AVB. (DTBO partition could share a public key with `odm` partition).\n\nFor details, refer to [Verified\nBoot](/docs/security/features/verifiedboot)."]]