+@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.
+@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, eg.
+@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 packages 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 initialization process (ie: (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{DEPRICATED} @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.
+@end itemize
+
+@comment END command list
+@end itemize
+
+@node Reset Configuration
+@chapter Reset Configuration
+@cindex reset configuration
+
+Every system configuration may require a different reset
+configuration. This can also be quite confusing. Please see the
+various board files for example.
+
+@section jtag_nsrst_delay <@var{ms}>
+@cindex jtag_nsrst_delay
+@*How long (in milliseconds) OpenOCD should wait after deasserting
+nSRST before starting new JTAG operations.
+
+@section jtag_ntrst_delay <@var{ms}>
+@cindex jtag_ntrst_delay
+@*Same @b{jtag_nsrst_delay}, but for nTRST
+
+The jtag_n[st]rst_delay options are useful if reset circuitry (like a
+big resistor/capacitor, reset supervisor, or on-chip features). This
+keeps the signal asserted for some time after the external reset got
+deasserted.
+
+@section reset_config
+
+@b{Note:} To maintainer types and integrators. Where exactly the
+``reset configuration'' goes is a good question. It touches several
+things at once. In the end, if you have a board file - the board file
+should define it and assume 100% that the DONGLE supports
+anything. However, that does not mean the target should not also make
+not of something the silicon vendor has done inside the
+chip. @i{Grr.... nothing is every pretty.}
+
+@* @b{Problems:}
+@enumerate
+@item Every JTAG Dongle is slightly different, some dongles impliment reset differently.
+@item Every board is also slightly different; some boards tie TRST and SRST together.
+@item Every chip is slightly different; some chips internally tie the two signals together.
+@item Some may not impliment all of the signals the same way.
+@item Some signals might be push-pull, others open-drain/collector.
+@end enumerate
+@b{Best Case:} OpenOCD can hold the SRST (push-button-reset), then
+reset the TAP via TRST and send commands through the JTAG tap to halt
+the CPU at the reset vector before the 1st instruction is executed,
+and finally release the SRST signal.
+@*Depending upon your board vendor, your chip vendor, etc, these
+signals may have slightly different names.
+
+OpenOCD defines these signals in these terms:
+@itemize @bullet
+@item @b{TRST} - is Tap Reset - and should reset only the TAP.
+@item @b{SRST} - is System Reset - typically equal to a reset push button.
+@end itemize
+
+The Command:
+
+@itemize @bullet
+@item @b{reset_config} <@var{signals}> [@var{combination}] [@var{trst_type}] [@var{srst_type}]
+@cindex reset_config
+@* The @t{reset_config} command tells OpenOCD the reset configuration
+of your combination of Dongle, Board, and Chips.
+If the JTAG interface provides SRST, but the target doesn't connect
+that signal properly, then OpenOCD can't use it. <@var{signals}> can
+be @option{none}, @option{trst_only}, @option{srst_only} or
+@option{trst_and_srst}.
+
+[@var{combination}] is an optional value specifying broken reset
+signal implementations. @option{srst_pulls_trst} states that the
+testlogic is reset together with the reset of the system (e.g. Philips
+LPC2000, "broken" board layout), @option{trst_pulls_srst} says that
+the system is reset together with the test logic (only hypothetical, I
+haven't seen hardware with such a bug, and can be worked around).
+@option{combined} imples both @option{srst_pulls_trst} and
+@option{trst_pulls_srst}. The default behaviour if no option given is
+@option{separate}.
+
+The [@var{trst_type}] and [@var{srst_type}] parameters allow the
+driver type of the reset lines to be specified. Possible values are
+@option{trst_push_pull} (default) and @option{trst_open_drain} for the
+test reset signal, and @option{srst_open_drain} (default) and
+@option{srst_push_pull} for the system reset. These values only affect
+JTAG interfaces with support for different drivers, like the Amontec
+JTAGkey and JTAGAccelerator.
+
+@comment - end command
+@end itemize
+
+
+
+@node Tap Creation
+@chapter Tap Creation
+@cindex tap creation
+@cindex tap configuration
+
+In order for OpenOCD to control a target, a JTAG tap must be
+defined/created.
+
+Commands to create taps are normally found in a configuration file and
+are not normally typed by a human.
+
+When a tap is created a @b{dotted.name} is created for the tap. Other
+commands use that dotted.name to manipulate or refer to the tap.
+
+Tap Uses:
+@itemize @bullet
+@item @b{Debug Target} A tap can be used by a GDB debug target
+@item @b{Flash Programing} Some chips program the flash via JTAG
+@item @b{Boundry Scan} Some chips support boundry scan.
+@end itemize
+
+
+@section jtag newtap
+@b{@t{jtag newtap CHIPNAME TAPNAME configparams ....}}
+@cindex jtag_device
+@cindex jtag newtap
+@cindex tap
+@cindex tap order
+@cindex tap geometry
+
+@comment START options
+@itemize @bullet
+@item @b{CHIPNAME}
+@* is a symbolic name of the chip.
+@item @b{TAPNAME}
+@* is a symbol name of a tap present on the chip.
+@item @b{Required configparams}
+@* Every tap has 3 required configparams, and several ``optional
+parameters'', the required parameters are:
+@comment START REQUIRED
+@itemize @bullet
+@item @b{-irlen NUMBER} - the length in bits of the instruction register
+@item @b{-ircapture NUMBER} - the ID code capture command.
+@item @b{-irmask NUMBER} - the corresponding mask for the ir register.
+@comment END REQUIRED
+@end itemize
+An example of a FOOBAR Tap
+@example
+jtag newtap foobar tap -irlen 7 -ircapture 0x42 -irmask 0x55
+@end example
+Creates the tap ``foobar.tap'' with the instruction register (IR) is 7
+bits long, during Capture-IR 0x42 is loaded into the IR, and bits
+[6,4,2,0] are checked.
+
+@item @b{Optional configparams}
+@comment START Optional
+@itemize @bullet
+@item @b{-expected-id NUMBER}
+@* By default it is zero. If non-zero represents the
+expected tap ID used when the Jtag Chain is examined. See below.
+@item @b{-disable}
+@item @b{-enable}
+@* By default not specified the tap is enabled. Some chips have a
+jtag route controller (JRC) that is used to enable and/or disable
+specific jtag taps. You can later enable or disable any JTAG tap via
+the command @b{jtag tapenable DOTTED.NAME} or @b{jtag tapdisable
+DOTTED.NAME}
+@comment END Optional
+@end itemize
+
+@comment END OPTIONS
+@end itemize
+@b{Notes:}
+@comment START NOTES
+@itemize @bullet
+@item @b{Technically}
+@* newtap is a sub command of the ``jtag'' command
+@item @b{Big Picture Background}
+@*GDB Talks to OpenOCD using the GDB protocol via
+tcpip. OpenOCD then uses the JTAG interface (the dongle) to
+control the JTAG chain on your board. Your board has one or more chips
+in a @i{daisy chain configuration}. Each chip may have one or more
+jtag taps. GDB ends up talking via OpenOCD to one of the taps.
+@item @b{NAME Rules}
+@*Names follow ``C'' symbol name rules (start with alpha ...)
+@item @b{TAPNAME - Conventions}
+@itemize @bullet
+@item @b{tap} - should be used only FPGA or CPLD like devices with a single tap.
+@item @b{cpu} - the main cpu of the chip, alternatively @b{foo.arm} and @b{foo.dsp}
+@item @b{flash} - if the chip has a flash tap, example: str912.flash
+@item @b{bs} - for boundary scan if this is a seperate tap.
+@item @b{jrc} - for jtag route controller (example: OMAP3530 found on Beagleboards)
+@item @b{unknownN} - where N is a number if you have no idea what the tap is for
+@item @b{Other names} - Freescale IMX31 has a SDMA (smart dma) with a JTAG tap, that tap should be called the ``sdma'' tap.
+@item @b{When in doubt} - use the chip makers name in their data sheet.
+@end itemize
+@item @b{DOTTED.NAME}
+@* @b{CHIPNAME}.@b{TAPNAME} creates the tap name, aka: the
+@b{Dotted.Name} is the @b{CHIPNAME} and @b{TAPNAME} combined with a
+dot (period); for example: @b{xilinx.tap}, @b{str912.flash},
+@b{omap3530.jrc}, or @b{stm32.cpu} The @b{dotted.name} is used in
+numerous other places to refer to various taps.
+@item @b{ORDER}
+@* The order this command appears via the config files is
+important.
+@item @b{Multi Tap Example}
+@* This example is based on the ST Microsystems STR912. See the ST
+document titled: @b{STR91xFAxxx, Section 3.15 Jtag Interface, Page:
+28/102, Figure 3: Jtag chaining inside the STR91xFA}.
+
+@url{http://eu.st.com/stonline/products/literature/ds/13495.pdf}
+@*@b{checked: 28/nov/2008}
+
+The diagram shows the TDO pin connects to the flash tap, flash TDI
+connects to the CPU debug tap, CPU TDI connects to the boundary scan
+tap which then connects to the TDI pin.
+
+@example
+ # The order is...
+ # create tap: 'str912.flash'
+ jtag newtap str912 flash ... params ...
+ # create tap: 'str912.cpu'
+ jtag newtap str912 cpu ... params ...
+ # create tap: 'str912.bs'
+ jtag newtap str912 bs ... params ...
+@end example
+
+@item @b{Note: Deprecated} - Index Numbers
+@* Prior to 28/nov/2008, JTAG taps where numbered from 0..N this
+feature is still present, however its use is highly discouraged and
+should not be counted upon.
+@item @b{Multiple chips}
+@* If your board has multiple chips, you should be
+able to @b{source} two configuration files, in the proper order, and
+have the taps created in the proper order.
+@comment END NOTES
+@end itemize
+@comment at command level
+@comment DOCUMENT old command
+@section jtag_device - REMOVED
+@example
+@b{jtag_device} <@var{IR length}> <@var{IR capture}> <@var{IR mask}> <@var{IDCODE instruction}>
+@end example
+@cindex jtag_device
+
+@* @b{Removed: 28/nov/2008} This command has been removed and replaced
+by the ``jtag newtap'' command. The documentation remains here so that
+one can easily convert the old syntax to the new syntax. About the old
+syntax: The old syntax is positional, ie: The 3rd parameter is the
+``irmask''. The new syntax requires named prefixes, and supports
+additional options, for example ``-expected-id 0x3f0f0f0f''. Please refer to the
+@b{jtag newtap} command for details.
+@example
+OLD: jtag_device 8 0x01 0xe3 0xfe
+NEW: jtag newtap CHIPNAME TAPNAME -irlen 8 -ircapture 0x01 -irmask 0xe3
+@end example
+
+@section Enable/Disable Taps
+@b{Note:} These commands are intended to be used as a machine/script
+interface. Humans might find the ``scan_chain'' command more helpful
+when querying the state of the JTAG taps.
+
+@b{By default, all taps are enabled}
+
+@itemize @bullet
+@item @b{jtag tapenable} @var{DOTTED.NAME}
+@item @b{jtag tapdisable} @var{DOTTED.NAME}
+@item @b{jtag tapisenabled} @var{DOTTED.NAME}
+@end itemize
+@cindex tap enable
+@cindex tap disable
+@cindex JRC
+@cindex route controller
+
+These commands are used when your target has a JTAG Route controller
+that effectively adds or removes a tap from the jtag chain in a
+non-standard way.
+
+The ``standard way'' to remove a tap would be to place the tap in
+bypass mode. But with the advent of modern chips, this is not always a
+good solution. Some taps operate slowly, others operate fast, and
+there are other JTAG clock syncronization problems one must face. To
+solve that problem, the JTAG Route controller was introduced. Rather
+then ``bypass'' the tap, the tap is completely removed from the
+circuit and skipped.
+
+
+From OpenOCD's view point, a JTAG TAP is in one of 3 states:
+
+@itemize @bullet
+@item @b{Enabled - Not In ByPass} and has a variable bit length
+@item @b{Enabled - In ByPass} and has a length of exactly 1 bit.
+@item @b{Disabled} and has a length of ZERO and is removed from the circuit.
+@end itemize
+
+The IEEE JTAG definition has no concept of a ``disabled'' tap.
+@b{Historical note:} this feature was added 28/nov/2008
+
+@b{jtag tapisenabled DOTTED.NAME}
+
+This command returns 1 if the named tap is currently enabled, 0 if not.
+This command exists so that scripts that manipulate a JRC (like the
+Omap3530 has) can determine if OpenOCD thinks a tap is presently
+enabled, or disabled.
+
+@page
+@node Target Configuration
+@chapter Target Configuration
+
+This chapter discusses how to create a GDB Debug Target. Before
+creating a ``target'' a JTAG Tap DOTTED.NAME must exist first.
+
+@section targets [NAME]
+@b{Note:} This command name is PLURAL - not singular.
+
+With NO parameter, this plural @b{targets} command lists all known
+targets in a human friendly form.
+
+With a parameter, this pural @b{targets} command sets the current
+target to the given name. (ie: If there are multiple debug targets)
+
+Example:
+@verbatim
+(gdb) mon targets
+ CmdName Type Endian ChainPos State
+-- ---------- ---------- ---------- -------- ----------
+ 0: target0 arm7tdmi little 0 halted
+@end verbatim
+
+@section target COMMANDS
+@b{Note:} This command name is SINGULAR - not plural. It is used to
+manipulate specific targets, to create targets and other things.
+
+Once a target is created, a TARGETNAME (object) command is created;
+see below for details.
+
+The TARGET command accepts these sub-commands:
+@itemize @bullet
+@item @b{create} .. parameters ..
+@* creates a new target, See below for details.
+@item @b{types}
+@* Lists all supported target types (perhaps some are not yet in this document).
+@item @b{names}
+@* Lists all current debug target names, for example: 'str912.cpu' or 'pxa27.cpu' example usage:
+@verbatim
+ foreach t [target names] {
+ puts [format "Target: %s\n" $t]
+ }
+@end verbatim
+@item @b{current}
+@* Returns the current target. OpenOCD always has, or refers to the ``current target'' in some way.
+By default, commands like: ``mww'' (used to write memory) operate on the current target.
+@item @b{number} @b{NUMBER}
+@* Internally OpenOCD maintains a list of targets - in numerical index
+(0..N-1) this command returns the name of the target at index N.
+Example usage:
+@verbatim
+ set thename [target number $x]
+ puts [format "Target %d is: %s\n" $x $thename]
+@end verbatim
+@item @b{count}
+@* Returns the number of targets known to OpenOCD (see number above)
+Example:
+@verbatim
+ set c [target count]
+ for { set x 0 } { $x < $c } { incr x } {
+ # Assuming you have created this function
+ print_target_details $x
+ }
+@end verbatim
+
+@end itemize
+
+@section TARGETNAME (object) commands
+@b{Use:} Once a target is created, an ``object name'' that represents the
+target is created. By convention, the target name is identical to the
+tap name. In a multiple target system, one can preceed many common
+commands with a specific target name and effect only that target.
+@example
+ str912.cpu mww 0x1234 0x42
+ omap3530.cpu mww 0x5555 123
+@end example
+
+@b{Model:} The Tcl/Tk language has the concept of object commands. A
+good example is a on screen button, once a button is created a button
+has a name (a path in TK terms) and that name is useable as a 1st
+class command. For example in TK, one can create a button and later
+configure it like this:
+
+@example
+ # Create
+ button .foobar -background red -command @{ foo @}
+ # Modify
+ .foobar configure -foreground blue
+ # Query
+ set x [.foobar cget -background]
+ # Report
+ puts [format "The button is %s" $x]
+@end example
+
+In OpenOCD's terms, the ``target'' is an object just like a Tcl/Tk
+button. Commands avaialble as a ``target object'' are:
+
+@comment START targetobj commands.
+@itemize @bullet
+@item @b{configure} - configure the target; see Target Config/Cget Options below
+@item @b{cget} - query the target configuration; see Target Config/Cget Options below
+@item @b{curstate} - current target state (running, halt, etc)
+@item @b{eventlist}
+@* Intended for a human to see/read the currently configure target events.
+@item @b{Various Memory Commands} See the ``mww'' command elsewhere.
+@comment start memory
+@itemize @bullet
+@item @b{mww} ...
+@item @b{mwh} ...
+@item @b{mwb} ...
+@item @b{mdw} ...
+@item @b{mdh} ...
+@item @b{mdb} ...
+@comment end memory
+@end itemize
+@item @b{Memory To Array, Array To Memory}
+@* These are aimed at a machine interface to memory
+@itemize @bullet
+@item @b{mem2array ARRAYNAME WIDTH ADDRESS COUNT}
+@item @b{array2mem ARRAYNAME WIDTH ADDRESS COUNT}
+@* Where:
+@* @b{ARRAYNAME} is the name of an array variable
+@* @b{WIDTH} is 8/16/32 - indicating the memory access size
+@* @b{ADDRESS} is the target memory address
+@* @b{COUNT} is the number of elements to process
+@end itemize
+@item @b{Used during ``reset''}
+@* These commands are used internally by the OpenOCD scripts to deal
+with odd reset situations and are not documented here.
+@itemize @bullet
+@item @b{arp_examine}
+@item @b{arp_poll}
+@item @b{arp_reset}
+@item @b{arp_halt}
+@item @b{arp_waitstate}
+@end itemize
+@item @b{invoke-event} @b{EVENT-NAME}
+@* Invokes the specific event manually for the target
+@end itemize
+
+@section Target Events
+At various times, certain things can happen, or you want them to happen.
+
+Examples:
+@itemize @bullet
+@item What should happen when GDB connects? Should your target reset?
+@item When GDB tries to flash the target, do you need to enable the flash via a special command?
+@item During reset, do you need to write to certain memory location to reconfigure the SDRAM?
+@end itemize
+
+All of the above items are handled by target events.
+
+To specify an event action, either during target creation, or later
+via ``$_TARGETNAME configure'' see this example.
+
+Syntactially, the option is: ``-event NAME BODY'' where NAME is a
+target event name, and BODY is a tcl procedure or string of commands
+to execute.
+
+The programmers model is the ``-command'' option used in Tcl/Tk
+buttons and events. Below are two identical examples, the first
+creates and invokes small procedure. The second inlines the procedure.
+
+@example
+ proc my_attach_proc @{ @} @{
+ puts "RESET...."
+ reset halt
+ @}
+ mychip.cpu configure -event gdb-attach my_attach_proc
+ mychip.cpu configure -event gdb-attach @{ puts "Reset..." ; reset halt @}
+@end example
+
+@section Current Events
+The following events are available:
+@itemize @bullet
+@item @b{debug-halted}
+@* The target has halted for debug reasons (ie: breakpoint)
+@item @b{debug-resumed}
+@* The target has resumed (ie: gdb said run)
+@item @b{early-halted}
+@* Occurs early in the halt process
+@item @b{examine-end}
+@* Currently not used (goal: when JTAG examine completes)
+@item @b{examine-start}
+@* Currently not used (goal: when JTAG examine starts)
+@item @b{gdb-attach}
+@* When GDB connects
+@item @b{gdb-detach}
+@* When GDB disconnects
+@item @b{gdb-end}
+@* When the taret has halted and GDB is not doing anything (see early halt)
+@item @b{gdb-flash-erase-start}
+@* Before the GDB flash process tries to erase the flash
+@item @b{gdb-flash-erase-end}
+@* After the GDB flash process has finished erasing the flash
+@item @b{gdb-flash-write-start}
+@* Before GDB writes to the flash
+@item @b{gdb-flash-write-end}
+@* After GDB writes to the flash
+@item @b{gdb-start}
+@* Before the taret steps, gdb is trying to start/resume the tarfget
+@item @b{halted}
+@* The target has halted
+@item @b{old-gdb_program_config}
+@* DO NOT USE THIS: Used internally
+@item @b{old-pre_resume}
+@* DO NOT USE THIS: Used internally
+@item @b{reset-assert-pre}
+@* Before reset is asserted on the tap.
+@item @b{reset-assert-post}
+@* Reset is now asserted on the tap.
+@item @b{reset-deassert-pre}
+@* Reset is about to be released on the tap
+@item @b{reset-deassert-post}
+@* Reset has been released on the tap
+@item @b{reset-end}
+@* Currently not used.
+@item @b{reset-halt-post}
+@* Currently not usd
+@item @b{reset-halt-pre}
+@* Currently not used
+@item @b{reset-init}
+@* Currently not used
+@item @b{reset-start}
+@* Currently not used
+@item @b{reset-wait-pos}
+@* Currently not used
+@item @b{reset-wait-pre}
+@* Currently not used
+@item @b{resume-start}
+@* Before any target is resumed
+@item @b{resume-end}
+@* After all targets have resumed
+@item @b{resume-ok}
+@* Success
+@item @b{resumed}
+@* Target has resumed
+@item @b{tap-enable}
+@* Executed by @b{jtag tapenable DOTTED.NAME} command. Example:
+@example
+jtag configure DOTTED.NAME -event tap-enable @{
+ puts "Enabling CPU"
+ ...
+@}
+@end example
+@item @b{tap-disable}
+@*Executed by @b{jtag tapdisable DOTTED.NAME} command. Example:
+@example
+jtag configure DOTTED.NAME -event tap-disable @{
+ puts "Disabling CPU"
+ ...
+@}
+@end example
+@end itemize
+
+
+@section target create
+@cindex target
+@cindex target creation
+
+@example
+@b{target} @b{create} <@var{NAME}> <@var{TYPE}> <@var{PARAMS ...}>
+@end example
+@*This command creates a GDB debug target that refers to a specific JTAG tap.
+@comment START params
+@itemize @bullet
+@item @b{NAME}
+@* Is the name of the debug target. By convention it should be the tap
+DOTTED.NAME, this name is also used to create the target object
+command.
+@item @b{TYPE}
+@* Specifies the target type, ie: arm7tdmi, or cortexM3. Currently supported targes are:
+@comment START types
+@itemize @minus
+@item @b{arm7tdmi}
+@item @b{arm720t}
+@item @b{arm9tdmi}
+@item @b{arm920t}
+@item @b{arm922t}
+@item @b{arm926ejs}
+@item @b{arm966e}
+@item @b{cortex_m3}
+@item @b{feroceon}
+@item @b{xscale}
+@item @b{arm11}
+@item @b{mips_m4k}
+@comment end TYPES
+@end itemize
+@item @b{PARAMS}
+@*PARAMs are various target configure parameters, the following are mandatory
+at configuration:
+@comment START mandatory
+@itemize @bullet
+@item @b{-endian big|little}
+@item @b{-chain-position DOTTED.NAME}
+@comment end MANDATORY
+@end itemize
+@comment END params
+@end itemize
+
+@section Target Config/Cget Options
+These options can be specified when the target is created, or later
+via the configure option or to query the target via cget.
+@itemize @bullet
+@item @b{-type} - returns the target type
+@item @b{-event NAME BODY} see Target events
+@item @b{-work-area-virt [ADDRESS]} specify/set the work area
+@item @b{-work-area-phys [ADDRESS]} specify/set the work area
+@item @b{-work-area-size [ADDRESS]} specify/set the work area
+@item @b{-work-area-backup [0|1]} does the work area get backed up
+@item @b{-endian [big|little]}
+@item @b{-variant [NAME]} some chips have varients OpenOCD needs to know about
+@item @b{-chain-position DOTTED.NAME} the tap name this target refers to.
+@end itemize
+Example:
+@example
+ for @{ set x 0 @} @{ $x < [target count] @} @{ incr x @} @{
+ set name [target number $x]
+ set y [$name cget -endian]
+ set z [$name cget -type]
+ puts [format "Chip %d is %s, Endian: %s, type: %s" $x $y $z]
+ @}
+@end example
+
+@section Target Varients
+@itemize @bullet
+@item @b{arm7tdmi}
+@* Unknown (please write me)
+@item @b{arm720t}
+@* Unknown (please write me) (simular to arm7tdmi)
+@item @b{arm9tdmi}
+@* Varients: @option{arm920t}, @option{arm922t} and @option{arm940t}
+This enables the hardware single-stepping support found on these
+cores.
+@item @b{arm920t}
+@* None.
+@item @b{arm966e}
+@* None (this is also used as the ARM946)
+@item @b{cortex_m3}
+@* use variant <@var{-variant lm3s}> when debugging luminary lm3s targets. This will cause
+OpenOCD to use a software reset rather than asserting 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.
+@item @b{xscale}
+@* Supported variants are @option{ixp42x}, @option{ixp45x}, @option{ixp46x},@option{pxa250}, @option{pxa255}, @option{pxa26x}.
+@item @b{arm11}
+@* Supported variants are @option{arm1136}, @option{arm1156}, @option{arm1176}
+@item @b{mips_m4k}
+@* Use variant @option{ejtag_srst} when debugging targets that do not
+provide a functional SRST line on the EJTAG connector. This causes
+OpenOCD to instead use an EJTAG software reset command to reset the
+processor. You still need to enable @option{srst} on the reset
+configuration command to enable OpenOCD hardware reset functionality.
+@comment END varients
+@end itemize
+@section working_area - Command Removed
+@cindex working_area
+@*@b{Please use the ``$_TARGETNAME configure -work-area-... parameters instead}
+@* This documentation remains because there are existing scripts that
+still use this that need to be converted.
+@example
+ working_area target# address size backup| [virtualaddress]
+@end example
+@* The target# is a the 0 based target numerical index.
+
+This command specifies a working area for the debugger to use. This
+may be used to speed-up downloads to target memory and flash
+operations, or to perform otherwise unavailable operations (some
+coprocessor operations on ARM7/9 systems, for example). The last
+parameter decides whether the memory should be preserved
+(<@var{backup}>) or can simply be overwritten (<@var{nobackup}>). If
+possible, use a working_area that doesn't need to be backed up, as
+performing a backup slows down operation.
+
+@node Flash Configuration
+@chapter Flash Programing
+@cindex Flash Configuration
+
+@b{Note:} As of 28/nov/2008 OpenOCD does not know how to program a SPI
+flash that a micro may boot from. Perhaps you the reader would like to
+contribute support for this.
+
+Flash Steps:
+@enumerate
+@item Configure via the command @b{flash bank}
+@* Normally this is done in a configuration file.
+@item Operate on the flash via @b{flash SOMECOMMAND}
+@* Often commands to manipulate the flash are typed by a human, or run
+via a script in some automated way. For example: To program the boot
+flash on your board.
+@item GDB Flashing
+@* Flashing via GDB requires the flash be configured via ``flash
+bank'', and the GDB flash features be enabled. See the Daemon
+configuration section for more details.
+@end enumerate
+
+@section Flash commands
+@cindex Flash commands
+@subsection flash banks
+@b{flash banks}
+@cindex flash banks
+@*List configured flash banks
+@*@b{NOTE:} the singular form: 'flash bank' is used to configure the flash banks.
+@subsection flash info
+@b{flash info} <@var{num}>
+@cindex flash info
+@*Print info about flash bank <@option{num}>
+@subsection flash probe
+@b{flash probe} <@var{num}>
+@cindex flash probe
+@*Identify the flash, or validate the parameters of the configured flash. Operation
+depends on the flash type.
+@subsection flash erase_check
+@b{flash erase_check} <@var{num}>
+@cindex flash erase_check
+@*Check erase state of sectors in flash bank <@var{num}>. This is the only operation that
+updates the erase state information displayed by @option{flash info}. That means you have
+to issue an @option{erase_check} command after erasing or programming the device to get
+updated information.
+@subsection flash protect_check
+@b{flash protect_check} <@var{num}>
+@cindex flash protect_check
+@*Check protection state of sectors in flash bank <num>.
+@option{flash erase_sector} using the same syntax.
+@subsection flash erase_sector
+@b{flash erase_sector} <@var{num}> <@var{first}> <@var{last}>
+@cindex flash erase_sector
+@anchor{flash erase_sector}
+@*Erase sectors at bank <@var{num}>, starting at sector <@var{first}> up to and including
+<@var{last}>. Sector numbering starts at 0. Depending on the flash type, erasing may
+require the protection to be disabled first (e.g. Intel Advanced Bootblock flash using
+the CFI driver).
+@subsection flash erase_address
+@b{flash erase_address} <@var{address}> <@var{length}>
+@cindex flash erase_address
+@*Erase sectors starting at <@var{address}> for <@var{length}> bytes
+@subsection flash write_bank
+@b{flash write_bank} <@var{num}> <@var{file}> <@var{offset}>
+@cindex flash write_bank
+@anchor{flash write_bank}
+@*Write the binary <@var{file}> to flash bank <@var{num}>, starting at
+<@option{offset}> bytes from the beginning of the bank.
+@subsection flash write_image
+@b{flash write_image} [@var{erase}] <@var{file}> [@var{offset}] [@var{type}]
+@cindex flash write_image
+@anchor{flash write_image}
+@*Write the image <@var{file}> to the current target's flash bank(s). A relocation
+[@var{offset}] can be specified and the file [@var{type}] can be specified
+explicitly as @option{bin} (binary), @option{ihex} (Intel hex), @option{elf}
+(ELF file) or @option{s19} (Motorola s19). Flash memory will be erased prior to programming
+if the @option{erase} parameter is given.
+@subsection flash protect
+@b{flash protect} <@var{num}> <@var{first}> <@var{last}> <@option{on}|@option{off}>
+@cindex flash protect
+@*Enable (@var{on}) or disable (@var{off}) protection of flash sectors <@var{first}> to
+<@var{last}> of @option{flash bank} <@var{num}>.
+
+@subsection mFlash commands
+@cindex mFlash commands
+@itemize @bullet
+@item @b{mflash probe}
+@cindex mflash probe
+Probe mflash.
+@item @b{mflash write} <@var{num}> <@var{file}> <@var{offset}>
+@cindex mflash write
+Write the binary <@var{file}> to mflash bank <@var{num}>, starting at
+<@var{offset}> bytes from the beginning of the bank.
+@item @b{mflash dump} <@var{num}> <@var{file}> <@var{offset}> <@var{size}>
+@cindex mflash dump
+Dump <size> bytes, starting at <@var{offset}> bytes from the beginning of the <@var{num}> bank
+to a <@var{file}>.
+@end itemize
+
+@section flash bank command
+The @b{flash bank} command is used to configure one or more flash chips (or banks in OpenOCD terms)
+
+@example
+@b{flash bank} <@var{driver}> <@var{base}> <@var{size}> <@var{chip_width}>
+<@var{bus_width}> <@var{target#}> [@var{driver_options ...}]
+@end example
+@cindex flash bank
+@*Configures a flash bank at <@var{base}> of <@var{size}> bytes and <@var{chip_width}>
+and <@var{bus_width}> bytes using the selected flash <driver>.
+
+@subsection External Flash - cfi options
+@cindex cfi options
+CFI flash are external flash chips - often they are connected to a
+specific chip select on the micro. By default at hard reset most
+micros have the ablity to ``boot'' from some flash chip - typically
+attached to the chips CS0 pin.
+
+For other chip selects: OpenOCD does not know how to configure, or
+access a specific chip select. Instead you the human might need to via
+other commands (like: mww) configure additional chip selects, or
+perhaps configure a GPIO pin that controls the ``write protect'' pin
+on the FLASH chip.
+
+@b{flash bank cfi} <@var{base}> <@var{size}> <@var{chip_width}> <@var{bus_width}>
+<@var{target#}> [@var{jedec_probe}|@var{x16_as_x8}]
+@*CFI flashes require the number of the target they're connected to as an additional
+argument. The CFI driver makes use of a working area (specified for the target)
+to significantly speed up operation.
+
+@var{chip_width} and @var{bus_width} are specified in bytes.
+
+The @var{jedec_probe} option is used to detect certain non-CFI flash roms, like AM29LV010 and similar types.
+
+@var{x16_as_x8} ???
+
+@subsection Internal Flash (Micro Controllers)
+@subsubsection lpc2000 options
+@cindex lpc2000 options
+
+@b{flash bank lpc2000} <@var{base}> <@var{size}> 0 0 <@var{target#}> <@var{variant}>
+<@var{clock}> [@var{calc_checksum}]
+@*LPC flashes don't require the chip and bus width to be specified. Additional
+parameters are the <@var{variant}>, which may be @var{lpc2000_v1} (older LPC21xx and LPC22xx)
+or @var{lpc2000_v2} (LPC213x, LPC214x, LPC210[123], LPC23xx and LPC24xx), the number
+of the target this flash belongs to (first is 0), the frequency at which the core
+is currently running (in kHz - must be an integral number), and the optional keyword
+@var{calc_checksum}, telling the driver to calculate a valid checksum for the exception
+vector table.
+
+
+@subsubsection at91sam7 options
+@cindex at91sam7 options
+
+@b{flash bank at91sam7} 0 0 0 0 <@var{target#}>
+@*AT91SAM7 flashes only require the @var{target#}, all other values are looked up after
+reading the chip-id and type.
+
+@subsubsection str7 options
+@cindex str7 options
+
+@b{flash bank str7x} <@var{base}> <@var{size}> 0 0 <@var{target#}> <@var{variant}>
+@*variant can be either STR71x, STR73x or STR75x.
+
+@subsubsection str9 options
+@cindex str9 options
+
+@b{flash bank str9x} <@var{base}> <@var{size}> 0 0 <@var{target#}>
+@*The str9 needs the flash controller to be configured prior to Flash programming, eg.
+@example
+str9x flash_config 0 4 2 0 0x80000
+@end example
+This will setup the BBSR, NBBSR, BBADR and NBBADR registers respectively.
+
+@subsubsection str9 options (str9xpec driver)
+
+@b{flash bank str9xpec} <@var{base}> <@var{size}> 0 0 <@var{target#}>
+@*Before using the flash commands the turbo mode will need enabling using str9xpec
+@option{enable_turbo} <@var{num>.}
+
+Only use this driver for locking/unlocking the device or configuring the option bytes.
+Use the standard str9 driver for programming. @xref{STR9 specific commands}.
+
+@subsubsection stellaris (LM3Sxxx) options
+@cindex stellaris (LM3Sxxx) options
+
+@b{flash bank stellaris} <@var{base}> <@var{size}> 0 0 <@var{target#}>
+@*stellaris flash plugin only require the @var{target#}.
+
+@subsubsection stm32x options
+@cindex stm32x options
+
+@b{flash bank stm32x} <@var{base}> <@var{size}> 0 0 <@var{target#}>
+@*stm32x flash plugin only require the @var{target#}.
+
+@subsubsection aduc702x options
+@cindex aduc702x options
+
+@b{flash bank aduc702x} <@var{base}> <@var{size}> 0 0 <@var{target#}>
+@*aduc702x flash plugin require the flash @var{base}, @var{size} and @var{target#}.
+
+@subsection mFlash configuration
+@cindex mFlash configuration
+@b{mflash bank} <@var{soc}> <@var{base}> <@var{chip_width}> <@var{bus_width}>
+<@var{RST pin}> <@var{WP pin}> <@var{DPD pin}> <@var{target #}>
+@cindex mflash bank
+@*Configures a mflash for <@var{soc}> host bank at
+<@var{base}>. <@var{chip_width}> and <@var{bus_width}> are bytes
+order. Pin number format is dependent on host GPIO calling convention.
+If WP or DPD pin was not used, write -1. Currently, mflash bank
+support s3c2440 and pxa270.
+
+(ex. of s3c2440) mflash <@var{RST pin}> is GPIO B1, <@var{WP pin}> and <@var{DPD pin}> are not used.
+@example
+mflash bank s3c2440 0x10000000 2 2 1b -1 -1 0
+@end example
+(ex. of pxa270) mflash <@var{RST pin}> is GPIO 43, <@var{DPD pin}> is not used and <@var{DPD pin}> is GPIO 51.
+@example
+mflash bank pxa270 0x08000000 2 2 43 -1 51 0
+@end example
+
+@section Micro Controller Specific Flash Commands
+
+@subsection AT91SAM7 specific commands
+@cindex AT91SAM7 specific commands
+The flash configuration is deduced from the chip identification register. The flash
+controller handles erases automatically on a page (128/265 byte) basis so erase is
+not necessary for flash programming. AT91SAM7 processors with less than 512K flash
+only have a single flash bank embedded on chip. AT91SAM7xx512 have two flash planes
+that can be erased separatly. Only an EraseAll command is supported by the controller
+for each flash plane and this is called with
+@itemize @bullet
+@item @b{flash erase} <@var{num}> @var{first_plane} @var{last_plane}
+@*bulk erase flash planes first_plane to last_plane.
+@item @b{at91sam7 gpnvm} <@var{num}> <@var{bit}> <@option{set}|@option{clear}>
+@cindex at91sam7 gpnvm
+@*set or clear a gpnvm bit for the processor
+@end itemize
+
+@subsection STR9 specific commands
+@cindex STR9 specific commands
+@anchor{STR9 specific commands}
+These are flash specific commands when using the str9xpec driver.
+@itemize @bullet
+@item @b{str9xpec enable_turbo} <@var{num}>
+@cindex str9xpec enable_turbo
+@*enable turbo mode, simply this will remove the str9 from the chain and talk
+directly to the embedded flash controller.
+@item @b{str9xpec disable_turbo} <@var{num}>
+@cindex str9xpec disable_turbo
+@*restore the str9 into jtag chain.
+@item @b{str9xpec lock} <@var{num}>
+@cindex str9xpec lock
+@*lock str9 device. The str9 will only respond to an unlock command that will
+erase the device.
+@item @b{str9xpec unlock} <@var{num}>
+@cindex str9xpec unlock
+@*unlock str9 device.
+@item @b{str9xpec options_read} <@var{num}>
+@cindex str9xpec options_read
+@*read str9 option bytes.
+@item @b{str9xpec options_write} <@var{num}>
+@cindex str9xpec options_write
+@*write str9 option bytes.
+@end itemize
+
+Note: Before using the str9xpec driver here is some background info to help
+you better understand how the drivers works. OpenOCD has two flash drivers for
+the str9.
+@enumerate
+@item
+Standard driver @option{str9x} programmed via the str9 core. Normally used for
+flash programming as it is faster than the @option{str9xpec} driver.
+@item
+Direct programming @option{str9xpec} using the flash controller, this is
+ISC compilant (IEEE 1532) tap connected in series with the str9 core. The str9
+core does not need to be running to program using this flash driver. Typical use
+for this driver is locking/unlocking the target and programming the option bytes.
+@end enumerate
+
+Before we run any cmds using the @option{str9xpec} driver we must first disable
+the str9 core. This example assumes the @option{str9xpec} driver has been
+configured for flash bank 0.
+@example
+# assert srst, we do not want core running
+# while accessing str9xpec flash driver
+jtag_reset 0 1
+# turn off target polling
+poll off
+# disable str9 core
+str9xpec enable_turbo 0
+# read option bytes
+str9xpec options_read 0
+# re-enable str9 core
+str9xpec disable_turbo 0
+poll on
+reset halt
+@end example
+The above example will read the str9 option bytes.
+When performing a unlock remember that you will not be able to halt the str9 - it
+has been locked. Halting the core is not required for the @option{str9xpec} driver
+as mentioned above, just issue the cmds above manually or from a telnet prompt.
+
+@subsection STR9 configuration
+@cindex STR9 configuration
+@itemize @bullet
+@item @b{str9x flash_config} <@var{bank}> <@var{BBSR}> <@var{NBBSR}>
+<@var{BBADR}> <@var{NBBADR}>
+@cindex str9x flash_config
+@*Configure str9 flash controller.
+@example
+eg. str9x flash_config 0 4 2 0 0x80000
+This will setup
+BBSR - Boot Bank Size register
+NBBSR - Non Boot Bank Size register
+BBADR - Boot Bank Start Address register
+NBBADR - Boot Bank Start Address register
+@end example
+@end itemize
+
+@subsection STR9 option byte configuration
+@cindex STR9 option byte configuration
+@itemize @bullet
+@item @b{str9xpec options_cmap} <@var{num}> <@option{bank0}|@option{bank1}>
+@cindex str9xpec options_cmap
+@*configure str9 boot bank.
+@item @b{str9xpec options_lvdthd} <@var{num}> <@option{2.4v}|@option{2.7v}>
+@cindex str9xpec options_lvdthd
+@*configure str9 lvd threshold.
+@item @b{str9xpec options_lvdsel} <@var{num}> <@option{vdd}|@option{vdd_vddq}>
+@cindex str9xpec options_lvdsel
+@*configure str9 lvd source.
+@item @b{str9xpec options_lvdwarn} <@var{bank}> <@option{vdd}|@option{vdd_vddq}>
+@cindex str9xpec options_lvdwarn
+@*configure str9 lvd reset warning source.
+@end itemize
+
+@subsection STM32x specific commands
+@cindex STM32x specific commands
+
+These are flash specific commands when using the stm32x driver.
+@itemize @bullet
+@item @b{stm32x lock} <@var{num}>
+@cindex stm32x lock
+@*lock stm32 device.
+@item @b{stm32x unlock} <@var{num}>
+@cindex stm32x unlock
+@*unlock stm32 device.
+@item @b{stm32x options_read} <@var{num}>
+@cindex stm32x options_read
+@*read stm32 option bytes.
+@item @b{stm32x options_write} <@var{num}> <@option{SWWDG}|@option{HWWDG}>
+<@option{RSTSTNDBY}|@option{NORSTSTNDBY}> <@option{RSTSTOP}|@option{NORSTSTOP}>
+@cindex stm32x options_write
+@*write stm32 option bytes.
+@item @b{stm32x mass_erase} <@var{num}>
+@cindex stm32x mass_erase
+@*mass erase flash memory.
+@end itemize
+
+@subsection Stellaris specific commands
+@cindex Stellaris specific commands
+
+These are flash specific commands when using the Stellaris driver.
+@itemize @bullet
+@item @b{stellaris mass_erase} <@var{num}>
+@cindex stellaris mass_erase
+@*mass erase flash memory.
+@end itemize
+
+
+@node General Commands
+@chapter General Commands
+@cindex commands
+
+The commands documented in this chapter here are common commands that
+you a human may want to type and see the output of. Configuration type
+commands are documented elsewhere.
+
+Intent:
+@itemize @bullet
+@item @b{Source Of Commands}
+@* OpenOCD commands can occur in a configuration script (discussed
+elsewhere) or typed manually by a human or supplied programatically,
+or via one of several Tcp/Ip Ports.
+
+@item @b{From the human}
+@* A human should interact with the Telnet interface (default port: 4444,
+or via GDB, default port 3333)
+
+To issue commands from within a GDB session, use the @option{monitor}
+command, e.g. use @option{monitor poll} to issue the @option{poll}
+command. All output is relayed through the GDB session.
+
+@item @b{Machine Interface}
+The TCL interface intent is to be a machine interface. The default TCL
+port is 5555.
+@end itemize
+
+
+@section Daemon Commands
+
+@subsection sleep [@var{msec}]
+@cindex sleep
+@*Wait for n milliseconds before resuming. Useful in connection with script files
+(@var{script} command and @var{target_script} configuration).
+
+@subsection shutdown
+@cindex shutdown
+@*Close the OpenOCD daemon, disconnecting all clients (GDB, Telnet, Other).
+
+@subsection debug_level [@var{n}]
+@cindex debug_level
+@anchor{debug_level}
+@*Display or adjust debug level to n<0-3>
+
+@subsection fast [@var{enable|disable}]
+@cindex fast
+@*Default disabled. Set default behaviour of OpenOCD to be "fast and dangerous". For instance ARM7/9 DCC memory
+downloads and fast memory access will work if the JTAG interface isn't too fast and
+the core doesn't run at a too low frequency. Note that this option only changes the default
+and that the indvidual options, like DCC memory downloads, can be enabled and disabled
+individually.
+
+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.
+
+Typically the "fast enable" is specified first on the command line:
+
+@example
+openocd -c "fast enable" -c "interface dummy" -f target/str710.cfg
+@end example
+
+@subsection log_output <@var{file}>
+@cindex log_output
+@*Redirect logging to <file> (default: stderr)
+
+@subsection script <@var{file}>
+@cindex script
+@*Execute commands from <file>
+Also see: ``source [find FILENAME]''
+
+@section Target state handling
+@subsection power <@var{on}|@var{off}>
+@cindex reg
+@*Turn power switch to target on/off.
+No arguments: print status.
+Not all interfaces support this.
+
+@subsection reg [@option{#}|@option{name}] [value]
+@cindex reg
+@*Access a single register by its number[@option{#}] or by its [@option{name}].
+No arguments: list all available registers for the current target.
+Number or name argument: display a register
+Number or name and value arguments: set register value
+
+@subsection poll [@option{on}|@option{off}]
+@cindex poll
+@*Poll the target for its current state. If the target is in debug mode, architecture
+specific information about the current state is printed. An optional parameter
+allows continuous polling to be enabled and disabled.
+
+@subsection halt [@option{ms}]
+@cindex halt
+@*Send a halt request to the target and wait for it to halt for up to [@option{ms}] milliseconds.
+Default [@option{ms}] is 5 seconds if no arg given.
+Optional arg @option{ms} is a timeout in milliseconds. Using 0 as the [@option{ms}]
+will stop OpenOCD from waiting.
+
+@subsection wait_halt [@option{ms}]
+@cindex wait_halt
+@*Wait for the target to enter debug mode. Optional [@option{ms}] is
+a timeout in milliseconds. Default [@option{ms}] is 5 seconds if no
+arg given.
+
+@subsection resume [@var{address}]
+@cindex resume
+@*Resume the target at its current code position, or at an optional address.
+OpenOCD will wait 5 seconds for the target to resume.
+
+@subsection step [@var{address}]
+@cindex step
+@*Single-step the target at its current code position, or at an optional address.
+
+@subsection reset [@option{run}|@option{halt}|@option{init}]
+@cindex reset
+@*Perform a hard-reset. The optional parameter specifies what should happen after the reset.
+
+With no arguments a "reset run" is executed
+@itemize @minus
+@item @b{run}
+@cindex reset run
+@*Let the target run.
+@item @b{halt}
+@cindex reset halt
+@*Immediately halt the target (works only with certain configurations).
+@item @b{init}
+@cindex reset init
+@*Immediately halt the target, and execute the reset script (works only with certain
+configurations)
+@end itemize
+
+@subsection soft_reset_halt
+@cindex reset
+@*Requesting target halt and executing a soft reset. This often used
+when a target cannot be reset and halted. The target, after reset is
+released begins to execute code. OpenOCD attempts to stop the CPU and
+then sets the Program counter back at the reset vector. Unfortunatlly
+that code that was executed may have left hardware in an unknown
+state.
+
+
+@section Memory access commands
+@subsection meminfo
+display available ram memory.
+@subsection Memory Peek/Poke type commands
+These commands allow accesses of a specific size to the memory
+system. Often these are used to configure the current target in some
+special way. For example - one may need to write certian values to the
+SDRAM controller to enable SDRAM.
+
+@enumerate
+@item To change the current target see the ``targets'' (plural) command
+@item In system level scripts these commands are depricated, please use the TARGET object versions.
+@end enumerate
+
+@itemize @bullet
+@item @b{mdw} <@var{addr}> [@var{count}]
+@cindex mdw
+@*display memory words (32bit)
+@item @b{mdh} <@var{addr}> [@var{count}]
+@cindex mdh
+@*display memory half-words (16bit)
+@item @b{mdb} <@var{addr}> [@var{count}]
+@cindex mdb
+@*display memory bytes (8bit)
+@item @b{mww} <@var{addr}> <@var{value}>
+@cindex mww
+@*write memory word (32bit)
+@item @b{mwh} <@var{addr}> <@var{value}>
+@cindex mwh
+@*write memory half-word (16bit)
+@item @b{mwb} <@var{addr}> <@var{value}>
+@cindex mwb
+@*write memory byte (8bit)
+@end itemize
+
+@section Image Loading Commands
+@subsection load_image
+@b{load_image} <@var{file}> <@var{address}> [@option{bin}|@option{ihex}|@option{elf}]
+@cindex load_image
+@anchor{load_image}
+@*Load image <@var{file}> to target memory at <@var{address}>
+@subsection fast_load_image
+@b{fast_load_image} <@var{file}> <@var{address}> [@option{bin}|@option{ihex}|@option{elf}]
+@cindex fast_load_image
+@anchor{fast_load_image}
+@*Normally you should be using @b{load_image} or GDB load. However, for
+testing purposes or when IO overhead is significant(OpenOCD running on embedded
+host), then storing the image in memory and uploading the image to the target
+can be a way to upload e.g. multiple debug sessions when the binary does not change.
+Arguments as @b{load_image}, but image is stored in OpenOCD host
+memory, i.e. does not affect target. This approach is also useful when profiling
+target programming performance as IO and target programming can easily be profiled
+seperately.
+@subsection fast_load
+@b{fast_load}
+@cindex fast_image
+@anchor{fast_image}
+@*Loads image stored in memory by @b{fast_load_image} to current target. Must be preceeded by fast_load_image.
+@subsection dump_image
+@b{dump_image} <@var{file}> <@var{address}> <@var{size}>
+@cindex dump_image
+@anchor{dump_image}
+@*Dump <@var{size}> bytes of target memory starting at <@var{address}> to a
+(binary) <@var{file}>.
+@subsection verify_image
+@b{verify_image} <@var{file}> <@var{address}> [@option{bin}|@option{ihex}|@option{elf}]
+@cindex verify_image
+@*Verify <@var{file}> against target memory starting at <@var{address}>.
+This will first attempt comparison using a crc checksum, if this fails it will try a binary compare.
+
+
+@section Breakpoint commands
+@cindex Breakpoint commands
+@itemize @bullet
+@item @b{bp} <@var{addr}> <@var{len}> [@var{hw}]
+@cindex bp
+@*set breakpoint <address> <length> [hw]
+@item @b{rbp} <@var{addr}>
+@cindex rbp
+@*remove breakpoint <adress>
+@item @b{wp} <@var{addr}> <@var{len}> <@var{r}|@var{w}|@var{a}> [@var{value}] [@var{mask}]
+@cindex wp
+@*set watchpoint <address> <length> <r/w/a> [value] [mask]
+@item @b{rwp} <@var{addr}>
+@cindex rwp
+@*remove watchpoint <adress>
+@end itemize
+
+@section Misc Commands
+@cindex Other Target Commands
+@itemize
+@item @b{profile} <@var{seconds}> <@var{gmon.out}>
+
+Profiling samples the CPU PC as quickly as OpenOCD is able, which will be used as a random sampling of PC.
+@end itemize
+
+@section Target Specific Commands
+@cindex Target Specific Commands
+
+
+@page
+@section Architecture Specific Commands
+@cindex Architecture Specific Commands
+
+@subsection ARMV4/5 specific commands
+@cindex ARMV4/5 specific commands
+
+These commands are specific to ARM architecture v4 and v5, like all ARM7/9 systems
+or Intel XScale (XScale isn't supported yet).
+@itemize @bullet
+@item @b{armv4_5 reg}
+@cindex armv4_5 reg
+@*Display a list 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.
+@item @b{armv4_5 core_mode} [@var{arm}|@var{thumb}]
+@cindex armv4_5 core_mode
+@*Displays the core_mode, optionally changing it to either ARM or Thumb mode.
+The target is resumed in the currently set @option{core_mode}.
+@end itemize
+
+@subsection ARM7/9 specific commands
+@cindex ARM7/9 specific commands
+
+These commands are specific to ARM7 and ARM9 targets, like ARM7TDMI, ARM720t,
+ARM920t or ARM926EJ-S.
+@itemize @bullet
+@item @b{arm7_9 dbgrq} <@var{enable}|@var{disable}>
+@cindex arm7_9 dbgrq
+@*Enable use of the DBGRQ bit to force entry into debug mode. This should be
+safe for all but ARM7TDMI--S cores (like Philips LPC).
+@item @b{arm7_9 fast_memory_access} <@var{enable}|@var{disable}>
+@cindex arm7_9 fast_memory_access
+@anchor{arm7_9 fast_memory_access}
+@*Allow OpenOCD to read and write memory without checking 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 a very low
+speed, like the 32kHz startup clock of an AT91RM9200.
+@item @b{arm7_9 dcc_downloads} <@var{enable}|@var{disable}>
+@cindex arm7_9 dcc_downloads
+@*Enable the use of the debug communications channel (DCC) to write larger (>128 byte)
+amounts of memory. DCC downloads offer a huge speed increase, but might be potentially
+unsafe, especially with targets running at a very low speed. This command was introduced
+with OpenOCD rev. 60.
+@end itemize
+
+@subsection ARM720T specific commands
+@cindex ARM720T specific commands
+
+@itemize @bullet
+@item @b{arm720t cp15} <@var{num}> [@var{value}]
+@cindex arm720t cp15
+@*display/modify cp15 register <@option{num}> [@option{value}].
+@item @b{arm720t md<bhw>_phys} <@var{addr}> [@var{count}]
+@cindex arm720t md<bhw>_phys
+@*Display memory at physical address addr.
+@item @b{arm720t mw<bhw>_phys} <@var{addr}> <@var{value}>
+@cindex arm720t mw<bhw>_phys
+@*Write memory at physical address addr.
+@item @b{arm720t virt2phys} <@var{va}>
+@cindex arm720t virt2phys
+@*Translate a virtual address to a physical address.
+@end itemize
+
+@subsection ARM9TDMI specific commands
+@cindex ARM9TDMI specific commands
+
+@itemize @bullet
+@item @b{arm9tdmi vector_catch} <@var{all}|@var{none}>
+@cindex arm9tdmi vector_catch
+@*Catch arm9 interrupt vectors, can be @option{all} @option{none} or any of the following:
+@option{reset} @option{undef} @option{swi} @option{pabt} @option{dabt} @option{reserved}
+@option{irq} @option{fiq}.
+
+Can also be used on other arm9 based cores, arm966, arm920t and arm926ejs.
+@end itemize
+
+@subsection ARM966E specific commands
+@cindex ARM966E specific commands
+
+@itemize @bullet
+@item @b{arm966e cp15} <@var{num}> [@var{value}]
+@cindex arm966e cp15
+@*display/modify cp15 register <@option{num}> [@option{value}].
+@end itemize
+
+@subsection ARM920T specific commands
+@cindex ARM920T specific commands
+
+@itemize @bullet
+@item @b{arm920t cp15} <@var{num}> [@var{value}]
+@cindex arm920t cp15
+@*display/modify cp15 register <@option{num}> [@option{value}].
+@item @b{arm920t cp15i} <@var{num}> [@var{value}] [@var{address}]
+@cindex arm920t cp15i
+@*display/modify cp15 (interpreted access) <@option{opcode}> [@option{value}] [@option{address}]
+@item @b{arm920t cache_info}
+@cindex arm920t cache_info
+@*Print information about the caches found. This allows you to see if your target
+is a ARM920T (2x16kByte cache) or ARM922T (2x8kByte cache).
+@item @b{arm920t md<bhw>_phys} <@var{addr}> [@var{count}]
+@cindex arm920t md<bhw>_phys
+@*Display memory at physical address addr.
+@item @b{arm920t mw<bhw>_phys} <@var{addr}> <@var{value}>
+@cindex arm920t mw<bhw>_phys
+@*Write memory at physical address addr.
+@item @b{arm920t read_cache} <@var{filename}>
+@cindex arm920t read_cache
+@*Dump the content of ICache and DCache to a file.
+@item @b{arm920t read_mmu} <@var{filename}>
+@cindex arm920t read_mmu
+@*Dump the content of the ITLB and DTLB to a file.
+@item @b{arm920t virt2phys} <@var{va}>
+@cindex arm920t virt2phys
+@*Translate a virtual address to a physical address.
+@end itemize