RISC-V support#292
Conversation
|
@esden reports reset does not work.
|
6e9af3e to
3960da4
Compare
|
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 |
|
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. |
FIXME: Use -O2 in Makefile again.
Use macros as pseudo-assembler for instruction encodings
Use macros as pseudo-assembler for instruction encodings
|
Hello, 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. |
Isn't BMP abstracted into layers? |
|
For the reboot issue can't we use |
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.
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 blackmagic/src/target/riscv_debug.c Lines 878 to 905 in 8c15dd4 |
First cut at RISC-V support, for single-hart rv32i.
Merge #291 first and then rebase.