简介这份文档面向高通平台开发与调试工程师系统梳理了QPST、QRCT、QXDM、Trace32四款常用调试工具的功能定位与使用要点适合刚接触高通芯片调试、需要快速建立工具认知框架的初中级开发者参考。资源包内仅含1个docx文件约45KB以文字说明形式集中呈现各工具的核心用途QPST负责文件传输、EFS浏览与代码烧录QRCT用于射频配置与测试QXDM专注日志查看与故障排查Trace32则基于JTAG实现底层内核调试。内容预览显示文档对QPST的五个客户端组件、QRCT的FTM模式与QMSL通信机制、QXDM的日志分析能力均有展开说明并提及可结合官方user guide快速上手。目前已有158人学习适合作为调试工具入门索引帮助读者在较短时间内厘清各工具的分工边界与典型应用场景。1. 高通平台常用调试Tool介绍从死机日志到性能瓶颈一套工具链怎么串起来做高通平台底层的兄弟大概都有过这种体验板子跑着跑着突然重启串口只留下一行冷冰冰的 “Kernel panic”或者某个场景帧率莫名其妙掉一半抓了半天 log 也看不出所以然。这时候真正拉开效率差距的不是谁更懂内核源码而是谁手里那套调试工具用得熟。高通平台常用调试Tool介绍这件事本质上不是背工具清单而是搞清楚“什么现象该用哪个工具、参数怎么配、日志里哪一行才是关键”。它面向的是做驱动、BSP、系统稳定性、性能优化的工程师尤其是刚接手高通平台、面对一堆 QXDM、T32、Perfetto 不知道从哪下手的同学。这篇不堆概念按“先能抓到数据、再能看懂数据、最后能定位根因”的顺序把常用工具串成一条能复现的链路。2. 抓现场崩溃与重启类问题该上哪些工具崩溃类问题的核心矛盾是现场转瞬即逝等你反应过来板子已经重启了。所以这一章的重点不是分析而是“怎么在第一时间把现场留下来”。高通平台在这块给的工具有点多但真正高频用的就那么几个选错了要么抓不到要么抓到了看不懂。2.1 RAMdump 与 crashdump死机后第一份要拿到的原始数据板子异常重启后最先要确认的是有没有生成 RAMdump。高通平台的 RAMdump 是内存的完整镜像配合对应的符号表vmlinux System.map才能解析出崩溃时的调用栈。常见做法是在 fastboot 或引导阶段配置好 dump 的落盘路径让它重启后自动把内存写到 eMMC 或通过 USB 导出。# 常见做法进入 fastboot 后确认 dump 相关分区与导出方式 fastboot devices # 部分平台通过 crashdump 模式导出具体命令随平台引导配置不同 # 导出后本地用解析脚本还原调用栈 python parse_ramdump.py --vmlinux ./out/vmlinux --dump ./DDRCS0.BIN --out ./parsed这里的逻辑是--vmlinux提供符号信息--dump指向原始内存镜像解析脚本负责把物理地址映射回函数名。参数上最容易翻车的是符号表版本——vmlinux 必须和出问题那版固件严格对应差一个编译配置栈回溯就可能指到完全不相干的函数上。我一般会先把固件版本号和 vmlinux 的 build id 对一遍再解析省得后面白忙。2.2 串口日志与 dmesg别小看最土的办法很多人一上来就奔着高级工具去结果忽略了串口。实际上内核 panic、watchdog 触发、早期启动失败这类问题串口日志往往是最完整、最不容易丢的。关键是把串口日志级别调对默认的 loglevel 可能把关键信息过滤掉了。# 提高内核日志级别确保 panic 前后的信息都打出来 echo 8 /proc/sys/kernel/printk # 实时抓串口落盘保存方便事后比对 # 常见做法是用 minicom 或脚本持续记录printk里的 8 表示所有级别都输出平时可以设低一点减少噪音但复现崩溃时一定要拉满。串口日志的价值在于时间线完整配合 dmesg 的时间戳能看出是哪个驱动先出问题、哪个是连锁反应。坑在于串口本身可能丢数据波特率太高或线材质量差都会导致日志断片所以关键复现建议降波特率、用带硬件流控的线。2.3 QXDM抓 modem 与系统级 trace 的主力如果问题涉及 modem、RIL、或者需要看系统级的 trace 事件QXDM 基本绕不开。它能抓 QXDM log、配置 mask、实时看信令流程。新手最容易犯的错是 mask 开太多抓出来的 log 几个 G打开就卡死。# QXDM 常见操作路径界面操作非命令行 # 1. 连接设备选择对应端口 # 2. 在 Filter 里按模块勾选需要的 mask不要全开 # 3. 开始抓取复现问题后停止并保存 .isf 或 .dlf # 4. 用 QCAT 做离线解析和过滤mask 的选择是门手艺先按问题域缩小范围比如只关心 modem 就只开对应子系统的 mask抓完再用 QCAT 按时间窗和关键词过滤。参数上注意 log 的环形缓冲大小太小会覆盖早期数据太大又占内存。我一般会先小范围抓一轮确认方向再放大 mask 做完整复现。3. 看性能CPU、GPU、内存瓶颈怎么量化性能类问题和崩溃类正好相反现场一直在但你不知道瓶颈在哪。这时候工具的作用是把“感觉卡”变成“具体哪个核、哪个频点、哪段耗时”。高通平台在这块的工具体系比较完整从内核态到用户态都有覆盖。3.1 Perfetto 与 systrace系统级时间线的正确打开方式Perfetto 现在是高通平台性能分析的主力systrace 基本被它取代。它能同时看 CPU 调度、频率、GPU、内存、以及应用层的自定义 trace 点。核心价值是把多个子系统的时间线对齐到同一根时间轴上一眼看出是谁在等谁。# 常见做法用 Perfetto 抓一段系统 trace # 通过 adb 触发配置 trace config 文件 adb shell perfetto -c /data/misc/perfetto-configs/default.cfg -o /data/misc/perfetto-traces/trace.pftrace adb pull /data/misc/perfetto-traces/trace.pftrace # 本地用 ui.perfetto.dev 打开分析trace config 是关键里面决定了抓哪些 category、缓冲区多大、抓多久。category 开太多会导致数据量爆炸且丢事件开太少又看不到关键路径。我一般会先确认要分析的场景只开相关的 atrace category 加上调度和频率抓 5 到 10 秒足够。分析时重点看三样大核有没有被拉起来、任务有没有被迁移、有没有长时间的 runnable 但没跑上的情况。3.2 频率与功耗别让降频背了性能的锅很多时候性能掉不是代码问题是热或者功耗策略把频率压下去了。这时候要看的是各簇的实时频率和温度。# 查看 CPU 各簇当前频率 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq cat /sys/devices/system/cpu/cpu4/cpufreq/scaling_cur_freq # 查看温度 cat /sys/class/thermal/thermal_zone*/temp # 查看频率统计判断是否长期被限频 cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_statetime_in_state能告诉你一段时间内各频点停留了多久如果高频段几乎没待过那性能问题很可能就是限频导致的。参数上注意不同平台的簇划分不一样cpu0 和 cpu4 不一定对应大小核得先确认拓扑。坑在于有些平台的频率节点是只读的或者被 vendor 的调频策略接管直接写值不一定生效得走对应的调频接口。3.3 内存与 IO被忽视的隐形瓶颈CPU 和 GPU 都正常但就是卡这时候要怀疑内存带宽和 IO。高通平台可以用 devfreq 和内存带宽监控来看。# 查看 DDR 频率与带宽相关节点 cat /sys/class/devfreq/*/cur_freq # 查看内存统计 cat /proc/meminfo # 查看 IO 等待 cat /proc/pressure/io/proc/pressure/io里的 some 和 full 值能反映 IO 争抢程度如果 full 持续偏高说明有任务在等 IO。内存这块重点看 available 和 swap 使用高通平台很多设备没有 swap一旦内存吃紧就是直接触发回收甚至杀进程。常见误用是只看 free 不看 availablefree 低不代表有问题available 才是能用的量。4. 避坑与排查这些工具用错比不用还糟工具本身不复杂复杂的是现场。下面几条都是实打实踩过的坑按“现象 → 原因 → 解决”整理能帮你少走弯路。4.1 解析出来的调用栈全是问号现象RAMdump 解析后栈回溯一堆???完全没法看。原因vmlinux 和出问题的固件版本不匹配或者 KASLR 偏移没处理。解决先核对 build id确认符号表版本如果开了 KASLR解析时要带上正确的偏移参数别用默认值硬解。4.2 QXDM 抓出来的 log 打不开或卡死现象抓了几个 G 的 logQCAT 打开直接卡住。原因mask 全开导致数据量远超预期且包含大量无关模块。解决按问题域重新配置 mask只开相关子系统抓取时设置合理的环形缓冲和分段保存别一个文件抓到底。4.3 Perfetto 抓不到自定义 trace 点现象代码里埋了 trace 点但 Perfetto 里看不到。原因category 没在 trace config 里启用或者 atrace 的 tag 没对上。解决确认 config 里的 category 和代码里用的 tag 完全一致注意大小写用户态的自定义 trace 需要对应的库正确初始化。4.4 频率统计和实际体感对不上现象time_in_state显示高频待得挺多但用起来还是卡。原因统计的是历史累计值不是当前窗口或者瓶颈根本不在 CPU 而在 IO 或 GPU。解决抓取前后各读一次做差值缩小时间窗同时用 Perfetto 看 GPU 和 IO 的时间线别只盯着 CPU。4.5 串口日志关键时刻断片现象崩溃前几行日志丢失正好缺了最关键的信息。原因波特率过高导致丢数据或者缓冲区溢出。解决复现时降低波特率启用硬件流控内核侧适当增大 log buffer必要时用 pstore 把 panic 日志存到持久分区。5. 把工具串成链路一个可复用的排查习惯工具会用了之后真正的效率来自“固定链路”。我自己的习惯是任何问题先分两类——崩溃类先保现场串口 RAMdump性能类先抓时间线Perfetto 频率。现场保住之后再谈分析顺序反了就是白干。具体到操作上我会在板子上常备一套脚本一键完成“提 loglevel、抓串口、存频率快照、触发 Perfetto”这几件事复现时直接跑省得手忙脚乱。下面这个思路可以照着改#!/bin/bash # 一键抓取基础现场信息按需裁剪 echo 8 /proc/sys/kernel/printk cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq /data/cpu_freq_snapshot.txt cat /proc/pressure/io /data/io_pressure.txt # 触发一段短 trace具体 config 按场景替换 perfetto -c /data/misc/perfetto-configs/quick.cfg -o /data/misc/perfetto-traces/quick.pftrace这套脚本的价值不在于多高级而在于把“抓现场”这个动作标准化避免每次复现都靠记忆去敲命令。参数上按平台微调路径config 按问题域换。再往上一层是建立自己的“现象 → 工具 → 关键字段”对照表。比如重启先看 pstore 和 RAMdump卡顿先看 Perfetto 里的 runnable 和频率modem 相关先看 QXDM 的信令流程。这张表越用越准慢慢就变成肌肉记忆。我踩过最大的坑就是一开始贪多什么工具都想上结果现场没保住、时间全花在配工具上。后来才明白调试工具的核心不是多而是“在对的时间抓到对的数据”。希望帮到你。本文还有配套的精品资源点击获取
