openocd-commit — OpenOCD commit maling list - read only

[Openocd-svn] r2513 - trunk/src/jtag

[ntfreak at B. <nt...@ma...>]

Author: ntfreak
Date: 2009-07-13 08:36:51 +0200 (Mon, 13 Jul 2009)
New Revision: 2513

Modified:
   trunk/src/jtag/jlink.c
Log:
Gary Carlson <gca...@ca...>
Spencer Oliver <sp...@sp...>

- fix jlink win32/linux/darwin startup issues
- see https://lists.berlios.de/pipermail/openocd-development/2009-July/009438.html

Modified: trunk/src/jtag/jlink.c
===================================================================
--- trunk/src/jtag/jlink.c	2009-07-12 19:32:22 UTC (rev 2512)
+++ trunk/src/jtag/jlink.c	2009-07-13 06:36:51 UTC (rev 2513)
@@ -835,13 +835,37 @@
 	return ERROR_OK;
 }
 
+static struct usb_device* find_jlink_device(void)
+{
+	struct usb_bus *busses;
+	struct usb_bus *bus;
+	struct usb_device *dev;
+
+	usb_find_busses();
+	usb_find_devices();
+
+	busses = usb_get_busses();
+
+	/* find jlink_jtag device in usb bus */
+
+	for (bus = busses; bus; bus = bus->next)
+	{
+		for (dev = bus->devices; dev; dev = dev->next)
+		{
+			if ((dev->descriptor.idVendor == VID) && (dev->descriptor.idProduct == PID)) {
+				return dev;
+			}
+		}
+	}
+
+	return NULL;
+}
+
 /*****************************************************************************/
 /* JLink USB low-level functions */
 
 static jlink_jtag_t* jlink_usb_open()
 {
-	struct usb_bus *busses;
-	struct usb_bus *bus;
 	struct usb_device *dev;
 
 	jlink_jtag_t *result;
@@ -849,56 +873,81 @@
 	result = (jlink_jtag_t*) malloc(sizeof(jlink_jtag_t));
 
 	usb_init();
-	usb_find_busses();
-	usb_find_devices();
 
-	busses = usb_get_busses();
+	if ((dev = find_jlink_device()) == NULL) {
+		free(result);
+		return NULL;
+	}
 
-	/* find jlink_jtag device in usb bus */
+	result->usb_handle = usb_open(dev);
 
-	for (bus = busses; bus; bus = bus->next)
+	if (result->usb_handle)
 	{
-		for (dev = bus->devices; dev; dev = dev->next)
+	
+		/* BE ***VERY CAREFUL*** ABOUT MAKING CHANGES IN THIS AREA!!!!!!!!!!!
+		 * The behavior of libusb is not completely consistent across Windows, Linux, and Mac OS X platforms.  The actions taken
+		 * in the following compiler conditionals may not agree with published documentation for libusb, but were found
+		 * to be necessary through trials and tribulations.  Even little tweaks can break one or more platforms, so if you do make changes
+		 * test them carefully on all platforms before committing them!
+		 */
+
+#if IS_WIN32 == 0
+
+		usb_reset(result->usb_handle);
+
+#if IS_DARWIN == 0
+
+		int timeout = 5;
+
+		/* reopen jlink after usb_reset
+		 * on win32 this may take a second or two to re-enumerate */
+		while ((dev = find_jlink_device()) == NULL)
 		{
-			if ((dev->descriptor.idVendor == VID) && (dev->descriptor.idProduct == PID))
-			{
-				result->usb_handle = usb_open(dev);
-				
-				/*
-				 *	Some j-link dongles experience intermittent communication issues at startup to varying degrees
-				 *	depending on the host operating system.  Troubleshooting this problem all the way back to libusb
-				 *	revealed that without a usb reset, the hardware can start in an uncertain state causing a litany
-				 *	of annoying problems.  The next step was added to the original code to address this problem.
-				 */
-				
-				usb_reset(result->usb_handle);
+			usleep(1000);
+			timeout--;
+			if (!timeout) {
+				break;
+			}
+		}
 
-				/* usb_set_configuration required under win32 */
-				usb_set_configuration(result->usb_handle, dev->config[0].bConfigurationValue);
-				usb_claim_interface(result->usb_handle, 0);
+		if (dev == NULL)
+		{
+			free(result);
+			return NULL;
+		}
 
+		result->usb_handle = usb_open(dev);
+#endif
+
+#endif
+
+		if (result->usb_handle)
+		{
+			/* usb_set_configuration required under win32 */
+			usb_set_configuration(result->usb_handle, dev->config[0].bConfigurationValue);
+			usb_claim_interface(result->usb_handle, 0);
+
 #if 0
-				/*
-				 * This makes problems under Mac OS X. And is not needed
-				 * under Windows. Hopefully this will not break a linux build
-				 */
-				usb_set_altinterface(result->usb_handle, 0);
+			/*
+			 * This makes problems under Mac OS X. And is not needed
+			 * under Windows. Hopefully this will not break a linux build
+			 */
+			usb_set_altinterface(result->usb_handle, 0);
 #endif
-				struct usb_interface *iface = dev->config->interface;
-				struct usb_interface_descriptor *desc = iface->altsetting;
-				for (int i = 0; i < desc->bNumEndpoints; i++)
-				{
-					uint8_t epnum = desc->endpoint[i].bEndpointAddress;
-					bool is_input = epnum & 0x80;
-					LOG_DEBUG("usb ep %s %02x", is_input ? "in" : "out", epnum);
-					if (is_input)
-						jlink_read_ep = epnum;
-					else
-						jlink_write_ep = epnum;
-				}
+			struct usb_interface *iface = dev->config->interface;
+			struct usb_interface_descriptor *desc = iface->altsetting;
+			for (int i = 0; i < desc->bNumEndpoints; i++)
+			{
+				uint8_t epnum = desc->endpoint[i].bEndpointAddress;
+				bool is_input = epnum & 0x80;
+				LOG_DEBUG("usb ep %s %02x", is_input ? "in" : "out", epnum);
+				if (is_input)
+					jlink_read_ep = epnum;
+				else
+					jlink_write_ep = epnum;
+			}
 
-				return result;
-			}
+			return result;
 		}
 	}
 

[Openocd-svn] r2512 - trunk

[<oh...@ma...>]

Author: oharboe
Date: 2009-07-12 21:32:22 +0200 (Sun, 12 Jul 2009)
New Revision: 2512

Modified:
   trunk/README
Log:
Xiaofan Chen <xia...@gm...> document my experiment
with MinGW cross build.


Modified: trunk/README
===================================================================
--- trunk/README	2009-07-12 19:31:13 UTC (rev 2511)
+++ trunk/README	2009-07-12 19:32:22 UTC (rev 2512)
@@ -416,4 +416,70 @@
 
 2) Run './configure --enable-maintainer-mode' with other options.
 
+The following URL is a good reference if you want to build OpenOCD
+under cygwin.
+http://forum.sparkfun.com/viewtopic.php?t=11221
 
+Alternatively you can build the Windows binary under Linux using
+MinGW cross compiler. The following documents some tips of
+using this cross build option.
+
+a) libusb-win32
+You can choose to use the libusb-win32 binary distribution from
+its Sourceforge page. As of this writing, the latest version
+is 0.1.12.2. This is the recommend version to use since it fixed
+an issue with USB composite device and this is important for FTDI
+based JTAG debuggers.
+http://sourceforge.net/projects/libusb-win32/
+
+You need to download the libusb-win32-device-bin-0.1.12.2.tar.gz 
+package. Please extract this file into a temp directory. 
+
+Copy the file libusb-win32-device-bin-0.1.12.2\include\usb.h
+to your MinGW include directory.
+
+Copy the library libusb-win32-device-bin-0.1.12.2\lib\gcc\libusb.a
+to your MinGW library directory.
+
+Take note that different Linux distros often have different
+MinGW installation directory. Some of them also put the
+library and include into a seperate sys-root directory.
+
+If there is a new svn version of libusb-win32, you can build it
+as well. 
+
+This is the instrunction from the libusb-win32 Makefile.
+# If you're cross-compiling and your mingw32 tools are called
+# i586-mingw32msvc-gcc and so on, then you can compile libusb-win32
+# by running
+#    make host_prefix=i586-mingw32msvc all
+
+b) libftdi
+libftdi source codes can be download from the following website.
+http://www.intra2net.com/en/developer/libftdi/download.php
+
+It does not provide Windows binary. You can build it from the
+source tarball or the git tree.
+
+If you are using the git tree, the following is the instruction 
+from README.mingw. You need to have cmake installed.
+- Edit Toolchain-mingw32.cmake to point to the correct MinGW 
+installation.
+- Create a build directory like "mkdir build-win32", e.g in ../libftdi/
+- cd in that directory and run  
+  "cmake -DCMAKE_TOOLCHAIN_FILE=../Toolchain-mingw32.cmake .."
+- Copy src/ftdi.h to your MinGW include directory.
+- Copy build-win32/src/*.a to your MinGW lib directory.
+
+c) OpenOCD
+Now you can build OpenOCD under Linux using MinGW.
+You need to use --host=your_mingW_prefix in the configure option.
+
+Example for libftdi (in one line, tested under Ubuntu 9.04):
+./configure --host=i586-mingw32msvc --enable-maintainer-mode 
+--disable-shared --enable-ft2232_libftdi
+
+Example for ftd2xx (in one line, tested under Ubuntu 9.04)
+./configure --host=i586-mingw32msvc --enable-maintainer-mode 
+--disable-shared --enable-ft2232_ftd2xx 
+--with-ftd2xx-win32-zipdir=/home/mcuee/Desktop/build/openocd/libftd2xx-win32

[Openocd-svn] r2511 - trunk/contrib

[<oh...@ma...>]

Author: oharboe
Date: 2009-07-12 21:31:13 +0200 (Sun, 12 Jul 2009)
New Revision: 2511

Removed:
   trunk/contrib/libftdi/
Log:
Xiaofan Chen <xia...@gm...> retire obsolete patch. OpenOCD only supports 0.14 and newer and the patch was for 0.14.

[Openocd-svn] r2510 - trunk/src/target

[<oh...@ma...>]

Author: oharboe
Date: 2009-07-12 21:29:08 +0200 (Sun, 12 Jul 2009)
New Revision: 2510

Modified:
   trunk/src/target/cortex_m3.c
Log:
Magnus Lundin  Thc cortex_m3_poll function does not identify that a target is running unless we transition from RESET.

This patch correctly identifies a running target.

Patch made a tad more palatable by David Brownell <da...@pa...>


Modified: trunk/src/target/cortex_m3.c
===================================================================
--- trunk/src/target/cortex_m3.c	2009-07-12 14:11:43 UTC (rev 2509)
+++ trunk/src/target/cortex_m3.c	2009-07-12 19:29:08 UTC (rev 2510)
@@ -512,16 +512,19 @@
 		}
 	}
 
-	/*
-	if (cortex_m3->dcb_dhcsr & S_SLEEP)
-		target->state = TARGET_SLEEP;
-	*/
+	/* REVISIT when S_SLEEP is set, it's in a Sleep or DeepSleep state.
+	 * How best to model low power modes?
+	 */
 
-#if 0
-	/* Read Debug Fault Status Register, added to figure out the lockup when running flashtest.script  */
-	mem_ap_read_atomic_u32(swjdp, NVIC_DFSR, &cortex_m3->nvic_dfsr);
-	LOG_DEBUG("dcb_dhcsr 0x%x, nvic_dfsr 0x%x, target->state: %s", cortex_m3->dcb_dhcsr, cortex_m3->nvic_dfsr, target_state_name(target));
-#endif
+	if (target->state == TARGET_UNKNOWN)
+	{
+		/* check if processor is retiring instructions */
+		if (cortex_m3->dcb_dhcsr & S_RETIRE_ST)
+		{
+			target->state = TARGET_RUNNING;
+			return ERROR_OK;
+		}
+	}
 
 	return ERROR_OK;
 }

[Openocd-svn] r2509 - trunk/tcl/interface

[<oh...@ma...>]

Author: oharboe
Date: 2009-07-12 16:11:43 +0200 (Sun, 12 Jul 2009)
New Revision: 2509

Modified:
   trunk/tcl/interface/usbprog.cfg
Log:
Peter Denison <op...@ma...> workaround for broken USBprog w/short tms sequences

Modified: trunk/tcl/interface/usbprog.cfg
===================================================================
--- trunk/tcl/interface/usbprog.cfg	2009-07-12 14:08:16 UTC (rev 2508)
+++ trunk/tcl/interface/usbprog.cfg	2009-07-12 14:11:43 UTC (rev 2509)
@@ -5,4 +5,6 @@
 #
 
 interface usbprog
-
+# USBprog is broken w/short tms sequences, this is a workaround
+# until the C code can be fixed.
+tms_sequence long
\ No newline at end of file

[Openocd-svn] r2508 - trunk/doc

[<oh...@ma...>]

Author: oharboe
Date: 2009-07-12 16:08:16 +0200 (Sun, 12 Jul 2009)
New Revision: 2508

Modified:
   trunk/doc/openocd.texi
Log:
David Brownell <da...@pa...> Mention how parallel clock voting implementations of RTCK work,
and reference TI's free VHDL code.

Modified: trunk/doc/openocd.texi
===================================================================
--- trunk/doc/openocd.texi	2009-07-11 02:01:22 UTC (rev 2507)
+++ trunk/doc/openocd.texi	2009-07-12 14:08:16 UTC (rev 2508)
@@ -5661,6 +5661,18 @@
 time. One can set a break point or halt the system in the deep power
 down code, slow step out until the system speeds up.
 
+Note that adaptive clocking may also need to work at the board level,
+when a board-level scan chain has multiple chips.
+Parallel clock voting schemes are good way to implement this,
+both within and between chips, and can easily be implemented
+with a CPLD.
+It's not difficult to have logic fan a module's input TCK signal out
+to each TAP in the scan chain, and then wait until each TAP's RTCK comes
+back with the right polarity before changing the output RTCK signal.
+Texas Instruments makes some clock voting logic available
+for free (with no support) in VHDL form; see
+@url{http://tiexpressdsp.com/index.php/Adaptive_Clocking}
+
 @b{Solution #2 - Always works - but may be slower}
 
 Often this is a perfectly acceptable solution.

[Openocd-svn] r2507 - trunk/src/jtag

[<du...@ma...>]

Author: duane
Date: 2009-07-11 04:01:22 +0200 (Sat, 11 Jul 2009)
New Revision: 2507

Modified:
   trunk/src/jtag/presto.c
Log:
Simple warning fix

Modified: trunk/src/jtag/presto.c
===================================================================
--- trunk/src/jtag/presto.c	2009-07-10 08:47:10 UTC (rev 2506)
+++ trunk/src/jtag/presto.c	2009-07-11 02:01:22 UTC (rev 2507)
@@ -239,7 +239,7 @@
 			LOG_DEBUG("FT_Open failed: %i", (int)presto->status);
 			continue;
 		}
-		LOG_DEBUG("FTDI device %i open", i);
+		LOG_DEBUG("FTDI device %i open", (int)i);
 
 		if ((presto->status = FT_GetDeviceInfo(presto->handle, &device, &vidpid,
 				presto->serial, devname, NULL)) == FT_OK)
@@ -251,7 +251,7 @@
 		else
 			LOG_DEBUG("FT_GetDeviceInfo failed: %lu", presto->status);
 
-		LOG_DEBUG("FTDI device %i does not match, closing", i);
+		LOG_DEBUG("FTDI device %i does not match, closing", (int)i);
 		FT_Close(presto->handle);
 		presto->handle = (FT_HANDLE)INVALID_HANDLE_VALUE;
 	}

[Openocd-svn] r2506 - trunk

[oharboe at B. <oh...@ma...>]

Author: oharboe
Date: 2009-07-10 10:47:10 +0200 (Fri, 10 Jul 2009)
New Revision: 2506

Modified:
   trunk/TODO
Log:
wrote up workaround for xscale/debug_handler.bin bug

Modified: trunk/TODO
===================================================================
--- trunk/TODO	2009-07-10 08:46:12 UTC (rev 2505)
+++ trunk/TODO	2009-07-10 08:47:10 UTC (rev 2506)
@@ -100,7 +100,8 @@
 
 - general layer cleanup: @par
   https://lists.berlios.de/pipermail/openocd-development/2009-May/006590.html
-- regression: xscale does not place debug_handler.bin into the right spot: @par
+- regression: xscale does not place debug_handler.bin into the right spot. workaround:
+  use -s option on command line to place xscale/debug_handler.bin in search path @par
   https://lists.berlios.de/pipermail/openocd-development/2009-July/009338.html
 - bug: either USBprog is broken with new tms sequence or there is a general
   problem with XScale and the new tms sequence. Workaround: use "tms_sequence long"

[Openocd-svn] r2505 - trunk

[oharboe at B. <oh...@ma...>]

Author: oharboe
Date: 2009-07-10 10:46:12 +0200 (Fri, 10 Jul 2009)
New Revision: 2505

Modified:
   trunk/TODO
Log:
noted XScale (or USBProg) problem

Modified: trunk/TODO
===================================================================
--- trunk/TODO	2009-07-10 07:21:12 UTC (rev 2504)
+++ trunk/TODO	2009-07-10 08:46:12 UTC (rev 2505)
@@ -102,6 +102,10 @@
   https://lists.berlios.de/pipermail/openocd-development/2009-May/006590.html
 - regression: xscale does not place debug_handler.bin into the right spot: @par
   https://lists.berlios.de/pipermail/openocd-development/2009-July/009338.html
+- bug: either USBprog is broken with new tms sequence or there is a general
+  problem with XScale and the new tms sequence. Workaround: use "tms_sequence long"
+  @par
+  https://lists.berlios.de/pipermail/openocd-development/2009-July/009426.html
 - regression: "reset halt" between 729(works) and 788(fails): @par
 https://lists.berlios.de/pipermail/openocd-development/2009-July/009206.html
 - ARM923EJS:

[Openocd-svn] r2504 - in trunk/tcl: board target

[oharboe at B. <oh...@ma...>]

Author: oharboe
Date: 2009-07-10 09:21:12 +0200 (Fri, 10 Jul 2009)
New Revision: 2504

Added:
   trunk/tcl/board/ek-lm3s3748.cfg
Modified:
   trunk/tcl/target/lm3s3748.cfg
Log:
David Brownell <da...@pa...> split EK board support out
from the target CPU support .

Added: trunk/tcl/board/ek-lm3s3748.cfg
===================================================================
--- trunk/tcl/board/ek-lm3s3748.cfg	2009-07-08 22:26:42 UTC (rev 2503)
+++ trunk/tcl/board/ek-lm3s3748.cfg	2009-07-10 07:21:12 UTC (rev 2504)
@@ -0,0 +1,17 @@
+# Stellaris lm3s3748 Evaluation Kit
+#  http://www.luminarymicro.com/products/lm3s3748_usb_h_d_evaluation_kits.html
+
+# NOTE:  to use the on-board FT2232 JTAG interface:
+#  source [find interface/luminary.cfg]
+
+source [find target/lm3s3748.cfg]
+
+# LM3S parts don't support RTCK
+jtag_khz 500
+
+jtag_nsrst_delay 100
+jtag_ntrst_delay 100
+
+# Board has only srst
+reset_config srst_only
+

Modified: trunk/tcl/target/lm3s3748.cfg
===================================================================
--- trunk/tcl/target/lm3s3748.cfg	2009-07-08 22:26:42 UTC (rev 2503)
+++ trunk/tcl/target/lm3s3748.cfg	2009-07-10 07:21:12 UTC (rev 2504)
@@ -1,7 +1,4 @@
-# Script for luminary lm3s3748
-#
-# NB! work in progress! Duplicated from lm3s811.cfg, but does
-# it need modification??
+# TI/Luminary Stellaris lm3s3748
 
 if { [info exists CHIPNAME] } {	
    set  _CHIPNAME $CHIPNAME    
@@ -19,31 +16,21 @@
 if { [info exists CPUTAPID ] } {
    set _CPUTAPID $CPUTAPID
 } else {
-  # force an error till we get a good number
    set _CPUTAPID 0x3ba00477
 }
 
-# RCLK 
-jtag_khz 500
-
-jtag_nsrst_delay 100
-jtag_ntrst_delay 100
-
-#lm3s3748 Evaluation Board has only srst
-reset_config srst_only
-
-#jtag scan chain
+# JTAG scan chain
 jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 1 -irmask 0xf -expected-id $_CPUTAPID
 
+# The "lm3s" variant works around an erratum when using Rev A of "DustDevil"
+# parts (third generation, includes LM3S3748).  It keeps the debug registers
+# from being cleared, by using software reset not SRST; NOP on newer revs.
+set _TARGETNAME $_CHIPNAME.cpu
+target create $_TARGETNAME cortex_m3 -endian $_ENDIAN \
+	-chain-position $_TARGETNAME -variant lm3s
 
-# the luminary variant causes a software reset rather than asserting SRST
-# this stops the debug registers from being cleared
-# this will be fixed in later revisions of silicon
-set _TARGETNAME [format "%s.cpu" $_CHIPNAME]
-target create $_TARGETNAME cortex_m3 -endian $_ENDIAN -chain-position $_TARGETNAME -variant lm3s
+# 8k working area at base of ram, not backed up
+$_TARGETNAME configure -work-area-phys 0x20000000 -work-area-size 0x2000
 
-# 8k working area at base of ram
-$_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x20000000 -work-area-size 0x2000 -work-area-backup 0
-
-#flash configuration
+# flash configuration -- one bank of 128K
 flash bank stellaris 0 0 0 0 0

[Openocd-svn] r2503 - trunk/doc/manual

[<zw...@ma...>]

Author: zwelch
Date: 2009-07-09 00:26:42 +0200 (Thu, 09 Jul 2009)
New Revision: 2503

Modified:
   trunk/doc/manual/style.txt
Log:
Add style rule to avoid combining assignment and logical tests.


Modified: trunk/doc/manual/style.txt
===================================================================
--- trunk/doc/manual/style.txt	2009-07-08 22:26:36 UTC (rev 2502)
+++ trunk/doc/manual/style.txt	2009-07-08 22:26:42 UTC (rev 2503)
@@ -107,6 +107,20 @@
 	...
 }
 @endcode
+- Separate assignment and logical test statements.  In other words, you
+should write statements like the following:
+@code
+// separate statements should be preferred
+result = foo();
+if (ERROR_OK != result)
+	...
+@endcode
+More directly, do @b not combine these kinds of statements:
+@code
+// Combined statements should be avoided
+if (ERROR_OK != (result = foo()))
+	return result;
+@endcode
 
  */
 /** @page styledoxygen Doxygen Style Guide

[Openocd-svn] r2502 - trunk

[<zw...@ma...>]

Author: zwelch
Date: 2009-07-09 00:26:36 +0200 (Thu, 09 Jul 2009)
New Revision: 2502

Modified:
   trunk/README
Log:
Add section to provide some documentation for cross-compiling.


Modified: trunk/README
===================================================================
--- trunk/README	2009-07-08 22:26:29 UTC (rev 2501)
+++ trunk/README	2009-07-08 22:26:36 UTC (rev 2502)
@@ -166,6 +166,29 @@
 final (optional) step, ``make install'', places all of the files in the
 required location.
 
+Cross-Compiling Options
+-----------------------
+
+To cross-compile, you must specify both --build and --host options to
+the 'configure' script.  For example, you can configure OpenOCD to
+cross-compile on a x86 Linux host to run on Windows (MinGW32), you could
+use the following configuration options:
+
+  ./configure --build=i686-pc-linux-gnu --host=i586-mingw32msvc ... 
+
+Likewise, the following options allow OpenOCD to be cross-compiled for
+an ARM target on the same x86 host:
+
+  ./configure --build=i686-pc-linux-gnu --host=arm-elf ...
+
+Both must be specified to work around bugs in autoconf.
+
+Scripts for producing ARM cross-compilers can be found on the web with a
+little searching.  A script to produce an x86 Linux-hosted MinGW32
+cross-compiler can be downloaded from the following URL:
+
+  http://www.mingw.org/wiki/LinuxCrossMinGW
+
 Configuration Options
 ---------------------
 

[Openocd-svn] r2501 - trunk/doc/manual/primer

[<zw...@ma...>]

Author: zwelch
Date: 2009-07-09 00:26:29 +0200 (Thu, 09 Jul 2009)
New Revision: 2501

Modified:
   trunk/doc/manual/primer/patches.txt
Log:
Add microscopic style guide at the end of the PATCH primer.


Modified: trunk/doc/manual/primer/patches.txt
===================================================================
--- trunk/doc/manual/primer/patches.txt	2009-07-08 22:26:20 UTC (rev 2500)
+++ trunk/doc/manual/primer/patches.txt	2009-07-08 22:26:29 UTC (rev 2501)
@@ -204,6 +204,19 @@
 work on the project voluntarily and without compensation for the time
 that they spend doing these tasks.
 
+@section primerpatchguide Guidelines for Submitting Patches
+
+- Each patch file should contain:
+  - A commit description that describes all of the changes.
+  - A separator line that contains three hyphens: <code>---</code>
+  - A summary of the changes produced by diffstat (optional)
+  - Another separator line (optional)
+  - The actual patch contents, containing a single change.
+
+- Each patch series should include:
+  - A summary of the patches in the series.
+  - Logically-related patches that contain incremental changes.
+
  */
 /** @file
 This file contains the @ref primerpatches page.

[Openocd-svn] r2500 - trunk

[<zw...@ma...>]

Author: zwelch
Date: 2009-07-09 00:26:20 +0200 (Thu, 09 Jul 2009)
New Revision: 2500

Modified:
   trunk/BUGS
   trunk/PATCHES
   trunk/TODO
Log:
Add comments to top-level files to "excuse" their Doxygen markup.


Modified: trunk/BUGS
===================================================================
--- trunk/BUGS	2009-07-08 18:29:03 UTC (rev 2499)
+++ trunk/BUGS	2009-07-08 22:26:20 UTC (rev 2500)
@@ -1,3 +1,4 @@
+// This file is part of the Doyxgen Developer Manual
 /** @page bugs Bug Reporting
 
 Please report bugs by subscribing to the OpenOCD mailing list and

Modified: trunk/PATCHES
===================================================================
--- trunk/PATCHES	2009-07-08 18:29:03 UTC (rev 2499)
+++ trunk/PATCHES	2009-07-08 22:26:20 UTC (rev 2500)
@@ -1,7 +1,7 @@
+// This file is part of the Doyxgen Developer Manual
 /** @page patchguide Patch Guidelines
 
-Please mail patches to:
-
+Please mail patches to: @par
 	ope...@li...
 
 Note that you can't send patches to that list unless

Modified: trunk/TODO
===================================================================
--- trunk/TODO	2009-07-08 18:29:03 UTC (rev 2499)
+++ trunk/TODO	2009-07-08 22:26:20 UTC (rev 2500)
@@ -1,3 +1,4 @@
+// This file is part of the Doyxgen Developer Manual
 /** @page tasks Pending and Open Tasks
 
 This page lists pending and open tasks being considered or worked upon

[Openocd-svn] r2499 - trunk/src/flash

[<oh...@ma...>]

Author: oharboe
Date: 2009-07-08 20:29:03 +0200 (Wed, 08 Jul 2009)
New Revision: 2499

Modified:
   trunk/src/flash/aduc702x.c
Log:
Fix SEGFAULTs and broken error handling for flash programming w/working area

Modified: trunk/src/flash/aduc702x.c
===================================================================
--- trunk/src/flash/aduc702x.c	2009-07-08 10:38:50 UTC (rev 2498)
+++ trunk/src/flash/aduc702x.c	2009-07-08 18:29:03 UTC (rev 2499)
@@ -193,6 +193,11 @@
 	return ERROR_FLASH_OPERATION_FAILED;
 }
 
+/* If this fn returns ERROR_TARGET_RESOURCE_NOT_AVAILABLE, then the caller can fall
+ * back to another mechanism that does not require onboard RAM
+ *
+ * Caller should not check for other return values specifically
+ */
 static int aduc702x_write_block(struct flash_bank_s *bank, uint8_t *buffer, uint32_t offset, uint32_t count)
 {
 	aduc702x_flash_bank_t *aduc702x_info = bank->driver_priv;
@@ -204,6 +209,12 @@
 	armv4_5_algorithm_t armv4_5_info;
 	int retval = ERROR_OK;
 
+	if (((count%2)!=0)||((offset%2)!=0))
+	{
+		LOG_ERROR("write block must be multiple of two bytes in offset & length");
+		return ERROR_FAIL;
+	}
+
         /* parameters:
 
         r0 - address of source data (absolute)
@@ -249,8 +260,12 @@
 		return ERROR_TARGET_RESOURCE_NOT_AVAILABLE;
 	};
 
-	target_write_buffer(target, aduc702x_info->write_algorithm->address,
+	retval=target_write_buffer(target, aduc702x_info->write_algorithm->address,
                 sizeof(aduc702x_flash_write_code), (uint8_t*)aduc702x_flash_write_code);
+	if (retval!=ERROR_OK)
+	{
+		return retval;
+	}
 
 	/* memory buffer */
 	while (target_alloc_working_area(target, buffer_size, &source) != ERROR_OK)
@@ -279,12 +294,16 @@
 
 	while (count > 0)
 	{
-		uint32_t thisrun_count = (count > (buffer_size / 2)) ? (buffer_size / 2) : count;
+		uint32_t thisrun_count = (count > buffer_size) ? buffer_size : count;
 
-		target_write_buffer(target, source->address, thisrun_count * 2, buffer);
+		retval=target_write_buffer(target, source->address, thisrun_count, buffer);
+		if (retval!=ERROR_OK)
+		{
+			break;
+		}
 
 		buf_set_u32(reg_params[0].value, 0, 32, source->address);
-		buf_set_u32(reg_params[1].value, 0, 32, thisrun_count);
+		buf_set_u32(reg_params[1].value, 0, 32, thisrun_count/2);
 		buf_set_u32(reg_params[2].value, 0, 32, address);
 		buf_set_u32(reg_params[4].value, 0, 32, 0xFFFFF800);
 
@@ -294,17 +313,19 @@
                         10000, &armv4_5_info)) != ERROR_OK)
 		{
 			LOG_ERROR("error executing aduc702x flash write algorithm");
-			retval = ERROR_FLASH_OPERATION_FAILED;
 			break;
 		}
 
-		if ((buf_get_u32(reg_params[3].value, 0, 32) & 1) != 1) {
-			retval = ERROR_FLASH_OPERATION_FAILED;
+		if ((buf_get_u32(reg_params[3].value, 0, 32) & 1) != 1)
+		{
+			/* FIX!!!! what does this mean??? replace w/sensible error message */
+			LOG_ERROR("aduc702x detected error writing flash");
+			retval = ERROR_FAIL;
 			break;
 		}
 
-		buffer += thisrun_count * 2;
-		address += thisrun_count * 2;
+		buffer += thisrun_count;
+		address += thisrun_count;
 		count -= thisrun_count;
 	}
 
@@ -382,14 +403,9 @@
                                 return ERROR_FLASH_OPERATION_FAILED;
                         }
                 }
-                else if (retval == ERROR_FLASH_OPERATION_FAILED)
-                {
-                        LOG_ERROR("flash block writing failed");
-                        return ERROR_FLASH_OPERATION_FAILED;
-                }
         }
 
-        return ERROR_OK;
+        return retval;
 }
 
 static int aduc702x_probe(struct flash_bank_s *bank)

[Openocd-svn] r2498 - trunk

[oharboe at B. <oh...@ma...>]

Author: oharboe
Date: 2009-07-08 12:38:50 +0200 (Wed, 08 Jul 2009)
New Revision: 2498

Modified:
   trunk/TODO
Log:
fix formatting of xscale bug entry(learning every day)

Modified: trunk/TODO
===================================================================
--- trunk/TODO	2009-07-08 10:25:39 UTC (rev 2497)
+++ trunk/TODO	2009-07-08 10:38:50 UTC (rev 2498)
@@ -97,12 +97,10 @@
 
 @section thelisttargets Target Support
 
-- regression: xscale does not place debug_handler.bin into the right spot:
-
-https://lists.berlios.de/pipermail/openocd-development/2009-July/009338.html
-
 - general layer cleanup: @par
   https://lists.berlios.de/pipermail/openocd-development/2009-May/006590.html
+- regression: xscale does not place debug_handler.bin into the right spot: @par
+  https://lists.berlios.de/pipermail/openocd-development/2009-July/009338.html
 - regression: "reset halt" between 729(works) and 788(fails): @par
 https://lists.berlios.de/pipermail/openocd-development/2009-July/009206.html
 - ARM923EJS:

[Openocd-svn] r2497 - trunk

[oharboe at B. <oh...@ma...>]

Author: oharboe
Date: 2009-07-08 12:25:39 +0200 (Wed, 08 Jul 2009)
New Revision: 2497

Modified:
   trunk/TODO
Log:
Xscale installation regression entered

Modified: trunk/TODO
===================================================================
--- trunk/TODO	2009-07-08 10:25:23 UTC (rev 2496)
+++ trunk/TODO	2009-07-08 10:25:39 UTC (rev 2497)
@@ -97,6 +97,10 @@
 
 @section thelisttargets Target Support
 
+- regression: xscale does not place debug_handler.bin into the right spot:
+
+https://lists.berlios.de/pipermail/openocd-development/2009-July/009338.html
+
 - general layer cleanup: @par
   https://lists.berlios.de/pipermail/openocd-development/2009-May/006590.html
 - regression: "reset halt" between 729(works) and 788(fails): @par

[Openocd-svn] r2496 - trunk/src/server

[oharboe at B. <oh...@ma...>]

Author: oharboe
Date: 2009-07-08 12:25:23 +0200 (Wed, 08 Jul 2009)
New Revision: 2496

Modified:
   trunk/src/server/gdb_server.c
Log:
typo in comment

Modified: trunk/src/server/gdb_server.c
===================================================================
--- trunk/src/server/gdb_server.c	2009-07-08 08:05:21 UTC (rev 2495)
+++ trunk/src/server/gdb_server.c	2009-07-08 10:25:23 UTC (rev 2496)
@@ -2,7 +2,7 @@
  *   Copyright (C) 2005 by Dominic Rath                                    *
  *   Dom...@gm...                                                   *
  *                                                                         *
- *   Copyright (C) 2007,2008 vind Harboe                                 *
+ *   Copyright (C) 2007,2008 �yvind Harboe                                 *
  *   oyv...@zy...                                               *
  *                                                                         *
  *   Copyright (C) 2008 by Spencer Oliver                                  *
@@ -671,7 +671,7 @@
 {
 	gdb_connection_t *gdb_connection = connection->priv;
 
-	/* In the GDB protocol when we are stepping or coninuing execution,
+	/* In the GDB protocol when we are stepping or continuing execution,
 	 * we have a lingering reply. Upon receiving a halted event
 	 * when we have that lingering packet, we reply to the original
 	 * step or continue packet.

[Openocd-svn] r2495 - trunk

[oharboe at B. <oh...@ma...>]

Author: oharboe
Date: 2009-07-08 10:05:21 +0200 (Wed, 08 Jul 2009)
New Revision: 2495

Modified:
   trunk/TODO
Log:
some TODO notes on aduc702x which clearly needs more work & testing

Modified: trunk/TODO
===================================================================
--- trunk/TODO	2009-07-08 06:49:15 UTC (rev 2494)
+++ trunk/TODO	2009-07-08 08:05:21 UTC (rev 2495)
@@ -136,6 +136,14 @@
 
 @section thelistflash Flash Support
 
+- aduc702x segfault reported by Thomas A Moulton
+
+https://lists.berlios.de/pipermail/openocd-development/2009-July/009186.html
+
+- aduc7024 programming w/working area does not work:
+
+https://lists.berlios.de/pipermail/openocd-development/2009-July/009337.html
+
 - finish documentation for the following flash drivers:
   - avr
   - ecosflash

[Openocd-svn] r2494 - trunk

[oharboe at B. <oh...@ma...>]

Author: oharboe
Date: 2009-07-08 08:49:15 +0200 (Wed, 08 Jul 2009)
New Revision: 2494

Modified:
   trunk/TODO
Log:
i.MX27 reset problems fixed & update remaining reset problems notes

Modified: trunk/TODO
===================================================================
--- trunk/TODO	2009-07-08 06:32:27 UTC (rev 2493)
+++ trunk/TODO	2009-07-08 06:49:15 UTC (rev 2494)
@@ -99,13 +99,10 @@
 
 - general layer cleanup: @par
   https://lists.berlios.de/pipermail/openocd-development/2009-May/006590.html
-- regression: "reset halt" between 729(works) and 838(fails): @par
+- regression: "reset halt" between 729(works) and 788(fails): @par
 https://lists.berlios.de/pipermail/openocd-development/2009-July/009206.html
 - ARM923EJS:
   - reset run/halt/step is not robust; needs testing to map out problems.
-- i.MX27 
-  -reset run problems: @par
-https://lists.berlios.de/pipermail/openocd-development/2009-July/009240.html
 - ARM11 improvements (MB?)
   - fix single stepping  (reported by �H)
   - implement missing functionality (grep FNC_INFO_NOTIMPLEMENTED ...)

[Openocd-svn] r2493 - trunk/tcl/target

[oharboe at B. <oh...@ma...>]

Author: oharboe
Date: 2009-07-08 08:32:27 +0200 (Wed, 08 Jul 2009)
New Revision: 2493

Modified:
   trunk/tcl/target/imx21.cfg
   trunk/tcl/target/imx27.cfg
Log:
sharpen reset_config for imx27 - use both trst & srst. srst pulls trst.

Modified: trunk/tcl/target/imx21.cfg
===================================================================
--- trunk/tcl/target/imx21.cfg	2009-07-07 16:50:28 UTC (rev 2492)
+++ trunk/tcl/target/imx21.cfg	2009-07-08 06:32:27 UTC (rev 2493)
@@ -1,4 +1,6 @@
 #use combined on interfaces or targets that can't set TRST/SRST separately
+#
+# Hmmm.... should srst_pulls_trst be used here like i.MX27???
 reset_config trst_and_srst
 
 if { [info exists CHIPNAME] } {	

Modified: trunk/tcl/target/imx27.cfg
===================================================================
--- trunk/tcl/target/imx27.cfg	2009-07-07 16:50:28 UTC (rev 2492)
+++ trunk/tcl/target/imx27.cfg	2009-07-08 06:32:27 UTC (rev 2493)
@@ -4,7 +4,7 @@
 # Without setting these options correctly you'll see all sorts
 # of weird errors, e.g. MOE=0xe, invalid cpsr values, reset
 # failing, etc.
-reset_config srst_only srst_pulls_trst
+reset_config trst_and_srst srst_pulls_trst
 
 if { [info exists CHIPNAME] } {	
    set  _CHIPNAME $CHIPNAME    

[Openocd-svn] r2492 - trunk/tcl/target

[<oh...@ma...>]

Author: oharboe
Date: 2009-07-07 18:50:28 +0200 (Tue, 07 Jul 2009)
New Revision: 2492

Modified:
   trunk/tcl/target/imx27.cfg
Log:
srst pulls trst according to Freescale docs for i.mx27

Modified: trunk/tcl/target/imx27.cfg
===================================================================
--- trunk/tcl/target/imx27.cfg	2009-07-07 11:39:04 UTC (rev 2491)
+++ trunk/tcl/target/imx27.cfg	2009-07-07 16:50:28 UTC (rev 2492)
@@ -1,5 +1,10 @@
-#use combined on interfaces or targets that can't set TRST/SRST separately
-reset_config trst_and_srst
+# page 3-34 of "MCIMC27 Multimedia Applications Processor Reference Manual, Rev 0.3"
+# SRST pulls TRST
+#
+# Without setting these options correctly you'll see all sorts
+# of weird errors, e.g. MOE=0xe, invalid cpsr values, reset
+# failing, etc.
+reset_config srst_only srst_pulls_trst
 
 if { [info exists CHIPNAME] } {	
    set  _CHIPNAME $CHIPNAME    

[Openocd-svn] r2491 - trunk

[oharboe at B. <oh...@ma...>]

Author: oharboe
Date: 2009-07-07 13:39:04 +0200 (Tue, 07 Jul 2009)
New Revision: 2491

Modified:
   trunk/TODO
Log:
Zach Welch: move bugs into the right section

Modified: trunk/TODO
===================================================================
--- trunk/TODO	2009-07-07 11:32:58 UTC (rev 2490)
+++ trunk/TODO	2009-07-07 11:39:04 UTC (rev 2491)
@@ -11,21 +11,6 @@
 
 Feel free to send patches to add or clarify items on this list, too.
 
-@section thelisttcl Regressions
-
-- Dominic has spotted a "reset halt" regression between 838(fails) and 729(works)
-
-https://lists.berlios.de/pipermail/openocd-development/2009-July/009206.html
-
-@section thelisttcl Bugs
-
-- reset run/halt/step for arm926ejs is not robust. Needs lots of testing to
-map out problems.
-
-- i.MX27 reset run problems.
-
-https://lists.berlios.de/pipermail/openocd-development/2009-July/009240.html
-
 @section thelisttcl TCL
 
 This section provides possible things to improve with OpenOCD's TCL support.
@@ -114,6 +99,13 @@
 
 - general layer cleanup: @par
   https://lists.berlios.de/pipermail/openocd-development/2009-May/006590.html
+- regression: "reset halt" between 729(works) and 838(fails): @par
+https://lists.berlios.de/pipermail/openocd-development/2009-July/009206.html
+- ARM923EJS:
+  - reset run/halt/step is not robust; needs testing to map out problems.
+- i.MX27 
+  -reset run problems: @par
+https://lists.berlios.de/pipermail/openocd-development/2009-July/009240.html
 - ARM11 improvements (MB?)
   - fix single stepping  (reported by �H)
   - implement missing functionality (grep FNC_INFO_NOTIMPLEMENTED ...)

[Openocd-svn] r2490 - trunk

[oharboe at B. <oh...@ma...>]

Author: oharboe
Date: 2009-07-07 13:32:58 +0200 (Tue, 07 Jul 2009)
New Revision: 2490

Modified:
   trunk/TODO
Log:
Use reference to mailing list for known arm926ejs bugs rather fill The List with lots of details

Modified: trunk/TODO
===================================================================
--- trunk/TODO	2009-07-07 11:29:34 UTC (rev 2489)
+++ trunk/TODO	2009-07-07 11:32:58 UTC (rev 2490)
@@ -22,25 +22,10 @@
 - reset run/halt/step for arm926ejs is not robust. Needs lots of testing to
 map out problems.
 
-- i.MX27 reset run problems. Notice below that even if the target is running,
-a EICE_DBG_STATUS_DBGACK(I think...) is detected and OpenOCD wrongly believes that the
-target is halted. Polling the target afterwards reveals that the
-target is running. Notice the MOE=0xe value.
+- i.MX27 reset run problems.
 
-> reset run
-JTAG tap: imx27.bs tap/device found: 0x1b900f0f (mfg: 0x787, part: 0xb900, ver: 0x1)
-JTAG Tap/device matched
-JTAG tap: imx27.cpu tap/device found: 0x07926121 (mfg: 0x090, part: 0x7926, ver: 0x0)
-JTAG Tap/device matched
-WARNING: unknown debug reason: 0xe
-target state: halted
-target halted in ARM state due to debug-request, current mode: User
-cpsr: 0x00000000 pc: 0xffffffe8
-MMU: disabled, D-Cache: disabled, I-Cache: disabled
+https://lists.berlios.de/pipermail/openocd-development/2009-July/009240.html
 
-
-
-
 @section thelisttcl TCL
 
 This section provides possible things to improve with OpenOCD's TCL support.

[Openocd-svn] r2489 - trunk

[oharboe at B. <oh...@ma...>]

Author: oharboe
Date: 2009-07-07 13:29:34 +0200 (Tue, 07 Jul 2009)
New Revision: 2489

Modified:
   trunk/README
Log:
fixed a small typo in howto create doxygen docs

Modified: trunk/README
===================================================================
--- trunk/README	2009-07-07 10:47:23 UTC (rev 2488)
+++ trunk/README	2009-07-07 11:29:34 UTC (rev 2489)
@@ -51,10 +51,11 @@
 The OpenOCD Developer Manual contains information about the internal
 architecture and other details about the code:
 
+  # NB! make sure doxygen is installed, type doxygen --version
   make doxygen
 
   # If HTMLVIEWER is set, this views the HTML Doxygen output.
-  ${HTMLVIEWER} doxyegen/index.html
+  ${HTMLVIEWER} doxygen/index.html
 
 The remaining sections describe how to configure the system such that
 you can build the in-tree documentation.