3. Android DTS 目录结构：kernel/arch/arm64/boot/dts/ 下的组织方式
Android 设备树源文件（DTS）的物理存放路径遵循 Linux 内核主线规范，同时融入了厂商（Vendor）与平台（Platform）的层次划分。理解这一目录结构，是进行多板型 DTS 覆盖与配置分离的基础。
3.1 顶层目录布局
所有 ARM64 架构的设备树文件均位于内核源码树的固定路径下：
kernel/arch/arm64/boot/dts/
├── allwinner/
├── amlogic/
├── broadcom/
├── exynos/
├── freescale/
├── hisilicon/
├── mediatek/
├── qcom/
├── rockchip/
├── samsung/
├── ti/
└── ...每个顶级子目录对应一个 SoC 厂商或平台家族。在 Android BSP 工程中，最常打交道的目录包括 qcom/（高通）、mediatek/（联发科）、exynos/（三星）、rockchip/（瑞芯微）等。
实践要点：Android 编译系统通过
BOARD_KERNEL_DTS 或 TARGET_DEVICE 变量定位具体 DTS 文件路径，而非扫描整个目录树。因此，目录结构的规范性直接影响编译效率。
3.2 Vendor 与 Platform 二级目录划分
在主流厂商目录内部，普遍采用 Vendor（厂商/品牌） 与 Platform（平台/芯片组） 两级子目录进行组织。以高通（qcom）为例：
kernel/arch/arm64/boot/dts/qcom/
├── sm8250.dtsi # 平台级 .dtsi（Snapdragon 865）
├── sm8250-pinctrl.dtsi # 引脚复用专用 .dtsi
├── sm8250-camera.dtsi # 摄像头专用 .dtsi
├── sm8250-display.dtsi # 显示专用 .dtsi
├── sm8250-vidc.dtsi # 视频编解码专用 .dtsi
├── sm8250-audio.dtsi # 音频专用 .dtsi
├── sm8250-thermal.dtsi # 温控专用 .dtsi
│
├── vendor/
│ ├── xiaomi/
│ │ ├── sm8250-xiaomi-alioth.dts # 小米 K40 Pro
│ │ ├── sm8250-xiaomi-alioth-overlay.dts
│ │ └── sm8250-xiaomi-cas.dts # 小米 10 Ultra
│ ├── oneplus/
│ │ ├── sm8250-oneplus-lemonade.dts # OnePlus 9
│ │ └── sm8250-oneplus-lemonadev.dts
│ └── google/
│ ├── sm8250-google-redbull.dts
│ └── sm8250-google-redbull-overlay.dts
│
└── platform/
├── sm8250-mtp.dts # 高通参考设计板（MTP）
├── sm8250-cdp.dts # 高通参考设计板（CDP）
├── sm8250-rumi.dts # 仿真/模拟平台
└── sm8250-qrd.dts # 高通参考设计（QRD）
关键概念：
- Platform 目录：存放 SoC 厂商提供的参考设计板级文件，用于芯片验证和早期驱动开发。
- Vendor 目录：存放终端设备厂商（OEM/ODM）的定制板级文件，包含产品特有的外设配置、GPIO 定义、电源管理等。
3.3 目录划分对比表
| 维度 | Platform 目录 | Vendor 目录 |
|---|---|---|
| 维护者 | SoC 厂商（如高通、联发科） | 终端设备厂商（如小米、OPPO） |
| 文件类型 | 参考设计 DTS、芯片级 .dtsi | 产品级 DTS、Overlay DTS |
| 变更频率 | 低（随内核版本或芯片版本更新） | 高（每个项目、每个 SKU 都可能变更） |
| 配置范围 | SoC 内部模块、总线、时钟、电源域 | 外设型号、GPIO 复用、LCD/TP 参数、传感器 |
| 复用性 | 跨多个 Vendor 项目复用 | 通常仅限同一产品系列 |
| 编译入口 | 由 Platform 的 Makefile 统一包含 | 由 BoardConfig.mk 或 dtbo.img 构建脚本指定 |
3.4 目录结构的内联 SVG 架构图
下图展示了从 SoC 厂商到终端产品的 DTS 文件组织层级与依赖关系：
3.5 文件命名规范与编译映射
Android DTS 文件的命名遵循 <soc_platform>-<vendor>-<board>.dts 的约定，这种命名方式直接映射到编译系统的目标输出：
- dtb 文件：
sm8250-xiaomi-alioth.dtb— 由同名 DTS 编译生成，用于 boot 分区。 - dtbo 文件：
sm8250-xiaomi-alioth-overlay.dtbo— 由 overlay DTS 编译生成，用于 dtbo 分区。 - dtb.img：多个 dtb 打包而成，包含同一平台下所有兼容板型的设备树。
常见陷阱：部分厂商在 Vendor 目录下直接放置
.dtsi 文件而非 .dts 文件，这会导致编译系统无法识别为独立板型入口。正确的做法是：Vendor 目录下只放 .dts（或 -overlay.dts），所有共享配置通过 #include 引用 Platform 目录或芯片级 .dtsi。
3.6 多板型场景下的目录组织策略
当一个 Vendor 在同一平台下维护多个板型时，推荐采用以下目录组织方式：
kernel/arch/arm64/boot/dts/qcom/vendor/xiaomi/
├── sm8250-xiaomi-alioth.dts # 主 DTS
├── sm8250-xiaomi-alioth-overlay.dts # DTBO 覆盖
├── sm8250-xiaomi-cas.dts # 另一款设备
├── sm8250-xiaomi-cas-overlay.dts
├── sm8250-xiaomi-renoir.dts
├── sm8250-xiaomi-renoir-overlay.dts
│
├── dtsi/ # 可选：项目级共享 .dtsi
│ ├── sm8250-xiaomi-common.dtsi # 小米通用配置
│ ├── sm8250-xiaomi-camera.dtsi # 相机模组配置
│ └── sm8250-xiaomi-display.dtsi # 显示面板配置
│
└── overlays/ # 可选：多个 overlay 片段
├── sm8250-xiaomi-alioth-overlay.dts
└── sm8250-xiaomi-cas-overlay.dts
最佳实践：
- 按项目分组：每个产品系列使用独立的子目录或前缀，避免文件混乱。
- 共享 .dtsi 下沉：将同品牌下多个板型共用的配置提取到
dtsi/子目录，减少重复。 - Overlay 与主 DTS 同目录：保持 overlay 文件与主 DTS 在同一层级，便于编译脚本统一处理。
- 避免深层嵌套：Vendor 目录下最多两级子目录（品牌/项目），过深会导致编译路径过长或引用混乱。
3.7 目录结构对编译系统的影响
Android 编译系统通过 device/ 目录下的 BoardConfig.mk 或 AndroidBoard.mk 指定 DTS 路径：
# device/xiaomi/alioth/BoardConfig.mk
BOARD_KERNEL_DTS := qcom/vendor/xiaomi/sm8250-xiaomi-alioth.dts
BOARD_DTBO_IMAGE := qcom/vendor/xiaomi/sm8250-xiaomi-alioth-overlay.dtbo编译系统根据这些变量，在 kernel/arch/arm64/boot/dts/ 下查找对应文件。因此，目录结构的任何变动（如重命名目录、移动文件）都必须同步更新 BoardConfig.mk，否则会导致编译失败。
| 编译产物 | 源文件路径（示例） | 输出路径 |
|---|---|---|
| dtb | qcom/vendor/xiaomi/sm8250-xiaomi-alioth.dts |
arch/arm64/boot/dts/qcom/vendor/xiaomi/sm8250-xiaomi-alioth.dtb |
| dtbo | qcom/vendor/xiaomi/sm8250-xiaomi-alioth-overlay.dts |
arch/arm64/boot/dts/qcom/vendor/xiaomi/sm8250-xiaomi-alioth-overlay.dtbo |
| dtb.img | 多个 dtb 打包 | out/target/product/alioth/dtb.img |