为何设备树本应替代board file却仍需二者配合使用？

首先需要明确：你观察到的根节点compatible属性匹配board file的场景，大多出现在仍处于迁移过渡期的ARM32架构平台、以及存在特殊定制需求的旧平台，当前主流的ARM64平台已经基本实现了无board file启动，完全通过设备树完成硬件匹配与驱动加载。

两者存在配合需求的具体原因如下：

• 历史兼容与迁移成本控制
  设备树普及前，Linux内核中已经积累了海量针对不同开发板编写的硬编码board file，一次性全部删除重构的迁移成本极高。用根节点compatible做匹配入口，可以在保留原有成熟板级初始化逻辑的前提下，把硬件资源描述的工作迁移到设备树实现，平滑完成适配过渡，不需要对老平台的内核代码做大规模改动。
• 非标准化板级逻辑的承载需求
  设备树的定位是静态硬件属性描述载体，不适合承载流程类、逻辑类的板级操作。部分开发板存在无法通过标准化设备树属性描述的特殊需求，比如硬件勘误的早期 workaround、自定义上电时序控制、特定引脚的启动前电平配置等，这类逻辑仍然需要放在board file中，通过compatible匹配到对应板卡后执行。
• 老旧子系统的适配过渡
  部分内核老旧子系统尚未完成全设备树适配，无法直接解析设备树节点完成初始化。此时board file会承担胶水层的作用：先从设备树中读取对应硬件参数，转换成老版本子系统支持的入参格式后再完成初始化，待对应子系统完成设备树适配后，这部分board file代码即可被移除。
• 同系列板卡的代码复用需求
  对于同一款SoC衍生的多款开发板而言，90%以上的板级初始化逻辑是通用的，只有少量差异化配置。此时可以把通用逻辑统一放在同一份board file中，通过compatible属性区分不同板卡，仅执行少量差异化代码，比为每款板卡在设备树中单独定义特殊属性的复用效率更高，也符合内核代码的维护规范。

内容的提问来源于stack exchange，提问作者user3693586