Previously, when listing the watchpoints, OpenOCD printed
numbers 0, 1 and 2 representing READ, WRITE and ACCESS type
watchpoints.
This patch changes it to 'r', 'w' and 'a'. This increases the
clarity as what type the watchpoint actually is.
Change-Id: I9eac72dfd0bb2a9596a5b0c080a3f584556ed599
Signed-off-by: Marek Vrbka <marek.vrbka@codasip.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7909
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-by: Jan Matyas <jan.matyas@codasip.com>
This patch adds the "all" option to the rwp command.
It removes all watchpoints, much like rbp all removes
all breakpoints.
Change-Id: Id58dd103085e558f17afa4a287888cf085566ca9
Signed-off-by: Marek Vrbka <marek.vrbka@codasip.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7907
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Previously, if you ran a tcl command in capture like so:
"capture { reg 0x1000 hw }"
Such command did overwrite the tcl result if LOG_LVL_INFO or
lower was logged during it.
This patch changes it by prepending the log to the tcl result instead.
As the tcl results should not be lost during capture.
Change-Id: I37381b45e15c931ba2844d65c9d38f6ed2f6e4fd
Signed-off-by: Marek Vrbka <marek.vrbka@codasip.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7902
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
Reviewed-by: Jan Matyas <jan.matyas@codasip.com>
Add support for the ARM MCRR/MRRC instructions which require the use of
two registers to transfer a 64-bit co-processor registers. We are going
to use this in a subsequent patch in order to properly dump 64-bit page
table descriptors that exist on ARMv7A with VMSA extensions.
We make use of r0 and r1 to transfer 64-bit quantities to/from DCC.
Change-Id: Ic4975026c1ae4f2853795575ac7701d541248736
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Michael Chalfant <michael.chalfant@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/5228
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Firstly, create the TPIU nrf52.tpiu if using the nrf52 target. This is
standard, using AP 0 and TPIU base address 0xE0040000.
Secondly, add a pre_enable handler for this TPIU which configures the
TRACEMUX field of the TRACECONFIG register. This register is reset
every time the MCU resets, so the pre_enable handler creates a
reset-end handler to ensure the register remains set.
Change-Id: I408b20fc03dc2060c21bad0c21ed713eee55a113
Signed-off-by: Frank Plowman <post@frankplowman.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7901
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
While we can read and write from memory from the view of various
processors, all K3 debug systems have a AXI Access port that allows
us to directly access memory from debug interface. This port is
especially useful in the following scenarios:
1. Debug cache related behavior on processors as this provides a
direct bypass path.
2. Processor has crashed or inaccessible for some reason (low power
state etc.)
3. Scenarios prior to the processor getting active.
4. Debug MMU or address translation issues (example: TI's Region
Address Table {RAT} translation table used to physically map
SoC address space into R5/M4F processor address space)
The AXI-AP port is the same for all processors in TI's K3 family.
To prevent a circular-loop scenario for axi-ap accessing debug memory
with dmem (direct memory access debug), enable this only when dmem is
disabled.
Change-Id: Ie4ca9222f034ffc2fa669fb5124a5f8e37b65e3b
Reported-by: Dubravko Srsan <dubravko.srsan@dolotron.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7899
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
The Texas Instruments' K3 devices are a mix of AMP and SMP systems.
The operating systems used on these processors can vary dramatically
as well. Introduce a RTOS array variable, which is keyed off the cpu
to identify which RTOS is used on that CPU. This can be "auto" or
"hwthread" in case of SMP debug etc.
For example:
AM625 with an general purpose M4F running Zephyr and 4 A53s running SMP
Linux could be invoked by:
openocd -c 'set V8_SMP_DEBUG 1' -c 'set RTOS(am625.cpu.gp_mcu) Zephyr' \
-c "set RTOS(am625.cpu.a53.0) hwthread" -f board/ti_am625evm.cfg
Change-Id: Ib5e59fa2583b3115e5799658afcdd0ee91935e82
Reported-by: Dubravko Srsan <dubravko.srsan@dolotron.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7898
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Describe the SMP Armv8 cores in SMP configuration with coreid
explicitly called out. This allows for gdb session to call the smp
behavior clearly.
Change-Id: Ie43be22db64737bbb66181f09d3c83567044f3ac
Signed-off-by: Dubravko Srsan <dubravko.srsan@dolotron.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7897
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
When _v8_smp_targets is used with V8_SMP_DEBUG=1, describe the targets
as SMP targets. However, the variable expansion is not in the context of
a proc, and a typo in referring to global $_v8_smp_targets causes this
to fail. Just refer to $_v8_smp_targets directly.
Change-Id: Iffe5fd2703bed6a9c840284285e70b8a8ce84e17
Signed-off-by: Dubravko Srsan <dubravko.srsan@dolotron.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7896
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
Currently, instruction cache is being invalidated in
arc_{un,}set_breakpoint() regardless of whether the breakpoint's type is
HW or SW. For SW breakpoints, this has no net effect as the caches are
flushed as a by-product of overwriting instructions in main memory and
is thus merely unnecessary; but for HW breakpoints this invalidation is
not preceded by a flush and might lead to loss of data. This patch
removes the invalidate() call altogether to correct this undesired
behavior for HW breakpoints.
With this patch applied, all supported HW breakpoint tests from the gdb
testsuite are now passing with the arc-openocd backend.
Change-Id: I3d252b97f01f1a1e2bf0eb8fb257bdab0c544bc2
Signed-off-by: Artemiy Volkov <artemiy@synopsys.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7767
Tested-by: jenkins
Reviewed-by: Evgeniy Didin <didin@synopsys.com>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
The comment above armv8_dpm_read_current_registers() doesn't match
the implementation, as the function reads all the registers from
ARMV8_PC and above.
The registers currently read are not relevant to answer to the
usual GDB initial request through the 'g' packet. Plus the lack of
differentiation per core state (AArch32 vs AArch64) causes the
read of not existing registers in AArch32 triggering errors, as
tentatively fixed by https://review.openocd.org/5517/
Fix the code to read the registers initially required by GDB.
Modify the comment to report the register list in AArch32 and in
AArch64.
Keep the extra checks inside the read loop, even if they are
mostly irrelevant; this could prevent errors if someone needs to
extend the number of registers to read.
The current implementation of the register's description in
OpenOCD does not allow to discriminate among AArch32 and AArch64
registers. Add a TODO comment to highlight it.
Change-Id: Icd47d93c19a9e1694a7b51bbc5ca7e21a578df41
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7887
Tested-by: jenkins
Previously, the bcm2835_peri_base value would be printed as a decimal
value despite having a "0x" prefix, implying it should be a hex value.
BCM2835 GPIO: peripheral_base = 0x1056964608
Now, the value is correctly converted to hexidecimal.
BCM2835 GPIO: peripheral_base = 0x3F000000
Change-Id: Id59185423917e6350f99ef68320e2102a3192291
Fixes: b41b368255 ("jtag/drivers/bcm2835gpio: extend peripheral_base to off_t")
Signed-off-by: Vincent Fazio <vfazio@xes-inc.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7888
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
