Version 0.3.1

Remove "-dev" tag

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>

BUGS

@@ -22,7 +22,8 @@ that may be important.
 - If the report is for a regression:
   - Include logs for both working and broken versions.
   - Find the precise version that caused the regression by binary search.
-    You can use "git bisect" to expedite this binary search.
+    You can use "git bisect" to expedite this binary search:  
+    http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
 
 If possible, please develop and attach a patch that helps to expose or
 solve the reported problem.  See the PATCHES file for more information

Doxyfile.in

@@ -307,13 +307,13 @@ EXTRACT_PRIVATE        = NO
 # If the EXTRACT_STATIC tag is set to YES all static members of a file
 # will be included in the documentation.
 
-EXTRACT_STATIC         = YES
+EXTRACT_STATIC         = NO
 
 # If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs)
 # defined locally in source files will be included in the documentation.
 # If set to NO only classes defined in header files are included.
 
-EXTRACT_LOCAL_CLASSES  = YES
+EXTRACT_LOCAL_CLASSES  = NO
 
 # This flag is only useful for Objective-C code. When set to YES local
 # methods, which are defined in the implementation section but not in

NEWS

@@ -5,12 +5,22 @@ other issues not mentioned here.
 
 JTAG Layer:
     FT2232H (high speed USB) support doesn't need separate configuration
+    New FT2232H JTAG adapters:  Amontec, Olimex, Signalyzer
     New reset_config options for SRST gating the JTAG clock (or not)
     TAP declaration no longer requires ircapture and mask attributes
-    New "post-reset" event handler for TAP-invariant setup code
+    Scan chain setup should be more robust, with better diagnostics
+    New TAP events:
+	"post-reset" for TAP-invariant setup code (TAPs not usable yet)
+	"setup" for use once TAPs are addressable (e.g. with ICEpick)
     Overridable Tcl "init_reset" and "jtag_init" procedures
+    Simple "autoprobe" mechanism to help simplify server setup
+
+Boundary Scan:
+    SVF bugfixes ... parsing fixes, better STATE switch conformance
+    XSVF bugfixes ... be more correct, handle Xilinx tool output
 
 Target Layer:
+    Warn on use of obsolete numeric target IDs
     New commands for use with Cortex-M3 processors:
 	"cortex_m3 disassemble" ... Thumb2 disassembly (UAL format)
 	"cortex_m3 vector_catch" ... traps certain hardware faults
@@ -18,20 +28,28 @@ Target Layer:
     If you're willing to help debug it
 	VERY EARLY Cortex-A8 and ARMv7A support
 	Updated BeagleBoard.org hardware support
+	you may need to explicitly "reset" after connect-to-Beagle
     New commands for use with XScale processors: "xscale vector_table"
+    ARM
+	bugfixes to single-stepping Thumb code
+	ETM: unavailable registers are not listed
+	ETB, ETM: report actual hardware status
     ARM9
 	name change:  "arm9 vector_catch" not "arm9tdmi vector_catch"
     ARM11
 	single stepping support for i.MX31
 	bugfix for missing "arm11" prefix on "arm11 memwrite ..."
-    ETM support
-	Unavailable registers are not listed
+    GDB support
+	gdb_attach command is gone
 
 Flash Layer:
     The lpc2000 driver handles the new NXP LPC1700 (Cortex-M3) chips
-    New lpc2900 driver for NXP LPC2900 chips (ARM968 based)
+    New drivers:
+	lpc2900, for NXP LPC2900 chips (ARM968 based)
+	mx3_nand, for imx31
     New "last" flag for NOR "flash erase_sector" and "flash protect"
     The "nand erase N" command now erases all of bank N
+    Speed up davinci_nand by about 3x
 
 Board, Target, and Interface Configuration Scripts:
     Amontec JTAGkey2 support
@@ -48,10 +66,16 @@ Documentation:
     Notes on target source code changes that may help debugging
 
 Build and Release:
+    Repository moved from SVN at Berlios to GIT at SourceForge
+    Clean builds on (32-bit) Cygwin
+    Clean builds on 64-bit MinGW
 
 For more details about what has changed since the last release,
-see the ChangeLog associated with this source archive.  For older NEWS,
-see the NEWS files associated with each release (i.e. NEWS-<version>).
+see the git repository history.  With gitweb, you can browse that
+in various levels of detail.
+
+For older NEWS, see the NEWS files associated with each release
+(i.e. NEWS-<version>).
 
 For more information about contributing test reports, bug fixes, or new
 features and device support, please read the new Developer Manual (or

configure.in

@@ -1,5 +1,5 @@
 AC_PREREQ(2.60)
-AC_INIT([openocd], [0.3.0-rc0],
+AC_INIT([openocd], [0.3.1],
   [OpenOCD Mailing List <openocd-development@lists.berlios.de>])
 AC_CONFIG_SRCDIR([src/openocd.c])
 
@@ -35,27 +35,78 @@ AC_TYPE_LONG_LONG_INT
 AC_SEARCH_LIBS([ioperm], [ioperm])
 AC_SEARCH_LIBS([dlopen], [dl])
 
-AC_CHECK_HEADERS(arpa/inet.h)
+AC_CHECK_HEADERS(sys/socket.h)
+AC_CHECK_HEADERS(arpa/inet.h, [], [], [dnl
+#include <stdio.h>
+#ifdef STDC_HEADERS
+# include <stdlib.h>
+# include <stddef.h>
+#else
+# ifdef HAVE_STDLIB_H
+#  include <stdlib.h>
+# endif
+#endif
+#ifdef HAVE_SYS_SOCKET_H
+# include <sys/socket.h>
+#endif
+])
 AC_CHECK_HEADERS(elf.h)
 AC_CHECK_HEADERS(dirent.h)
 AC_CHECK_HEADERS(fcntl.h)
-AC_CHECK_HEADERS(ifaddrs.h)
+AC_CHECK_HEADERS(ifaddrs.h, [], [], [dnl
+#include <stdio.h>
+#ifdef STDC_HEADERS
+# include <stdlib.h>
+# include <stddef.h>
+#else
+# ifdef HAVE_STDLIB_H
+#  include <stdlib.h>
+# endif
+#endif
+#ifdef HAVE_SYS_SOCKET_H
+# include <sys/socket.h>
+#endif
+])
 AC_CHECK_HEADERS(malloc.h)
 AC_CHECK_HEADERS(netdb.h)
-AC_CHECK_HEADERS(netinet/in.h)
-AC_CHECK_HEADERS(netinet/tcp.h)
+AC_CHECK_HEADERS([netinet/in.h], [], [], [dnl
+#include <stdio.h>
+#ifdef STDC_HEADERS
+# include <stdlib.h>
+# include <stddef.h>
+#else
+# ifdef HAVE_STDLIB_H
+#  include <stdlib.h>
+# endif
+#endif
+#ifdef HAVE_SYS_SOCKET_H
+# include <sys/socket.h>
+#endif
+])
+AC_CHECK_HEADERS(netinet/tcp.h, [], [], [dnl
+#include <stdio.h>
+#ifdef STDC_HEADERS
+# include <stdlib.h>
+# include <stddef.h>
+#else
+# ifdef HAVE_STDLIB_H
+#  include <stdlib.h>
+# endif
+#endif
+#ifdef HAVE_SYS_SOCKET_H
+# include <sys/socket.h>
+#endif
+])
 AC_CHECK_HEADERS(pthread.h)
 AC_CHECK_HEADERS(strings.h)
 AC_CHECK_HEADERS(sys/ioctl.h)
 AC_CHECK_HEADERS(sys/param.h)
 AC_CHECK_HEADERS(sys/poll.h)
 AC_CHECK_HEADERS(sys/select.h)
-AC_CHECK_HEADERS(sys/socket.h)
 AC_CHECK_HEADERS(sys/stat.h)
 AC_CHECK_HEADERS(sys/time.h)
 AC_CHECK_HEADERS(sys/types.h)
 AC_CHECK_HEADERS(unistd.h)
-
 AC_CHECK_HEADERS([net/if.h], [], [], [dnl
 #include <stdio.h>
 #ifdef STDC_HEADERS

doc/manual/release.txt

@@ -10,7 +10,7 @@ This page provides an introduction to the OpenOCD Release Processes:
   activities for each release cycle.
 - @ref releasehow - Outlines all of the steps for the
   processes used to produce and release the package source archives.
-- @ref releasescript - Introduces the automated @c release.sh script.
+- @ref releasescriptcmds - Introduces the automated @c release.sh script.
 
 @section releasewhy Why Produce Releases?
 
@@ -25,14 +25,21 @@ release, this command will package the tree into several popular archive
 formats: <code>openocd-\<version\>.{tar.gz,tar.bz2,zip}</code>.  If
 produced properly, these files are suitable for release to the public.
 
-When released for users, these archives present several important
-advantages when contrasted to using the git repository:
+When properly versioned and released for users, these archives present
+several important advantages compared to using the source repository
+(including snapshots downloaded from that repository using gitweb):
 
--# They allow others to package and distribute the code.
--# They build easier for developers, because they contain
-   a working configure script that was produced by the Release Manager.
--# They prevent users from trying a random work-in-process revision.
--# They free developers from answering questions about mainline breakage.
+-# They allow others to package and distribute the code using
+   consistent version labels.  Users won't normally need to care
+   whose package they use, just the version of OpenOCD.
+-# They contain a working configure script and makefiles, which
+   were produced as part of creating the archive.
+-# Because they have been formally released by the project, users
+   don't need to try a random work-in-process revision.  Releasing
+   involves spending some time specifically on quality improvments,
+   including bugfixing source code and documentation.
+-# They provide developers with the flexibility needed to address
+   larger issues, which sometimes involves temporary breakage.
 
 Hopefully, this shows several good reasons to produce regular releases,
 but the release processes were developed with some additional design
@@ -45,66 +52,112 @@ following properties:
 -# Allow scheduling and automation of building and publishing milestones.
 
 The current release processes are documented in the following sections.
-They attempt to meet these design goals, but there may improvements
-remaining to be made toward automating the process.
+They attempt to meet these design goals, but improvements may still
+need to be made.
 
-@section releaseversions Release Versions
+@subsection version_labels Version Labels
+
+Users can display the OpenOCD version string in at least two
+ways.  The command line <code>openocd -v</code> invocation
+displays it; as does the Tcl <code>version</code> command.
+
+Labels for released versions look like <em>0.3.0</em>, or
+<em>0.3.0-rc1</em> for a preliminary release.
+Non-released (developer) versions look like <em>0.3.0-dev</em>,
+or <em>0.3.0-rc1-dev</em>.
+In all cases, additional tags may be appended to those base
+release version labels.
+
+The <code>tools/release/version.sh</code> script is used to
+manipulate version IDs found in the source tree.
+
+@subsubsection releaseversions Release Versions and Tags
 
 The OpenOCD version string is composed of three numeric components
 separated by two decimal points: @c x.y.z, where @c x is the @a major
 version number, @c y is the @a minor number, and @c z is the @a micro.
-
-For a <i>bug-fix</i> release, the micro version number will be non-zero
+For any <em>bug-fix</em> release, the micro version number will be non-zero
 (<code>z > 0</code>).  For a <i>minor release</i>, the micro version
 number will be zero (<code>z = 0</code>).  For a <i>major releases</i>,
 the minor version will @a also be zero (<code>y = 0, z = 0</code>).
 
-@subsection releaseversiontags Version Tags
+After these required numeric components, release version strings
+may contain tags such as as <em>-rc1</em> or <em>-rc2</em>.
+These 'rc' tags indicate "release candidate" versions of the package.
+Like the major/minor/micro numbers, these tags will be manipulated
+by the automated release process.
 
-After these required numeric components, the version string may contain
-one or more <i>version tags</i>, such as '-rc1' or '-dev'.
+The release process includes version number manipulations to the tree
+being released, ensuring that all numbers are incremented (or rolled
+over) at the right time and in the proper locations of the repository.
+One of those manipulations creates a repository tag matching that
+release's version label.
 
-Mainline and all branches should have the tag '-dev' in
-their version number.  This tag helps developers identify reports
-created from the git repository, and it can be detected and
-manipulated by the release script.  Specifically, this tag will be
-removed and re-added during the release process; it should never be
-manipulated by developers in submitted patches.
-
-The 'rc' tags indicate a "release candidate" version of the package.
-This tag will also be manipulated by the automated release process.
-
-Additional tags may be used as necessary.
-
-@subsection releaseversionsdist Packager Versions
+@subsubsection releaseversionsdist Packager Versions
 
 Distributors of patched versions of OpenOCD are encouraged to extend the
 version string with a unique version tag when producing external
 releases, as this helps to identify your particular distribution series.
+Knowing that a release has such patches can be essential to tracking
+down and fixing bugs.
 
-For example, the following command will add a 'foo1' tag to the
-configure.in script of a local copy of the source tree:
+Packager version tags should always be suffixes to the version
+code from the OpenOCD project, signifying modifications to the
+original code base.  Each packager release should have a unique
+version.
+
+For example, the following command will add a 'foo' tag to the
+configure.in script of a local copy of the source tree, giving
+a version label like <em>0.3.0-foo</em>:
 
 @code
-tools/release.sh version bump tag foo
+tools/release/version.sh version tag add foo
 @endcode
 
 This command will modify the configure.in script in your working copy
 only.  After running the @c bootstrap sequence, the tree can be patched
-and used to produce your own derived versions.  The same command can be
-used each time the derived package is released, incrementing the tag's
+and used to produce your own derived versions.  You might check that
+change into a private branch of your git tree, along with the other
+patches you are providing.
+
+You can also "bump" those tags (so "foo1" becomes "foo2" etc)
+each time a derived package is released, incrementing the tag's
 version to facilitate tracking the changes you have distributed.
 
-@subsection releaseversionhow Version Processes
+@code
+tools/release/version.sh version bump tag foo
+@endcode
 
-The release process includes version number manipulations to the tree
-being released, ensuring that all numbers are incremented at the right
-time and in the proper locations of the repository.
+Of course, any patches in your branches must be provided to
+your customers, and be in conformance with the GPL.  In most
+cases you should also work to merge your improvements to the
+mainline tree.
 
-The version numbers for any branch should increase monotonically
-to the next successive integer, except when reset to zero
-during major or minor releases.  The community should decide when
-major and minor milestones will be released.
+@subsubsection version_tags Development Versions and Tags
+
+Everything except formal releases should have the tag <em>-dev</em>
+in their version number.  This helps developers identify reports
+created from non-release versions, and it can be detected and
+manipulated by the release script.  Specifically, this tag will be
+removed and re-added during the release process; it should never be
+manipulated by developers in submitted patches.
+
+Versions built from developer trees may have additional tags.
+Trees built from git snapshots have <em>snapshot</em> tags.
+When built from a "live" git tree, tags specify
+specific git revisions:
+
+0.3.0-rc1-dev-00015-gf37c9b8-dirty
+
+indicates a development tree based on git revison f37c9b8
+(a truncated version of a SHA1 hash) with some non-git
+patches applied (the <em>dirty</em> tag).  This information
+can be useful when tracking down bugs.
+(Note that at this writing, the tags do not directly
+correspond to <code>git describe</code> output.  The
+hash ID can be used with <code>git show</code>, but
+the relevant repository tag isn't <em>0.3.0-rc1-dev</em>;
+this might change in the future.)
 
 @section releasewho Release Manager
 
@@ -132,14 +185,23 @@ the changes to the package version, though the release tools should
 manage the tasks of adding or removing any required development branch
 tags and incrementing the version.
 
+These responsibilities matter most towards the end of the release
+cycle, when the RM creates the first RC and all contributors enter
+a quality-improvement mode.  The RM works with other contributors
+to make sure everyone knows what kinds of fixes should merge, the
+status of major issues, and the release timetable.
+
+In particular, the RM has the final decision on whether a given
+bug should block the release.
+
 @section releasewhen Release Schedule
 
 The OpenOCD release process must be carried out on a periodic basis, so
 the project can realize the benefits presented in answer to the question,
 @ref releasewhy.
 
-Starting with the 0.2.0 release, the OpenOCD project should produce a
-new minor release every month or two, with a major release once a year.
+Starting with the 0.2.0 release, the OpenOCD project expects to produce
+new releases every few months.
 Bug fix releases could be provided more frequently.  These release
 schedule goals may be adjusted in the future, after the project
 maintainers and distributors receive feedback and experience.
@@ -155,16 +217,26 @@ beginning of the development cycle through the delivery of the new
 release.  This section presents guidelines for scheduling key points
 where the community must be informed of changing conditions.
 
-If T is the time of the next release, then the following schedule
-might describe some of the key milestones of the new release cycle:
+If Tn is the time of release n, then the following schedule
+might describe some key T0-to-T1 release cycle milestones.
 
-- T minus one month: start of new development cycle
-- T minus two weeks: announce pending mainline closure to new work
-- T minus one week: close mainline to new work, begin testing phase
-- T minus two days: call for final bug fixes
-- T minus one day: produce -rc packages and distribute to testers
-- T minus one hour: produce final packages and post on-line
-- T minus zero: Announce the release to our mailing list and the world.
+- T0 ... End of T0 release cycle. T1 cycle starts, with merge
+  window opening.  Developers begin to merge queued work.
+- <em>... several weeks of merge window ...</em>
+- RC1 ... Close mainline to new work.  Produce RC1
+  release, begin testing phase; developers are in "bugfix mode",
+  all other work is queued; send out planned endgame schedule.
+- RC2 ... Produce RC2 and send schedule update to
+  mailing list, listing priorities for remaining fixes
+- <em>... more RC milestones, until ready ...</em>
+- T1: End of T1 release cycle. T2 cycle starts, with merge
+  window opening.  Developers begin to merge queued work.
+
+Note that until it happens, any date for T1 is just a goal.
+Critical bugs prevent releases from happening.  We are just
+beginning to use this window-plus-RCs process, so the lengths
+of the merge windows versus the RC phase is subject to change.
+Most projects have RC phases of a month or more.
 
 Some additional supplemental communication will be desirable.  The above
 list omits the step-by-step instructions to daily release management.
@@ -176,29 +248,21 @@ The next section explains why the OpenOCD project allows significant
 flexibility in the part of the development that precedes the release
 process.
 
-@note The OpenOCD project does not presently produce -rc packages.  As
-such, the step suggested in the list above should be read as trying to
-stimulate others to test the project build and packaging on as many
-platforms as possible.  This proposition will be palatable once release
-management tools have been committed to the tree.
-
 @subsection releasewhenflex Schedule Flexibility
 
 The Release Manager should attempt to follow the guidelines in this
 document, but the process of scheduling each release milestone should be
-community driven at the start.  By the end, missing features that were
-scheduled for a release must be dropped by the Release Manager, rather
-than allowing the release cycle to be delayed while waiting for them.
+community driven at the start.  Features that don't complete before
+the merge window closes can be held (perhaps in some branch) until
+the next merge window opens, rather than delaying the release cycle.
 
-Despite any assurances this schedule may appear to give, the Release
+The Release
 Manager cannot schedule the work that will be done on the project,
 when it will be submitted, reviewed, and deemed suitable to be committed.
-In this way, the RM cannot act as a priest in a cathedral; OpenOCD uses
+That is, the RM cannot act as a priest in a cathedral; OpenOCD uses
 the bazaar development model.  The release schedule must adapt
-continuously in response to changes in the rate of churn.
-
-In particular, the suggested period of "one or two month" reflects some
-expectation of a fairly high rate of development.  Fewer releases may be
+continuously in response to changes in the rate of work.
+Fewer releases may be
 required if developers contribute less patches, and more releases may be
 desirable if the project continues to grow and experience high rates of
 community contribution.  During each cycle, the RM should be tracking
@@ -206,49 +270,52 @@ the situation and gathering feedback from the community.
 
 @section releasehow Release Process: Step-by-Step
 
-The release process may require a few iterations to work out any bugs.
-Even with the release script, some steps require clear user intervention
--- and not only by the Release Manager.
+The release process is not final; it may need more iterations
+to work out bugs.
+While there are release scripts, key steps require community
+support; the Release Manager isn't the only participant.
 
 The following steps should be followed to produce each release:
 
--# Produce final manual patches to mainline (or release branch):
+-# Produce final patches to mainline (or a release branch).  Nobody
+   except the RM should be committing anything.
   -# Finalize @c NEWS file to describe the changes in the release
-    - This file is Used to automatically post "blurbs" about the project.
+    - This file is used to automatically post "blurbs" about the project.
     - This material should be produced during the development cycle.
     - Add a new item for each @c NEWS-worthy contribution, when committed.
   -# Bump library version if our API changed (not yet required)
--# Produce and tag the final revision in the git repository:
-  - Update and commit the final package version in @c configure.in :
-  -# Remove @c -dev tag.
-  -# Remove @c -rc tag, if producing the final release from an -rc series.
-  - Tags must be named consistently:
-@verbatim
-@endverbatim
-  - Tag the final commit with a consistent GIT tag name and message:
+  -# Update and commit the final package version in @c configure.in:
+     <code>tools/release/version.sh</code> may help ensure the versions
+     are named consistently:
+    -# Remove @c -dev tag.
+    -# Update the @c -rc tag:
+      - If producing the final release from an -rc series, remove it
+      - If producing the first RC in a series, add rc1
+      - If producing the next RC in a series, bump the rc number
+    -# Commit that version change.
+  -# Create a git tag for the final commit, with a tag name matching
+     the version string in <code>configure.in</code> (including <em>-rcN</em>
+     where relevant):
 @verbatim
 PACKAGE_VERSION="x.y.z"
 PACKAGE_TAG="v${PACKAGE_VERSION}"
 git tag -m "The openocd-${PACKAGE_VERSION} release." "${PACKAGE_TAG}"
 @endverbatim
--# Prepare to resume normal development on the branch:
-  - Restore @c -dev and -@c -rc0 version tags.
-  - To start a new major (or minor) release cycle on the @c master branch:
-    - Bump major (or minor) package version, zeroing sub-components.
-    - Add -rc0 version tag:
-      - This insures casual releases from GIT always increase monotonically.
-      - For example, a major increment after releasing 1.2.3 starts 2.0.0-rc0-dev.
-    - Archive @c NEWS file as "<code>doc/news/NEWS-${PACKAGE_VERSION}</code>".
-    - Create a new @c NEWS file for the next release
-  - To start a bug-fix release on a non-master branch:
-    -# Bump bug-fix version.
-  - To start another release candidate on a major or minor branch:
-    -# Bump rc tag.
+-# Prepare to resume normal development on mainline (major or minor release)
+  - Update the version label
+     - Restore @c -dev version tag.
+     - For a new minor release cycle, increment the release's minor number
+     - For a new major release cycle, increment the release's major number
+       and zero its minor number
+  - Archive @c NEWS file as "<code>doc/news/NEWS-${PACKAGE_VERSION}</code>".
+  - Create a new @c NEWS file for the next release
+  - Commit those changes, and push the commit and the release tag
+    to mainline.
 -# Produce the package source archives:
-  -# Start with a clean working copy, used for producing releases only.
+  -# <em>Start with a new clone of the source tree</em>, with the
+     release's tag.  This is used only for producing these packages.
   -# Checkout the appropriate tag:
-<code>git checkout $(git tag ) "${PACKAGE_VERSION}"</code>
-  -# Produce a ChangeLog for the release (using @c git2cl).
+<code>git checkout "${PACKAGE_VERSION}"</code>
   -# @c bootstrap, @c configure, and @c make the package.
   -# Run <code>make distcheck</code> to produce the distribution archives.
   -# Run <code>make maintainer-clean</code> verify the repository is empty.
@@ -257,8 +324,7 @@ git tag -m "The openocd-${PACKAGE_VERSION} release." "${PACKAGE_TAG}"
   - Allow users to access the documentation for each of our releases.
   - Place static copies of the following files on the project website:
     - @c NEWS: to provide a blurb for each release
-    - @c ChangeLog: to show exactly what has been changed
-    - User Guide, Developer Manual: to allow easy on-line viewing
+    - User's Guide, Developer Manual: to allow easy on-line viewing
 -# Upload packages and post announcements of their availability:
   -# Release packages into files section of project sites:
     - SF.net:
@@ -271,7 +337,7 @@ git tag -m "The openocd-${PACKAGE_VERSION} release." "${PACKAGE_TAG}"
        - .zip: Windows
     - Berlios:
      -# Create the new release for the new version.
-     -# Provide @c NEWS and ChangeLog files, as requested.
+     -# Provide @c NEWS file, as requested.
      -# Upload files via FTP to ftp://ftp.berlios.de/incoming/
      -# Edit descriptions for each file.
      -# Click button to send E-mail Release Notice.
@@ -279,24 +345,23 @@ git tag -m "The openocd-${PACKAGE_VERSION} release." "${PACKAGE_TAG}"
   -# Announce updates on freshmeat.net and other trackers.
   -# Submit big updates to news feeds (e.g. Digg, Reddit, etc.).
 
-@section releasescript The Release Script
-
-Many of the processes described in the last section are no longer
-entrusted to humans.  Instead, the @c release.sh script provides
-automation of the mechanical steps.
-
-Presently, the @c release.sh script automates steps 2 through 4,
-allowing the Release Manager from perform these tasks in easy steps.
-
-The following task still need to be automated:
-
-- Step 5: produce documentation for website using released source archive.
-- Step 6(a): package archive upload process.
-- Step 6(b): package announcement e-mail process.
-- Step 6(c): post files and announce them using releaseforge.
+To start a bug-fix release branch:
+-# Create a new branch, starting from a major or
+   minor release tag
+-# Restore @c -dev version tag.
+-# Bump micro version number in configure.in
+-# Backport bugfix patches from mainline into that branch.
+   (Always be sure mainline has the fix first, so it's hard
+   to just lose a bugfix.)
+-# Commit and push those patches.
+-# When desired, release as above ... except note that the next
+   release of a bugfix branch is never a new major or minor release
 
 @subsection releasescriptcmds Release Script Commands
 
+The @c release.sh script automates some of the steps involved
+in making releases, simplifying the Release Manager's work.
+
 The release script can be used for two tasks:
 - Creating releases and starting a new release cycle:
 @code

doc/openocd.texi

@@ -725,6 +725,13 @@ than the target config file, as in the AT91SAM7X256 example.
 That's because there is no external memory (flash, DDR RAM), and
 the board differences are encapsulated by application code.
 
+@item Maybe you don't know yet what your board looks like to JTAG.
+Once you know the @file{interface.cfg} file to use, you may
+need help from OpenOCD to discover what's on the board.
+Once you find the TAPs, you can just search for appropriate
+configuration files ... or write your own, from the bottom up.
+@xref{Autoprobing}.
+
 @item You can often reuse some standard config files but
 need to write a few new ones, probably a @file{board.cfg} file.
 You will be using commands described later in this User's Guide,
@@ -1533,6 +1540,8 @@ may access or activate TAPs.
 After it leaves this stage, configuration commands may no
 longer be issued.
 
+@section Entering the Run Stage
+
 The first thing OpenOCD does after leaving the configuration
 stage is to verify that it can talk to the scan chain
 (list of TAPs) which has been configured.
@@ -1545,10 +1554,18 @@ Common errors include using an initial JTAG speed that's too
 fast, and not providing the right IDCODE values for the TAPs
 on the scan chain.
 
+Once OpenOCD has entered the run stage, a number of commands
+become available.
+A number of these relate to the debug targets you may have declared.
+For example, the @command{mww} command will not be available until
+a target has been successfuly instantiated.
+If you want to use those commands, you may need to force
+entry to the run stage.
+
 @deffn {Config Command} init
 This command terminates the configuration stage and
-enters the normal command mode. This can be useful to add commands to
-the startup scripts and commands such as resetting the target,
+enters the run stage.  This helps when you need to have
+the startup scripts manage tasks such as resetting the target,
 programming flash, etc. To reset the CPU upon startup, add "init" and
 "reset" at the end of the config script or at the end of the OpenOCD
 command line using the @option{-c} command line switch.
@@ -2791,6 +2808,75 @@ for querying the state of the JTAG taps.
 @end quotation
 @end deffn
 
+@anchor{Autoprobing}
+@section Autoprobing
+@cindex autoprobe
+@cindex JTAG autoprobe
+
+TAP configuration is the first thing that needs to be done
+after interface and reset configuration.  Sometimes it's
+hard finding out what TAPs exist, or how they are identified.
+Vendor documentation is not always easy to find and use.
+
+To help you get past such problems, OpenOCD has a limited
+@emph{autoprobing} ability to look at the scan chain, doing
+a @dfn{blind interrogation} and then reporting the TAPs it finds.
+To use this mechanism, start the OpenOCD server with only data
+that configures your JTAG interface, and arranges to come up
+with a slow clock (many devices don't support fast JTAG clocks
+right when they come out of reset).
+
+For example, your @file{openocd.cfg} file might have:
+
+@example
+source [find interface/olimex-arm-usb-tiny-h.cfg]
+reset_config trst_and_srst
+jtag_rclk 8
+@end example
+
+When you start the server without any TAPs configured, it will
+attempt to autoconfigure the TAPs.  There are two parts to this:
+
+@enumerate
+@item @emph{TAP discovery} ...
+After a JTAG reset (sometimes a system reset may be needed too),
+each TAP's data registers will hold the contents of either the
+IDCODE or BYPASS register.
+If JTAG communication is working, OpenOCD will see each TAP,
+and report what @option{-expected-id} to use with it.
+@item @emph{IR Length discovery} ...
+Unfortunately JTAG does not provide a reliable way to find out
+the value of the @option{-irlen} parameter to use with a TAP
+that is discovered.
+If OpenOCD can discover the length of a TAP's instruction
+register, it will report it.
+Otherwise you may need to consult vendor documentation, such
+as chip data sheets or BSDL files.
+@end enumerate
+
+In many cases your board will have a simple scan chain with just
+a single device.  Here's what OpenOCD reported with one board
+that's a bit more complex:
+
+@example
+clock speed 8 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
+@end example
+
+Given that information, you should be able to either find some existing
+config files to use, or create your own.  If you create your own, you
+would configure from the bottom up:  first a @file{target.cfg} file
+with these TAPs, any targets associated with them, and any on-chip
+resources; then a @file{board.cfg} with off-chip resources, clocking,
+and so forth.
+
 @node CPU Configuration
 @chapter CPU Configuration
 @cindex GDB target
@@ -2923,15 +3009,15 @@ At this writing, the supported CPU types and variants are:
 
 @itemize @bullet
 @item @code{arm11} -- this is a generation of ARMv6 cores
-@item @code{arm720t} -- this is an ARMv4 core
+@item @code{arm720t} -- this is an ARMv4 core with an MMU
 @item @code{arm7tdmi} -- this is an ARMv4 core
-@item @code{arm920t} -- this is an ARMv5 core
-@item @code{arm926ejs} -- this is an ARMv5 core
+@item @code{arm920t} -- this is an ARMv5 core with an MMU
+@item @code{arm926ejs} -- this is an ARMv5 core with an MMU
 @item @code{arm966e} -- this is an ARMv5 core
 @item @code{arm9tdmi} -- this is an ARMv4 core
 @item @code{avr} -- implements Atmel's 8-bit AVR instruction set.
 (Support for this is preliminary and incomplete.)
-@item @code{cortex_a8} -- this is an ARMv7 core
+@item @code{cortex_a8} -- this is an ARMv7 core with an MMU
 @item @code{cortex_m3} -- this is an ARMv7 core, supporting only the
 compact Thumb2 instruction set.  It supports one variant:
 @itemize @minus
@@ -2941,6 +3027,7 @@ SRST, to avoid a issue with clearing the debug registers.
 This is fixed in Fury Rev B, DustDevil Rev B, Tempest; these revisions will
 be detected and the normal reset behaviour used.
 @end itemize
+@item @code{dragonite} -- resembles arm966e
 @item @code{fa526} -- resembles arm920 (w/o Thumb)
 @item @code{feroceon} -- resembles arm926
 @item @code{mips_m4k} -- a MIPS core.  This supports one variant:

src/helper/bin2char.c

@@ -21,6 +21,10 @@
 #include <stdio.h>
 #include <stdlib.h>
 
+#ifdef _WIN32
+ #include <fcntl.h>
+#endif
+
 int main(int argc, char **argv)
 {
 	int c;
@@ -34,6 +38,12 @@ int main(int argc, char **argv)
 		exit(1);
 	}
 
+#ifdef _WIN32
+	/* for win32 set stdin/stdout to binary mode */
+	_setmode(_fileno(stdin), _O_BINARY);
+	_setmode(_fileno(stdout), _O_BINARY);
+#endif
+
 	n = 0;
 	name = argv[1];
 	fprintf(stdout, "/* autogenerated from %s */\n", argv[0]);

src/jtag/ft2232.c

@@ -71,6 +71,17 @@
 /* this speed value tells that RTCK is requested */
 #define RTCK_SPEED -1
 
+/*
+ * On my Athlon XP 1900+ EHCI host with FT2232H JTAG dongle I get read timeout
+ * errors with a retry count of 100. Increasing it solves the problem for me.
+ *	- Dimitar
+ *
+ * FIXME There's likely an issue with the usb_read_timeout from libftdi.
+ * Fix that (libusb? kernel? libftdi? here?) and restore the retry count
+ * to something sane.
+ */
+#define LIBFTDI_READ_RETRY_COUNT		2000
+
 #ifndef BUILD_FT2232_HIGHSPEED
  #if BUILD_FT2232_FTD2XX == 1
 	enum { FT_DEVICE_2232H = 6, FT_DEVICE_4232H };
@@ -400,7 +411,7 @@ static int ft2232_read(uint8_t* buf, uint32_t size, uint32_t* bytes_read)
 
 #elif BUILD_FT2232_LIBFTDI == 1
 	int retval;
-	int timeout = 100;
+	int timeout = LIBFTDI_READ_RETRY_COUNT;
 	*bytes_read = 0;
 
 	while ((*bytes_read < size) && timeout--)
@@ -418,9 +429,10 @@ static int ft2232_read(uint8_t* buf, uint32_t size, uint32_t* bytes_read)
 
 	if (*bytes_read < size)
 	{
-		LOG_ERROR("couldn't read the requested number of bytes from FT2232 device (%i < %i)",
-			  (unsigned int)(*bytes_read),
-			  (unsigned int)size);
+		LOG_ERROR("couldn't read enough bytes from "
+				"FT2232 device (%i < %i)",
+				(unsigned)*bytes_read,
+				(unsigned)size);
 		return ERROR_JTAG_DEVICE_ERROR;
 	}
 
@@ -679,7 +691,8 @@ static int ft2232_send_and_recv(jtag_command_t* first, jtag_command_t* last)
 
 	if (ft2232_expect_read)
 	{
-		int timeout = 100;
+		/* FIXME this "timeout" is never changed ... */
+		int timeout = LIBFTDI_READ_RETRY_COUNT;
 		ft2232_buffer_size = 0;
 
 #ifdef _DEBUG_USB_IO_
@@ -709,16 +722,21 @@ static int ft2232_send_and_recv(jtag_command_t* first, jtag_command_t* last)
 
 		if (ft2232_expect_read != ft2232_buffer_size)
 		{
-			LOG_ERROR("ft2232_expect_read (%i) != ft2232_buffer_size (%i) (%i retries)", ft2232_expect_read,
+			LOG_ERROR("ft2232_expect_read (%i) != "
+					"ft2232_buffer_size (%i) "
+					"(%i retries)",
+					ft2232_expect_read,
 					ft2232_buffer_size,
-					100 - timeout);
+					LIBFTDI_READ_RETRY_COUNT - timeout);
 			ft2232_debug_dump_buffer();
 
 			exit(-1);
 		}
 
 #ifdef _DEBUG_USB_COMMS_
-		LOG_DEBUG("read buffer (%i retries): %i bytes", 100 - timeout, ft2232_buffer_size);
+		LOG_DEBUG("read buffer (%i retries): %i bytes",
+				LIBFTDI_READ_RETRY_COUNT - timeout,
+				ft2232_buffer_size);
 		ft2232_debug_dump_buffer();
 #endif
 	}

src/svf/svf.c

@@ -685,9 +685,9 @@ static int svf_copy_hexstring_to_binary(char *str, uint8_t **bin, int orig_bit_l
 		str_len--;
 
 	// check valid
-	if (str_len > 0 || (ch & ~((1 << (4 - (bit_len % 4))) - 1)) != 0)
+	if (str_len > 0 || (ch & ~((2 << ((bit_len - 1) % 4)) - 1)) != 0)
 	{
-		LOG_ERROR("value execede length");
+		LOG_ERROR("value execeeds length");
 		return ERROR_FAIL;
 	}
 

src/target/arm7_9_common.c

@@ -2821,8 +2821,11 @@ int arm7_9_checksum_memory(struct target_s *target, uint32_t address, uint32_t c
 	buf_set_u32(reg_params[0].value, 0, 32, address);
 	buf_set_u32(reg_params[1].value, 0, 32, count);
 
+	/* 20 second timeout/megabyte */
+	int timeout = 20000 * (1 + (count / (1024*1024)));
+
 	if ((retval = target_run_algorithm(target, 0, NULL, 2, reg_params,
-		crc_algorithm->address, crc_algorithm->address + (sizeof(arm7_9_crc_code) - 8), 20000, &armv4_5_info)) != ERROR_OK)
+		crc_algorithm->address, crc_algorithm->address + (sizeof(arm7_9_crc_code) - 8), timeout, &armv4_5_info)) != ERROR_OK)
 	{
 		LOG_ERROR("error executing arm7_9 crc algorithm");
 		destroy_reg_param(&reg_params[0]);

src/target/arm920t.c

@@ -555,26 +555,25 @@ int arm920t_write_memory(struct target_s *target, uint32_t address, uint32_t siz
 	if ((retval = arm7_9_write_memory(target, address, size, count, buffer)) != ERROR_OK)
 		return retval;
 
+	/* This fn is used to write breakpoints, so we need to make sure that the
+	 * datacache is flushed and the instruction cache is invalidated */
 	if (((size == 4) || (size == 2)) && (count == 1))
 	{
 		if (arm920t->armv4_5_mmu.armv4_5_cache.d_u_cache_enabled)
 		{
-			LOG_DEBUG("D-Cache enabled, writing through to main memory");
-			uint32_t pa, cb, ap;
-			int type, domain;
-
-			pa = armv4_5_mmu_translate_va(target, &arm920t->armv4_5_mmu, address, &type, &cb, &domain, &ap);
-			if (type == -1)
-				return ERROR_OK;
-			/* cacheable & bufferable means write-back region */
-			if (cb == 3)
-				armv4_5_mmu_write_physical(target, &arm920t->armv4_5_mmu, pa, size, count, buffer);
+			LOG_DEBUG("D-Cache enabled, flush and invalidate cache line");
+			/* MCR p15,0,Rd,c7,c10,2 */
+			retval = arm920t_write_cp15_interpreted(target, 0xee070f5e, 0x0, address);
+			if (retval != ERROR_OK)
+				return retval;
 		}
 
 		if (arm920t->armv4_5_mmu.armv4_5_cache.i_cache_enabled)
 		{
 			LOG_DEBUG("I-Cache enabled, invalidating affected I-Cache line");
-			arm920t_write_cp15_interpreted(target, 0xee070f35, 0x0, address);
+			retval = arm920t_write_cp15_interpreted(target, 0xee070f35, 0x0, address);
+			if (retval != ERROR_OK)
+				return retval;
 		}
 	}
 

src/target/arm926ejs.c

@@ -906,7 +906,9 @@ static int arm926ejs_virt2phys(struct target_s *target, uint32_t virtual, uint32
 static int arm926ejs_mmu(struct target_s *target, int *enabled)
 {
 	armv4_5_common_t *armv4_5 = target->arch_info;
-	arm926ejs_common_t *arm926ejs = armv4_5->arch_info;
+	arm7_9_common_t *arm7_9 = armv4_5->arch_info;
+	arm9tdmi_common_t *arm9tdmi = arm7_9->arch_info;
+	arm926ejs_common_t *arm926ejs = arm9tdmi->arch_info;
 
 	if (target->state != TARGET_HALTED)
 	{

src/target/arm9tdmi.c

@@ -1042,14 +1042,11 @@ static int handle_arm9tdmi_catch_vectors_command(
 		embeddedice_store_reg(vector_catch);
 	}
 
-	/* output current settings (skip RESERVED vector) */
-	for (i = 0; i < 8; i++)
-	{
-		if (i != 5)
-		{
-			command_print(cmd_ctx, "%s: %s", arm9tdmi_vectors[i].name,
-				(vector_catch_value & (1 << i)) ? "catch" : "don't catch");
-		}
+	/* output current settings */
+	for (i = 0; arm9tdmi_vectors[i].name; i++) {
+		command_print(cmd_ctx, "%s: %s", arm9tdmi_vectors[i].name,
+			(vector_catch_value & arm9tdmi_vectors[i].value)
+				? "catch" : "don't catch");
 	}
 
 	return ERROR_OK;

src/target/target.c

@@ -1040,18 +1040,35 @@ int target_alloc_working_area(struct target_s *target, uint32_t size, working_ar
 	{
 		int retval;
 		int enabled;
+
 		retval = target->type->mmu(target, &enabled);
 		if (retval != ERROR_OK)
 		{
 			return retval;
 		}
-		if (enabled)
-		{
-			target->working_area = target->working_area_virt;
-		}
-		else
-		{
-			target->working_area = target->working_area_phys;
+
+		if (!enabled) {
+			if (target->working_area_phys_spec) {
+				LOG_DEBUG("MMU disabled, using physical "
+					"address for working memory 0x%08x",
+					(unsigned)target->working_area_phys);
+				target->working_area = target->working_area_phys;
+			} else {
+				LOG_ERROR("No working memory available. "
+					"Specify -work-area-phys to target.");
+				return ERROR_TARGET_RESOURCE_NOT_AVAILABLE;
+			}
+		} else {
+			if (target->working_area_virt_spec) {
+				LOG_DEBUG("MMU enabled, using virtual "
+					"address for working memory 0x%08x",
+					(unsigned)target->working_area_virt);
+				target->working_area = target->working_area_virt;
+			} else {
+				LOG_ERROR("No working memory available. "
+					"Specify -work-area-virt to target.");
+				return ERROR_TARGET_RESOURCE_NOT_AVAILABLE;
+			}
 		}
 	}
 
@@ -1080,8 +1097,6 @@ int target_alloc_working_area(struct target_s *target, uint32_t size, working_ar
 		uint32_t first_free = target->working_area;
 		uint32_t free_size = target->working_area_size;
 
-		LOG_DEBUG("allocating new working area");
-
 		c = target->working_areas;
 		while (c)
 		{
@@ -1098,6 +1113,8 @@ int target_alloc_working_area(struct target_s *target, uint32_t size, working_ar
 			return ERROR_TARGET_RESOURCE_NOT_AVAILABLE;
 		}
 
+		LOG_DEBUG("allocated new working area at address 0x%08x", (unsigned)first_free);
+
 		new_wa = malloc(sizeof(working_area_t));
 		new_wa->next = NULL;
 		new_wa->size = size;
@@ -3763,6 +3780,7 @@ static int target_configure(Jim_GetOptInfo *goi, target_t *target)
 					return e;
 				}
 				target->working_area_virt = w;
+				target->working_area_virt_spec = true;
 			} else {
 				if (goi->argc != 0) {
 					goto no_params;
@@ -3780,6 +3798,7 @@ static int target_configure(Jim_GetOptInfo *goi, target_t *target)
 					return e;
 				}
 				target->working_area_phys = w;
+				target->working_area_phys_spec = true;
 			} else {
 				if (goi->argc != 0) {
 					goto no_params;

src/target/target.h

@@ -128,9 +128,11 @@ typedef struct target_s
 	int reset_halt;						/* attempt resetting the CPU into the halted mode? */
 	uint32_t working_area;					/* working area (initialized RAM). Evaluated
 										 * upon first allocation from virtual/physical address. */
-	uint32_t working_area_virt;				/* virtual address */
-	uint32_t working_area_phys;				/* physical address */
-	uint32_t working_area_size;				/* size in bytes */
+	bool working_area_virt_spec;		/* virtual address specified? */
+	uint32_t working_area_virt;			/* virtual address */
+	bool working_area_phys_spec;		/* virtual address specified? */
+	uint32_t working_area_phys;			/* physical address */
+	uint32_t working_area_size;			/* size in bytes */
 	uint32_t backup_working_area;			/* whether the content of the working area has to be preserved */
 	struct working_area_s *working_areas;/* list of allocated working areas */
 	enum target_debug_reason debug_reason;/* reason why the target entered debug state */

src/xsvf/xsvf.c

@@ -211,9 +211,16 @@ static int handle_xsvf_command(struct command_context_s *cmd_ctx, char *cmd, cha
 	int		tdo_mismatch = 0;
 	int		result;
 	int		verbose = 1;
-	char*	filename;
+	char		*filename;
 
-	int		runtest_requires_tck = 0;	/* a flag telling whether to clock TCK during waits, or simply sleep, controled by virt2 */
+	bool		collecting_path = false;
+	tap_state_t	path[XSTATE_MAX_PATH];
+	unsigned	pathlen = 0;
+
+	/* a flag telling whether to clock TCK during waits,
+	 * or simply sleep, controled by virt2
+	 */
+	int		runtest_requires_tck = 0;
 
 
 	/* use NULL to indicate a "plain" xsvf file which accounts for
@@ -263,9 +270,88 @@ static int handle_xsvf_command(struct command_context_s *cmd_ctx, char *cmd, cha
 
 	while (read(xsvf_fd, &opcode, 1) > 0)
 	{
-		/* record the position of the just read opcode within the file */
+		/* record the position of this opcode within the file */
 		file_offset = lseek(xsvf_fd, 0, SEEK_CUR) - 1;
 
+		/* maybe collect another state for a pathmove();
+		 * or terminate a path.
+		 */
+		if (collecting_path) {
+			tap_state_t	mystate;
+			uint8_t		uc;
+
+			switch (opcode) {
+			case XCOMMENT:
+				/* ignore/show comments between XSTATE ops */
+				break;
+			case XSTATE:
+				/* try to collect another transition */
+				if (pathlen == XSTATE_MAX_PATH) {
+					LOG_ERROR("XSVF: path too long");
+					do_abort = 1;
+					break;
+				}
+
+				if (read(xsvf_fd, &uc, 1) < 0)
+				{
+					do_abort = 1;
+					break;
+				}
+
+				mystate = xsvf_to_tap(uc);
+				path[pathlen++] = mystate;
+
+				LOG_DEBUG("XSTATE 0x%02X %s", uc,
+						tap_state_name(mystate));
+
+				/* If path is incomplete, collect more */
+				if (!svf_tap_state_is_stable(mystate))
+					continue;
+
+				/* Else execute the path transitions we've
+				 * collected so far.
+				 *
+				 * NOTE:  Punting on the saved path is not
+				 * strictly correct, but we must to do this
+				 * unless jtag_add_pathmove() stops rejecting
+				 * paths containing RESET.  This is probably
+				 * harmless, since there aren't many options
+				 * for going from a stable state to reset;
+				 * at the worst, we may issue extra clocks
+				 * once we get to RESET.
+				 */
+				if (mystate == TAP_RESET) {
+					LOG_WARNING("XSVF: dodgey RESET");
+					path[0] = mystate;
+				}
+
+				/* FALL THROUGH */
+			default:
+				/* Execute the path we collected
+				 *
+				 * NOTE: OpenOCD requires something that XSVF
+				 * doesn't:  the last TAP state in the path
+				 * must be stable.  In practice, tools that
+				 * create XSVF seem to follow that rule too.
+				 */
+				collecting_path = false;
+
+				if (path[0] == TAP_RESET)
+					jtag_add_tlr();
+				else
+					jtag_add_pathmove(pathlen, path);
+
+				result = jtag_get_error();
+				if (result != ERROR_OK) {
+					LOG_ERROR("XSVF: pathmove error %d",
+							result);
+					do_abort = 1;
+					break;
+				}
+				continue;
+			}
+		}
+
 		switch (opcode)
 		{
 		case XCOMPLETE:
@@ -500,6 +586,12 @@ static int handle_xsvf_command(struct command_context_s *cmd_ctx, char *cmd, cha
 
 				LOG_DEBUG("XSTATE 0x%02X %s", uc, tap_state_name(mystate));
 
+				if (mystate == TAP_INVALID) {
+					LOG_ERROR("XSVF: bad XSTATE %02x", uc);
+					do_abort = 1;
+					break;
+				}
+
 				/* NOTE: the current state is SVF-stable! */
 
 				/* no change == NOP */
@@ -518,19 +610,12 @@ static int handle_xsvf_command(struct command_context_s *cmd_ctx, char *cmd, cha
 
 				/*
 				 * A sequence of XSTATE transitions, each TAP
-				 * state adjacent to the previous one.
-				 *
-				 * NOTE: OpenOCD requires something that XSVF
-				 * doesn't:  the last TAP state in the path
-				 * must be stable.
-				 *
-				 * FIXME Implement path collection; submit via
-				 * jtag_add_pathmove() after teaching it to
-				 * report errors.
+				 * state adjacent to the previous one.  Start
+				 * collecting them.
 				 */
-				LOG_ERROR("XSVF: 'XSTATE %s' ... NYET",
-						tap_state_name(mystate));
-				unsupported = 1;
+				collecting_path = true;
+				pathlen = 1;
+				path[0] = mystate;
 			}
 			break;
 

tcl/interface/olimex-arm-usb-ocd-h.cfg

@@ -0,0 +1,11 @@
+#
+# Olimex ARM-USB-OCD-H
+#
+# http://www.olimex.com/dev/arm-usb-ocd.html
+#
+
+interface ft2232
+ft2232_device_desc "Olimex OpenOCD JTAG ARM-USB-OCD-H"
+ft2232_layout olimex-jtag
+ft2232_vid_pid 0x15ba 0x002b
+

tcl/interface/olimex-arm-usb-tiny-h.cfg

@@ -0,0 +1,11 @@
+#
+# Olimex ARM-USB-TINY-H
+#
+# http://www.olimex.com/dev/arm-usb-tiny-h.html
+#
+
+interface ft2232
+ft2232_device_desc "Olimex OpenOCD JTAG ARM-USB-TINY-H"
+ft2232_layout olimex-jtag
+ft2232_vid_pid 0x15ba 0x002a
+

tcl/target/at91r40008.cfg

@@ -45,7 +45,7 @@ $_TARGETNAME configure -event gdb-flash-erase-start {
 
 $_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x3C000 -work-area-size 0x4000 -work-area-backup 0
 
-flash bank cfi 0x10000000 0x400000 2 2 0
+flash bank cfi 0x10000000 0x400000 2 2 $_TARGETNAME
 
 # For more information about the configuration files, take a look at:
 # openocd.texi

tcl/target/epc9301.cfg

@@ -28,4 +28,4 @@ target create $_TARGETNAME arm920t -endian $_ENDIAN -chain-position $_TARGETNAME
 
 #flash configuration
 #flash bank <driver> <base> <size> <chip_width> <bus_width> [driver_options ...]
-flash bank cfi 0x60000000 0x1000000 2 2 0
+flash bank cfi 0x60000000 0x1000000 2 2 $_TARGETNAME

tcl/target/lpc1768.cfg

@@ -44,7 +44,7 @@ $_TARGETNAME configure -event reset-init {
 # LPC1768 has 512kB of user-available FLASH (bootloader is located in separate dedicated region).
 # flash bank lpc1700 <base> <size> 0 0 <target#> <variant> <cclk> [calc_checksum]
 
-flash bank lpc2000 0x0 0x80000 0 0 0 lpc1700 12000 calc_checksum
+flash bank lpc2000 0x0 0x80000 0 0 $_TARGETNAME lpc1700 12000 calc_checksum
 
 # 4MHz / 6 = 666kHz, so use 500
 jtag_khz 500

tcl/target/lpc2103.cfg

@@ -35,4 +35,4 @@ $_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x40000000 -work-area-s
 
 # 32kB of internal Flash, core clocked with 12MHz crystal
 # flash bank lpc2000 <base> <size> 0 0 <target#> <variant> <clock> [calc_checksum]
-flash bank lpc2000 0x0 0x8000 0 0 0 lpc2000_v2 12000 calc_checksum
+flash bank lpc2000 0x0 0x8000 0 0 $_TARGETNAME lpc2000_v2 12000 calc_checksum

tcl/target/lpc2124.cfg

@@ -39,4 +39,4 @@ $_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x40000000 -work-area-s
 
 
 #flash bank <driver> <base> <size> <chip_width> <bus_width>
-flash bank lpc2000 0x0 0x40000 0 0 0 lpc2000_v1 14745 calc_checksum
+flash bank lpc2000 0x0 0x40000 0 0 $_TARGETNAME lpc2000_v1 14745 calc_checksum

tcl/target/lpc2129.cfg

@@ -38,4 +38,4 @@ target create $_TARGETNAME arm7tdmi -endian $_ENDIAN -chain-position $_TARGETNAM
 $_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x40000000 -work-area-size 0x4000 -work-area-backup 0
 
 #flash bank <driver> <base> <size> <chip_width> <bus_width>
-flash bank lpc2000 0x0 0x40000 0 0 0 lpc2000_v1 14765 calc_checksum
+flash bank lpc2000 0x0 0x40000 0 0 $_TARGETNAME lpc2000_v1 14765 calc_checksum

tcl/target/lpc2148.cfg

@@ -52,4 +52,4 @@ $_TARGETNAME configure -event reset-init {
 }
 
 # flash bank lpc2000 <base> <size> 0 0 <target#> <variant> <clock> [calc_checksum]
-flash bank lpc2000 0x0 0x7d000 0 0 0 lpc2000_v2 14765 calc_checksum
+flash bank lpc2000 0x0 0x7d000 0 0 $_TARGETNAME lpc2000_v2 14765 calc_checksum

tcl/target/lpc2294.cfg

@@ -32,7 +32,7 @@ $_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x40000000 -work-area-s
 
 #flash configuration
 #flash bank lpc2000 <base> <size> 0 0 <target#> <variant>
-flash bank lpc2000 0x0 0x40000 0 0 0 lpc2000_v1 14765 calc_checksum
+flash bank lpc2000 0x0 0x40000 0 0 $_TARGETNAME lpc2000_v1 14765 calc_checksum
 
 # For more information about the configuration files, take a look at:
 # openocd.texi

tcl/target/lpc2378.cfg

@@ -43,7 +43,7 @@ $_TARGETNAME configure -event reset-init {
 # LPC2378 has 512kB of FLASH, but upper 8kB are occupied by bootloader.
 # After reset the chip uses its internal 4MHz RC oscillator
 #flash bank lpc2000 <base> <size> 0 0 <target#> <variant>
-flash bank lpc2000 0x0 0x0007D000 0 0 0 lpc2000_v2 4000 calc_checksum
+flash bank lpc2000 0x0 0x0007D000 0 0 $_TARGETNAME lpc2000_v2 4000 calc_checksum
 
 # 4MHz / 6 = 666kHz, so use 500
 jtag_khz 500

tcl/target/lpc2478.cfg

@@ -43,7 +43,7 @@ $_TARGETNAME configure -event reset-init {
 # LPC2378 has 512kB of FLASH, but upper 8kB are occupied by bootloader.
 # After reset the chip uses its internal 4MHz RC oscillator.
 # flash bank lpc2000 <base> <size> 0 0 <target#> <variant> <clock> [calc checksum]
-flash bank lpc2000 0x0 0x7D000 0 0 0 lpc2000_v2 12000 calc_checksum
+flash bank lpc2000 0x0 0x7D000 0 0 $_TARGETNAME lpc2000_v2 12000 calc_checksum
 
 # Try to use RCLK, if RCLK is not available use "normal" mode. 4MHz / 6 = 666kHz, so use 500.
 jtag_rclk 500

tcl/target/smdk6410.cfg

@@ -5,4 +5,4 @@
 
 source [find target/samsung_s3c6410.cfg]
 
-flash bank cfi 0x00000000 0x00100000 2 2 0 jedec_probe
+flash bank cfi 0x00000000 0x00100000 2 2 $_TARGETNAME jedec_probe

tcl/target/stm32.cfg

@@ -40,10 +40,11 @@ if { [info exists CPUTAPID ] } {
 jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID
 
 if { [info exists BSTAPID ] } {
+   # FIXME this never gets used to override defaults...
    set _BSTAPID $BSTAPID
 } else {
   # See STM Document RM0008
-  # Section 26.6.2
+  # Section 29.6.2
   # Low density devices, Rev A
   set _BSTAPID1 0x06412041
   # Medium density devices, Rev A
@@ -55,14 +56,16 @@ if { [info exists BSTAPID ] } {
   # Connectivity line devices, Rev A and Rev Z
   set _BSTAPID5 0x06418041
 }
-jtag newtap $_CHIPNAME bs  -irlen 5 -ircapture 0x1 -irmask 0x1 -expected-id $_BSTAPID1 -expected-id $_BSTAPID2 -expected-id $_BSTAPID3 -expected-id $_BSTAPID4 -expected-id $_BSTAPID5
+jtag newtap $_CHIPNAME bs -irlen 5 -expected-id $_BSTAPID1 \
+	-expected-id $_BSTAPID2 -expected-id $_BSTAPID3 \
+	-expected-id $_BSTAPID4 -expected-id $_BSTAPID5
 
 set _TARGETNAME $_CHIPNAME.cpu
 target create $_TARGETNAME cortex_m3 -endian $_ENDIAN -chain-position $_TARGETNAME
 
 $_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x20000000 -work-area-size $_WORKAREASIZE -work-area-backup 0
 
-flash bank stm32x 0 0 0 0 0
+flash bank stm32x 0 0 0 0 $_TARGETNAME
 
 # For more information about the configuration files, take a look at:
 # openocd.texi

tcl/target/xba_revA3.cfg

@@ -79,7 +79,7 @@ $_TARGETNAME configure -event reset-init {
 $_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x20010000 -work-area-size 0x8060 -work-area-backup 0
 
 
-flash bank cfi 0x50000000 0x400000 2 2 0
+flash bank cfi 0x50000000 0x400000 2 2 $_TARGETNAME
 
 init
 reset init

tools/release.sh

@@ -1,8 +1,10 @@
-#!/bin/sh -e
+#!/bin/bash
 # release.sh: openocd release process automation
 # Copyright (C) 2009 by Zachary T Welch <zw@superlucidity.net>
 # Release under the GNU GPL v2 (or later versions).
 
+# FIXME Remove more bash-isms.  Fix errors making "ash -e" lose.
+
 ## set these to control the build process
 #CONFIG_OPTS=""
 #MAKE_OPTS=""
@@ -13,7 +15,7 @@
 ## The default is the current user name, as found by the 'id' command.
 #RELEASE_TAG="$(id -un)"
 
-source "tools/release/helpers.sh"
+. "tools/release/helpers.sh"
 
 VERSION_SH="tools/release/version.sh"
 
@@ -35,7 +37,6 @@ Build Commands:
   build         Compiles the project; runs configure, if needed.
 
 Packaging Commands:
-  changelog     Generate a new ChangeLog using ${SCM}2cl.
   package       Produce new distributable source archives.
   stage         Move archives to staging area for upload.
 
@@ -81,17 +82,8 @@ do_build() {
 maybe_build() { [ -f "src/openocd" ] || do_build; }
 do_build_clean() { [ -f Makefile ] && make maintainer-clean >/dev/null; }
 
-do_changelog() {
-	echo "Creating ChangeLog..."
-	local CMD=tools/git2cl/git2cl
-	eval ${CMD} ${OPTS} > ChangeLog
-}
-do_changelog_clean() {
-	git checkout ChangeLog
-}
 
 do_package() {
-	do_changelog
 	maybe_build
 	echo "Building distribution packages..."
 	make ${MAKE_OPTS} distcheck 2>&1 | perl tools/logger.pl > "release-pkg.log"
@@ -118,14 +110,12 @@ do_stage() {
 		mv -v "${FILE}" archives/
 	done
 	cp -a NEWS archives/
-	cp -a ChangeLog archives/
 }
 do_stage_clean() { rm -v -f -r archives; }
 
 do_clean() {
 	do_build_clean
 	do_package_clean
-	do_changelog_clean
 	rm -v -f release-*.log
 }
 do_clean_all() {
@@ -193,12 +183,13 @@ do_release_step_news() {
 	git mv "NEWS" "NEWS-${RELEASE_VERSION}"
 
 	cat >NEWS <<NEWS
-This file should include items worth mentioning in the
-OpenOCD ${NEXT_RELEASE_VERSION} source archive release.
-
-The following areas of OpenOCD functionality changed in this release:
+This file includes highlights of the changes made in the
+OpenOCD ${NEXT_RELEASE_VERSION} source archive release.  See the
+repository history for details about what changed, including
+bugfixes and other issues not mentioned here.
 
 JTAG Layer:
+Boundary Scan:
 Target Layer:
 Flash Layer:
 Board, Target, and Interface Configuration Scripts:
@@ -206,8 +197,11 @@ Documentation:
 Build and Release:
 
 For more details about what has changed since the last release,
-see the ChangeLog associated with this source archive.  For older NEWS,
-see the NEWS files associated with each release (i.e. NEWS-<version>).
+see the git repository history.  With gitweb, you can browse that
+in various levels of detail.
+
+For older NEWS, see the NEWS files associated with each release
+(i.e. NEWS-<version>).
 
 For more information about contributing test reports, bug fixes, or new
 features and device support, please read the new Developer Manual (or
@@ -238,13 +232,6 @@ do_release_step_rebranch() {
 	git branch -d "${OLD_BRANCH}"
 }
 
-do_release_step_0() { do_release_step_branch; }
-do_release_step_1() { do_release_step_tag; }
-do_release_step_2() { do_release_step_bump; }
-do_release_step_3() { do_release_step_news; }
-do_release_step_4() { do_release_step_package; }
-do_release_step_5() { do_release_step_rebranch; }
-
 do_release_setup() {
 	echo "Starting $CMD for ${RELEASE_VERSION}..."
 	[ "${RELEASE_TYPE}" ] || \
@@ -274,7 +261,7 @@ do_countdown() {
 do_branch() {
 	do_release_setup
 	local i=
-	for i in 0 2 5; do
+	for i in branch bump rebranch; do
 		"do_release_step_${i}"
 	done
 }
@@ -284,7 +271,7 @@ do_release() {
 	do_release_setup
 	do_release_check
 	local i=
-	for i in $(seq 0 5); do
+	for i in branch tag bump news package rebranch; do
 		"do_release_step_${i}"
 	done
 }
@@ -358,9 +345,9 @@ CMD=$1
 [ "${CMD}" ] || usage
 shift
 
-ACTION_CMDS="bootstrap|configure|build|changelog|package|stage|clean"
+ACTION_CMDS="bootstrap|configure|build|package|stage|clean"
 MISC_CMDS="all|info|release|branch|reset|help|usage"
-CLEAN_CMDS="build_clean|changelog_clean|package_clean|stage_clean|clean_all"
+CLEAN_CMDS="build_clean|package_clean|stage_clean|clean_all"
 CMDS="|${ACTION_CMDS}|${CLEAN_CMDS}|${MISC_CMDS}|"
 is_command() { echo "${CMDS}" | grep "|$1|" >/dev/null; }
 

tools/release/version.sh

@@ -1,9 +1,20 @@
-#!/bin/sh -e
+#!/bin/bash
 # version.sh: openocd version process automation
 # Copyright (C) 2009 by Zachary T Welch <zw@superlucidity.net>
 # Release under the GNU GPL v2 (or later versions).
 
-source "tools/release/helpers.sh"
+# FIXME Remove more bash-isms.  Fix errors making "ash -e" lose.
+
+# NOTE Use with care!  "RC" should only follow x.x.x, with
+# vendor tags after that.  Be traditional; avoid "rc0".
+
+# NOTE:  This *ONLY* updates the "configure.in" version tag.
+# It does not affect GIT tags.  Use this script immediately
+# before making a release, to remove the "-dev" tag and to
+# update the version label.  Then commit the change and tag
+# that commit to match the version label.
+
+. "tools/release/helpers.sh"
 
 do_version_usage() {
 	cat << USAGE
@@ -15,6 +26,7 @@ Version Commands:
   bump tag <label>             Add or bump a versioned tag (e.g. -rcN).
   bump final <label>           Remove a versioned tag (e.g. -rcN).
 USAGE
+# REVISIT ... "commit" not listed.
 }
 
 do_version_sed() {