X-Git-Url: https://review.openocd.org/gitweb?a=blobdiff_plain;f=doc%2Fopenocd.texi;h=b32ed213f16aa1f6f8000451fbcb5c0fe8464ad1;hb=4e56a2303b3f68bb647d8bb640a830f7f21ea231;hp=2ddcd0417b61836a6fc8b9f79468956ecb6cbef5;hpb=afed39c0fe20bffcf0f289e59e80ab9d6bb40a91;p=openocd.git diff --git a/doc/openocd.texi b/doc/openocd.texi index 2ddcd0417b..b32ed213f1 100644 --- a/doc/openocd.texi +++ b/doc/openocd.texi @@ -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 } switch. -Search paths for config/script files can be added to OpenOCD by using -the @option{-s } 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 @@ -1406,6 +1411,20 @@ chip can be tweaked by the board. Some chips have specific ways the TRST and SRST signals are managed. In the unusual case that these are @emph{chip specific} and can never be changed by board wiring, they could go here. +For example, some chips can't support JTAG debugging without +both signals. + +Provide a @code{reset-assert} event handler if you can. +Such a handler uses JTAG operations to reset the target, +letting this target config be used in systems which don't +provide the optional SRST signal, or on systems where you +don't want to reset all targets at once. +Such a handler might write to chip registers to force a reset, +use a JRC to do that (preferable -- the target may be wedged!), +or force a watchdog timer to trigger. +(For Cortex-M3 targets, this is not necessary. The target +driver knows how to use trigger an NVIC reset when SRST is +not available.) Some chips need special attention during reset handling if they're going to be used with JTAG. @@ -1413,6 +1432,8 @@ An example might be needing to send some commands right after the target's TAP has been reset, providing a @code{reset-deassert-post} event handler that writes a chip register to report that JTAG debugging is being done. +Another would be reconfiguring the watchdog so that it stops +counting while the core is halted in the debugger. JTAG clocking constraints often change during reset, and in some cases target config files (rather than board config files) @@ -1503,7 +1524,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 +1997,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 +@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 @@ -2360,6 +2417,12 @@ There are also @emph{event handlers} associated with TAPs or Targets. Those handlers are Tcl procedures you can provide, which are invoked at particular points in the reset sequence. +@emph{When SRST is not an option} you must set +up a @code{reset-assert} event handler for your target. +For example, some JTAG adapters don't include the SRST signal; +and some boards have multiple targets, and you won't always +want to reset everything at once. + After configuring those mechanisms, you might still find your board doesn't start up or reset correctly. For example, maybe it needs a slightly different sequence @@ -3185,13 +3248,18 @@ since performing a backup slows down operations. For example, the beginning of an SRAM block is likely to be used by most build systems, but the end is often unused. -@item @code{-work-area-size} @var{size} -- specify/set the work area +@item @code{-work-area-size} @var{size} -- specify work are size, +in bytes. The same size applies regardless of whether its physical +or virtual address is being used. @item @code{-work-area-phys} @var{address} -- set the work area base @var{address} to be used when no MMU is active. @item @code{-work-area-virt} @var{address} -- set the work area base @var{address} to be used when an MMU is active. +@emph{Do not specify a value for this except on targets with an MMU.} +The value should normally correspond to a static mapping for the +@code{-work-area-phys} address, set up by the current operating system. @end itemize @end deffn @@ -3344,9 +3412,14 @@ For example: @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 Is using SRST appropriate (and possible) on your system? +Or instead of that, do you need to issue JTAG commands to trigger reset? +SRST usually resets everything on the scan chain, which can be inappropriate. @item During reset, do you need to write to certain memory locations to set up system clocks or to reconfigure the SDRAM? +How about configuring the watchdog timer, or other peripherals, +to stop running while you hold the core stopped for debugging? @end itemize All of the above items can be addressed by target event handlers. @@ -3411,16 +3484,28 @@ The following target events are defined: @item @b{reset-assert-pre} @* Issued as part of @command{reset} processing after @command{reset_init} was triggered -but before SRST alone is re-asserted on the tap. +but before either SRST alone is re-asserted on the scan chain, +or @code{reset-assert} is triggered. +@item @b{reset-assert} +@* Issued as part of @command{reset} processing +after @command{reset-assert-pre} was triggered. +When such a handler is present, cores which support this event will use +it instead of asserting SRST. +This support is essential for debugging with JTAG interfaces which +don't include an SRST line (JTAG doesn't require SRST), and for +selective reset on scan chains that have multiple targets. @item @b{reset-assert-post} @* Issued as part of @command{reset} processing -when SRST is asserted on the tap. +after @code{reset-assert} has been triggered. +or the target asserted SRST on the entire scan chain. @item @b{reset-deassert-pre} @* Issued as part of @command{reset} processing -when SRST is about to be released on the tap. +after @code{reset-assert-post} has been triggered. @item @b{reset-deassert-post} @* Issued as part of @command{reset} processing -when SRST has been released on the tap. +after @code{reset-deassert-pre} has been triggered +and (if the target is using it) after SRST has been +released on the scan chain. @item @b{reset-end} @* Issued as the final step in @command{reset} processing. @ignore @@ -3500,7 +3585,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. @@ -3508,6 +3593,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 @@ -3683,7 +3770,7 @@ The @var{num} parameter is a value shown by @command{flash banks}. @end deffn @anchor{Flash Driver List} -@section Flash Drivers, Options, and Commands +@section Flash Driver List As noted above, the @command{flash bank} command requires a driver name, and allows driver-specific options and behaviors. Some drivers also activate driver-specific commands. @@ -3699,7 +3786,7 @@ specific external chip select on the CPU. Frequently the first such chip is used to boot the system. Your board's @code{reset-init} handler might need to configure additional chip selects using other commands (like: @command{mww} to -configure a bus and its timings) , or +configure a bus and its timings), or perhaps configure a GPIO pin that controls the ``write protect'' pin on the flash chip. The CFI driver can use a target-specific working area to significantly @@ -3720,6 +3807,15 @@ wide on a sixteen bit bus: flash bank cfi 0x00000000 0x01000000 2 2 $_TARGETNAME flash bank cfi 0x01000000 0x01000000 2 2 $_TARGETNAME @end example + +To configure one bank of 32 MBytes +built from two sixteen bit (two byte) wide parts wired in parallel +to create a thirty-two bit (four byte) bus with doubled throughput: + +@example +flash bank cfi 0x00000000 0x02000000 2 4 $_TARGETNAME +@end example + @c "cfi part_id" disabled @end deffn @@ -4407,7 +4503,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 @@ -4421,6 +4517,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}. @@ -4571,6 +4669,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 @@ -4615,7 +4739,7 @@ with the wrong ECC data can cause them to be marked as bad. @end deffn @anchor{NAND Driver List} -@section NAND Drivers, Options, and Commands +@section NAND Driver List As noted above, the @command{nand device} command allows driver-specific options and behaviors. Some controllers also activate controller-specific commands. @@ -4854,26 +4978,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 @@ -5038,9 +5173,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 @@ -5049,10 +5186,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 @@ -5242,11 +5381,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. @@ -5424,16 +5575,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. @@ -5441,30 +5590,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}) @@ -5491,49 +5655,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}; @@ -5577,8 +5705,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 @@ -5611,8 +5739,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. @@ -5621,20 +5749,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}; @@ -5783,15 +5904,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 @@ -5808,15 +5920,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; @@ -5844,7 +5947,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] @@ -5870,23 +5973,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 @@ -6471,10 +6557,8 @@ called "flash_banks". @section OpenOCD specific Global Variables -@subsection HostOS - Real Tcl has ::tcl_platform(), and platform::identify, and many other -variables. JimTCL, as implemented in OpenOCD creates $HostOS which +variables. JimTCL, as implemented in OpenOCD creates $ocd_HOSTOS which holds one of the following values: @itemize @bullet @@ -6495,91 +6579,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