移植U-Boot至主线时Spacemit K1 Reset驱动未被探测

以下是针对该问题的具体排查方向：

• 设备树兼容性校验

  • 核对驱动文件reset-spacemit-k1.c中of_match_table的compatible字符串，必须与设备树reset-controller节点的compatible属性完全一致（大小写、标点符号都不能出错）。
  • 用fdt print /reset-controller命令查看设备树节点的reg地址，确认与SoC手册中Reset控制器的基地址匹配；同时用fdt addr验证设备树是否被正确加载到内存。

• 驱动注册与依赖检查

  • 检查驱动的U_BOOT_DRIVER定义，确保id、name、of_match字段配置无误，尤其是of_match要指向正确的匹配表。
  • 确认依赖配置已开启：必须确保CONFIG_DM_RESET已在defconfig中启用；另外检查Reset控制器挂载的总线（如AHB/APB）驱动是否已初始化，总线未就绪会导致驱动无法访问寄存器，probe直接失败。

• 编译链接验证

  • 查看编译日志，确认reset-spacemit-k1.o被正确编译：执行grep reset-spacemit-k1 build.log查看编译记录，或用nm u-boot | grep reset_spacemit_k1检查驱动符号是否存在。如果符号缺失，重新核对Kconfig中的依赖项是否满足，以及Makefile中obj-$(CONFIG_RESET_SPACEMIT_K1) += reset-spacemit-k1.o的配置是否正确。
  • 执行make savedefconfig生成当前配置文件，确认CONFIG_RESET_SPACEMIT_K1=y确实生效，避免因依赖项未满足导致该选项被自动关闭。

• 调试日志增强

  • 在驱动probe函数开头添加debug("Spacemit K1 reset probe triggered\n");这类早期调试输出，同时开启U-Boot的调试级别（启用CONFIG_DEBUG_UART、CONFIG_LOG_LEVEL_DEBUG），通过启动日志判断probe是否被调用，或在哪个环节失败。
  • 查看启动时的设备树解析日志，排查是否有reset节点被忽略、解析错误的提示信息。

• 初始化时序调整

  • 确认Reset控制器的初始化顺序是否晚于依赖硬件：若Reset控制器挂在APB总线上，需保证APB总线驱动先完成初始化。可调整驱动U_BOOT_DRIVER中的flags（如添加DM_PRE_RELOC）或depends字段，指定依赖的总线驱动。

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