1. 09 Nov, 2009 2 commits
    • David Brownell's avatar
      finish removing deprecated/obsolete commands · d70d9634
      David Brownell authored
      
      
      It's been about a year since these were deprecated and, in most
      cases, removed.  There's no point in carrying that documentation,
      or backwards compatibility for "jtag_device" and "jtag_speed",
      around forever.  (Or a few remnants of obsolete code...)
      
      Removed a few obsolete uses of "jtag_speed":
      
       - The Calao stuff hasn't worked since July 2008.  (Those Atmel
         targets need to work with a 32KHz core clock after reset until
         board-specific init-reset code sets up the PLL and enables a
         faster JTAg clock.)
       - Parport speed controls don't actually work (tops out at about
         1 MHz on typical HW).
       - In general, speed controls need to live in board.cfg files (or
         sometimes target.cfg files), not interface.cfg ...
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      d70d9634
    • Zachary T Welch's avatar
      src/jtag: remove 'extern' and wrap headers. · 5e9d18f0
      Zachary T Welch authored
      Removes the 'extern' keyword from function declarations.
      Wraps long prototypes to fit into 80 columns.
      
      Fixes documentation for jtag_tap_s::{,has}idcode fields.
      5e9d18f0
  2. 23 Oct, 2009 2 commits
    • David Brownell's avatar
      jtag: clean up TAP state name handling · 79f71fad
      David Brownell authored
      
      
      Some cosmetic cleanup, and switch to a single table mapping
      between state names and symbols (vs two routines which only
      share that state with difficulty).
      
      Get rid of TAP_NUM_STATES, and some related knowledge about
      how TAP numbers are assigned.  Later on, this will help us
      get rid of more such hardwired knowlege.
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      79f71fad
    • David Brownell's avatar
      SVF: clean up, mostly for TAP state name handling · 814183a5
      David Brownell authored
      
      
       - Use the name mappings all the other code uses:
          + name-to-state ... needed to add one special case
          + state-to-name
       - Improve various diagnostics:
          + don't complain about a "valid" state when the issue
            is actually that it must be "stable"
          + say which command was affected
       - Misc:
          + make more private data and code be static
          + use public DIM() not private dimof()
          + shorten the affected lines
      
      Re the mappings, this means we're more generous in inputs we
      accept, since case won't matter.  Also our output diagnostics
      will be a smidgeon more informative, saying "RUN/IDLE" not
      just "IDLE" (emphasizing that there can be side effects).
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      814183a5
  3. 21 Oct, 2009 1 commit
    • David Brownell's avatar
      XSVF: use svf_add_statemove() · 7556a93a
      David Brownell authored
      
      
      XSVF improvements:
      
       - Layer parts of XSVF directly over SVF, calling svf_add_statemove()
         instead of expecting jtag_add_statemove() to conform to the SVF/XSVF
         requirements (which it doesn't).
      
         This should improve XSTATE handling a lot; it removes most users of
         jtag_add_statemove(), and the comments about how it should really do
         what svf_add_statemove() does.
      
       - Update XSTATE logic to be a closer match to the XSVF spec.  The main
         open issue here is (still) that this implementation doesn't know how
         to build and submit paths from single-state transitions ... but now
         it will report that error case.
      
       - Update the User's Guide to mention the two utility scripts for
         working with XSVF, and to mention the five extension opcodes.
      
      Handling of state transition paths is, overall, still a mess.  I think
      they should all be specified as paths not unlike SVF uses, and compiled
      to the bitstrings later ... so that we can actually make sense of the
      paths.  (And see the extra clocks, detours through RUN, etc.)
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      7556a93a
  4. 08 Oct, 2009 2 commits
    • David Brownell's avatar
      prevent abort via polling during jtag_reset · a8234af0
      David Brownell authored
      
      
      Observed:
      
        openocd: core.c:318: jtag_checks: Assertion `jtag_trst == 0' failed.
      
      The issue was that nothing disabled background polling during calls
      from the TCL shell to "jtag_reset 1 1".  Fix by moving the existing
      poll-disable mechanism to the JTAG layer where it belongs, and then
      augmenting it to always pay attention to TRST and SRST.
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      a8234af0
    • David Brownell's avatar
      Stop ignoring most scan chain validation errors · 40c9668b
      David Brownell authored
      
      
      Among other things this causes startup errors to kick in the
      fallback "reset harder" logic during server startup.  Comments
      are also updated a bit, explaining what the various error paths
      signify (in at least my observation).
      
      There's one class of validation error that we can still plausibly
      ignore:  when wrong IDCODE values are observed.
      
      This change seems to have helped make an OMAP5912 behave much
      more reliably.  There's still some post-reset flakiness, but
      it's unrelated to scan verification.
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      40c9668b
  5. 07 Oct, 2009 2 commits
  6. 06 Oct, 2009 1 commit
  7. 05 Oct, 2009 1 commit
    • dbrownell's avatar
      Add a new JTAG "setup" event; use for better DaVinci ICEpick support. · 7c7467b3
      dbrownell authored
      The model is that this fires after scanchain verification, when it's
      safe to call "jtag tapenable $TAPNAME".  So it will fire as part of
      non-error paths of "init" and "reset" command processing.  However it
      will *NOT* trigger during "jtag_reset" processing, which skips all
      scan chain verification, or after verification errors.
      
      ALSO:
       - switch DaVinci chips to use this new mechanism
       - log TAP activation/deactivation, since their IDCODEs aren't verified
       - unify "enum jtag_event" scripted event notifications
       - remove duplicative JTAG_TAP_EVENT_POST_RESET
      
      
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2800 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      7c7467b3
  8. 29 Sep, 2009 1 commit
  9. 17 Sep, 2009 1 commit
  10. 11 Sep, 2009 1 commit
  11. 26 Aug, 2009 1 commit
  12. 18 Aug, 2009 1 commit
  13. 17 Jul, 2009 1 commit
  14. 30 Jun, 2009 1 commit
  15. 29 Jun, 2009 1 commit
    • zwelch's avatar
      David Brownell <david-b@pacbell.net>: · f0fd28a6
      zwelch authored
      Warn when people (or scripts) use numeric identifiers for TAPs,
      instead of dotted.name values.  We want this usage to go away,
      so that for example adding more TAPs doesn't cause config scripts
      to break because some sequence number changed.
      
      It's been deprecated since late 2008, but putting a warning on
      this should help us remove it (say, in June 2010) by helping to
      phase out old (ab)usage in config scripts.
      
      Other than in various config files, the only code expecting such
      a number was the almost unused str9xpec driver.  This code was
      changed to use the TAP it was passed, instead of making its own
      dubious lookup and ignoring that TAP.
      
      
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2415 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      f0fd28a6
  16. 23 Jun, 2009 2 commits
  17. 19 Jun, 2009 1 commit
  18. 18 Jun, 2009 2 commits
  19. 17 Jun, 2009 1 commit
  20. 16 Jun, 2009 4 commits
    • zwelch's avatar
      David Brownell <david-b@pacbell.net>: · a0c10dd2
      zwelch authored
      Extend the internal JTAG event handlers to cover enable/disable,
      and use those events to make sure that targets get "examined" if
      they were disabled when the scan chain was first set up:
      
       - Remove "enum jtag_tap_event", merge with "enum jtag_event",
         so C code can now listen for TAP enable/disable events.
      
       - Report those events so they can trigger callbacks.
      
       - During startup, make target_examine() register a handler to
         catch ENABLE events for any then-disabled targets.
      
      This fixes bugs like "can't halt target after enabling its TAP".
      
      One class of unresolved bugs:  if the target has an ETM hooked
      up to an ETB, nothing activates the ETB.  But starting up the
      ETM without access to the ETB registers fails...
      
      
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2251 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      a0c10dd2
    • zwelch's avatar
      David Brownell <david-b@pacbell.net>: · 5f9b74d0
      zwelch authored
      Doc update:  say "jtag newtap ... -disable" records the
      state after exiting the RESET state, matching the only
      implementation we're working with so far (TI ICEpick-C).
      
      Matching code updates.  Now we can be sure that the
      "enabled" flag value is correct after JTAG resets.
      
      
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2246 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      5f9b74d0
    • zwelch's avatar
      David Brownell <david-b@pacbell.net>: · 03803a9d
      zwelch authored
      Fix a memory leak in jtag_tap_free():  unregister the event
      callback too.
      
      Also fix the associated conceptual bug in unregistering JTAG
      event callbacks:  since the same callback procedure is used
      many times with different callback data (a TAP handle), that
      data must be considered when unregistering any callback.
      
      This could fix some crashes after TAP registration errors,
      by making sure the reset event handler doesn't scribble over
      memory that's now used by something else.
      
      
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2245 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      03803a9d
    • zwelch's avatar
      David Brownell <david-b@pacbell.net>: · c7cfb341
      zwelch authored
      Minor jtag cleanup:
      
       - remove hidden assumption about JTAG event numbering
       - move function declarations to a header
       - some end'o'line whitespace
       - use "calloc" not "malloc + memset"
      
      
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2244 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      c7cfb341
  21. 11 Jun, 2009 6 commits
  22. 09 Jun, 2009 5 commits