RISC-V support #292

First cut at RISC-V support, for single-hart rv32i.

Merge #291 first and then rebase.

@esden reports reset does not work.

I think hard_srst and connect_srst reset everything including the jtag debug subsystem ... causing issues. also run seems to not restart the program from the beginning over here. start results in No registers.

Just a note for the casual visitor of this pull request. We have tested this code and it works as well as the OOCD target does. Unfortunately the RISC-V debug interface V11 that is implemented on the Freedom E310 silicon has a reset bug preventing 'run' 'start' and some other typical debug operations from working. This means all you can do is connect to the target and step through the code from the position where the code was at the moment of connection.

As it is only of limited usability for debugging purposes and does not have equivalent ease of use and expected feature set compared to the currently supported ARM targets we will not be merging the RISC-V support at the moment.

We will likely wait for the next generation of SiFive chips to become available with fully functional debug interface (V13) before we add RISC-V support to Black Magic Probe.

If you have questions or suggestions please feel free to leave them here, we will keep this pull request open for now. :)

Note: We are missing a flash stub to be able to use the load command and flash the firmware through the BMP. This will be added when we return to the RISC-V platform debugging.

I rebased the branch, hopefully with no colateral damage. GD32V103 uses debug version 1 not (yet?) supported.

Will this be merged soon then?

Probably not soon, as it only supports V0.11. I played around with it and the SiPeed Longan (GD32VF103) and had only problems and no success. Somebody has to care for V0.13...

Ah, that's unfortunate.

Rebased again.

Hello,
I don't understand the reason why this branch is not merged since there are now multiple RISC-V chips on the market (Gigadevice, Espressif). Are you waiting for at least one chip fully supported?

Thank you.

Hi arabine, this PR implements experimental support for RISC-V's older version 0.11 debug spec. This means it won't work for most of the current RISC-V chips. Because the support required to make either this or version 0.13 debug spec work requires some major work inside BMP to do, we are in the process of preparing the code base (v1.9). Support will land in v2.

TL;DR: It's a complicated problem and we're working on it but it takes time.

Ok thank you for your answer. I can help you testing if needed.

Hi arabine, this PR implements experimental support for RISC-V's older version 0.11 debug spec. This means it won't work for most of the current RISC-V chips. Because the support required to make either this or version 0.13 debug spec work requires some major work inside BMP to do, we are in the process of preparing the code base (v1.9). Support will land in v2.

TL;DR: It's a complicated problem and we're working on it but it takes time.

Isn't BMP abstracted into layers?
Higher layer saying write XZ to address Z and not caring about implementation details?

For the reboot issue can't we use NVIC_SystemReset();
it's implemented on RISC-V and CMSIS.

Hi arabine, this PR implements experimental support for RISC-V's older version 0.11 debug spec. This means it won't work for most of the current RISC-V chips. Because the support required to make either this or version 0.13 debug spec work requires some major work inside BMP to do, we are in the process of preparing the code base (v1.9). Support will land in v2.
TL;DR: It's a complicated problem and we're working on it but it takes time.

Isn't BMP abstracted into layers? Higher layer saying write XZ to address Z and not caring about implementation details?

Yes, but that's not relevant to the question - there are multiple versions of the RISC-V debug protocol that are in production, and supporting, eg, v0.13 protocol does not provide support for parts talking v0.11 protocol as they are incompatible. BMD was, at the time we answered, also suffering from a significant amount of ARM-specificity which inhibited the lower level layers from working correctly with RISC-V devices.

For the reboot issue can't we use NVIC_SystemReset();
it's implemented on RISC-V and CMSIS.

No, RISC-V processors do not have an NVIC (this is an ARM-specific) and this conflates the concepts of target firmware-induced reboot with debugger induced reboot, which are two entirely different mechanisms. The latter is driven by, for RISC-V debug, a mix of the nRST pin on the target, and registers in the DM - see github.com/blackmagic-debug/blackmagic@8c15dd459b/src/target/riscv_debug.c (L878-L905) for details.