+This is an SNIP/example for an STR912 - which has 3 internal taps. Key features shown:
+
+@enumerate
+@item @b{Unform tap names} - See: Tap Naming Convention
+@item @b{_TARGETNAME} is created at the end where used.
+@end enumerate
+
+@example
+if @{ [info exists FLASHTAPID ] @} @{
+ set _FLASHTAPID $FLASHTAPID
+@} else @{
+ set _FLASHTAPID 0x25966041
+@}
+jtag newtap $_CHIPNAME flash -irlen 8 -ircapture 0x1 -irmask 0x1 -expected-id $_FLASHTAPID
+
+if @{ [info exists CPUTAPID ] @} @{
+ set _CPUTAPID $CPUTAPID
+@} else @{
+ set _CPUTAPID 0x25966041
+@}
+jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0xf -irmask 0xe -expected-id $_CPUTAPID
+
+
+if @{ [info exists BSTAPID ] @} @{
+ set _BSTAPID $BSTAPID
+@} else @{
+ set _BSTAPID 0x1457f041
+@}
+jtag newtap $_CHIPNAME bs -irlen 5 -ircapture 0x1 -irmask 0x1 -expected-id $_BSTAPID
+
+set _TARGETNAME [format "%s.cpu" $_CHIPNAME]
+@end example
+
+@b{Tap Naming Convention}
+
+See the command ``jtag newtap'' for detail, but in brief the names you should use are:
+
+@itemize @bullet
+@item @b{tap}
+@item @b{cpu}
+@item @b{flash}
+@item @b{bs}
+@item @b{jrc}
+@item @b{unknownN} - it happens :-(
+@end itemize
+
+@subsection Reset Configuration
+
+Some chips have specific ways the TRST and SRST signals are
+managed. If these are @b{CHIP SPECIFIC} they go here, if they are
+@b{BOARD SPECIFIC} they go in the board file.
+
+@subsection Work Areas
+
+Work areas are small RAM areas used by OpenOCD to speed up downloads,
+and to download small snippets of code to program flash chips.
+
+If the chip includes a form of ``on-chip-ram'' - and many do - define
+a reasonable work area and use the ``backup'' option.
+
+@b{PROBLEMS:} On more complex chips, this ``work area'' may become
+inaccessible if/when the application code enables or disables the MMU.
+
+@subsection ARM Core Specific Hacks
+
+If the chip has a DCC, enable it. If the chip is an ARM9 with some
+special high speed download features - enable it.
+
+If the chip has an ARM ``vector catch'' feature - by default enable
+it for Undefined Instructions, Data Abort, and Prefetch Abort, if the
+user is really writing a handler for those situations - they can
+easily disable it. Experiance has shown the ``vector catch'' is
+helpful - for common programing errors.
+
+If present, the MMU, the MPU and the CACHE should be disabled.
+
+@subsection Internal Flash Configuration
+
+This applies @b{ONLY TO MICROCONTROLLERS} that have flash built in.
+
+@b{Never ever} in the ``target configuration file'' define any type of
+flash that is external to the chip. (For example the BOOT flash on
+Chip Select 0). The BOOT flash information goes in a board file - not
+the TARGET (chip) file.
+
+Examples:
+@itemize @bullet
+@item at91sam7x256 - has 256K flash YES enable it.
+@item str912 - has flash internal YES enable it.
+@item imx27 - uses boot flash on CS0 - it goes in the board file.
+@item pxa270 - again - CS0 flash - it goes in the board file.
+@end itemize
+
+@node About JIM-Tcl
+@chapter About JIM-Tcl
+@cindex JIM Tcl
+@cindex tcl
+
+OpenOCD includes a small ``TCL Interpreter'' known as JIM-TCL. You can
+learn more about JIM here: @url{http://jim.berlios.de}
+
+@itemize @bullet
+@item @b{JIM vs. Tcl}
+@* JIM-TCL is a stripped down version of the well known Tcl language,
+which can be found here: @url{http://www.tcl.tk}. JIM-Tcl has far
+fewer features. JIM-Tcl is a single .C file and a single .H file and
+impliments the basic Tcl command set along. In contrast: Tcl 8.6 is a
+4.2 MB .zip file containing 1540 files.
+
+@item @b{Missing Features}
+@* Our practice has been: Add/clone the real Tcl feature if/when
+needed. We welcome JIM Tcl improvements, not bloat.
+
+@item @b{Scripts}
+@* OpenOCD configuration scripts are JIM Tcl Scripts. OpenOCD's
+command interpreter today (28/nov/2008) is a mixture of (newer)
+JIM-Tcl commands, and (older) the orginal command interpreter.
+
+@item @b{Commands}
+@* At the OpenOCD telnet command line (or via the GDB mon command) one
+can type a Tcl for() loop, set variables, etc.
+
+@item @b{Historical Note}
+@* JIM-Tcl was introduced to OpenOCD in spring 2008.
+
+@item @b{Need a crash course in Tcl?}
+@* See: @xref{Tcl Crash Course}.
+@end itemize
+
+
+@node Daemon Configuration
+@chapter Daemon Configuration
+The commands here are commonly found in the openocd.cfg file and are
+used to specify what TCP/IP ports are used, and how GDB should be
+supported.
+@section init
+@cindex 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,
+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.
+
+If this command does not appear in any startup/configuration file
+OpenOCD executes the command for you after processing all
+configuration files and/or command line options.
+
+@b{NOTE:} This command normally occurs at or near the end of your
+openocd.cfg file to force OpenOCD to ``initialize'' and make the
+targets ready. For example: If your openocd.cfg file needs to
+read/write memory on your target - the init command must occur before
+the memory read/write commands.
+
+@section TCP/IP Ports
+@itemize @bullet
+@item @b{telnet_port} <@var{number}>
+@cindex telnet_port
+@*Intended for a human. Port on which to listen for incoming telnet connections.
+
+@item @b{tcl_port} <@var{number}>
+@cindex tcl_port
+@*Intended as a machine interface. Port on which to listen for
+incoming Tcl syntax. This port is intended as a simplified RPC
+connection that can be used by clients to issue commands and get the
+output from the Tcl engine.
+
+@item @b{gdb_port} <@var{number}>
+@cindex gdb_port
+@*First port on which to listen for incoming GDB connections. The GDB port for the
+first target will be gdb_port, the second target will listen on gdb_port + 1, and so on.
+@end itemize
+
+@section GDB Items
+@itemize @bullet
+@item @b{gdb_breakpoint_override} <@var{hard|soft|disable}>
+@cindex gdb_breakpoint_override
+@anchor{gdb_breakpoint_override}
+@*Force breakpoint type for gdb 'break' commands.
+The raison d'etre for this option is to support GDB GUI's without
+a hard/soft breakpoint concept where the default OpenOCD and
+GDB behaviour is not sufficient. Note that GDB will use hardware
+breakpoints if the memory map has been set up for flash regions.
+
+This option replaces older arm7_9 target commands that addressed
+the same issue.
+
+@item @b{gdb_detach} <@var{resume|reset|halt|nothing}>
+@cindex gdb_detach
+@*Configures what OpenOCD will do when GDB detaches from the daemon.
+Default behaviour is <@var{resume}>
+
+@item @b{gdb_memory_map} <@var{enable|disable}>
+@cindex gdb_memory_map
+@*Set to <@var{enable}> to cause OpenOCD to send the memory configuration to GDB when
+requested. GDB will then know when to set hardware breakpoints, and program flash
+using the GDB load command. @option{gdb_flash_program enable} must also be enabled
+for flash programming to work.
+Default behaviour is <@var{enable}>
+@xref{gdb_flash_program}.
+
+@item @b{gdb_flash_program} <@var{enable|disable}>
+@cindex gdb_flash_program
+@anchor{gdb_flash_program}
+@*Set to <@var{enable}> to cause OpenOCD to program the flash memory when a
+vFlash packet is received.
+Default behaviour is <@var{enable}>
+@comment END GDB Items
+@end itemize
+
+@node Interface - Dongle Configuration
+@chapter Interface - Dongle Configuration
+Interface commands are normally found in an interface configuration
+file which is sourced by your openocd.cfg file. These commands tell
+OpenOCD what type of JTAG dongle you have and how to talk to it.
+@section Simple Complete Interface Examples
+@b{A Turtelizer FT2232 Based JTAG Dongle}
+@verbatim
+#interface
+interface ft2232
+ft2232_device_desc "Turtelizer JTAG/RS232 Adapter A"
+ft2232_layout turtelizer2
+ft2232_vid_pid 0x0403 0xbdc8
+@end verbatim
+@b{A SEGGER Jlink}
+@verbatim
+# jlink interface
+interface jlink
+@end verbatim
+@b{A Raisonance RLink}
+@verbatim
+# rlink interface
+interface rlink
+@end verbatim
+@b{Parallel Port}
+@verbatim
+interface parport
+parport_port 0xc8b8
+parport_cable wiggler
+jtag_speed 0
+@end verbatim
+@b{ARM-JTAG-EW}
+@verbatim
+interface arm-jtag-ew
+@end verbatim
+@section Interface Command
+
+The interface command tells OpenOCD what type of JTAG dongle you are
+using. Depending on the type of dongle, you may need to have one or
+more additional commands.
+
+@itemize @bullet
+
+@item @b{interface} <@var{name}>
+@cindex interface
+@*Use the interface driver <@var{name}> to connect to the
+target. Currently supported interfaces are
+
+@itemize @minus
+
+@item @b{parport}
+@* PC parallel port bit-banging (Wigglers, PLD download cable, ...)
+
+@item @b{amt_jtagaccel}
+@* Amontec Chameleon in its JTAG Accelerator configuration connected to a PC's EPP
+mode parallel port
+
+@item @b{ft2232}
+@* FTDI FT2232 (USB) based devices using either the open-source libftdi or the binary only
+FTD2XX driver. The FTD2XX is superior in performance, but not available on every
+platform. The libftdi uses libusb, and should be portable to all systems that provide
+libusb.
+
+@item @b{ep93xx}
+@*Cirrus Logic EP93xx based single-board computer bit-banging (in development)
+
+@item @b{presto}
+@* ASIX PRESTO USB JTAG programmer.
+
+@item @b{usbprog}
+@* usbprog is a freely programmable USB adapter.
+
+@item @b{gw16012}
+@* Gateworks GW16012 JTAG programmer.
+
+@item @b{jlink}
+@* Segger jlink USB adapter
+
+@item @b{rlink}
+@* Raisonance RLink USB adapter
+
+@item @b{vsllink}
+@* vsllink is part of Versaloon which is a versatile USB programmer.
+
+@item @b{arm-jtag-ew}
+@* Olimex ARM-JTAG-EW USB adapter
+@comment - End parameters
+@end itemize
+@comment - End Interface
+@end itemize
+@subsection parport options
+
+@itemize @bullet
+@item @b{parport_port} <@var{number}>
+@cindex parport_port
+@*Either the address of the I/O port (default: 0x378 for LPT1) or the number of
+the @file{/dev/parport} device
+
+When using PPDEV to access the parallel port, use the number of the parallel port:
+@option{parport_port 0} (the default). If @option{parport_port 0x378} is specified
+you may encounter a problem.
+@item @b{parport_cable} <@var{name}>
+@cindex parport_cable
+@*The layout of the parallel port cable used to connect to the target.
+Currently supported cables are
+@itemize @minus
+@item @b{wiggler}
+@cindex wiggler
+The original Wiggler layout, also supported by several clones, such
+as the Olimex ARM-JTAG
+@item @b{wiggler2}
+@cindex wiggler2
+Same as original wiggler except an led is fitted on D5.
+@item @b{wiggler_ntrst_inverted}
+@cindex wiggler_ntrst_inverted
+Same as original wiggler except TRST is inverted.
+@item @b{old_amt_wiggler}
+@cindex old_amt_wiggler
+The Wiggler configuration that comes with Amontec's Chameleon Programmer. The new
+version available from the website uses the original Wiggler layout ('@var{wiggler}')
+@item @b{chameleon}
+@cindex chameleon
+The Amontec Chameleon's CPLD when operated in configuration mode. This is only used to
+program the Chameleon itself, not a connected target.
+@item @b{dlc5}
+@cindex dlc5
+The Xilinx Parallel cable III.
+@item @b{triton}
+@cindex triton
+The parallel port adapter found on the 'Karo Triton 1 Development Board'.
+This is also the layout used by the HollyGates design
+(see @uref{http://www.lartmaker.nl/projects/jtag/}).
+@item @b{flashlink}
+@cindex flashlink
+The ST Parallel cable.
+@item @b{arm-jtag}
+@cindex arm-jtag
+Same as original wiggler except SRST and TRST connections reversed and
+TRST is also inverted.
+@item @b{altium}
+@cindex altium
+Altium Universal JTAG cable.
+@end itemize
+@item @b{parport_write_on_exit} <@var{on}|@var{off}>
+@cindex parport_write_on_exit
+@*This will configure the parallel driver to write a known value to the parallel
+interface on exiting OpenOCD
+@end itemize
+
+@subsection amt_jtagaccel options
+@itemize @bullet
+@item @b{parport_port} <@var{number}>
+@cindex parport_port
+@*Either the address of the I/O port (default: 0x378 for LPT1) or the number of the
+@file{/dev/parport} device
+@end itemize
+@subsection ft2232 options
+
+@itemize @bullet
+@item @b{ft2232_device_desc} <@var{description}>
+@cindex ft2232_device_desc
+@*The USB device description of the FTDI FT2232 device. If not
+specified, the FTDI default value is used. This setting is only valid
+if compiled with FTD2XX support.
+
+@b{TODO:} Confirm the following: On Windows the name needs to end with
+a ``space A''? Or not? It has to do with the FTD2xx driver. When must
+this be added and when must it not be added? Why can't the code in the
+interface or in OpenOCD automatically add this if needed? -- Duane.
+
+@item @b{ft2232_serial} <@var{serial-number}>
+@cindex ft2232_serial
+@*The serial number of the FTDI FT2232 device. If not specified, the FTDI default
+values are used.
+@item @b{ft2232_layout} <@var{name}>
+@cindex ft2232_layout
+@*The layout of the FT2232 GPIO signals used to control output-enables and reset
+signals. Valid layouts are
+@itemize @minus
+@item @b{usbjtag}
+"USBJTAG-1" layout described in the original OpenOCD diploma thesis
+@item @b{jtagkey}
+Amontec JTAGkey and JTAGkey-Tiny
+@item @b{signalyzer}
+Signalyzer
+@item @b{olimex-jtag}
+Olimex ARM-USB-OCD
+@item @b{m5960}
+American Microsystems M5960
+@item @b{evb_lm3s811}
+Luminary Micro EVB_LM3S811 as a JTAG interface (not onboard processor), no TRST or
+SRST signals on external connector
+@item @b{comstick}
+Hitex STR9 comstick
+@item @b{stm32stick}
+Hitex STM32 Performance Stick
+@item @b{flyswatter}
+Tin Can Tools Flyswatter
+@item @b{turtelizer2}
+egnite Software turtelizer2
+@item @b{oocdlink}
+OOCDLink
+@item @b{axm0432_jtag}
+Axiom AXM-0432
+@end itemize
+
+@item @b{ft2232_vid_pid} <@var{vid}> <@var{pid}>
+@*The vendor ID and product ID of the FTDI FT2232 device. If not specified, the FTDI
+default values are used. Multiple <@var{vid}>, <@var{pid}> pairs may be given, e.g.
+@example
+ft2232_vid_pid 0x0403 0xcff8 0x15ba 0x0003
+@end example
+@item @b{ft2232_latency} <@var{ms}>
+@*On some systems using FT2232 based JTAG interfaces the FT_Read function call in
+ft2232_read() fails to return the expected number of bytes. This can be caused by
+USB communication delays and has proved hard to reproduce and debug. Setting the
+FT2232 latency timer to a larger value increases delays for short USB packets but it
+also reduces the risk of timeouts before receiving the expected number of bytes.
+The OpenOCD default value is 2 and for some systems a value of 10 has proved useful.
+@end itemize
+
+@subsection ep93xx options
+@cindex ep93xx options
+Currently, there are no options available for the ep93xx interface.
+
+@section JTAG Speed
+@itemize @bullet
+@item @b{jtag_khz} <@var{reset speed kHz}>
+@cindex jtag_khz
+
+It is debatable if this command belongs here - or in a board
+configuration file. In fact, in some situations the JTAG speed is
+changed during the target initialisation process (i.e.: (1) slow at
+reset, (2) program the CPU clocks, (3) run fast)
+
+Speed 0 (khz) selects RTCK method. A non-zero speed is in KHZ. Hence: 3000 is 3mhz.
+
+Not all interfaces support ``rtck''. If the interface device can not
+support the rate asked for, or can not translate from kHz to
+jtag_speed, then an error is returned.
+
+Make sure the JTAG clock is no more than @math{1/6th CPU-Clock}. This is
+especially true for synthesized cores (-S). Also see RTCK.
+
+@b{NOTE: Script writers} If the target chip requires/uses RTCK -
+please use the command: 'jtag_rclk FREQ'. This Tcl proc (in
+startup.tcl) attempts to enable RTCK, if that fails it falls back to
+the specified frequency.
+
+@example
+ # Fall back to 3mhz if RCLK is not supported
+ jtag_rclk 3000
+@end example
+
+@item @b{DEPRECATED} @b{jtag_speed} - please use jtag_khz above.
+@cindex jtag_speed
+@*Limit the maximum speed of the JTAG interface. Usually, a value of zero means maximum
+speed. The actual effect of this option depends on the JTAG interface used.
+
+The speed used during reset can be adjusted using setting jtag_speed during
+pre_reset and post_reset events.
+@itemize @minus
+
+@item wiggler: maximum speed / @var{number}
+@item ft2232: 6MHz / (@var{number}+1)
+@item amt jtagaccel: 8 / 2**@var{number}
+@item jlink: maximum speed in kHz (0-12000), 0 will use RTCK
+@item rlink: 24MHz / @var{number}, but only for certain values of @var{number}
+@comment end speed list.