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.
Peter Stuge [Sun, 1 Aug 2010 01:26:47 +0000 (03:26 +0200)]
Remove srst_pulls_trst from LPC2148 target
srst_pulls_trst is only true on some (broken) LPC2148 boards, a fact
which is already documented in doc/openocd.texi, so it shouldn't be
set unconditionally in the target tcl.
This patch was needed to reflash when an Abort exception occured very
early after reset, before OpenOCD tried to halt the CPU.
David Brownell [Sun, 1 Aug 2010 06:27:14 +0000 (02:27 -0400)]
stellaris flash comment update
This flash driver works on more than just two chips.
(Though it does need work still, e.g. to protect more than 64K.
(On non-'3748-A0 chips where errata allow that.))
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
projects / openocd / log