Re: [Openocd-development] [PATCH] arm: dcc_downloads and fast_memory_access are now enabled by default

2009-12-01 Thread Zach Welch
On Tue, 2009-12-01 at 08:52 +0100, Øyvind Harboe wrote: How about a warning when it's _not_ explicitly enabled or disabled by the user? Specifically, tell the users to try enabling those features or to add explicit commands to stop the warnings. Scripts for boards where that feature will

Re: [Openocd-development] [PATCH 1/3] command: the Jim interpreter can now be provided rather than created

2009-12-01 Thread Zach Welch
Only one minor suggested improvement, below. Otherwise, these both look okay to me. On Tue, 2009-12-01 at 08:48 +0100, Øyvind Harboe wrote: In embedded hosts, the Jim interpreter can come from the existing context rather than be created by OpenOCD. Signed-off-by: Øyvind Harboe

Re: [Openocd-development] [PATCH 1/3] command: the Jim interpreter can now be provided rather than created

2009-12-01 Thread Øyvind Harboe
 #if !BUILD_ECOSBOARD It is now safe to kill this #if logic too.  It's like a bonus prize. ;) Almost, but not quite. I tried before I remembered that Jim is embedded into the athttpd server... You know the slightly messy and awkward jump tables that Jim uses... I'll push the two patches

Re: [Openocd-development] [PATCH] arm: dcc_downloads and fast_memory_access are now enabled by default

2009-12-01 Thread Øyvind Harboe
On Tue, Dec 1, 2009 at 9:03 AM, Zach Welch z...@superlucidity.net wrote: On Tue, 2009-12-01 at 08:52 +0100, Øyvind Harboe wrote: How about a warning when it's _not_ explicitly enabled or disabled by the user?  Specifically, tell the users to try enabling those features or to add explicit

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-12-01 Thread Michael Schwingen
Zach Welch wrote: On Mon, 2009-11-30 at 14:42 -0800, David Brownell wrote: On Monday 30 November 2009, Zachary T Welch wrote: Registers a signal handler to catch SIGSEGV in order to display the stack where the program crashed. Is this for inside OpenOCD? If so, I'd rather

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-12-01 Thread Øyvind Harboe
Hm - I'm with David here: I am not very fond of re-inventing parts of gdb to include it in OpenOCD. Fully implementing this would make OpenOCD depend on libbfd just for crash reports - this is ridiculous. If something like this was added, it should not create any dependencies or do anything

Re: [Openocd-development] [PATCH 1/3] command: the Jim interpreter can now be provided rather than created

2009-12-01 Thread Zach Welch
On Tue, 2009-12-01 at 09:17 +0100, Øyvind Harboe wrote: #if !BUILD_ECOSBOARD It is now safe to kill this #if logic too. It's like a bonus prize. ;) Almost, but not quite. I tried before I remembered that Jim is embedded into the athttpd server... You know the slightly messy and

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-12-01 Thread Zach Welch
On Tue, 2009-12-01 at 09:37 +0100, Michael Schwingen wrote: Zach Welch wrote: On Mon, 2009-11-30 at 14:42 -0800, David Brownell wrote: On Monday 30 November 2009, Zachary T Welch wrote: Registers a signal handler to catch SIGSEGV in order to display the stack where the program

Re: [Openocd-development] [PATCH 1/3] command: the Jim interpreter can now be provided rather than created

2009-12-01 Thread Øyvind Harboe
The patch to ecosboard.c always gives a non-NULL value, and we always pass in NULL from openocd.c.  The #if is entirely redundant when you take a moment to look at the big picture. Except it doesn't build, it's that messy bit with difference build modes for Jim. I'm kinda hopeful that the #if

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-12-01 Thread Zach Welch
On Tue, 2009-12-01 at 09:45 +0100, Øyvind Harboe wrote: Hm - I'm with David here: I am not very fond of re-inventing parts of gdb to include it in OpenOCD. Fully implementing this would make OpenOCD depend on libbfd just for crash reports - this is ridiculous. If something like this

Re: [Openocd-development] [PATCH 1/3] command: the Jim interpreter can now be provided rather than created

2009-12-01 Thread Zach Welch
On Tue, 2009-12-01 at 10:16 +0100, Øyvind Harboe wrote: The patch to ecosboard.c always gives a non-NULL value, and we always pass in NULL from openocd.c. The #if is entirely redundant when you take a moment to look at the big picture. Except it doesn't build, it's that messy bit with

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-12-01 Thread David Brownell
Registers a signal handler to catch SIGSEGV in order to display the stack where the program crashed. Is this for inside OpenOCD? If so, I'd rather just expect folk to run inside GDB. Either they're running natively and should never see SEGV ... or they should be able to fire up

Re: [Openocd-development] [PATCH 1/3] command: the Jim interpreter can now be provided rather than created

2009-12-01 Thread Øyvind Harboe
On Tue, Dec 1, 2009 at 10:19 AM, Zach Welch z...@superlucidity.net wrote: On Tue, 2009-12-01 at 10:16 +0100, Øyvind Harboe wrote: The patch to ecosboard.c always gives a non-NULL value, and we always pass in NULL from openocd.c.  The #if is entirely redundant when you take a moment to look

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-12-01 Thread Øyvind Harboe
On Tue, Dec 1, 2009 at 10:17 AM, Zach Welch z...@superlucidity.net wrote: On Tue, 2009-12-01 at 09:45 +0100, Øyvind Harboe wrote: Hm - I'm with David here: I am not very fond of re-inventing parts of gdb to include it in OpenOCD. Fully implementing this would make OpenOCD depend on libbfd

Re: [Openocd-development] [PATCH] arm: dcc_downloads and fast_memory_access are now enabled by default

2009-12-01 Thread Zach Welch
On Tue, 2009-12-01 at 09:18 +0100, Øyvind Harboe wrote: On Tue, Dec 1, 2009 at 9:03 AM, Zach Welch z...@superlucidity.net wrote: On Tue, 2009-12-01 at 08:52 +0100, Øyvind Harboe wrote: How about a warning when it's _not_ explicitly enabled or disabled by the user? Specifically, tell the

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-12-01 Thread David Brownell
On Tuesday 01 December 2009, Øyvind Harboe wrote: How about adding an option to statically link with GDB or create a script that launched OpenOCD via GDB as default? I have shell scripts that start up OpenOCD and points it at a particular board. The src/openocd invocation is usually preceded

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-12-01 Thread Øyvind Harboe
2009/12/1 David Brownell davi...@pacbell.net: On Tuesday 01 December 2009, Ųyvind Harboe wrote: How about adding an option to statically link with GDB or create a script that launched OpenOCD via GDB as default? I have shell scripts that start up OpenOCD and points it at a particular board.

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-12-01 Thread Zach Welch
On Tue, 2009-12-01 at 01:23 -0800, David Brownell wrote: Registers a signal handler to catch SIGSEGV in order to display the stack where the program crashed. Is this for inside OpenOCD? If so, I'd rather just expect folk to run inside GDB. Either they're running natively and

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-12-01 Thread Zach Welch
On Tue, 2009-12-01 at 10:25 +0100, Øyvind Harboe wrote: On Tue, Dec 1, 2009 at 10:17 AM, Zach Welch z...@superlucidity.net wrote: On Tue, 2009-12-01 at 09:45 +0100, Øyvind Harboe wrote: Hm - I'm with David here: I am not very fond of re-inventing parts of gdb to include it in OpenOCD.

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-12-01 Thread Øyvind Harboe
No one was talking about linking with GDB.  That's just insane. ;) libbfd is part of binutils.  But again it should be_optional. OK. Explain the benefit of complicating OpenOCD vs. adding a script to launch OpenOCD via GDB then... Seriously... you've never had a Heisenbug either?  Am I

Re: [Openocd-development] [PATCH 1/3] command: the Jim interpreter can now be provided rather than created

2009-12-01 Thread Zach Welch
On Tue, 2009-12-01 at 10:24 +0100, Øyvind Harboe wrote: On Tue, Dec 1, 2009 at 10:19 AM, Zach Welch z...@superlucidity.net wrote: On Tue, 2009-12-01 at 10:16 +0100, Øyvind Harboe wrote: The patch to ecosboard.c always gives a non-NULL value, and we always pass in NULL from openocd.c. The

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-12-01 Thread David Brownell
On Tuesday 01 December 2009, Øyvind Harboe wrote: The src/openocd invocation is usually preceded by a comment        # gdb --args \ this script does not work when some of the args have a space in them, but yes, a script pretty much like that one. :-) The args get quoted. GDB

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-12-01 Thread David Brownell
On Tuesday 01 December 2009, Zach Welch wrote: On Tue, 2009-12-01 at 01:23 -0800, David Brownell wrote: Registers a signal handler to catch SIGSEGV in order to display the stack where the program crashed. Is this for inside OpenOCD? If so, I'd rather just expect folk to

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-12-01 Thread Zach Welch
On Tue, 2009-12-01 at 01:52 -0800, David Brownell wrote: On Tuesday 01 December 2009, Zach Welch wrote: On Tue, 2009-12-01 at 01:23 -0800, David Brownell wrote: Registers a signal handler to catch SIGSEGV in order to display the stack where the program crashed. Is this

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-12-01 Thread Zach Welch
On Tue, 2009-12-01 at 10:36 +0100, Øyvind Harboe wrote: No one was talking about linking with GDB. That's just insane. ;) libbfd is part of binutils. But again it should be_optional. OK. Explain the benefit of complicating OpenOCD vs. adding a script to launch OpenOCD via GDB then...

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-12-01 Thread Øyvind Harboe
On Tue, Dec 1, 2009 at 11:02 AM, Zach Welch z...@superlucidity.net wrote: On Tue, 2009-12-01 at 10:36 +0100, Øyvind Harboe wrote: No one was talking about linking with GDB.  That's just insane. ;) libbfd is part of binutils.  But again it should be_optional. OK. Explain the benefit of

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-12-01 Thread Zach Welch
On Tue, 2009-12-01 at 11:06 +0100, Øyvind Harboe wrote: On Tue, Dec 1, 2009 at 11:02 AM, Zach Welch z...@superlucidity.net wrote: On Tue, 2009-12-01 at 10:36 +0100, Øyvind Harboe wrote: No one was talking about linking with GDB. That's just insane. ;) libbfd is part of binutils. But

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-12-01 Thread Øyvind Harboe
Again, you have missed the point.  This is about users and our releases. I cannot make that point more clearly.  It is not about developers who are willing to use GDB.  It's about users who aren't. I haven't done the statistics, but are we not seing SEGFAULT's in development builds mostly?

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-12-01 Thread Michael Schwingen
Zach Welch wrote: Hm - I'm with David here: I am not very fond of re-inventing parts of gdb to include it in OpenOCD. Fully implementing this would make OpenOCD depend on libbfd just for crash reports - this is ridiculous. You clearly missed the part where I say it will be

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-12-01 Thread Zach Welch
On Tue, 2009-12-01 at 11:14 +0100, Øyvind Harboe wrote: Again, you have missed the point. This is about users and our releases. I cannot make that point more clearly. It is not about developers who are willing to use GDB. It's about users who aren't. I haven't done the statistics, but

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-12-01 Thread Zach Welch
On Tue, 2009-12-01 at 11:27 +0100, Michael Schwingen wrote: Zach Welch wrote: Hm - I'm with David here: I am not very fond of re-inventing parts of gdb to include it in OpenOCD. Fully implementing this would make OpenOCD depend on libbfd just for crash reports - this is ridiculous.

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-12-01 Thread Michael Schwingen
Zach Welch wrote: To be fair, these extra steps also moot my Heisenbug argument; however, these are still activities that could be expected by these platforms' users. Running GDB is not a user activity, except _possibly_ when using it _with_ OpenOCD. Remember, not everyone uses OpenOCD with

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-12-01 Thread Øyvind Harboe
On Tue, Dec 1, 2009 at 1:49 PM, Michael Schwingen rincew...@discworld.dascon.de wrote: Zach Welch wrote: To be fair, these extra steps also moot my Heisenbug argument; however, these are still activities that could be expected by these platforms' users.  Running GDB is not a user activity,

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-12-01 Thread David Brownell
On Tuesday 01 December 2009, Øyvind Harboe wrote: Zach made a good point that there are bug reports we are not receiving today. Those are the ones he's after here I think. I'm sure this project loses more potential bug reports by requiring folk to subscribe to Yet Another Mailing List than we

[Openocd-development] flyswatter and beagleboard

2009-12-01 Thread John Rigby
I'm trying to use OpenOCD with a Flyswatter and a beagleboard and I get this: # openocd -f ./tcl/interface/flyswatter.cfg -f ./tcl/board/ti_beagleboard.cfg Open On-Chip Debugger 0.4.0-dev-00740-ga65e75e (2009-12-01-12:05) For bug reports, read

Re: [Openocd-development] flyswatter and beagleboard

2009-12-01 Thread David Brownell
On Tuesday 01 December 2009, John Rigby wrote: I'm trying to use OpenOCD with a Flyswatter and a beagleboard and I get this: # openocd -f ./tcl/interface/flyswatter.cfg -f ./tcl/board/ti_beagleboard.cfg Open On-Chip Debugger 0.4.0-dev-00740-ga65e75e (2009-12-01-12:05) For bug reports, read

Re: [Openocd-development] flyswatter and beagleboard

2009-12-01 Thread John Rigby
I already tried that: $ telnet localhost Trying ::1... Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Open On-Chip Debugger reset halt RCLK not supported - fallback to 1000 kHz JTAG scan chain interrogation failed: all ones Check JTAG interface, timings, target power,

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-12-01 Thread Andreas Fritiofson
On Tue, Dec 1, 2009 at 10:32 AM, Zach Welch z...@superlucidity.net wrote: On Tue, 2009-12-01 at 10:25 +0100, Øyvind Harboe wrote: On Tue, Dec 1, 2009 at 10:17 AM, Zach Welch z...@superlucidity.net wrote: On Tue, 2009-12-01 at 09:45 +0100, Øyvind Harboe wrote: Hm - I'm with David here: I am

Re: [Openocd-development] flyswatter and beagleboard

2009-12-01 Thread John Rigby
Doh! Working now. I had the beagle board adapter plugged into the beagle instead of the flyswatter. On Tue, Dec 1, 2009 at 1:49 PM, John Rigby jcri...@gmail.com wrote: I already tried that: $ telnet localhost Trying ::1... Trying 127.0.0.1... Connected to localhost. Escape character

[Openocd-development] [PATCH 3/7] mflash: factor init to 'mflash init'

2009-12-01 Thread Zachary T Welch
Splits mflash initialiation to 'mflash init', called from 'init'. Signed-off-by: Zachary T Welch z...@superlucidity.net --- src/flash/mflash.c | 23 +++ src/openocd.c |5 ++--- 2 files changed, 25 insertions(+), 3 deletions(-) diff --git a/src/flash/mflash.c

[Openocd-development] [PATCH 2/7] nand: factor init to 'nand init'

2009-12-01 Thread Zachary T Welch
Split NAND initialization into 'nand init', which gets called from the main 'init' command. Signed-off-by: Zachary T Welch z...@superlucidity.net --- src/flash/nand.c | 26 ++ src/openocd.c|5 ++--- 2 files changed, 28 insertions(+), 3 deletions(-) diff --git

[Openocd-development] [PATCH 4/7] flash: factor init to 'flash init'

2009-12-01 Thread Zachary T Welch
Split flash initialiation into 'flash init', called from 'init'. Signed-off-by: Zachary T Welch z...@superlucidity.net --- src/flash/flash.c | 23 +++ src/openocd.c |5 ++--- 2 files changed, 25 insertions(+), 3 deletions(-) diff --git a/src/flash/flash.c

[Openocd-development] [PATCH 5/7] jtag: factor init into 'jtag init'

2009-12-01 Thread Zachary T Welch
Adds 'jtag init' command handler, which can be called as part of a fine-grained 'init' process. Signed-off-by: Zachary T Welch z...@superlucidity.net --- src/jtag/tcl.c | 23 +++ src/openocd.c | 16 +--- 2 files changed, 32 insertions(+), 7 deletions(-) diff

[Openocd-development] [PATCH 1/7] pld: factor init to 'pld init'

2009-12-01 Thread Zachary T Welch
Split PLD initialization into 'pld init', which gets called from 'init'. Signed-off-by: Zachary T Welch z...@superlucidity.net --- src/openocd.c |5 +++-- src/pld/pld.c | 23 +++ 2 files changed, 26 insertions(+), 2 deletions(-) diff --git a/src/openocd.c

[Openocd-development] [PATCH 0/7] split the 'init' command

2009-12-01 Thread Zachary T Welch
Hi all, This series makes most of the individual steps in 'init' accessible to direct invocation. The changes should allow recovery in cases when OpenOCD is run interactively and (for example) you fail to specify an interface before trying to to run 'init'. These new subcommands help with the

[Openocd-development] [PATCH 6/7] target: factor target_init() into pieces

2009-12-01 Thread Zachary T Welch
Moves body of target initialization loop into a helper function, cleaning up its visual flow in the process. Signed-off-by: Zachary T Welch z...@superlucidity.net --- src/target/target.c | 153 --- 1 files changed, 84 insertions(+), 69

[Openocd-development] [PATCH 7/7] target: factor init to 'target init'

2009-12-01 Thread Zachary T Welch
Adds 'target init' command handler, called as part of 'init'. Signed-off-by: Zachary T Welch z...@superlucidity.net --- src/openocd.c |7 ++- src/target/target.c | 23 +++ 2 files changed, 25 insertions(+), 5 deletions(-) diff --git a/src/openocd.c

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-12-01 Thread Zach Welch
On Tue, 2009-12-01 at 21:57 +0100, Andreas Fritiofson wrote: On Tue, Dec 1, 2009 at 10:32 AM, Zach Welch z...@superlucidity.net wrote: On Tue, 2009-12-01 at 10:25 +0100, Øyvind Harboe wrote: On Tue, Dec 1, 2009 at 10:17 AM, Zach Welch z...@superlucidity.net wrote: On Tue, 2009-12-01 at

[Openocd-development] [PATCH 4/7] add stack_assert for an improved assert macro

2009-12-01 Thread Zachary T Welch
Adds backtraces to all assert messages, so developers receive the context of the problem. After all, finding the problem often requires knowing how the code managed to reach the call that contains the assertion that has failed. Signed-off-by: Zachary T Welch z...@superlucidity.net --- NOTE: The

Re: [Openocd-development] FT4232H support

2009-12-01 Thread Zach Welch
On Mon, 2009-11-30 at 16:38 -0600, Austin, Alex wrote: Hello, I’ve built a JTAG adapter (Very similar to oocdlink-h) using the FT4232H instead of the FT2232H. Due to the lack of ACBUS on the 4232, I’ve routed the reset lines to the same pins on BDBUS. CDBUS and DDBUS both go to serial

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-12-01 Thread Andreas Fritiofson
On Tue, Dec 1, 2009 at 10:23 PM, Zach Welch z...@superlucidity.net wrote: On Tue, 2009-12-01 at 21:57 +0100, Andreas Fritiofson wrote: On Tue, Dec 1, 2009 at 10:32 AM, Zach Welch z...@superlucidity.net wrote: On Tue, 2009-12-01 at 10:25 +0100, Øyvind Harboe wrote: On Tue, Dec 1, 2009 at

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-12-01 Thread Andreas Fritiofson
On Tue, Dec 1, 2009 at 11:08 PM, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Tue, Dec 1, 2009 at 10:23 PM, Zach Welch z...@superlucidity.net wrote: On Tue, 2009-12-01 at 21:57 +0100, Andreas Fritiofson wrote: On Tue, Dec 1, 2009 at 10:32 AM, Zach Welch z...@superlucidity.net

Re: [Openocd-development] [rfc] improving 'help'... volunteers?

2009-12-01 Thread Zach Welch
On Sat, 2009-11-28 at 15:26 -0800, David Brownell wrote: On Saturday 28 November 2009, Zach Welch wrote: On Sat, 2009-11-28 at 14:07 -0800, David Brownell wrote: On Saturday 28 November 2009, Zach Welch wrote: Next, we should consider updating all help messages to full sentences, so

Re: [Openocd-development] [rfc] improving 'help'... volunteers?

2009-12-01 Thread David Brownell
On Tuesday 01 December 2009, Zach Welch wrote: The use of angle brackets intends to distinguish parameter names from literal arguments.  Thus [foo]  means an optional thing which semantically will be used as a foo, whereas [foo|bar] means you can optionally provide the 'foo' or 'bar'

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-12-01 Thread Zach Welch
On Tue, 2009-12-01 at 23:09 +0100, Andreas Fritiofson wrote: On Tue, Dec 1, 2009 at 11:08 PM, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Tue, Dec 1, 2009 at 10:23 PM, Zach Welch z...@superlucidity.net wrote: On Tue, 2009-12-01 at 21:57 +0100, Andreas Fritiofson wrote: On

Re: [Openocd-development] [rfc] improving 'help'... volunteers?

2009-12-01 Thread Zach Welch
On Tue, 2009-12-01 at 14:28 -0800, David Brownell wrote: On Tuesday 01 December 2009, Zach Welch wrote: The use of angle brackets intends to distinguish parameter names from literal arguments. Thus [foo] means an optional thing which semantically will be used as a foo, whereas

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-12-01 Thread Zach Welch
On Tue, 2009-12-01 at 10:08 -0800, David Brownell wrote: On Tuesday 01 December 2009, Øyvind Harboe wrote: Zach made a good point that there are bug reports we are not receiving today. Those are the ones he's after here I think. I'm sure this project loses more potential bug reports by

Re: [Openocd-development] split flash/* into flash/nor/* and flash/nand/*

2009-12-01 Thread Dean Glazeski
Aargh, darn school! I can't keep up with these patches, but do it! This leaves some room for work I want to do when I have time again :). // Dean Glazeski On Tue, Dec 1, 2009 at 5:30 PM, Zach Welch z...@superlucidity.net wrote: Hi all, I want to clean up our flash directory, moving the

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-12-01 Thread Andreas Fritiofson
On Tue, Dec 1, 2009 at 11:50 PM, Zach Welch z...@superlucidity.net wrote: On Tue, 2009-12-01 at 23:09 +0100, Andreas Fritiofson wrote: On Tue, Dec 1, 2009 at 11:08 PM, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Tue, Dec 1, 2009 at 10:23 PM, Zach Welch z...@superlucidity.net

[Openocd-development] policy vs. mechanism

2009-12-01 Thread Zach Welch
Hi all, Part of my impetus to restructure the command set is to see more separation of policy and mechanism in the code. The JTAG layer shows how this can be done: a tcl.c file contains all of the command handlers, while core.c contains the low-level functions that do the work. It might be

Re: [Openocd-development] split flash/* into flash/nor/* and flash/nand/*

2009-12-01 Thread Zach Welch
Yeah, sorry Dean. I know it impacts you, but -- as I said -- I think that it will be relatively easy to merge your changes after the refactoring. I Want To Believe that Git is that smart. The truth will be out there, waiting for you in your tree when you get back to it. ;) On Tue, 2009-12-01

Re: [Openocd-development] [PATCH 2/4] produce stack traces on segfaults

2009-12-01 Thread Zach Welch
On Wed, 2009-12-02 at 00:56 +0100, Andreas Fritiofson wrote: On Tue, Dec 1, 2009 at 11:50 PM, Zach Welch z...@superlucidity.net wrote: On Tue, 2009-12-01 at 23:09 +0100, Andreas Fritiofson wrote: [snip] I like it, except I think it needs to be disabled in the default case. We will get

Re: [Openocd-development] [PATCH 0/7] split the 'init' command

2009-12-01 Thread Zach Welch
On Tue, 2009-12-01 at 13:01 -0800, Zachary T Welch wrote: Hi all, This series makes most of the individual steps in 'init' accessible to direct invocation. The changes should allow recovery in cases when OpenOCD is run interactively and (for example) you fail to specify an interface before

[Openocd-development] [PATCH 0/3] remove all #if logic from openocd.c

2009-12-01 Thread Zachary T Welch
Hi all, This series removes all #if logic from the src/openocd.c file, making it look much nicer and helping to stablize our ABI in the process. If these look good, I will continue this quest in future series. Cheers, Zach ___ Openocd-development

[Openocd-development] [PATCH 3/3] remove #if BUILD_HTTPD

2009-12-01 Thread Zachary T Welch
Add httpd_stubs.c to provide no-op implementations of httpd_start() and httpd_stop(). Allows these routines to be called unconditionally and ensures the libocdserver ABI remains unchanged regardless of whether this feature was built-in or not. Prints a DEBUG message when the stub implementation

[Openocd-development] [PATCH 1/3] remove #if logic for openocd_sleep_*lude

2009-12-01 Thread Zachary T Welch
Adds server_stubs.c to hold these routines, using automake logic to ensure it gets included under the right conditions. Signed-off-by: Zachary T Welch z...@superlucidity.net --- src/openocd.c | 14 -- src/openocd.h |5 - src/server/Makefile.am|

[Openocd-development] [PATCH 2/3] remove BUILD_IOUTIL symbol

2009-12-01 Thread Zachary T Welch
Add ioutil_stubs.c to provide an empty ioutil_init() routine. Add ioutil.h to prevent applications from needing to declare it. Allows unconditionally calling that function during startup, and the resulting libocdhelper library API is now more stable. Prints a DEBUG message when the stub

Re: [Openocd-development] [PATCH 0/3] remove all #if logic from openocd.c

2009-12-01 Thread David Brownell
On Tuesday 01 December 2009, Zachary T Welch wrote: This series removes all #if logic from the src/openocd.c file, making it look much nicer and helping to stablize our ABI in the process. Yes! ___ Openocd-development mailing list

Re: [Openocd-development] [PATCH 0/3] remove all #if logic from openocd.c

2009-12-01 Thread Zach Welch
On Tue, 2009-12-01 at 20:49 -0800, David Brownell wrote: On Tuesday 01 December 2009, Zachary T Welch wrote: This series removes all #if logic from the src/openocd.c file, making it look much nicer and helping to stablize our ABI in the process. Yes! These patches were easy. I am not yet

Re: [Openocd-development] policy vs. mechanism

2009-12-01 Thread David Brownell
On Tuesday 01 December 2009, Zach Welch wrote: After the command cleanup that I have started, I believe this type of factoring deserves to be pursued in the other modules.  I propose making these changes in the following order:  - svf, xsvf, pld: simple core/tcl separation: */core.c and

[Openocd-development] libopenocd... again

2009-12-01 Thread Zach Welch
Hi all, Assuming a split between policy and mechanism can be addressed, OpenOCD will become much more usable as a proper library. One of the questions that needs resolution is how to install our header files. The answer that we chose for this will determine how much restructuring will be

Re: [Openocd-development] policy vs. mechanism

2009-12-01 Thread Zach Welch
On Tue, 2009-12-01 at 20:57 -0800, David Brownell wrote: On Tuesday 01 December 2009, Zach Welch wrote: After the command cleanup that I have started, I believe this type of factoring deserves to be pursued in the other modules. I propose making these changes in the following order:

[Openocd-development] [patch 2/2] Cortex-A8: basic watchpoint support

2009-12-01 Thread David Brownell
Actually this should handle both breakpoints and watchpoints ... but the DPM framework only handles watchpoints for now. Works on Beagle. --- src/target/cortex_a8.c | 66 +++ 1 file changed, 66 insertions(+) --- a/src/target/cortex_a8.c +++

[Openocd-development] [patch 1/2] ARM: core DPM support for watchpoints

2009-12-01 Thread David Brownell
This is a NOP unless the underlying core exposes two new methods, and neither of the two cores using this (ARM11xx, Cortex-A8) do so yet. This patch only updates those cores so they pass a flag saying whether or not to update breakpoint and watchpoint status before resuming; and removing some

Re: [Openocd-development] [rfc] improving 'help'... volunteers?

2009-12-01 Thread Albert ARIBAUD
David Brownell a écrit : On Tuesday 01 December 2009, Zach Welch wrote: The use of angle brackets intends to distinguish parameter names from literal arguments. Thus [foo] means an optional thing which semantically will be used as a foo, whereas [foo|bar] means you can optionally provide