之前我在一个 H15 的 SBC 开发板上遇到一块 8GB DDR，在 SCU-BL 阶段出现了如下报错：
最后的解决办法如下：
屏蔽掉 u-boot 代码中arch/arm/dts/hailo15-sbc.dts中的设置： ddr_config { dram_auto_detect_en = <1>; }; 同时在同一个文件中，引入对应正确的 8GB DDR 配置：hailo15_ddr_MT53E2G32D4DE-046_regconfig_8GB.dtsi这样就可以正常运行并使用 8GB DDR。
H15 启动机制研究
经过这件事情，我研究了 H15 的启动机制。H15 的启动流程大致如下：
| 阶段 | 运行处理器 | 核心任务 |
|---|---|---|
| BootROM | SCU (M4) | 从 Flash 加载 SCU-BL。 |
| SCU-BL | SCU (M4) | 读取配置，选择并加载 SCU-FW，管理启动重试。 |
| SCU-FW | SCU (M4) | DDR 训练与初始化；管理电源/复位；加载 SPL 并唤醒 AP。 |
| U-Boot SPL | AP (A53) | 从存储介质加载完整的主引导镜像束 (u-boot-tfa.itb)。 |
| TF-A | AP (A53) | 安全环境初始化，跳转至 EL1 环境。 |
| 主 U-Boot | AP (A53) | 运行引导脚本，加载并启动 Linux 内核包 (fitImage)。 |
| Linux 内核 | AP (A53) | 驱动硬件，挂载文件系统，启动用户空间应用。 |
获取未加密的 Device Tree 文件
在 SCU-BL 阶段，H15 会读取我们烧写到 Flash 中的 Device Tree：u-boot.dtb.signed。该文件是加密的，如果想获取对应的未加密 Device Tree 文件，可以按照如下方法操作：
进入 Yocto 编译目录：
build/tmp/work/hailo15_sbc-poky-linux/u-boot/1_2022.01-r0/u-boot-2022.01
你可以看到以下文件：
u-boot.dtb, u-boot-dtb.bin, u-boot-dtb.img, u-boot.dtb.signed
其中 u-boot.dtb 是原始 Device Tree Blob。 运行命令： file u-boot.dtb 输出会显示 "Device Tree Blob"，其中 Blob 表示原始数据。
获取纯净的 Device Tree 文件示例：
hexdump -C u-boot.dtb | head # 查看 offset 起始位置，H15 的起始位置为 0x00, 如果不为0x00可以用如下命令进行截取并利用dtc反解析 dd if=u-boot.dtb of=extracted.dtb bs=1 skip=123456 dtc -I dtb -O dts extracted.dtb > extracted.dts
这样就可以获得可读的 dts 文件，从中可以查看非常详细的 DDR 配置。
同理，也可以在 build/tmp/work/hailo15_sbc-poky-linux/linux-yocto-hailo/5.15.32-r0/deploy-linux-yocto-hailo 获取到 Kernel 对应的 Device Tree。
总结
简单来说，现代 Camera SoC 的 BSP（Board Support Package）定制中，DTS 的修改和管理确实是核心工作之一。能够获得最终版本的可读 DTS 文件，可以极大地方便确认 BSP 定制是否正常。
发表回复