Remove annoying end-of-line whitespace from doc/* files.

git-svn-id: svn://svn.berlios.de/openocd/trunk@2744 b42882b7-edfa-0310-969c-e2dbd0fdcd60

15 files changed, 131 insertions, 131 deletions

diff --git a/doc/INSTALL.txt b/doc/INSTALL.txt
index 5b8077ad..c329be2c 100644
--- a/doc/INSTALL.txt
+++ b/doc/INSTALL.txt
@@ -16,7 +16,7 @@ possible using a Cygwin host.
 Basic Installation
 ==================
 
-   OpenOCD is distributed without autotools generated files, i.e. without a 
+   OpenOCD is distributed without autotools generated files, i.e. without a
 configure script. Run ./bootstrap in the openocd directory to have all
 necessary files generated.
 
@@ -77,7 +77,7 @@ The simplest way to compile this package is:
      documentation.
 
   4. You can remove the program binaries and object files from the
-     source code directory by typing `make clean'.  
+     source code directory by typing `make clean'.
 
 Compilers and Options
 =====================
diff --git a/doc/manual/flash.txt b/doc/manual/flash.txt
index dbc4b94b..a9f6c2a5 100644
--- a/doc/manual/flash.txt
+++ b/doc/manual/flash.txt
@@ -7,7 +7,7 @@ FMI, etc.).
 
 The Flash module provides the following APIs:
 
-  - @subpage flashcfi 
+  - @subpage flashcfi
   - @subpage flashnand
   - @subpage flashtarget
 
diff --git a/doc/manual/jtag.txt b/doc/manual/jtag.txt
index 54d0a568..8f0804ce 100644
--- a/doc/manual/jtag.txt
+++ b/doc/manual/jtag.txt
@@ -32,7 +32,7 @@ asynchronous transactions.
     - includes the Cable/TAP API (commands starting with @c tap_)
 
 - @subpage jtagdriver
-  - @b private minidriver API 
+  - @b private minidriver API
   - declared in @c src/jtag/minidriver.h
   - used @a only by the core and minidriver implementations:
     - @c jtag_driver.c (in-tree OpenOCD drivers)
diff --git a/doc/manual/primer/autotools.txt b/doc/manual/primer/autotools.txt
index 10c60006..fbf42196 100644
--- a/doc/manual/primer/autotools.txt
+++ b/doc/manual/primer/autotools.txt
@@ -144,7 +144,7 @@ implement new checks.
 The <code>make distcheck</code> command produces an archive of the
 project deliverables (using <code>make dist</code>) and verifies its
 integrity for distribution by attemptng to use the package in the same
-manner as a user.  
+manner as a user.
 
 These checks includes the following steps:
 -# Unpack the project archive into its expected directory.
diff --git a/doc/manual/primer/docs.txt b/doc/manual/primer/docs.txt
index d478d81c..504da790 100644
--- a/doc/manual/primer/docs.txt
+++ b/doc/manual/primer/docs.txt
@@ -90,7 +90,7 @@ provide detailed documentation for each option.
 To support out-of-tree building of the documentation, the @c Doxyfile.in
 @c INPUT values will have all instances of the string @c "@srcdir@"
 replaced with the current value of the make variable
-<code>$(srcdir)</code>.  The Makefile uses a rule to convert 
+<code>$(srcdir)</code>.  The Makefile uses a rule to convert
 @c Doxyfile.in into the @c Doxyfile used by <code>make doxygen</code>.
 
 @section primerdoxyoocd OpenOCD Input Files
@@ -105,7 +105,7 @@ that can be found under the @c doc/manual directory in the project tree.
 New files containing valid Doxygen markup that are placed in or under
 that directory will be detected and included in The Manual automatically.
 
-@section primerdoxyman Doxygen Reference Manual 
+@section primerdoxyman Doxygen Reference Manual
 
 The full documentation for Doxygen can be referenced on-line at the project
 home page: http://www.doxygen.org/index.html.  In HTML versions of this
diff --git a/doc/manual/primer/jtag.txt b/doc/manual/primer/jtag.txt
index 9142dadc..0c675282 100644
--- a/doc/manual/primer/jtag.txt
+++ b/doc/manual/primer/jtag.txt
@@ -1,14 +1,14 @@
 /** @page primerjtag OpenOCD JTAG Primer
 
-JTAG is unnecessarily confusing, because JTAG is often confused with 
+JTAG is unnecessarily confusing, because JTAG is often confused with
 boundary scan, which is just one of its possible functions.
 
-JTAG is simply a communication interface designed to allow communication 
-to functions contained on devices, for the designed purposes of 
-initialisation, programming, testing, debugging, and anything else you 
+JTAG is simply a communication interface designed to allow communication
+to functions contained on devices, for the designed purposes of
+initialisation, programming, testing, debugging, and anything else you
 want to use it for (as a chip designer).
 
-Think of JTAG as I2C for testing.  It doesn't define what it can do, 
+Think of JTAG as I2C for testing.  It doesn't define what it can do,
 just a logical interface that allows a uniform channel for communication.
 
 See @par
@@ -17,42 +17,42 @@ See @par
 and @par
 	http://www.inaccessnetworks.com/projects/ianjtag/jtag-intro/jtag-state-machine-large.png
 
-The first page (among other things) shows a logical representation 
-describing how multiple devices are wired up using JTAG.  JTAG does not 
-specify, data rates or interface levels (3.3V/1.8V, etc) each device can 
-support different data rates/interface logic levels.  How to wire them 
+The first page (among other things) shows a logical representation
+describing how multiple devices are wired up using JTAG.  JTAG does not
+specify, data rates or interface levels (3.3V/1.8V, etc) each device can
+support different data rates/interface logic levels.  How to wire them
 in a compatible way is an exercise for an engineer.
 
-Basically TMS controls which shift register is placed on the device, 
-between TDI and TDO.  The second diagram shows the state transitions on 
+Basically TMS controls which shift register is placed on the device,
+between TDI and TDO.  The second diagram shows the state transitions on
 TMS which will select different shift registers.
 
-The first thing you need to do is reset the state machine, because when 
-you connect to a chip you do not know what state the controller is in,you need 
-to clock TMS as 1, at least 7 times.  This will put you into "Test Logic 
-Reset" State.  Knowing this, you can, once reset, then track what each 
-transition on TMS will do, and hence know what state the JTAG state 
+The first thing you need to do is reset the state machine, because when
+you connect to a chip you do not know what state the controller is in,you need
+to clock TMS as 1, at least 7 times.  This will put you into "Test Logic
+Reset" State.  Knowing this, you can, once reset, then track what each
+transition on TMS will do, and hence know what state the JTAG state
 machine is in.
 
-There are 2 "types" of shift registers.  The Instruction shift register 
-and the data shift register.  The sizes of these are undefined, and can 
-change from chip to chip.  The Instruction register is used to select 
-which Data register/data register function is used, and the data 
+There are 2 "types" of shift registers.  The Instruction shift register
+and the data shift register.  The sizes of these are undefined, and can
+change from chip to chip.  The Instruction register is used to select
+which Data register/data register function is used, and the data
 register is used to read data from that function or write data to it.
 
-Each of the states control what happens to either the data register or 
+Each of the states control what happens to either the data register or
 instruction register.
 
-For example, one of the data registers will be known as "bypass" this is 
-(usually) a single bit which has no function and is used to bypass the 
-chip.  Assume we have 3 identical chips, wired up like the picture 
-and each has a 3 bit instruction register, and there are 2 known 
-instructions (110 = bypass, 010 = some other function) if we want to use 
-"some other function", on the second chip in the line, and not change 
+For example, one of the data registers will be known as "bypass" this is
+(usually) a single bit which has no function and is used to bypass the
+chip.  Assume we have 3 identical chips, wired up like the picture
+and each has a 3 bit instruction register, and there are 2 known
+instructions (110 = bypass, 010 = some other function) if we want to use
+"some other function", on the second chip in the line, and not change
 the other chips we would do the following transitions.
 
 From Test Logic Reset, TMS goes:
- 
+
   0 1 1 0 0
 
 which puts every chip in the chain into the "Shift IR state"
@@ -60,7 +60,7 @@ Then (while holding TMS as 0) TDI goes:
 
   0 1 1  0 1 0  0 1 1
 
-which puts the following values in the instruction shift register for 
+which puts the following values in the instruction shift register for
 each chip [110] [010] [110]
 
 The order is reversed, because we shift out the least significant bit
@@ -70,18 +70,18 @@ first.  Then we transition TMS:
 
 which puts us in the "Shift DR state".
 
-Now when we clock data onto TDI (again while holding TMS to 0) , the 
-data shifts through the data registers, and because of the instruction 
-registers we selected (some other function has 8 bits in its data 
+Now when we clock data onto TDI (again while holding TMS to 0) , the
+data shifts through the data registers, and because of the instruction
+registers we selected (some other function has 8 bits in its data
 register), our total data register in the chain looks like this:
 
   0 00000000 0
 
-The first and last bit are in the "bypassed" chips, so values read from 
-them are irrelevant and data written to them is ignored.  But we need to 
+The first and last bit are in the "bypassed" chips, so values read from
+them are irrelevant and data written to them is ignored.  But we need to
 write bits for those registers, because they are in the chain.
 
-If we wanted to write 0xF5 to the data register we would clock out of 
+If we wanted to write 0xF5 to the data register we would clock out of
 TDI (holding TMS to 0):
 
   0 1 0 1 0 1 1 1 1 0
@@ -91,13 +91,13 @@ clock TMS:
 
   1 1 0
 
-which updates the selected data register with the value 0xF5 and returns 
+which updates the selected data register with the value 0xF5 and returns
 us to run test idle.
 
-If we needed to read the data register before over-writing it with F5, 
-no sweat, that's already done, because the TDI/TDO are set up as a 
-circular shift register, so if you write enough bits to fill the shift 
-register, you will receive the "captured" contents of the data registers 
+If we needed to read the data register before over-writing it with F5,
+no sweat, that's already done, because the TDI/TDO are set up as a
+circular shift register, so if you write enough bits to fill the shift
+register, you will receive the "captured" contents of the data registers
 simultaneously on TDO.
 
 That's JTAG in a nutshell.  On top of this, you need to get specs for
diff --git a/doc/manual/primer/patches.txt b/doc/manual/primer/patches.txt
index 098766eb..b24e72fa 100644
--- a/doc/manual/primer/patches.txt
+++ b/doc/manual/primer/patches.txt
@@ -8,7 +8,7 @@ for OpenOCD contributors who are unfamiliar with the process.
 The standard method for creating patches requires developers to:
 - checkout the Subversion repository (or bring a copy up-to-date),
 - make the necessary modifications to a working copy,
-- check with 'svn status' to see which files will be modified/added, and 
+- check with 'svn status' to see which files will be modified/added, and
 - use 'svn diff' to review the changes and produce a patch.
 
 It is important to minimize the changes to only those lines that contain
@@ -67,7 +67,7 @@ patch, or you can specified specific files and directories when using
 <code>svn diff</code>.  Overlapping patches will be discussed in the
 next section.
 
-The remainder of this section provides 
+The remainder of this section provides
 
 @subsection primerpatchprops Subversion Properties
 
@@ -110,7 +110,7 @@ The following series of commands will work: @par
 svn diff foo | unix2dos | patch -R
 @endcode
 
-This is not a bug. 
+This is not a bug.
 
 @todo Does Subversion's treatment of line-endings for files marked with
 svn:eol-style=native continue to pose the problems described here, or
diff --git a/doc/manual/primer/tcl.txt b/doc/manual/primer/tcl.txt
index c10c3647..9be4a05e 100644
--- a/doc/manual/primer/tcl.txt
+++ b/doc/manual/primer/tcl.txt
@@ -115,7 +115,7 @@ Exception: The arrays.
 
        set x "2 * 6"
        set foo([expr $x])  "twelve"
-       
+
 **************************************************
 ***************************************************
 === TCL TOUR ===
@@ -133,7 +133,7 @@ This means it is evaluated when the file is parsed.
 In TCL, "FOR" is a funny thing, it is not what you think it is.
 
 Syntactically - FOR is a just a command, it is not language
-construct like for(;;) in C... 
+construct like for(;;) in C...
 
 The "for" command takes 4 parameters.
    (1) The "initial command" to execute.
@@ -215,7 +215,7 @@ All memory regions must have 2 things:
  (2)  NAME( array )
       And the array must have some specific names:
           ( <idx>, THING )
-	    Where: THING is one of: 
+	    Where: THING is one of:
 		   CHIPSELECT
 		   BASE
 		   LEN
@@ -224,7 +224,7 @@ All memory regions must have 2 things:
 		   RWX - the access ability.
 		   WIDTH - the accessible width.
 
-        ie: Some regions of memory are not 'word' 
+        ie: Some regions of memory are not 'word'
 	accessible.
 
 The function "address_info" - given an address should
@@ -237,14 +237,14 @@ tell you about the address.
 MAJOR FUNCTION:
 ==
 
-proc memread32 { ADDR } 
-proc memread16 { ADDR } 
-proc memread8 { ADDR } 
+proc memread32 { ADDR }
+proc memread16 { ADDR }
+proc memread8 { ADDR }
 
 All read memory - and return the contents.
 
 [ FIXME: 7/5/2008 - I need to create "memwrite" functions]
-		 
+
 **************************************************
 ***************************************************
 === TCL TOUR ===
@@ -265,13 +265,13 @@ In a makefile or shell script you may have seen this:
      FOO_linux = "Penguins rule"
      FOO_winXP = "Broken Glass"
      FOO_mac   = "I like cat names"
-     
+
      # Pick one
      BUILD  = linux
      #BUILD = winXP
      #BUILD = mac
      FOO = ${FOO_${BUILD}}
-				
+
 The "double [set] square bracket" thing is the TCL way, nothing more.
 
 ----
@@ -290,7 +290,7 @@ Notice this IF COMMAND - (not statement) is like this:
 The "IF" command expects either 2 params, or 4 params.
 
  === Sidebar: About "commands" ===
-  
+
      Take a look at the internals of "jim.c"
      Look for the function: Jim_IfCoreCommand()
      And all those other "CoreCommands"
@@ -298,10 +298,10 @@ The "IF" command expects either 2 params, or 4 params.
      You'll notice - they all have "argc" and "argv"
 
      Yea, the entire thing is done that way.
-     
+
      IF is a command. SO is "FOR" and "WHILE" and "DO" and the
      others. That is why I keep using the phase it is a "command"
-     
+
  === END: Sidebar: About "commands" ===
 
 Parameter 1 to the IF command is expected to be an expression.
@@ -315,7 +315,7 @@ CATCH - is an error catcher.
 You give CATCH 1 or 2 parameters.
     The first 1st parameter is the "code to execute"
     The 2nd (optional) is where to put the error message.
-    
+
     CATCH returns 0 on success, 1 for failure.
     The "![catch command]" is self explaintory.
 
@@ -325,7 +325,7 @@ above, the IF command can take many parameters they just have to
 be joined by exactly the words "else" or "elseif".
 
 The 4th parameter contains:
-    
+
     "error [format STRING....]"
 
 This lets me modify the previous lower level error by tacking more
@@ -346,7 +346,7 @@ string, then using "dlopen()" and "dlsym()" to look it up - and get a
 function pointer - and calling the function pointer.
 
 In this case - I execute a dynamic command. You can do some cool
-tricks with interpretors. 
+tricks with interpretors.
 
 ----------
 
@@ -380,7 +380,7 @@ Some assumptions:
 
 The "CHIP" file has defined some variables in a proper form.
 
-ie:   AT91C_BASE_US0 - for usart0, 
+ie:   AT91C_BASE_US0 - for usart0,
       AT91C_BASE_US1 - for usart1
       ... And so on ...
 
@@ -419,9 +419,9 @@ with the generated list of commands for the entire USART.
 With that little bit of code - I now have a bunch of functions like:
 
    show_US0, show_US1, show_US2, .... etc ...
-   
+
    And show_US0_MR, show_US0_IMR ... etc...
-  
+
 And - I have this for every USART... without having to create tons of
 boiler plate yucky code.
 
diff --git a/doc/manual/release.txt b/doc/manual/release.txt
index c7069717..273f228a 100644
--- a/doc/manual/release.txt
+++ b/doc/manual/release.txt
@@ -113,7 +113,7 @@ tags and incrementing the version.
 
 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.  
+@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.
@@ -132,7 +132,7 @@ 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 
+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:
 
 - T minus one month: start of new development cycle
@@ -190,7 +190,7 @@ Even with the release script, some steps require clear user intervention
 The following steps should be followed to produce each release:
 
 -# Produce final patches to the trunk (or release branch):
-  -# Finalize @c NEWS file to describe the changes in the release 
+  -# Finalize @c NEWS file to describe the changes in the release
     - 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.
@@ -208,7 +208,7 @@ svn cp .../trunk .../branches/${RELEASE_BRANCH}
 svn cp .../branches/${RELEASE_BRANCH} .../tags/${RELEASE_TAG}
 @endverbatim
   - For bug-fix releases produced in their respective branch, a tag
-    should be created in the repository: 
+    should be created in the repository:
 @verbatim
 svn cp .../branches/${RELEASE_BRANCH} .../tags/${RELEASE_TAG}
 @endverbatim
diff --git a/doc/manual/scripting.txt b/doc/manual/scripting.txt
index e5b5f700..783541ca 100644
--- a/doc/manual/scripting.txt
+++ b/doc/manual/scripting.txt
@@ -5,7 +5,7 @@
 The scripting support is intended for developers of OpenOCD.
 It is not the intention that normal OpenOCD users will
 use tcl scripting extensively, write lots of clever scripts,
-or contribute back to OpenOCD. 
+or contribute back to OpenOCD.
 
 Target scripts can contain new procedures that end users may
 tinker to their needs without really understanding tcl.
@@ -31,7 +31,7 @@ Default implementation of procedures in tcl/procedures.tcl.
     file format and structure of serialnumber. Tcl allows
     an argument to consist of e.g. a list so the structure of
     the serial number is not limited to a single string.
-  - reset handling. Precise control of how srst, trst & 
+  - reset handling. Precise control of how srst, trst &
     tms is handled.
 - replace some parts of the current command line handler.
   This is only to simplify the implementation of OpenOCD
@@ -42,7 +42,7 @@ Default implementation of procedures in tcl/procedures.tcl.
   that return machine readable output. These low level tcl
   functions constitute the tcl api. flash_banks is such
   a low level tcl proc. "flash banks" is an example of
-  a command that has human readable output. The human 
+  a command that has human readable output. The human
   readable output is expected to change inbetween versions
   of OpenOCD. The output from flash_banks may not be
   in the preferred form for the client. The client then
@@ -50,8 +50,8 @@ Default implementation of procedures in tcl/procedures.tcl.
   or b) write a small piece of tcl to output the
   flash_banks output to a more suitable form. The latter may
   be simpler.
-  
-  
+
+
 @section scriptingexternal External scripting
 
 The embedded Jim Tcl interpreter in OpenOCD is very limited
diff --git a/doc/manual/server.txt b/doc/manual/server.txt
index 2e5aaf3b..4310d365 100644
--- a/doc/manual/server.txt
+++ b/doc/manual/server.txt
@@ -32,14 +32,14 @@ high-level interface to OpenOCD, because they only had two choices:
 - the ablity to write a complex internal commands: native 'commands'
   inside of OpenOCD was complicated.
 
-Fundamentally, the basic problem with both of those would be solved 
+Fundamentally, the basic problem with both of those would be solved
 with a script language:
 
 -# <b>Internal</b>: simple, small, and self-contained.
 -# <b>Cross Language</b>: script friendly front-end
 -# <b>Cross Host</b>: GUI Host interface
 -# <b>Cross Debugger</b>: GUI-like interface
-  
+
 What follows hopefully shows how the plans to solve these problems
 materialized and help to explain the grand roadmap plan.
 
@@ -64,7 +64,7 @@ file, allowing OpenOCD to avoid the spider web of dependent packages.
 
 The TCL Server port was added in mid-2008.  With embedded TCL, we can
 write scripts internally to help things, or we can write "C" code  that
-interfaces well with TCL. 
+interfaces well with TCL.
 
 From there, the developers wanted to create an external front-end that
 would be @a very usable and that that @a any language could utilize,
@@ -81,7 +81,7 @@ terse, simple ASCII protocols that are emensely parsable by a script.
 Thus, the TCL server -- a 'machine' type socket interface -- was added
 with the hope was it would output simple "name-value" pair type
 data.  At the time, simple name/value pairs seemed reasonably easier to
-do at the time, though Maybe it should output JSON; 
+do at the time, though Maybe it should output JSON;
 
 See here:
 
@@ -101,11 +101,11 @@ How do we solve that problem?
 For example, Cygwin can be painful, Cygwin GUI packages want X11
 to be present, crossing the barrier between MinGW and Cygwin is
 painful, let alone getting the GUI front end to work on MacOS, and
-Linux, yuck yuck yuck. Painful. very very painful.  
+Linux, yuck yuck yuck. Painful. very very painful.
 
 What works easier and is less work is what is already present in every
 platform?  The answer: A web browser.  In other words, OpenOCD could
-serve out embedded web pages via "localhost" to your browser. 
+serve out embedded web pages via "localhost" to your browser.
 
 Long before OpenOCD had a TCL command line, Zylin AS built their ZY1000
 devince with a built-in HTTP server.  Later, they were willing to both
@@ -169,7 +169,7 @@ the Socket Approach is used.
 
 During 2008, Duane Ellis created some TCL scripts to display peripheral
 register contents. For example, look at the sam7 TCL scripts, and the
-stm32 TCL scripts.  The hope was others would create more. 
+stm32 TCL scripts.  The hope was others would create more.
 
 
 A good example of this is display/view the peripheral registers on
@@ -215,7 +215,7 @@ One reason might be, this adds one more host side requirement to make
 use of the feature.  In other words, one could write a Python/TK
 front-end, but it is only useable if you have Python/TK installed.
 Maybe this can be done via Ecllipse, but not all developers use Ecplise.
-Many devlopers use Emacs (possibly with GUD mode) or vim and will not 
+Many devlopers use Emacs (possibly with GUD mode) or vim and will not
 accept such an interface.  The next developer reading this might be
 using Insight (GDB-TK) - and somebody else - DDD..
 
diff --git a/doc/manual/style.txt b/doc/manual/style.txt
index 0fe33876..ef73aed6 100644
--- a/doc/manual/style.txt
+++ b/doc/manual/style.txt
@@ -149,7 +149,7 @@ comments.
  * in blocks such as the one in which this example appears in the Style
  * Guide.  See the Doxygen Manual for the full list of commands.
  *
- * @param foo For a function, describe the parameters (e.g. @a foo). 
+ * @param foo For a function, describe the parameters (e.g. @a foo).
  * @returns The value(s) returned, or possible error conditions.
  */
 @endverbatim
@@ -229,7 +229,7 @@ This file contains the @ref pagename page.
 @endverbatim
 
 For an example, the Doxygen source for this Style Guide can be found in
-@c doc/manual/style.txt, alongside other parts of The Manual.  
+@c doc/manual/style.txt, alongside other parts of The Manual.
 
  */
 /** @page styletexinfo Texinfo Style Guide
@@ -344,7 +344,7 @@ Likewise, the @ref primerlatex for using this guide needs to be completed.
 This page provides some style guidelines for using Perl, a scripting
 language used by several small tools in the tree:
 
--# Ensure all Perl scripts use the proper suffix (@c .pl for scripts, and 
+-# Ensure all Perl scripts use the proper suffix (@c .pl for scripts, and
    @c .pm for modules)
 -# Pass files as script parameters or piped as input:
   - Do NOT code paths to files in the tree, as this breaks out-of-tree builds.
diff --git a/doc/manual/target/notarm.txt b/doc/manual/target/notarm.txt
index c368ed1c..5d5be78c 100644
--- a/doc/manual/target/notarm.txt
+++ b/doc/manual/target/notarm.txt
@@ -37,7 +37,7 @@ mailing list
 @section targetnotarmsupport Target Support
 
 target.h is relatively CPU agnostic and
-the intention is to move in the direction of less 
+the intention is to move in the direction of less
 instruction set specific.
 
 Non-CPU targets are also supported, but there isn't
@@ -56,7 +56,7 @@ OpenOCD does not today have targets that use non-JTAG.
 The actual physical layer is a relatively modest part
 of the total OpenOCD system.
 
- 
+
 @section targetnotarmppc PowerPC
 
 there exists open source implementations of powerpc
diff --git a/doc/openocd.1 b/doc/openocd.1
index b3525219..77abcf9b 100644
--- a/doc/openocd.1
+++ b/doc/openocd.1
@@ -8,19 +8,19 @@ boundary\-scan testing tool for ARM and MIPS systems
 .B OpenOCD
 is an on\-chip debugging, in\-system programming and boundary\-scan
 testing tool for various ARM and MIPS systems.
-.PP 
+.PP
 The debugger uses an IEEE 1149\-1 compliant JTAG TAP bus master to access
 on\-chip debug functionality available on ARM based microcontrollers or
 system-on-chip solutions. For MIPS systems the EJTAG interface is supported.
-.PP 
+.PP
 User interaction is realized through a telnet command line interface,
 a gdb (the GNU debugger) remote protocol server, and a simplified RPC
 connection that can be used to interface with OpenOCD's Jim Tcl engine.
-.PP 
+.PP
 OpenOCD supports various different types of JTAG interfaces/programmers,
 please check the \fIopenocd\fR info page for the complete list.
 .SH "OPTIONS"
-.TP 
+.TP
 .B "\-f, \-\-file <filename>"
 Use configuration file
 .BR <filename> .
@@ -29,43 +29,43 @@ In order to specify multiple config files, you can use multiple
 arguments. If this option is omitted, the config file
 .B openocd.cfg
 in the current working directory will be used.
-.TP 
+.TP
 .B "\-s, \-\-search <dirname>"
 Search for config files and scripts in the directory
 .BR <dirname> .
 If this option is omitted, OpenOCD searches for config files and scripts
 in the current directory.
-.TP 
+.TP
 .B "\-d, \-\-debug <debuglevel>"
 Set debug level. Possible values are:
-.br 
+.br
 .RB "  * " 0 " (errors)"
-.br 
+.br
 .RB "  * " 1 " (warnings)"
-.br 
+.br
 .RB "  * " 2 " (informational messages)"
-.br 
+.br
 .RB "  * " 3 " (debug messages)"
-.br 
+.br
 The default level is
 .BR 2 .
-.TP 
+.TP
 .B "\-l, \-\-log_output <filename>"
 Redirect log output to the file
 .BR <filename> .
 Per default the log output is printed on
 .BR stderr .
-.TP 
+.TP
 .B "\-c, \-\-command <cmd>"
 Run the command
 .BR <cmd> .
-.TP 
+.TP
 .B "\-p, \-\-pipe"
 Use pipes when talking to gdb.
-.TP 
+.TP
 .B "\-h, \-\-help"
 Show a help text and exit.
-.TP 
+.TP
 .B "\-v, \-\-version"
 Show version information and exit.
 .SH "BUGS"
@@ -95,6 +95,6 @@ Also, the OpenOCD wiki contains some more information and examples:
 .B http://openfacts.berlios.de/index-en.phtml?title=Open_On-Chip_Debugger
 .SH "AUTHORS"
 Please see the file AUTHORS.
-.PP 
+.PP
 This manual page was written by Uwe Hermann <uwe@hermann\-uwe.de>.
 It is licensed under the terms of the GNU GPL (version 2 or later).
diff --git a/doc/openocd.texi b/doc/openocd.texi
index ab15bedb..6b9e12e0 100644
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -252,7 +252,7 @@ and has a built in relay to power cycle targets remotely.
 
 There are several things you should keep in mind when choosing a dongle.
 
-@enumerate 
+@enumerate
 @item @b{Voltage} What voltage is your target - 1.8, 2.8, 3.3, or 5V?
 Does your dongle support it?  You might need a level converter.
 @item @b{Pinout} What pinout does your target board use?
@@ -260,7 +260,7 @@ Does your dongle support it?  You may be able to use jumper
 wires, or an "octopus" connector, to convert pinouts.
 @item @b{Connection} Does your computer have the USB, printer, or
 Ethernet port needed?
-@item @b{RTCK} Do you require RTCK? Also known as ``adaptive clocking'' 
+@item @b{RTCK} Do you require RTCK? Also known as ``adaptive clocking''
 @end enumerate
 
 @section Stand alone Systems
@@ -344,7 +344,7 @@ Raisonance has an adapter called @b{RLink}.  It exists in a stripped-down form o
 @item @b{USBprog}
 @* Link: @url{http://www.embedded-projects.net/usbprog} - which uses an Atmel MEGA32 and a UBN9604
 
-@item @b{USB - Presto} 
+@item @b{USB - Presto}
 @* Link: @url{http://tools.asix.net/prg_presto.htm}
 
 @item @b{Versaloon-Link}
@@ -2098,7 +2098,7 @@ haven't seen hardware with such a bug, and can be worked around).
 
 @option{srst_gates_jtag} indicates that asserting SRST gates the
 JTAG clock. This means that no communication can happen on JTAG
-while SRST is asserted. 
+while SRST is asserted.
 
 The optional @var{trst_type} and @var{srst_type} parameters allow the
 driver mode of each reset line to be specified.  These values only affect
@@ -4359,7 +4359,7 @@ individually overridden.
 
 The target specific "dangerous" optimisation tweaking options may come and go
 as more robust and user friendly ways are found to ensure maximum throughput
-and robustness with a minimum of configuration. 
+and robustness with a minimum of configuration.
 
 Typically the "fast enable" is specified first on the command line:
 
@@ -4919,7 +4919,7 @@ those instructions are not currently understood by OpenOCD.)
 @deffn Command {armv4_5 reg}
 Display a table of all banked core registers, fetching the current value from every
 core mode if necessary. OpenOCD versions before rev. 60 didn't fetch the current
-register value. 
+register value.
 @end deffn
 
 @subsection ARM7 and ARM9 specific commands
@@ -4934,7 +4934,7 @@ and any other core-specific commands that may be available.
 @deffn Command {arm7_9 dbgrq} (@option{enable}|@option{disable})
 Control use of the EmbeddedIce DBGRQ signal to force entry into debug mode,
 instead of breakpoints.  This should be
-safe for all but ARM7TDMI--S cores (like Philips LPC). 
+safe for all but ARM7TDMI--S cores (like Philips LPC).
 This feature is enabled by default on most ARM9 cores,
 including ARM9TDMI, ARM920T, and ARM926EJ-S.
 @end deffn
@@ -4952,7 +4952,7 @@ with OpenOCD rev. 60, and requires a few bytes of working area.
 Enable or disable memory writes and reads that don't check completion of
 the operation. This provides a huge speed increase, especially with USB JTAG
 cables (FT2232), but might be unsafe if used with targets running at very low
-speeds, like the 32kHz startup clock of an AT91RM9200. 
+speeds, like the 32kHz startup clock of an AT91RM9200.
 @end deffn
 
 @deffn {Debug Command} {arm7_9 write_core_reg} num mode word
@@ -5843,7 +5843,7 @@ the following OpenOCD configuration option:
 gdb_memory_map disable
 @end example
 For this to function correctly a valid flash configuration must also be set
-in OpenOCD. For faster performance you should also configure a valid 
+in OpenOCD. For faster performance you should also configure a valid
 working area.
 
 Informing GDB of the memory map of the target will enable GDB to protect any
@@ -5887,10 +5887,10 @@ of currently active target, the Tcl API proc's take this sort of state
 information as an argument to each proc.
 
 There are three main types of return values: single value, name value
-pair list and lists. 
+pair list and lists.
 
 Name value pair. The proc 'foo' below returns a name/value pair
-list. 
+list.
 
 @verbatim
 
@@ -5913,7 +5913,7 @@ Thus, to get the names of the associative array is easy:
                 puts "Name: $name, Value: $value"
      }
 @end verbatim
- 
+
 Lists returned must be relatively small. Otherwise a range
 should be passed in to the proc in question.
 
@@ -5949,7 +5949,7 @@ Real Tcl has ::tcl_platform(), and platform::identify, and many other
 variables. JimTCL, as implemented in OpenOCD creates $HostOS which
 holds one of the following values:
 
-@itemize @bullet 
+@itemize @bullet
 @item @b{winxx}    Built using Microsoft Visual Studio
 @item @b{linux}    Linux is the underlying operating sytem
 @item @b{darwin}   Darwin (mac-os) is the underlying operating sytem.
@@ -6088,7 +6088,7 @@ Imagine debugging a 500MHz ARM926 hand held battery powered device
 that ``deep sleeps'' at 32kHz between every keystroke. It can be
 painful.
 
-@b{Solution #1 - A special circuit} 
+@b{Solution #1 - A special circuit}
 
 In order to make use of this, your JTAG dongle must support the RTCK
 feature. Not all dongles support this - keep reading!
@@ -6156,7 +6156,7 @@ jtag_khz 1234
 @item @b{Win32 Pathnames} Why don't backslashes work in Windows paths?
 
 OpenOCD uses Tcl and a backslash is an escape char. Use @{ and @}
-around Windows filenames. 
+around Windows filenames.
 
 @example
 > echo \a
@@ -6199,7 +6199,7 @@ settings in your PC BIOS (ECP, EPP, and different versions of those).
 
 @item @b{Data Aborts} When debugging with OpenOCD and GDB (plain GDB, Insight, or Eclipse),
 I get lots of "Error: arm7_9_common.c:1771 arm7_9_read_memory():
-memory read caused data abort". 
+memory read caused data abort".
 
 The errors are non-fatal, and are the result of GDB trying to trace stack frames
 beyond the last valid frame. It might be possible to prevent this by setting up
@@ -6220,7 +6220,7 @@ remember to pop them off when the ISR is done.
 
 @b{Also note:} If you have a multi-threaded operating system, they
 often do not @b{in the intrest of saving memory} waste these few
-bytes. Painful... 
+bytes. Painful...
 
 
 @item @b{JTAG Reset Config} I get the following message in the OpenOCD console (or log file):
@@ -6342,7 +6342,7 @@ TODO.
 
 @node Tcl Crash Course
 @chapter Tcl Crash Course
-@cindex Tcl 
+@cindex Tcl
 
 Not everyone knows Tcl - this is not intended to be a replacement for
 learning Tcl, the intent of this chapter is to give you some idea of
@@ -6461,7 +6461,7 @@ control flow operators.
 
 Commands are executed like this:
 
-@enumerate 
+@enumerate
 @item Parse the next line into (argc) and (argv[]).
 @item Look up (argv[0]) in a table and call its function.
 @item Repeat until End Of File.
@@ -6609,7 +6609,7 @@ substituted on the orginal command line.
 @enumerate
 @item The SET command creates 2 variables, X and Y.
 @item The double [nested] EXPR command performs math
-@* The EXPR command produces numerical result as a string. 
+@* The EXPR command produces numerical result as a string.
 @* Refer to Rule #1
 @item The format command is executed, producing a single string
 @* Refer to Rule #1.
@@ -6632,7 +6632,7 @@ substituted on the orginal command line.
 #4 DANGER DANGER DANGER
    $_TARGETNAME configure -event foo "puts \"Time: [date]\""
 @end example
-@enumerate 
+@enumerate
 @item The $_TARGETNAME is an OpenOCD variable convention.
 @*@b{$_TARGETNAME} represents the last target created, the value changes
 each time a new target is created. Remember the parsing rules. When
@@ -6699,9 +6699,9 @@ foreach who @{A B C D E@}
 OpenOCD comes with a target configuration script library. These scripts can be
 used as-is or serve as a starting point.
 
-The target library is published together with the OpenOCD executable and 
+The target library is published together with the OpenOCD executable and
 the path to the target library is in the OpenOCD script search path.
-Similarly there are example scripts for configuring the JTAG interface. 
+Similarly there are example scripts for configuring the JTAG interface.
 
 The command line below uses the example parport configuration script
 that ship with OpenOCD, then configures the str710.cfg target and