This lets users tell OpenOCD which non-standard CSRs exist on their
target, that will also be accessible and whose existence will be
communicated to gdb.
Change-Id: I56163a9fcb84ad7ebe815ae74fbd9fcc208f5a9d
(It's really only 2 bits, but something wonky happens between gdb and
OpenOCD if I make it that size.)
Change-Id: I562a65cb0ebe5aa0edcc54c251d0fea0e26f9cb1
Because there is no instruction that moves just half of a 64-bit FPR
to/from a GPR, we need to use scratch memory for this operation. This
code can theoretically use:
1. DMI_DATA, if it is memory mapped in the target.
2. DMI_PROGBUF, if it is writable in the target.
3. A user-configured address.
I have only tested this code very lightly. One reason is that gdb thinks
that on RV32 harts every register is 32 bits wide. Another is that this
is mostly proof-of-concept to satisfy the small program buffer code
review, which I don't want to drag out forever.
Existing tests don't realize that floating support was broken with
RV32D, and don't realize that it still doesn't work because of the gdb
problem mentioned above.
This change improves Issue #110 but there's more work to be done.
Change-Id: I99b8a36e5fea26f1d9e16e36cf99adc7be26b944
The actual implementation of triggers didn't change between those two
versions, so there's no need to duplicate the code.
In the process, I also fixed a minor multicore bug where tselect didn't
always get written on all harts.
When first connecting to a target, have the debugger disable any
hardware triggers that are set by a previously connected debugger.
The 0.11 code already did this, but 0.13 did not.
To achieve this I decided to share the code to enumerate triggers
between 0.11 and 0.13, which required me to implement get_register() and
set_register() for 0.11, which made the whole change a lot larger than
you might have guessed.
Hopefully this sets us up to in the future share the code to set/remove
triggers as well.
Rather than having a bunch of "if rtos" stuff, I now just check "if
hart_enabled". This makes some code paths cleaner, all of which were
buggy in the non-RTOS multi-hart mode.
When I disappeared the polls everywhere I forgot to sanitize the hartid
after halting. This is an invariant that GDB expects: when you return
from a halt whatever thread is marked as currently selected is the
thread that the next register accesses reference.
Main change is to make riscv_addr_t be unsigned. The rest is mechanical
fixing of types, print statements, and a few signed/unsigned compares.
Smoketest indicates everything is working more or less as before.
This means I don't know what hart to look at, so I might as well
invalidate the register cache. Without this, you might get stale
registers the first time you ask for them.
I thought OpenOCD did this, but it looks like that doesn't happen when
runningi in RTOS mode. With this I can get to the end of most of the
RTOS tests, but they SIGINT instead of exiting.
This is a major rewrite of the RISC-V v0.13 OpenOCD port. This
shouldn't have any meaningful effect on the v0.11 support, but it does
add generic versions of many functions that will allow me to later
refactor the v0.11 support so it's easier to maintain both ports. This
started as an emergency feature branch and went on for a long time, so
it's all been squashed down into one commit so there isn't a big set of
broken commits lying around. The changes are:
* You can pass "-rtos riscv" to the target in OpenOCD's configuration
file, which enables multi-hart mode. This uses OpenOCD's RTOS
support to control all the harts from the debug module using commands
like "info threads" in GDB. This support is still expermental.
* There is support for RV64I, but due to OpenOCD limitations we only
support 32-bit physical addresses. I hope to remedy this by rebasing
onto the latest OpenOCD release, which I've heard should fix this.
* This matches the latest draft version of the RISC-V debug spec, as of
April 26th. This version fixes a number of spec bugs and should be
close to the final debug spec.
If the working area is large enough, every fespi_write() results in just
a single algorithm execution.
Change-Id: I87a12e29f50ef6ea1f46fbd1edf440f9e54a2162
Halting didn't work right in slow targets, because some code assumed the
register cache is valid before it was guaranteed to be.
Also made dbus_busy_delay and interrupt_high_delay grow faster, so that
on slow targets it takes less time to learn the correct values.
Change-Id: I948a49d4e3cd0638f5449ab94994406319fd5f42
It's not a failure in the debugger or even a real problem if a user asks
to access memory that's not accessible.
Change-Id: I30b8424d5265d1996fe4826012ed160a83f0bc6c
Also only do work for debug RAM that actually exists on the target
(exposing the off-by-one error on 32-bit targets).
Change-Id: I37e0005b6a70e949286f1d6494716f3abea03c12
Read dtmcontrol's idle field to decide how many run-test/idle cycles are
required to communicate with the target.
In riscv_examine(), write and read all of Debug RAM to check the target
is at least somewhat sane.
Change-Id: Ieedb7a50418fa1f5e0d456cde53c52f7fc51662b
Old code would write 64 bytes of DRAM if the dbus was busy in
cache_write().
New code clears the dbus error condition when the bus is busy. (This
part is untested.)
Change-Id: Ia396fe819fa1828bb75726d85513b113cc9e13f0
Now logging is consistent and more readable.
I did remove most logging during riscv_poll() since it clutters up the
log/screen and is not generally helpful.
Users can use this register to inspect and change the privilege level of
the core. It doesn't make any assumptions about the actual underlying
debug mechanism (as opposed to having the user change DCSR directly,
which may not exist in all debug implementations).
Now you can attach with gdb, and it'll attempt to read a register. That
will fail because the core won't clear debug interrupt. Adding nops
doesn't help this time.
Tim Newsome
Megan Wachs
Palmer Dabbelt