Skip to content
This repository was archived by the owner on Mar 7, 2026. It is now read-only.

RISC-V support#292

Open
gsmcmullin wants to merge 19 commits intoblackmagic-debug:mainfrom
gsmcmullin:riscv
Open

RISC-V support#292
gsmcmullin wants to merge 19 commits intoblackmagic-debug:mainfrom
gsmcmullin:riscv

Conversation

@gsmcmullin
Copy link
Copy Markdown
Contributor

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

Merge #291 first and then rebase.

@gsmcmullin gsmcmullin added the Enhancement General project improvement label Oct 3, 2017
@gsmcmullin
Copy link
Copy Markdown
Contributor Author

gsmcmullin commented Oct 3, 2017

@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.

@gsmcmullin gsmcmullin force-pushed the riscv branch 2 times, most recently from 6e9af3e to 3960da4 Compare October 4, 2017 19:34
@esden
Copy link
Copy Markdown
Member

esden commented Nov 3, 2017

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.

@UweBonnes
Copy link
Copy Markdown
Contributor

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

@alistair23
Copy link
Copy Markdown

Will this be merged soon then?

@UweBonnes
Copy link
Copy Markdown
Contributor

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...

@alistair23
Copy link
Copy Markdown

Ah, that's unfortunate.

@UweBonnes
Copy link
Copy Markdown
Contributor

Rebased again.

@esden esden added the New Target New debug target label Dec 20, 2021
@arabine
Copy link
Copy Markdown

arabine commented Jul 22, 2022

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.

@dragonmux
Copy link
Copy Markdown
Member

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.

@arabine
Copy link
Copy Markdown

arabine commented Jul 25, 2022

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

@perigoso perigoso mentioned this pull request Feb 23, 2023
6 tasks
@mrx23dot
Copy link
Copy Markdown

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?

@mrx23dot
Copy link
Copy Markdown

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

@dragonmux
Copy link
Copy Markdown
Member

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

/* Do note that this can be used with a riscv_halt_request() call to initiate halt-on-reset debugging */
static void riscv_reset(target_s *const target)
{
riscv_hart_s *const hart = riscv_hart_struct(target);
bool has_reset = false;
/* If the target does not have the nRST pin inhibited, use that to initiate reset */
if (!(target->target_options & TOPT_INHIBIT_NRST)) {
platform_nrst_set_val(true);
has_reset = riscv_dm_poll_state(hart->dbg_module, RV_DM_STAT_ALL_RESET);
platform_nrst_set_val(false);
/* In theory we're done at this point and no debug state was perturbed */
}
/*
* Otherwise, if nRST is not usable (or failed), use instead reset via dmcontrol. In this case,
* when reset is requested, use the ndmreset bit to perform a system reset
*/
if (!has_reset) {
riscv_dm_write(hart->dbg_module, RV_DM_CONTROL, hart->hartsel | RV_DM_CTRL_SYSTEM_RESET);
riscv_dm_poll_state(hart->dbg_module, RV_DM_STAT_ALL_RESET);
/* Complete the reset by resetting ndmreset */
riscv_dm_write(hart->dbg_module, RV_DM_CONTROL, hart->hartsel);
}
/* Acknowledge the reset */
riscv_dm_write(hart->dbg_module, RV_DM_CONTROL, hart->hartsel | RV_DM_CTRL_HART_ACK_RESET);
riscv_halt_request(target);
target_check_error(target);
}
for details.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Enhancement General project improvement New Target New debug target

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants