diff options
author | zwelch <zwelch@b42882b7-edfa-0310-969c-e2dbd0fdcd60> | 2009-05-28 00:47:30 +0000 |
---|---|---|
committer | zwelch <zwelch@b42882b7-edfa-0310-969c-e2dbd0fdcd60> | 2009-05-28 00:47:30 +0000 |
commit | d9284c06118d68fe459513f816ab0b2e2d2d041d (patch) | |
tree | 8c922ea4abd50d9d3bfe9c14213b2cdd12f193b7 /doc | |
parent | 19124a34f31235c1bb6f0389112f2408f15e1f02 (diff) | |
download | riscv-openocd-d9284c06118d68fe459513f816ab0b2e2d2d041d.zip riscv-openocd-d9284c06118d68fe459513f816ab0b2e2d2d041d.tar.gz riscv-openocd-d9284c06118d68fe459513f816ab0b2e2d2d041d.tar.bz2 |
David Brownell <david-b@pacbell.net>:
Fix a bunch of PDF generation bugs in the texi:
* The "overfull" warnings are basically complaints about lines
that are too long, so they ran off the right margin of the
PDF documentation and turn into a "black blot".
* The "underfull" warnings are basically complaints about lines
that look ugly when they get filled, because the tokens are
so long that the line-break algorithm can't do anything good.
In a few cases the simplest fix seemed to be to use more appropriate
texi commands.
In other cases the fix was a content bugfix: "ocd_" not "openocd_";
and many of those "target variants" actually aren't recognized.
git-svn-id: svn://svn.berlios.de/openocd/trunk@1936 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Diffstat (limited to 'doc')
-rw-r--r-- | doc/openocd.texi | 189 |
1 files changed, 108 insertions, 81 deletions
diff --git a/doc/openocd.texi b/doc/openocd.texi index 00f9acf..224a58b 100644 --- a/doc/openocd.texi +++ b/doc/openocd.texi @@ -261,7 +261,7 @@ a FTDI FT2232 based interface: @item @b{ftdi2232} libftdi (@uref{http://www.intra2net.com/opensource/ftdi/}) @item @b{ftd2xx} libftd2xx (@uref{http://www.ftdichip.com/Drivers/D2XX.htm}) @item When using the Amontec JTAGkey, you have to get the drivers from the Amontec -homepage (@uref{http://www.amontec.com}), as the JTAGkey uses a non-standard VID/PID. +homepage (@uref{http://www.amontec.com}). The JTAGkey uses a non-standard VID/PID. @end itemize libftdi is supported under Windows. Do not use versions earlier than 0.14. @@ -320,9 +320,11 @@ should be included (among other things): @item @option{--enable-ft2232_libftdi} - An open source (free) alternative to FTDICHIP.COM ftd2xx solution (Linux, MacOS, Cygwin). @item -@option{--with-ftd2xx-win32-zipdir=PATH} - If using FTDICHIP.COM ft2232c, point at the directory where the Win32 FTDICHIP.COM 'CDM' driver zip file was unpacked. +@option{--with-ftd2xx-win32-zipdir=PATH} - If using FTDICHIP.COM ft2232c driver, +give the directory where the Win32 FTDICHIP.COM 'CDM' driver zip file was unpacked. @item -@option{--with-ftd2xx-linux-tardir=PATH} - Linux only. Equivalent of @option{--with-ftd2xx-win32-zipdir}, where you unpacked the TAR.GZ file. +@option{--with-ftd2xx-linux-tardir=PATH} - If using FTDICHIP.COM ft2232c driver +on Linux, give the directory where the Linux driver's TAR.GZ file was unpacked. @item @option{--with-ftd2xx-lib=shared|static} - Linux only. Default: static. Specifies how the FTDICHIP.COM libftd2xx driver should be linked. Note: 'static' only works in conjunction with @option{--with-ftd2xx-linux-tardir}. The 'shared' value is supported (12/26/2008), however you must manually install the required header files and shared libraries in an appropriate place. This uses ``libusb'' internally. @item @@ -369,43 +371,54 @@ files ``in an appropriate place'' As a result, there are two Below is an example build process: -1) Check out the latest version of ``openocd'' from SVN. +@enumerate +@item Check out the latest version of ``openocd'' from SVN. -2) Download & unpack either the Windows or Linux FTD2xx drivers - (@uref{http://www.ftdichip.com/Drivers/D2XX.htm}). +@item If you are using the FTDICHIP.COM driver, download +and unpack the Windows or Linux FTD2xx drivers +(@uref{http://www.ftdichip.com/Drivers/D2XX.htm}). +If you are using the libftdi driver, install that package +(e.g. @command{apt-get install libftdi} on systems with APT). @example - /home/duane/ftd2xx.win32 => the Cygwin/Win32 ZIP file contents. - /home/duane/libftd2xx0.4.16 => the Linux TAR.GZ file contents. +/home/duane/ftd2xx.win32 => the Cygwin/Win32 ZIP file contents +/home/duane/libftd2xx0.4.16 => the Linux TAR.GZ file contents @end example -3) Configure with these options: +@item Configure with options resembling the following. + +@enumerate a +@item Cygwin FTDICHIP solution: +@example +./configure --prefix=/home/duane/mytools \ + --enable-ft2232_ftd2xx \ + --with-ftd2xx-win32-zipdir=/home/duane/ftd2xx.win32 +@end example +@item Linux FTDICHIP solution: @example -Cygwin FTDICHIP solution: - ./configure --prefix=/home/duane/mytools \ - --enable-ft2232_ftd2xx \ - --with-ftd2xx-win32-zipdir=/home/duane/ftd2xx.win32 - -Linux FTDICHIP solution: - ./configure --prefix=/home/duane/mytools \ - --enable-ft2232_ftd2xx \ - --with-ft2xx-linux-tardir=/home/duane/libftd2xx0.4.16 - -Cygwin/Linux LIBFTDI solution: - Assumes: - 1a) For Windows: The Windows port of LIBUSB is in place. - 1b) For Linux: libusb has been built/installed and is in place. - - 2) And libftdi has been built and installed - Note: libftdi - relies upon libusb. - - ./configure --prefix=/home/duane/mytools \ - --enable-ft2232_libftdi - +./configure --prefix=/home/duane/mytools \ + --enable-ft2232_ftd2xx \ + --with-ft2xx-linux-tardir=/home/duane/libftd2xx0.4.16 @end example -4) Then just type ``make'', and perhaps ``make install''. +@item Cygwin/Linux LIBFTDI solution ... assuming that +@itemize +@item For Windows -- that the Windows port of LIBUSB is in place. +@item For Linux -- that libusb has been built/installed and is in place. +@item That libftdi has been built and installed (relies on libusb). +@end itemize + +Then configure the libftdi solution like this: + +@example +./configure --prefix=/home/duane/mytools \ + --enable-ft2232_libftdi +@end example +@end enumerate + +@item Then just type ``make'', and perhaps ``make install''. +@end enumerate @section Miscellaneous Configure Options @@ -467,9 +480,10 @@ and has a built in relay to power cycle targets remotely. There are many USB JTAG dongles on the market, many of them are based on a chip from ``Future Technology Devices International'' (FTDI) -known as the FTDI FT2232. - -See: @url{http://www.ftdichip.com} or @url{http://www.ftdichip.com/Products/FT2232H.htm} +known as the FTDI FT2232; this is a USB full speed (12 Mbps) chip. +See: @url{http://www.ftdichip.com} for more information. +In summer 2009, USB high speed (480 Mbps) versions of these FTDI +chips are starting to become available in JTAG adapters. As of 28/Nov/2008, the following are supported: @@ -489,7 +503,9 @@ As of 28/Nov/2008, the following are supported: @item @b{flyswatter} @* See: @url{http://www.tincantools.com} @item @b{turtelizer2} -@* See: @url{http://www.ethernut.de}, or @url{http://www.ethernut.de/en/hardware/turtelizer/index.html} +@* See: +@uref{http://www.ethernut.de/en/hardware/turtelizer/index.html, Turtelizer 2}, or +@url{http://www.ethernut.de} @item @b{comstick} @* Link: @url{http://www.hitex.com/index.php?id=383} @item @b{stm32stick} @@ -563,7 +579,8 @@ produced, PDF schematics are easily found and it is easy to make. @* Link: @url{http://www.gateworks.com/products/avila_accessories/gw16042.php} @item @b{Wiggler2} -@* Link: @url{http://www.ccac.rwth-aachen.de/~michaels/index.php/hardware/armjtag} +@*@uref{http://www.ccac.rwth-aachen.de/@/~michaels/@/index.php/hardware/@/armjtag, +Improved parallel-port wiggler-style JTAG adapter} @item @b{Wiggler_ntrst_inverted} @* Yet another variation - See the source code, src/jtag/parport.c @@ -581,12 +598,13 @@ produced, PDF schematics are easily found and it is easy to make. @* Unknown. @item @b{Lattice} -@* ispDownload from Lattice Semiconductor @url{http://www.latticesemi.com/lit/docs/devtools/dlcable.pdf} +@* ispDownload from Lattice Semiconductor +@url{http://www.latticesemi.com/lit/docs/@/devtools/dlcable.pdf} @item @b{flashlink} -@* From ST Microsystems, link: -@url{http://www.st.com/stonline/products/literature/um/7889.pdf} -Title: FlashLINK JTAG programing cable for PSD and uPSD +@* From ST Microsystems; +@uref{http://www.st.com/stonline/@/products/literature/um/7889.pdf, +FlashLINK JTAG programing cable for PSD and uPSD} @end itemize @@ -717,7 +735,7 @@ You can use a series of ``-f filename'' options on the command line, OpenOCD will read each filename in sequence, for example: @example - openocd -f file1.cfg -f file2.cfg -f file2.cfg +openocd -f file1.cfg -f file2.cfg -f file2.cfg @end example You can also intermix various commands with the ``-c'' command line @@ -806,11 +824,6 @@ A preconfigured interface file should exist for every interface in use today, that said, perhaps some interfaces have only been used by the sole developer who created it. -@b{FIXME/NOTE:} We need to add support for a variable like Tcl variable -tcl_platform(platform), it should be called jim_platform (because it -is jim, not real tcl) and it should contain 1 of 3 words: ``linux'', -``cygwin'' or ``mingw'' - Interface files should be found in @t{$(INSTALLDIR)/lib/openocd/interface} @section Board Config Files @@ -881,8 +894,10 @@ error or warning like this. The hope is that this will help to pinpoint problems in OpenOCD configurations. @example -Info: JTAG tap: sam7x256.cpu tap/device found: 0x3f0f0f0f (Manufacturer: 0x787, Part: 0xf0f0, Version: 0x3) -Error: ERROR: Tap: sam7x256.cpu - Expected id: 0x12345678, Got: 0x3f0f0f0f +Info: JTAG tap: sam7x256.cpu tap/device found: 0x3f0f0f0f + (Manufacturer: 0x787, Part: 0xf0f0, Version: 0x3) +Error: ERROR: Tap: sam7x256.cpu - Expected id: 0x12345678, + Got: 0x3f0f0f0f Error: ERROR: expected: mfg: 0x33c, part: 0x2345, ver: 0x1 Error: ERROR: got: mfg: 0x787, part: 0xf0f0, ver: 0x3 @end example @@ -989,7 +1004,8 @@ After the ``defaults'' are choosen [see above] the taps are created. @example # for an ARM7TDMI. set _TARGETNAME [format "%s.cpu" $_CHIPNAME] -jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID +jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf \ + -expected-id $_CPUTAPID @end example @b{COMPLEX example:} @@ -1007,14 +1023,16 @@ if @{ [info exists FLASHTAPID ] @} @{ @} else @{ set _FLASHTAPID 0x25966041 @} -jtag newtap $_CHIPNAME flash -irlen 8 -ircapture 0x1 -irmask 0x1 -expected-id $_FLASHTAPID +jtag newtap $_CHIPNAME flash -irlen 8 -ircapture 0x1 -irmask 0x1 \ + -expected-id $_FLASHTAPID if @{ [info exists CPUTAPID ] @} @{ set _CPUTAPID $CPUTAPID @} else @{ set _CPUTAPID 0x25966041 @} -jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0xf -irmask 0xe -expected-id $_CPUTAPID +jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0xf -irmask 0xe \ + -expected-id $_CPUTAPID if @{ [info exists BSTAPID ] @} @{ @@ -1022,7 +1040,8 @@ if @{ [info exists BSTAPID ] @} @{ @} else @{ set _BSTAPID 0x1457f041 @} -jtag newtap $_CHIPNAME bs -irlen 5 -ircapture 0x1 -irmask 0x1 -expected-id $_BSTAPID +jtag newtap $_CHIPNAME bs -irlen 5 -ircapture 0x1 -irmask 0x1 \ + -expected-id $_BSTAPID set _TARGETNAME [format "%s.cpu" $_CHIPNAME] @end example @@ -1145,7 +1164,6 @@ can type a Tcl for() loop, set variables, etc. @* See: @xref{Tcl Crash Course}. @end itemize - @node Daemon Configuration @chapter Daemon Configuration @cindex initialization @@ -2087,7 +2105,10 @@ creates and invokes small procedure. The second inlines the procedure. reset halt @} mychip.cpu configure -event gdb-attach my_attach_proc - mychip.cpu configure -event gdb-attach @{ puts "Reset..." ; reset halt @} + mychip.cpu configure -event gdb-attach @{ + puts "Reset..." + reset halt + @} @end example @section Current Events @@ -2256,27 +2277,16 @@ Example: @section Target Variants @itemize @bullet -@item @b{arm7tdmi} -@* Unknown (please write me) -@item @b{arm720t} -@* Unknown (please write me) (similar to arm7tdmi) -@item @b{arm9tdmi} -@* Variants: @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 +@* Use variant @option{lm3s} when debugging older Stellaris 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} +@*Supported variants are +@option{ixp42x}, @option{ixp45x}, @option{ixp46x}, +@option{pxa250}, @option{pxa255}, @option{pxa26x}. @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 @@ -3536,8 +3546,13 @@ be used to access files on PCs (either the developer's PC or some other PC). The way this works on the ZY1000 is to prefix a filename by "/tftp/ip/" and append the TFTP path on the TFTP -server (tftpd). E.g. "load_image /tftp/10.0.0.96/c:\temp\abc.elf" will -load c:\temp\abc.elf from the developer pc (10.0.0.96) into memory as +server (tftpd). For example, + +@example +load_image /tftp/10.0.0.96/c:\temp\abc.elf +@end example + +will load c:\temp\abc.elf from the developer pc (10.0.0.96) into memory as if the file was hosted on the embedded host. In order to achieve decent performance, you must choose a TFTP server @@ -3567,7 +3582,8 @@ Detailed information about each section can be found at OpenOCD configuration. To start OpenOCD with a target script for the AT91R40008 CPU and reset the CPU upon startup of the OpenOCD daemon. @example -openocd -f interface/parport.cfg -f target/at91r40008.cfg -c init -c reset +openocd -f interface/parport.cfg -f target/at91r40008.cfg \ + -c "init" -c "reset" @end example @@ -3585,7 +3601,8 @@ instance GDB 6.3 has a known bug that produces bogus memory access errors, which has since been fixed: look up 1836 in @url{http://sourceware.org/cgi-bin/gnatsweb.pl?database=gdb} -@*OpenOCD can communicate with GDB in two ways: +OpenOCD can communicate with GDB in two ways: + @enumerate @item A socket (TCP/IP) connection is typically started as follows: @@ -3603,7 +3620,7 @@ Using this method has the advantage of GDB starting/stopping OpenOCD for the deb session. @end enumerate -@*To see a list of available OpenOCD commands type @option{monitor help} on the +To list the available OpenOCD commands type @command{monitor help} on the GDB command line. OpenOCD supports the gdb @option{qSupported} packet, this enables information @@ -3707,8 +3724,9 @@ should be passed in to the proc in question. By low-level, the intent is a human would not directly use these commands. -Low-level commands are (should be) prefixed with "openocd_", e.g. openocd_flash_banks -is the low level API upon which "flash banks" is implemented. +Low-level commands are (should be) prefixed with "ocd_", e.g. +@command{ocd_flash_banks} +is the low level API upon which @command{flash banks} is implemented. @itemize @bullet @item @b{ocd_mem2array} <@var{varname}> <@var{width}> <@var{addr}> <@var{nelems}> @@ -3745,6 +3763,13 @@ holds one of the following values: Note: 'winxx' was choosen because today (March-2009) no distinction is made between Win32 and Win64. +@quotation Note +We should add support for a variable like Tcl variable +@code{tcl_platform(platform)}, it should be called +@code{jim_platform} (because it +is jim, not real tcl). +@end quotation + @node Upgrading @chapter Deprecated/Removed Commands @cindex Deprecated/Removed Commands @@ -3753,7 +3778,8 @@ Certain OpenOCD commands have been deprecated/removed during the various revisio @itemize @bullet @item @b{arm7_9 fast_writes} @cindex arm7_9 fast_writes -@*use @option{arm7_9 fast_memory_access} command with same args. @xref{arm7_9 fast_memory_access}. +@*Use @command{arm7_9 fast_memory_access} instead. +@xref{arm7_9 fast_memory_access}. @item @b{arm7_9 force_hw_bkpts} @cindex arm7_9 force_hw_bkpts @*Use @command{gdb_breakpoint_override} instead. Note that GDB will use hardware breakpoints @@ -4451,7 +4477,8 @@ finally issues the init and reset commands. The communication speed is set to 10kHz for reset and 8MHz for post reset. @example -openocd -f interface/parport.cfg -f target/str710.cfg -c "init" -c "reset" +openocd -f interface/parport.cfg -f target/str710.cfg \ + -c "init" -c "reset" @end example To list the target scripts available: |