+@node Running
+@chapter Running
+@cindex running OpenOCD
+@cindex --configfile
+@cindex --debug_level
+@cindex --logfile
+@cindex --search
+
+The @option{--help} option shows:
+@verbatim
+bash$ openocd --help
+
+--help | -h display this help
+--version | -v display OpenOCD version
+--file | -f use configuration file <name>
+--search | -s dir to search for config files and scripts
+--debug | -d set debug level <0-3>
+--log_output | -l redirect log output to file <name>
+--command | -c run <command>
+--pipe | -p use pipes when talking to gdb
+@end verbatim
+
+By default OpenOCD reads the file configuration file ``openocd.cfg''
+in the current directory. To specify a different (or multiple)
+configuration file, you can use the ``-f'' option. For example:
+
+@example
+ openocd -f config1.cfg -f config2.cfg -f config3.cfg
+@end example
+
+Once started, OpenOCD runs as a daemon, waiting for connections from
+clients (Telnet, GDB, Other).
+
+If you are having problems, you can enable internal debug messages via
+the ``-d'' option.
+
+Also it is possible to interleave commands w/config scripts using the
+@option{-c} command line switch.
+
+To enable debug output (when reporting problems or working on OpenOCD
+itself), use the @option{-d} command line switch. This sets the
+@option{debug_level} to "3", outputting the most information,
+including debug messages. The default setting is "2", outputting only
+informational messages, warnings and errors. You can also change this
+setting from within a telnet or gdb session using @option{debug_level
+<n>} @xref{debug_level}.
+
+You can redirect all output from the daemon to a file using the
+@option{-l <logfile>} switch.
+
+Search paths for config/script files can be added to OpenOCD by using
+the @option{-s <search>} switch. The current directory and the OpenOCD
+target library is in the search path by default.
+
+For details on the @option{-p} option. @xref{Connecting to GDB}.
+
+Note! OpenOCD will launch the GDB & telnet server even if it can not
+establish a connection with the target. In general, it is possible for
+the JTAG controller to be unresponsive until the target is set up
+correctly via e.g. GDB monitor commands in a GDB init script.
+
+@node Simple Configuration Files
+@chapter Simple Configuration Files
+@cindex configuration
+
+@section Outline
+There are 4 basic ways of ``configurating'' OpenOCD to run, they are:
+
+@enumerate
+@item A small openocd.cfg file which ``sources'' other configuration files
+@item A monolithic openocd.cfg file
+@item Many -f filename options on the command line
+@item Your Mixed Solution
+@end enumerate
+
+@section Small configuration file method
+
+This is the preferred method. It is simple and works well for many
+people. The developers of OpenOCD would encourage you to use this
+method. If you create a new configuration please email new
+configurations to the development list.
+
+Here is an example of an openocd.cfg file for an ATMEL at91sam7x256
+
+@example
+source [find interface/signalyzer.cfg]
+
+# Change the default telnet port...
+telnet_port 4444
+# GDB connects here
+gdb_port 3333
+# GDB can also flash my flash!
+gdb_memory_map enable
+gdb_flash_program enable
+
+source [find target/sam7x256.cfg]
+@end example
+
+There are many example configuration scripts you can work with. You
+should look in the directory: @t{$(INSTALLDIR)/lib/openocd}. You
+should find:
+
+@enumerate
+@item @b{board} - eval board level configurations
+@item @b{interface} - specific dongle configurations
+@item @b{target} - the target chips
+@item @b{tcl} - helper scripts
+@item @b{xscale} - things specific to the xscale.
+@end enumerate
+
+Look first in the ``boards'' area, then the ``targets'' area. Often a board
+configuration is a good example to work from.
+
+@section Many -f filename options
+Some believe this is a wonderful solution, others find it painful.
+
+You can use a series of ``-f filename'' options on the command line,
+OpenOCD will read each filename in sequence, for example:
+
+@example
+ openocd -f file1.cfg -f file2.cfg -f file2.cfg
+@end example
+
+You can also intermix various commands with the ``-c'' command line
+option.
+
+@section Monolithic file
+The ``Monolithic File'' dispenses with all ``source'' statements and
+puts everything in one self contained (monolithic) file. This is not
+encouraged.
+
+Please try to ``source'' various files or use the multiple -f
+technique.
+
+@section Advice for you
+Often, one uses a ``mixed approach''. Where possible, please try to
+``source'' common things, and if needed cut/paste parts of the
+standard distribution configuration files as needed.
+
+@b{REMEMBER:} The ``important parts'' of your configuration file are:
+
+@enumerate
+@item @b{Interface} - Defines the dongle
+@item @b{Taps} - Defines the JTAG Taps
+@item @b{GDB Targets} - What GDB talks to
+@item @b{Flash Programing} - Very Helpful
+@end enumerate
+
+Some key things you should look at and understand are:
+
+@enumerate
+@item The reset configuration of your debug environment as a whole
+@item Is there a ``work area'' that OpenOCD can use?
+@* For ARM - work areas mean up to 10x faster downloads.
+@item For MMU/MPU based ARM chips (i.e.: ARM9 and later) will that work area still be available?
+@item For complex targets (multiple chips) the JTAG SPEED becomes an issue.
+@end enumerate
+
+
+
+@node Config File Guidelines
+@chapter Config File Guidelines
+
+This section/chapter is aimed at developers and integrators of
+OpenOCD. These are guidelines for creating new boards and new target
+configurations as of 28/Nov/2008.
+
+However, you, the user of OpenOCD, should be somewhat familiar with
+this section as it should help explain some of the internals of what
+you might be looking at.
+
+The user should find the following directories under @t{$(INSTALLDIR)/lib/openocd} :
+
+@itemize @bullet
+@item @b{interface}
+@*Think JTAG Dongle. Files that configure the JTAG dongle go here.
+@item @b{board}
+@* Think Circuit Board, PWA, PCB, they go by many names. Board files
+contain initialization items that are specific to a board - for
+example: The SDRAM initialization sequence for the board, or the type
+of external flash and what address it is found at. Any initialization
+sequence to enable that external flash or SDRAM should be found in the
+board file. Boards may also contain multiple targets, i.e.: Two CPUs, or
+a CPU and an FPGA or CPLD.
+@item @b{target}
+@* Think chip. The ``target'' directory represents a JTAG tap (or
+chip) OpenOCD should control, not a board. Two common types of targets
+are ARM chips and FPGA or CPLD chips.
+@end itemize
+
+@b{If needed...} The user in their ``openocd.cfg'' file or the board
+file might override a specific feature in any of the above files by
+setting a variable or two before sourcing the target file. Or adding
+various commands specific to their situation.
+
+@section Interface Config Files
+
+The user should be able to source one of these files via a command like this:
+
+@example
+ source [find interface/FOOBAR.cfg]
+Or:
+ openocd -f interface/FOOBAR.cfg
+@end example
+
+A preconfigured interface file should exist for every interface in use
+today, that said, perhaps some interfaces have only been used by the
+sole developer who created it.
+
+@b{FIXME/NOTE:} We need to add support for a variable like Tcl variable
+tcl_platform(platform), it should be called jim_platform (because it
+is jim, not real tcl) and it should contain 1 of 3 words: ``linux'',
+``cygwin'' or ``mingw''
+
+Interface files should be found in @t{$(INSTALLDIR)/lib/openocd/interface}
+
+@section Board Config Files
+
+@b{Note: BOARD directory NEW as of 28/nov/2008}
+
+The user should be able to source one of these files via a command like this:
+
+@example
+ source [find board/FOOBAR.cfg]
+Or:
+ openocd -f board/FOOBAR.cfg
+@end example
+
+
+The board file should contain one or more @t{source [find
+target/FOO.cfg]} statements along with any board specific things.
+
+In summary the board files should contain (if present)
+
+@enumerate
+@item External flash configuration (i.e.: the flash on CS0)
+@item SDRAM configuration (size, speed, etc.
+@item Board specific IO configuration (i.e.: GPIO pins might disable a 2nd flash)
+@item Multiple TARGET source statements
+@item All things that are not ``inside a chip''
+@item Things inside a chip go in a 'target' file
+@end enumerate
+
+@section Target Config Files
+
+The user should be able to source one of these files via a command like this:
+
+@example
+ source [find target/FOOBAR.cfg]
+Or:
+ openocd -f target/FOOBAR.cfg
+@end example
+
+In summary the target files should contain
+
+@enumerate
+@item Set defaults
+@item Create taps
+@item Reset configuration
+@item Work areas
+@item CPU/Chip/CPU-Core specific features
+@item On-Chip flash
+@end enumerate
+
+@subsection Important variable names
+
+By default, the end user should never need to set these
+variables. However, if the user needs to override a setting they only
+need to set the variable in a simple way.
+
+@itemize @bullet
+@item @b{CHIPNAME}
+@* This gives a name to the overall chip, and is used as part of the
+tap identifier dotted name.
+@item @b{ENDIAN}
+@* By default little - unless the chip or board is not normally used that way.
+@item @b{CPUTAPID}
+@* When OpenOCD examines the JTAG chain, it will attempt to identify
+every chip. If the @t{-expected-id} is nonzero, OpenOCD attempts
+to verify the tap id number verses configuration file and may issue an
+error or warning like this. The hope is that this will help to pinpoint
+problems in OpenOCD configurations.
+
+@example
+Info: JTAG tap: sam7x256.cpu tap/device found: 0x3f0f0f0f (Manufacturer: 0x787, Part: 0xf0f0, Version: 0x3)
+Error: ERROR: Tap: sam7x256.cpu - Expected id: 0x12345678, Got: 0x3f0f0f0f
+Error: ERROR: expected: mfg: 0x33c, part: 0x2345, ver: 0x1
+Error: ERROR: got: mfg: 0x787, part: 0xf0f0, ver: 0x3
+@end example
+
+@item @b{_TARGETNAME}
+@* By convention, this variable is created by the target configuration
+script. The board configuration file may make use of this variable to
+configure things like a ``reset init'' script, or other things
+specific to that board and that target.
+
+If the chip has 2 targets, use the names @b{_TARGETNAME0},
+@b{_TARGETNAME1}, ... etc.
+
+@b{Remember:} The ``board file'' may include multiple targets.
+
+At no time should the name ``target0'' (the default target name if
+none was specified) be used. The name ``target0'' is a hard coded name
+- the next target on the board will be some other number.
+In the same way, avoid using target numbers even when they are
+permitted; use the right target name(s) for your board.
+
+The user (or board file) should reasonably be able to:
+
+@example
+ source [find target/FOO.cfg]
+ $_TARGETNAME configure ... FOO specific parameters
+
+ source [find target/BAR.cfg]
+ $_TARGETNAME configure ... BAR specific parameters
+@end example
+
+@end itemize
+
+@subsection Tcl Variables Guide Line
+The Full Tcl/Tk language supports ``namespaces'' - JIM-Tcl does not.
+
+Thus the rule we follow in OpenOCD is this: Variables that begin with
+a leading underscore are temporary in nature, and can be modified and
+used at will within a ?TARGET? configuration file.
+
+@b{EXAMPLE:} The user should be able to do this:
+
+@example
+ # Board has 3 chips,
+ # PXA270 #1 network side, big endian
+ # PXA270 #2 video side, little endian
+ # Xilinx Glue logic
+ set CHIPNAME network
+ set ENDIAN big
+ source [find target/pxa270.cfg]
+ # variable: _TARGETNAME = network.cpu
+ # other commands can refer to the "network.cpu" tap.
+ $_TARGETNAME configure .... params for this CPU..
+
+ set ENDIAN little
+ set CHIPNAME video
+ source [find target/pxa270.cfg]
+ # variable: _TARGETNAME = video.cpu
+ # other commands can refer to the "video.cpu" tap.
+ $_TARGETNAME configure .... params for this CPU..
+
+ unset ENDIAN
+ set CHIPNAME xilinx
+ source [find target/spartan3.cfg]
+
+ # Since $_TARGETNAME is temporal..
+ # these names still work!
+ network.cpu configure ... params
+ video.cpu configure ... params
+
+@end example
+
+@subsection Default Value Boiler Plate Code
+
+All target configuration files should start with this (or a modified form)
+
+@example
+# SIMPLE example
+if @{ [info exists CHIPNAME] @} @{
+ set _CHIPNAME $CHIPNAME
+@} else @{
+ set _CHIPNAME sam7x256
+@}
+
+if @{ [info exists ENDIAN] @} @{
+ set _ENDIAN $ENDIAN
+@} else @{
+ set _ENDIAN little
+@}
+
+if @{ [info exists CPUTAPID ] @} @{
+ set _CPUTAPID $CPUTAPID
+@} else @{
+ set _CPUTAPID 0x3f0f0f0f
+@}
+
+@end example
+
+@subsection Creating Taps
+After the ``defaults'' are choosen [see above] the taps are created.
+
+@b{SIMPLE example:} such as an Atmel AT91SAM7X256
+
+@example
+# for an ARM7TDMI.
+set _TARGETNAME [format "%s.cpu" $_CHIPNAME]
+jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID
+@end example
+
+@b{COMPLEX example:}
+
+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{etb}
+@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.
+
+Some ARM cores are equipped with trace support, which permits
+examination of the instruction and data bus activity. Trace
+activity is controlled through an ``Embedded Trace Module'' (ETM)
+on one of the core's scan chains. The ETM emits voluminous data
+through a ``trace port''. The trace port is accessed in one
+of two ways. When its signals are pinned out from the chip,
+boards may provide a special high speed debugging connector;
+software support for this is not configured by default, use
+the ``--enable-oocd_trace'' option. Alternatively, trace data
+may be stored an on-chip SRAM which is packaged as an ``Embedded
+Trace Buffer'' (ETB). An ETB has its own TAP, usually right after
+its associated ARM core. OpenOCD supports the ETM, and your
+target configuration should set it up with the relevant trace
+port: ``etb'' for chips which use that, else the board-specific
+option will be either ``oocd_trace'' or ``dummy''.
+
+@example
+etm config $_TARGETNAME 16 normal full etb
+etb config $_TARGETNAME $_CHIPNAME.etb
+@end example
+
+@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}>