* riscv: work around buggy hart states during reset in some DMs
As described in the comment this change adds, the GD32VF103 DM reports
that the hart is in more than one state while it is resetting. Because
of this, the current code acknowledges resets before they actually
complete. This sometimes prevents havereset from getting cleared as
intended, leading to a spurious "Hart 0 unexpectedly reset!" message the
next time riscv_is_halted() gets called.
To work around this, check for the absence of the unavailable state
rather than the presence of the running or halted states. This behavior
is also arguably more true to the spec than what exists now: Section 3.2
states that "The system may take an arbitrarily long time to come out of
reset, as reported by allunavail, anyunavail."
Change-Id: I34e90a16233125608bce8e4c2414dbead637600e
Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
* riscv: support custom reset-assert scripts
The reset-assert event is used, if present, to override the default
reset logic for ARM and MIPS cores. Do the same for RISC-V so that
devices with buggy ndmreset functionality (like GD32VF103) or
nonstandard reset sequences can specify the appropriate logic in Tcl.
Change-Id: I5e12077d67509853edb8ef3ad3f037f293a5fbb6
Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
* tcl/target: support GD32VF103 RISC-V MCU
The GD32VF103 is a low-cost 32-bit RISC-V microcontroller with
peripherals that are more-or-less compatible with the STM32F103 ARM
microcontroller. It is available on several low-cost dev boards, such as
the Sipeed Longan Nano, which is what I am testing on.
Add initial support for this chip, including a workaround for a buggy
ndmreset line (i.e. one that doesn't actually trigger a reset) in its
integrated debug module. Use the existing GD32VF103 flash driver that
was ported from the vendor's code in commit 48e40f3513 ("Add support
for GD32VF103 flash").
Change-Id: Iadac47ceb5437b8e18f3d35901388f10fef9f876
Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
* tcl/target/gd32vf103: add main flash alias
The GD32VF103 creates an alias to either main flash or the bootloader at
0x0, depending on how it was booted. As such, we want to indicate to
debuggers that the memory at 0x0 is flash and so cannot support software
breakpoints. To do this, add an alias to the main flash in the config.
This isn't strictly accurate in the case where we're running the
bootloader, but it still suits our purpose of fixing breakpoint
behavior.
Change-Id: I9eb8462d354f096eee231c0e5e2bffa538a5903e
Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
Tom Hebb