Hello Improper CatGirl, Your proposal to separate the RISC-V transport specific code (DTM-specific logic) from the rest of the RISC-V code sounds perfectly fine to me. I support that direction.
Nevertheless, I am afraid that I won't have enough time to review your current implementation in near term. As a hint: You may also want to check the patch [1] (or an attempted split of that patch [2]) which aims to introduce a DTM as a separate entity in OpenOCD's Tcl configuration files. It sounds like that effort is at least somewhat related to your work. Regards, Jan [1] https://review.openocd.org/c/openocd/+/9695 [2] https://review.openocd.org/c/openocd/+/9760 + related series of patches ________________________________ From: Improper CatGirl <[email protected]> Sent: Wednesday, July 15, 2026 2:12 PM To: [email protected] <[email protected]> Subject: [RFC] riscv: decouple Debug Module logic from the JTAG DMI transport Some people who received this message don't often get email from [email protected]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Hello, I have been working on support for a non-JTAG RISC-V debug transport and would like feedback on decoupling OpenOCD's RISC-V Debug Module logic from its current JTAG DTM implementation. Background The RISC-V debug architecture separates the Debug Module Interface (DMI) and Debug Module from the transport used to access them. The specification defines a standard JTAG DTM, but the spec specifically said implementations may provide access to DMI through any other transport. OpenOCD's current RISC-V implementation hard coded the assumption of JTAG. The riscv-013 code directly uses JTAG TAPs, IR and DR scans, DTMCS operations, idle cycles, and JTAG-oriented DMI batches. Consequently, a target that provides standard RISC-V DMI semantics over a non-JTAG transport cannot reuse the existing RISC-V Debug Module implementation. Proposed direction I propose introducing a transport-neutral DMI operations layer between the RISC-V Debug Module implementation and the transport-specific code. A transport backend would provide operations for initialization, DMI reads and writes, DMI reset, and preferably batched DMI transactions. Details that are specific to the JTAG DTM, such as IR selection, DTMCS scans, run-test/idle cycles and BSCAN tunneling, would remain in the JTAG backend. Use case and proof of concept I have a working proof of concept for WCH RISC-V devices. These devices use WCH's non-JTAG debug connection, therefore, cannot be supported by OpenOCD in its current form. The proof of concept includes: an adapter driver for the proof-of-concept probe; a demonstration abstraction for non-JTAG DMI transactions; support for WCH devices as the initial test targets; and working debug access through the existing RISC-V Debug Module operations. Repo: https://github.com/ImproperCatGirl/openocd https://github.com/ImproperCatGirl/RVSWD_pico This is intended solely as a dirty architectural demonstration. I am not assuming that the current interface or patch organization is suitable for upstream in its present form.
