I don't think there are any real bugs here, but at least this gives us a
clean slate moving forward.

Change-Id: I29c6c398c28dfe580f9a2deb3bdbcfc491a2ceb6
Signed-off-by: Tim Newsome <tim@sifive.com>

target/riscv: improve error handling in `write_memory_progbuf()`

Update riscv/debug_defines (to sync with riscv-debug-spec commit 40b9a05)

Change-Id: Ie969866d1de83360a5f45e96e22108b58b8aa02f
Signed-off-by: Kirill Radkin <kirill.radkin@syntacore.com>

The goal of this commit is to provide more robust error handling in
`write_memory_progbuf()`. This is achieved by rewriting it in a fashion
similar to `read_memory_progbuf()`.

The motivation is: some instability in `load_image` was encountered. No
stable reproduction could be obtained, so the root cause was not
determined. Therefore, it was decided to clean-up the code, that may be
implicated in such failures.

Examples of unhanded errors in the code prior to this commit:
* Most of `dmi_write()` return values are discarded.
* If `dm_read()` on `abstractcs` failed (line 4546), `abstractauto` was
  not cleared.

Furthermore, the structure of the code was quite complicated, which made
it hard to analyze and reason whether or not all possible failures are
handled properly.

Change-Id: I8a100b686e594855fbf34acf5ccf0e1550f18869
Signed-off-by: Evgeniy Naydanov <evgeniy.naydanov@syntacore.com>

target/riscv: report helpfull location during register decode

OpenOCD style guide(`doc/manual/style.txt`) prohibits use of VLA:

> - use malloc() to create dynamic arrays. Do @b not use @c alloca
> or variable length arrays on the stack. non-MMU hosts(uClinux) and
> pthreads require modest and predictable stack usage.

Change-Id: I12e4a5087fd056d69866137237af6deca27f5d33
Signed-off-by: Evgeniy Naydanov <evgeniy.naydanov@syntacore.com>

`LOG_TARGET_DEBUG()` reports file, line and function name at the call
site. This information is not helpfull if it always points to the same
location inside `log_debug_reg()`.

Change-Id: Ib73be0344fb5c80c9ac8e5fdee1084d405522eb7
Signed-off-by: Evgeniy Naydanov <evgeniy.naydanov@syntacore.com>

fix erroneously-resolved merge conflict

Change-Id: I4278e3e444eec93c418dfe153f60404f9848a20a
Signed-off-by: Parshintsev Anatoly <anatoly.parshintsev@syntacore.com>

Merge up to 4b1ea851 from upstream

If we can't remove bp/wp, we will stuck in endless loop

Change-Id: I44c0a164db1d15c0a0637d33c75087a49cf5c0f4
Signed-off-by: Kirill Radkin <kirill.radkin@syntacore.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7940


Tested-by: jenkins
Reviewed-by: Anatoly P <kupokupokupopo@gmail.com>
Reviewed-by: Tim Newsome <tim@sifive.com>
Reviewed-by: Jan Matyas <jan.matyas@codasip.com>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>

Change-Id: I59366e08a4ac7e443e426b5fd6727c649f1ac9d5

There was a big conflict with this one incoming change. This version of
the code passes all the tests (which don't test for the changed behavior
at all AFAIK), and at least passes errors back everywhere.

Conflicts:
	src/target/breakpoints.c

Change-Id: I72f75a3e08deda7e624e8bb82e1a9ea07a7a9276

Change-Id: I05cd5ef9b04fa61a27321ae9b6a4fecabe3dee80

When an attempt to set watchpoint fails because there is no free triggers OpenOCD reports "unknown error"

target/riscv: Replace [sg]et_field macros with functions.

target/riscv: Handle sbbusyerror in read_memory_bus_v1

target/riscv: dump_field() shouldn't always decode

When an attempt to set watchpoint fails because there is no free triggers OpenOCD reports "unknown error"

Now it returns `resource not available`

Change-Id: Ifbbd468bdf62023850690eb96fe8a16f4114e915
Signed-off-by: Kirill Radkin <kirill.radkin@syntacore.com>

The existing code didn't seem to work right at all. I have spike
modifications that exercise these new cases. I'll merge those once this
has merged.

Change-Id: I89bd336f34f1b208a76f25b6b41fe3877800765b
Signed-off-by: Tim Newsome <tim@sifive.com>

Compilers are good at optimizing, and with functions it's abundantly
clear what all the types involved are. This change means we don't have
to be super careful about the type of values because of what the macro
might do to them that might cause overflow.

The only place where the return type matters is in printf-style
functions, and I made get_value32() for those cases where a change was
needed.

This should set the stage for simply copying the latest debug_defines.h
from the debug spec build again.

Change-Id: I5fb19d0cfc1e20137832a7b344b05db215ce00e1
Signed-off-by: Tim Newsome <tim@sifive.com>

The reasoning for the change:
* `__func__` is part of C99, `__PRETTY_FUNCTION__` is GNU extension.
* `__PRETTY_FUNCTION__` is defined to be the same as `__func__` for C
  sources by GCC documentation but differ for C++ sources (full
  signature instead of just a name).
* Currently Clang does support `__PRETTY_FUNCTION__`, though it uses
  GCC's C++ variant across C and C++.

Therefore using `__PRETTY_FUNCTION__` creates confusion and does not
provide any valueble information in the logs.

Change-Id: Ie0db6d73f602784b6752a30911dcef3dd7ee4594

Sometimes, the value from of some DMI scans has no meaning (e.g. when
`op` is read). Such values should not be decoded. To make the dumps more
consistent, `<no decoding available>` is printed when there is no
decoding for a register.

Change-Id: I415f06a5a80f2fc8fb8ab3f79132bdf0602c8ad6
Signed-off-by: Evgeniy Naydanov <evgeniy.naydanov@syntacore.com>

target/riscv: clarify usage of `coreid`

target/riscv: cache requests to trigger configuration

By definition in `target/target.h`, `coreid` is not a unique identifier
of a target -- it can be the same for targets on different TAPs.

Change-Id: Ifce78da55fffe28dd8b6b06ecae7d8c4e305c0a2
Signed-off-by: Evgeniy Naydanov <evgeniy.naydanov@syntacore.com>

target/riscv: Replace watchpoint value mask comparison value with macro.

This patch replaces ~(typeof(watchpoint->mask))0 with
WATCHPOINT_IGNORE_DATA_VALUE_MASK. This improves
readability and moves the RISCV target in line with
other targets.

Change-Id: I15ac4d4ee76098b304d9b22f720911ba4329c190
Signed-off-by: Marek Vrbka <marek.vrbka@codasip.com>

Merge commit '05ee8891' from upstream

target/riscv: Stop caching writes to DPC

Depending on configuration, the existing implementation of watchpoints is
rather inefficient for certain scenarios. Consider HW that:

1. triggers 0-3 can be used as instruction breakpoints
2. triggers 4-7 can be used as data breakpoints (watchpoints)
3.  NAPOT triggers are not supported.

Now, consider that we have a pending watchpoint. And we perform a "step"
operation. According to the current implementation:

* OpenOCD will disable watchpoints
* Perform a single-step
* Will try to restore the original watchpoints. It will need 12 attempts
to find a suitable trigger: (8 attempts to try NAPOT, and another 4 to try
GE+LE).

This patch introduces a dedicated cache for requests to triggers. It
significantly speeds things up, since we cache failed attempts and no
additional interactions with HW is necessary.

Change-Id: Ic272895eaa763a7ae84d14f7633790afd015ca9d
Signed-off-by: Anastasiya Chernikova <anastasiya.chernikova@syntacore.com>

Conflicts:
	src/jtag/drivers/xds110.c
	src/target/riscv/riscv.c
	src/target/riscv/riscv_semihosting.c
	tcl/target/esp_common.cfg

Change-Id: If0c02817df03b7fd700cc84b4da2c02d36737d28

target/riscv: gdb_regno_name takes an enum.

Otherwise it won't compile for me. Not sure why that doesn't affect the
automated builds.

Change-Id: Ic66c743e1698c4c0772e5601723cb5c711b4fa5c
Signed-off-by: Tim Newsome <tim@sifive.com>

target/riscv: Adding register tables to make register names consiste

From upstream

Since DPC is WARL (same rules as MEPC according to
the specification), it is possible that
writes to it won't result in the exact value present.
Therefore, writes to it shouldn't be cached, same as
with other WARL registers.

Change-Id: I818c0cef9727b999b7d84b19f9f42cd706c99d69
Signed-off-by: Marek Vrbka <marek.vrbka@codasip.com>

target/riscv: Fix memory access when MMU is enabled and address couldn't be translated

Added the ability to enter dimensionless registers

Change-Id: I1b781959ce4690ec65304142bd9a7c6f540b3e86
Signed-off-by: Anastasiya Chernikova <anastasiya.chernikova@syntacore.com>