X-Git-Url: https://review.openocd.org/gitweb?a=blobdiff_plain;f=doc%2Fopenocd.texi;h=68417bd7401b232f4642214beb1bacb1b3824c56;hb=c402c1166bc314761c01d7f8afb700a2b14fceb6;hp=8b7e58887bf93b845e6e7311b0cfe313156a0ca3;hpb=738b91ddb430a0b42ab8eb3ae6ba725110231713;p=openocd.git

diff --git a/doc/openocd.texi b/doc/openocd.texi
index 8b7e58887b..68417bd740 100644
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -168,7 +168,7 @@ STM32x). Preliminary support for various NAND flash controllers
 
 The OpenOCD web site provides the latest public news from the community:
 
-@uref{http://openocd.berlios.de/web/}
+@uref{http://openocd.sourceforge.net/}
 
 @section Latest User's Guide:
 
@@ -176,11 +176,11 @@ The user's guide you are now reading may not be the latest one
 available.  A version for more recent code may be available.
 Its HTML form is published irregularly at:
 
-@uref{http://openocd.berlios.de/doc/html/index.html}
+@uref{http://openocd.sourceforge.net/doc/html/index.html}
 
 PDF form is likewise published at:
 
-@uref{http://openocd.berlios.de/doc/pdf/openocd.pdf}
+@uref{http://openocd.sourceforge.net/doc/pdf/openocd.pdf}
 
 @section OpenOCD User's Forum
 
@@ -241,7 +241,7 @@ providing a Doxygen reference manual.  This document contains more
 technical information about the software internals, development
 processes, and similar documentation:
 
-@uref{http://openocd.berlios.de/doc/doxygen/index.html}
+@uref{http://openocd.sourceforge.net/doc/doxygen/html/index.html}
 
 This document is a work-in-progress, but contributions would be welcome
 to fill in the gaps.  All of the source files are provided in-tree,
@@ -252,7 +252,7 @@ listed in the Doxyfile configuration in the top of the source tree.
 The OpenOCD Developer Mailing List provides the primary means of
 communication between developers:
 
-@uref{https://lists.berlios.de/mailman/listinfo/openocd-development}
+@uref{https://lists.sourceforge.net/mailman/listinfo/openocd-devel}
 
 Discuss and submit patches to this list.
 The @file{PATCHES.txt} file contains basic information about how
@@ -372,6 +372,8 @@ Stellaris eval boards, they can be used to debug other target boards.
 @* Axiom AXM-0432 Link @url{http://www.axman.com}
 @item @b{cortino}
 @* Link @url{http://www.hitex.com/index.php?id=cortino}
+@item @b{dlp-usb1232h}
+@* Link @url{http://www.dlpdesign.com/usb/usb1232h.shtml}
 @end itemize
 
 @section USB-JTAG / Altera USB-Blaster compatibles
@@ -632,7 +634,7 @@ If all goes well you'll see output something like
 @example
 Open On-Chip Debugger 0.4.0 (2010-01-14-15:06)
 For bug reports, read
-        http://openocd.berlios.de/doc/doxygen/bugs.html
+        http://openocd.sourceforge.net/doc/doxygen/bugs.html
 Info : JTAG tap: lm3s.cpu tap/device found: 0x3ba00477
        (mfg: 0x23b, part: 0xba00, ver: 0x3)
 @end example
@@ -2321,6 +2323,43 @@ ft2232_vid_pid 0x0403 0xbdc8
 @end example
 @end deffn
 
+@deffn {Interface Driver} {remote_bitbang}
+Drive JTAG from a remote process. This sets up a UNIX or TCP socket connection
+with a remote process and sends ASCII encoded bitbang requests to that process
+instead of directly driving JTAG.
+
+The remote_bitbang driver is useful for debugging software running on
+processors which are being simulated.
+
+@deffn {Config Command} {remote_bitbang_port} number
+Specifies the TCP port of the remote process to connect to or 0 to use UNIX
+sockets instead of TCP.
+@end deffn
+
+@deffn {Config Command} {remote_bitbang_host} hostname
+Specifies the hostname of the remote process to connect to using TCP, or the
+name of the UNIX socket to use if remote_bitbang_port is 0.
+@end deffn
+
+For example, to connect remotely via TCP to the host foobar you might have
+something like:
+
+@example
+interface remote_bitbang
+remote_bitbang_port 3335
+remote_bitbang_host foobar
+@end example
+
+To connect to another process running locally via UNIX sockets with socket
+named mysocket:
+
+@example
+interface remote_bitbang
+remote_bitbang_port 0
+remote_bitbang_host mysocket
+@end example
+@end deffn
+
 @deffn {Interface Driver} {usb_blaster}
 USB JTAG/USB-Blaster compatibles over one of the userspace libraries
 for FTDI chips.  These interfaces have several commands, used to
@@ -5435,6 +5474,27 @@ in the MLC controller mode, but won't change SLC behavior.
 @end deffn
 @comment current lpc3180 code won't issue 5-byte address cycles
 
+@deffn {NAND Driver} mx3
+This driver handles the NAND controller in i.MX31. The mxc driver
+should work for this chip aswell.
+@end deffn
+
+@deffn {NAND Driver} mxc
+This driver handles the NAND controller found in Freescale i.MX
+chips. It has support for v1 (i.MX27 and i.MX31) and v2 (i.MX35).
+The driver takes 3 extra arguments, chip (@option{mx27},
+@option{mx31}, @option{mx35}), ecc (@option{noecc}, @option{hwecc})
+and optionally if bad block information should be swapped between
+main area and spare area (@option{biswap}), defaults to off.
+@example
+nand device mx35.nand mxc imx35.cpu mx35 hwecc biswap
+@end example
+@deffn Command {mxc biswap} bank_num [enable|disable]
+Turns on/off bad block information swaping from main area,
+without parameter query status.
+@end deffn
+@end deffn
+
 @deffn {NAND Driver} orion
 These controllers require an extra @command{nand device}
 parameter:  the address of the controller.