定制 Linux 板调试：从电源轨到应用运行

作者LIU, ZHUOHUI

定制 Linux 板打印出登录提示，并不意味着板级调试已经完成。真正有用的里程碑，是从正确的供电与复位行为，到已验证启动镜像、正常外设驱动，以及能够从预期故障中恢复的应用，形成可重复验证的完整链路。

本文介绍基于设备树的嵌入式 Linux 板分阶段调试计划，重点面向 ARM 和 AArch64 设计。实际 SoC 启动 ROM、电源管理芯片、DDR 初始化组件和厂商 BSP 决定具体顺序。下列测试属于建议的工程检查，并非某一产品的实测结果。

1. 准备证据和恢复通道

上电前，收集原理图、装配版本、物料替代情况、电源树、DDR 拓扑、启动绑带设置和连接器引脚定义。对照参考设计检查实际装配板，而不是假定布局在电气上等效。确认装配后哪些调试引脚仍然可以访问。

准备适合电路板的限流电源、额定电压合适的仪器、已验证的串口适配器，以及厂商支持的恢复方式。TTL UART 必须与电路板电压域匹配，RS232 适配器不能直接替代。断开不受控负载，并检查 USB 或调试连接器是否造成意外供电通路。

按电路板序列号、硬件版本和镜像哈希建立调试日志。从接通电源开始保存完整串口输出。记录跳线状态，并区分真正冷启动与软件重启，避免把外设残留状态误认为初始化成功。

Linux 板调试的六个关卡：供电与复位、ROM 与加载器、DDR 与存储、内核与设备树、根文件系统，以及应用与恢复。
示意性阶段关卡：上一层具备证据及可恢复的失败路径后，再进入下一层。

2. 确认供电、复位和时钟

按照硬件团队流程，在上电前检查阻值和明显装配问题。上电后，根据所选器件规格验证各电源轨电压及顺序，捕获复位释放相对于电源稳定和时钟就绪的关系。万用表读数不能单独证明启动时序，也不能排除短暂瞬态。

如果电流异常，应停止并调查，而不是反复启动。如果没有串口输出，应检查电压域、引脚复用假设、波特率和启动源。有些启动 ROM 本来就不打印信息。应使用文档规定的恢复枚举或其他厂商指示，区分“ROM 正在运行”和“UART 没有输出”。

不要通过随意添加软件延时掩盖电气问题。延时可以帮助定位时序问题，但最终需求应明确真实依赖关系及允许时序。

3. 验证首级加载器、DDR 和启动存储

识别启动链中的每个可执行阶段。不同平台可能由 ROM 依次加载 SPL、厂商 DDR 初始化程序、安全固件和 U-Boot。记录各组件版本及打包偏移。有时看似 Linux 的问题，实际是镜像中打包了错误的 DDR 训练组件。

给应用施加压力前，先采用厂商支持的 DDR 验证流程及安全内存测试。不要对正在运行的加载器、保留固件区域或诊断缓冲区执行破坏性测试。在约定工作条件下重复冷启动。热启动成功不能证明冷启动 DDR 初始化正常。

对于 eMMC、SD 或其他存储，验证枚举、容量、总线设置及分区映射。通过文档规定的非破坏性方式，将读回数据与烧录镜像比较。如果问题只在更高速总线模式出现，应先调查信号完整性、电压切换、时序配置和驱动支持，而不是直接接受永久降速作为解决方案。

4. 向 Linux 传递正确的硬件描述

设备树描述硬件拓扑和资源，不会自动生成缺失驱动，也不能修复错误接线。时钟、稳压器、复位线、中断和引脚配置必须与装配板一致。Linux 设备树使用模型说明了它在平台识别、运行时配置和设备建立中的作用。

把内核、DTB、模块和固件文件作为同一个版本化发布集合维护。参考板遗留 DTB 可能仍可启动，却悄悄描述了错误的电源或中断。使用所选源码树提供的模式进行校验。内核 绑定文档区分了模式本身的检查与设备树数据检查。

# Run in the configured kernel source tree with its required tooling.
make dt_binding_check
make dtbs_check

这些检查能发现结构和绑定问题，但不能证明实际接线与描述一致。厂商内核可能使用较旧模式或未文档化扩展。应记录差异，而不是不加理解地消除警告。

对于 AArch64，引导程序交接还必须满足镜像放置、设备树和处理器状态等架构要求。应依据所选内核的 AArch64 启动协议，不要照搬无关电路板的加载地址。

5. 区分内核就绪与根文件系统就绪

内核启动但无法挂载根文件系统时，应核对根分区标识、存储驱动是否可用、文件系统支持和 initramfs 假设。如果驱动只编译成模块，而该模块又存放在尚未挂载的根文件系统内，除非更早的用户空间阶段加载它，否则无法帮助挂载该文件系统。保留第一条错误，而不只是最后的 panic。

用户空间启动后，确认预期 init 进程、可写位置、设备权限、时间初始化和服务依赖。验证正在运行的内核、模块及应用与发布清单对应。SSH 可以登录，并不能证明全部存储、网络及外设需求已经满足。

6. 每次打通一条外设路径

建立接口表，把连接器标签与 Linux 设备名、驱动名及应用角色对应起来。每个设备都要测试枚举、基本操作、预期负载、支持情况下的断开行为，以及重启行为。显示屏需要面板时序和背光控制；触摸控制器还需要独立验证中断和坐标。一个部分正常不代表另一个部分也已通过。

设备探测失败时，应先检查最早的依赖错误。稳压器、时钟、复位或固件缺失，可能导致后续症状看起来像驱动缺陷。采用定向调试输出，而不是打开所有信息。内核具备相应配置时，Linux 动态调试可按模块、文件或函数选择支持的调试输出点。

7. 交付应用之前测试恢复能力

  • 让一个可选外设故意不可用，验证必要服务仍达到约定就绪状态。
  • 应用运行期间断开测试网络，验证重试有界，恢复时不会重复执行命令。
  • 使用受控测试分区验证存储满的处理，确认日志不会占用应用必需的全部空间。
  • 在可恢复台架样机上执行约定的升级中断及损坏镜像测试，不要覆盖唯一恢复通道。
  • 重复冷启动、热重启及要求的休眠唤醒循环，并记录具体条件和失败情况。

如果持久崩溃日志使用 ramoops，应保留合适内存，并验证所选复位路径会保留内容。ramoops 并不能保证断电时不丢失数据，参见内核 ramoops 文档。验收证据应说明已捕获内容及仍未测试的部分。

板级调试的具体范围示例

欧蓓特的 RK3566 嵌入式终端与 BSP 适配项目方案描述了针对特定面板、通过 FPC 连接外设的终端。页面明确区分已经引出的接口与需要修改电路板才能使用的接口。板级调试计划应采用这样的边界，而不是假定 SoC 的所有功能都能在装配产品上使用。

进行 固件与 BSP 诊断评估时，请提供电路板版本、原理图、完整冷启动日志、镜像清单和最早失败的阶段。明确的阶段边界通常比“Linux 不能用”更适合作为行动起点。

类似文章