Hello Fabien,
On Sat, Nov 28, 2009 at 5:13 PM, lementec fabien
wrote:
> Hi,
>
> I have a board using this chip. I lost the nand contents,
> I would like to program it using openocd. I saw the
> functions are not implemented, do you think it is difficult,
> is anyone working on it? Is there any re
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 [] means an optional thing which
semantically will be used as a "foo", whereas [foo|bar] means you can
option
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 now-
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
+++ b/src/tar
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:
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
requi
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
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 n
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
Openocd-development
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 implement
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
---
src/openocd.c | 14 --
src/openocd.h |5 -
src/server/Makefile.am|4
src/server/se
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 i
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 mai
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 b
On Wed, 2009-12-02 at 00:56 +0100, Andreas Fritiofson wrote:
> On Tue, Dec 1, 2009 at 11:50 PM, Zach Welch 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 complaints if OpenOCD
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 at
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 worth
On Tue, Dec 1, 2009 at 11:50 PM, Zach Welch wrote:
> On Tue, 2009-12-01 at 23:09 +0100, Andreas Fritiofson wrote:
>> On Tue, Dec 1, 2009 at 11:08 PM, Andreas Fritiofson
>> wrote:
>> > On Tue, Dec 1, 2009 at 10:23 PM, Zach Welch wrote:
>> >> On Tue, 2009-12-01 at 21:57 +0100, Andreas Fritiofson w
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 wrote:
> Hi all,
>
> I want to clean up our flash directory, moving the files into
> subdirect
Hi all,
I want to clean up our flash directory, moving the files into
subdirectories and simplifying the nand filenames. This paves the way
for future types of flash technologies, drivers for which seem like they
could be imminent. It simplifies another proposal of mine appreciably,
so I want to
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
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 [] means an optional thing which
> > > > semantically will be used as a "foo
On Tue, 2009-12-01 at 23:09 +0100, Andreas Fritiofson wrote:
> On Tue, Dec 1, 2009 at 11:08 PM, Andreas Fritiofson
> wrote:
> > On Tue, Dec 1, 2009 at 10:23 PM, Zach Welch wrote:
> >> On Tue, 2009-12-01 at 21:57 +0100, Andreas Fritiofson wrote:
> >>> On Tue, Dec 1, 2009 at 10:32 AM, Zach Welch
On Tuesday 01 December 2009, Zach Welch wrote:
>
> > > The use of angle brackets intends to distinguish parameter names from
> > > literal arguments. Thus [] means an optional thing which
> > > semantically will be used as a "foo", whereas [foo|bar] means you can
> > > optionally provide the 'fo
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
On Tue, Dec 1, 2009 at 11:08 PM, Andreas Fritiofson
wrote:
> On Tue, Dec 1, 2009 at 10:23 PM, Zach Welch wrote:
>> On Tue, 2009-12-01 at 21:57 +0100, Andreas Fritiofson wrote:
>>> On Tue, Dec 1, 2009 at 10:32 AM, Zach Welch wrote:
>>> > On Tue, 2009-12-01 at 10:25 +0100, Øyvind Harboe wrote:
>>>
On Tue, Dec 1, 2009 at 10:23 PM, Zach Welch wrote:
> On Tue, 2009-12-01 at 21:57 +0100, Andreas Fritiofson wrote:
>> On Tue, Dec 1, 2009 at 10:32 AM, Zach Welch wrote:
>> > On Tue, 2009-12-01 at 10:25 +0100, Øyvind Harboe wrote:
>> >> On Tue, Dec 1, 2009 at 10:17 AM, Zach Welch
>> >> wrote:
>>
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
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
---
NOTE: The complete series is avai
On Tue, 2009-12-01 at 21:57 +0100, Andreas Fritiofson wrote:
> On Tue, Dec 1, 2009 at 10:32 AM, Zach Welch wrote:
> > On Tue, 2009-12-01 at 10:25 +0100, Øyvind Harboe wrote:
> >> On Tue, Dec 1, 2009 at 10:17 AM, Zach Welch wrote:
> >> > On Tue, 2009-12-01 at 09:45 +0100, Øyvind Harboe wrote:
> >>
Adds 'target init' command handler, called as part of 'init'.
Signed-off-by: Zachary T Welch
---
src/openocd.c |7 ++-
src/target/target.c | 23 +++
2 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/src/openocd.c b/src/openocd.c
index 79a30e7..12
Moves body of target initialization loop into a helper function,
cleaning up its visual flow in the process.
Signed-off-by: Zachary T Welch
---
src/target/target.c | 153 ---
1 files changed, 84 insertions(+), 69 deletions(-)
diff --git a/src/tar
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 tr
Split PLD initialization into 'pld init', which gets called from 'init'.
Signed-off-by: Zachary T Welch
---
src/openocd.c |5 +++--
src/pld/pld.c | 23 +++
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/src/openocd.c b/src/openocd.c
index 44e0292..777e6
Adds 'jtag init' command handler, which can be called as part of a
fine-grained 'init' process.
Signed-off-by: Zachary T Welch
---
src/jtag/tcl.c | 23 +++
src/openocd.c | 16 +---
2 files changed, 32 insertions(+), 7 deletions(-)
diff --git a/src/jtag/tcl.c
Split flash initialiation into 'flash init', called from 'init'.
Signed-off-by: Zachary T Welch
---
src/flash/flash.c | 23 +++
src/openocd.c |5 ++---
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/src/flash/flash.c b/src/flash/flash.c
index 7023ef
Split NAND initialization into 'nand init', which gets called from
the main 'init' command.
Signed-off-by: Zachary T Welch
---
src/flash/nand.c | 26 ++
src/openocd.c|5 ++---
2 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/src/flash/nand.c b/src
Splits mflash initialiation to 'mflash init', called from 'init'.
Signed-off-by: Zachary T Welch
---
src/flash/mflash.c | 23 +++
src/openocd.c |5 ++---
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/src/flash/mflash.c b/src/flash/mflash.c
index 0
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 wrote:
> I already tried that:
>
> $ telnet localhost
> Trying ::1...
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
>
On Tue, Dec 1, 2009 at 10:32 AM, Zach Welch wrote:
> On Tue, 2009-12-01 at 10:25 +0100, Øyvind Harboe wrote:
>> On Tue, Dec 1, 2009 at 10:17 AM, Zach Welch 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 part
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,
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, re
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
http://openocd.berlios.de/doc/doxygen/bugs.htm
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
On Tue, Dec 1, 2009 at 1:49 PM, Michael Schwingen
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, except _possibly_ when usi
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 wi
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
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 statistic
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
> 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?
On Tue, 2009-12-01 at 11:06 +0100, Øyvind Harboe wrote:
> On Tue, Dec 1, 2009 at 11:02 AM, Zach Welch 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
On Tue, Dec 1, 2009 at 11:02 AM, Zach Welch 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 compl
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
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.
> > > >
> For OpenOCD, it is not nearly as hard as you make it seem:
>
> 1) Rename ecosboard.c as openocd_ecos.c
> 2) Add openocd_common.c, openocd_linux.c, openocd_win32.c, etc.
> 3) Declare stuff in openocd.h and define them in all files. Some files
> will declare only stubs... others will
OK. This sou
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 exp
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 un
On Tue, 2009-12-01 at 10:24 +0100, Øyvind Harboe wrote:
> On Tue, Dec 1, 2009 at 10:19 AM, Zach Welch 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 enti
>> > 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 eit
On Tue, 2009-12-01 at 10:25 +0100, Øyvind Harboe wrote:
> On Tue, Dec 1, 2009 at 10:17 AM, Zach Welch 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.
> >> >
> >> > F
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
2009/12/1 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/
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
On Tue, 2009-12-01 at 09:18 +0100, Øyvind Harboe wrote:
> On Tue, Dec 1, 2009 at 9:03 AM, Zach Welch 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
On Tue, Dec 1, 2009 at 10:17 AM, Zach Welch 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 just for
On Tue, Dec 1, 2009 at 10:19 AM, Zach Welch 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 at the big pi
> > > 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
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
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
> 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 #
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
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
> 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 anyth
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
On Tue, Dec 1, 2009 at 9:03 AM, Zach Welch 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 commands to sto
>> #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 so
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
> ---
>
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 featu
78 matches
Mail list logo
