Label builds as OpenOCD v0.4.0

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>

NEWS

@@ -11,6 +11,8 @@ Boundary Scan:
 
 Target Layer:
 	General
+		- Removed commands which have been obsolete for at least
+		  a year (from both documentation and, sometimes, code).
 		- new "reset-assert" event, for systems without SRST
 	ARM
 		- supports "reset-assert" event (except on Cortex-M3)

README

@@ -64,8 +64,8 @@ you can build the in-tree documentation.
 Installing OpenOCD
 ==================
 
-On Linux, you may have permissions problems to address.  The best
+On Linux, you may have permissions problems to address.  The best way
-way to do this is to use the contrib/udev.rules file.  It probably
+to do this is to use the contrib/openocd.udev rules file.  It probably
 belongs somewhere in /etc/udev/rules.d, but consult your operating
 system documentation to be sure.  In particular, make sure that it
 matches the syntax used by your operating system's version of udev.

configure.in

@@ -1,5 +1,5 @@
 AC_PREREQ(2.60)
-AC_INIT([openocd], [0.4.0-rc2],
+AC_INIT([openocd], [0.4.0],
   [OpenOCD Mailing List <openocd-development@lists.berlios.de>])
 AC_CONFIG_SRCDIR([src/openocd.c])
 

doc/openocd.texi

@@ -506,6 +506,14 @@ as Tcl scripts, from a @file{startup.tcl} file internal to the server.
 @cindex logfile
 @cindex directory search
 
+Properly installing OpenOCD sets up your operating system to grant it access
+to the JTAG adapters.  On Linux, this usually involves installing a file
+in @file{/etc/udev/rules.d,} so OpenOCD has permissions.  MS-Windows needs
+complex and confusing driver configuration for every peripheral.  Such issues
+are unique to each operating system, and are not detailed in this User's Guide.
+
+Then later you will invoke the OpenOCD server, with various options to
+tell it how each debug session should work.
 The @option{--help} option shows:
 @verbatim
 bash$ openocd --help
@@ -1984,6 +1992,10 @@ MMU: disabled, D-Cache: disabled, I-Cache: enabled
 @cindex config file, interface
 @cindex interface config file
 
+Correctly installing OpenOCD includes making your operating system give
+OpenOCD access to JTAG adapters.  Once that has been done, Tcl commands
+are used to select which one is used, and to configure how it is used.
+
 JTAG Adapters/Interfaces/Dongles are normally configured
 through commands in an interface configuration
 file which is sourced by your @file{openocd.cfg} file, or

src/helper/options.c

@@ -190,7 +190,7 @@ int parse_cmdline_args(struct command_context *cmd_ctx, int argc, char *argv[])
 
 	if (help_flag)
 	{
-		LOG_OUTPUT("Open On-Chip Debugger\n(c) 2005-2008 by Dominic Rath\n\n");
+		LOG_OUTPUT("Open On-Chip Debugger\nLicensed under GNU GPL v2\n");
 		LOG_OUTPUT("--help       | -h\tdisplay this help\n");
 		LOG_OUTPUT("--version    | -v\tdisplay OpenOCD version\n");
 		LOG_OUTPUT("--file       | -f\tuse configuration file <name>\n");

src/jtag/drivers/parport.c

@@ -265,7 +265,6 @@ static int parport_init(void)
 	struct cable *cur_cable;
 #if PARPORT_USE_PPDEV == 1
 	char buffer[256];
-	int i = 0;
 #endif
 
 	cur_cable = cables;
@@ -323,7 +322,8 @@ static int parport_init(void)
 	LOG_DEBUG("...open");
 
 #if !defined(__FreeBSD__) && !defined(__FreeBSD_kernel__)
-	i = ioctl(device_handle, PPCLAIM);
+	int i = ioctl(device_handle, PPCLAIM);
+
 	if (i < 0)
 	{
 		LOG_ERROR("cannot claim device");

src/openocd.c

@@ -228,7 +228,8 @@ struct command_context *setup_command_handler(Jim_Interp *interp)
 	}
 	LOG_DEBUG("command registration: complete");
 
-	LOG_OUTPUT(OPENOCD_VERSION "\n");
+	LOG_OUTPUT(OPENOCD_VERSION "\n"
+			"Licensed under GNU GPL v2\n");
 
 	global_cmd_ctx = cmd_ctx;
 

src/target/dsp563xx.c

@@ -246,6 +246,29 @@ static const struct
 	/* *INDENT-ON* */
 };
 
+static int dsp563xx_get_gdb_reg_list(struct target *target, struct reg **reg_list[],
+			      int *reg_list_size)
+{
+	struct dsp563xx_common *dsp563xx = target_to_dsp563xx(target);
+	int i;
+
+	if (target->state != TARGET_HALTED)
+	{
+		return ERROR_TARGET_NOT_HALTED;
+	}
+
+	*reg_list_size = DSP563XX_NUMCOREREGS;
+	*reg_list = malloc(sizeof(struct reg *) * (*reg_list_size));
+
+	for (i = 0; i < DSP563XX_NUMCOREREGS; i++)
+	{
+		(*reg_list)[i] = &dsp563xx->core_cache->reg_list[i];
+	}
+
+	return ERROR_OK;
+
+}
+
 int dsp563xx_read_core_reg(struct target *target, int num)
 {
 	uint32_t reg_value;
@@ -974,6 +997,8 @@ struct target_type dsp563xx_target = {
 
 	.target_request_data = NULL,
 
+	.get_gdb_reg_list = dsp563xx_get_gdb_reg_list,
+
 	.halt = dsp563xx_halt,
 	.resume = dsp563xx_resume,
 	.step = dsp563xx_step,

tcl/board/csb337.cfg

@@ -113,3 +113,5 @@ proc csb337_reset_init { } {
 }
 
 $_TARGETNAME configure -event reset-init {csb337_reset_init}
+
+arm7_9 fast_memory_access enable

tcl/target/lpc1768.cfg

@@ -33,11 +33,11 @@ target create $_TARGETNAME cortex_m3 -endian $_ENDIAN -chain-position $_TARGETNA
 # LPC1768 has 32kB of SRAM on its main system bus (so-called Local On-Chip SRAM)
 $_TARGETNAME configure -work-area-phys 0x10000000 -work-area-size 0x8000 -work-area-backup 0
 
+# REVISIT is there any good reason to have this reset-init event handler??
+# Normally they should set up (board-specific) clocking then probe the flash...
 $_TARGETNAME configure -event reset-init {
-	# Force target into ARM state
+	# Force NVIC.VTOR to point to flash at 0 ...
-	arm core_state arm
+	# WHY?  This is it's reset value; we run right after reset!!
-	#do not remap 0x0000-0x0020 to anything but the flash
-#	mwb 0xE01FC040 0x01
 	mwb 0xE000ED08 0x00
 }