X-Git-Url: https://review.openocd.org/gitweb?p=openocd.git;a=blobdiff_plain;f=doc%2Fopenocd.texi;h=817c4f93f3f258fe205b83eeef5c7c4e3f8641cd;hp=069367d91ade58d16271afc6d263331d6f828a5d;hb=cf692abe83a90f74cb21b1864f348cd52fe26454;hpb=c73342fbe77b0d0432ce189566e0e8383f2b7493

diff --git a/doc/openocd.texi b/doc/openocd.texi
index 069367d91a..817c4f93f3 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/web/}
 
 @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/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
@@ -632,7 +632,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
@@ -1677,7 +1677,7 @@ Again using the at91sam7 as an example, this can look like:
 $_TARGETNAME configure -work-area-phys 0x00200000 \
              -work-area-size 0x4000 -work-area-backup 0
 @end example
-@pxref{Define CPU targets working in SMP}
+
 @anchor{Define CPU targets working in SMP}
 @subsection Define CPU targets working in SMP
 @cindex SMP
@@ -2321,6 +2321,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
@@ -3602,14 +3639,7 @@ At this writing, the supported CPU types and variants are:
 (Support for this is preliminary and incomplete.)
 @item @code{cortex_a8} -- this is an ARMv7 core with an MMU
 @item @code{cortex_m3} -- this is an ARMv7 core, supporting only the
-compact Thumb2 instruction set.  It supports one variant:
-@itemize @minus
-@item @code{lm3s} ... Use this 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.
-@end itemize
+compact Thumb2 instruction set.
 @item @code{dragonite} -- resembles arm966e
 @item @code{dsp563xx} -- implements Freescale's 24-bit DSP.
 (Support for this is still incomplete.)