1. 10 Apr, 2010 29 commits
  2. 09 Apr, 2010 3 commits
  3. 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>
    • 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>
    • 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>
    • 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>
  4. 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'
      Signed-off-by: default avatarØyvind Harboe <oyvind.harboe@zylin.com>
  5. 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>
  6. 26 Mar, 2010 2 commits