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.
