开源：Qualcomm/Snapdragon设备USB端口中隐藏的JTAG

“高通近期开源了其强大的嵌入式USB调试（EUD）接口源代码。这一举措有望彻底改变高通平台的底层开发与调试体验，使得以往需要昂贵专业设备的复杂调试工作，现在通过一根USB线即可轻松实现。”

今年二月，高通悄悄地发布了用于与 EUD 交互的源代码。这或许是他们近期所做的最激动人心的事情之一，特别是如果你花费大量时间调试内核或 U-Boot 的话。

EUD 的全称是Embedded USB Debug（嵌入式 USB 调试）：本质上，这是一个内置于几乎每一款自 2018 年以来高通 SoC 的调试接口。在内部，它深入到 SoC 的核心，不仅为 CPU 提供调试功能，还为无数的 Hexagon 协处理器/DSP 提供支持。许多激动人心的细节可以在这份追溯到 2014 年的专利中找到：

https://patents.google.com/patent/US20160124822A1/en

在实践中，对于非生产设备（如开发板），EUD 可以通过写入几个寄存器然后启动 USB phy 来启用。与你可能预期的任何典型 USB 小工具不同，出现在你电脑上的是一个 7 端口的 USB 集线器，其中一个端口被“EUD 控制接口”占用。

通过发送正确的 USB 命令，第二个设备将会出现，这个设备暴露了一个SWD 接口！没错！SWD 直接通过 USB 数据线实现，无需外部工具，无需焊接，也无需昂贵的调试器。这种闭壳调试（几乎）让谷歌的 Suzy-Q 都相形见绌！

对于不熟悉的人来说：JTAG 和 SWD 都是用于调试设备内部 CPU 核的机制，就像你可以使用 GDB 来调试你电脑上的程序（或你 IDE 的集成调试器）一样。它们可以让你设置断点、暂停执行、检查寄存器、单步执行指令以及进行各种其他有用的操作。

代码的发布

相当长一段时间以来，高通在 CodeLinaro 上发布了一个引人注目的 OpenOCD 分支，承诺集成 EUD。然而，它依赖于一个当时专有的 EUD 库，该库仅对高通员工及其 OEM 合作伙伴开放。

设备端部分（启用 EUD 接口使其在你的电脑上显示出来）在一段时间内已在上游 Linux 中得到部分支持。去年八月，有人尝试为一些有额外需求的较新平台扩展此支持。这引发了一些关于内核策略的讨论：在 Linux 中拥有只能由某些内部软件使用的驱动程序，并且这些软件被高通及其付费合作伙伴所把持，这是否可以接受？答案似乎是否定的，这似乎足以推动高通朝着正确的方向前进，因为在沉寂了 8 个月之后，我们终于等到了！

代码终于发布了（https://github.com/quic/eud），同时更新了他们的 OpenOCD 分支，使其指向现在开源的库，太棒了！

让我们来试试…

src/swd_api.cpp:408:64: error: castfrom'std::nullptr_t'to'uint32_t'{aka'unsignedint'} loses precision [-fpermissive]408|    queue_swd_packet_special(swd_handle_p, SWD_CMD_STATUS, (uint32_t)NULL,&swd_status);` 

清理工作

公平地说，它几乎肯定可以在 Ubuntu 20.10 上用高通的 GCC 8.x 工具链正常构建。但那并不是大多数人正在使用的环境，我们必须修复这个问题！

事实证明问题不算太糟，只是一些小毛病。不过，他们不知何故启用了-Wall和-Werror标志，我们目前还不可能让所有代码都通过检查。

在所有东西都能构建之后，必要的修复（和一个全新的.gitignore文件）已经提交到了高通的仓库。

现在我们已经可以构建 EUD 了，可以用 OpenOCD 来试试。看起来他们是基于最新的 OpenOCD 0.12.0 版本进行修改的，非常好。但是等等，这个版本是 2023 年发布的，而 OpenOCD 仍在活跃开发中……所以这中间有两年的变更，而且：

; gitlog--oneline v0.12.0 up/master |wc-l10808

将近 11000 次提交！如果最终能将这些变更合并到上游就太好了，所以也许我们可以快速地进行一次 rebase，反正我们也需要将它指向清理过的 EUD 分支。

在高通为支持 EUD 所做的更改中，还有一些增加了 Hexagon 调试支持的补丁（似乎还有一些对 LLDB 的改进）。这些在过程中丢失了，但几乎肯定值得在某个时候研究一下。

所以，我们花了一天来修复和 rebase 一些代码库：

; ./src/openocd-f tcl/interface/eud.cfg-f tcl/target/qualcomm/qcom.cfgOpenOn-Chip Debugger0.12.0+dev-01935-g234bdc765544 (2025-04-02-15:20)Licensed under GNU GPL v2Forbug reports, read   http://openocd.org/doc/doxygen/bugs.htmlforce hard breakpointsInfo : Listeningonport6666fortcl connectionsInfo : Listeningonport4444fortelnet connectionsInfo :UsingEUD2.1.7Error:Translationfromadapter speedtokhznotimplementedInfo : adapter-specificclock speedvalue6Info : SWD DPIDR0x5ba02477Info : QCOM.cpu0: hardware has6breakpoints,4watchpointsInfo : [QCOM.cpu0] Examination succeedInfo : [QCOM.cpu0] starting gdb serveron3333Info : Listeningonport3333forgdb connectionsInfo : QCOM.cpu0 cluster0core0multi coreQCOM.cpu0 haltedinAArch64 state duetodebug-request,currentmode: EL0Tcpsr:0x00000000pc:0xffff95cf9a4cMMU: enabled, D-Cache: enabled, I-Cache: enabled

你可以在 linux-msm GitHub（https://github.com/linux-msm/openocd） 上找到 rebase 后的 OpenOCD 补丁，以及 README 文件中的一些快速入门说明。到目前为止，这已经在骁龙 845 上进行了测试，对于 855 和 865 应该也类似，我们只需修改启用寄存器，然后使用 Linux 或 U-Boot 启动一个 USB 小工具即可。然而，更新的 SoC 可能需要额外的更改，比如针对 SM8450 的这些更改。希望这些旧的补丁系列现在能够得到更新，因为工具方面的情况已经好多了！

实际用途

众所周知，Torvalds 本人并不支持在内核中使用调试器（尽管这没有阻止 kgdb 的出色工作），他曾在 2000 年写道：

我不喜欢调试器。从来没有，可能永远也不会。我不赞成通过单步执行代码来寻找 bug。

因此，JTAG 支持的实际用处确实取决于你的工作流程。在 Linaro 的高通落地团队中，由于成本和复杂性等典型原因，调试器从未成为我们工作的主要工具。然而，随着越来越多的精力投入到非内核领域，如 U-Boot 和 secure world，这种情况正在改变。

U-Boot 对我们来说是一个明显的例子，因为它目前在崩溃时不会提供堆栈跟踪，诊断有时会是一个艰巨的过程，而使用(gdb) bt（gdb 的 backtrace 命令）会让这个过程变得无限简单。

我们对 EUD 为调试垂直集成的 BSP（板级支持包）所带来的可能性特别感兴趣，尤其是当 TF-A、OP-TEE 和 U-Boot 通过 OpenEmbedded 的 Trusted Substrate 混合在一起时。

除了 SWD 外设，还有一个 COM (UART) 外设和一个 trace（追踪）外设。这些尚未被探索（也未集成到 OpenOCD 中），但它们应分别允许双向串行端口和 MMIO（内存映射 I/O）追踪。这些确实为生产环境中的闭壳调试开辟了一些更有趣的用例.这似乎是高通有意为之，EUD 作为生产签名过程的一部分被禁用，但可以通过一个（经过加密验证的）“调试策略”重新启用。

你能如何提供帮助

不同的 SoC 对调试基址和 CTI 基址寄存器使用不同的地址，启用 EUD 所需的额外更改也不同。如果你能在你的板子/SoC 上成功实现，请在 linux-msm 分支上提交一个 issue，让我们知道你是如何做到的。

此外，还有一个奇怪的现象，即 PRSR 寄存器的粘性复位位（sticky reset bit）总是被设置，这可能与 SMP（对称多处理）有关。目前，OpenOCD 的粘性复位行为已被禁用，但查明其原因会很有帮助。

SMP 支持目前也普遍缺乏。配置文件已更新（以 rcar 为参考）以定义多个 CPU 核心，但这在 Linux 中似乎无法正常工作。目前，如果你想实际调试你的内核，建议使用maxcpus=1启动。

你的设备上是否可用 EUD 似乎取决于多种选项：有用于配置允许何种调试功能的熔断位（fuses），以及支持可覆盖此行为的、由 OEM 签名的“调试策略”。在至少一款生产设备（OnePlus 6）上，EUD 似乎通过熔断位禁用了，但它却能正常工作。该设备还启用了非典型的“崩溃转储模式”，这表明 OnePlus 可能在发货时使用了一个宽松的调试策略，或许是无心之失。

最后，虽然拥有合适的 JTAG 来调试内核（尤其是当它如此轻松时！）当然非常有用，但显而易见的问题是：这能否用来获得更高执行级别的控制权？不幸的是，答案似乎是否定的。如果你确实设法在 EL2（执行级别 2）暂停了执行，所有寄存器都将读作 0，并且似乎做不了太多事情，至少在生产设备上是这样。如果你的板子表现不同，请务必告诉我们！

结论

EUD 为我们提供了一个巨大的新探索领域，并有潜力极大地改善在高通板子上进行底层调试的体验。我们为它现在被发布并可免费使用感到非常兴奋，并非常希望随着工具和驱动程序的更好集成，它将成为一种无缝的体验。

看到高通致力于改善开发者体验并使其平台更加开放的承诺继续体现在其行动中，真是太棒了。EUD 有潜力节省昂贵调试设备的大量资金，大幅减少设置时间，并使远程调试变得更容易（毫无疑问，它最终将被集成到我们现有的远程调试工具中）。简而言之，这为所有在高通平台上工作的人奠定了基础，我们迫不及待地想看到接下来的发展。

---

原文转载自https://www.linaro.org/blog/hidden-jtag-qualcomm-snapdragon-usb/，经翻译、校对