Skip to content
GitLab
  1. 10 Apr, 2010 29 commits
  3. 09 Apr, 2010 3 commits
  5. 04 Apr, 2010 4 commits
    • David Brownell's avatar
      Restore deleted '!' character · 2a17fd9f
      David Brownell authored 
      

I'm not sure what caused this significant character to get deleted.
it may be related to intermittent Editor or terminal flakes  I've
been seeing lately (sigh).  This fix is trivial.

Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      2a17fd9f
    • David Brownell's avatar
      target: are we running algorithm code? · 876bf9bf
      David Brownell authored 
      

Fixing one bug can easily uncover another  .... in this case,
making sure that we properly invalidate some cached NOR state when
resuming arbitrary target code turned up an issue when the code
wasn't quite arbitrary (and we couldn't know that, but some parts
of OpenOCD assumed the cache would not be invalidated.

Specifically:  some flash drivers (like CFI) update that state in loops
with downloaded algorithms, thus invalidating the state as it's probed.

 + Add a new target state flag, to record whether the target is
  running downloaded algorithm code.

 + Use that flag to add a special case:  "trust" downloaded algorithms
   not to corrupt that cached state, bypassing cache invalidation.

Also update some of the documentation to stipulate that this flavor of
trustworthiness is now *required* ... not just a fortuitous acident.

Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      876bf9bf
    • David Brownell's avatar
      simplify and unconfuse target_run_algorithm() · 88fcb5a9
      David Brownell authored 
      

For some reason there are *two* schemes for interposing logic into
the run_algorithm() code path...  One is a standard procedural wapper
around the target method invocation.

the other (superfluous) one hacked the method table by splicing
a second procedural wrapper into the method table.  Remove it:

	* Rename its  slightly-more-featureful wrapper so it becomes
	  the standard procedural wrapper, leaving its added logic
	  (where it should have been in the first place.

          Also add a paranoia check, to report targets that don't
	  support algorithms without traversing a NULL pointer, and
	  tweak its code structure a bit so it's easier to modify.

	* Get rid of the superfluous/conusing method table hacks.

This is a net simplification, making it simpler to analyse what's
going on, and then interpose logic . ... by ensuring there's only one
natural place for it to live.

------------

Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      88fcb5a9
    • David Brownell's avatar
      buildfix · d37a10da
      David Brownell authored 
      

Without this, a system using gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4)
aborts builds after reporting:

tcl.c: In function ‘handle_irscan_command’:
tcl.c:1168: warning: passing argument 1 of ‘buf_set_u32’ discards qualifiers from pointer target type

Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      d37a10da
  7. 29 Mar, 2010 1 commit
    • Mike Dunn's avatar
      xscale: fix trace buffer functionality when resuming from a breakpoint · 33e5dd12
      Mike Dunn authored 
      

Problem: halt at a breakpoint, enable trace buffer ('xscale trace_buffer enable
fill'), then resume.  Wait for debug exception when trace buffer fills (if not
sooner due to another breakpoint, vector catch, etc).  Instead, never halts.
When halted explicitly from OpenOCD and trace buffer dumped, it contains only
one entry; a branch to the address of the original breakpoint.  If the above
steps are repeated, except that the breakpoint is removed before resuming, the
trace buffer fills and the debug exception is generated, as expected.

Cause: related to how a breakpoint is stepped over on resume.  The breakpoint is
temporarily removed, and a hardware breakpoint is set on the next instruction
that will execute.  xscale_debug_entry() is called when that breakpoint hits.
This function checks if the trace buffer is enabled, and if so reads the trace
buffer from the target and then disables the trace (unless multiple trace
buffers are specified by the user when trace is enabled).  Thus you only trace
one instruction before it is disabled.

Solution: kind of a hack on top of a hack, but it's simple.  Anything better
would involve some refactoring.  This has been tested and trace now works as
intended, except that the very first instruction is not part of the trace when
resuming from a breakpoint.

TODO: still many issues with trace: doesn't work during single-stepping (trace
buffer is flushed each step), 'xscale analyze_trace' works only marginally for
a trace captured in 'fill' mode, and not at all for a trace captured in 'wrap'
mode.

Signed-off-by: default avatarØyvind Harboe <oyvind.harboe@zylin.com>
      33e5dd12
  9. 27 Mar, 2010 1 commit
    • David Brownell's avatar
      jtag/tcl.c cleanup -- split out "adapter.c" · d60ebc0a
      David Brownell authored 
      

Clean up the jtag/tcl.c file, which was one of the biggest and
messiest ones in that directory.  Do it by splitting out all the
generic adapter commands to a separate "adapter.c" file (leaving
the "tcl.c" file holding only JTAG utilities).

Also rename the little-used "jtag interface" to "adapter_name", which
should have been at least re-categorized earlier (it's not jtag-only).

Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      d60ebc0a
  11. 26 Mar, 2010 2 commits