调试手段按「从软到硬」排：串口日志是最常用的一层，串口失效再上 JTAG；测试则分软件功能/压测和量产PCBA两级。本文基于触觉智能RK3576开发板演示，把这四块串成一套完整的调试与验收方法，分上下篇为大家分享。

开发期先用串口把日志调通，调不通再上 JTAG；验证阶段用 rockchip-test 做功能与压力，量产用 PCBA 测试逐模块体检。上篇先讲透开发期两条关键调试链路——console 与 loglevel 串口日志调通、OpenOCD + GDB 硬件级兜底，覆盖「板子起不来、日志断流、死在第一条指令之前」这一类最让人头疼的早期问题。造

console与loglevel调试

"串口就打印几行就停了"通常是两个原因：console 没从 earlycon 切换到正式 console，或日志级别太低把后面的输出滤掉了。把这两处调对，日志就源源不断了。

串口日志的输出链路是：

earlycon（早期）→ console=ttyFIQ0（正式）→ init 后用户态。

只看到几行的常见根因：

① console 参数没生效/波特率不对（后面的日志走不到串口）；

② 日志级别（loglevel）太低，把 INFO 以下的打印滤掉了；

③ 卡在内核早期（见 01.05，那是真问题）。

1、console 从哪来：earlycon → 正式 console

• 本 SDK bootargs（rk3576-linux.dtsi）：earlycon=uart8250,mmio32,0x2ad40000 console=ttyFIQ0；

• console=ttyFIQ0 是 RK 的 FIQ 调试口，内核编了 CONFIG_SERIAL_8250_CONSOLE=y 才能把 console 挂到串口；

• 波特率必须与 U-Boot 一致

  ，否则正式 console 一接管就"断流"（这经常被误读成"卡住了"）。
  
  

2、printk 与 loglevel

日志能不能上串口，由内核 printk 级别决定。运行时看/改 /proc/sys/kernel/printk（四个数字）：

启动时用内核命令行 loglevel=8（或 ignore_loglevel）能从一开始就全量输出；运行时用 echo "7 4 1 7" > /proc/sys/kernel/printk 临时调。

3、常见问题对照表

4、实操

# 1. 运行时把日志级别开到最大（临时）
echo "7 4 1 7" > /proc/sys/kernel/printk
# 2. 确认 console 设备与注册
ls /dev/ttyFIQ* ; dmesg | grep -i "console"
# 3. 启动参数带 loglevel 全量输出（改 dts bootargs，见 02.03 后重烧）
#    bootargs += "loglevel=8"
# 4. 串口抓取
minicom -D /dev/ttyUSB0 -b 1500000   # 波特率与内核一致

串口"只有几行"先分清：是 console 没接管（波特率/console 参数/CONFIG），还是 loglevel 太低（滤掉了）。前者查 console=ttyFIQ0 与波特率，后者 loglevel=8 或改 /proc/sys/kernel/printk。两处都对了，日志自然源源不断。

用JTAG兜底调试

串口没输出、内核起不来，往往是"太早期就死了"。这时候JTAG是唯一能"掀开盖板看寄存器"的手段——OpenOCD+GDB 可以停住CPU、看 PC/寄存器/内存。

JTAG/OpenOCD是串口失效时的兜底调试手段：它可以停住CPU（halt）、读PC/寄存器/内存、设断点，定位"死在第一条指令之前"的问题（如 DDR 初始化失败、时钟/电源没起来导致 CPU 卡死）。代价是需要 JTAG 调试器 + 目标配置文件，且早期阶段很多外设还没初始化。它定位的是"硬件/极早期初始化"问题，而不是驱动逻辑。

边界说明：官方文档 Common/DEBUG/..._GNU_MCU_Eclipse_OpenOCD_CN.pdf 侧重 MCU（RTOS/AMP）核调试；本文只讲主系统（A核）早期崩溃的 JTAG 思路。

1、什么时候需要它

2、OpenOCD 从哪来

• SDK 把它做成了 buildroot 包：buildroot/package/openocd/（openocd.mk），需要时在 Buildroot 里勾选打进系统；
• 官方调试文档：docs/cn/Common/DEBUG/Rockchip_Developer_Guide_GNU_MCU_Eclipse_OpenOCD_CN.pdf；
• 另外 RK 还提供 GPIO 级调试工具 PinDebug（tools/linux/PinDebug，Windows 版 tools/windows/pin_debug_tool_v1.17_...），用来查引脚/电平，和 JTAG 互补。

3、基本工作流

# 1. 准备好 JTAG 调试器（如 J-Link/ST-Link 等）+ 目标板 JTAG 接口
# 2. 启动 OpenOCD，加载目标配置文件
openocd -f interface/jlink.cfg -f target/<rk3576 或对应 target>.cfg
#     —— 监听 localhost:3333 (gdb)
# 3. GDB 连上去
aarch64-linux-gnu-gdb <vmlinux 或 u-boot elf>
(gdb) target remote :3333
(gdb) halt            # 停住 CPU
(gdb) info registers  # 看 PC/SP/通用寄存器
(gdb) x/16i $pc       # 反汇编当前指令
(gdb) break function_name
(gdb) continue

4、能力边界与提示

• 需要硬件

  JTAG 调试器 + 板上 JTAG 引脚（是否引出、复用到哪一组，见板级原理图/调试文档）；

• 需要匹配的目标配置

  目标板的 core、DAP/AP 地址等，SDK 没现成 RK3576 配置时需按 OpenOCD 模板适配（标注"推断"）；
• 早期段调试要连 <符号> 用带符号的 vmlinux/u-boot elf，配合 CONFIG_DEBUG_INFO_DWARF4=y（本 SDK 已开）看源码行。

串口都救不了的"极早期/硬件"问题，用JTAG + OpenOCD：halt 停 CPU → 看 PC/寄存器 → 断点/单步 → 对带符号的 vmlinux。它是调试链的最后一道手段，配合 buildroot 的 openocd 包与官方 OpenOCD 文档上手；引脚级问题用 RK 的 PinDebug工具。

上篇到此结束。串口能打通、JTAG能兜底，开发期「起不来」的问题基本就覆盖了。下篇进入验收量产测试，为大家分享功能验没验全、压力扛不扛得住、量产每块板怎么检验。

官方文档依据：

docs/cn/Common/UART/Rockchip_Developer_Guide_UART_CN.pdf
docs/cn/Common/UART/Rockchip_Developer_Guide_UART_FAQ_CN.pdf（串口与 FAQ）

SDK 源码依据：

kernel-6.1/arch/arm64/boot/dts/rockchip/rk3576-linux.dtsi（earlycon/console bootargs）
kernel-6.1/arch/arm64/configs/rockchip_linux_rk3576_defconfig（CONFIG_SERIAL_8250_CONSOLE=y、CONFIG_SERIAL_8250_DW=y、CONFIG_PRINTK_TIME=y）
kernel-6.1/arch/arm64/boot/dts/rockchip/rk3576.dtsi（uart2 节点）