ARM Cortex-A9 multi-core chips expose a single TAP/DAP which connects
to both cores. The '-coreid' option selects which core the target
should connect to.
Note that at present, OpenOCD can connect to either core, but not both
simulatenously, until ADI contexts can be shared.
Signed-off-by: Aaron Carroll <aaronc@cse.unsw.edu.au>
ahbap_debugport_init was queueing reads to a local stack variable but
didn't execute the queue before returning. Since the result of the reads
are not used anyway, it's better to pass NULL as the destination instead of
a dummy variable. I changed this throughout the function, even for the
reads that were actually executed.
Signed-off-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
Remove extra \n from LOG_DEBUG, LOG_INFO, and LOG_WARNING messages
Remove LOG_INFO_N
LOG_INFO_N was only used once and had a \n at the end
Change LOG_USER_N calls that end with \n to LOG_USER
Add a working area that is preserved between calls to
mips_m4k_bulk_write_memory - this gives us a speed increase
of approx 3kb/sec during flash writes to the pic32mx.
This area is released during a resume/reset.
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
We only use the struct working_area member 'free' as a
true/false type so might as well use a bool data type.
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
Do not propagate error number to user. This is for internal
programming purposes only. Error messages to the user is
reported as text via LOG_ERROR().
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
This patch fixes the issue where the OMAP CPU (and possibly others) was mistaken
for iMX51 and therefore had misadjusted debug base.
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
I received a number of "-Wshadow" related warnings (treated as errors) while
trying to build on OS X Leopard. In addition, there were two miscellaneous
other warnings in the flash drivers. Attached are two patches which correct
these issues and the commit messages to accompany them.
My system has the following configuration (taken from uname -a):
Darwin 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009;
root:xnu-1228.15.4~1/RELEASE_I386 i386
=== Werror_patch.txt Commit Message ===
compilation: fixes for -Wshadow warnings on OS X
These changes fix -Wshadow compilation warnings on OS X 10.5.8
Compiled with the following configure command:
../configure --prefix=/usr/local --enable-maintainer-mode --enable-jlink
--enable-ft2232_libftdi
=== flash_patch.txt Commit Message ===
compilation: fixes for flash driver warnings on OS X
These changes fix two compilation warnings on OS X 10.5.8:
../../../../src/flash/nor/at91sam3.c:2767: warning: redundant redeclaration
of 'at91sam3_flash'
../../../../src/flash/nor/at91sam3.c:101: warning: previous declaration of
'at91sam3_flash' was here
and
../../../../src/flash/nor/stmsmi.c:205: warning: format not a string literal
and no format arguments
Compiled with the following configure command:
../configure --prefix=/usr/local --enable-maintainer-mode --enable-jlink
--enable-ft2232_libftdi
===
Andrew
error numbers are only reported at DEBUG log levels and
used internally, they are not part of the user interface.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
This piggy backs on JTAG so it's not yet pretty, but that
seems unavoidable so far given today's OpenOCD internals.
SWD init and data transfer are unfinished and untested, but
that should cause no regressions, and will be addressed by
the time drivers start using this infrastructure. Checking
in whould get the code working better sooner, and turn up any
structural/architectural issues while they're easier to fix.
The debug adapter drivers will provide simple SWD driver
structs with methods that kick in as needed (instead of JTAG).
So far just one adapter driver has been updated (not yet
ready to use or circulate).
The biggest issues are probably
- fault handling, where the ARM Debug Interface V5 pipelining
needs work in both JTAG and SWD modes and
- missing rewrite of block I/O code to work on both of our
Cortex-ready transports (Current code is hard-wired to JTAG);
relates also to the pipelining issue.
- omitted support to activate/deactivate SWO/SWV trace (this is
technically trivial, but configuring what to trace is NOT.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
----
doc/openocd.texi | 17 ++
src/jtag/core.c | 3
src/jtag/interface.h | 4
src/jtag/jtag.h | 2
src/jtag/swd.h | 114 +++++++++++++++++++
src/jtag/tcl.c | 2
src/target/adi_v5_swd.c | 281 ++++++++++++++++++++++++++++++++++++++++++++++--
src/target/arm_adi_v5.c | 8 +
src/target/arm_adi_v5.h | 3
9 files changed, 425 insertions(+), 9 deletions(-)
this allows configuration scripts to export a init_targets proc
rather than setting up the target directly.
This allows for new conventions in how to set up target vs. board
script and how to transfer default settings between board and
target scripts.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Hi everyone,
Since a call went out for patches... been sitting on this for months. For some
reason, the xscale trace buffer is automatically disabled as soon as a break
occurs and the trace data is collected. This patch was a result of the
frustration of always re-enabling it, or else hitting a breakpoint and checking
the trace data, only to discover that I forgot to re-enable it before resuming.
Don't see why it should work this way. There is no run-time penalty, AFAIK.
Along the way, I also cleaned up a little by removing the ugly practice of
recording wrap mode by setting the fill count variable to "-1", replacing it
with an enum that records the trace mode.
I've been using this for months. Comments, criticisms gratefully received.
Mike
Signed-off-by: Mike Dunn <mikedunn@newsguy.com>
Currently the cmd 'cortex_m3 reset_config' will overide the default
target's 'reset_config'.
Chnage the behaviour to use the target 'reset_config' if configured and
fallback if not.
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
it's a lie that is somewhere in the vicinity of the
truth. Certainly 64MHz confuses gprof and produces
zero output and no error messages.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
If the CPU crashed at some point, poll will discover this.
Previously the poll fn would clear the error and print a warning,
rather than propagating the error.
The new behavior is to report the error back up, but still
clear the error.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Implement autodetection of debug base. Also, implement a function solving
various hardware quirks (like iMX51 ROM Table location bug).
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
This patch implements "dap_lookup_cs_component()", which allows to lookup CS
component by it's identification.
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
This patch adds function called "dap_detect_debug_base()", which should be
called to get location of the ROM Table. By walking ROM Table, it's possible to
discover the location of DAP.
Sadly, some CPUs misreport this value, therefore I had to introduce an fixup
table, which will be used in case such CPU is detected.
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
So far most of the people have been using existing ARM966E in the
place of ARM946E, because they have practically the same scan chains.
However, ARM946E has caches, which further complicates JATG handling
via scan-chain. this was preventing single-stepping for ARM946E when
SW breakpoints are used.
This patch thus introduces :
1) Correct cache handling on memory write
2) Possibility to flush whole cache and turn it off during debug, or
just to flush affected lines (faster and better)
3) Correct SW breakpoint handling and correct single-stepping
4) Corrects the bug on CP15 read and write, so CP15 values
are now correctly R/W
Collect variable definitions.
Report syntax error to command dispatcher.
Propagate error when unable to open file.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
short story: if the JTAG clock is too high, then the
behavior will be flaky and kludging the code may
seem to make things beter, but really it's just a red
herring.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Hi everyone,
A while back I sent in a patch that adds support for watchpoint lengths greater
than four on xscale. It's been working well, until the other day, when it
caused an unexpected debug exception. Looking into this I realized there is a
case where it breaks: when the length arg is greater than the base address.
This is a consequence of the way the hardware works. Don't see a work-around,
so I added code to xscale_add_watchpoint() to check for and disallow this
combination.
Some more detail... xscale watchpoint hardware does not support a length
directly. Instead, a mask value can be specified (not to be confused with the
optional mask arg to the wp command, which xscale does not support). Any bits
set in the mask are ignored when the watchpoint hardware compares the access
address to the watchpoint address. So as long as the length is a power of two,
setting the mask to length-1 effectively specifies the length. Or so I thought,
until I realized that if the length exceeds the base address, *all* bits of the
base address are ignored by the comaparator, and the watchpoint range
effectively becomes 0 .. length.
Questions, comments, criticisms gratefully received.
Thanks,
Mike
Signed-off-by: Mike Dunn <mikedunn@newsguy.com>
Hi everyone,
Added more LOG_ERROR messsages to watchpoint and breakpoint code, given that the
infrastructure no longer interprets returned error codes. Also changed
existing LOG_INFO and LOG_WARNING to LOG_ERROR for cases where an error is
returned.
Note that the check of the target state is superflous, since the infrastruture
code currently checks this before calling target code. Is this being
reconsidered as well? Also, should we stop returning anything other than
ERROR_OK and ERROR_FAIL?
Comments gratefully received.
Thanks,
Mike
Signed-off-by: Mike Dunn <mikedunn@newsguy.com>
do not try to interpret "retval" into a string, just
amend a bit about the context of the already reported
error.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Hi everyone,
Version 2 of this patch. Code added to breakpoints.c was removed from previous
patch, and item 3 added, per discussion with Øyvind regarding error reporting.
Item 4 added, which I just noticed.
I tried to use a software breakpoint in thumb code on the xscale for the first
time recently, and was surprised to find that it didn't work. The result was
this patch, which does four things:
1): fix trivial cut-n-paste error that caused thumb breakpoints to not work
2): call xscale_set_breakpoint() from xscale_add_breakpoint()
3): log error on data abort in xscale_write_memory()
4): fixed incorrect error code returned by xscale_set_breakpoint() when no
breakpoint register is available; added comment
Item 2 not only makes the xscale breakpoint code consistent with other targets,
but also alerts the user immediately if an error occurs when writing the
breakpoint instruction to target memory (previously, xscale_set_breakpoint() was
not called until execution resumed). Also, calling xscale_breakpoint_set() as
part of the call chain starting with handle_bp_command() and propagating the
return status back up the chain avoids the situation where OpenOCD "thinks" the
breakpoint is set when in reality an error ocurred.
Item 3 provides a helpful message for a common reason for failure to set sw
breakpoint.
This was thoroughly tested, mindful of the fact that breakpoint management is
somewhat dicey during single-stepping.
Comments and criticisms of course gratefully received.
Mike
Signed-off-by: Mike Dunn <mikedunn@newsguy.com>
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Hi everyone,
I figured since I was poking around in the breakpoint code on other arches, I'd
add this change to those arches that don't do it already. This patch propagates
the return code of <arch>_set_breakpoint() up the call stack. This ensures that
the higher layer breakpoint infrastructure is aware that an error ocurred, in
which case the breakpoint is not recorded.
Normally I wouldn't touch code that I can't test, but the code is very
uniform across architectures, and the change is rather benign, so I figured
after careful inspection that it is safe. If the maintainers or others think
this is imprudent, the patch can be dropped.
Also changed the error code to something more appropriate in two cases where
hardware resources are unavailable.
Comments and criticisms of course gratefully received.
Mike
Signed-off-by: Mike Dunn <mikedunn@newsguy.com>
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Hi everyone,
This simple patch fixes a problem I noticed on the xscale where incorrect values
are sometimes reported by the reg command. The problem can occur when
requesting the value of registers in the xscale-specific register cache. With a
couple of exceptions, none of the registers in the xscale register cache are
automatically retrieved on debug entry. This is probably fine, as they are
unlikely to be needed on a regular basis during a typical debug session, and
they can be retrieved when explicitly requested by name using the reg command.
The problem is that once this is done, the register remains marked as valid for
the remainder of the OpenOCD session, and the reg command will henceforth always
report the same value because it is obtained from the cache and is never again
retrieved from the debug handler on the target.
The fix is to mark all registers in the xscale register cache as invalid on
debug entry (before the two exceptions are retrieved), thus forcing retrieval
(when requested) from the target across resumptions in execution, and avoiding
the reporting of stale values.
Small addition change by Øyvind: change 'i' to unsigned to fix compiler
warning for xscale_debug_entry() fn.
Signed-off-by: Mike Dunn <mikedunn@newsguy.com>
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
This new cmd adds the ability to choose the Cortex-M3
reset method used.
It defaults to using SRST for reset if available otherwise
it falls back to using NVIC VECTRESET. This is known to work
on all cores.
Move any luminary specific reset handling to the stellaris cfg file.
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
committed so as to ease cooperation and to let it be improved
over time.
So far it supports:
- halt/resume
- registers inspection
- memory inspection/modification
I'm still getting up to speed with OpenOCD internals and AVR32 so code is a little
bit messy and I'd appreciate any feedback.
ocd_ prefix is used internally in OpenOCD as a kludge more
or less to deal with the two kinds of commands that OpenOCD
has.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
if polling is off, then "reset run + halt" would fail
since halt incorrectly assumed the target was in the
reset state as it is the internal poll implementation
that moves the sw tracking of the target state out
of the reset state.
To reproduce:
> reset run; halt
JTAG tap: zy1000.cpu tap/device found: 0x1f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x1)
BUG: arm7/9 does not support halt during reset. This is handled in arm7_9_assert_reset()
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Aaron Carroll
Mathias K
Andreas Fritiofson
Eric Wetzel
Spencer Oliver
Øyvind Harboe
Marek Vasut
Andrew MacIsaac
David Brownell
Mike Dunn
ddraskovic
Peter Stuge
Antonio Borneo
Oleksandr Tymoshenko