“高通近期開源了其強大的嵌入式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/，經翻譯、校對