Page-1

# 调试概述子系统在 Qualcomm^®^ SoC 上的其自己的执行环境中独立处理。本节介绍受影响子系统的工具、示例日志和故障排查方法。了解子系统中的差异和检查错误的方法对于诊断和排查此类异常很有用。下表列出了SoC上的重要子系统。表：SoC上的子系统 | 子系统 (Subsystem) | 说明 | | --- | --- | | 应用处理器子系统 (APSS) | 该主要子系统将 Qualcomm Linux 内核作为高级操作系统 (HLOS) 执行。 | | 应用数字信号处理器 (aDSP) | 该子系统称为低功耗音频子系统 (LPASS)，处理数字信号处理任务，例如音频编码/解码和语音识别。 | | 计算数字信号处理器 (cDSP) | 该子系统称为计算 DSP，执行计算密集型任务，例如与神经网络相关的计算。 | | Qualcomm^®^ 受信任执行环境 (TEE)/TrustZone (TZ) | 该子系统执行安全操作并利用 Arm® TrustZone® 架构。有关详细信息，请参见 [Qualcomm Linux 安全指南](https://docs.qualcomm.com/bundle/publicresource/topics/80-70018-11)。 | | 无线局域网处理器子系统 (WPSS) | 该子系统连接到 Wi-Fi 网络，传输和接收数据包，处理安全协议并确保稳定的网络性能。有关更多信息，请参阅 [Qualcomm Linux Wi-Fi 指南](https://docs.qualcomm.com/bundle/publicresource/topics/80-70018-14/introduction.html)。 | | Always On 处理器 (AOP) | 该子系统可以调节设备的电源。 | 除应用处理器外，所有子系统的软件都称为非 HLOS。要了解子系统的启动流程，参见 [Qualcomm Linux 启动指南](https://docs.qualcomm.com/bundle/publicresource/topics/80-70018-4)。 Note 请参阅 Qualcomm^®^ Linux^®^ 支持的[硬件 SoCs](https://docs.qualcomm.com/bundle/publicresource/topics/80-70018-115/soc.html)。 ## 调试工作流由于 Qualcomm SoC 上有许多子系统，因此请先确定问题首先发生的子系统。这有助于您调试相关子系统。应用处理器作为主要子系统，可检测其他子系统何时崩溃。例如，如果 aDSP 处理器子系统崩溃，则内核日志会捕获子系统重启 (SSR) 崩溃错误日志。因此，要识别需要调试的子系统，首先要验证内核调试消息。下图显示了识别错误和需要调试的组件的工作流程。 **图：识别受影响子系统的工作流程** 当内核 dmesg 日志未显示任何 panic 特征时，请验证 Qualcomm TEE 诊断 (diag) 日志中是否存在错误，例如非安全看门狗 bite 和片上网络 (NoC) 错误。以下部分描述了指示内核 panic、bug 和子系统崩溃问题的示例内核消息。 ### 识别内核 panic 和 bug 从内核 dmesg 日志中，您可以确定重置是内核 panic 还是 bug。以下是一些指示内核 panic 或 bug 的示例日志： - Panic（模式：一般错误） 18.800936: <6> Kernel panic - not syncing: Fatal exception 18.800938: <6> SMP: stopping secondary CPUs 18.800947: <6> CPU0: stopping Kernel panic - not syncing: Apps watchdog Bark received! - Bug（模式 1：由于内存损坏而强制崩溃） 12.899532: <6> BUG kmalloc-128 (Not tainted): Redzone overwritten 12.905418: <6> ----------------------------------------------------------------------------- - Bug（模式 2：驱动程序强制崩溃） 320.510769: <6> ------------[ cut here ]------------ 320.510781: <6> kernel BUG at /local/mnt/workspace/lnxbuild/project/trees\_in\_use/free\_tree\_platform\_manifest\_refs\_tags/drivers/platform/msm/ipa/ipa\_v3/ipa\_qmi\_service.c:955! - Bug（模式 3：由于锁定问题而强制崩溃） [ 180.993861] BUG: spinlock lockup suspected on CPU#0, swapper/0/0 [ 180.993883] lock: stop\_lock+0x0/0x18, .magic: dead4ead, .owner: swapper/6/0, .owner\_cpu: 6 [ 181.015629] Causing a watchdog bite! Note 大多数 bug 通常会导致内核 panic。有关调试内核问题的更多信息，请参阅 [Qualcomm Linux 内核指南](https://docs.qualcomm.com/bundle/publicresource/topics/80-70018-3/overview.html)。 ### 识别子系统崩溃问题您可以验证内核 dmesg 日志以确定重启是否是由于子系统崩溃造成的。例如，根据 `qcm6490.dtsi`（node：remoteproc\_adsp：remoteproc@3000000），以下日志表明aDSP子系统崩溃。 0x000000000A27652C | 5198.790423: qcom\_q6v5\_pas 3000000.remoteproc: fatal error received: err\_inject\_crash.c:413:Crash injected via Diag 0x000000000A276689 | 5198.801061: remoteproc remoteproc2: crash detected in 3000000.remoteproc: type fatal error 0x000000000A2767A1 | 5198.809602: remoteproc remoteproc2: handling crash #1 in 3000000.remoteproc 0x000000000A27688E | 5198.816837: remoteproc remoteproc2: recovering 3000000.remoteproc 0x000000000A276971 | 5198.823784: qcom\_q6v5\_pas 8a00000.remoteproc: subsystem event rejected ### 从 Qualcomm TEE 日志中识别系统问题此功能可供具有授权访问权限的许可开发者使用。关于指示 Qualcomm TEE 中错误的示例日志，请参阅 [Qualcomm Linux Debug Guide - Addendum](https://docs.qualcomm.com/bundle/resource/topics/80-70018-12A/identify_subsystem_to_be_debugged.html#identify_and_debug_errors_in_tz)。如果 Qualcomm TEE 诊断日志未显示任何错误，则问题可能是由于安全看门狗 bite 问题造成的。有关看门狗问题的更多信息，请参阅[硬件重置](https://docs.qualcomm.com/doc/80-70018-12SC/topic/general_system_debugging.html#reset-hardware)。有关 Qualcomm TEE 中调试问题的更多信息，请参阅 [Qualcomm Linux 安全指南](https://docs.qualcomm.com/bundle/publicresource/topics/80-70018-11/debug.html)。 ## 调试方法以下是两种调试方法： - **目标上调试** 目标上调试可解决软件问题。这种方法允许直接从实时设备访问大部分信息。使用 SSH 将 Linux 主机连接到实时设备。要设置 SSH，请参阅[使用 SSH 登录](https://docs.qualcomm.com/bundle/publicresource/topics/80-70018-254/how_to.html#use-ssh)。关于各种目标上调试功能的更多信息，请参阅[目标上调试功能](https://docs.qualcomm.com/doc/80-70018-12SC/topic/Debug-overview.html#on-target-debug-features)。 - **目标外调试** 这种方法使用日志而非实际设备，使其成为一种高效的调试方法。您可以使用内存 dump 或日志记录工具进行调试，并可以使用各类日志进行离线调试。由于 RAM dump 可采集大部分内存区域，但只能采集有限的硬件寄存器信息，因此，调试与硬件相关的问题可能是一个挑战。关于各种目标外调试功能的更多信息，请参阅[目标外调试功能](https://docs.qualcomm.com/doc/80-70018-12SC/topic/Debug-overview.html#off-target-debug-features)。 ## 目标上调试功能您可以在 runtime 在设备上使用以下调试功能： - Perf 工具 - 子系统重启 - 强制子系统复位 - [使用 OpenOCD 进行调试](https://docs.qualcomm.com/doc/80-70018-12SC/topic/debugging_linux_kernel.html#debug-using-openocd) ### Perf 工具 Linux 中的 Perf 工具可辅助进行性能分析。Linux 内核在 `tools/perf` 目录中包含此工具。您可以使用 Perf 工具调试系统行为的各个方面，包括 CPU 性能计数器、跟踪点、kprobe 和 uprobe（用于动态跟踪）。下表列出了 Perf 工具的主要功能。表：Perf 工具的主要功能 | 功能 | 说明 | | --- | --- | | CPU 性能计数器 | 这些 CPU 硬件寄存器用于跟踪已执行指令、缓存未命中和分支误预测等事件。这些事件构成了分析应用程序和识别性能瓶颈的基础。 | | 跟踪点 | 您可将这些跟踪点放置在代码的逻辑位置，例如系统调用、网络事件和文件系统操作处。这些跟踪点以最小的开销提供时间戳和堆栈跟踪等信息。 | | 动态跟踪 | 此功能使用 kprobe 和 uprobe 框架动态创建跟踪点，从而允许在内核空间和用户空间进行跟踪。 | 有关 Perf 工具的更多信息，请参阅以下资源： - [https://perf.wiki.kernel.org/index.php/Main_Page](https://perf.wiki.kernel.org/index.php/Main_Page) - [https://github.com/Linaro/OpenCSD/blob/master/HOWTO.md](https://github.com/Linaro/OpenCSD/blob/master/HOWTO.md) - [https://docs.kernel.org/trace/coresight/index.html](https://docs.kernel.org/trace/coresight/index.html) - [https://docs.kernel.org/trace/coresight/coresight-perf.html](https://docs.kernel.org/trace/coresight/coresight-perf.html) ### 子系统重启 (Subsystem restart) 子系统崩溃时可独立重启而无需设备重启，这称为子系统重启 (SSR)。SSR 功能使用 Linux 内核中可用的 remoteproc 框架。若要为调试目的启用完整内存 dump，需默认禁用 SSR 功能。建议在商用设备上使用 SSR 功能，不要在开发阶段使用。有关 SSR 功能的更多信息，请参阅 [Remoteproc 子系统](https://docs.qualcomm.com/bundle/publicresource/topics/80-70018-3/features.html#remoteproc-subsystem)。启用 SSR 功能可在子系统重启时生成 SSR dump。由于 SSR dump 的大小小于完整内存 dump 的大小，建议使用 SSR dump 进行调试。然而，调试某些子系统崩溃时仍需完整 RAM dump。有关如何启用和采集子系统 dump 的更多信息，请参阅[子系统 dump](https://docs.qualcomm.com/doc/80-70018-12SC/topic/debugging_linux_kernel.html#subsystem-ram-dumps)。 ### 强制子系统复位使用此功能调试需要重启子系统的用例。此功能可供具有授权访问权限的许可开发者使用。要强制重置子系统，可以使用 QXDM Professional^™^ 运行 `diag` 命令。有关 QXDM Professional 命令及其用法的更多信息，请参阅 [Qualcomm Linux Debug Guide - Addendum](https://docs.qualcomm.com/bundle/resource/topics/80-70018-12A/debug-non-hlos-subsystems.html#qxdm_professional)。 ## 目标外调试功能用户可以使用 RAM dump 或 QXDM Professional 进行离线调试。 ### RAM dump RAM dump 是发生故障时整个内存的拍照。您可使用多种工具分析 RAM dump，包括 Qualcomm^®^ Crash Analysis Portal (QCAP)、RAMParser、Lauterbach TRACE32 模拟器和 Crash utility。有关如何收集和解析 RAM dump 的更多信息，请参阅[收集和解析 RAM dump](https://docs.qualcomm.com/doc/80-70018-12SC/topic/debugging_linux_kernel.html#collect-and-parse-ram-dumps)。 ### QXDM Professional 使用 QXDM Professional 调试各种子系统。该工具可供具有授权访问权限的许可开发者使用。有关 QXDM Professional 命令及其用法的更多信息，请参阅 [Qualcomm Linux Debug Guide - Addendum](https://docs.qualcomm.com/bundle/resource/topics/80-70018-12A/debug-non-hlos-subsystems.html#qxdm_professional)。 ## 常见系统问题您可将系统问题分为以下类型之一： > > > - [Linux 内核空间问题](https://docs.qualcomm.com/doc/80-70018-12SC/topic/debugging_linux_kernel.html#debugging-linux-kernel) > - [系统问题](https://docs.qualcomm.com/doc/80-70018-12SC/topic/general_system_debugging.html#general-system-debugging) > > > > > > > > > - [看门狗问题](https://docs.qualcomm.com/doc/80-70018-12SC/topic/general_system_debugging.html#watchdog-timeout) > > - [总线 hang 和超时问题](https://docs.qualcomm.com/doc/80-70018-12SC/topic/general_system_debugging.html#erroneous-transaction-on-bus-error-and-timeout) > > - [硬件复位问题](https://docs.qualcomm.com/doc/80-70018-12SC/topic/general_system_debugging.html#reset-hardware) ## 其他问题可能遇到的其他各类问题如下： - 由于软件 bug 导致设备冻结问题 - Linux应用程序相关问题 - 由于 PCB 相关硬件问题导致的随机复位要调试 Linux 内核相关问题，请参阅[调试 Linux 内核空间问题](https://docs.qualcomm.com/doc/80-70018-12SC/topic/debugging_linux_kernel.html#debugging-linux-kernel)。要调试 Linux 应用程序相关问题，请参阅[调试 Linux 用户空间问题](https://docs.qualcomm.com/doc/80-70018-12SC/topic/using_open_source_debug_tools.html#using-open-source-debug-tools)。 Last Published: May 12, 2025 [Next Topic 调试 Linux 用户空间问题](https://docs.qualcomm.com/bundle/publicresource/80-70018-12SC/topics/using_open_source_debug_tools.md)