auracaster/sw_openocd
3
0
Fork 0
forked from auracaster/openocd
Code Pull Requests Activity

target/riscv: tcl/target: move the WA for GD32VF103 to Tcl

Browse Source 
The GD32VF103 has a perculiar reset procedure that does not fully comply
with the RISC-V Debug Specification.
Move the workaroung to the `deassert-reset-post` handler.

Change-Id: I153c866a5b7e2dff2552cc92772ce6ed77ad606b
Signed-off-by: Evgeniy Naydanov <eugnay@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/9314
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Tested-by: jenkins
This commit is contained in:
Evgeniy Naydanov
2025-12-12 14:17:53 +03:00
committed by Antonio Borneo
parent 2a0b9bbc28
commit 21e345a2f7
2 changed files with 17 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
src/target/riscv/riscv-013.c
View File

@@ -3001,15 +3001,7 @@ static int deassert_reset(struct target *target)
get_field(dmstatus, DM_DMSTATUS_ALLHAVERESET) ? "true" : "false"); get_field(dmstatus, DM_DMSTATUS_ALLHAVERESET) ? "true" : "false");
return ERROR_TIMEOUT_REACHED; return ERROR_TIMEOUT_REACHED;
} }
/* Certain debug modules, like the one in GD32VF103 } while (!get_field(dmstatus, DM_DMSTATUS_ALLHAVERESET));
* MCUs, violate the specification's requirement that
* each hart is in "exactly one of four states" and,
* during reset, report harts as both unavailable and
* halted/running. To work around this, we check for
* the absence of the unavailable state rather than
* the presence of any other state. */
} while (get_field(dmstatus, DM_DMSTATUS_ALLUNAVAIL) &&
!get_field(dmstatus, DM_DMSTATUS_ALLHAVERESET));
riscv_scan_set_delay(&info->learned_delays, RISCV_DELAY_BASE, riscv_scan_set_delay(&info->learned_delays, RISCV_DELAY_BASE,
orig_base_delay); orig_base_delay);

16
tcl/target/gd32vf103.cfg
View File

@@ -116,6 +116,22 @@ $_TARGETNAME configure -event reset-assert {
default_mem_access default_mem_access
} }
# On GD32VF103 the specification's requirement that each hart is in "exactly
# one of four states" is violated and, during reset, report harts as both
# unavailable and halted/running. To work around this, after the havereset is
# lowered in the main deassert_reset procedure, we wait for the absence of the
# unavailable state.
$_TARGETNAME configure -event reset-deassert-post {
set timeout_s 2
set start [clock seconds]
# dmstatus address is 0x11, allunavail is the 12th bit
while {[riscv dmi_read 0x11] & 1 << 12} {
if {[clock seconds] - $start > $timeout_s} {
error {Timed out waiting for the hart to become available after a reset}
}
}
}
# Capture the mode of a given reset so that we can use it later in the # Capture the mode of a given reset so that we can use it later in the
# reset-assert handler. # reset-assert handler.
proc init_reset { mode } { proc init_reset { mode } {