Hello, the RaspberryPi chip RP2350 has Risc-V behind ARM DAP, no DTM as far as I understand. There is a fork of OpenOCD that already addresses RP2350. I hope to see it upstream soon. See the thread in https://sourceforge.net/p/openocd/mailman/openocd-devel/thread/CAAj6DX2tjx5893gJYK_LhWFAOt_J6XTG32DRkie4Wvw14h-_3A%40mail.gmail.com/#msg59241351
Said that, any contribution to OpenOCD is welcome! Feel free to propose your work by following the hints in the file HACKING. Regards Antonio On Thu, Jul 16, 2026 at 8:23 AM Jan Matyáš <[email protected]> wrote: > 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. > > > >
