date:20091121

Re: [Openocd-development] Slowly moving from 8 to 32 bit words in jtag_add_xxx API

2009-11-21 Thread Øyvind Harboe

On Fri, Nov 20, 2009 at 10:43 PM, Michael Bruck mbr...@digenius.de wrote:
 On Fri, Nov 20, 2009 at 19:05, Øyvind Harboe oyvind.har...@zylin.com wrote:
 Just to clarify the whole issue once more, my proposal was actually
 three different things:

 1. Making the use of scan_field safer by providing standard handlers
 for the most common cases.

 This not only helps with the readability and reduces trivial
 copypaste errors. It also makes it much simpler to rewire the
 underlying scan_field in a later step.

 We can relatively easily do away with the scanfields entirely
 rather than putting lipstick on it... See the branch I was working on
 or jtag_add_dr_out() API for which I'm looking into adding a in_value
 as well as the existing out_value that it takes today.

 This still uses an array that needs to be initialized. Your own
 embeddedice example patch didn't make use of it...

The example on my harddrive that has been put to pasture makes
use of it :-)

 And by adding out_value the caller is forced to hold all data in
 uint32_t. My suggestion was intended to make (almost) all data types
 first class citizens, not just choosing one that is the most commonly
 used.

The thing that forces the users to use 32 bit is the fact that the
*target* is 32 bit. It doesn't matter what word size the OpenOCD host
CPU is using in the approach I'm suggesting. It works equally well
with any *target* word size.


 These are two things. The global JTAG device instance and the global
 command sequence. The TODO is specific on the device instances, but
 not on command queues.

The whole point is that whether or not that there *is* an actual
command sequence is something that it is up to the interface
to implement. Today the interface has that freedom. By exposing
the queue explicitly in the calling API you remove the ability to
the interface to drop the implementation of a queue.

The current JTAG API allows for a hardware queue, which is super
efficient.

 Where is the bottleneck in this case? Latency, memory consumption, cpu
 load or something else?

The *current* jtag_add_dr_out() implementation breaks down to *two pokes*
if you have a hardware JTAG queue.

*Anything* you add on top of that is going to increase performance overhead
siginficantly :-)

To get a sense of perspective, a single malloc() is orders of magnitude more
work that a synchronous jtag_add_dr_out() w/a hardware queue.

I've profiled this extensively, so it's no coincidence that I ended up with
the particular jtag_add_dr_out() syntax. Notice that the first argument
is a constant so with GCC's constant forward propagation, jtag_add_dr_out()
really *can* boil down to poking two hardware registers...


 Did you look at jtag_add_dr_out() which exists today?

 git format-patch d14b6ca0^...d14b6ca0

I don't know what you mean by the above against which repository.


-- 
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Slowly moving from 8 to 32 bit words in jtag_add_xxx API

2009-11-21 Thread Michael Schwingen

Øyvind Harboe wrote:
 3. Break up jtag_add_dr_scan etc.

 This works best in tandem with (2). The general idea is not to pass
 one array of scan fields but to pass them in separate function calls
 (which would mimic, but replace the ones in (1)). To output a 7 bit
 field the caller just hands the value to the function and doesn't
 bother about allocating space. To turn jtag_add_?r_scan inside out
 like this requires its states to be kept somewhere so that
 plausibility checks and bypassing can be done. The local copy of the
 jtag_command_queue would be ideal for that (although it would also
 work by adding even more global variables). The caller then does
 something like this:

 jtag_queue_t * q = jq_alloc_queue();
 

 I'm very much against *forcing* interfaces to implement a queue
 in memory. It should be possible to execute the commands
 synchronously. The existance of a queue would make the code
 *much* less efficient on embedded devices.
   
Hm. I do not have a complete view of the proposed API, but does it
really *force* you to implement a queue?

It looks to me you only have to have a queue structure, which is used to
hold state across multiple calls (maybe it should have a different
name?). You don't *have* to queue the commands, right?

So if you have a hardware queue, the queue struct may be mostly unused
by your interface implementation, and every add_... call simply stashes
the arguments into your hardware queue.

Please correct me if I overlooked something (which is entirely possible).

cu
Michael


___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Slowly moving from 8 to 32 bit words in jtag_add_xxx API

2009-11-21 Thread Øyvind Harboe

On Sat, Nov 21, 2009 at 2:09 PM, Michael Schwingen
rincew...@discworld.dascon.de wrote:
 Øyvind Harboe wrote:
 3. Break up jtag_add_dr_scan etc.

 This works best in tandem with (2). The general idea is not to pass
 one array of scan fields but to pass them in separate function calls
 (which would mimic, but replace the ones in (1)). To output a 7 bit
 field the caller just hands the value to the function and doesn't
 bother about allocating space. To turn jtag_add_?r_scan inside out
 like this requires its states to be kept somewhere so that
 plausibility checks and bypassing can be done. The local copy of the
 jtag_command_queue would be ideal for that (although it would also
 work by adding even more global variables). The caller then does
 something like this:

 jtag_queue_t * q = jq_alloc_queue();


 I'm very much against *forcing* interfaces to implement a queue
 in memory. It should be possible to execute the commands
 synchronously. The existance of a queue would make the code
 *much* less efficient on embedded devices.

 Hm. I do not have a complete view of the proposed API, but does it
 really *force* you to implement a queue?

The important point is that the queuing of JTAG commands
can be done in hardware today, with no overhead.

We want to keep the actual queue implementation something
completely internal to the interface implementations.



-- 
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] Openocd vrs Commercial jtag dongles

2009-11-21 Thread Duane Ellis

Recently, I've been using quite a few commercial jtag tools from chip 
vendors.

One thing I've noticed is that they all have implement the design with 
an small usb-controller + FPGA of some type (typically a xilinx 
spartan). I can see the real benefit, they download and flash the target 
at an unbelievable speed, ie: couple seconds for 256K of data. In 
contrast, non-fpga solutions, (bitbang  ftdi, etc) are much slower overall.

My guess is they are creating a hugely fast chip specific download 
engine they just feed data bytes to - and it operates at some hugely 
fast speed (that probably helps) In theory, the dongle has 2 modes, 
simple slow bitbang - once the target is determined, download an 
acceleration engine the fpga.

The debugger step-in/over/line/etc rate with these tools is so fast... 
perhaps they have have implemented some common tasks like step and 
register dump type sequences in the dongle's fpga.  Watch windows are 
for example very snappy.

Sadly, that also requires a lot of engineering expertise to write that 
fpga code. in the cases I've seen [ie: vendor supplied tools] the chip 
companies also have a large pool of people who know or understand 
verilog/vhdl and can write such fpga code.

It is just blindingly fast...

-Duane.





___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Slowly moving from 8 to 32 bit words in jtag_add_xxx API

2009-11-21 Thread Michael Schwingen

Øyvind Harboe wrote:
 The important point is that the queuing of JTAG commands
 can be done in hardware today, with no overhead.

 We want to keep the actual queue implementation something
 completely internal to the interface implementations.
   
Understood. I still do not see how the proposed API would break that.

cu
Michael


___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH 0/3] improve default script search path

2009-11-21 Thread Andreas Fritiofson

This series improves the default script search path to include $HOME/.openocd.
It also updates the search path on Windows to match what appears to be the
result of a standard 'configure  make  make install' in one particular
MSYS environment. Other environments have not been tested, but the current
path seems wrong regardless.

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH 2/3] update win32 script search path

2009-11-21 Thread Andreas Fritiofson

The default script search path on Windows seems to be out of date with the
current layout, causing the standard scripts not to be found after a
conventional './configure  make  make install' under msys/MinGW. The same
should hold true for cygwin native builds although not verified.

Update the search path to ../share/openocd/scripts instead of ../lib/openocd,
relative the openocd executable.

Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com
---
 src/helper/options.c |   10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/helper/options.c b/src/helper/options.c
index 874196e..5792e11 100644
--- a/src/helper/options.c
+++ b/src/helper/options.c
@@ -74,21 +74,21 @@ static void add_default_dirs(void)
add_script_search_dir(strExePath);
}
/*
-* Add support for the default (as of 20080121) layout when
-* using autotools and cygwin to build native MinGW binary.
+* Add support for the default (as of 20091118) layout when
+* using autotools and cygwin/MinGW to build native binary.
 * Path separator is converted to UNIX style so that MinGW is
 * pleased.
 *
 * bin/openocd.exe
-* lib/openocd/event/at91eb40a_reset.cfg
-* lib/openocd/target/at91eb40a.cfg
+* share/openocd/scripts/interface/dummy.cfg
+* share/openocd/scripts/target/at91eb40a.cfg
 */
{
char strExePath [MAX_PATH];
char *p;
GetModuleFileName (NULL, strExePath, MAX_PATH);
*strrchr(strExePath, '\\') = 0;
-   strcat(strExePath, /../lib/PACKAGE);
+   strcat(strExePath, /../share/PACKAGE/scripts);
for (p = strExePath; *p; p++) {
if (*p == '\\')
*p = '/';
-- 
1.6.3.3

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH 3/3] support for scripts in $HOME/.openocd

2009-11-21 Thread Andreas Fritiofson

Add $HOME/.openocd as the first default script search directory, allowing
the user to override the standard scripts.

Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com
---
 src/helper/options.c |   16 +++-
 1 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/src/helper/options.c b/src/helper/options.c
index 5792e11..2187ff7 100644
--- a/src/helper/options.c
+++ b/src/helper/options.c
@@ -29,6 +29,7 @@
 #include server.h
 
 #include getopt.h
+#include stdlib.h
 
 static int help_flag, version_flag;
 
@@ -54,6 +55,10 @@ int configuration_output_handler(struct command_context 
*context, const char* li
 
 static void add_default_dirs(void)
 {
+#ifndef MAX_PATH
+#define MAX_PATH 1024
+#endif
+
 #ifdef _WIN32
/* Add the parent of the directory where openocd.exe resides to the
 * config script search path.
@@ -101,7 +106,16 @@ static void add_default_dirs(void)
 * listed last in the built-in search order, so the user can
 * override these scripts with site-specific customizations.
 */
-   /// @todo Implement @c add_script_search_dir(${HOME}/.openocd).
+
+   char *home = getenv(HOME);
+
+   if (home) {
+   char path[MAX_PATH];
+
+   if (snprintf(path, MAX_PATH, %s/.openocd, home)  MAX_PATH)
+   add_script_search_dir(path);
+   }
+
add_script_search_dir(PKGDATADIR /site);
add_script_search_dir(PKGDATADIR /scripts);
 #endif
-- 
1.6.3.3

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH 1/3] show script search dirs in debug log

2009-11-21 Thread Andreas Fritiofson

Add this to ease debugging why the standard scripts aren't found on the
default script search path in some build/install enviroments. Especially on
Windows it's not straight forward where openocd actually looks for the
scripts.

Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com
---
 src/helper/configuration.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/src/helper/configuration.c b/src/helper/configuration.c
index 74bcc9b..2ea5da4 100644
--- a/src/helper/configuration.c
+++ b/src/helper/configuration.c
@@ -41,6 +41,8 @@ void add_script_search_dir (const char *dir)
 
script_search_dirs[num_script_dirs-1] = strdup(dir);
script_search_dirs[num_script_dirs] = NULL;
+
+   LOG_DEBUG(adding %s, dir);
 }
 
 void add_config_command (const char *cfg)
-- 
1.6.3.3

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 3/3] support for scripts in $HOME/.openocd

2009-11-21 Thread Øyvind Harboe

How about using a dynamic allocation and not worrying about
max size at all?

These changes seem reasonably to me, but without documentation
to go with it, I fear nobody would use it. Could you add some?

-- 
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Openocd vrs Commercial jtag dongles

2009-11-21 Thread Leon Woestenberg

Hello,

On Sat, Nov 21, 2009 at 4:42 PM, Duane Ellis open...@duaneellis.com wrote:
 Recently, I've been using quite a few commercial jtag tools from chip
 vendors.

 One thing I've noticed is that they all have implement the design with
 an small usb-controller + FPGA of some type (typically a xilinx
 spartan). I can see the real benefit, they download and flash the target
 at an unbelievable speed, ie: couple seconds for 256K of data. In
 contrast, non-fpga solutions, (bitbang  ftdi, etc) are much slower overall.

If someone wants to go down that road, I think the BeMicro solution is
quite nice.
It's a USB dongle with modern FPGA and 80 pin (or so) header, priced $49.

The software to develop the FPGA code is freely usable, and available for Linux.

I'm in no way affiliated with them.

Regards,
-- 
Leon
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] How to add support for a board?

2009-11-21 Thread David Brownell

On Wednesday 18 November 2009, Albert ARIBAUD wrote:
  Can someone on the list point me to instructions on how to create 
  interface, target and board files for this board?
  
  Start with the User's Guide; there's a chapter on that stuff.
 
 Thanks. I'd gone through the manual already once, but I was more looking 
 for a where to start and how to progress section, or a typical kinds 
 of JTAG setups you can encouter ones. A second read of the 
 interface-related sections clarifies things--a bit.

If you could explain how they might be improved, or submit a
patch (I could help clean it up) that would be the way to get
progress ...

I think most folk on this list are a bit beyond the specific
questions you're thinking of, so if you -- who have them fresh
in your mind! -- can help identify documentation deficiencies,
that'd help.

If you're after something that's really tutorial, we probably
won't put it in the manual.  Something that makes all that
reference material more approachbale, especially to someone
just starting, would be reasonable to see there.

- Dave


___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 5/8] improve 'help' command

2009-11-21 Thread David Brownell

On Friday 20 November 2009, Zach Welch wrote:
 
   Also, any reason to hold off on this present series or the USB series?
  
  These command patches, didn't see a reason.
 
 Okay, I've made a few trivial changes to them after working on the
 changes to support proper usage function, but I will try to push them
 along this afternoon.

The foo and hello commands probably shouldn't be built by
default ... 

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Openocd vrs Commercial jtag dongles

2009-11-21 Thread David Brownell

On Saturday 21 November 2009, Duane Ellis wrote:
 It is just blindingly fast...

I suspect that many of those speed improvements can be
had even with a CPU-based solution ... if the CPU is
driving the JTAG interface directly, it can do things
like handshaking in microseconds, not the milliseconds
that a USB roundrip takes.

In terms of Open processes, I can imagine doing that
with various microcontrollers that come with USB (or
Ethernet) links.  It needn't be all that more pricey
than an FT2232H dongle.  Consider a board:

  USB --  Cortex-M3 -- level shifting -- JTAG

Wouldn't be as fast as an FPGA, necessarily, though
if the level shifting were packaged in a CPLD there
might be scope to offload some of the most common
handshakes.  

Come up with such a board with initial it works
firmware ... and OpenOCD could speed things up
over time.

- Dave

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Openocd vrs Commercial jtag dongles

2009-11-21 Thread Øyvind Harboe

There are a raft of tricks than can be employed
to improve performance. The ZY1000 does 400kBytes/s
w/arm7/9 @ 16MHz btw, using OpenOCD. The advantage of ZY1000
is low latency, but it has a feeble host CPU. The history of optimizing
the ZY1000 showed significant improvement benefits for
USB dongles as well.

Profiling is the right place to start... always... Code inspection
should come only after profiling. There is plenty of inefficient code
that is hardly ever run and has no impact on observable performance.

That said, there are high level tricks that can be employed. E.g.
caching of target memory. This can be done both by GDB
(and I wonder if it can be done automatically), by e.g. caching
read only memory on the GDB end or secondarily on the
OpenOCD end.

Caching code memory would be a *HUGE* improvement for
single stepping...

Ideally we could exploit the GDB protocol better w.r.t. such
caching or add some scheme to tell OpenOCD what memory
that is to be considered as read-only by the OpenOCD GDB
server...

This may be possible *without* any change to OpenOCD. Perhaps
a tool that reads out the read-only sections from elf file and generate
a list of GDB commands to be issued in .gdbinit?

-- 
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 1/3] show script search dirs in debug log

2009-11-21 Thread David Brownell

On Saturday 21 November 2009, Andreas Fritiofson wrote:
 +   LOG_DEBUG(adding %s, dir);

That one's a no-brainer ... merged. :)

No comment on the other two, except that they need thought
and I'll wait to see the followup (doc etc) especially on
the third one.

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 5/8] improve 'help' command

2009-11-21 Thread Zach Welch

On Sat, 2009-11-21 at 09:36 -0700, David Brownell wrote:
 On Friday 20 November 2009, Zach Welch wrote:
  
Also, any reason to hold off on this present series or the USB series?
   
   These command patches, didn't see a reason.
  
  Okay, I've made a few trivial changes to them after working on the
  changes to support proper usage function, but I will try to push them
  along this afternoon.
 
 The foo and hello commands probably shouldn't be built by
 default ... 

Yes, I was waiting for someone to say something.  The documentation for
them even talks about how you need to uncomment a line.  I just forgot
to add that comment before committing.  I was thinking about adding a
--enable-extra-goodies or some such option to make it, but anyone that
wants to use those commands for what they are intended (code examples)
must be able to manage changing and recompiling the code for themselves.

--Z
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH 0/12] jtag command registration cleanup

2009-11-21 Thread Zachary T Welch

Hi all,

This series builds upon the last to cleanup the JTAG layer command
handler registration.  First, each module gets converted to use
register_commands() with a command registration array.  The final patch
converts the jtag_interface structure to contain the registration list
(and its size), removing the register_commands callback functions from
all of the interface drivers.

Cheers,

Zach
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH 05/12] ft2232: use register_commands()

2009-11-21 Thread Zachary T Welch

Use register_commands() with a command registration array.

Signed-off-by: Zachary T Welch z...@superlucidity.net
---
 src/jtag/ft2232.c |   60 +---
 1 files changed, 42 insertions(+), 18 deletions(-)

diff --git a/src/jtag/ft2232.c b/src/jtag/ft2232.c
index e560b22..d202427 100644
--- a/src/jtag/ft2232.c
+++ b/src/jtag/ft2232.c
@@ -3968,27 +3968,51 @@ static void ktlink_blink(void)
buffer_write(high_output);
buffer_write(high_direction);
 }
+static const struct command_registration ft2232_command_handlers[] = {
+   {
+   .name = ft2232_device_desc,
+   .handler = ft2232_handle_device_desc_command,
+   .mode = COMMAND_CONFIG,
+   .help = set the USB device description of the FTDI 
FT2232 device,
+   .usage = description,
+   },
+   {
+   .name = ft2232_serial,
+   .handler = ft2232_handle_serial_command,
+   .mode = COMMAND_CONFIG,
+   .help = set the serial number of the FTDI FT2232 
device,
+   .usage = serial#,
+   },
+   {
+   .name = ft2232_layout,
+   .handler = ft2232_handle_layout_command,
+   .mode = COMMAND_CONFIG,
+   .help = set the layout of the FT2232 GPIO signals used 

+   to control output-enables and reset signals,
+   .usage = layout,
+   },
+   {
+   .name = ft2232_vid_pid,
+   .handler = ft2232_handle_vid_pid_command,
+   .mode = COMMAND_CONFIG,
+   .help = the vendor ID and product ID of the FTDI 
FT2232 device,
+   .usage = vid pid [...],
+   },
+   {
+   .name = ft2232_latency,
+   .handler = ft2232_handle_latency_command,
+   .mode = COMMAND_CONFIG,
+   .help = set the FT2232 latency timer to a new value,
+   .usage = vid pid [...],
+   }
+   };
+
 
 static int ft2232_register_commands(struct command_context* cmd_ctx)
 {
-   COMMAND_REGISTER(cmd_ctx, NULL, ft2232_device_desc,
-   ft2232_handle_device_desc_command, COMMAND_CONFIG,
-   the USB device description of the FTDI FT2232 device);
-   COMMAND_REGISTER(cmd_ctx, NULL, ft2232_serial,
-   ft2232_handle_serial_command, COMMAND_CONFIG,
-   the serial number of the FTDI FT2232 device);
-   COMMAND_REGISTER(cmd_ctx, NULL, ft2232_layout,
-   ft2232_handle_layout_command, COMMAND_CONFIG,
-   the layout of the FT2232 GPIO signals used 
-   to control output-enables and reset signals);
-   COMMAND_REGISTER(cmd_ctx, NULL, ft2232_vid_pid,
-   ft2232_handle_vid_pid_command, COMMAND_CONFIG,
-   the vendor ID and product ID of the FTDI FT2232 
device);
-   COMMAND_REGISTER(cmd_ctx, NULL, ft2232_latency,
-   ft2232_handle_latency_command, COMMAND_CONFIG,
-   set the FT2232 latency timer to a new value);
-
-   return ERROR_OK;
+   return register_commands(cmd_ctx, NULL,
+   ARRAY_SIZE(ft2232_command_handlers),
+   ft2232_command_handlers);
 }
 
 
-- 
1.6.4.4

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH 03/12] arm-jtag-ew: use register_commands()

2009-11-21 Thread Zachary T Welch

Uses register_commands() with command registration array.

Signed-off-by: Zachary T Welch z...@superlucidity.net
---
 src/jtag/arm-jtag-ew.c |   16 
 1 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/src/jtag/arm-jtag-ew.c b/src/jtag/arm-jtag-ew.c
index 82ff2a0..5363ae8 100644
--- a/src/jtag/arm-jtag-ew.c
+++ b/src/jtag/arm-jtag-ew.c
@@ -501,12 +501,20 @@ COMMAND_HANDLER(armjtagew_handle_armjtagew_info_command)
return ERROR_OK;
 }
 
+static const struct command_registration armjtagew_command_handlers[] = {
+   {
+   .name = armjtagew_info,
+   .handler = armjtagew_handle_armjtagew_info_command,
+   .mode = COMMAND_EXEC,
+   .help = query armjtagew info,
+   },
+   };
+
 static int armjtagew_register_commands(struct command_context *cmd_ctx)
 {
-   COMMAND_REGISTER(cmd_ctx, NULL, armjtagew_info,
-   armjtagew_handle_armjtagew_info_command, COMMAND_EXEC,
-   query armjtagew info);
-   return ERROR_OK;
+   return register_commands(cmd_ctx, NULL,
+   ARRAY_SIZE(armjtagew_command_handlers),
+   armjtagew_command_handlers);
 }
 
 struct jtag_interface armjtagew_interface = {
-- 
1.6.4.4

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH 04/12] at91rm9200: use register_commands()

2009-11-21 Thread Zachary T Welch

Use register_commands() with command registration array.
---
This module was broken by previous changes, but no one has complained.
Are there still users for this modules?

Signed-off-by: Zachary T Welch z...@superlucidity.net
---
 src/jtag/at91rm9200.c |   15 ---
 1 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/src/jtag/at91rm9200.c b/src/jtag/at91rm9200.c
index 024dd6d..34bcd60 100644
--- a/src/jtag/at91rm9200.c
+++ b/src/jtag/at91rm9200.c
@@ -200,11 +200,20 @@ static int at91rm9200_handle_device_command(struct 
command_context *cmd_ctx, cha
return ERROR_OK;
 }
 
+static const struct command_registration at91rm9200_command_handlers[] = {
+   {
+   .name = at91rm9200_device,
+   .handler = at91rm9200_handle_device_command,
+   .mode = COMMAND_CONFIG,
+   .help = query armjtagew info,
+   },
+   };
+
 static int at91rm9200_register_commands(struct command_context *cmd_ctx)
 {
-   COMMAND_REGISTER(cmd_ctx, NULL, at91rm9200_device, 
at91rm9200_handle_device_command,
-   COMMAND_CONFIG, NULL);
-   return ERROR_OK;
+   return register_commands(cmd_ctx, NULL,
+   ARRAY_SIZE(at91rm9200_command_handlers),
+   at91rm9200_command_handlers);
 }
 
 static int at91rm9200_init(void)
-- 
1.6.4.4

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH 06/12] gw16012: use register_commands()

2009-11-21 Thread Zachary T Welch

Use register_commands() with command registration array.

Signed-off-by: Zachary T Welch z...@superlucidity.net
---
 src/jtag/gw16012.c |   18 +-
 1 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/src/jtag/gw16012.c b/src/jtag/gw16012.c
index bc0e472..5118562 100644
--- a/src/jtag/gw16012.c
+++ b/src/jtag/gw16012.c
@@ -562,13 +562,21 @@ COMMAND_HANDLER(gw16012_handle_parport_port_command)
return ERROR_OK;
 }
 
+static const struct command_registration gw16012_command_handlers[] = {
+   {
+   .name = parport_port,
+   .handler = gw16012_handle_parport_port_command,
+   .mode = COMMAND_CONFIG,
+   .help = configure the parallel port to use,
+   .usage = port_num,
+   },
+   };
+
 static int gw16012_register_commands(struct command_context *cmd_ctx)
 {
-   COMMAND_REGISTER(cmd_ctx, NULL, parport_port,
-   gw16012_handle_parport_port_command, COMMAND_CONFIG,
-   NULL);
-
-   return ERROR_OK;
+   return register_commands(cmd_ctx, NULL,
+   ARRAY_SIZE(gw16012_command_handlers),
+   gw16012_command_handlers);
 }
 
 struct jtag_interface gw16012_interface = {
-- 
1.6.4.4

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH 07/12] jlink: use register_commands()

2009-11-21 Thread Zachary T Welch

Use register_commands() with command registration array.

Signed-off-by: Zachary T Welch z...@superlucidity.net
---
 src/jtag/jlink.c |   27 +++
 1 files changed, 19 insertions(+), 8 deletions(-)

diff --git a/src/jtag/jlink.c b/src/jtag/jlink.c
index 0f76c9f..200dfe4 100644
--- a/src/jtag/jlink.c
+++ b/src/jtag/jlink.c
@@ -628,16 +628,27 @@ COMMAND_HANDLER(jlink_handle_jlink_hw_jtag_command)
return ERROR_OK;
 }
 
+static const struct command_registration jlink_command_handlers[] = {
+   {
+   .name = jlink_info,
+   .handler = jlink_handle_jlink_info_command,
+   .mode = COMMAND_EXEC,
+   .help = show jlink info,
+   },
+   {
+   .name = jlink_hw_jtag,
+   .handler = jlink_handle_jlink_hw_jtag_command,
+   .mode = COMMAND_EXEC,
+   .help = access J-Link HW JTAG command version,
+   .usage = [2|3],
+   },
+   };
+
 static int jlink_register_commands(struct command_context *cmd_ctx)
 {
-
-   COMMAND_REGISTER(cmd_ctx, NULL, jlink_info,
-   jlink_handle_jlink_info_command, COMMAND_EXEC,
-   query jlink info);
-   COMMAND_REGISTER(cmd_ctx, NULL, jlink_hw_jtag,
-   jlink_handle_jlink_hw_jtag_command, COMMAND_EXEC,
-   set/get jlink hw jtag command version [2 | 3]);
-   return ERROR_OK;
+   return register_commands(cmd_ctx, NULL,
+   ARRAY_SIZE(jlink_command_handlers),
+   jlink_command_handlers);
 }
 
 struct jtag_interface jlink_interface = {
-- 
1.6.4.4

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH 01/12] openocd: update version/init command registration

2009-11-21 Thread Zachary T Welch

Use register_commands() for top-level version and init command.

Signed-off-by: Zachary T Welch z...@superlucidity.net
---
 src/openocd.c |   25 +++--
 1 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/src/openocd.c b/src/openocd.c
index 379373c..4d13611 100644
--- a/src/openocd.c
+++ b/src/openocd.c
@@ -159,6 +159,22 @@ COMMAND_HANDLER(handle_init_command)
return ERROR_OK;
 }
 
+static const struct command_registration openocd_command_handlers[] = {
+   {
+   .name = version,
+   .handler = handle_version_command,
+   .mode = COMMAND_EXEC,
+   .help = show program version,
+   },
+   {
+   .name = init,
+   .handler = handle_init_command,
+   .mode = COMMAND_ANY,
+   .help = Initializes configured targets and servers.  
+   If called more than once, does nothing.,
+   },
+   };
+
 struct command_context *global_cmd_ctx;
 
 /// src/hello.c gives a simple example for writing new command modules
@@ -171,9 +187,9 @@ struct command_context *setup_command_handler(void)
 
global_cmd_ctx = cmd_ctx = command_init(openocd_startup_tcl);
 
-   COMMAND_REGISTER(cmd_ctx, NULL, version, handle_version_command,
-COMMAND_EXEC, show OpenOCD version);
-
+   register_commands(cmd_ctx, NULL,
+   ARRAY_SIZE(openocd_command_handlers),
+   openocd_command_handlers);
/* register subsystem commands */
hello_register_commands(cmd_ctx);
server_register_commands(cmd_ctx);
@@ -198,9 +214,6 @@ struct command_context *setup_command_handler(void)
 
LOG_OUTPUT(OPENOCD_VERSION \n);
 
-   COMMAND_REGISTER(cmd_ctx, NULL, init, handle_init_command,
-COMMAND_ANY, initializes target and 
servers - nop on subsequent invocations);
-
return cmd_ctx;
 }
 
-- 
1.6.4.4

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH 11/12] vsllink: use register_commands()

2009-11-21 Thread Zachary T Welch

Use register_commands() with command registration array.

Signed-off-by: Zachary T Welch z...@superlucidity.net
---
 src/jtag/vsllink.c |   56 +--
 1 files changed, 36 insertions(+), 20 deletions(-)

diff --git a/src/jtag/vsllink.c b/src/jtag/vsllink.c
index 538ae0b..d6a2ec8 100644
--- a/src/jtag/vsllink.c
+++ b/src/jtag/vsllink.c
@@ -1880,28 +1880,44 @@ static void vsllink_debug_buffer(uint8_t *buffer, int 
length)
 }
 #endif // _DEBUG_USB_COMMS_ || _DEBUG_JTAG_IO_
 
+static const struct command_registration vsllink_command_handlers[] = {
+   {
+   .name = vsllink_usb_vid,
+   .handler = vsllink_handle_usb_vid_command,
+   .mode = COMMAND_CONFIG,
+   },
+   {
+   .name = vsllink_usb_pid,
+   .handler = vsllink_handle_usb_pid_command,
+   .mode = COMMAND_CONFIG,
+   },
+   {
+   .name = vsllink_usb_bulkin,
+   .handler = vsllink_handle_usb_bulkin_command,
+   .mode = COMMAND_CONFIG,
+   },
+   {
+   .name = vsllink_usb_bulkout,
+   .handler = vsllink_handle_usb_bulkout_command,
+   .mode = COMMAND_CONFIG,
+   },
+   {
+   .name = vsllink_usb_interface,
+   .handler = vsllink_handle_usb_interface_command,
+   .mode = COMMAND_CONFIG,
+   },
+   {
+   .name = vsllink_mode,
+   .handler = vsllink_handle_mode_command,
+   .mode = COMMAND_CONFIG,
+   },
+   };
+
 static int vsllink_register_commands(struct command_context *cmd_ctx)
 {
-   COMMAND_REGISTER(cmd_ctx, NULL, vsllink_usb_vid,
-   vsllink_handle_usb_vid_command, COMMAND_CONFIG,
-   NULL);
-   COMMAND_REGISTER(cmd_ctx, NULL, vsllink_usb_pid,
-   vsllink_handle_usb_pid_command, COMMAND_CONFIG,
-   NULL);
-   COMMAND_REGISTER(cmd_ctx, NULL, vsllink_usb_bulkin,
-   vsllink_handle_usb_bulkin_command, COMMAND_CONFIG,
-   NULL);
-   COMMAND_REGISTER(cmd_ctx, NULL, vsllink_usb_bulkout,
-   vsllink_handle_usb_bulkout_command, COMMAND_CONFIG,
-   NULL);
-   COMMAND_REGISTER(cmd_ctx, NULL, vsllink_usb_interface,
-   vsllink_handle_usb_interface_command, COMMAND_CONFIG,
-   NULL);
-   COMMAND_REGISTER(cmd_ctx, NULL, vsllink_mode,
-   vsllink_handle_mode_command, COMMAND_CONFIG,
-   NULL);
-
-   return ERROR_OK;
+   return register_commands(cmd_ctx, NULL,
+   ARRAY_SIZE(vsllink_command_handlers),
+   vsllink_command_handlers);
 }
 
 struct jtag_interface vsllink_interface = {
-- 
1.6.4.4

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH 10/12] jtag: use register_commands()

2009-11-21 Thread Zachary T Welch

Use register commands with command registration array.

Signed-off-by: Zachary T Welch z...@superlucidity.net
---
 src/jtag/tcl.c |  187 
 1 files changed, 120 insertions(+), 67 deletions(-)

diff --git a/src/jtag/tcl.c b/src/jtag/tcl.c
index bd672b6..1c80245 100644
--- a/src/jtag/tcl.c
+++ b/src/jtag/tcl.c
@@ -1413,66 +1413,128 @@ COMMAND_HANDLER(handle_tms_sequence_command)
return ERROR_OK;
 }
 
+static const struct command_registration jtag_command_handlers[] = {
+   {
+   .name = interface,
+   .handler = handle_interface_command,
+   .mode = COMMAND_CONFIG,
+   .help = select a JTAG interface,
+   .usage = driver_name,
+   },
+   {
+   .name = interface_list,
+   .handler = handle_interface_list_command,
+   .mode = COMMAND_ANY,
+   .help = list all built-in interfaces,
+   },
+   {
+   .name = jtag_khz,
+   .handler = handle_jtag_khz_command,
+   .mode = COMMAND_ANY,
+   .help = set maximum jtag speed (if supported),
+   .usage = khz:0=rtck,
+   },
+   {
+   .name = jtag_rclk,
+   .handler = handle_jtag_rclk_command,
+   .mode = COMMAND_ANY,
+   .help = set JTAG speed to RCLK or use fallback speed,
+   .usage = fallback_speed_khz,
+   },
+   {
+   .name = reset_config,
+   .handler = handle_reset_config_command,
+   .mode = COMMAND_ANY,
+   .help = configure JTAG reset behavior,
+   .usage = [none|trst_only|srst_only|trst_and_srst] 
+   
[srst_pulls_trst|trst_pulls_srst|combined|separate] 
+   [srst_gates_jtag|srst_nogate] 
+   [trst_push_pull|trst_open_drain] 
+   [srst_push_pull|srst_open_drain],
+   },
+   {
+   .name = jtag_nsrst_delay,
+   .handler = handle_jtag_nsrst_delay_command,
+   .mode = COMMAND_ANY,
+   .help = - delay after deasserting srst in ms,
+   .usage = ms,
+   },
+   {
+   .name = jtag_ntrst_delay,
+   .handler = handle_jtag_ntrst_delay_command,
+   .mode = COMMAND_ANY,
+   .help =  delay after deasserting trst in ms,
+   .usage = ms
+   },
+   {
+   .name = jtag_nsrst_assert_width,
+   .handler = handle_jtag_nsrst_assert_width_command,
+   .mode = COMMAND_ANY,
+   .help = - delay after asserting srst in ms,
+   .usage = ms
+   },
+   {
+   .name = jtag_ntrst_assert_width,
+   .handler = handle_jtag_ntrst_assert_width_command,
+   .mode = COMMAND_ANY,
+   .help = - delay after asserting trst in ms,
+   .usage = ms
+   },
+   {
+   .name = scan_chain,
+   .handler = handle_scan_chain_command,
+   .mode = COMMAND_EXEC,
+   .help = print current scan chain configuration,
+   },
+   {
+   .name = jtag_reset,
+   .handler = handle_jtag_reset_command,
+   .mode = COMMAND_EXEC,
+   .help = toggle reset lines,
+   .usage = trst srst,
+   },
+   {
+   .name = runtest,
+   .handler = handle_runtest_command,
+   .mode = COMMAND_EXEC,
+   .help = move to Run-Test/Idle, and execute 
num_cycles,
+   .usage = num_cycles
+   },
+   {
+   .name = irscan,
+   .handler = handle_irscan_command,
+   .mode = COMMAND_EXEC,
+   .help = execute IR scan,
+   .usage = device instr [dev2] [instr2] ...,
+   },
+   {
+   .name = verify_ircapture,
+   .handler = handle_verify_ircapture_command,
+   .mode = COMMAND_ANY,
+   .help = verify value captured during Capture-IR,
+   .usage =

[Openocd-development] [PATCH 12/12] remove register_callbacks from jtag interface

2009-11-21 Thread Zachary T Welch

Changes the jtag_interface-register_callbacks field to a list of
commands to be registered.  Changes callback to invocation of
register_commands() with that command registration list.  Removes all
JTAG interface driver register_command callback functions, which the
previous commits had converted into identical calls.

Signed-off-by: Zachary T Welch z...@superlucidity.net
---
 src/jtag/amt_jtagaccel.c |   10 ++
 src/jtag/arm-jtag-ew.c   |   13 +
 src/jtag/dummy.c |9 +++--
 src/jtag/ft2232.c|   12 ++--
 src/jtag/gw16012.c   |   10 ++
 src/jtag/interface.h |3 ++-
 src/jtag/jlink.c |   13 +
 src/jtag/parport.c   |   29 +
 src/jtag/presto.c|   13 +
 src/jtag/rlink/rlink.c   |   44 
 src/jtag/tcl.c   |   11 +--
 src/jtag/vsllink.c   |   11 +++
 12 files changed, 47 insertions(+), 131 deletions(-)

diff --git a/src/jtag/amt_jtagaccel.c b/src/jtag/amt_jtagaccel.c
index 7729714..0d22634 100644
--- a/src/jtag/amt_jtagaccel.c
+++ b/src/jtag/amt_jtagaccel.c
@@ -557,16 +557,10 @@ static const struct command_registration 
amtjtagaccel_command_handlers[] = {
},
};
 
-static int amt_jtagaccel_register_commands(struct command_context *cmd_ctx)
-{
-   return register_commands(cmd_ctx, NULL,
-   ARRAY_SIZE(amtjtagaccel_command_handlers),
-   amtjtagaccel_command_handlers);
-}
-
 struct jtag_interface amt_jtagaccel_interface = {
.name = amt_jtagaccel,
-   .register_commands = amt_jtagaccel_register_commands,
+   .num_commands = ARRAY_SIZE(amtjtagaccel_command_handlers),
+   .commands = amtjtagaccel_command_handlers,
.init = amt_jtagaccel_init,
.quit = amt_jtagaccel_quit,
.speed = amt_jtagaccel_speed,
diff --git a/src/jtag/arm-jtag-ew.c b/src/jtag/arm-jtag-ew.c
index 5363ae8..698e5e2 100644
--- a/src/jtag/arm-jtag-ew.c
+++ b/src/jtag/arm-jtag-ew.c
@@ -510,19 +510,16 @@ static const struct command_registration 
armjtagew_command_handlers[] = {
},
};
 
-static int armjtagew_register_commands(struct command_context *cmd_ctx)
-{
-   return register_commands(cmd_ctx, NULL,
-   ARRAY_SIZE(armjtagew_command_handlers),
-   armjtagew_command_handlers);
-}
-
 struct jtag_interface armjtagew_interface = {
.name = arm-jtag-ew,
+
+   .num_commands = ARRAY_SIZE(armjtagew_command_handlers),
+   .commands = armjtagew_command_handlers,
+
.execute_queue = armjtagew_execute_queue,
.speed = armjtagew_speed,
.khz = armjtagew_khz,
-   .register_commands = armjtagew_register_commands,
+
.init = armjtagew_init,
.quit = armjtagew_quit,
};
diff --git a/src/jtag/dummy.c b/src/jtag/dummy.c
index 0516790..be804b5 100644
--- a/src/jtag/dummy.c
+++ b/src/jtag/dummy.c
@@ -134,11 +134,6 @@ static int dummy_speed(int speed)
return ERROR_OK;
 }
 
-static int dummy_register_commands(struct command_context *cmd_ctx)
-{
-   return ERROR_OK;
-}
-
 static int dummy_init(void)
 {
bitbang_interface = dummy_bitbang;
@@ -157,10 +152,12 @@ static int dummy_quit(void)
 struct jtag_interface dummy_interface = {
.name = dummy,
 
+   .commands = NULL,
+   .num_commands = 0,
+
.execute_queue = bitbang_execute_queue,
 
.speed = dummy_speed,
-   .register_commands = dummy_register_commands,
.khz = dummy_khz,
.speed_div = dummy_speed_div,
 
diff --git a/src/jtag/ft2232.c b/src/jtag/ft2232.c
index d202427..8b80f87 100644
--- a/src/jtag/ft2232.c
+++ b/src/jtag/ft2232.c
@@ -4007,18 +4007,10 @@ static const struct command_registration 
ft2232_command_handlers[] = {
}
};
 
-
-static int ft2232_register_commands(struct command_context* cmd_ctx)
-{
-   return register_commands(cmd_ctx, NULL,
-   ARRAY_SIZE(ft2232_command_handlers),
-   ft2232_command_handlers);
-}
-
-
 struct jtag_interface ft2232_interface = {
.name = ft2232,
-   .register_commands = ft2232_register_commands,
+   .num_commands = ARRAY_SIZE(ft2232_command_handlers),
+   .commands = ft2232_command_handlers,
.init = ft2232_init,
.quit = ft2232_quit,
.speed = ft2232_speed,
diff --git a/src/jtag/gw16012.c b/src/jtag/gw16012.c
index 5118562..74cdfa0 100644
--- a/src/jtag/gw16012.c
+++ b/src/jtag/gw16012.c
@@ -572,16 +572,10 @@ static const struct command_registration 
gw16012_command_handlers[] = {
},
};
 
-static int

[Openocd-development] [PATCH 09/12] presto: use register_commands()

2009-11-21 Thread Zachary T Welch

Use register_commands() with command registration array.

Signed-off-by: Zachary T Welch z...@superlucidity.net
---
 src/jtag/presto.c |   16 +---
 1 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/src/jtag/presto.c b/src/jtag/presto.c
index f22bd9e..6f5833a 100644
--- a/src/jtag/presto.c
+++ b/src/jtag/presto.c
@@ -739,11 +739,21 @@ COMMAND_HANDLER(presto_handle_serial_command)
return ERROR_OK;
 }
 
+static const struct command_registration presto_command_handlers[] = {
+   {
+   .name = presto_serial,
+   .handler = presto_handle_serial_command,
+   .mode = COMMAND_CONFIG,
+   .help = configure serial port,
+   .usage = devname,
+   },
+   };
+
 static int presto_jtag_register_commands(struct command_context *cmd_ctx)
 {
-   COMMAND_REGISTER(cmd_ctx, NULL, presto_serial, 
presto_handle_serial_command,
-   COMMAND_CONFIG, NULL);
-   return ERROR_OK;
+   return register_commands(cmd_ctx, NULL,
+   ARRAY_SIZE(presto_command_handlers),
+   presto_command_handlers);
 }
 
 static int presto_jtag_init(void)
-- 
1.6.4.4

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 3/3] support for scripts in $HOME/.openocd

2009-11-21 Thread Andreas Fritiofson

On Sat, Nov 21, 2009 at 7:14 PM, Zach Welch z...@superlucidity.net wrote:
 On Sat, 2009-11-21 at 16:53 +0100, Andreas Fritiofson wrote:
 Add $HOME/.openocd as the first default script search directory, allowing
 the user to override the standard scripts.

 Comments are in-line and at the end.

 Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com
 ---
  src/helper/options.c |   16 +++-
  1 files changed, 15 insertions(+), 1 deletions(-)

 diff --git a/src/helper/options.c b/src/helper/options.c
 index 5792e11..2187ff7 100644
 --- a/src/helper/options.c
 +++ b/src/helper/options.c
 @@ -29,6 +29,7 @@
  #include server.h

  #include getopt.h
 +#include stdlib.h

  static int help_flag, version_flag;

 @@ -54,6 +55,10 @@ int configuration_output_handler(struct command_context 
 *context, const char* li

  static void add_default_dirs(void)
  {
 +#ifndef MAX_PATH
 +#define MAX_PATH 1024
 +#endif
 +

 PATH_MAX should be defined and available (in limits.h).  Use it.

I did some research on the matter, and it seems that PATH_MAX is only
defined if there actually is a limit, which apparently is not always
the case. Even if defined, the value is often arbitrary or unsuitably
large. So the #ifndef would have to stay, albeit with another name.
Since MAX_PATH was already used in the WIN32 specific section, I
decided to reuse that to avoid confusion with two different names.

Of course, should PATH_MAX be equally valid on WIN32 even though it's
an extension, that section could be changed to use it too if
available. I can verify if that's the case earliest on Monday, since I
have no Windows machine at home, and submit a clean-up patch after
that. In the meantime, this should work perfectly, even if users with
a 1K long home directory might be disappointed. :)


  #ifdef _WIN32
       /* Add the parent of the directory where openocd.exe resides to the
        * config script search path.
 @@ -101,7 +106,16 @@ static void add_default_dirs(void)
        * listed last in the built-in search order, so the user can
        * override these scripts with site-specific customizations.
        */
 -     /// @todo Implement @c add_script_search_dir(${HOME}/.openocd).

 As the one who added that @todo item, thanks for doing this! :)

 +
 +     char *home = getenv(HOME);
 +
 +     if (home) {
 +             char path[MAX_PATH];
 +
 +             if (snprintf(path, MAX_PATH, %s/.openocd, home)  MAX_PATH)
 +                     add_script_search_dir(path);
 +     }
 +
       add_script_search_dir(PKGDATADIR /site);
       add_script_search_dir(PKGDATADIR /scripts);
  #endif

 As others note, this deserves mention in doc/openocd.texi and NEWS.


I'll look into a patch for those soon-ish.

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 0/3] improve default script search path

2009-11-21 Thread Michael Schwingen

Andreas Fritiofson wrote:
 This series improves the default script search path to include $HOME/.openocd.
   
Good idea.
I proposed that a long time ago, but it was rejected back then for
forgotten reasons - which is why I use a wrapper script now.

cu
Michael

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 3/3] support for scripts in $HOME/.openocd

2009-11-21 Thread Øyvind Harboe

On Sat, Nov 21, 2009 at 7:14 PM, Zach Welch z...@superlucidity.net wrote:
 On Sat, 2009-11-21 at 16:53 +0100, Andreas Fritiofson wrote:
 Add $HOME/.openocd as the first default script search directory, allowing
 the user to override the standard scripts.

 Comments are in-line and at the end.

 Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com
 ---
  src/helper/options.c |   16 +++-
  1 files changed, 15 insertions(+), 1 deletions(-)

 diff --git a/src/helper/options.c b/src/helper/options.c
 index 5792e11..2187ff7 100644
 --- a/src/helper/options.c
 +++ b/src/helper/options.c
 @@ -29,6 +29,7 @@
  #include server.h

  #include getopt.h
 +#include stdlib.h

  static int help_flag, version_flag;

 @@ -54,6 +55,10 @@ int configuration_output_handler(struct command_context 
 *context, const char* li

  static void add_default_dirs(void)
  {
 +#ifndef MAX_PATH
 +#define MAX_PATH 1024
 +#endif
 +

 PATH_MAX should be defined and available (in limits.h).  Use it.

Why not just allocate dynamically and avoid the problem at the root?

There *is* no PATH_MAX in Windows really.


-- 
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 03/12] arm-jtag-ew: use register_commands()

2009-11-21 Thread Øyvind Harboe

Why is a table better than a fn call for registering commands?




-- 
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 03/12] arm-jtag-ew: use register_commands()

2009-11-21 Thread Zach Welch

On Sat, 2009-11-21 at 21:31 +0100, Øyvind Harboe wrote:
 Why is a table better than a fn call for registering commands?

It's harder to screw up with the new way of doing things, as the
registration parameters are more explicit.  It also eliminates a lot of
redundant calls to register_command{,s} with a single call in tcl.c.
In short, it's more readable and produces slightly better binaries. 

More importantly, the first patches in the previous series allowed the
registration parameters to be extended without disrupting the existing
registration callers.  That series then added aded the 'usage' command,
and subsequent patches begin to split the help text out.  Other
extensions will be much easier -- and can be done in stages -- by using
a table instead of a function.

For the target and flash, we'll need further patches to extend the
registration capabilities to allow inheriting commands.  An arm966e
might register its own commands, but it also needs to register the
arm9tdmi, arm7_9_common, arm, and etm groups of commands as well.
I have these changes underway in my local tree, but each of my current
series offered reasonable milestones that showed the intended benefits.

There are some other minor features that need to be added to allow this
transformation to take place throughout the tree, but the result should
be a more openly transparent and extensible command handling system
(that eliminates redundancy when coding things up).  Naturally, I'll
update the command API documentation in the manual once I am done with
these changes throughout the tree.

--Z

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [patch 0/5] more ARM register cleanup

2009-11-21 Thread David Brownell

I'm trying to get rid of most I know how the register cache
is laid out knowledge, and eventually to make the ARM11 code
use the standard register framework.  These are stepping stones
along that path.

 - ARM11: remove useless #defines
 - simplify CPSR access
 - define set_cpsr() and a mapping utility
 - make set_cpsr() handle Thumb/Jazelle mode bits
 - kick in that mapping utility

These all seem to behave, but I'm still giving that last one
some eyeballing.  Assuming no significant issue are reported,
I'll commit these tomorrow.

- Dave
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [patch 1/5] ARM11: remove disabled register hooks

2009-11-21 Thread David Brownell

Minor cleanup of ARM11 register handling:  remove disabled
register hooks.  This should all be handled by shared code,
and this stuff is just clutter.
---
 src/target/arm11.c |   89 ---
 src/target/arm11.h |7 +---
 2 files changed, 3 insertions(+), 93 deletions(-)

--- a/src/target/arm11.c
+++ b/src/target/arm11.c
@@ -115,52 +115,8 @@ static const struct arm11_reg_defs arm11
{lr,  14, 14, ARM11_REGISTER_CORE},
{pc,  15, 15, ARM11_REGISTER_CORE},
 
-#if ARM11_REGCACHE_FREGS
-   {f0,  0,  16, ARM11_REGISTER_FX},
-   {f1,  1,  17, ARM11_REGISTER_FX},
-   {f2,  2,  18, ARM11_REGISTER_FX},
-   {f3,  3,  19, ARM11_REGISTER_FX},
-   {f4,  4,  20, ARM11_REGISTER_FX},
-   {f5,  5,  21, ARM11_REGISTER_FX},
-   {f6,  6,  22, ARM11_REGISTER_FX},
-   {f7,  7,  23, ARM11_REGISTER_FX},
-   {fps, 0,  24, ARM11_REGISTER_FPS},
-#endif
-
{cpsr,0,  25, ARM11_REGISTER_CPSR},
 
-#if ARM11_REGCACHE_MODEREGS
-   {r8_fiq,  8,  -1, ARM11_REGISTER_FIQ},
-   {r9_fiq,  9,  -1, ARM11_REGISTER_FIQ},
-   {r10_fiq, 10, -1, ARM11_REGISTER_FIQ},
-   {r11_fiq, 11, -1, ARM11_REGISTER_FIQ},
-   {r12_fiq, 12, -1, ARM11_REGISTER_FIQ},
-   {r13_fiq, 13, -1, ARM11_REGISTER_FIQ},
-   {r14_fiq, 14, -1, ARM11_REGISTER_FIQ},
-   {spsr_fiq, 0, -1, ARM11_REGISTER_SPSR_FIQ},
-
-   {r13_svc, 13, -1, ARM11_REGISTER_SVC},
-   {r14_svc, 14, -1, ARM11_REGISTER_SVC},
-   {spsr_svc, 0, -1, ARM11_REGISTER_SPSR_SVC},
-
-   {r13_abt, 13, -1, ARM11_REGISTER_ABT},
-   {r14_abt, 14, -1, ARM11_REGISTER_ABT},
-   {spsr_abt, 0, -1, ARM11_REGISTER_SPSR_ABT},
-
-   {r13_irq, 13, -1, ARM11_REGISTER_IRQ},
-   {r14_irq, 14, -1, ARM11_REGISTER_IRQ},
-   {spsr_irq, 0, -1, ARM11_REGISTER_SPSR_IRQ},
-
-   {r13_und, 13, -1, ARM11_REGISTER_UND},
-   {r14_und, 14, -1, ARM11_REGISTER_UND},
-   {spsr_und, 0, -1, ARM11_REGISTER_SPSR_UND},
-
-   /* ARM1176 only */
-   {r13_mon, 13, -1, ARM11_REGISTER_MON},
-   {r14_mon, 14, -1, ARM11_REGISTER_MON},
-   {spsr_mon, 0, -1, ARM11_REGISTER_SPSR_MON},
-#endif
-
/* Debug Registers */
{dscr,0,  -1, ARM11_REGISTER_DSCR},
{wdtr,0,  -1, ARM11_REGISTER_WDTR},
@@ -191,52 +147,8 @@ enum arm11_regcache_ids
ARM11_RC_R15,
ARM11_RC_PC = ARM11_RC_R15,
 
-#if ARM11_REGCACHE_FREGS
-   ARM11_RC_F0,
-   ARM11_RC_FX = ARM11_RC_F0,
-   ARM11_RC_F1,
-   ARM11_RC_F2,
-   ARM11_RC_F3,
-   ARM11_RC_F4,
-   ARM11_RC_F5,
-   ARM11_RC_F6,
-   ARM11_RC_F7,
-   ARM11_RC_FPS,
-#endif
-
ARM11_RC_CPSR,
 
-#if ARM11_REGCACHE_MODEREGS
-   ARM11_RC_R8_FIQ,
-   ARM11_RC_R9_FIQ,
-   ARM11_RC_R10_FIQ,
-   ARM11_RC_R11_FIQ,
-   ARM11_RC_R12_FIQ,
-   ARM11_RC_R13_FIQ,
-   ARM11_RC_R14_FIQ,
-   ARM11_RC_SPSR_FIQ,
-
-   ARM11_RC_R13_SVC,
-   ARM11_RC_R14_SVC,
-   ARM11_RC_SPSR_SVC,
-
-   ARM11_RC_R13_ABT,
-   ARM11_RC_R14_ABT,
-   ARM11_RC_SPSR_ABT,
-
-   ARM11_RC_R13_IRQ,
-   ARM11_RC_R14_IRQ,
-   ARM11_RC_SPSR_IRQ,
-
-   ARM11_RC_R13_UND,
-   ARM11_RC_R14_UND,
-   ARM11_RC_SPSR_UND,
-
-   ARM11_RC_R13_MON,
-   ARM11_RC_R14_MON,
-   ARM11_RC_SPSR_MON,
-#endif
-
ARM11_RC_DSCR,
ARM11_RC_WDTR,
ARM11_RC_RDTR,
@@ -244,6 +156,7 @@ enum arm11_regcache_ids
ARM11_RC_MAX,
 };
 
+/* GDB expects ARMs to give R0..R15, CPSR, and 7 FPA dummies */
 #define ARM11_GDB_REGISTER_COUNT   26
 
 static int arm11_on_enter_debug_state(struct arm11_common *arm11);
--- a/src/target/arm11.h
+++ b/src/target/arm11.h
@@ -37,12 +37,9 @@
 #define ZU %Iu
 #endif
 
-#define ARM11_REGCACHE_MODEREGS0
-#define ARM11_REGCACHE_FREGS   0
 
-#define ARM11_REGCACHE_COUNT   (20 +   
\
-23 * ARM11_REGCACHE_MODEREGS + 
\
- 9 * ARM11_REGCACHE_FREGS)
+/* TEMPORARY -- till we switch to the shared infrastructure */
+#define ARM11_REGCACHE_COUNT   20
 
 #define ARM11_TAP_DEFAULT  TAP_INVALID
 
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [patch 3/5] ARM: define two register utilities

2009-11-21 Thread David Brownell

Define arm_reg_current() ... returning handle to a given register,
and encapsulating the current mode's register shadowing.  It's got
one current use, for reporting the current register set to GDB.
This will let later patches clean up much ARMV4_5_CORE_REG_MODE()
nastiness, saving a bit of code.

Define and use arm_set_cpsr() ... initially it updates the cached
CPSR and sets up state used by arm_reg_current(), plus any SPSR
handle.   (Later: can also set up for T and J bits.)
---
 src/target/arm720t.c   |   12 +++--
 src/target/arm7_9_common.c |   18 +++-
 src/target/arm920t.c   |   12 +++--
 src/target/arm926ejs.c |   12 +++--
 src/target/armv4_5.c   |   96 +--
 src/target/armv4_5.h   |8 +++
 src/target/cortex_a8.c |7 ---
 src/target/xscale.c|5 --
 8 files changed, 122 insertions(+), 48 deletions(-)

--- a/src/target/arm720t.c
+++ b/src/target/arm720t.c
@@ -347,18 +347,20 @@ static int arm720t_soft_reset_halt(struc
target-state = TARGET_HALTED;
 
/* SVC, ARM state, IRQ and FIQ disabled */
-   buf_set_u32(armv4_5-cpsr-value, 0, 8, 0xd3);
+   uint32_t cpsr;
+
+   cpsr = buf_get_u32(armv4_5-cpsr-value, 0, 32);
+   cpsr = ~0xff;
+   cpsr |= 0xd3;
+   arm_set_cpsr(armv4_5, cpsr);
armv4_5-cpsr-dirty = 1;
-   armv4_5-cpsr-valid = 1;
+   armv4_5-core_state = ARMV4_5_STATE_ARM;
 
/* start fetching from 0x0 */
buf_set_u32(armv4_5-core_cache-reg_list[15].value, 0, 32, 0x0);
armv4_5-core_cache-reg_list[15].dirty = 1;
armv4_5-core_cache-reg_list[15].valid = 1;
 
-   armv4_5-core_mode = ARMV4_5_MODE_SVC;
-   armv4_5-core_state = ARMV4_5_STATE_ARM;
-
arm720t_disable_mmu_caches(target, 1, 1, 1);
arm720t-armv4_5_mmu.mmu_enabled = 0;
arm720t-armv4_5_mmu.armv4_5_cache.d_u_cache_enabled = 0;
--- a/src/target/arm7_9_common.c
+++ b/src/target/arm7_9_common.c
@@ -1227,18 +1227,20 @@ int arm7_9_soft_reset_halt(struct target
register_cache_invalidate(armv4_5-core_cache);
 
/* SVC, ARM state, IRQ and FIQ disabled */
-   buf_set_u32(armv4_5-cpsr-value, 0, 8, 0xd3);
+   uint32_t cpsr;
+
+   cpsr = buf_get_u32(armv4_5-cpsr-value, 0, 32);
+   cpsr = ~0xff;
+   cpsr |= 0xd3;
+   arm_set_cpsr(armv4_5, cpsr);
armv4_5-cpsr-dirty = 1;
-   armv4_5-cpsr-valid = 1;
+   armv4_5-core_state = ARMV4_5_STATE_ARM;
 
/* start fetching from 0x0 */
buf_set_u32(armv4_5-core_cache-reg_list[15].value, 0, 32, 0x0);
armv4_5-core_cache-reg_list[15].dirty = 1;
armv4_5-core_cache-reg_list[15].valid = 1;
 
-   armv4_5-core_mode = ARMV4_5_MODE_SVC;
-   armv4_5-core_state = ARMV4_5_STATE_ARM;
-
/* reset registers */
for (i = 0; i = 14; i++)
{
@@ -1401,11 +1403,7 @@ static int arm7_9_debug_entry(struct tar
if (armv4_5-core_state == ARMV4_5_STATE_THUMB)
cpsr |= 0x20;
 
-   buf_set_u32(armv4_5-cpsr-value, 0, 32, cpsr);
-   armv4_5-cpsr-dirty = 0;
-   armv4_5-cpsr-valid = 1;
-
-   armv4_5-core_mode = cpsr  0x1f;
+   arm_set_cpsr(armv4_5, cpsr);
 
if (!is_arm_mode(armv4_5-core_mode))
{
--- a/src/target/arm920t.c
+++ b/src/target/arm920t.c
@@ -596,18 +596,20 @@ int arm920t_soft_reset_halt(struct targe
target-state = TARGET_HALTED;
 
/* SVC, ARM state, IRQ and FIQ disabled */
-   buf_set_u32(armv4_5-cpsr-value, 0, 8, 0xd3);
+   uint32_t cpsr;
+
+   cpsr = buf_get_u32(armv4_5-cpsr-value, 0, 32);
+   cpsr = ~0xff;
+   cpsr |= 0xd3;
+   arm_set_cpsr(armv4_5, cpsr);
armv4_5-cpsr-dirty = 1;
-   armv4_5-cpsr-valid = 1;
+   armv4_5-core_state = ARMV4_5_STATE_ARM;
 
/* start fetching from 0x0 */
buf_set_u32(armv4_5-core_cache-reg_list[15].value, 0, 32, 0x0);
armv4_5-core_cache-reg_list[15].dirty = 1;
armv4_5-core_cache-reg_list[15].valid = 1;
 
-   armv4_5-core_mode = ARMV4_5_MODE_SVC;
-   armv4_5-core_state = ARMV4_5_STATE_ARM;
-
arm920t_disable_mmu_caches(target, 1, 1, 1);
arm920t-armv4_5_mmu.mmu_enabled = 0;
arm920t-armv4_5_mmu.armv4_5_cache.d_u_cache_enabled = 0;
--- a/src/target/arm926ejs.c
+++ b/src/target/arm926ejs.c
@@ -565,18 +565,20 @@ int arm926ejs_soft_reset_halt(struct tar
target-state = TARGET_HALTED;
 
/* SVC, ARM state, IRQ and FIQ disabled */
-   buf_set_u32(armv4_5-cpsr-value, 0, 8, 0xd3);
+   uint32_t cpsr;
+
+   cpsr = buf_get_u32(armv4_5-cpsr-value, 0, 32);
+   cpsr = ~0xff;
+   cpsr |= 0xd3;
+   arm_set_cpsr(armv4_5, cpsr);
armv4_5-cpsr-dirty = 1;
-   armv4_5-cpsr-valid = 1;
+   armv4_5-core_state = ARMV4_5_STATE_ARM;
 
/* start fetching from 0x0 */
buf_set_u32(armv4_5-core_cache-reg_list[15].value, 0, 32, 0x0);
armv4_5-core_cache-reg_list[15].dirty = 1;

[Openocd-development] [patch 4/5] ARM: arm_set_cpsr() handles T and J bits

2009-11-21 Thread David Brownell

Have arm_set_cpsr() handle the two core state flags, updating
the CPU state.  This eliminates code in various debug_entry()
paths, and marginally improves handling of the J bit.

Catch and comment a few holes in the handling of the J bit on
ARM926ejs cores ... it's unlikely our users will care about
Jazelle mode, but we can at least warn of Impending Doom.  If
anyone does use it, these breadcrumbs may help them to find
the right path through the code.
---
 src/target/arm720t.c   |1 
 src/target/arm7_9_common.c |   32 +---
 src/target/arm920t.c   |1 
 src/target/arm926ejs.c |1 
 src/target/armv4_5.c   |   67 +++
 src/target/cortex_a8.c |   23 --
 src/target/xscale.c|6 ---
 7 files changed, 52 insertions(+), 79 deletions(-)

--- a/src/target/arm720t.c
+++ b/src/target/arm720t.c
@@ -354,7 +354,6 @@ static int arm720t_soft_reset_halt(struc
cpsr |= 0xd3;
arm_set_cpsr(armv4_5, cpsr);
armv4_5-cpsr-dirty = 1;
-   armv4_5-core_state = ARMV4_5_STATE_ARM;
 
/* start fetching from 0x0 */
buf_set_u32(armv4_5-core_cache-reg_list[15].value, 0, 32, 0x0);
--- a/src/target/arm7_9_common.c
+++ b/src/target/arm7_9_common.c
@@ -1223,6 +1223,8 @@ int arm7_9_soft_reset_halt(struct target
arm7_9-change_to_arm(target, r0_thumb, pc_thumb);
}
 
+   /* REVISIT likewise for bit 5 -- switch Jazelle-to-ARM */
+
/* all register content is now invalid */
register_cache_invalidate(armv4_5-core_cache);
 
@@ -1234,7 +1236,6 @@ int arm7_9_soft_reset_halt(struct target
cpsr |= 0xd3;
arm_set_cpsr(armv4_5, cpsr);
armv4_5-cpsr-dirty = 1;
-   armv4_5-core_state = ARMV4_5_STATE_ARM;
 
/* start fetching from 0x0 */
buf_set_u32(armv4_5-core_cache-reg_list[15].value, 0, 32, 0x0);
@@ -1334,7 +1335,7 @@ static int arm7_9_debug_entry(struct tar
uint32_t context[16];
uint32_t* context_p[16];
uint32_t r0_thumb, pc_thumb;
-   uint32_t cpsr;
+   uint32_t cpsr, cpsr_mask = 0;
int retval;
struct arm7_9_common *arm7_9 = target_to_arm7_9(target);
struct armv4_5_common_s *armv4_5 = arm7_9-armv4_5_common;
@@ -1379,11 +1380,21 @@ static int arm7_9_debug_entry(struct tar
LOG_DEBUG(target entered debug from Thumb state);
/* Entered debug from Thumb mode */
armv4_5-core_state = ARMV4_5_STATE_THUMB;
+   cpsr_mask = 1  5;
arm7_9-change_to_arm(target, r0_thumb, pc_thumb);
-   LOG_DEBUG(r0_thumb: 0x%8.8 PRIx32 , pc_thumb: 0x%8.8 PRIx32 
, r0_thumb, pc_thumb);
-   }
-   else
-   {
+   LOG_DEBUG(r0_thumb: 0x%8.8 PRIx32
+   , pc_thumb: 0x%8.8 PRIx32, r0_thumb, pc_thumb);
+   } else if (buf_get_u32(dbg_stat-value, 5, 1)) {
+   /* \todo Get some vaguely correct handling of Jazelle, if
+* anyone ever uses it and full info becomes available.
+* See ARM9EJS TRM B.7.1 for how to switch J-ARM; and
+* B.7.3 for the reverse.  That'd be the bare minimum...
+*/
+   LOG_DEBUG(target entered debug from Jazelle state);
+   armv4_5-core_state = ARMV4_5_STATE_JAZELLE;
+   cpsr_mask = 1  24;
+   LOG_ERROR(Jazelle debug entry -- BROKEN!);
+   } else {
LOG_DEBUG(target entered debug from ARM state);
/* Entered debug from ARM mode */
armv4_5-core_state = ARMV4_5_STATE_ARM;
@@ -1399,11 +1410,10 @@ static int arm7_9_debug_entry(struct tar
if ((retval = jtag_execute_queue()) != ERROR_OK)
return retval;
 
-   /* if the core has been executing in Thumb state, set the T bit */
-   if (armv4_5-core_state == ARMV4_5_STATE_THUMB)
-   cpsr |= 0x20;
-
-   arm_set_cpsr(armv4_5, cpsr);
+   /* Sync our CPSR copy with J or T bits EICE reported, but
+* which we then erased by putting the core into ARM mode.
+*/
+   arm_set_cpsr(armv4_5, cpsr | cpsr_mask);
 
if (!is_arm_mode(armv4_5-core_mode))
{
--- a/src/target/arm920t.c
+++ b/src/target/arm920t.c
@@ -603,7 +603,6 @@ int arm920t_soft_reset_halt(struct targe
cpsr |= 0xd3;
arm_set_cpsr(armv4_5, cpsr);
armv4_5-cpsr-dirty = 1;
-   armv4_5-core_state = ARMV4_5_STATE_ARM;
 
/* start fetching from 0x0 */
buf_set_u32(armv4_5-core_cache-reg_list[15].value, 0, 32, 0x0);
--- a/src/target/arm926ejs.c
+++ b/src/target/arm926ejs.c
@@ -572,7 +572,6 @@ int arm926ejs_soft_reset_halt(struct tar
cpsr |= 0xd3;
arm_set_cpsr(armv4_5, cpsr);
armv4_5-cpsr-dirty = 1;
-   armv4_5-core_state = ARMV4_5_STATE_ARM;
 
/* start fetching from 0x0 */
buf_set_u32(armv4_5-core_cache-reg_list[15].value, 0, 32, 0x0);
---

[Openocd-development] [patch 5/5] ARM: use arm_reg_current()

2009-11-21 Thread David Brownell

Start using the arm_reg_current() call.  This shrinks and speeds
the affected code.  It can also prevent some coredumps coming from
invalid CPSR values ... the ARMV4_5_CORE_REG_MODE() macro returns
bogus registers if e.g. Secure Monitor mode isn't supported by
the current CPU.
---
Not fully tweaked yet, but it behaves in basic testing.

 src/target/arm7_9_common.c |   45 -
 src/target/arm920t.c   |   66 ++-
 src/target/cortex_a8.c |   24 +--
 src/target/xscale.c|   21 -
 4 files changed, 87 insertions(+), 69 deletions(-)

--- a/src/target/arm7_9_common.c
+++ b/src/target/arm7_9_common.c
@@ -1245,9 +1245,11 @@ int arm7_9_soft_reset_halt(struct target
/* reset registers */
for (i = 0; i = 14; i++)
{
-   buf_set_u32(ARMV4_5_CORE_REG_MODE(armv4_5-core_cache, 
armv4_5-core_mode, i).value, 0, 32, 0x);
-   ARMV4_5_CORE_REG_MODE(armv4_5-core_cache, armv4_5-core_mode, 
i).dirty = 1;
-   ARMV4_5_CORE_REG_MODE(armv4_5-core_cache, armv4_5-core_mode, 
i).valid = 1;
+   struct reg *r = arm_reg_current(armv4_5, i);
+
+   buf_set_u32(r-value, 0, 32, 0x);
+   r-dirty = 1;
+   r-valid = 1;
}
 
if ((retval = target_call_event_callbacks(target, TARGET_EVENT_HALTED)) 
!= ERROR_OK)
@@ -1443,32 +1445,31 @@ static int arm7_9_debug_entry(struct tar
 
for (i = 0; i = 15; i++)
{
+   struct reg *r = arm_reg_current(armv4_5, i);
+
LOG_DEBUG(r%i: 0x%8.8 PRIx32 , i, context[i]);
-   buf_set_u32(ARMV4_5_CORE_REG_MODE(armv4_5-core_cache, 
armv4_5-core_mode, i).value, 0, 32, context[i]);
-   ARMV4_5_CORE_REG_MODE(armv4_5-core_cache, armv4_5-core_mode, 
i).dirty = 0;
-   ARMV4_5_CORE_REG_MODE(armv4_5-core_cache, armv4_5-core_mode, 
i).valid = 1;
+
+   buf_set_u32(r-value, 0, 32, context[i]);
+   /* r0 and r15 (pc) have to be restored later */
+   r-dirty = (i == 0) || (i == 15);
+   r-valid = 1;
}
 
LOG_DEBUG(entered debug state at PC 0x% PRIx32 , context[15]);
 
/* exceptions other than USR  SYS have a saved program status register 
*/
-   if ((armv4_5-core_mode != ARMV4_5_MODE_USR)  (armv4_5-core_mode != 
ARMV4_5_MODE_SYS))
-   {
+   if (armv4_5-spsr) {
uint32_t spsr;
arm7_9-read_xpsr(target, spsr, 1);
if ((retval = jtag_execute_queue()) != ERROR_OK)
{
return retval;
}
-   buf_set_u32(ARMV4_5_CORE_REG_MODE(armv4_5-core_cache, 
armv4_5-core_mode, 16).value, 0, 32, spsr);
-   ARMV4_5_CORE_REG_MODE(armv4_5-core_cache, armv4_5-core_mode, 
16).dirty = 0;
-   ARMV4_5_CORE_REG_MODE(armv4_5-core_cache, armv4_5-core_mode, 
16).valid = 1;
+   buf_set_u32(armv4_5-spsr-value, 0, 32, spsr);
+   armv4_5-spsr-dirty = 0;
+   armv4_5-spsr-valid = 1;
}
 
-   /* r0 and r15 (pc) have to be restored later */
-   ARMV4_5_CORE_REG_MODE(armv4_5-core_cache, armv4_5-core_mode, 0).dirty 
= ARMV4_5_CORE_REG_MODE(armv4_5-core_cache, armv4_5-core_mode, 0).valid;
-   ARMV4_5_CORE_REG_MODE(armv4_5-core_cache, armv4_5-core_mode, 
15).dirty = ARMV4_5_CORE_REG_MODE(armv4_5-core_cache, armv4_5-core_mode, 
15).valid;
-
if ((retval = jtag_execute_queue()) != ERROR_OK)
return retval;
 
@@ -2377,8 +2378,11 @@ int arm7_9_read_memory(struct target *ta
if (!is_arm_mode(armv4_5-core_mode))
return ERROR_FAIL;
 
-   for (i = 0; i = last_reg; i++)
-   ARMV4_5_CORE_REG_MODE(armv4_5-core_cache, armv4_5-core_mode, 
i).dirty = ARMV4_5_CORE_REG_MODE(armv4_5-core_cache, armv4_5-core_mode, 
i).valid;
+   for (i = 0; i = last_reg; i++) {
+   struct reg *r = arm_reg_current(armv4_5, i);
+
+   r-dirty = r-valid;
+   }
 
arm7_9-read_xpsr(target, cpsr, 0);
if ((retval = jtag_execute_queue()) != ERROR_OK)
@@ -2562,8 +2566,11 @@ int arm7_9_write_memory(struct target *t
if (!is_arm_mode(armv4_5-core_mode))
return ERROR_FAIL;
 
-   for (i = 0; i = last_reg; i++)
-   ARMV4_5_CORE_REG_MODE(armv4_5-core_cache, armv4_5-core_mode, 
i).dirty = ARMV4_5_CORE_REG_MODE(armv4_5-core_cache, armv4_5-core_mode, 
i).valid;
+   for (i = 0; i = last_reg; i++) {
+   struct reg *r = arm_reg_current(armv4_5, i);
+
+   r-dirty = r-valid;
+   }
 
arm7_9-read_xpsr(target, cpsr, 0);
if ((retval = jtag_execute_queue()) != ERROR_OK)
--- a/src/target/arm920t.c
+++ b/src/target/arm920t.c
@@ -216,6 +216,7 @@ static int arm920t_read_cp15_interpreted
uint32_t* regs_p[1];
uint32_t regs[2];
uint32_t cp15c15 = 0x0;
+

[Openocd-development] [patch 2/5] ARM: simplify CPSR handling

2009-11-21 Thread David Brownell

Stash a pointer to the CPSR in the struct arm, to help get rid
of the (common) references to its index in the register cache.

This removes almost all references to CPSR offsets outside of the
toplevel ARM code ... except a pair related to the current ARM11
simulator logic (which should be removable soonish).

This is a net minor code shrink of a few hundred bytes of object
code, and also makes the code more readable.
---
 src/target/arm720t.c   |8 ++---
 src/target/arm7_9_common.c |   59 ++-
 src/target/arm920t.c   |8 ++---
 src/target/arm926ejs.c |8 ++---
 src/target/arm_simulator.c |2 -
 src/target/armv4_5.c   |   38 ++-
 src/target/armv4_5.h   |   16 +++
 src/target/armv7a.c|3 --
 src/target/armv7a.h|   10 ---
 src/target/cortex_a8.c |   12 +++-
 src/target/xscale.c|   26 +++---
 11 files changed, 103 insertions(+), 87 deletions(-)

--- a/src/target/arm720t.c
+++ b/src/target/arm720t.c
@@ -240,7 +240,7 @@ static int arm720t_arch_state(struct tar
 armv4_5_state_strings[armv4_5-core_state],
 Jim_Nvp_value2name_simple(nvp_target_debug_reason, 
target-debug_reason)-name ,
 arm_mode_name(armv4_5-core_mode),
-
buf_get_u32(armv4_5-core_cache-reg_list[ARMV4_5_CPSR].value, 0, 32),
+buf_get_u32(armv4_5-cpsr-value, 0, 32),
 buf_get_u32(armv4_5-core_cache-reg_list[15].value, 
0, 32),
 state[arm720t-armv4_5_mmu.mmu_enabled],
 
state[arm720t-armv4_5_mmu.armv4_5_cache.d_u_cache_enabled]);
@@ -347,9 +347,9 @@ static int arm720t_soft_reset_halt(struc
target-state = TARGET_HALTED;
 
/* SVC, ARM state, IRQ and FIQ disabled */
-   buf_set_u32(armv4_5-core_cache-reg_list[ARMV4_5_CPSR].value, 0, 8, 
0xd3);
-   armv4_5-core_cache-reg_list[ARMV4_5_CPSR].dirty = 1;
-   armv4_5-core_cache-reg_list[ARMV4_5_CPSR].valid = 1;
+   buf_set_u32(armv4_5-cpsr-value, 0, 8, 0xd3);
+   armv4_5-cpsr-dirty = 1;
+   armv4_5-cpsr-valid = 1;
 
/* start fetching from 0x0 */
buf_set_u32(armv4_5-core_cache-reg_list[15].value, 0, 32, 0x0);
--- a/src/target/arm7_9_common.c
+++ b/src/target/arm7_9_common.c
@@ -1227,9 +1227,9 @@ int arm7_9_soft_reset_halt(struct target
register_cache_invalidate(armv4_5-core_cache);
 
/* SVC, ARM state, IRQ and FIQ disabled */
-   buf_set_u32(armv4_5-core_cache-reg_list[ARMV4_5_CPSR].value, 0, 8, 
0xd3);
-   armv4_5-core_cache-reg_list[ARMV4_5_CPSR].dirty = 1;
-   armv4_5-core_cache-reg_list[ARMV4_5_CPSR].valid = 1;
+   buf_set_u32(armv4_5-cpsr-value, 0, 8, 0xd3);
+   armv4_5-cpsr-dirty = 1;
+   armv4_5-cpsr-valid = 1;
 
/* start fetching from 0x0 */
buf_set_u32(armv4_5-core_cache-reg_list[15].value, 0, 32, 0x0);
@@ -1401,9 +1401,9 @@ static int arm7_9_debug_entry(struct tar
if (armv4_5-core_state == ARMV4_5_STATE_THUMB)
cpsr |= 0x20;
 
-   buf_set_u32(armv4_5-core_cache-reg_list[ARMV4_5_CPSR].value, 0, 32, 
cpsr);
-   armv4_5-core_cache-reg_list[ARMV4_5_CPSR].dirty = 0;
-   armv4_5-core_cache-reg_list[ARMV4_5_CPSR].valid = 1;
+   buf_set_u32(armv4_5-cpsr-value, 0, 32, cpsr);
+   armv4_5-cpsr-dirty = 0;
+   armv4_5-cpsr-valid = 1;
 
armv4_5-core_mode = cpsr  0x1f;
 
@@ -1520,7 +1520,8 @@ int arm7_9_full_context(struct target *t
uint32_t tmp_cpsr;
 
/* change processor mode (and mask T bit) */
-   tmp_cpsr = 
buf_get_u32(armv4_5-core_cache-reg_list[ARMV4_5_CPSR].value, 0, 8)  0xE0;
+   tmp_cpsr = buf_get_u32(armv4_5-cpsr-value, 0, 8)
+0xe0;
tmp_cpsr |= armv4_5_number_to_mode(i);
tmp_cpsr = ~0x20;
arm7_9-write_xpsr_im8(target, tmp_cpsr  0xff, 0, 0);
@@ -1551,7 +1552,9 @@ int arm7_9_full_context(struct target *t
}
 
/* restore processor mode (mask T bit) */
-   arm7_9-write_xpsr_im8(target, 
buf_get_u32(armv4_5-core_cache-reg_list[ARMV4_5_CPSR].value, 0, 8)  ~0x20, 
0, 0);
+   arm7_9-write_xpsr_im8(target,
+   buf_get_u32(armv4_5-cpsr-value, 0, 8)  ~0x20,
+   0, 0);
 
if ((retval = jtag_execute_queue()) != ERROR_OK)
{
@@ -1645,7 +1648,8 @@ int arm7_9_restore_context(struct target
uint32_t tmp_cpsr;
 
/* change processor mode (mask T bit) */
-   tmp_cpsr = 
buf_get_u32(armv4_5-core_cache-reg_list[ARMV4_5_CPSR].value, 0, 8)  0xE0;
+   tmp_cpsr = buf_get_u32(armv4_5-cpsr-value,
+

Re: [Openocd-development] STM32: flash write_image has an alignment issue and flash protect/erase is broken

2009-11-21 Thread Øyvind Harboe

On Thu, Nov 19, 2009 at 11:46 PM, Johnny Halfmoon
jhalfm...@milksnot.com wrote:
 Hiya,

 I've found a few issues in OpenOCD and thought that I'd share before hacking 
 a solution together. The following revision is used:

 commit 8f446fcf676e9cd13cf53d9946f0cae5d29a10ec
 Date:   Thu Nov 19 13:23:49 2009 -0800

 When doing flash write_image erase unlock image.bin 0x800 bin on an 
 STM32, the following error is generated:

 auto erase enabled
 auto unlock enabled
 Info : device id = 0x20036410
 Info : flash size = 128kbytes
 Warn : Error: start and end sectors must be on a 4 sector boundary
 Error: failed setting protection for areas 0 to 21 (-901)

 So it seems we need write_image to be a bit smarter and do some boundary
 aligning before doing the unprotect / erase.

Could you include a debug_level 3 trace?

The conclusion seems a bit premature based on the limited information
above.


-- 
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 04/12] at91rm9200: use register_commands()

2009-11-21 Thread David Brownell

On Saturday 21 November 2009, Zachary T Welch wrote:
 +static const struct command_registration at91rm9200_command_handlers[] = {
 +   {
 +   .name = at91rm9200_device,
 +   .handler = at91rm9200_handle_device_command,
 +   .mode = COMMAND_CONFIG,
 +   .help = query armjtagew info,
 +   },
 +   };

Could we get one less level of indent throughout?
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 3/3] support for scripts in $HOME/.openocd

2009-11-21 Thread Andreas Fritiofson

On Sat, Nov 21, 2009 at 9:31 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
 On Sat, Nov 21, 2009 at 7:14 PM, Zach Welch z...@superlucidity.net wrote:

 PATH_MAX should be defined and available (in limits.h).  Use it.

 Why not just allocate dynamically and avoid the problem at the root?


That sounds like the best solution, I'll prepare an updated patch.

Ehm... The question is... how do i do it?? This was more or less my
first git experience and I found it rather easy to develop and commit
this on a separate branch, prepare the patch series with
git-format-patch and even send it with git-send-email. But when
there's feedback on one of the patches, like in this case, how do I
revise that patch and send an updated version? I find myself in the
dark here... I've read some tutorials, but most speak in rather
general terms. This ought to be a very common scenario. Step-by-step
guide, anyone?

/Andreas
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 04/12] at91rm9200: use register_commands()

2009-11-21 Thread Zach Welch

On Sat, 2009-11-21 at 16:24 -0700, David Brownell wrote:
 On Saturday 21 November 2009, Zachary T Welch wrote:
  +static const struct command_registration at91rm9200_command_handlers[] = {
  +   {
  +   .name = at91rm9200_device,
  +   .handler = at91rm9200_handle_device_command,
  +   .mode = COMMAND_CONFIG,
  +   .help = query armjtagew info,
  +   },
  +   };
 
 Could we get one less level of indent throughout?

There a couple of arguments for using this style at the top-level:
- It's consistent with the other indenting.  The statement has not been
completed, so the code should not return to the original tab-stop.
- It generally fits fine with cols=80, even at tab=8.  I still use tab=4
as the final rule, where one level is barely noticeable.

It would be painful to retouch all of these for this issue alone, but I
suppose that I should have expected you to raise this particular point.

Cheers,

Zach
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 3/3] support for scripts in $HOME/.openocd

2009-11-21 Thread Zach Welch

On Sun, 2009-11-22 at 00:52 +0100, Andreas Fritiofson wrote:
 On Sat, Nov 21, 2009 at 9:31 PM, Øyvind Harboe oyvind.har...@zylin.com 
 wrote:
  On Sat, Nov 21, 2009 at 7:14 PM, Zach Welch z...@superlucidity.net wrote:
 
  PATH_MAX should be defined and available (in limits.h).  Use it.
 
  Why not just allocate dynamically and avoid the problem at the root?
 
 
 That sounds like the best solution, I'll prepare an updated patch.
 
 Ehm... The question is... how do i do it?? This was more or less my
 first git experience and I found it rather easy to develop and commit
 this on a separate branch, prepare the patch series with
 git-format-patch and even send it with git-send-email. But when
 there's feedback on one of the patches, like in this case, how do I
 revise that patch and send an updated version? I find myself in the
 dark here... I've read some tutorials, but most speak in rather
 general terms. This ought to be a very common scenario. Step-by-step
 guide, anyone?
 
 /Andreas

Checkout your branch and run 'git rebase master'.  That will update your
branch against the current master.  Then, do the same thing with '-i'.
Select the patches to change and mark them with 'e', change the files,
add them and --amend the comment, then --continue the rebase. Rinse and
repeat for all marked files.  

--Z

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 04/12] at91rm9200: use register_commands()

2009-11-21 Thread David Brownell

On Saturday 21 November 2009, Zach Welch wrote:
 
  Could we get one less level of indent throughout?
 
 There a couple of arguments for using this style at the top-level:
 - It's consistent with the other indenting.  The statement has not been
 completed, so the code should not return to the original tab-stop.

It's *NOT* consistent, since the first level of indent is
double-sized.

Though ... I'm also used to having *no* indent for new
members of array structs; it's not as if there's any more
structure to highlight.  Which is why having *TWO* indents
is particularly annoying... even one is superfluous.

I'd not object to *two* less levels of intent.  But at
the least, be consistent about not *starting* indents
with a double serving.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] STM32: flash write_image has an alignment issue and flash protect/erase is broken

2009-11-21 Thread Johnny Halfmoon


Hi,

Øyvind Harboe wrote:
 
 Could you include a debug_level 3 trace?
 
 The conclusion seems a bit premature based on the limited information
 above.
 
 

Maybe the following example (output is pasted below) can illustrate the issue a 
bit better. First I try to flash a 20KB block, then a 21KB block and finally a 
24KB block. Only the blocks of 20 and 24 succeed, because they happen to be 
nicely 4K alligned. All blocks that are not 4K alligned will fail. OpenOCD 
tries to erase, (un)protect and flash only those sectors that are modified, but 
doesn't take into account that some platforms require certain alligments. Debug 
level 3 yields nothing interresting:

User : 209 1107 command.c:608 jim_echo(): ---Flashing---
Debug: 211 1110 command.c:64 script_debug(): command - write_image
Debug: 212 1110 command.c:74 script_debug(): write_image - 
argv[0]=ocd_flash_write_image
Debug: 213 1110 command.c:74 script_debug(): write_image - argv[1]=erase
Debug: 214 1110 command.c:74 script_debug(): write_image - argv[2]=unlock
Debug: 215 1110 command.c:74 script_debug(): write_image - 
argv[3]=out/monster_flash.bin
Debug: 216 1110 command.c:74 script_debug(): write_image - argv[4]=0x800
Debug: 217 1110 command.c:74 script_debug(): write_image - argv[5]=bin
User : 218 1110 command.c:405 command_print(): auto erase enabled
User : 219 1110 command.c:405 command_print(): auto unlock enabled
Debug: 220 1123 configuration.c:83 find_file(): found out/monster_flash.bin
Debug: 221 1126 target.c:1516 target_read_u32(): address: 0xe0042000, value: 
0x20036410
Info : 222 1126 stm32x.c:677 stm32x_probe(): device id = 0x20036410
Debug: 223 1128 target.c:1544 target_read_u16(): address: 0x17e0, value: 
0x0080
Info : 224 1128 stm32x.c:752 stm32x_probe(): flash size = 128kbytes
Warn : 225 1129 stm32x.c:366 stm32x_protect(): Error: start and end sectors 
must be on a 4 sector boundary
Error: 226 1129 flash.c:117 flash_driver_protect(): failed setting protection 
for areas 0 to 20 (-901)
Debug: 227 1129 command.c:472 run_command(): Command failed with error code -901
User : 228 1129 command.c:675 openocd_jim_vfprintf(): 
User : 231 1129 command.c:675 openocd_jim_vfprintf(): 
User : 233 1129 command.c:675 openocd_jim_vfprintf(): 
User : 235 1129 command.c:675 openocd_jim_vfprintf(): 
User : 237 1129 command.c:675 openocd_jim_vfprintf(): 
User : 239 1129 command.c:675 openocd_jim_vfprintf(): 
User : 241 1129 command.c:675 openocd_jim_vfprintf(): 
make: *** [flash] Error 1

Here's the output of the examples I mentioned:

bla /1/arm/workspace/monster $ dd if=/dev/zero of=out/monster_flash.bin bs=1024 
count=20
20+0 records in
20+0 records out
20480 bytes (20 kB) copied, 0.00668803 s, 3.1 MB/s
bla /1/arm/workspace/monster $ rm flash -f ;make flash
---Flashing---  

   auto erase enabled
auto unlock enabled
Info : device id = 0x20036410
Info : flash size = 128kbytes
wrote 20480 byte from file out/monster_flash.bin in 2.049710s (9.757 kb/s)
---Done---

bla /1/arm/workspace/monster $ dd if=/dev/zero of=out/monster_flash.bin bs=1024 
count=21
   
21+0 records in
21+0 records out
21504 bytes (22 kB) copied, 0.00829303 s, 2.6 MB/s
bla /1/arm/workspace/monster $ rm flash -f ;make flash
---Flashing---
auto erase enabled
auto unlock enabled
Info : device id = 0x20036410
Info : flash size = 128kbytes
Warn : Error: start and end sectors must be on a 4 sector boundary
Error: failed setting protection for areas 0 to 20 (-901)
make: *** [flash] Error 1

bla /1/arm/workspace/monster $ dd if=/dev/zero of=out/monster_flash.bin bs=1024 
count=24
24+0 records in
24+0 records out
24576 bytes (25 kB) copied, 0.00896715 s, 2.7 MB/s
bla /1/arm/workspace/monster $ rm flash -f ;make flash
---Flashing---
auto erase enabled
auto unlock enabled
Info : device id = 0x20036410
Info : flash size = 128kbytes
wrote 24576 byte from file out/monster_flash.bin in 2.299153s (10.439 kb/s)
---Done---

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 3/3] support for scripts in $HOME/.openocd

2009-11-21 Thread Andreas Fritiofson

On Sun, Nov 22, 2009 at 1:13 AM, Zach Welch z...@superlucidity.net wrote:
 Checkout your branch and run 'git rebase master'.  That will update your
 branch against the current master.  Then, do the same thing with '-i'.
 Select the patches to change and mark them with 'e', change the files,
 add them and --amend the comment, then --continue the rebase. Rinse and
 repeat for all marked files.

Great, that was easy, thanks! Here's an updated patch, this time using
C99 variable length arrays. I'm using the unbounded string functions
here, guessing we can trust getenv() to return a piece of memory that
won't change on the fly.

Btw, is it suitable to attach an updated patch as an attachment like
this? I thought git-send-email was fancy, but I hardly think it can
figure out to send the new patch as a reply in the old thread?

/Andreas
From 4fb41a4855e58448070f5d4e3434878aa1c8c72f Mon Sep 17 00:00:00 2001
From: Andreas Fritiofson andreas.fritiof...@gmail.com
Date: Thu, 19 Nov 2009 23:58:15 +0100
Subject: [PATCH 2/2] support for scripts in $HOME/.openocd

Add $HOME/.openocd as the first default script search directory, allowing
the user to override the standard scripts.

Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com
---
 src/helper/options.c |   13 -
 1 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/src/helper/options.c b/src/helper/options.c
index 5792e11..84e391b 100644
--- a/src/helper/options.c
+++ b/src/helper/options.c
@@ -101,7 +101,18 @@ static void add_default_dirs(void)
 	 * listed last in the built-in search order, so the user can
 	 * override these scripts with site-specific customizations.
 	 */
-	/// @todo Implement @c add_script_search_dir(${HOME}/.openocd).
+
+	const char *home = getenv(HOME);
+	const char *suffix = /.openocd;
+
+	if (home) {
+		char path[strlen(home) + strlen(suffix) + 1];
+
+		strcpy(path, home);
+		strcat(path, suffix);
+		add_script_search_dir(path);
+	}
+
 	add_script_search_dir(PKGDATADIR /site);
 	add_script_search_dir(PKGDATADIR /scripts);
 #endif
-- 
1.6.3.3

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 3/3] support for scripts in $HOME/.openocd

2009-11-21 Thread Zach Welch

On Sun, 2009-11-22 at 01:56 +0100, Andreas Fritiofson wrote:
 On Sun, Nov 22, 2009 at 1:13 AM, Zach Welch z...@superlucidity.net wrote:
  Checkout your branch and run 'git rebase master'.  That will update your
  branch against the current master.  Then, do the same thing with '-i'.
  Select the patches to change and mark them with 'e', change the files,
  add them and --amend the comment, then --continue the rebase. Rinse and
  repeat for all marked files.
 
 Great, that was easy, thanks! Here's an updated patch, this time using
 C99 variable length arrays. I'm using the unbounded string functions
 here, guessing we can trust getenv() to return a piece of memory that
 won't change on the fly.

Tuck the 'suffix' variable into the scope of the 'if' block.

Documentation?  :)  That can be part of the same patch.

 Btw, is it suitable to attach an updated patch as an attachment like
 this? I thought git-send-email was fancy, but I hardly think it can
 figure out to send the new patch as a reply in the old thread?

When I run it, it asks me for the message-id to which it should reply.

Also, I prefer to see patches in-line (not as attachments), as it's much
easier to review them then save a series to import with 'git am'.

--Z
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH 2/2] support for scripts in $HOME/.openocd

2009-11-21 Thread Andreas Fritiofson

Add $HOME/.openocd as the first default script search directory, allowing
the user to override the standard scripts.

Update the user guide with information on where OpenOCD expects to find
configuration files and scripts. Also fixed some minor formatting issues.

Add entry to NEWS as well.

Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com
---
 NEWS |1 +
 doc/openocd.texi |   22 ++
 src/helper/options.c |   13 -
 3 files changed, 27 insertions(+), 9 deletions(-)

diff --git a/NEWS b/NEWS
index 1a024e4..0dcc4bc 100644
--- a/NEWS
+++ b/NEWS
@@ -19,6 +19,7 @@ Flash Layer:
 Board, Target, and Interface Configuration Scripts:
ARM9
- ETM and ETB hookup for iMX2* targets
+   Add $HOME/.openocd to the search path.
 
 Documentation:
 Build and Release:
diff --git a/doc/openocd.texi b/doc/openocd.texi
index 9659e92..f895cc3 100644
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -483,14 +483,24 @@ bash$ openocd --help
 --pipe   | -p   use pipes when talking to gdb
 @end verbatim
 
-By default OpenOCD reads the file configuration file @file{openocd.cfg}
-in the current directory.  To specify a different (or multiple)
-configuration file, you can use the ``-f'' option. For example:
+By default OpenOCD reads the configuration file @file{openocd.cfg}.
+To specify a different (or multiple)
+configuration file, you can use the @option{-f} option. For example:
 
 @example
 openocd -f config1.cfg -f config2.cfg -f config3.cfg
 @end example
 
+Configuration files and scripts are searched for in
+...@enumerate
+...@item the current directory,
+...@item any search dir specified on the command line using the @option{-s} 
option,
+...@item @file{$HOME/.openocd} (not on Windows),
+...@item the site wide script library @file{$pkgdatadir/site} and
+...@item the OpenOCD-supplied script library @file{$pkgdatadir/scripts}.
+...@end enumerate
+The first found file with a matching file name will be used.
+
 OpenOCD starts by processing the configuration commands provided
 on the command line or in @file{openocd.cfg}.
 @xref{Configuration Stage}.
@@ -507,7 +517,7 @@ clients (Telnet, GDB, Other) and processes the commands 
issued through
 those channels.
 
 If you are having problems, you can enable internal debug messages via
-the ``-d'' option.
+the @option{-d} option.
 
 Also it is possible to interleave JIM-Tcl commands w/config scripts using the
 @option{-c} command line switch.
@@ -523,10 +533,6 @@ setting from within a telnet or gdb session using 
@command{debug_level
 You can redirect all output from the daemon to a file using the
 @option{-l logfile} switch.
 
-Search paths for config/script files can be added to OpenOCD by using
-the @option{-s search} switch. The current directory and the OpenOCD
-target library is in the search path by default.
-
 For details on the @option{-p} option. @xref{Connecting to GDB}.
 
 Note! OpenOCD will launch the GDB  telnet server even if it can not
diff --git a/src/helper/options.c b/src/helper/options.c
index 5792e11..438fb94 100644
--- a/src/helper/options.c
+++ b/src/helper/options.c
@@ -101,7 +101,18 @@ static void add_default_dirs(void)
 * listed last in the built-in search order, so the user can
 * override these scripts with site-specific customizations.
 */
-   /// @todo Implement @c add_script_search_dir(${HOME}/.openocd).
+
+   const char *home = getenv(HOME);
+
+   if (home) {
+   const char *suffix = /.openocd;
+   char path[strlen(home) + strlen(suffix) + 1];
+
+   strcpy(path, home);
+   strcat(path, suffix);
+   add_script_search_dir(path);
+   }
+
add_script_search_dir(PKGDATADIR /site);
add_script_search_dir(PKGDATADIR /scripts);
 #endif
-- 
1.6.3.3

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

49 matches

Mail list logo