1. 09 Nov, 2009 1 commit
    • 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>
  2. 26 Oct, 2009 1 commit
    • David Brownell's avatar
      JTAG: simple autoprobing · 6cb1d10c
      David Brownell authored
      This patch adds basic autoprobing support for the JTAG scan chains
      which cooperate.  To use, you can invoke OpenOCD with just:
       - interface spec: "-f interface/...cfg"
       - possibly with "-c 'reset_config ...'" for SRST/TRST
       - possibly with "-c 'jtag_khz ...'" for the JTAG clock
      Then set up config files matching the reported TAPs.  It doesn't
      declare targets ... just TAPs.  So facilities above the JTAG and
      SVF/XSVF levels won't be available without a real config; this is
      almost purely a way to generate diagnostics.
      Autoprobe was successful with most boards I tested, except ones
      incorporating C55x DSPs (which don't cooperate with this scheme
      for IR length autodetection).  Here's what one multi-TAP chip
      reported, with the "Warn:" prefixes removed:
       clock speed 500 kHz
       There are no enabled taps.  AUTO PROBING MIGHT NOT WORK!!
       AUTO auto0.tap - use "jtag newtap auto0 tap -expected-id 0x2b900f0f ..."
       AUTO auto1.tap - use "jtag newtap auto1 tap -expected-id 0x07926001 ..."
       AUTO auto2.tap - use "jtag newtap auto2 tap -expected-id 0x0b73b02f ..."
       AUTO auto0.tap - use "... -irlen 4"
       AUTO auto1.tap - use "... -irlen 4"
       AUTO auto2.tap - use "... -irlen 6"
       no gdb ports allocated as no target has been specified
      The patch tweaks IR setup a bit, so we can represent TAPs with
      undeclared IR length.
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
  3. 25 Oct, 2009 1 commit
  4. 20 Oct, 2009 1 commit
  5. 15 Oct, 2009 1 commit
  6. 10 Oct, 2009 1 commit
  7. 09 Oct, 2009 2 commits
  8. 08 Oct, 2009 2 commits
    • David Brownell's avatar
      prevent abort via polling during jtag_reset · a8234af0
      David Brownell authored
        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>
    • 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>
  9. 07 Oct, 2009 3 commits
  10. 06 Oct, 2009 1 commit
  11. 05 Oct, 2009 2 commits
    • dbrownell's avatar
      Improve jtag_validate_ircapture() diagnostics. · 7a57c316
      dbrownell authored
      Bugfix the error message so it shows the disliked value, and add
      a debug message showing each TAP's IR capture value, all N bits.
      This just changes diagnostics ... it still ignores the parameters
      given to us at TAP declaration time.
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2801 b42882b7-edfa-0310-969c-e2dbd0fdcd60
    • 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.
       - 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
  12. 29 Sep, 2009 3 commits
  13. 26 Sep, 2009 2 commits
  14. 21 Sep, 2009 1 commit
    • dbrownell's avatar
      Update the jtag-examine_chain() logic to verify that there's no · d20103cd
      dbrownell authored
      garbage after the expected data (from the TAPs' BYPASS or IDCODE
      NOTE that there was previously some code that looked like it was
      trying to do this ... which didn't work, because it was looping
      over the list of expected TAPs, and never checked *after* that
      list completed!  That could hide some *nasty* reset issues...
      Also replace a now-obsolete scanchain length test with one that
      behaves correctly; and update reporting of unexpected IDCODEs.
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2739 b42882b7-edfa-0310-969c-e2dbd0fdcd60
  15. 20 Sep, 2009 1 commit
    • dbrownell's avatar
      Debug message updates: · 0c4b119d
      dbrownell authored
       - Shrink messaging during resets, primarily by getting rid of
         "nothing happened" noise that hides *useful* information.
       - Improve: the "no IDCODE" message by identifying which tap only
         supports BYPASS; and the TAP event strings.
      Related minor code updates:
       - Remove two needless tests when examining the chain:  we know
         we have a TAP, and that all TAPs have names.
       - Clean up two loops, turning "while"s into "for"s which better
         show what's actually being done.
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2736 b42882b7-edfa-0310-969c-e2dbd0fdcd60
  16. 19 Sep, 2009 1 commit
    • dbrownell's avatar
      Minor behavior fixes for the two JTAG reset events (C/internal, · 2d3bcddf
      dbrownell authored
      and Tcl/external):
       - Reorder so *both* paths (TCK/TMS or TRST) can enable TAPs with
         ICEpick ... first C code flags TAPs that got disabled, then call
         any Tcl code that might want to re-enable them.
       - Always call the C/internal handlers when JTAG operations can be
         issued; previously that wasn't done when TRST was used. 
      Plus some small cleanups (whitespace, strings, better messaging
      during debug and on some errors) to reset-related code.
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2730 b42882b7-edfa-0310-969c-e2dbd0fdcd60
  17. 17 Sep, 2009 1 commit
  18. 11 Sep, 2009 1 commit
  19. 26 Aug, 2009 3 commits
  20. 25 Aug, 2009 3 commits
    • oharboe's avatar
      David Brownell <david-b@pacbell.net> More jtag_add_reset() cleanup: · 24f011eb
      oharboe authored
      Unify the handling of the req_srst parameter, and rip out a
      large NOP branch and its associated FIXME.  (There didn't seem
      to be anything that needs fixing; but that was unclear since
      the constraints were scattered all over the place not unified.)
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2623 b42882b7-edfa-0310-969c-e2dbd0fdcd60
    • oharboe's avatar
      David Brownell <david-b@pacbell.net> More jtag_add_reset() cleanup: · 86b49612
      oharboe authored
      Unify the handling of the req_tlr_or_trst parameter.  Basically,
      JTAG TMS+TCK ops ("TLR") is always used ... unless TRST is a safe
      option in this system configuration.
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2622 b42882b7-edfa-0310-969c-e2dbd0fdcd60
    • oharboe's avatar
      David Brownell <david-b@pacbell.net> Some jtag_add_reset() cleanup: · 6f359fba
      oharboe authored
       - Track whether TRST and/or SRST actually change:
          * If they're not changing, don't ask the JTAG adapter to do anything!
            (JTAG TCK/TMS ops might still be used to enter TAP_RESET though.)
          * Don't change their recorded values until after the adapter says it
            did so ... so fault paths can't leave corrupt state.
          * Detect and report jtag_execute_queue() failure mode
          * Only emit messages saying what really changed; this includes adding
            an omitted "deasserted TRST" message.
          * Only apply delays after deasserting SRST/TRST if we *DID* deassert!
       - Messages say "TLR" not "RESET", to be less confusing; there are many
         kinds of reset.  (Though "TLR" isn't quite ideal either, since it's
         the name of the TAP state being entered by TMS+TCK or TRST; it's at
         least non-ambiguous in context.)
      So the main effect is to do only the work this routine was told to do;
      and to have debug messaging make more sense.
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2621 b42882b7-edfa-0310-969c-e2dbd0fdcd60
  21. 24 Aug, 2009 1 commit
  22. 18 Aug, 2009 1 commit
  23. 17 Jul, 2009 1 commit
  24. 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
  25. 23 Jun, 2009 4 commits