Merge commit '16e9b9c44fa62ea6eec99d1fb7bc43a8f1cc2f7e' into from_upstream

Conflicts:
	configure.ac
	tcl/target/gd32vf103.cfg

Change-Id: I72bbb973249b7bbfa720696fa2c76a87a41a2e9c

2 files changed, 97 insertions, 3 deletions

diff --git a/tcl/target/at91sama5d2.cfg b/tcl/target/at91sama5d2.cfg
index 65e5217..30ddc92 100644
--- a/tcl/target/at91sama5d2.cfg
+++ b/tcl/target/at91sama5d2.cfg
@@ -1,5 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0-or-later
 #
+# SAMA5D2 devices support both JTAG and SWD transports.
+#
 # The JTAG connection is disabled at reset, and during the ROM Code execution.
 # It is re-enabled when the ROM code jumps in the boot file copied from an
 # external Flash memory into the internalSRAM, or when the ROM code launches
@@ -12,14 +14,28 @@
 # - if enabled, boundary Scan mode is activated. JTAG ID Code value is 0x05B3F03F.
 # - if disabled, ICE mode is activated. Debug Port JTAG IDCODE value is 0x5BA00477
 #
+
+source [find target/swj-dp.tcl]
+
+#jtag scan chain
+if { [info exists CPUTAPID] } {
+	set _CPUTAPID $CPUTAPID
+} else {
+	if { [using_jtag] } {
+		set _CPUTAPID 0x5ba00477
+	} else {
+		# SWD IDCODE (single drop, arm)
+		set _CPUTAPID 0x5ba02477
+	}
+}
+
 if { [info exists CHIPNAME] } {
 	set  _CHIPNAME $CHIPNAME
 } else {
 	set  _CHIPNAME at91sama5d2
 }
 
-jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x01 -irmask 0x0f \
-	-expected-id 0x5ba00477
+swj_newdap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID
 
 # Cortex-A5 target
 set _TARGETNAME $_CHIPNAME.cpu_a5
diff --git a/tcl/target/gd32vf103.cfg b/tcl/target/gd32vf103.cfg
index 6262697..77fdff7 100644
--- a/tcl/target/gd32vf103.cfg
+++ b/tcl/target/gd32vf103.cfg
@@ -13,6 +13,13 @@ transport select jtag
 
 reset_config srst_nogate
 
+# The smallest RAM size 6kB (GD32VF103C4/T4/R4)
+if { [info exists WORKAREASIZE] } {
+   set _WORKAREASIZE $WORKAREASIZE
+} else {
+   set _WORKAREASIZE 0x1800
+}
+
 set _CHIPNAME gd32vf103
 # The vendor's configuration expects an ID of 0x1e200a6d, but this one is what
 # I have on my board (Sipeed Longan Nano, GD32VF103CBT6).
@@ -29,7 +36,7 @@ proc default_mem_access {} {
 
 default_mem_access
 
-$_TARGETNAME configure -work-area-phys 0x20000000 -work-area-size 0x1000 -work-area-backup 1
+$_TARGETNAME configure -work-area-phys 0x20000000 -work-area-size $_WORKAREASIZE -work-area-backup 0
 
 set _FLASHNAME $_CHIPNAME.flash
 flash bank $_FLASHNAME stm32f1x 0x08000000 0 0 0 $_TARGETNAME
@@ -107,3 +114,74 @@ proc init_reset { mode } {
 		jtag arp_init-reset
 	}
 }
+
+# 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
+	}
+}