GDB can be built for multi-architecture through the command
./configure --enable-targets=all && make
Such multi-architecture GDB requires the target's architecture to
be selected either manually by the user through the GDB command
"set architecture" or automatically by the target description sent
by the remote target (i.e. OpenOCD).
Commit e65acd889c ("gdb_server: add
support for architecture element") already provides the required
infrastructure to support multi-architecture gdb.
aarch64-linux-gnu-gdb 8.2 uses "aarch64" as default architecture,
but also supports the value "aarch64:ilp32" and all the values
supported by arm-none-eabi-gdb.
These values can be displayed on arm gdb prompt by typing
"set architecture " followed by a TAB for autocompletion.
Set the gdb architecture value for aarch64 target to "aarch64".
Change-Id: I63e9769f47d8e73f048eb84fa73e082dd1c8e52c
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: http://openocd.zylin.com/4755
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
GDB can be built for multi-architecture through the command
./configure --enable-targets=all && make
Such multi-architecture GDB requires the target's architecture to
be selected either manually by the user through the GDB command
"set architecture" or automatically by the target description sent
by the remote target (i.e. OpenOCD).
Commit e65acd889c ("gdb_server: add
support for architecture element") already provides the required
infrastructure to support multi-architecture gdb.
arm-none-eabi-gdb 8.2 uses "arm" as default architecture, but also
supports the following values: "arm_any", "armv2", "armv2a",
"armv3", "armv3m", "armv4", "armv4t", "armv5", "armv5t", "armv5te",
"armv5tej", "armv6", "armv6k", "armv6kz", "armv6-m", "armv6s-m",
"armv6t2", "armv7", "armv7e-m", "armv8-a", "armv8-m.base",
"armv8-m.main", "armv8-r", "ep9312", "iwmmxt", "iwmmxt2", "xscale".
These values can be displayed on arm gdb prompt by typing
"set architecture " followed by a TAB for autocompletion.
Set the gdb architecture value for all arm targets to "arm".
Change-Id: I176cb89878606e1febd546ce26543b3e7849500a
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: http://openocd.zylin.com/4754
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
GDB can be built for multi-architecture through the command
./configure --enable-targets=all && make
Such multi-architecture GDB requires the target's architecture to
be selected either manually by the user through the GDB command
"set architecture" or automatically by the target description sent
by the remote target (i.e. OpenOCD).
Commit e65acd889c ("gdb_server: add
support for architecture element") already provides the required
infrastructure to support multi-architecture gdb.
The gdb patches for stm8 are still not merged in the official
repository and are temporarily hosted in
https://stm8-binutils-gdb.sourceforge.io/
The latest patch set
stm8-binutils-gdb-sources-2018-03-04.tar.gz
define only one possible value ("stm8") for this architecture; it
can be displayed typing "set architecture " followed by a TAB for
autocompletion in gdb for stm8.
Set the gdb architecture value for stm8 to "stm8".
Change-Id: I643ceba662de46cecf061d1dc672b9178a077f1b
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: http://openocd.zylin.com/4753
Tested-by: jenkins
Reviewed-by: Ake Rehnman <ake.rehnman@gmail.com>
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
xPSR.T sets the processor to Thumb mode when set to 1. ARMv7-M only
supports execution of Thumb instructions, so it must always be set to 1.
If xPSR.T is set to 0 on armv7m, a usage fault is generated when a
instruction execution is attempted.
On armv7m, issuing a reset causes the vector table to be examined. PC
and xPSR.T are loaded from the vector table at byte offset 4. xPSR.T is
taken from the least significant bit this value, PC from the remaining
bits. This occurs even with `reset halt`, as the reset itself causes
this load to occur without the execution of any instructions.
As a result of this, following a reset with a "bad" value programmed in
the vector table, openocd would be unable to run algorithms on the
target, as running them would immediately result in a usage fault due to
xPSR.T being unset (0).
Allow algorithms to run regardless of the content of the vector table by
explicitly setting xPSR so that xPSR.T=1 prior to executing an
algorithm. One can think of this as openocd more closely emulating a
reset or branch instruction in executing it's algorithms.
Ticket: https://sourceforge.net/p/openocd/tickets/203/
Signed-off-by: Cody P Schafer <openocd@codyps.com>
Change-Id: I4dc3427ab195d06c3fd780ea768027fefccc4c28
Reviewed-on: http://openocd.zylin.com/4658
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
The Agama family of devices (CC26x2/CC13x2) required an
additional bit to be set when adding the core's TAP into
the scan chain. The cancel reset bit 0x10000 tells the
ICEPick to take the bus out of reset so that the other
bits will take effect. This bit is a NOP on other devices
and ICEPicks, so the change shouldn't adversely affect
other devices.
Change-Id: I9245eef0936ea7eea28ae84ab5e8ce05fa63af40
Signed-off-by: Edward Fewell <efewell@ti.com>
Reviewed-on: http://openocd.zylin.com/4789
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
The XDS110 stand-alone version has the ability to supply
voltage to the target board via it's AUX FUNCTIONS port.
Added command to enable setting the voltage on the XDS110
stand-alone.
Change-Id: I2f21c4a3d15ed99e649f3a83973c5e724c4bfeb6
Signed-off-by: Edward Fewell <efewell@ti.com>
Reviewed-on: http://openocd.zylin.com/4793
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
The fact that one needs to always push contributions to a single
remote reference (refs/for/master) might seem odd to people unfamiliar
with Gerrit. GitHub, for instance, hosts personal repositories where
developers typically create topic branches for each contribution and
use a proprietary mecanism to request a review (the "pull request").
More generally, one normally does not expect to be able to push
non-fast-forwarding stuff to a remote branch.
This commit adds a clarifying note to the patch guidelines.
Change-Id: Ia750b815b82b18e92b6109c07f451000dcbecf9b
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-on: http://openocd.zylin.com/4806
Tested-by: jenkins
Reviewed-by: Christopher Head <chead@zaber.com>
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
These devices differ from LPC8xx devices in that they have a different
IAP entry point, but everything else is the same. Using Tcl to pass
different IAP entry point.
no new Clang analyser warnings and no new build sanitizers issues.
Change-Id: I2d654dd250f416e74262c0228cad8713a283402f
Signed-off-by: Rod Boyce <developer@teamboyce.co.uk>
Reviewed-on: http://openocd.zylin.com/4684
Reviewed-by: Jean-Christian de Rivaz <jcamdr70@gmail.com>
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Currently it is impossible to flash ELF with correct offsets. The reason
is a bogus offset calculation extracted from base.
Since any other spi drivers do not care about base, do the same for
ath79 as well.
Change-Id: I9e46e01c9e7a709c2d07da9203c634f302603afd
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Reviewed-on: http://openocd.zylin.com/4821
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Longest erase all FLASH for nRF5 series is 295.3 ms for nRF52832.
Timeout period now is set to 340 ms (295.3 + 15%)
Change-Id: Iae00ed7b634f111b9798db11e35e4e066d4aaa95
Signed-off-by: Jānis Skujenieks <janis.skujenieks@gmail.com>
Reviewed-on: http://openocd.zylin.com/4822
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
target configure -work-area-xxx calls target_free_all_working_areas()
and sets the desired new parameter. Without this change the working area
does not get reallocated if it has been allocated before.
target_free_all_working_areas() results in work area containing one block
marked as free.
Completely free working area in target_free_all_working_areas()
Change-Id: I79c681082f32f2a96a2b40eb3b8751e427549693
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/4797
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
The block of code moved without any changes
Change-Id: I70b82dc3315dcc3f34de0537b362bee230007d02
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/4796
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Remove option 'srst' which is not recognized from on-line help and texi.
Check parameter and return syntax error if wrong option is entered.
Change-Id: I87daa423a9f53193a0b015080594820b933628f5
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/4795
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Cortex-M0, M0+ and M1 do not support VECTRESET bit in AIRCR.
Without this change the 'reset' command silently fails if VECTRESET
is requested.
Detect these cores, show warning if VECTRESET is about to use
and use SYSRESETREQ instead.
Change-Id: Ief174373e3ef0e6b287c57911c0aca4dfa8209f2
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/4794
Tested-by: jenkins
Reviewed-by: Jean-Christian de Rivaz <jcamdr70@gmail.com>
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
This commit adds TARGET_HALTED check in armv8_get_core_reg32()
and armv8_set_core_reg32() to void a crash issue when gdb connects
but fails to halt the ARM core. Similar logic can be found in
armv8_get_core_reg() and armv8_set_core_reg().
Below is the call stack information of this case when gdb connects.
(gdb) bt
regnum=regnum@entry=0, dpm=0x990110) at src/target/armv8_dpm.c:657
r=0x9c7240, regnum=0, mode=<optimized out>) at src/target/armv8_dpm.c:974
at src/target/armv8.c:1487
packet=0x8ec8e0 <gdb_packet_buffer.9962> "g",
packet_size=<optimized out>, connection=<optimized out>)
at src/server/gdb_server.c:1200
at src/server/gdb_server.c:3180
command_context=command_context@entry=0x935010)
at src/server/server.c:566
...
Change-Id: I159837b533f110998184f910a0abe48409bd58f1
Signed-off-by: Liming Sun <lsun@mellanox.com>
Reviewed-on: http://openocd.zylin.com/4758
Tested-by: jenkins
Reviewed-by: Matthias Welwarsky <matthias@welwarsky.de>
Arm architecture reference manual DDI0406C reports at page 2024 in
table C3-1 the processor behaviour on debug events depending on
the debug-mode (none, monitor or halt), mode selected through the
bits MDBGen and HDBGen in DSCR register.
The halt request is served independently from the debug-mode. Thus
it's useless to enable the halt debug-mode in cortex_a_halt() by
setting the bit HDBGen (macro DSCR_HALT_DBG_MODE).
On the other side, halting for a breakpoint, a watchpoint or a
vector catch requires being in halt debug-mode.
Today HDBGen is set only in cortex_a_halt(), so we are forced to
halt the core at least once before it can be halted for hitting a
breakpoint/watchpoint/vector-catch. This is annoying since there
is no need to halt the target to set a HW breakpoint.
Move in cortex_a_init_debug_access() the selection of the halt
debug-mode, so the mode is set during examine.
To prevent a misconfigured hardware breakpoint/watchpoint/vector
catch to halt the target when OpenOCD has already quit, return to
debug-mode none at OpenOCD exit.
Change-Id: I68a1c51de3572ca1b89e90caf7eb20374268e926
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: http://openocd.zylin.com/4783
Tested-by: jenkins
Reviewed-by: Matthias Welwarsky <matthias@welwarsky.de>
DEBUG_WAIT is useful to debug adi_jtag issue,
and the WCR register is replaced by DLCR for DP registers update
in commit 150b7d26f2.
Change-Id: I3faa9ea8a6adacd3d5275e40382801da731db32f
Signed-off-by: YanLin Zhu <zhuyanlin@pinecone.net>
Reviewed-on: http://openocd.zylin.com/4804
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-by: Christopher Head <chead@zaber.com>
The OpenOCD commands that have been wrapped with 'ocd_bouncer' are
executed within two levels of nested proc's:
# see register_command_handler() in src/helper/command.c
proc my_command {args} {eval ocd_bouncer my_command $args}
# see ocd_bouncer in src/helper/startup.tcl
proc ocd_bouncer {name args} {
... [eval ocd_my_command $args] ...
}
This causes the stack frame of 'ocd_my_command' to be the same one
of proc 'ocd_bouncer', thus two levels below the stack frame of the
caller of 'my_command'. This is an issue with commands that receive
a variable by name and have to resolve them to access the value.
E.g. the command
<target> mem2array arrayname bitwidth address count
is wrapped; it receives the name of the array but fails to resolve
it in the current stack frame. Instead, the commands
mem2array arrayname bitwidth address count
ocd_<target> mem2array arrayname bitwidth address count
are not wrapped and can directly access the array because they share
the same stack frame of the caller.
Same situation with the symmetric commands 'array2mem'.
How to test:
within a telnet connection, run the following set of commands,
eventually replacing the address 0x08000000 with a valid readable
address of your <target>,
unset -nocomplain v1 v2 v3
info vars v?
mem2array v1 32 0x08000000 1
<target> mem2array v2 32 0x08000000 1
ocd_<target> mem2array v3 32 0x08000000 1
info vars v?
and notice that only v1 and v3 are now allocated. The array v2 has
been allocated in the temporarily stack frame of proc ocd_bouncer,
together with its local variables, and then lost when proc ended.
Fixed by executing the wrapped commands with the command 'uplevel'
instead of 'eval'. The amount of levels to skip is checked to avoid
errors in the unusual case 'ocd_bouncer' is called directly without
the first level of wrapper.
Change-Id: Iff90fb8921faf9b5ab04f61062a530578cc20d78
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: http://openocd.zylin.com/4731
Tested-by: jenkins
Reviewed-by: Christopher Head <chead@zaber.com>
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
