Generic riscv chip via JTAG uses ARM driver

[andreasWallnerIFX]

Generic riscv chip via JTAG uses ARM driver

[Tiwalun]

probe-rs infois a bit of a special case, because it tries to autodetect the connected chip. I'm not sure if it even considers the chip argument.

What happens if you try something like probe-rs debug --chip riscv?

[bugadani]

I'm inclined to remove or rename probe-rs info. It's just not useful for anything non-ARM currently (even if some other chips may have coresight compatible components). info is very brute-force, and there's a very good chance it does something evil to the connected device, because it's essentially sending random bits to something unknown and hoping it'll understand.

the ID is read correctly
the TAP is detected correctly (IR length 8, 1 tap)

💓

which seems to want to do a SWD reset.

Ugh... Anything related to protocols is a mess currently 😭

The core itself implements the RISC-V debug spec v0.13.2 - but I guess this should make a difference since probe-rs never reads the version?

It should, if it gets to that point:

probe-rs/probe-rs/src/architecture/riscv/communication_interface.rs

Lines 451 to 457 in 88d09eb

	let status: Dmstatus = self.read_dm_register()?;
	self.state.progbuf_cache.fill(0);
	self.state.debug_version = DebugModuleVersion::from(status.version() as u8);
	// Only version of 0.13 of the debug specification is currently supported.
	if self.state.debug_version != DebugModuleVersion::Version0_13 {

[Tiwalun]

I'm inclined to remove or rename probe-rs info. It's just not useful for anything non-ARM currently (even if some other chips may have coresight compatible components). info is very brute-force, and there's a very good chance it does something evil to the connected device, because it's essentially sending random bits to something unknown and hoping it'll understand.

The whole reason info exists is to help with developing probe-rs, it was never intended to be a public tool. But people liked the CLI examples in probe-rs so much that they became an actual tool... 😄

Maybe we should move it back to an example, but I would very much like to keep it, it is very useful when looking at ARM chips.

[andreasWallnerIFX]

probe-rs infois a bit of a special case, because it tries to autodetect the connected chip. I'm not sure if it even considers the chip argument.

That explains my initial issue - I thought I'd start out with a simple command 😢

The core itself implements the RISC-V debug spec v0.13.2 - but I guess this should make a difference since probe-rs never reads the version?

It should, if it gets to that point:

Above I meant that it shouldn't make a difference since probe-rs never got that far, that's all good now

What happens if you try something like probe-rs debug --chip riscv?

That looks much better, but still does not work - I'll have to go through the log to see what's happening and why it's failing, but will do that tomorrow. Been a long day already...

[andreasWallnerIFX]

Ok - the remaining issue that I have seems to be in our silicon - not probe-rs 💯

OpenOCD is happy to continue, increase the idle cycles to a number where our silicon starts to work - which hid the issue so far.

What would you think of a setting to overwrite the number of idle cycles that are read from the card? (Not a real fan of the auto-increment in OOCD). I'd be happy to make a PR - but only if you would be fine with such a thing... (also totally fine if you don't think it fits - it's certainly a niche use-case to have to overwrite info that the chip provides)

[andreasWallnerIFX]

Maybe to expand a bit on the issue here since I'm not 100% sure on how to read the debug spec.
What happens is:

• scan chain detection & IDCODE work as expected
• dmcontrol is written to 0x0001
• dmstatus is read - this read returns a "BUSY" sticky response (this read writes 0x44000000001 to the DR)
• dmstatus is immediately read again - it now successfully reads 0x00000001

The value read from dmstatus is inconsistent (incorrect version, also some other bits are incorrect)

OpenOCD will in this case add additional IDLE cycles until there is no busy response anymore.
I guess they read the RISC-V debug spec v1.0, 6.1.5 - where the op description in the table says about the busy state: "If a debugger sees this status, it needs to give the target more TCK edges between Update-DR and Capture-DR" and decided to in these cases ignore the reponse from the DUT.

What I'm not sure about: On the other hand there is the note in 6.1.5 stating that "In Update-DR, the DTM start the operation specified in op unless the current status reported in op is sticky - which to me does not explicitly invalidate the command sent before (and I couldn't find an indication for that anywhere else in the spec...

But also the text for "In Capture-DR, the DTM updates data with the result from that operation, ..."

If the operation did not happen (because the status is busy) then the question is what that operation refers to - the one that was ignored, or the previous one.

EDIT: the more often I read that part of the spec, the more I think that OpenOCD is doing the right thing here (we should have put the correct number of needed idle cycles into the dtmcs register, but the spec does have the mandate to increase the number in case of busy responses...

Here also two picture from the logic analyzer to help the description (just snipping out a bunch of idle time):