1. 09 Apr, 2010 1 commit
  2. 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
  3. 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
  4. 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
  5. 26 Mar, 2010 2 commits
  6. 25 Mar, 2010 6 commits
  7. 24 Mar, 2010 3 commits
  8. 22 Mar, 2010 4 commits
    • Øyvind Harboe's avatar
      zy1000: fix optimisaion bug in dcc writes · 721502f1
      Øyvind Harboe authored
      
      
      Introduced & corrected since 0.4.
      
      Signed-off-by: default avatarØyvind Harboe <oyvind.harboe@zylin.com>
      721502f1
    • Mike Dunn's avatar
      fix software breakpoints on xscale · 4be9eded
      Mike Dunn authored
      This patch fixes xscale software breakpoints by cleaning the dcache and
      invalidating the icache after the bkpt instruction is inserted or removed.  The
      icache operation is necessary in order to flush the fetch buffers, even if the
      icache is disabled (see section 4.2.7 of the xscale core developer's manual).
      The dcache is presumed to be enabled; no harm done if not.  The dcache is also
      invalidated after cleaning in order to safeguard against a future load of
      invalid data, in the event that cache_clean_address points to memory that is
      valid and in use.
      
      Also corrected a confusing typo I noticed in a comment.
      
      TODO (or not TODO...?): the xscale's 2K "mini dcache" is not cleaned.  This
      cache is not used unless the 'X' bit in the page table entry is set.  This is a
      proprietary xscale extension to the ARM architecture.  If a target's OS or
      executive makes use of this for memory regions holding code, the breakpoint
      problem will persist.  Flushing the mini dcache requires that 2K of valid
      cacheable memory (mapped with 'X' bit set) be designated by the user for this
      purpose.  The debug handler that gets downloaded to the target will also need to
      be extended.
      4be9eded
    • Øyvind Harboe's avatar
      bitq: fix warning now that out_value is const · ccfaed8b
      Øyvind Harboe authored
      
      
      This was an easy one. Just add the missing "const" to a
      local variable definition.
      
      Signed-off-by: default avatarØyvind Harboe <oyvind.harboe@zylin.com>
      ccfaed8b
    • David Brownell's avatar
      ft2232 init mess cleanup · c2f714bd
      David Brownell authored
      
      
      In the ft2232 driver, initialization for many layouts punts to a routine
      called usbjtag_init(), instead of a routine specific to each layout.
      
      That routine is  a mess  built around a "what type layout am I" core.
      That's a bad design ... in this case, especially so, since it bypasses
      the layout-specific dispatch which was just done, and obfuscates the
      initialization which is at least somewhat generic, instead of being
      specific to the "usbjtag" layout.
      
      Split and document out the generic parts of usbjtag_init(), and make
      the rest of those layouts have layout-specific init methods.  Also,
      rename usbjtag_reset() ... that also was not specific to the "usbjtag"
      layout, and thus contributed to the previous code structure confusion.
      
      (Eventually, all layout-specific code (and method tables) should probably
      live in files specific to each layout.  These changes will facilitate
      those and other cleanups to this driver.)
      
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      c2f714bd
  9. 21 Mar, 2010 2 commits
  10. 20 Mar, 2010 1 commit
  11. 19 Mar, 2010 9 commits
  12. 18 Mar, 2010 6 commits