1. 09 Nov, 2009 3 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>
    • David Brownell's avatar
      User's Guide: Flash/NAND doc tweaks · 9253ce9b
      David Brownell authored
      Rename the "Drivers, Options, and Commands" sections to be
      just "Driver List" matching the earlier reference.  Add an
      example of parallel CFI flash.
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
    • David Brownell's avatar
      User's Guide: bugfix global state info · 4882647f
      David Brownell authored
      The "$ocd_HOSTOS" variable was wrongly documented.  Fix its
      documentation, and its value on Linux.
      Shrink a few of the too-long lines.
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
  2. 08 Nov, 2009 1 commit
    • David Brownell's avatar
      target.cfg: remove "-work-area-virt 0" · 3e6f9e8d
      David Brownell authored
      The semantics of "-work-area-virt 0" (or phys) changed with
      the patch to require specifying physical or virtrual work
      area addresses.  Specifying zero was previously a NOP.  Now
      it means that address zero is valid.
      This patch addresses three related issues:
       - MMU-less processors should never specify work-area-virt;
         remove those specifications.  Such processors include
         ARM7TDMI, Cortex-M3, and ARM966.
       - MMU-equipped processors *can* specify work-area-virt...
         but zero won't be appropriate, except in mischievous
         contexts (which hide null pointer exceptions).
         Remove those specs from those processors too.  If any of
         those mappings is valid, someone will need to submit a
         patch adding it ... along with a comment saying what OS
         provides the mapping, and in which context.  Example,
         say "works with Linux 2.6.30+, in kernel mode".  (Note
         that ARM Linux doesn't map kernel memory to zero ...)
       - Clarify docs on that "-virt" and other work area stuff.
      Seems to me work-area-virt is quite problematic; not every
      operating system provides such static mappings; if they do,
      they're not in every MMU context...
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
  3. 05 Nov, 2009 1 commit
  4. 02 Nov, 2009 1 commit
  5. 25 Oct, 2009 1 commit
  6. 23 Oct, 2009 1 commit
    • David Brownell's avatar
      arm9tdmi vector_catch: reserved means "don't use" · 75cdc8a2
      David Brownell authored
      Bit 5 shouldn't be used.  Remove all support for modifying it.
      Matches the exception vector table, of course ... more than one
      bootloader uses that non-vector to help distinguish valid boot
      images from random garbage in flash.
  7. 22 Oct, 2009 1 commit
    • David Brownell's avatar
      ETM: rename registers, doc tweaks · 344bed2f
      David Brownell authored
      The register names are perversely not documented as zero-indexed,
      so rename them to match that convention.  Also switch to lowercase
      suffixes and infix numbering, matching ETB and EmbeddedICE usage.
      Update docs to be a bit more accurate, especially regarding what
      the "trigger" event can cause; and to split the issues into a few
      more paragraphs, for clarity.
      Make "configure" helptext point out that "oocd_trace" is prototype
      hardware, not anything "real".
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
  8. 21 Oct, 2009 4 commits
  9. 20 Oct, 2009 1 commit
  10. 19 Oct, 2009 1 commit
  11. 14 Oct, 2009 1 commit
    • David Brownell's avatar
      doc updates to match "help" better · bc792857
      David Brownell authored
      This makes the documentation a closer match to "help" output:
       - "pathmove" somehow was not documented in the User's Guide
       - "jtag_nsrst_assert_width" and "jtag_ntrst_assert_width"
         are new; both needed descriptions.
       - Removed two undocumented and fairly useless script mechanisms:
          * production/production_info/production_test ... using it,
            requires replacing everything; so having it adds no value.
          * cpu ... way out of date; hopeless to keep that current
      Note that anyone using that "production" stuff already defines
      their own procedures, and can keep using them with no change.
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
  12. 13 Oct, 2009 1 commit
  13. 12 Oct, 2009 2 commits
  14. 09 Oct, 2009 3 commits
  15. 08 Oct, 2009 2 commits
  16. 07 Oct, 2009 3 commits
  17. 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.
       - 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
  18. 02 Oct, 2009 1 commit
    • dbrownell's avatar
      Minor ETB and ETM bugfixes and doc updates · 10336333
      dbrownell authored
       - ETB
          * report _actual_ hardware status, not just expected status
          * add a missing diagnostic on a potential ETB setup error
          * prefix any diagnostics with "ETB"
       - ETM
          * make "etm status" show ETM hardware status too, instead of
            just traceport status (which previously was fake, sigh)
       - Docs
          * flesh out "etm tracemode" docs a bit
          * clarify "etm status" ... previously it was traceport status
          * explain "etm trigger_percent" as a *traceport* option
      ETM+ETB tracing still isn't behaving, but now I can see that part of 
      the reason is that the ETB turns itself off almost immediately after
      being enabled, and before collecting any data.
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2790 b42882b7-edfa-0310-969c-e2dbd0fdcd60
  19. 29 Sep, 2009 3 commits
  20. 26 Sep, 2009 1 commit
    • dbrownell's avatar
      Streamline Capture-IR handling and integrity test. · 2e210ee4
      dbrownell authored
      Change the handling of the "-ircapture" and "-irmask" parameters
      to be slightly more sensible, given that the JTAG spec describes
      what is required, and that we already require that conformance in
      one place.  IR scan returns some bitstring with LSBs "01".
       - First, provide and use default values that satisfy the IEEE spec.
         Existing TAP configs will override the defaults, but those parms
         are no longer required.
       - Second, warn if any TAP gets set up to violate the JTAG spec.
         It's likely a bug, but maybe not; else this should be an error.
         Improve the related diagnostics to say which TAP is affected.
      And associated minor fixes/cleanups to comments and diagnostics.
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2758 b42882b7-edfa-0310-969c-e2dbd0fdcd60
  21. 23 Sep, 2009 1 commit
    • dbrownell's avatar
      When setting up an ETM, cache its ETM_CONFIG register. Then · 22045fa6
      dbrownell authored
      only expose the registers which are actually present.  They
      could be missing for two basic reasons:
       - This version might not support them at all; e.g. ETMv1.1
         doesn't have some control/status registers.  (My sample of
         ARM9 boards shows all with ETMv1.3 support, FWIW.)
       - The configuration on this chip may not populate as many
         registers as possible; e.g. only two data value comparators
         instead of eight.
      Includes a bugfix in the "etm info" command:  only one of the
      two registers is missing on older silicon, so show the first
      one before bailing.
      Update ETM usage docs to explain that those registers need to be
      written to configure what is traced, and that some ETM configs
      are not yet handled.  Also, give some examples of the kinds of
      constrained trace which could be arranged.
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2752 b42882b7-edfa-0310-969c-e2dbd0fdcd60
  22. 22 Sep, 2009 1 commit
  23. 21 Sep, 2009 2 commits
  24. 20 Sep, 2009 1 commit
  25. 19 Sep, 2009 1 commit
  26. 17 Sep, 2009 1 commit
    • dbrownell's avatar
      Minor fixes to NAND code and docs · 9536577c
      dbrownell authored
      Erase logic:
       - command invocation
          + treat "nand erase N" (no offset/length) as "erase whole chip N"
          + catch a few more bogus parameter cases, like length == 0 (sigh)
       - nand_erase() should be static
       - on error
          + say which block failed, and if it was a bad block
          + don't give up after the first error; try to erase the rest
       - on success, say which nand device was erased (name isn't unique)
      Device list ("nand list"):
       - say how many blocks there are
       - split summary into two lines
       - give example in the docs
      Doc tweaks:
       - Use @option{...} for DaVinci's supported hardware ECC options
      For the record, I've observed that _sometimes_ erasing bad blocks causes
      failure reports, and that manufacturer bad block markers aren't always
      erasable (even when erasing their blocks doesn't trigger an error report).
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2724 b42882b7-edfa-0310-969c-e2dbd0fdcd60