David Brownell [Sun, 10 Oct 2010 21:41:11 +0000 (14:41 -0700)]
swj-dp.tcl (SWD infrastructure #1)
Provide new helper proc that can set up either an SWD or JTAG DAP
based on the transport which is in use -- mostly for SWJ-DP.
Also update some SWJ-DP based chips/targets to use it. The goal
is making SWD-vs-JTAG transparent in most places. SWJ-DP based chips
really need this flexible configuration to cope with debug adapters
that support different transports, without needing new target configs
for each transport or adapter.
For JTAG-DP, callers will use "jtag newtap" directly, as today; only
one chip-level transport option exists.
For SW-DP (e.g. LPC1[13]xx or EFM32, they'll use "swd newdap" directly
(part of an upcoming SWD transport patch). Again, only one transport
option exists, so hard-wiring is appropriate there.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Spencer Oliver [Tue, 5 Oct 2010 14:00:40 +0000 (15:00 +0100)]
gdbderver: fix gdb pipe startup overflow
When usng gdb pipes we need to keep openocd output at a minimum,
otherwise the gdb stdin will overflow and fail.
Make the calls to gdb_port and log_output synchronous to stop this.
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
Firstly this patch fixes the build issue, but it also disables support
for named pipes under Windows. Windows does not support posix named
pipes.
A cross-platfom access layer will need creating before support can be
enabled again.
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
Stick with the name "gdb_port" even if this command
can be used for other things(disable, named pipes,
anonymous stdin/out pipe). "port" is correct for
probably more than 90% of use cases, if not more.
Luca Bruno [Mon, 27 Sep 2010 14:21:04 +0000 (16:21 +0200)]
Update ep93xx and at91rm9200 drivers
ep93xx and at91rm9200 are conditionally built only on arm and were not
updated to reflect changes in command registration handler.
This patch makes them properly compile again, fixing a build failure
experienced on Debian armel.
Signed-off-by: Luca Bruno <lucab@debian.org> Signed-off-by: Zachary T Welch <zwelch@codesourcery.com>
jtagdp: remove #if 0'd kludges and explain why the code is correct
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.
Antonio Borneo [Tue, 21 Sep 2010 08:06:37 +0000 (16:06 +0800)]
TCL scripts: collect duplicated procedures
TCL procedures mrw and mmw, originally in DaVinci target code,
are duplicated in other TCL scripts.
Moved in a common helper file, and added help/usage description.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Mike Dunn [Sun, 19 Sep 2010 21:48:51 +0000 (14:48 -0700)]
xscale: check that wp length does not exceed address
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.
Mike Dunn [Sun, 19 Sep 2010 21:35:46 +0000 (14:35 -0700)]
xscale: bp/wp: additional LOG_ERROR on failure
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?
Mike Dunn [Mon, 13 Sep 2010 19:45:37 +0000 (12:45 -0700)]
xscale: fix sw breakpoints for thumb; set bp immediately
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>
Mike Dunn [Sun, 12 Sep 2010 19:05:07 +0000 (12:05 -0700)]
propagate return status of set_breakpoint() up call chain
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>
you can now set a variable in a script like set version [version].
Also version takes an optional argument "git" to show git version
of source. If git is not installed during the build, then this
will yield an error that is ignored during the build and "version git"
returns an empty string.
Mike Dunn [Thu, 9 Sep 2010 02:13:14 +0000 (19:13 -0700)]
xscale: mark xscale registers invalid on debug entry
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>
Alexander Stein [Wed, 8 Sep 2010 08:17:54 +0000 (10:17 +0200)]
Remove duplicated initialization
I a mail conversation with Øyvind we stated that speed may not be set at
all on case CLOCK_MODE_KHZ and CLOCK_MODE_RCLK. Also there isn't proper
error propagation adapter_khz_to_speed or jtag_rclk_to_speed.
So jtag_get_speed may need some rewrite for error propagation.
Wookey [Tue, 31 Aug 2010 12:53:50 +0000 (13:53 +0100)]
Numonyx M29W160ET patch
Someone called David Carne popped up on IRC and offered a fix (as he's not
on this list so can;t post here). I am just passing it on. (thanx David)
10:54 < davidc__> Basically; the Numonyx M29W160ET has an incorrect CFI PRI
block; it describes the erase blocks backwards
10:54 < davidc__> the linked patch has a fixup for that part [really trivial]:
Spencer Oliver [Wed, 25 Aug 2010 19:29:22 +0000 (20:29 +0100)]
cortex m3: add cortex_m3 reset_config cmd
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>
Spencer Oliver [Tue, 24 Aug 2010 19:50:20 +0000 (20:50 +0100)]
cfg: update Luminary config files
- Update all Luminary config's to use a common target/stellaris.cfg.
- Add Luminary ek-lm3s6965 config.
- Increase working area for boards with more ram.
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
David Brownell [Fri, 27 Aug 2010 22:16:39 +0000 (15:16 -0700)]
bitq: unshadow pause()
bitq.c: In function ‘bitq_scan_field’:
bitq.c:224: error: declaration of ‘pause’ shadows a global declaration
/usr/include/unistd.h:429: error: shadowed declaration is here
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Ben Gardiner [Mon, 9 Aug 2010 18:41:56 +0000 (14:41 -0400)]
cfg: add omapl138 support and da850evm preliminary support
This patch adds support for the omapl138 target and preliminary support for the da850evm. The
target cfg file is based on the icepick routing done by the target/ti_dm6446.cfg file.
I have performed limited testing with this setup. I am posting this patch in the interest of
sharing cfg files and in the hopes that the experts on this list can correct errors I have made or
point out enhancements.
The testing I have performed is debugging uboot with gdb where I also use the following local.cfg
and gdbinit files. Debugging appears to work in so much as 'ni' works.
local.cfg:
gdb_memory_map disable
gdbinit:
target remote localhost:3333
set remote hardware-breakpoint-limit 2
set remote hardware-watchpoint-limit 2
monitor poll on
Øyvind Harboe [Sun, 8 Aug 2010 17:21:04 +0000 (19:21 +0200)]
arm7/9: fix "reset run + halt"
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()
Mike Dunn [Mon, 2 Aug 2010 19:50:29 +0000 (12:50 -0700)]
xscale documentation: vector table handling
Hi everyone. I noticed some incorrect information in the user manual
regarding how the vector table is handled on the xscale, so for your
consideration, here's a short patch that corrects it, and adds a
little more detail I thought might be helpful.
The documentation states that OpenOCD does not attempt to synchronize
the vector tables in memory with those stored in the "mini instruction
cache". In fact, on each resume it does copy from memory to the cache
all entries in the high and low tables that were not previously
defined using the 'xscale vector_table' command. (In
src/target/xscale.c, see xscale_update_vectors(), which is invoked by
xscale_resume().) I take advantage of this during Linux boot-up. The
extra detail describes in general terms how I do this.
Corrections, comments are of course gratefully received.
projects / openocd / log