OpenOCD source code for CH32V series MCUs released by Mounriver IDE

[kprasadvnsi]

I have requested the OpenOCD source code from Mounriver and today I received it. This might help your reverse engineering efforts.

https://github.com/kprasadvnsi/riscv-openocd-wch

[fxsheep]

Thank you for this. Actually I'm glad/surprised to see them provided GPL sources.
My further plan includes further reversing the transport protocol strictly on-wire, then implement an opensource RVSWD debug adapter, since REing WCH-Link firmware isn't feasible (mcs-51 disassembly, with thousands of NOPs used for protocol timing) nor legal (not GPL-derived).

However, I don't find it possible to get upstreamed(sadly). Both fully-custom DTM and too-buggy DM makes it not near compatible with mainstream RISC-V designs and OpenOCD framework.

[josuah]

Could someone point at the discussion about getting it upstreamed?
I cannot seem to find it at https://sourceforge.net/p/openocd/mailman/search/?q=ch32v&mail_list=all

[fxsheep]

@josuah Thank you for your interest in this project. Unfortunately, all existing WCH RISC-V implementation has major breakage of the specification. This is beyond custom 2/1-wire protocol ("physical layer"), to the extent of how OpenOCD on RISC-V works. WCH RISC-V is NOT compatible with OpenOCD, thus workarounds in this fork is never meant to be upstreamed.

[josuah]

[UPDATE: I misunderstood this as being a fork due to OpenOCD refusing merging this upstream, while it was not submitted in the first place. See @karlp comment below.]

Marvellous effort to support hellish deviations getting in the way of upstreaming.

It is not really possible for OpenOCD team to say "ask the foundry to apply this silicon patch on the debugger core and we will support it".

I understand why OpenOCD wants to avoid breaking everything just for one chip support.
Not an easy choice.
Would require manpower to reunify everything and maintain it.
Not choosing anything would be letting the forks proliferate.

Summarizing this thread: https://www.eevblog.com/forum/microcontrollers/wch-$0-10-risc-v-mcu/?all

• WCH wanted fewer pins than the 4 of JTAG, here just 1.
• WCH would have to pay ARM money for SWD
• WCH did not bother either to go with https://riscv.org/wp-content/uploads/2019/03/riscv-debug-release.pdf

One more protocol on the wall... implement one down, pass it around...
Thank you again for your efforts.

[josuah]

For anyone wanting to keep things reasonably simple with all the forks of OpenOCD, here is something that can be done:

While compiling:

PREFIX=/usr/local/share # edit to your preferred installation root
./configure --prefix="$PREFIX" --program-suffix=-wchlink [...] --datarootdir="$PREFIX/openocd-wchlink"

This will create a command named openocd-wchlink-rv instead of openocd.

Then, for instance in a Makefile, it is common to have a variable holding the name of the tool:

OPENOCD = openocd-wchlink-rv

flash:
	$(OPENOCD) [...]

[karlp]

one correction: this repository, and the work done here all predates the ch32v003. Ie, it targets WCH's "proprietary" two wire interface, similar to SWD. CH32v003 brought in another proprietary interface, using one wire. mounriver's gpl tarballs, including the latest version (1.60 at time of writing) here: https://github.com/karlp/openocd-hacks/commits/mrs-wch-riscv-221010 supports both styles, via the new required wch-link-E hardware.

openocd is completely ok with hardware specific hacks/"customizations" but they have to be done in a way that doesn't break all existing code, that's all. And wch/MRS's current style of "take over everything" is obviously never going to fly.