support for scripts in $HOME/.openocd
[fw/openocd] / doc / openocd.texi
index 8e1d1a8f60614d51c9d70fbc74d128f100dd4cd7..e94c9d02bfef6afe80f226273deb1f967bf98529 100644 (file)
@@ -81,7 +81,6 @@ Free Documentation License''.
 * TFTP::                             TFTP
 * GDB and OpenOCD::                  Using GDB and OpenOCD
 * Tcl Scripting API::                Tcl Scripting API
-* Upgrading::                        Deprecated/Removed Commands
 * FAQ::                              Frequently Asked Questions
 * Tcl Crash Course::                 Tcl Crash Course
 * License::                          GNU Free Documentation License
@@ -484,14 +483,24 @@ bash$ openocd --help
 --pipe       | -p       use pipes when talking to gdb
 @end verbatim
 
-By default OpenOCD reads the file configuration file @file{openocd.cfg}
-in the current directory.  To specify a different (or multiple)
-configuration file, you can use the ``-f'' option. For example:
+By default OpenOCD reads the configuration file @file{openocd.cfg}.
+To specify a different (or multiple)
+configuration file, you can use the @option{-f} option. For example:
 
 @example
 openocd -f config1.cfg -f config2.cfg -f config3.cfg
 @end example
 
+Configuration files and scripts are searched for in
+@enumerate
+@item the current directory,
+@item any search dir specified on the command line using the @option{-s} option,
+@item @file{$HOME/.openocd} (not on Windows),
+@item the site wide script library @file{$pkgdatadir/site} and
+@item the OpenOCD-supplied script library @file{$pkgdatadir/scripts}.
+@end enumerate
+The first found file with a matching file name will be used.
+
 OpenOCD starts by processing the configuration commands provided
 on the command line or in @file{openocd.cfg}.
 @xref{Configuration Stage}.
@@ -508,7 +517,7 @@ clients (Telnet, GDB, Other) and processes the commands issued through
 those channels.
 
 If you are having problems, you can enable internal debug messages via
-the ``-d'' option.
+the @option{-d} option.
 
 Also it is possible to interleave JIM-Tcl commands w/config scripts using the
 @option{-c} command line switch.
@@ -524,10 +533,6 @@ setting from within a telnet or gdb session using @command{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
@@ -1503,7 +1508,7 @@ proc setc15 @{regs value@} @{
 
     echo [format "set p15 0x%04x, 0x%08x" $regs $value]
 
-    arm11 mcr $TARGETNAME 15 [expr ($regs>>12)&0x7] \
+    mcr 15 [expr ($regs>>12)&0x7] \
         [expr ($regs>>0)&0xf] [expr ($regs>>4)&0xf] \
         [expr ($regs>>8)&0x7] $value
 @}
@@ -1976,6 +1981,42 @@ When using PPDEV to access the parallel port, use the number of the parallel por
 you may encounter a problem.
 @end deffn
 
+@deffn Command {parport_toggling_time} [nanoseconds]
+Displays how many nanoseconds the hardware needs to toggle TCK;
+the parport driver uses this value to obey the
+@command{jtag_khz} configuration.
+When the optional @var{nanoseconds} parameter is given,
+that setting is changed before displaying the current value.
+
+The default setting should work reasonably well on commodity PC hardware.
+However, you may want to calibrate for your specific hardware.
+@quotation Tip
+To measure the toggling time with a logic analyzer or a digital storage
+oscilloscope, follow the procedure below:
+@example
+> parport_toggling_time 1000
+> jtag_khz 500
+@end example
+This sets the maximum JTAG clock speed of the hardware, but
+the actual speed probably deviates from the requested 500 kHz.
+Now, measure the time between the two closest spaced TCK transitions.
+You can use @command{runtest 1000} or something similar to generate a
+large set of samples.
+Update the setting to match your measurement:
+@example
+> parport_toggling_time <measured nanoseconds>
+@end example
+Now the clock speed will be a better match for @command{jtag_khz rate}
+commands given in OpenOCD scripts and event handlers.
+
+You can do something similar with many digital multimeters, but note
+that you'll probably need to run the clock continuously for several
+seconds before it decides what clock rate to show.  Adjust the
+toggling time up or down until the measured clock rate is a good
+match for the jtag_khz rate you specified; be conservative.
+@end quotation
+@end deffn
+
 @deffn {Config Command} {parport_write_on_exit} (on|off)
 This will configure the parallel driver to write a known
 cable-specific value to the parallel interface on exiting OpenOCD
@@ -3505,7 +3546,7 @@ board by (re)installing working boot firmware.
 @section Flash Configuration Commands
 @cindex flash configuration
 
-@deffn {Config Command} {flash bank} driver base size chip_width bus_width target [driver_options]
+@deffn {Config Command} {flash bank} name driver base size chip_width bus_width target [driver_options]
 Configures a flash bank which provides persistent storage
 for addresses from @math{base} to @math{base + size - 1}.
 These banks will often be visible to GDB through the target's memory map.
@@ -3513,6 +3554,8 @@ In some cases, configuring a flash bank will activate extra commands;
 see the driver-specific documentation.
 
 @itemize @bullet
+@item @var{name} ... may be used to reference the flash bank
+in other flash commands.
 @item @var{driver} ... identifies the controller driver
 associated with the flash bank being declared.
 This is usually @code{cfi} for external flash, or else
@@ -4421,7 +4464,7 @@ NAND chips must be declared in configuration scripts,
 plus some additional configuration that's done after
 OpenOCD has initialized.
 
-@deffn {Config Command} {nand device} controller target [configparams...]
+@deffn {Config Command} {nand device} name controller target [configparams...]
 Declares a NAND device, which can be read and written to
 after it has been configured through @command{nand probe}.
 In OpenOCD, devices are single chips; this is unlike some
@@ -4435,6 +4478,8 @@ initialization has completed.  Use it in board specific
 configuration files, not interactively.
 
 @itemize @bullet
+@item @var{name} ... may be used to reference the NAND bank
+in other commands.
 @item @var{controller} ... identifies the controller driver
 associated with the NAND device being declared.
 @xref{NAND Driver List}.
@@ -4585,6 +4630,32 @@ the underlying driver from applying hardware ECC.
 @end itemize
 @end deffn
 
+@deffn Command {nand verify} num filename offset [option...]
+@cindex NAND verification
+@cindex NAND programming
+Verify the binary data in the file has been programmed to the
+specified NAND device, starting at the specified offset.
+The @var{num} parameter is the value shown by @command{nand list}.
+
+Use a complete path name for @var{filename}, so you don't depend
+on the directory used to start the OpenOCD server.
+
+The @var{offset} must be an exact multiple of the device's page size.
+All data in the file will be read and compared to the contents of the
+flash, assuming it doesn't run past the end of the device.
+As with @command{nand write}, only full pages are verified, so any extra
+space in the last page will be filled with 0xff bytes.
+
+The same @var{options} accepted by @command{nand write},
+and the file will be processed similarly to produce the buffers that
+can be compared against the contents produced from @command{nand dump}.
+
+@b{NOTE:} This will not work when the underlying NAND controller
+driver's @code{write_page} routine must update the OOB with a
+hardward-computed ECC before the data is written.  This limitation may
+be removed in a future release.
+@end deffn
+
 @section Other NAND commands
 @cindex NAND other commands
 
@@ -4868,26 +4939,37 @@ target which should become current.
 
 @deffn Command reg [(number|name) [value]]
 Access a single register by @var{number} or by its @var{name}.
+The target must generally be halted before access to CPU core
+registers is allowed.  Depending on the hardware, some other
+registers may be accessible while the target is running.
 
 @emph{With no arguments}:
 list all available registers for the current target,
 showing number, name, size, value, and cache status.
+For valid entries, a value is shown; valid entries
+which are also dirty (and will be written back later)
+are flagged as such.
 
 @emph{With number/name}: display that register's value.
 
 @emph{With both number/name and value}: set register's value.
+Writes may be held in a writeback cache internal to OpenOCD,
+so that setting the value marks the register as dirty instead
+of immediately flushing that value.  Resuming CPU execution
+(including by single stepping) or otherwise activating the
+relevant module will flush such values.
 
 Cores may have surprisingly many registers in their
 Debug and trace infrastructure:
 
 @example
 > reg
-(0) r0 (/32): 0x0000D3C2 (dirty: 1, valid: 1)
-(1) r1 (/32): 0xFD61F31C (dirty: 0, valid: 1)
-(2) r2 (/32): 0x00022551 (dirty: 0, valid: 1)
+===== ARM registers
+(0) r0 (/32): 0x0000D3C2 (dirty)
+(1) r1 (/32): 0xFD61F31C
+(2) r2 (/32)
 ...
-(164) ETM_CONTEXTID_COMPARATOR_MASK (/32): \
-              0x00000000 (dirty: 0, valid: 0)
+(164) ETM_contextid_comparator_mask (/32)
 >
 @end example
 @end deffn
@@ -5052,9 +5134,11 @@ about what TAP is the current target, or about MMU configuration.
 Display contents of address @var{addr}, as
 32-bit words (@command{mdw}), 16-bit halfwords (@command{mdh}),
 or 8-bit bytes (@command{mdb}).
+When the current target has an MMU which is present and active,
+@var{addr} is interpreted as a virtual address.
+Otherwise, or if the optional @var{phys} flag is specified,
+@var{addr} is interpreted as a physical address.
 If @var{count} is specified, displays that many units.
-@var{phys} is an optional flag to indicate to use
-physical address and bypass MMU
 (If you want to manipulate the data instead of displaying it,
 see the @code{mem2array} primitives.)
 @end deffn
@@ -5063,10 +5147,12 @@ see the @code{mem2array} primitives.)
 @deffnx Command mwh [phys] addr halfword
 @deffnx Command mwb [phys] addr byte
 Writes the specified @var{word} (32 bits),
-@var{halfword} (16 bits), or @var{byte} (8-bit) pattern,
+@var{halfword} (16 bits), or @var{byte} (8-bit) value,
 at the specified address @var{addr}.
-@var{phys} is an optional flag to indicate to use
-physical address and bypass MMU
+When the current target has an MMU which is present and active,
+@var{addr} is interpreted as a virtual address.
+Otherwise, or if the optional @var{phys} flag is specified,
+@var{addr} is interpreted as a physical address.
 @end deffn
 
 
@@ -5256,11 +5342,23 @@ Several of the parameters must reflect the trace port capabilities,
 which are a function of silicon capabilties (exposed later
 using @command{etm info}) and of what hardware is connected to
 that port (such as an external pod, or ETB).
-The @var{width} must be either 4, 8, or 16.
-The @var{mode} must be @option{normal}, @option{multiplexted},
-or @option{demultiplexted}.
+The @var{width} must be either 4, 8, or 16,
+except with ETMv3.0 and newer modules which may also
+support 1, 2, 24, 32, 48, and 64 bit widths.
+(With those versions, @command{etm info} also shows whether
+the selected port width and mode are supported.)
+
+The @var{mode} must be @option{normal}, @option{multiplexed},
+or @option{demultiplexed}.
 The @var{clocking} must be @option{half} or @option{full}.
 
+@quotation Warning
+With ETMv3.0 and newer, the bits set with the @var{mode} and
+@var{clocking} parameters both control the mode.
+This modified mode does not map to the values supported by
+previous ETM modules, so this syntax is subject to change.
+@end quotation
+
 @quotation Note
 You can see the ETM registers using the @command{reg} command.
 Not all possible registers are present in every ETM.
@@ -5438,16 +5536,14 @@ Reports whether the capture clock is locked or not.
 @end deffn
 
 
-@section ARMv4 and ARMv5 Architecture
-@cindex ARMv4
-@cindex ARMv5
+@section Generic ARM
+@cindex ARM
 
-These commands are specific to ARM architecture v4 and v5,
-including all ARM7 or ARM9 systems and Intel XScale.
+These commands should be available on all ARM processors.
 They are available in addition to other core-specific
 commands that may be available.
 
-@deffn Command {armv4_5 core_state} [@option{arm}|@option{thumb}]
+@deffn Command {arm core_state} [@option{arm}|@option{thumb}]
 Displays the core_state, optionally changing it to process
 either @option{arm} or @option{thumb} instructions.
 The target may later be resumed in the currently set core_state.
@@ -5455,30 +5551,45 @@ The target may later be resumed in the currently set core_state.
 that is not currently supported in OpenOCD.)
 @end deffn
 
-@deffn Command {armv4_5 disassemble} address [count [@option{thumb}]]
+@deffn Command {arm disassemble} address [count [@option{thumb}]]
 @cindex disassemble
 Disassembles @var{count} instructions starting at @var{address}.
 If @var{count} is not specified, a single instruction is disassembled.
 If @option{thumb} is specified, or the low bit of the address is set,
-Thumb (16-bit) instructions are used;
+Thumb2 (mixed 16/32-bit) instructions are used;
 else ARM (32-bit) instructions are used.
 (Processors may also support the Jazelle state, but
 those instructions are not currently understood by OpenOCD.)
+
+Note that all Thumb instructions are Thumb2 instructions,
+so older processors (without Thumb2 support) will still
+see correct disassembly of Thumb code.
+Also, ThumbEE opcodes are the same as Thumb2,
+with a handful of exceptions.
+ThumbEE disassembly currently has no explicit support.
 @end deffn
 
-@deffn Command {armv4_5 reg}
+@deffn Command {arm reg}
 Display a table of all banked core registers, fetching the current value from every
-core mode if necessary. OpenOCD versions before rev. 60 didn't fetch the current
-register value.
+core mode if necessary.
 @end deffn
 
+@section ARMv4 and ARMv5 Architecture
+@cindex ARMv4
+@cindex ARMv5
+
+The ARMv4 and ARMv5 architectures are widely used in embedded systems,
+and introduced core parts of the instruction set in use today. 
+That includes the Thumb instruction set, introduced in the ARMv4T
+variant.
+
 @subsection ARM7 and ARM9 specific commands
 @cindex ARM7
 @cindex ARM9
 
 These commands are specific to ARM7 and ARM9 cores, like ARM7TDMI, ARM720T,
 ARM9TDMI, ARM920T or ARM926EJ-S.
-They are available in addition to the ARMv4/5 commands,
+They are available in addition to the ARM commands,
 and any other core-specific commands that may be available.
 
 @deffn Command {arm7_9 dbgrq} (@option{enable}|@option{disable})
@@ -5505,49 +5616,13 @@ cables (FT2232), but might be unsafe if used with targets running at very low
 speeds, like the 32kHz startup clock of an AT91RM9200.
 @end deffn
 
-@deffn {Debug Command} {arm7_9 write_core_reg} num mode word
-@emph{This is intended for use while debugging OpenOCD; you probably
-shouldn't use it.}
-
-Writes a 32-bit @var{word} to register @var{num} (from 0 to 16)
-as used in the specified @var{mode}
-(where e.g. mode 16 is "user" and mode 19 is "supervisor";
-the M4..M0 bits of the PSR).
-Registers 0..15 are the normal CPU registers such as r0(0), r1(1) ... pc(15).
-Register 16 is the mode-specific SPSR,
-unless the specified mode is 0xffffffff (32-bit all-ones)
-in which case register 16 is the CPSR.
-The write goes directly to the CPU, bypassing the register cache.
-@end deffn
-
-@deffn {Debug Command} {arm7_9 write_xpsr} word (@option{0}|@option{1})
-@emph{This is intended for use while debugging OpenOCD; you probably
-shouldn't use it.}
-
-If the second parameter is zero, writes @var{word} to the
-Current Program Status register (CPSR).
-Else writes @var{word} to the current mode's Saved PSR (SPSR).
-In both cases, this bypasses the register cache.
-@end deffn
-
-@deffn {Debug Command} {arm7_9 write_xpsr_im8} byte rotate (@option{0}|@option{1})
-@emph{This is intended for use while debugging OpenOCD; you probably
-shouldn't use it.}
-
-Writes eight bits to the CPSR or SPSR,
-first rotating them by @math{2*rotate} bits,
-and bypassing the register cache.
-This has lower JTAG overhead than writing the entire CPSR or SPSR
-with @command{arm7_9 write_xpsr}.
-@end deffn
-
 @subsection ARM720T specific commands
 @cindex ARM720T
 
 These commands are available to ARM720T based CPUs,
 which are implementations of the ARMv4T architecture
 based on the ARM7TDMI-S integer core.
-They are available in addition to the ARMv4/5 and ARM7/ARM9 commands.
+They are available in addition to the ARM and ARM7/ARM9 commands.
 
 @deffn Command {arm720t cp15} regnum [value]
 Display cp15 register @var{regnum};
@@ -5591,8 +5666,8 @@ or a list with one or more of the following:
 These commands are available to ARM920T based CPUs,
 which are implementations of the ARMv4T architecture
 built using the ARM9TDMI integer core.
-They are available in addition to the ARMv4/5, ARM7/ARM9,
-and ARM9TDMI commands.
+They are available in addition to the ARM, ARM7/ARM9,
+and ARM9 commands.
 
 @deffn Command {arm920t cache_info}
 Print information about the caches found. This allows to see whether your target
@@ -5625,8 +5700,8 @@ Dump the content of the ITLB and DTLB to a file named @file{filename}.
 These commands are available to ARM926ej-s based CPUs,
 which are implementations of the ARMv5TEJ architecture
 based on the ARM9EJ-S integer core.
-They are available in addition to the ARMv4/5, ARM7/ARM9,
-and ARM9TDMI commands.
+They are available in addition to the ARM, ARM7/ARM9,
+and ARM9 commands.
 
 The Feroceon cores also support these commands, although
 they are not built from ARM926ej-s designs.
@@ -5635,20 +5710,13 @@ they are not built from ARM926ej-s designs.
 Print information about the caches found.
 @end deffn
 
-@deffn Command {arm926ejs cp15} opcode1 opcode2 CRn CRm regnum [value]
-Accesses cp15 register @var{regnum} using
-@var{opcode1}, @var{opcode2}, @var{CRn}, and @var{CRm}.
-If a @var{value} is provided, that value is written to that register.
-Else that register is read and displayed.
-@end deffn
-
 @subsection ARM966E specific commands
 @cindex ARM966E
 
 These commands are available to ARM966 based CPUs,
 which are implementations of the ARMv5TE architecture.
-They are available in addition to the ARMv4/5, ARM7/ARM9,
-and ARM9TDMI commands.
+They are available in addition to the ARM, ARM7/ARM9,
+and ARM9 commands.
 
 @deffn Command {arm966e cp15} regnum [value]
 Display cp15 register @var{regnum};
@@ -5797,15 +5865,6 @@ Without arguments, the current settings are displayed.
 @subsection ARM11 specific commands
 @cindex ARM11
 
-@deffn Command {arm11 mcr} pX opc1 CRn CRm opc2 value
-Write @var{value} to a coprocessor @var{pX} register
-passing parameters @var{CRn},
-@var{CRm}, opcodes @var{opc1} and @var{opc2},
-and the MCR instruction.
-(The difference beween this and the MCR2 instruction is
-one bit in the encoding, effecively a fifth parameter.)
-@end deffn
-
 @deffn Command {arm11 memwrite burst} [value]
 Displays the value of the memwrite burst-enable flag,
 which is enabled by default. Burst writes are only used
@@ -5822,15 +5881,6 @@ which is enabled by default.
 If @var{value} is defined, first assigns that.
 @end deffn
 
-@deffn Command {arm11 mrc} pX opc1 CRn CRm opc2
-Read a coprocessor @var{pX} register passing parameters @var{CRn},
-@var{CRm}, opcodes @var{opc1} and @var{opc2},
-and the MRC instruction.
-(The difference beween this and the MRC2 instruction is
-one bit in the encoding, effecively a fifth parameter.)
-Displays the result.
-@end deffn
-
 @deffn Command {arm11 step_irq_enable}  [value]
 Displays the value of the flag controlling whether
 IRQs are enabled during single stepping;
@@ -5858,7 +5908,7 @@ cores @emph{except the ARM1176} use the same six bits.
 @cindex Debug Access Port
 @cindex DAP
 These commands are specific to ARM architecture v7 Debug Access Port (DAP),
-included on cortex-m3 and cortex-a8 systems.
+included on Cortex-M3 and Cortex-A8 systems.
 They are available in addition to other core-specific commands that may be available.
 
 @deffn Command {dap info} [num]
@@ -5884,23 +5934,6 @@ Displays the number of extra tck for mem-ap memory bus access [0-255].
 If @var{value} is defined, first assigns that.
 @end deffn
 
-@subsection ARMv7-A specific commands
-@cindex ARMv7-A
-
-@deffn Command {armv7a disassemble} address [count [@option{thumb}]]
-@cindex disassemble
-Disassembles @var{count} instructions starting at @var{address}.
-If @var{count} is not specified, a single instruction is disassembled.
-If @option{thumb} is specified, or the low bit of the address is set,
-Thumb2 (mixed 16/32-bit) instructions are used;
-else ARM (32-bit) instructions are used.
-With a handful of exceptions, ThumbEE instructions are the same as Thumb2;
-ThumbEE disassembly currently has no explicit support.
-(Processors may also support the Jazelle state, but
-those instructions are not currently understood by OpenOCD.)
-@end deffn
-
-
 @subsection Cortex-M3 specific commands
 @cindex Cortex-M3
 
@@ -6507,91 +6540,6 @@ We should add support for a variable like Tcl variable
 is jim, not real tcl).
 @end quotation
 
-@node Upgrading
-@chapter Deprecated/Removed Commands
-@cindex Deprecated/Removed Commands
-Certain OpenOCD commands have been deprecated or
-removed during the various revisions.
-
-Upgrade your scripts as soon as possible.
-These descriptions for old commands may be removed
-a year after the command itself was removed.
-This means that in January 2010 this chapter may
-become much shorter.
-
-@itemize @bullet
-@item @b{arm7_9 fast_writes}
-@cindex arm7_9 fast_writes
-@*Use @command{arm7_9 fast_memory_access} instead.
-@xref{arm7_9 fast_memory_access}.
-@item @b{endstate}
-@cindex endstate
-@*An buggy old command that would not really work since background polling would wipe out the global endstate
-@item @b{arm7_9 force_hw_bkpts}
-@*Use @command{gdb_breakpoint_override} instead. Note that GDB will use hardware breakpoints
-for flash if the GDB memory map has been set up(default when flash is declared in
-target configuration). @xref{gdb_breakpoint_override}.
-@item @b{arm7_9 sw_bkpts}
-@*On by default. @xref{gdb_breakpoint_override}.
-@item @b{daemon_startup}
-@*this config option has been removed, simply adding @option{init} and @option{reset halt} to
-the end of your config script will give the same behaviour as using @option{daemon_startup reset}
-and @option{target cortex_m3 little reset_halt 0}.
-@item @b{dump_binary}
-@*use @option{dump_image} command with same args. @xref{dump_image}.
-@item @b{flash erase}
-@*use @option{flash erase_sector} command with same args. @xref{flash erase_sector}.
-@item @b{flash write}
-@*use @option{flash write_bank} command with same args. @xref{flash write_bank}.
-@item @b{flash write_binary}
-@*use @option{flash write_bank} command with same args. @xref{flash write_bank}.
-@item @b{flash auto_erase}
-@*use @option{flash write_image} command passing @option{erase} as the first parameter. @xref{flash write_image}.
-
-@item @b{jtag_device}
-@*use the @command{jtag newtap} command, converting from positional syntax
-to named prefixes, and naming the TAP.
-@xref{jtag newtap}.
-Note that if you try to use the old command, a message will tell you the
-right new command to use; and that the fourth parameter in the old syntax
-was never actually used.
-@example
-OLD: jtag_device 8 0x01 0xe3 0xfe
-NEW: jtag newtap CHIPNAME TAPNAME \
-           -irlen 8 -ircapture 0x01 -irmask 0xe3
-@end example
-
-@item @b{jtag_speed} value
-@*@xref{JTAG Speed}.
-Usually, a value of zero means maximum
-speed. The actual effect of this option depends on the JTAG interface used.
-@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
-
-@item @b{load_binary}
-@*use @option{load_image} command with same args. @xref{load_image}.
-@item @b{run_and_halt_time}
-@*This command has been removed for simpler reset behaviour, it can be simulated with the
-following commands:
-@smallexample
-reset run
-sleep 100
-halt
-@end smallexample
-@item @b{target} <@var{type}> <@var{endian}> <@var{jtag-position}>
-@*use the create subcommand of @option{target}.
-@item @b{target_script} <@var{target#}> <@var{eventname}> <@var{scriptname}>
-@*use <@var{target_name}> configure -event <@var{eventname}> "script <@var{scriptname}>"
-@item @b{working_area}
-@*use the @option{configure} subcommand of @option{target} to set the work-area-virt, work-area-phy, work-area-size, and work-area-backup properties of the target.
-@end itemize
-
 @node FAQ
 @chapter FAQ
 @cindex faq