target/xtensa: avoid IHI for writes to non-executable memory

[openocd.git] / tcl / target / gd32vf103.cfg

diff --git a/tcl/target/gd32vf103.cfg b/tcl/target/gd32vf103.cfg
index 0681243343f9d8472284a50ce58e7fff8ab80d26..54a74e8cc514a29bb39014d84d2ec7f8e473345f 100644 (file)
--- a/tcl/target/gd32vf103.cfg
+++ b/tcl/target/gd32vf103.cfg
@@ -28,6 +28,12 @@ jtag newtap $_CHIPNAME cpu -irlen 5 -expected-id 0x1000563d
 set _TARGETNAME $_CHIPNAME.cpu
 target create $_TARGETNAME riscv -chain-position $_TARGETNAME
 
+proc default_mem_access {} {
+       riscv set_mem_access progbuf
+}
+
+default_mem_access
+
 $_TARGETNAME configure -work-area-phys 0x20000000 -work-area-size $_WORKAREASIZE -work-area-backup 0
 
 set _FLASHNAME $_CHIPNAME.flash
@@ -40,3 +46,74 @@ $_TARGETNAME configure -event reset-init {
        # DBGMCU_CR |= DBG_WWDG_STOP | DBG_IWDG_STOP
        mmw 0xE0042004 0x00000300 0
 }
+
+# On this chip, ndmreset (the debug module bit that triggers a software reset)
+# doesn't work. So for JTAG connections without an SRST, we need to trigger a
+# reset manually. This is an undocumented reset sequence that's used by the
+# JTAG flashing script in the vendor-supplied GD32VF103 PlatformIO plugin:
+#
+#   https://github.com/sipeed/platform-gd32v/commit/f9cbb44819bc05dd2010cc815c32be0486800cc2
+#
+$_TARGETNAME configure -event reset-assert {
+       set dmcontrol           0x10
+       set dmcontrol_dmactive  [expr {1 << 0}]
+       set dmcontrol_ackhavereset [expr {1 << 28}]
+       set dmcontrol_haltreq   [expr {1 << 31}]
+
+       global _RESETMODE
+
+       # If hardware NRST signal is connected and configured (reset_config srst_only)
+       # the device has been recently reset in 'jtag arp_init-reset', therefore
+       # DM_DMSTATUS_ANYHAVERESET reads 1.
+       # The following 'halt' command checks this status bit
+       # and shows 'Hart 0 unexpectedly reset!' if set.
+       # Prevent this message by sending an acknowledge first.
+       set val [expr {$dmcontrol_dmactive | $dmcontrol_ackhavereset}]
+       riscv dmi_write $dmcontrol $val
+
+       # Halt the core so that we can write to memory. We do this first so
+       # that it doesn't clobber our dmcontrol configuration.
+       halt
+
+       # Set haltreq appropriately for the type of reset we're doing. This
+       # replicates what the generic RISC-V reset_assert() function would
+       # do if we weren't overriding it. The $_RESETMODE hack sucks, but
+       # it's the least invasive way to determine whether we need to halt.
+       #
+       # If we didn't override the generic handler, we'd actually still have
+       # to do this: the default handler sets ndmreset, which prevents memory
+       # access even though it doesn't actually trigger a reset on this chip.
+       # So we'd need to unset it here, which involves a write to dmcontrol,
+       # Since haltreq is write-only and there's no way to leave it unchanged,
+       # we'd have to figure out its proper value anyway.
+       set val $dmcontrol_dmactive
+       if {$_RESETMODE ne "run"} {
+               set val [expr {$val | $dmcontrol_haltreq}]
+       }
+       riscv dmi_write $dmcontrol $val
+
+       # Unlock 0xe0042008 so that the next write triggers a reset
+       mww 0xe004200c 0x4b5a6978
+
+       # We need to trigger the reset using abstract memory access, since
+       # progbuf access tries to read a status code out of a core register
+       # after the write happens, which fails when the core is in reset.
+       riscv set_mem_access abstract
+
+       # Go!
+       mww 0xe0042008 0x1
+
+       # Put the memory access mode back to what it was.
+       default_mem_access
+}
+
+# Capture the mode of a given reset so that we can use it later in the
+# reset-assert handler.
+proc init_reset { mode } {
+       global _RESETMODE
+       set _RESETMODE $mode
+
+       if {[using_jtag]} {
+               jtag arp_init-reset
+       }
+}