date:20090609

Changed reset handling: save off polling state, disable
polling and restore after reset.

With timer based polling enabled a drscan/irscan sequence
in a reset event script could have a poll run inbetween commands,
which would cause havoc, occasionally.

Passed smoketests.

Note that reset may explicitly wait for the target to enter the halted
state and here polling is called directly instead of via a timer, this
polling still happens and was never a problem.

Comments?

Objections?

-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/target/target.c
===
--- src/target/target.c (revision 2179)
+++ src/target/target.c (working copy)
@@ -434,9 +434,14 @@
return ERROR_FAIL;
}
 
+   int save_poll = target_continous_poll;
+   target_continous_poll = 0;
+
sprintf( buf, "ocd_process_reset %s", n->name );
retval = Jim_Eval( interp, buf );
 
+   target_continous_poll = save_poll;
+
if(retval != JIM_OK) {
Jim_PrintErrorMessage(interp);
return ERROR_FAIL;
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Cygwin & EOL settings - an idea..

> Maybe I'm missing something subtle, but as I understand it, the problem is
> that a shell script (which will never be attempted to be run by native
> Windows) is sometimes failing because it has CRLF "Windows" line-endings.
>
> Why don't we set the svn:eol-style property on that file to be LF? That
> way, it will always get LF and only LF line endings, regardless of the
> system on which it is checked out.
>
> svn propset svn:eol-style 'LF' guess-rev.sh (and all other .sh files)

Certainly for .sh files that makes sense to me. I have never heard a reason
why we shouldn't force LF in this case.


-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Cygwin & EOL settings - an idea..

2009-06-09 Thread Peter Denison

On Tue, 9 Jun 2009, Duane Ellis wrote:

> Could there be something we could put in the "configure script" - that
> tells CYGWIN - to behave?
> ie: Perhaps something like the  SHELLOPTS thing?
>
> For example - maybe in the "bootstrap" script?
> And in the "CONFIGURE' script?
> And in the Makefiles?
>
> FYI - with SVN - is who thinks what is native and when.
>
> Tortiose - Native = Windows, period, no way to override this
> SVN - cygwin = Native = CYGWIN setting
>SVN - DOS = Native = Windows
>SVN - on a Linux box = Unix
>  It's even more nasty, if you share something via SAMBA...

Maybe I'm missing something subtle, but as I understand it, the problem is 
that a shell script (which will never be attempted to be run by native 
Windows) is sometimes failing because it has CRLF "Windows" line-endings.

Why don't we set the svn:eol-style property on that file to be LF? That 
way, it will always get LF and only LF line endings, regardless of the 
system on which it is checked out.

svn propset svn:eol-style 'LF' guess-rev.sh (and all other .sh files)

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

Re: [Openocd-development] [patch] workaround CFI alignment error traps

On Tuesday 09 June 2009, Brian Hutchinson wrote:

> What do these alignment traps look like when they happen?  I just updated to
> the latest OpenOCD (SVN 2177) and when I do reset init ... it thinks my
> target isn't halted and times out:

I'd get messages about data alignment, giving addresses like 0x554 (?)
with size 2 ... those were in the "autoprobe" paths ISTR.

Unfortunately I couldn't reproduce them a few moments ago when I
tried; I can't recall the exact commands I was using before.

Not like the simpler "halt" messages you showed.

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

Re: [Openocd-development] RFC: struct cleanup and more

On Tuesday 09 June 2009, Rick Altherr wrote:
> I'm proposing that we use encapsulation and possibly ADTs to define  
> clear boundaries for functionality in the code base.  Rather than have  
> one massive code base, I'd like to see subsystems that can be worked  
> on internally with minimal effect to the users of that subsystem.   
> OpenOCD has some of that and Zach has been doing a lot of work to  
> refine that.

I think we agree there.  And yes, Zach's code overhauls are
good to see.

Something else that's worth observing is that clean boundaries
might make it practical to build an OpenOCD core which doesn't
pre-link every interface, NOR, NAND, and CPU driver ... they
could be dynamically loaded modules.  (CPU drivers being the
most complex.)

Having clean boundaries there would make it easier to provide
new modules, by reducing the amount of information folk need
to master before they can plug in new code.

- Dave

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

Re: [Openocd-development] RFC: struct cleanup and more

The strong vs weak typing issue is very vague and either side could be
defended for nearly every programming language as you can see from
this very discussion. See http://en.wikipedia.org/wiki/Strongly-typed_programming_language
for more examples. In the grand scheme of things, weak vs strong
has very little to do with the suitability of a language for a design
pattern or algorithm.

I'm proposing that we use encapsulation and possibly ADTs to define
clear boundaries for functionality in the code base. Rather than have
one massive code base, I'd like to see subsystems that can be worked
on internally with minimal effect to the users of that subsystem.
OpenOCD has some of that and Zach has been doing a lot of work to
refine that.

--
Rick Altherr
kc8...@kc8apf.net

"He said he hadn't had a byte in three days. I had a short, so I split
it with him."

-- Unsigned

On Jun 9, 2009, at 8:51 PM, David Brownell wrote:

On Tuesday 09 June 2009, Rick Altherr wrote:

although this is the first time I've ever
heard anyone apply that term to C. ...

I've commonly heard C and C++ referred to as strongly-typed.

Never *once* have I heard that usage before yours. Usually C gets
described as a weakly/loosely typed language. (This is in the
context of multiple classes and seminars that did comparative
studies of dozens of programming languages and type systems.)

The fact
that you can't declare a variable without a type is an indication of
this.

No; it just means they have types, and require declarations.

But in fact, C doesn't require, and never has required, types
for everything. I just compiled the following; no errors, and
not even any warnings unless I specify "-std=c99".

main(argc, argv)
{
argc = argv;
return 0;
}

Over time, C has integrated mechanisms that lets one's code
trigger warnings from some flavors of type abuse. But at
its core, it's still weakly typed.

Plus, having a declaration says nothing about whether that
will be "strongly" enforced, or can instead be suborned.

void * let's you work around some undesirable effects of strong-
typing, but it is a type itself.

That "work around" means "violate any type rules you want",
which is prima facie evidence that the type system is not
what's called "strong" ... either at compile time, or at
run time.

Contrast that to something like LISP or Lua ... or even TCL.
In key ways, those have stronger typing than C: they have
only a handful of data types and you can't escape them.
(That property is also a flavor of what's called "safety",
and one which lends itself to crash-free software. C is
not known for being crash-free; neither is C++.)

But on the flip side their type systems are not extensible,
so when you build abstraction layers you've got to define
your own typing conventions. Which can't be enforced at
compile time (another aspect of "safety", which would help
some other robustness characteristics), so they're weak in
those respects. Yet C provides some extension mechanisms...

However, I'm all in favor of evolving code to respect clearly
defined

data types, which encapsulate roles and responsibilities to support
better system structures. If there's a better way to do it, I've
not

yet come across that answer. :)

That's really all I'm recommending. I've seen a dynamic- and
strongly-

typed language do very well for doing encapsulation and using ADTs to
make a very clean system architecture that allows for lots of future
extensions.

smime.p7s
Description: S/MIME cryptographic signature
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [patch] workaround CFI alignment error traps

On Tue, 2009-06-09 at 15:13 -0700, David Brownell wrote:
> Tweak the csb337 code so that it doesn't enable alignment traps when
> it completes the "reset init" sequence.
> 
> It turns out that the current CFI code reliably triggers such traps.
> I don't have time now to sort out what flavor bug that is; I just
> need flash reading/writing to work.
> ---
>  tcl/board/csb337.cfg |4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)

Committed, r2179.

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

Re: [Openocd-development] [patch] improve "poll" docs, and report bgnd polling status

On Tue, 2009-06-09 at 15:12 -0700, David Brownell wrote:
> Move the documentation for the "poll" command up with
> other server configuration.  Explain what it's about;
> reference the related "$target_name curstate" method.
> 
> Update "poll" output to report whether background polling
> is enabled or not.
> 
> Also fix a small typo; PC's have "complementary" tools.
> Some have also "complimentary" ones; but not all.
> ---
>  doc/openocd.texi|   82 +++---
>  src/target/target.c |6 ++-
>  2 files changed, 68 insertions(+), 20 deletions(-)

Committed, r2178.  (Forgot to include attribution though. Sorry).

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

Re: [Openocd-development] RFC: struct cleanup and more

On Tuesday 09 June 2009, Rick Altherr wrote:
> > although this is the first time I've ever
> > heard anyone apply that term to C.  ...
> 
> I've commonly heard C and C++ referred to as strongly-typed.

Never *once* have I heard that usage before yours.  Usually C gets
described as a weakly/loosely typed language.  (This is in the
context of multiple classes and seminars that did comparative
studies of dozens of programming languages and type systems.)

> The fact   
> that you can't declare a variable without a type is an indication of  
> this. 

No; it just means they have types, and require declarations.

But in fact, C doesn't require, and never has required, types
for everything.  I just compiled the following; no errors, and
not even any warnings unless I specify "-std=c99".

main(argc, argv)
{
argc = argv;
return 0;
}

Over time, C has integrated mechanisms that lets one's code
trigger warnings from some flavors of type abuse.  But at
its core, it's still weakly typed.

Plus, having a declaration says nothing about whether that
will be "strongly" enforced, or can instead be suborned.

> void * let's you work around some undesirable effects of strong-  
> typing, but it is a type itself.

That "work around" means "violate any type rules you want",
which is prima facie evidence that the type system is not
what's called "strong" ... either at compile time, or at
run time.

Contrast that to something like LISP or Lua ... or even TCL.
In key ways, those have stronger typing than C:  they have
only a handful of data types and you can't escape them.
(That property is also a flavor of what's called "safety",
and one which lends itself to crash-free software.  C is
not known for being crash-free; neither is C++.)

But on the flip side their type systems are not extensible,
so when you build abstraction layers you've got to define
your own typing conventions.   Which can't be enforced at
compile time (another aspect of "safety", which would help
some other robustness characteristics), so they're weak in
those respects.  Yet C provides some extension mechanisms...

:)

> > However, I'm all in favor of evolving code to respect clearly defined
> > data types, which encapsulate roles and responsibilities to support
> > better system structures.  If there's a better way to do it, I've not
> > yet come across that answer.  :)
>
> That's really all I'm recommending.  I've seen a dynamic- and strongly-
> typed language do very well for doing encapsulation and using ADTs to  
> make a very clean system architecture that allows for lots of future  
> extensions.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [patch] workaround CFI alignment error traps

On Tue, Jun 9, 2009 at 6:13 PM, David Brownell  wrote:

> Tweak the csb337 code so that it doesn't enable alignment traps when
> it completes the "reset init" sequence.
>
> It turns out that the current CFI code reliably triggers such traps.
> I don't have time now to sort out what flavor bug that is; I just
> need flash reading/writing to work.
> ---
>  tcl/board/csb337.cfg |4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
>
> ___
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
>

What do these alignment traps look like when they happen?  I just updated to
the latest OpenOCD (SVN 2177) and when I do reset init ... it thinks my
target isn't halted and times out:

hu...@hutch-laptop:/$ !telnet
telnet localhost 
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> reset init
JTAG tap: pc205.cpu tap/device found: 0x079263a9 (mfg: 0x1d4, part: 0x7926,
ver: 0x0)
JTAG Tap/device matched
PC was not 0. Does this target need srst_pulls_trst?
target state: halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x00d3 pc: 0x
MMU: disabled, D-Cache: disabled, I-Cache: disabled
fast memory access is enabled
dcc downloads are enabled
3000 kHz
target not halted
Runtime error, file "/usr/local/share/openocd/scripts/board/tess.cfg", line
38:

timed out while waiting for target halted
Runtime error, file "embedded:startup.tcl", line 226:
expected return code but got 'TARGET: pc205.cpu - Not halted'
in procedure 'ocd_process_reset'
called at file "embedded:startup.tcl", line 208
called at file "embedded:startup.tcl", line 209
called at file "embedded:startup.tcl", line 225
Runtime error, file "command.c", line 453:
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] RFC: struct cleanup and more




On Jun 9, 2009, at 6:41 PM, David Brownell wrote:


On Monday 01 June 2009, Rick Altherr wrote:

C and C++ are both strongly typed


I'm used to definitions of "strong" typing that preclude the  
inability to

break out of the type system.


That would be "very strong".  "strong" just means that a variable has  
a designated type associated with it.  "weak" on the other hand is  
like JavaScript where a variable has no type information attached to it.



C makes that trivial:  cast to/from "void *"
pointers, and you're done.  That's because it was intended from the
start to be a low level language, for systems programming, which  
doesn't

hide the machine-specific details that "strong" typing does.



"strong" typing has nothing to do with hiding machine-specific  
details.  It's all about a variable being designated to hold a  
specific type of data rather than an arbitrary type.  Now, void * in C  
lets you cast between types that would otherwise cause errors.  That  
doesn't make it "weak", just not as "strong".



It is however worth pointing out that there are dozens of definitions
of what "strong typing" is ... although this is the first time I've  
ever

heard anyone apply that term to C.  (Since I first found a looseleaf
binder of line-printer output, called "The C Programming Language", in
one of the libraries at Case Western.  The printed/bound versions  
weren't

very available!)



I've commonly heard C and C++ referred to as strongly-typed.  The fact  
that you can't declare a variable without a type is an indication of  
this.  void * let's you work around some undesirable effects of strong- 
typing, but it is a type itself.


C++ adds a few type frameworks to C, yes, but still doesn't have  
what I'd

call "strong" typing.  (Plus, all its dynamic/reinterpret/static/const
cast mechanisms get confusing.)



I agree the multitude of options for casting are confusing in C++, but  
those actually point to the fact that C++ is strongly typed by  
default.  The reason that dynamic_cast exists is that C++ assumes that  
references to variables are to a specific type (static typing) and  
will normally write code to access it directly as such.  dynamic_cast  
tells C++ to instead evaluate the type at runtime (dynamic typing) so  
the underlying type can be changed without recompiling the calling code.





 but proper use
of an abstract type can greatly simplify the implementation as the
efforts to simplify the target APIs has shown. We are already  
adopting
most of the encapsulation paradigm for targets and ADTs build on  
that.


Encapsulation != strong typing (and vice versa!).


I never said it was.  Encapsulation can easily be done in any language  
regardless of strong vs weak.  ADTs on the other hand build on top of  
encapsulation and dynamic runtime type information.  They utilize  
encapsulation to hide the internal details of the object so that those  
internals can be changed by subclasses.  Further, by using dynamic  
typing, the subclasses can be passed a reference to the ADT and  
convert it into their subclass so they can do special things to it.



And I still stand
by my observation that I've usually seen *team* approaches to strong
typing fail, when they need to be built with weakly typed languages.
The dynamics rarely support it as the code base evolves.



I'm not a huge fan of "very strong" for typing nor of static typing.   
They purport to improve the stability of the code by always knowing  
what can be done with an object but it makes for a lot of nasty code  
though since non-trivial programs often need some of the features of  
weak-typing along with dynamic typing.  I'm actually quite fond of  
Objective-C which is strongly-typed and very dynamic.  Further,  
everything is allocated on the heap and passed by pointer.  So objects  
can be cast to a generic type that means "some type of class" and then  
have the type information recovered by asking the object.



However, I'm all in favor of evolving code to respect clearly defined
data types, which encapsulate roles and responsibilities to support
better system structures.  If there's a better way to do it, I've not
yet come across that answer.  :)



That's really all I'm recommending.  I've seen a dynamic- and strongly- 
typed language do very well for doing encapsulation and using ADTs to  
make a very clean system architecture that allows for lots of future  
extensions.





I think that a well thought out implementation of an abstract target
type and interface will do wonders to the code base and maintenance.
Using encapsulation will make this even better for future expansion
and enhancement.


All that's true, but it's still very different from "strong typing"
(using any definition I've worked with).

:)




--
Rick Altherr
kc8...@kc8apf.net

"He said he hadn't had a byte in three days. I had a short, so I split  
it with him."

 -- Unsigned




smime.p7s
Description: S/MIME cryptographic signature
___

Re: [Openocd-development] assert vs. error messages

2009-06-09 Thread Michael Bruck

Errors in user input should detected where user input is parsed. This
includes checks that pre-conditions for internal API calls are
satisfied.

Internal functions should use an assert.

Moving user error diagnostics from the user input functions to
internal functions is a clear violation of the API layers.

To make this more clear, the moment you have a user input handler that
calls more than one internal function the user messages you have
piggy-backed on the internal APIs will become less and less meaningful
to the user. The fact that we have user function like "drscan" that
just maps to exactly one internal API call is merely a coincidence and
should not be an excuse to let Brownian motion cause the drifting of
user error diagnostics into internal API layers.

Michael

On Tue, Jun 9, 2009 at 9:39 AM, Øyvind Harboe wrote:
> I'm satisfied that I've put the performance issue with checking at too
> low a level on the radar.
>
> I'll leave this to Zach's judgement (he's the one who's working on it
> currently), but I'm reserving the right to raise an objection later based
> on measured performance problems(referring to Rick pointing out
> that performance should be dealt with by measurements and
> not speculation).
>
> I very few concerns that it will be fundamentally hard to address any
> documented performance issues in this regard, unless something
> radically new crops up in terms of doing *extensive* runtime checking.
>
>
>
> --
> Øyvind Harboe
> Embedded software and hardware consulting services
> http://consulting.zylin.com
> ___
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
>
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] My source [find target, interface etc.] lines in my .cfg files don't work with latest build

On Tue, Jun 9, 2009 at 8:05 PM, Zach Welch  wrote:

> On Tue, 2009-06-09 at 17:52 -0400, Brian Hutchinson wrote:
> >
> >
> > On Tue, Jun 9, 2009 at 5:26 PM, Brian Hutchinson
> >  wrote:
> > I searched and saw the thread on find tcl/target etc. from a
> > week ago but can't figure out what is going on.  Do we not use
> > source [find interface/jtagkey.cfg] type lines in our configs
> > anymore?
> >
> > I guess I've missed something ... tough to be on vacation and
> > come back to a full inbox :)
> >
> > Regards,
> >
> > Brian
> >
> > I usually start openocd with a line like:
> > openocd -c "fast enable" -f board/my_board.cfg -c "init"
> >
> > With SVN 2177, it complained that it couldn't find my_board.cfg.
> >
> > I took the "board" out and tried to launch with just:
> > openocd -c "fast enable" -f my_board.cfg -c "init"
> >
> > ... and then it complained about my first source [find target/ ... ]
> > line.
> >
> > Searched the list and the only thing that smelled like what I was
> > seeing was:
> >
> http://www.mail-archive.com/openocd-development@lists.berlios.de/msg05321.html
> >
> > I'm using custom .cfg files that were already in
> > my /usr/loca/lib/openocd tree.
>
> The installed path of these files changed in revision r1920.  Its commit
> comment documents the specific changes, but the gist of it would be that
> OpenOCD searches for these files in a $(pkgdatadir)/scripts or
> $(pkgdatadir)/site.  Your scripts should live under the later path.
>
> Cheers,
>
> Zach
>
> Thanks,

I noticed that if I launched openocd from my /usr/local/lib/openocd
directory that it worked.  I'll check out the comments you mentioned and
move my scripts to the right place.

Regards,

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

Re: [Openocd-development] RFC: struct cleanup and more

On Monday 01 June 2009, Rick Altherr wrote:
> C and C++ are both strongly typed

I'm used to definitions of "strong" typing that preclude the inability to
break out of the type system.  C makes that trivial:  cast to/from "void *"
pointers, and you're done.  That's because it was intended from the
start to be a low level language, for systems programming, which doesn't
hide the machine-specific details that "strong" typing does.

It is however worth pointing out that there are dozens of definitions
of what "strong typing" is ... although this is the first time I've ever
heard anyone apply that term to C.  (Since I first found a looseleaf
binder of line-printer output, called "The C Programming Language", in
one of the libraries at Case Western.  The printed/bound versions weren't
very available!)

C++ adds a few type frameworks to C, yes, but still doesn't have what I'd
call "strong" typing.  (Plus, all its dynamic/reinterpret/static/const
cast mechanisms get confusing.)

>but proper use  
> of an abstract type can greatly simplify the implementation as the  
> efforts to simplify the target APIs has shown. We are already adopting  
> most of the encapsulation paradigm for targets and ADTs build on that.  

Encapsulation != strong typing (and vice versa!).  And I still stand
by my observation that I've usually seen *team* approaches to strong
typing fail, when they need to be built with weakly typed languages.
The dynamics rarely support it as the code base evolves.

However, I'm all in favor of evolving code to respect clearly defined
data types, which encapsulate roles and responsibilities to support
better system structures.  If there's a better way to do it, I've not
yet come across that answer.  :)

> I think that a well thought out implementation of an abstract target  
> type and interface will do wonders to the code base and maintenance.  
> Using encapsulation will make this even better for future expansion  
> and enhancement. 

All that's true, but it's still very different from "strong typing"
(using any definition I've worked with).

:)

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

Re: [Openocd-development] Jlink not running under cygwin

2009-06-09 Thread Xiaofan Chen

On Tue, Jun 9, 2009 at 11:44 PM, Gene Smith wrote:
> I now get a successful build under cygwin. When I plug the jlink usb to
> windows and run openocd I see the the "Cannot find jlink Interface!"
> error as printed below. Do I need another special windows driver when
> running jlink in cygwin? To build I only copied usb.h and libusb.a as
> directed from libusb-win32 project. There is quite a bit of stuff in the
> libusb-win32-device-bin.tar.gz that I haven't used. Should this be
> installed?

If you are using XP, you can try the libusb-win32 filter driver (to work
along with the Segger driver).

If you are using Vista 32 bit, you'd better use the libusb-win32 device
driver (to replace the default Segger driver). The filter driver is not
recommended by the author any more. It can cause BSOD under
Vista or cause other problems under Vista 32.

I've tried OpenOCD under Vista 32bit with the libusb-win32 device
driver for J-Link without any issue.

If you are using Vista 64bit, you are out of luck as libusb-win32 does
not work under Vista 64bit.

To install the device driver, you need to use the INF wizard to
create the INF file. Then under Device Manager, you can
right click the J-link entry and choose "Update Driver". Point
Windows to the extracted libusb-win32-device-bin directory
(where the INF file is created).

-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] My source [find target, interface etc.] lines in my .cfg files don't work with latest build

On Tue, 2009-06-09 at 17:52 -0400, Brian Hutchinson wrote:
> 
> 
> On Tue, Jun 9, 2009 at 5:26 PM, Brian Hutchinson
>  wrote:
> I searched and saw the thread on find tcl/target etc. from a
> week ago but can't figure out what is going on.  Do we not use
> source [find interface/jtagkey.cfg] type lines in our configs
> anymore?
> 
> I guess I've missed something ... tough to be on vacation and
> come back to a full inbox :)
> 
> Regards,
> 
> Brian
> 
> I usually start openocd with a line like:
> openocd -c "fast enable" -f board/my_board.cfg -c "init"
> 
> With SVN 2177, it complained that it couldn't find my_board.cfg.
> 
> I took the "board" out and tried to launch with just:
> openocd -c "fast enable" -f my_board.cfg -c "init"
> 
> ... and then it complained about my first source [find target/ ... ]
> line.
> 
> Searched the list and the only thing that smelled like what I was
> seeing was:
> http://www.mail-archive.com/openocd-development@lists.berlios.de/msg05321.html
> 
> I'm using custom .cfg files that were already in
> my /usr/loca/lib/openocd tree.

The installed path of these files changed in revision r1920.  Its commit
comment documents the specific changes, but the gist of it would be that
OpenOCD searches for these files in a $(pkgdatadir)/scripts or
$(pkgdatadir)/site.  Your scripts should live under the later path.

Cheers,

Zach

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

Re: [Openocd-development] unable to open ftdi device

Paul, Rick,

I found the problem. My usbfs somehow got unmounted. Thanks for the ideas.

Cheers,
Paul

Rick Altherr wrote:
> There is a udev rule file in the contrib folder.  It's been a while 
> since I've messed with Linux device nodes, but I believe the device will 
> show up in /sys but udev needs to create the /dev node.
> -- 
> Rick Altherr
> kc8...@kc8apf.net
> 
> "He said he hadn't had a byte in three days. I had a short, so I split 
> it with him."
>  -- Unsigned
> 
> 
> 
> On Jun 9, 2009, at 2:32 PM, Paul J THACKER wrote:
> 
>> Hi,
>>
>> Openocd-0.1.0 on OpenSUSE 11.0 with Amontec jtagkey-tiny:
>>
>> thack...@cea05:~/cartesio/eclipse/trunk> openocd -f jtagkey-tiny.cfg
>> Open On-Chip Debugger 0.1.0 (2009-05-21-09:56) Release
>>
>>
>> BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
>>
>>
>> $URL:
>> https://kc8...@svn.berlios.de/svnroot/repos/openocd/tags/openocd-0.1.0/src/openocd.c
>>  
>>
>> $
>> Error: unable to open ftdi device: 18
>> initialise_usb failed
>> Error: ListDevices: NONE
>>
>> Runtime error, file "command.c", line 456:
>>

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

[Openocd-development] Cygwin & EOL settings - an idea..

2009-06-09 Thread Duane Ellis

All -

I saw a while ago  something about "SHELLOPTS=igncr"

I suffered from similar problems with "LANG=", to the point where - my 
core scripts set & export - and override all "LOCALE" settings and force 
them to ENGLISH , more correctly "C" - not english. Once I did that, 
many of my problems where greatly resolved.  Yea, some of my non-native 
english speakers complained, I (1) showed the how to undo the problem, 
(2) and told them when they had a fix for the bug/problem - (3) please 
send it to me, then (4) I would give them another bug, after a while (5) 
they gave up and stopped asking.

Could there be something we could put in the "configure script" - that 
tells CYGWIN - to behave?
ie: Perhaps something like the  SHELLOPTS thing?

For example - maybe in the "bootstrap" script?
And in the "CONFIGURE' script?
And in the Makefiles?

FYI - with SVN - is who thinks what is native and when.

 Tortiose - Native = Windows, period, no way to override this
 SVN - cygwin = Native = CYGWIN setting
SVN - DOS = Native = Windows
SVN - on a Linux box = Unix
  It's even more nasty, if you share something via SAMBA...

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

Re: [Openocd-development] RFC: add doc/interface/, doc/target/, and doc/board/*

On Thursday 21 May 2009, Zach Welch wrote:
> Hi all,
> 
> In thinking about user documentation, I was wondering whether we should
> think about adding doc/target/ and doc/boards directories.  In it, we
> would place a documentation file for each supported target and board,
> respectively.  It may be possible to consolidate some guides, but this
> would allow us to provide a nice addition to the user guide that would
> answer the example question:  "what do I do to get target XX working?"

One of the last significant things-yet-to-be-done for the User's guide
is in this area.  The answer I *want* to see for that question is:

- Fire up $EDITOR for "openocd.cfg"

- Add "source [find interface/...cfg]" for your
  particular interface

- Add "source [find board/...cfg]" for your
  particular board

- Save the file, exit $EDITOR

- Invoke "openocd" in the directory with openocd.cfg and
  which holds files you want to download, and other stuff
  you need to work with.

Plus the hardware connectivity steps, presumably for one of the widely
available ft2232 adapters.  And a plea to submit more board config files.

Beyond that, I think that today we're realistically only at the stage
where "read the board config files" is good advice.  There's too much
variability there, users need to know exactly what they're getting.

There's nothing wrong IMO with having documentation in the board.cfg
files ...

> Basically, I am suggesting target Quick Setup Guides, References, and
> FAQs.  If we consider the same thing for the JTAG interfaces, this would
> allow us to move most of the part-specific text out of the main User
> Guide proper, allowing it to focus on introducing the general concepts
> that apply to all targets, boards, and interfaces.

Doesn't seem that plausible to me right now.  Agree about focussing
the user's guide in that way -- it's got "issues" still -- but having
a flotilla of other docs seems very unlikely.

What does seem plausible is getting it to the point that there's less
chaos in the process of bringing up new boards, and that the docs
start to *help* that process.  For two basic types of user:  (a) the
person who can use one of the canned configs, since they already have
a config for their board/interface; and (b) the person who needs to
coem up with a new config.

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

Re: [Openocd-development] unable to open ftdi device

Hi Paul,

 From configure.log:

./configure --enable-ft2232_ftd2xx --no-create --no-recursion

The libs are installed:

thack...@cea05:~/openocd/openocd-0.1.0> ll /usr/local/lib/libftd*
lrwxrwxrwx 1 root root 34 2009-05-21 09:52 
/usr/local/lib/libftd2xx.so -> /usr/local/lib/libftd2xx.so.0.4.10
lrwxrwxrwx 1 root root 34 2009-05-21 09:52 
/usr/local/lib/libftd2xx.so.0 -> /usr/local/lib/libftd2xx.so.0.4.10
-rwxr-xr-x 1 root root 313768 2009-05-20 16:09 
/usr/local/lib/libftd2xx.so.0.4.10

What's really strange is that it worked with the STM32 last week, but 
now that doesn't work either.

Thanks,
Paul

Paul Thomas wrote:
> Paul,
> 
> With my ft2232 device it shows up as /dev/usbdevX.Y_epZ. Did you build 
> openocd with libftdi and/or ftd2xx support? Is libftdi or ftd2xx 
> installed on your system?
> 
> thanks,
> Paul
> 
> On Tue, Jun 9, 2009 at 2:32 PM, Paul J THACKER  > wrote:
> 
> Hi,
> 
> Openocd-0.1.0 on OpenSUSE 11.0 with Amontec jtagkey-tiny:
> 
> thack...@cea05:~/cartesio/eclipse/trunk> openocd -f jtagkey-tiny.cfg
> Open On-Chip Debugger 0.1.0 (2009-05-21-09:56) Release
> 
> 
> BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
> 
> 
> $URL:
> 
> https://kc8...@svn.berlios.de/svnroot/repos/openocd/tags/openocd-0.1.0/src/openocd.c
> 
> 
> $
> Error: unable to open ftdi device: 18
> initialise_usb failed
> Error: ListDevices: NONE
> 
> Runtime error, file "command.c", line 456:
> 
> Trace and debug outputs:
> 
> open("jtagkey-tiny.cfg", O_RDONLY)  = 3
> close(3)= 0
> open("jtagkey-tiny.cfg", O_RDONLY)  = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb8092000
> read(3, "#interface\ninterface ft2232\nft22"..., 4096) = 118
> read(3, "", 4096)   = 0
> read(3, "", 4096)   = 0
> close(3)= 0
> munmap(0xb8092000, 4096)= 0
> gettimeofday({1244582536, 328068}, NULL) = 0
> gettimeofday({1244582536, 328114}, NULL) = 0
> gettimeofday({1244582536, 329023}, NULL) = 0
> gettimeofday({1244582536, 329079}, NULL) = 0
> gettimeofday({1244582536, 329212}, NULL) = 0
> gettimeofday({1244582536, 329255}, NULL) = 0
> gettimeofday({1244582536, 329362}, NULL) = 0
> gettimeofday({1244582536, 329404}, NULL) = 0
> gettimeofday({1244582536, 329534}, NULL) = 0
> gettimeofday({1244582536, 329577}, NULL) = 0
> open("/proc/sys/kernel/osrelease", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb8092000
> read(3, "2.6.25.18-0.2-pae\n", 1024)= 18
> read(3, "", 1024)   = 0
> close(3)= 0
> munmap(0xb8092000, 4096)= 0
> open("/proc/bus/usb",
> O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x8) = 3
> fstat64(3, {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
> fcntl64(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
> getdents64(3, /* 2 entries */, 1024)= 48
> getdents64(3, /* 0 entries */, 1024)= 0
> close(3)= 0
> open("/dev/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x8) =
> -1 ENOENT (No such file or directory)
> write(2, "Error: unable to open ftdi devic"..., 38Error: unable to open
> ftdi device: 18
> ) = 38
> open("/proc/bus/usb",
> O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x8) = 3
> fstat64(3, {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
> getdents64(3, /* 2 entries */, 1024)= 48
> getdents64(3, /* 0 entries */, 1024)= 0
> close(3)= 0
> open("/dev/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x8) =
> -1 ENOENT (No such file or directory)
> fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 6), ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb8092000
> write(1, "initialise_usb failed\n", 22initialise_usb failed
> ) = 22
> write(2, "Error: ListDevices: NONE\n\n", 26Error: ListDevices: NONE
> 
> ) = 26
> write(2, "Runtime error, file \"command.c\","..., 47Runtime error, file
> "command.c", line 456:
> ) = 47
> exit_group(1)
> 
> cea05:/home/thackerp/cartesio/eclipse/trunk # openocd -d 3 -f
> jtagkey-tiny.cfg
> Open On-Chip Debugger 0.1.0 (2009-05-21-09:56) Release
> 
> 
> BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
> 
> 
> $URL:
> 
> https://kc8...@svn.berlios.de/svnroot/repos/openocd/tags/openocd-0.1.0/src/openocd.c
>

Re: [Openocd-development] unable to open ftdi device

Hi Rick,

I saw the openocd.udev file. Unfortunately, OpenSUSE doesn't have a 
group named "plugdev". I created the following using some existing rules 
as an example, but it doesn't help:

BUS=="usb", SYSFS{idVendor}=="0403", SYSFS{idProduct}=="cff8", 
MODE="664", RUN="/etc/udev/setmode"

These are my /sys and /dev usb nodes:

cea05:~ # ls -l /sys/bus/usb/devices/
total 0
lrwxrwxrwx 1 root root 0 2009-06-09 14:55 1-0:1.0 -> 
../../../devices/pci:00/:00:02.0/usb1/1-0:1.0
lrwxrwxrwx 1 root root 0 2009-06-09 14:55 1-1 -> 
../../../devices/pci:00/:00:02.0/usb1/1-1
lrwxrwxrwx 1 root root 0 2009-06-09 14:55 1-1:1.0 -> 
../../../devices/pci:00/:00:02.0/usb1/1-1/1-1:1.0
lrwxrwxrwx 1 root root 0 2009-06-09 14:55 1-3 -> 
../../../devices/pci:00/:00:02.0/usb1/1-3
lrwxrwxrwx 1 root root 0 2009-06-09 14:55 1-3:1.0 -> 
../../../devices/pci:00/:00:02.0/usb1/1-3/1-3:1.0
lrwxrwxrwx 1 root root 0 2009-06-09 14:55 1-3:1.1 -> 
../../../devices/pci:00/:00:02.0/usb1/1-3/1-3:1.1
lrwxrwxrwx 1 root root 0 2009-06-09 14:55 2-0:1.0 -> 
../../../devices/pci:00/:00:02.2/usb2/2-0:1.0
lrwxrwxrwx 1 root root 0 2009-06-09 14:55 2-3 -> 
../../../devices/pci:00/:00:02.2/usb2/2-3
lrwxrwxrwx 1 root root 0 2009-06-09 14:55 2-3:1.0 -> 
../../../devices/pci:00/:00:02.2/usb2/2-3/2-3:1.0
lrwxrwxrwx 1 root root 0 2009-06-09 14:55 3-0:1.0 -> 
../../../devices/pci:00/:00:02.1/usb3/3-0:1.0
lrwxrwxrwx 1 root root 0 2009-06-09 14:55 3-2 -> 
../../../devices/pci:00/:00:02.1/usb3/3-2
lrwxrwxrwx 1 root root 0 2009-06-09 14:55 3-2:1.0 -> 
../../../devices/pci:00/:00:02.1/usb3/3-2/3-2:1.0
lrwxrwxrwx 1 root root 0 2009-06-09 14:55 usb1 -> 
../../../devices/pci:00/:00:02.0/usb1
lrwxrwxrwx 1 root root 0 2009-06-09 14:55 usb2 -> 
../../../devices/pci:00/:00:02.2/usb2
lrwxrwxrwx 1 root root 0 2009-06-09 14:55 usb3 -> 
../../../devices/pci:00/:00:02.1/usb3
cea05:~ # ls -l /dev/usb*
crw-rw 1 root root 253,  0 2009-06-08 02:08 /dev/usbdev1.1_ep00
crw-rw 1 root root 253,  1 2009-06-08 02:08 /dev/usbdev1.1_ep81
crw-rw 1 root root 253,  9 2009-06-08 02:08 /dev/usbdev1.2_ep00
crw-rw 1 root root 253, 10 2009-06-08 02:08 /dev/usbdev1.2_ep81
crw-rw-r-- 1 root root 253, 13 2009-06-09 14:54 /dev/usbdev1.5_ep00
crw-rw-r-- 1 root root 253, 15 2009-06-09 14:54 /dev/usbdev1.5_ep02
crw-rw-r-- 1 root root 253, 17 2009-06-09 14:54 /dev/usbdev1.5_ep04
crw-rw-r-- 1 root root 253, 14 2009-06-09 14:54 /dev/usbdev1.5_ep81
crw-rw-r-- 1 root root 253, 16 2009-06-09 14:54 /dev/usbdev1.5_ep83
crw-rw 1 root root 253,  2 2009-06-08 02:08 /dev/usbdev2.1_ep00
crw-rw 1 root root 253,  3 2009-06-08 02:08 /dev/usbdev2.1_ep81
crw-rw 1 root root 253,  6 2009-06-08 02:08 /dev/usbdev2.3_ep00
crw-rw 1 root root 253,  7 2009-06-08 02:08 /dev/usbdev2.3_ep01
crw-rw 1 root root 253,  8 2009-06-08 02:08 /dev/usbdev2.3_ep82
crw-rw 1 root root 253,  4 2009-06-08 02:08 /dev/usbdev3.1_ep00
crw-rw 1 root root 253,  5 2009-06-08 02:08 /dev/usbdev3.1_ep81
crw-rw 1 root root 253, 11 2009-06-08 02:08 /dev/usbdev3.2_ep00
crw-rw 1 root root 253, 12 2009-06-08 02:08 /dev/usbdev3.2_ep81

/sys/bus/usb/devices/1-3 is the Amontec, based on the pid/vid, but I 
don't see a corresponding device.

Thanks,
Paul

Rick Altherr wrote:
> There is a udev rule file in the contrib folder.  It's been a while 
> since I've messed with Linux device nodes, but I believe the device will 
> show up in /sys but udev needs to create the /dev node.
> -- 
> Rick Altherr
> kc8...@kc8apf.net
> 
> "He said he hadn't had a byte in three days. I had a short, so I split 
> it with him."
>  -- Unsigned
> 
> 
> 
> On Jun 9, 2009, at 2:32 PM, Paul J THACKER wrote:
> 
>> Hi,
>>
>> Openocd-0.1.0 on OpenSUSE 11.0 with Amontec jtagkey-tiny:
>>
>> thack...@cea05:~/cartesio/eclipse/trunk> openocd -f jtagkey-tiny.cfg
>> Open On-Chip Debugger 0.1.0 (2009-05-21-09:56) Release
>>
>>
>> BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
>>
>>
>> $URL:
>> https://kc8...@svn.berlios.de/svnroot/repos/openocd/tags/openocd-0.1.0/src/openocd.c
>>  
>>
>> $
>> Error: unable to open ftdi device: 18
>> initialise_usb failed
>> Error: ListDevices: NONE
>>
>> Runtime error, file "command.c", line 456:
>>
>> Trace and debug outputs:
>>
>> open("jtagkey-tiny.cfg", O_RDONLY)  = 3
>> close(3)= 0
>> open("jtagkey-tiny.cfg", O_RDONLY)  = 3
>> fstat64(3, {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
>> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
>> 0) = 0xb8092000
>> read(3, "#interface\ninterface ft2232\nft22"..., 4096) = 118
>> read(3, "", 4096)   = 0
>> read(3, "", 4096)   = 0
>> close(3)= 0
>> munmap(0xb8092000, 4096)= 0
>> gettimeofday({1244582536, 328068}, NULL) = 0
>> gettimeofday({1244582536, 328114}, NULL) = 0
>> gettimeofday({124458253

[Openocd-development] [patch] workaround CFI alignment error traps

Tweak the csb337 code so that it doesn't enable alignment traps when
it completes the "reset init" sequence.

It turns out that the current CFI code reliably triggers such traps.
I don't have time now to sort out what flavor bug that is; I just
need flash reading/writing to work.
---
 tcl/board/csb337.cfg |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

Tweak the csb337 code so that it doesn't enable alignment traps when
it completes the "reset init" sequence.

It turns out that the current CFI code reliably triggers such traps.
I don't have time now to sort out what flavor bug that is; I just
need flash reading/writing to work.
---
 tcl/board/csb337.cfg |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

--- a/tcl/board/csb337.cfg
+++ b/tcl/board/csb337.cfg
@@ -108,9 +108,7 @@ proc csb337_reset_init { } {
 	#	I(12) = 1
 	#  - Reserved/ones
 	#	6:3 = 1
-	#  - Alignment traps enabled
-	#	A(1) = 1
-	arm920t cp15 2 0xc000107a
+	arm920t cp15 2 0xc0001078
 }
 
 $_TARGETNAME configure -event reset-init {csb337_reset_init}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [patch] improve "poll" docs, and report bgnd polling status

Move the documentation for the "poll" command up with
other server configuration.  Explain what it's about;
reference the related "$target_name curstate" method.

Update "poll" output to report whether background polling
is enabled or not.

Also fix a small typo; PC's have "complementary" tools.
Some have also "complimentary" ones; but not all.
---
 doc/openocd.texi|   82 +++---
 src/target/target.c |6 ++-
 2 files changed, 68 insertions(+), 20 deletions(-)

Move the documentation for the "poll" command up with
other server configuration.  Explain what it's about;
reference the related "$target_name curstate" method.

Update "poll" output to report whether background polling
is enabled or not.

Also fix a small typo; PC's have "complementary" tools.
Some have also "complimentary" ones; but not all.
---
 doc/openocd.texi|   82 +++---
 src/target/target.c |6 ++-
 2 files changed, 68 insertions(+), 20 deletions(-)

--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -1302,6 +1302,67 @@ The default behaviour is @option{disable
 use @option{enable} see these errors reported.
 @end deffn
 
+...@anchor{event Polling}
+...@section Event Polling
+
+Hardware debuggers are parts of asynchronous systems,
+where significant events can happen at any time.
+The OpenOCD server needs to detect some of these events,
+so it can report them to through TCL command line
+or to GDB.
+
+Examples of such events include:
+
+...@itemize
+...@item One of the targets can stop running ... maybe it triggers
+a code breakpoint or data watchpoint, or halts itself.
+...@item Messages may be sent over ``debug message'' channels ... many
+targets support such messages sent over JTAG,
+for receipt by the person debugging or tools.
+...@item Loss of power ... some adapters can detect these events.
+...@item Resets not issued through JTAG ... such reset sources
+can include button presses or other system hardware, sometimes
+including the target itself (perhaps through a watchdog).
+...@item Debug instrumentation sometimes supports event triggering
+such as ``trace buffer full'' (so it can quickly be emptied)
+or other signals (to correlate with code behavior).
+...@end itemize
+
+None of those events are signaled through standard JTAG signals.
+However, most conventions for JTAG connectors include voltage
+level and system reset (SRST) signal detection.
+Some connectors also include instrumentation signals, which
+can imply events when those signals are inputs.
+
+In general, OpenOCD needs to periodically check for those events,
+either by looking at the status of signals on the JTAG connector
+or by sending synchronous ``tell me your status'' JTAG requests
+to the various active targets.
+There is a command to manage and monitor that polling,
+which is normally done in the background.
+
+...@deffn Command poll [...@option{on}|@option{off}]
+Poll the current target for its current state.
+(Also, @pxref{target curstate}.)
+If that target is in debug mode, architecture
+specific information about the current state is printed.
+An optional parameter
+allows background polling to be enabled and disabled.
+
+You could use this from the TCL command shell, or
+from GDB using @command{monitor poll} command.
+...@example
+> poll
+background polling: on
+target state: halted
+target halted in ARM state due to debug-request, \
+   current mode: Supervisor
+cpsr: 0x80d3 pc: 0x11081bfc
+MMU: disabled, D-Cache: disabled, I-Cache: enabled
+>
+...@end example
+...@end deffn
+
 @node Interface - Dongle Configuration
 @chapter Interface - Dongle Configuration
 JTAG Adapters/Interfaces/Dongles are normally configured
@@ -2492,12 +2553,14 @@ for @{ set x 0 @} @{ $x < [target count]
 @end example
 @end deffn
 
+...@anchor{target curstate}
 @deffn Command {$target_name curstate}
 Displays the current target state:
 @code{debug-running},
 @code{halted},
 @code{reset},
 @code{running}, or @code{unknown}.
+(Also, @pxref{Event Polling}.)
 @end deffn
 
 @deffn Command {$target_name eventlist}
@@ -3769,23 +3832,6 @@ Debug and trace infrastructure:
 @end example
 @end deffn
 
-...@deffn Command poll [...@option{on}|@option{off}]
-Poll the current target for its current state.
-If that target is in debug mode, architecture
-specific information about the current state is printed. An optional parameter
-allows continuous polling to be enabled and disabled.
-
-...@example
-> poll
-target state: halted
-target halted in ARM state due to debug-request, \
-   current mode: Supervisor
-cpsr: 0x80d3 pc: 0x11081bfc
-MMU: disabled, D-Cache: disabled, I-Cache: enabled
->
-...@end example
-...@end deffn
-
 @deffn Command halt [ms]
 @deffnx Command wait_halt [ms]
 The @command{halt} command first sends a halt request to the target,
@@ -3843,7 +3889,7 @@ state.
 These commands are available when
 OpenOCD is built with @option{--enable-ioutil}.
 They are m

Re: [Openocd-development] My source [find target, interface etc.] lines in my .cfg files don't work with latest build

On Tue, Jun 9, 2009 at 5:26 PM, Brian Hutchinson wrote:

> I searched and saw the thread on find tcl/target etc. from a week ago but
> can't figure out what is going on.  Do we not use source [find
> interface/jtagkey.cfg] type lines in our configs anymore?
>
> I guess I've missed something ... tough to be on vacation and come back to
> a full inbox :)
>
> Regards,
>
> Brian
>

I usually start openocd with a line like:
openocd -c "fast enable" -f board/my_board.cfg -c "init"

With SVN 2177, it complained that it couldn't find my_board.cfg.

I took the "board" out and tried to launch with just:
openocd -c "fast enable" -f my_board.cfg -c "init"

... and then it complained about my first source [find target/ ... ] line.

Searched the list and the only thing that smelled like what I was seeing
was:
http://www.mail-archive.com/openocd-development@lists.berlios.de/msg05321.html

I'm using custom .cfg files that were already in my /usr/loca/lib/openocd
tree.

Hope that sheds more light I what I'm talking about since the first post was
knee-jerk.

Regards,

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

Re: [Openocd-development] unable to open ftdi device

There is a udev rule file in the contrib folder.  It's been a while  
since I've messed with Linux device nodes, but I believe the device  
will show up in /sys but udev needs to create the /dev node.

--
Rick Altherr
kc8...@kc8apf.net

"He said he hadn't had a byte in three days. I had a short, so I split  
it with him."

 -- Unsigned



On Jun 9, 2009, at 2:32 PM, Paul J THACKER wrote:


Hi,

Openocd-0.1.0 on OpenSUSE 11.0 with Amontec jtagkey-tiny:

thack...@cea05:~/cartesio/eclipse/trunk> openocd -f jtagkey-tiny.cfg
Open On-Chip Debugger 0.1.0 (2009-05-21-09:56) Release


BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS


$URL:
https://kc8...@svn.berlios.de/svnroot/repos/openocd/tags/openocd-0.1.0/src/openocd.c
$
Error: unable to open ftdi device: 18
initialise_usb failed
Error: ListDevices: NONE

Runtime error, file "command.c", line 456:

Trace and debug outputs:

open("jtagkey-tiny.cfg", O_RDONLY)  = 3
close(3)= 0
open("jtagkey-tiny.cfg", O_RDONLY)  = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb8092000
read(3, "#interface\ninterface ft2232\nft22"..., 4096) = 118
read(3, "", 4096)   = 0
read(3, "", 4096)   = 0
close(3)= 0
munmap(0xb8092000, 4096)= 0
gettimeofday({1244582536, 328068}, NULL) = 0
gettimeofday({1244582536, 328114}, NULL) = 0
gettimeofday({1244582536, 329023}, NULL) = 0
gettimeofday({1244582536, 329079}, NULL) = 0
gettimeofday({1244582536, 329212}, NULL) = 0
gettimeofday({1244582536, 329255}, NULL) = 0
gettimeofday({1244582536, 329362}, NULL) = 0
gettimeofday({1244582536, 329404}, NULL) = 0
gettimeofday({1244582536, 329534}, NULL) = 0
gettimeofday({1244582536, 329577}, NULL) = 0
open("/proc/sys/kernel/osrelease", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb8092000
read(3, "2.6.25.18-0.2-pae\n", 1024)= 18
read(3, "", 1024)   = 0
close(3)= 0
munmap(0xb8092000, 4096)= 0
open("/proc/bus/usb",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x8) = 3
fstat64(3, {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
fcntl64(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
getdents64(3, /* 2 entries */, 1024)= 48
getdents64(3, /* 0 entries */, 1024)= 0
close(3)= 0
open("/dev/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY| 
0x8) =

-1 ENOENT (No such file or directory)
write(2, "Error: unable to open ftdi devic"..., 38Error: unable to  
open

ftdi device: 18
) = 38
open("/proc/bus/usb",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x8) = 3
fstat64(3, {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
getdents64(3, /* 2 entries */, 1024)= 48
getdents64(3, /* 0 entries */, 1024)= 0
close(3)= 0
open("/dev/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY| 
0x8) =

-1 ENOENT (No such file or directory)
fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 6), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb8092000
write(1, "initialise_usb failed\n", 22initialise_usb failed
) = 22
write(2, "Error: ListDevices: NONE\n\n", 26Error: ListDevices: NONE

) = 26
write(2, "Runtime error, file \"command.c\","..., 47Runtime error,  
file

"command.c", line 456:
) = 47
exit_group(1)

cea05:/home/thackerp/cartesio/eclipse/trunk # openocd -d 3 -f
jtagkey-tiny.cfg
Open On-Chip Debugger 0.1.0 (2009-05-21-09:56) Release


BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS


$URL:
https://kc8...@svn.berlios.de/svnroot/repos/openocd/tags/openocd-0.1.0/src/openocd.c
$
User : 5 0 command.c:494 command_run_line():
Debug: 6 0 configuration.c:88 find_file(): found jtagkey-tiny.cfg
Debug: 8 0 command.c:91 script_command(): script_command - interface
Debug: 9 0 command.c:108 script_command(): script_command - interface,
argv[0]=ocd_interface
Debug: 10 0 command.c:108 script_command(): script_command -  
interface,

argv[1]=ft2232
Debug: 12 0 command.c:91 script_command(): script_command -
ft2232_device_desc
Debug: 13 0 command.c:108 script_command(): script_command -
ft2232_device_desc, argv[0]=ocd_ft2232_device_desc
Debug: 14 0 command.c:108 script_command(): script_command -
ft2232_device_desc, argv[1]=Amontec JTAGkey A
Debug: 16 0 command.c:91 script_command(): script_command -  
ft2232_layout

Debug: 17 0 command.c:108 script_command(): script_command -
ft2232_layout, argv[0]=ocd_ft2232_layout
Debug: 18 0 command.c:108 script_command(): script_command -
ft2232_layout, argv[1]=jtagkey
Debug: 20 0 command.c:91 script_command(): script_command -  
ft2232_vid_pid

Debug: 21 0 command.c:108 script_command(): script_command -
ft2232_vid_pid, argv[0]=ocd_ft2232_vid_pid
Debug: 22 0

Re: [Openocd-development] unable to open ftdi device

2009-06-09 Thread Paul Thomas

Paul,

With my ft2232 device it shows up as /dev/usbdevX.Y_epZ. Did you build
openocd with libftdi and/or ftd2xx support? Is libftdi or ftd2xx installed
on your system?

thanks,
Paul

On Tue, Jun 9, 2009 at 2:32 PM, Paul J THACKER  wrote:

> Hi,
>
> Openocd-0.1.0 on OpenSUSE 11.0 with Amontec jtagkey-tiny:
>
> thack...@cea05:~/cartesio/eclipse/trunk> openocd -f jtagkey-tiny.cfg
> Open On-Chip Debugger 0.1.0 (2009-05-21-09:56) Release
>
>
> BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
>
>
> $URL:
> https://kc8apf@
> svn.berlios.de/svnroot/repos/openocd/tags/openocd-0.1.0/src/openocd.c
> $
> Error: unable to open ftdi device: 18
> initialise_usb failed
> Error: ListDevices: NONE
>
> Runtime error, file "command.c", line 456:
>
> Trace and debug outputs:
>
> open("jtagkey-tiny.cfg", O_RDONLY)  = 3
> close(3)= 0
> open("jtagkey-tiny.cfg", O_RDONLY)  = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb8092000
> read(3, "#interface\ninterface ft2232\nft22"..., 4096) = 118
> read(3, "", 4096)   = 0
> read(3, "", 4096)   = 0
> close(3)= 0
> munmap(0xb8092000, 4096)= 0
> gettimeofday({1244582536, 328068}, NULL) = 0
> gettimeofday({1244582536, 328114}, NULL) = 0
> gettimeofday({1244582536, 329023}, NULL) = 0
> gettimeofday({1244582536, 329079}, NULL) = 0
> gettimeofday({1244582536, 329212}, NULL) = 0
> gettimeofday({1244582536, 329255}, NULL) = 0
> gettimeofday({1244582536, 329362}, NULL) = 0
> gettimeofday({1244582536, 329404}, NULL) = 0
> gettimeofday({1244582536, 329534}, NULL) = 0
> gettimeofday({1244582536, 329577}, NULL) = 0
> open("/proc/sys/kernel/osrelease", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb8092000
> read(3, "2.6.25.18-0.2-pae\n", 1024)= 18
> read(3, "", 1024)   = 0
> close(3)= 0
> munmap(0xb8092000, 4096)= 0
> open("/proc/bus/usb",
> O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x8) = 3
> fstat64(3, {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
> fcntl64(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
> getdents64(3, /* 2 entries */, 1024)= 48
> getdents64(3, /* 0 entries */, 1024)= 0
> close(3)= 0
> open("/dev/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x8) =
> -1 ENOENT (No such file or directory)
> write(2, "Error: unable to open ftdi devic"..., 38Error: unable to open
> ftdi device: 18
> ) = 38
> open("/proc/bus/usb",
> O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x8) = 3
> fstat64(3, {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
> getdents64(3, /* 2 entries */, 1024)= 48
> getdents64(3, /* 0 entries */, 1024)= 0
> close(3)= 0
> open("/dev/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x8) =
> -1 ENOENT (No such file or directory)
> fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 6), ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb8092000
> write(1, "initialise_usb failed\n", 22initialise_usb failed
> ) = 22
> write(2, "Error: ListDevices: NONE\n\n", 26Error: ListDevices: NONE
>
> ) = 26
> write(2, "Runtime error, file \"command.c\","..., 47Runtime error, file
> "command.c", line 456:
> ) = 47
> exit_group(1)
>
> cea05:/home/thackerp/cartesio/eclipse/trunk # openocd -d 3 -f
> jtagkey-tiny.cfg
> Open On-Chip Debugger 0.1.0 (2009-05-21-09:56) Release
>
>
> BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
>
>
> $URL:
> https://kc8apf@
> svn.berlios.de/svnroot/repos/openocd/tags/openocd-0.1.0/src/openocd.c
> $
> User : 5 0 command.c:494 command_run_line():
> Debug: 6 0 configuration.c:88 find_file(): found jtagkey-tiny.cfg
> Debug: 8 0 command.c:91 script_command(): script_command - interface
> Debug: 9 0 command.c:108 script_command(): script_command - interface,
> argv[0]=ocd_interface
> Debug: 10 0 command.c:108 script_command(): script_command - interface,
> argv[1]=ft2232
> Debug: 12 0 command.c:91 script_command(): script_command -
> ft2232_device_desc
> Debug: 13 0 command.c:108 script_command(): script_command -
> ft2232_device_desc, argv[0]=ocd_ft2232_device_desc
> Debug: 14 0 command.c:108 script_command(): script_command -
> ft2232_device_desc, argv[1]=Amontec JTAGkey A
> Debug: 16 0 command.c:91 script_command(): script_command - ft2232_layout
> Debug: 17 0 command.c:108 script_command(): script_command -
> ft2232_layout, argv[0]=ocd_ft2232_layout
> Debug: 18 0 command.c:108 script_command(): script_command -
> ft2232_layout, argv[1]=jtagkey
> Debug: 20 0 command.c:91 script_command(): script_command - ft2232_vid_pid
> Debug: 21 0 command.c:108 script_command(): script_command -
> ft223

[Openocd-development] unable to open ftdi device

Hi,

Openocd-0.1.0 on OpenSUSE 11.0 with Amontec jtagkey-tiny:

thack...@cea05:~/cartesio/eclipse/trunk> openocd -f jtagkey-tiny.cfg
Open On-Chip Debugger 0.1.0 (2009-05-21-09:56) Release


BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS


$URL: 
https://kc8...@svn.berlios.de/svnroot/repos/openocd/tags/openocd-0.1.0/src/openocd.c
 
$
Error: unable to open ftdi device: 18
initialise_usb failed
Error: ListDevices: NONE

Runtime error, file "command.c", line 456:

Trace and debug outputs:

open("jtagkey-tiny.cfg", O_RDONLY)  = 3
close(3)= 0
open("jtagkey-tiny.cfg", O_RDONLY)  = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0xb8092000
read(3, "#interface\ninterface ft2232\nft22"..., 4096) = 118
read(3, "", 4096)   = 0
read(3, "", 4096)   = 0
close(3)= 0
munmap(0xb8092000, 4096)= 0
gettimeofday({1244582536, 328068}, NULL) = 0
gettimeofday({1244582536, 328114}, NULL) = 0
gettimeofday({1244582536, 329023}, NULL) = 0
gettimeofday({1244582536, 329079}, NULL) = 0
gettimeofday({1244582536, 329212}, NULL) = 0
gettimeofday({1244582536, 329255}, NULL) = 0
gettimeofday({1244582536, 329362}, NULL) = 0
gettimeofday({1244582536, 329404}, NULL) = 0
gettimeofday({1244582536, 329534}, NULL) = 0
gettimeofday({1244582536, 329577}, NULL) = 0
open("/proc/sys/kernel/osrelease", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0xb8092000
read(3, "2.6.25.18-0.2-pae\n", 1024)= 18
read(3, "", 1024)   = 0
close(3)= 0
munmap(0xb8092000, 4096)= 0
open("/proc/bus/usb", 
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x8) = 3
fstat64(3, {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
fcntl64(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
getdents64(3, /* 2 entries */, 1024)= 48
getdents64(3, /* 0 entries */, 1024)= 0
close(3)= 0
open("/dev/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x8) = 
-1 ENOENT (No such file or directory)
write(2, "Error: unable to open ftdi devic"..., 38Error: unable to open 
ftdi device: 18
) = 38
open("/proc/bus/usb", 
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x8) = 3
fstat64(3, {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
getdents64(3, /* 2 entries */, 1024)= 48
getdents64(3, /* 0 entries */, 1024)= 0
close(3)= 0
open("/dev/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x8) = 
-1 ENOENT (No such file or directory)
fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 6), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0xb8092000
write(1, "initialise_usb failed\n", 22initialise_usb failed
) = 22
write(2, "Error: ListDevices: NONE\n\n", 26Error: ListDevices: NONE

) = 26
write(2, "Runtime error, file \"command.c\","..., 47Runtime error, file 
"command.c", line 456:
 ) = 47
exit_group(1)

cea05:/home/thackerp/cartesio/eclipse/trunk # openocd -d 3 -f 
jtagkey-tiny.cfg
Open On-Chip Debugger 0.1.0 (2009-05-21-09:56) Release


BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS


$URL: 
https://kc8...@svn.berlios.de/svnroot/repos/openocd/tags/openocd-0.1.0/src/openocd.c
 
$
User : 5 0 command.c:494 command_run_line():
Debug: 6 0 configuration.c:88 find_file(): found jtagkey-tiny.cfg
Debug: 8 0 command.c:91 script_command(): script_command - interface
Debug: 9 0 command.c:108 script_command(): script_command - interface, 
argv[0]=ocd_interface
Debug: 10 0 command.c:108 script_command(): script_command - interface, 
argv[1]=ft2232
Debug: 12 0 command.c:91 script_command(): script_command - 
ft2232_device_desc
Debug: 13 0 command.c:108 script_command(): script_command - 
ft2232_device_desc, argv[0]=ocd_ft2232_device_desc
Debug: 14 0 command.c:108 script_command(): script_command - 
ft2232_device_desc, argv[1]=Amontec JTAGkey A
Debug: 16 0 command.c:91 script_command(): script_command - ft2232_layout
Debug: 17 0 command.c:108 script_command(): script_command - 
ft2232_layout, argv[0]=ocd_ft2232_layout
Debug: 18 0 command.c:108 script_command(): script_command - 
ft2232_layout, argv[1]=jtagkey
Debug: 20 0 command.c:91 script_command(): script_command - ft2232_vid_pid
Debug: 21 0 command.c:108 script_command(): script_command - 
ft2232_vid_pid, argv[0]=ocd_ft2232_vid_pid
Debug: 22 0 command.c:108 script_command(): script_command - 
ft2232_vid_pid, argv[1]=0x0403
Debug: 23 0 command.c:108 script_command(): script_command - 
ft2232_vid_pid, argv[2]=0xcff8
User : 24 0 command.c:494 command_run_line():
Debug: 26 0 command.c:91 script_command(): script_command - init
Debug: 27 0 command.c:108 script_command(): script_command - init, 
argv[0]=ocd_init
Debug: 28 0 openoc

[Openocd-development] My source [find target, interface etc.] lines in my .cfg files don't work with latest build

I searched and saw the thread on find tcl/target etc. from a week ago but
can't figure out what is going on.  Do we not use source [find
interface/jtagkey.cfg] type lines in our configs anymore?

I guess I've missed something ... tough to be on vacation and come back to a
full inbox :)

Regards,

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

Re: [Openocd-development] Idea on dr/irscan command handling

Having thought of the problem with asynchronous stuff like
DCC feedback, I'm now leaning towards defining a macro
that wraps dr/irscan sequences with poll off/on.


I'm thinking that the entire reset procedure should be w/polling off too.

-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Problems with svn eol line endings and Cygwin when using Windows svn client







Don't know about this one though:

./tools/uncrustify1.sh


Whose file is that?


Dunno.


Based on 'svn log', it looks like Rick's contribution.  I am not a fan
of automated cleanup tools (other than sed), so I am unlikely to try  
it.

"Machines that can know good style...  that'll be the day"** ;)

Cheers,

Zach

P.S. This is a sentiment that I would love to rue, but I know that the
technology is not there yet.  If we were, we would not be coding in C.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development



That file was actually from Dick.  It runs uncrustify with the config  
file that is also part of the tree.  In my experimentation, it looks  
like uncrustify will handle all pure-syntax style rules assuming  
someone spends enough time setting the hundreds of options in the  
config.  Dick had made the initial config which does most of the  
syntax rules.


--
Rick Altherr
kc8...@kc8apf.net

"He said he hadn't had a byte in three days. I had a short, so I split  
it with him."

 -- Unsigned




smime.p7s
Description: S/MIME cryptographic signature
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Idea on dr/irscan command handling

On Tuesday 09 June 2009, Øyvind Harboe wrote:
> > And the only event of interest seems to be transitioning
> > from a "running" or "debug-running" state ... to something
> > else.  With the only listeners being the TCL shell, or in
> > some cases GDB (when a breakpoint or watchpoint fires).
> 
> There are other events:
> 
> - the target can send messages via DCC
> - power outage(which drivers can detect if they support it)
> - srst assert/deassert detection. srst can be asserted by
>   other devices than JTAG, e.g. the CPU itself.

Good info.  I'll supply a doc update to highlight and explain
this polling activity ... I think I have good answers for my
questions now.  :)

Same update will make "poll" output say if the periodic polling
is active.

There are also various JTAG connector standards which support
GPIO-ish event channels (potentially bidirectional).  Atmel's
Nexus connectors include event in and out signals.  TI uses
EMU0 and EMU1 ... and on some connectors I think EMU2..EMU5.
And I think I've seen this on other hardware too.

Sometimes that seems to be called "instrumentation support",
with some of the signals used to flag e.g. "trace buffer has
overflowed" or whatever else might merit immediate debugger
attention.

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

[Openocd-development] Numonyx Flash support?

I have a board with Numonyx 256M NOR (PC28F256M29).  The version of OpenOCD
I'm currently running (1470M) can query, probe, flash info etc., but can't
program it for some reason.

Has anyone used Numonyx flash with OpenOCD yet?  Just wondering if support
has been added up stream from me or if I need to dig into the problem and
add support for this flash.

Thanks,

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

Re: [Openocd-development] Idea on dr/irscan command handling

> And the only event of interest seems to be transitioning
> from a "running" or "debug-running" state ... to something
> else.  With the only listeners being the TCL shell, or in
> some cases GDB (when a breakpoint or watchpoint fires).

There are other events:

- the target can send messages via DCC
- power outage(which drivers can detect if they support it)
- srst assert/deassert detection. srst can be asserted by
other devices than JTAG, e.g. the CPU itself.


-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Jlink not running under cygwin [Working now]

Gene Smith wrote:
> I now get a successful build under cygwin. When I plug the jlink usb to 
> windows and run openocd I see the the "Cannot find jlink Interface!" 
> error as printed below. Do I need another special windows driver when 
> running jlink in cygwin? To build I only copied usb.h and libusb.a as 
> directed from libusb-win32 project. There is quite a bit of stuff in the 
> libusb-win32-device-bin.tar.gz that I haven't used. Should this be 
> installed?
> 
Yes.

I had the segger jlink commander installed so its driver ran when I 
plugged in the jlink and didn't work with openocd. I had to replace it 
with the driver from libusb-win32-device-bin on sourceforge. (A "no 
driver found dialog" would have popped up if I didn't have segger 
installed already, I think.) Uninstalling segger jlink tools did not 
remove the segger driver. Had to go into Control Panel/System/Device 
Manager and update the jlink driver to point at the new jlink.inf file I 
had made with the libusb-win32/bin inf-wizard. Then I browsed to the 
actual unsigned driver pointed to by the inf, libusb0.dll from the 
libusb-win32-device-bin distribution to complete the installation. I did 
not try to use the "filter" driver which I think can coexist with the 
segger driver (according to a post by Xiaofan which seems to be the only 
mention of whether this 3rd party driver is really needed by openocd).

Note: the segger driver appeared under "Universal Serial Bus 
Controllers" in Device Manager (winXP) while the libusb-win32 driver 
appears as new top level Dev Mgr category "LibUSB-Win32 Devices".

-gene

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

Re: [Openocd-development] Idea on dr/irscan command handling

On Tuesday 09 June 2009, Øyvind Harboe wrote:
> On Tue, Jun 9, 2009 at 7:37 PM, David Brownell wrote:
> > On Tuesday 09 June 2009, Ųyvind Harboe wrote:
> >> - make all reset event scripts run with background
> >>   events disabled.
> >
> > Surprises me that's not already the case...
> >
> > Note that output of "poll" doesn't say whether the timer
> > thing is active.  So it's pretty much hidden.
> >
> > Also, that the documentation doesn't mention *why* this
> > background activity might be desired.  Is there a better
> > reason than "that's how it's always been done"?
> 
> An example of why this was done in the past is that when
> you type "resume", you want to get a message when the
> target halts. So when the command line is in idle, you poll.

Makes sense.


> However, I've given some thought to when polling should
> be active and perhaps we have gotten it wrong and
> *no* polling should be done.
> 
> Instead we could define that a telnet session that shows
> a prompt is *NOT* idle, but rather that a telnet prompt waiting
> for input is polling the *active* target.
> 
> So during execution of a command or when the telnet
> is closed and only gdb is running, there is no background
> polling.

That's what I would expect.  Only poll if the event could
happen, and there's a listener that cares about it.

And the only event of interest seems to be transitioning
from a "running" or "debug-running" state ... to something
else.  With the only listeners being the TCL shell, or in
some cases GDB (when a breakpoint or watchpoint fires).

 
> I'm not a great fan of numerous handlers that listens
> for events(control inversion) and invokes fn's that somehow
> have to figure out if it is time to do something or other...

Sometimes async/event-driven code is required.  I have a
similar aversion to code that tries to model async realities
in synchronous terms.  ;)

In this case there's true concurrency except when all the
targets are halted.  

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

Re: [Openocd-development] Idea on dr/irscan command handling

On Tue, Jun 9, 2009 at 7:37 PM, David Brownell wrote:
> On Tuesday 09 June 2009, Ųyvind Harboe wrote:
>> - make all reset event scripts run with background
>>   events disabled.
>
> Surprises me that's not already the case...
>
> Note that output of "poll" doesn't say whether the timer
> thing is active.  So it's pretty much hidden.
>
> Also, that the documentation doesn't mention *why* this
> background activity might be desired.  Is there a better
> reason than "that's how it's always been done"?

An example of why this was done in the past is that when
you type "resume", you want to get a message when the
target halts. So when the command line is in idle, you poll.

However, I've given some thought to when polling should
be active and perhaps we have gotten it wrong and
*no* polling should be done.

Instead we could define that a telnet session that shows
a prompt is *NOT* idle, but rather that a telnet prompt waiting
for input is polling the *active* target.

So during execution of a command or when the telnet
is closed and only gdb is running, there is no background
polling.

I'm not a great fan of numerous handlers that listens
for events(control inversion) and invokes fn's that somehow
have to figure out if it is time to do something or other...

-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Idea on dr/irscan command handling

2009-06-09 Thread Magnus Lundin

Øyvind Harboe wrote:
> Q: should dr/irscan throw an error if polling is enabled?
>
> OpenOCD does background polling based on a timer, so
> two consecutive ir/drscan commands could see other
> JTAG operations intervening, wreaking havoc.
>
> Targets such as the OMAP needs to run a sequence
> of jtag commands uninterrupted.
>
> Some ideas:
>
> - implementations must start such sequences by poll off
> and end them with poll on. Ugly, but supported today.
> - define a wrapper tcl proc that handles reading the
> current polling state, turning off polling, executing
> a sequence of commands and then restoring the
> polling status regardless of whether an exception was
> thrown or not. Writing such a wrapper is easy.
> - make all reset event scripts run with background
> events disabled.
>
>
>
>
>
> The ir/drscan also lacks the ability to return the data clocked in, it
> does not support longer than 32 bits scans, and there is no
> statemove/pathmove command + a raft of other shortcomings
> of these commands, but that's really an independant issue.
>
>
>   
I do not think this is so bad really:

The type of target/tap initialisation that needs dr/ir scans to setup 
the jtag chain and controller are run before  the  target can be 
examined. The type of target initialisations that sets memory mapped 
registers with mww are not affected by polling-

Polls, and many other commands,  are not sent to targets that has not 
been examined. So the initial dr/ir scans are not interrupted.

If we want to do manual dr/ir scans after the target has been setup, 
initialised and examined, the it is reasonable that we have to use poll off.

So what I think we need is a delayed target examination, something like 
when defining a target we set a flag  -delay_examine to signal that more 
setup must be done before the targtet can be examined  with  arp_examine.

My två öre,
regards
Magnus

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

Re: [Openocd-development] Idea on dr/irscan command handling

On Tuesday 09 June 2009, Øyvind Harboe wrote:
> - make all reset event scripts run with background
>   events disabled.

Surprises me that's not already the case...

Note that output of "poll" doesn't say whether the timer
thing is active.  So it's pretty much hidden.

Also, that the documentation doesn't mention *why* this
background activity might be desired.  Is there a better
reason than "that's how it's always been done"?
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] Idea on dr/irscan command handling

Q: should dr/irscan throw an error if polling is enabled?

OpenOCD does background polling based on a timer, so
two consecutive ir/drscan commands could see other
JTAG operations intervening, wreaking havoc.

Targets such as the OMAP needs to run a sequence
of jtag commands uninterrupted.

Some ideas:

- implementations must start such sequences by poll off
and end them with poll on. Ugly, but supported today.
- define a wrapper tcl proc that handles reading the
current polling state, turning off polling, executing
a sequence of commands and then restoring the
polling status regardless of whether an exception was
thrown or not. Writing such a wrapper is easy.
- make all reset event scripts run with background
events disabled.





The ir/drscan also lacks the ability to return the data clocked in, it
does not support longer than 32 bits scans, and there is no
statemove/pathmove command + a raft of other shortcomings
of these commands, but that's really an independant issue.


-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] cygwin libtool: s/ECHO=/echo=/

Zach Welch wrote:
> On Tue, 2009-06-09 at 11:05 -0400, Gene Smith wrote:
>> Zach Welch wrote:
>>> On Tue, 2009-06-09 at 09:58 -0400, Gene Smith wrote:
 I think most of the problem I discovered building under cygwin have been 
 addressed today. However, I still have the problem with trunk/libtool 
 needing to be modified manually to change ECHO= to echo=.  Seems to be 
 OK in linux. It appears to be a mismatch between the libtool version on 
 my linux (fedora8) which is 1.x compared to cygwin which is 2.x.  Or is 
 this just a user error on my part?
>>> This may be a mismatch, but I do not think it matters.  I am testing
>>> with 1.5.x here, which I think is the most commonly deployed version.
>>> However, I just tested on Ubuntu Jaunty, which has libtool 2.2.6.
>>>
 I did notice that trunk/ltmain.sh is removed when you do a distclean and 
 never comes back. I got it back but it didn't make a difference. Even 
 moved it to the one in /cygwin/usr/share/libtool/config and it still 
 produces a bad libtool file under trunk/
>>> Does the output of the following commands match?
>>>
>>> libtool --version
>>> ./libtool --version
>> Not on cygwin (printed below) but they do on linux f8.
>>
>> $ libtool --version
>> libtool (GNU libtool 1.3081 2009-02-17) 2.2.7a
>> Written by Gordon Matzigkeit , 1996
>>
>> Copyright (C) 2009 Free Software Foundation, Inc.
>>
>>
>> $ ./libtool --version
>> ltmain.sh (GNU libtool) 1.5.24 (1.1220.2.456 2007/06/24 02:25:32)
>>
>> Copyright (C) 2007  Free Software Foundation, Inc.
>>
>>
>>> The following link seems to be related, doesn't it?
>>>
>>>   https://bugs.launchpad.net/ubuntu/+source/libtool/+bug/285841
>> I also found quite a few references to this error but the only one I 
>> could find that actually told what to do was the one that said ECHO 
>> (upper case) was the problem. I will look more in details at this ubuntu 
>> bug and see if they point to a solution.
> 
> The link I provided suggests exactly what you are seeing; you somehow
> have mismatched versions of libtool, with the in-tree version being from
> 2007 and the installed version being from 2009.  I am not sure what
> caused it or how to fix it exactly (rm ./libtool? and rebootstrap), but
> I am willing to bet that this is the problem.

I notice it always writes a new ./libtool at the end of configure. I 
have not tried to delete it before bootstraping...

OK, I just when though this procedure:

cd trunk
rm ./libtool
./bootstrap
./configure --enable-maintainer-mode ...
make

This is different; when I do make it sees nothing to update. Before it 
always saw all files as out of date!

When I do a
make clean all

I see the usual error that fails due to ECHO. When I change ECHO= to 
echo= in the new ./libtool the build occurs with no errors.


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

[Openocd-development] Jlink not running under cygwin

I now get a successful build under cygwin. When I plug the jlink usb to 
windows and run openocd I see the the "Cannot find jlink Interface!" 
error as printed below. Do I need another special windows driver when 
running jlink in cygwin? To build I only copied usb.h and libusb.a as 
directed from libusb-win32 project. There is quite a bit of stuff in the 
libusb-win32-device-bin.tar.gz that I haven't used. Should this be 
installed?

$ src/openocd.exe  -d 3 -s ./tcl -f interface/jlink.cfg 
board/stm3210e_eval.cfg
Open On-Chip Debugger 0.2.0-in-development (2009-06-09-11:02) svn:2177M


BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS


$URL: svn://localhost:36903/openocd/trunk/src/openocd.c $
Debug: 5 0 configuration.c:83 find_file(): found ./tcl/interface/jlink.cfg
Debug: 7 0 command.c:88 script_command(): script_command - interface
Debug: 8 0 command.c:105 script_command(): script_command - interface, 
argv[0]=ocd_interface
Debug: 9 0 command.c:105 script_command(): script_command - interface, 
argv[1]=jlink
Debug: 11 15 command.c:88 script_command(): script_command - init
Debug: 12 15 command.c:105 script_command(): script_command - init, 
argv[0]=ocd_init
Debug: 13 15 openocd.c:129 handle_init_command(): target init complete
Error: 14 15 jlink.c:315 jlink_init(): Cannot find jlink Interface! 
Please check connection and permissions.
Debug: 15 15 command.c:424 run_command(): Command failed with error code 
-100
User : 16 15 command.c:626 openocd_jim_vfprintf(): Runtime error, file 
"command.c", line 453:
 User : 17 15 command.c:626 openocd_jim_vfprintf():

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

Re: [Openocd-development] cygwin libtool: s/ECHO=/echo=/

On Tue, 2009-06-09 at 11:05 -0400, Gene Smith wrote:
> Zach Welch wrote:
> > On Tue, 2009-06-09 at 09:58 -0400, Gene Smith wrote:
> >> I think most of the problem I discovered building under cygwin have been 
> >> addressed today. However, I still have the problem with trunk/libtool 
> >> needing to be modified manually to change ECHO= to echo=.  Seems to be 
> >> OK in linux. It appears to be a mismatch between the libtool version on 
> >> my linux (fedora8) which is 1.x compared to cygwin which is 2.x.  Or is 
> >> this just a user error on my part?
> > 
> > This may be a mismatch, but I do not think it matters.  I am testing
> > with 1.5.x here, which I think is the most commonly deployed version.
> > However, I just tested on Ubuntu Jaunty, which has libtool 2.2.6.
> > 
> >> I did notice that trunk/ltmain.sh is removed when you do a distclean and 
> >> never comes back. I got it back but it didn't make a difference. Even 
> >> moved it to the one in /cygwin/usr/share/libtool/config and it still 
> >> produces a bad libtool file under trunk/
> > 
> > Does the output of the following commands match?
> > 
> > libtool --version
> > ./libtool --version
> 
> Not on cygwin (printed below) but they do on linux f8.
> 
> $ libtool --version
> libtool (GNU libtool 1.3081 2009-02-17) 2.2.7a
> Written by Gordon Matzigkeit , 1996
> 
> Copyright (C) 2009 Free Software Foundation, Inc.
> 
> 
> $ ./libtool --version
> ltmain.sh (GNU libtool) 1.5.24 (1.1220.2.456 2007/06/24 02:25:32)
> 
> Copyright (C) 2007  Free Software Foundation, Inc.
> 
> 
> > 
> > The following link seems to be related, doesn't it?
> > 
> >   https://bugs.launchpad.net/ubuntu/+source/libtool/+bug/285841
> 
> I also found quite a few references to this error but the only one I 
> could find that actually told what to do was the one that said ECHO 
> (upper case) was the problem. I will look more in details at this ubuntu 
> bug and see if they point to a solution.

The link I provided suggests exactly what you are seeing; you somehow
have mismatched versions of libtool, with the in-tree version being from
2007 and the installed version being from 2009.  I am not sure what
caused it or how to fix it exactly (rm ./libtool? and rebootstrap), but
I am willing to bet that this is the problem.

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

Re: [Openocd-development] cygwin libtool: s/ECHO=/echo=/

Zach Welch wrote:
> On Tue, 2009-06-09 at 09:58 -0400, Gene Smith wrote:
>> I think most of the problem I discovered building under cygwin have been 
>> addressed today. However, I still have the problem with trunk/libtool 
>> needing to be modified manually to change ECHO= to echo=.  Seems to be 
>> OK in linux. It appears to be a mismatch between the libtool version on 
>> my linux (fedora8) which is 1.x compared to cygwin which is 2.x.  Or is 
>> this just a user error on my part?
> 
> This may be a mismatch, but I do not think it matters.  I am testing
> with 1.5.x here, which I think is the most commonly deployed version.
> However, I just tested on Ubuntu Jaunty, which has libtool 2.2.6.
> 
>> I did notice that trunk/ltmain.sh is removed when you do a distclean and 
>> never comes back. I got it back but it didn't make a difference. Even 
>> moved it to the one in /cygwin/usr/share/libtool/config and it still 
>> produces a bad libtool file under trunk/
> 
> Does the output of the following commands match?
> 
> libtool --version
> ./libtool --version

Not on cygwin (printed below) but they do on linux f8.

$ libtool --version
libtool (GNU libtool 1.3081 2009-02-17) 2.2.7a
Written by Gordon Matzigkeit , 1996

Copyright (C) 2009 Free Software Foundation, Inc.


$ ./libtool --version
ltmain.sh (GNU libtool) 1.5.24 (1.1220.2.456 2007/06/24 02:25:32)

Copyright (C) 2007  Free Software Foundation, Inc.


> 
> The following link seems to be related, doesn't it?
> 
>   https://bugs.launchpad.net/ubuntu/+source/libtool/+bug/285841

I also found quite a few references to this error but the only one I 
could find that actually told what to do was the one that said ECHO 
(upper case) was the problem. I will look more in details at this ubuntu 
bug and see if they point to a solution.

> 
> Cheers,
> 
> Zach

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

Re: [Openocd-development] cygwin libtool: s/ECHO=/echo=/

On Tue, 2009-06-09 at 09:58 -0400, Gene Smith wrote:
> I think most of the problem I discovered building under cygwin have been 
> addressed today. However, I still have the problem with trunk/libtool 
> needing to be modified manually to change ECHO= to echo=.  Seems to be 
> OK in linux. It appears to be a mismatch between the libtool version on 
> my linux (fedora8) which is 1.x compared to cygwin which is 2.x.  Or is 
> this just a user error on my part?

This may be a mismatch, but I do not think it matters.  I am testing
with 1.5.x here, which I think is the most commonly deployed version.
However, I just tested on Ubuntu Jaunty, which has libtool 2.2.6.

> I did notice that trunk/ltmain.sh is removed when you do a distclean and 
> never comes back. I got it back but it didn't make a difference. Even 
> moved it to the one in /cygwin/usr/share/libtool/config and it still 
> produces a bad libtool file under trunk/

Does the output of the following commands match?

libtool --version
./libtool --version

The following link seems to be related, doesn't it?

  https://bugs.launchpad.net/ubuntu/+source/libtool/+bug/285841

Cheers,

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

[Openocd-development] cygwin libtool: s/ECHO=/echo=/

I think most of the problem I discovered building under cygwin have been 
addressed today. However, I still have the problem with trunk/libtool 
needing to be modified manually to change ECHO= to echo=.  Seems to be 
OK in linux. It appears to be a mismatch between the libtool version on 
my linux (fedora8) which is 1.x compared to cygwin which is 2.x.  Or is 
this just a user error on my part?

I did notice that trunk/ltmain.sh is removed when you do a distclean and 
never comes back. I got it back but it didn't make a difference. Even 
moved it to the one in /cygwin/usr/share/libtool/config and it still 
produces a bad libtool file under trunk/

-gene

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

Re: [Openocd-development] Problems with svn eol line endings and Cygwin when using Windows svn client

2009-06-09 Thread Michael Bruck

On Tue, Jun 9, 2009 at 1:19 PM, Zach Welch wrote:
> On Tue, 2009-06-09 at 12:29 +0200, Michael Bruck wrote:
>> IIRC I had to set
>>
>> SHELLOPTS=igncr
>>
>> globally to force cygwin bash to work with CRLF scripts. On the other
>> hand I suspect that option is what breaks the autotools generated
>> configure file for me. So I "correct" configure manually whenever it
>> is regenerated by replacing '\\r' (see full-text search) with $ac_cr.
>
> Can you provides some more details of your specific process?  Basically,
> what macro(s) create the output that you need to fix up?  We must be

No. It is a call to gawk, which causes the problem. The whole section
with the edit in it looks like this:


# Set up the scripts for CONFIG_FILES section.
# No need to generate them if there are no CONFIG_FILES.
# This happens for instance with `./config.status config.h'.
if test -n "$CONFIG_FILES"; then


ac_cr='
'
ac_cs_awk_cr=`$AWK 'BEGIN { print "a\rb" }' /dev/null`
if test "$ac_cs_awk_cr" = "a${ac_cr}b"; then
  ac_cs_awk_cr=$ac_cr
else
  ac_cs_awk_cr=$ac_cr
fi

echo 'BEGIN {' >"$tmp/subs1.awk" &&
_ACEOF


> missing something, because I do not recall this much pain in the past.

The problem has been there since I used cygwin for this (with igncr always set).

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

Re: [Openocd-development] Problems with svn eol line endings and Cygwin when using Windows svn client

On Tue, 2009-06-09 at 13:26 +0200, Øyvind Harboe wrote:
> BTW, I'm using Eclipse w/Subclipse and svnkit(java implementation
> of svn).
> 
> >> If you try to run a .sh file under Cygwin and that file has Windows
> >> line endings, it will fail w/a syntax error.
> >
> > Even with the bash igncr option?
> 
> My problem with that(on behalf of users) is that how the "#!¤&"#¤&"#
> will they know to set this option?

This is a good question, but I still want an answer to mine.  Does it
solve the problem?  Or is there still more going on here?

As far as a cure, I think there needs to be a README.Cygwin file that
provides step-by-step instructions for building on that platform.
Answers to questions like this need to be documented somewhere.

Cheers,

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

Re: [Openocd-development] make maintainer-clean is does not work when build != src dir

On Tue, 2009-06-09 at 12:39 +0200, Øyvind Harboe wrote:
> On Tue, Jun 9, 2009 at 12:24 PM, Zach Welch wrote:
> > On Tue, 2009-06-09 at 12:00 +0200, Øyvind Harboe wrote:
> >> I use a different build & openocd src dir, this means "make
> >> maintainer-clean" does not work...
> >>
> >> Is this old news?
> >>
> >> This is reproduceable under Linux as well as Cygwin.
> >>
> >> I tricked myself into believing that "make maintainer-clean" worked from
> >> the build directory at some point and confused that with the eol native
> >> line issues
> >
> > Whoops!  I will commit a patch that fixes this shortly.
> 
> Works fine now. Thanks!
> 
> My remaining concern is that "bootstrap" does not do a "make
> maintainer-clean"...

If you _always_ do a maintainer-clean _before_ merging changes that
touch the build system, then the clean building process you want to work
should work flawlessly (if there are no bugs).

I would even say that doing otherwise is a "user error".  Your mess. ;)

> I'd want/expect the following sequence to *always* work:
> 
> - svn update
> - boostrap
> - configure
> - make

Without a maintainer-clean first, this is impossible to guarantee.

Specifically, there is no way for the build system to know the version
or state of the old code version and how to clean it up.  That said, it
should work most of the time.  With --enable-maintainer-mode, you should
not even need to bother with the bootstrap and configure steps!  A
simple make is usually sufficient, and it will rebuild the required
Makefiles or other files when the autotools sources are changed.

If it doesn't, well, that's why I warn you to run maintainer-clean. :)
The first place to start debugging will be "starting from a fresh
checkout", which was what that preparatory command was meant to do.

Cheers,

Zach

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

Re: [Openocd-development] Problems with svn eol line endings and Cygwin when using Windows svn client

BTW, I'm using Eclipse w/Subclipse and svnkit(java implementation
of svn).

>> If you try to run a .sh file under Cygwin and that file has Windows
>> line endings, it will fail w/a syntax error.
>
> Even with the bash igncr option?

My problem with that(on behalf of users) is that how the "#!¤&"#¤&"#
will they know to set this option?


> Based on 'svn log', it looks like Rick's contribution.  I am not a fan
> of automated cleanup tools (other than sed), so I am unlikely to try it.
> "Machines that can know good style...  that'll be the day"** ;)

I have a superior answer to this problem, handle it at the presentation level:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=45423



-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Problems with svn eol line endings and Cygwin when using Windows svn client

On Tue, 2009-06-09 at 12:29 +0200, Michael Bruck wrote:
> IIRC I had to set
> 
> SHELLOPTS=igncr
> 
> globally to force cygwin bash to work with CRLF scripts. On the other
> hand I suspect that option is what breaks the autotools generated
> configure file for me. So I "correct" configure manually whenever it
> is regenerated by replacing '\\r' (see full-text search) with $ac_cr.

Can you provides some more details of your specific process?  Basically,
what macro(s) create the output that you need to fix up?  We must be
missing something, because I do not recall this much pain in the past.

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

Re: [Openocd-development] Problems with svn eol line endings and Cygwin when using Windows svn client

On Tue, 2009-06-09 at 13:07 +0200, Øyvind Harboe wrote:
> On Tue, Jun 9, 2009 at 1:02 PM, Zach Welch wrote:
> > On Tue, 2009-06-09 at 12:54 +0200, Øyvind Harboe wrote:
> >> > Some more information about the subject:
> >> >
> >> >  http://www.cygwin.com/ml/cygwin/2008-12/msg00525.html
> >> >
> >> > I particularly like the postscript. :)  We are not alone here.
> >>
> >> I'm just going to close my eyes and hope I never hear of this
> >> again :-)
> >
> > Not so fast.
> >
> > Can we reset the configure.in and Makefile.am svn:eol-style properties?
> > If these changes did not fix a problem, then I would like to see these
> > reverted to prevent future line-ending issues in these files.
> 
> Done. It was a red herring and I've set it back.

Thanks.

> >> I've grepped the source tree and "guess-rev.sh" was the .sh
> >> file that is used during normal builds that was broken.
> >
> > I am not sure what that means though.
> 
> If you try to run a .sh file under Cygwin and that file has Windows
> line endings, it will fail w/a syntax error.

Even with the bash igncr option?

> >> Don't know about this one though:
> >>
> >> ./tools/uncrustify1.sh
> >
> > Whose file is that?
> 
> Dunno.

Based on 'svn log', it looks like Rick's contribution.  I am not a fan
of automated cleanup tools (other than sed), so I am unlikely to try it.
"Machines that can know good style...  that'll be the day"** ;)

Cheers,

Zach

P.S. This is a sentiment that I would love to rue, but I know that the
technology is not there yet.  If we were, we would not be coding in C.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Problems with svn eol line endings and Cygwin when using Windows svn client

On Tue, Jun 9, 2009 at 1:02 PM, Zach Welch wrote:
> On Tue, 2009-06-09 at 12:54 +0200, Øyvind Harboe wrote:
>> > Some more information about the subject:
>> >
>> >  http://www.cygwin.com/ml/cygwin/2008-12/msg00525.html
>> >
>> > I particularly like the postscript. :)  We are not alone here.
>>
>> I'm just going to close my eyes and hope I never hear of this
>> again :-)
>
> Not so fast.
>
> Can we reset the configure.in and Makefile.am svn:eol-style properties?
> If these changes did not fix a problem, then I would like to see these
> reverted to prevent future line-ending issues in these files.

Done. It was a red herring and I've set it back.

>> I've grepped the source tree and "guess-rev.sh" was the .sh
>> file that is used during normal builds that was broken.
>
> I am not sure what that means though.

If you try to run a .sh file under Cygwin and that file has Windows
line endings, it will fail w/a syntax error.

>> Don't know about this one though:
>>
>> ./tools/uncrustify1.sh
>
> Whose file is that?

Dunno.



-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Problems with svn eol line endings and Cygwin when using Windows svn client

On Tue, 2009-06-09 at 12:54 +0200, Øyvind Harboe wrote:
> > Some more information about the subject:
> >
> >  http://www.cygwin.com/ml/cygwin/2008-12/msg00525.html
> >
> > I particularly like the postscript. :)  We are not alone here.
> 
> I'm just going to close my eyes and hope I never hear of this
> again :-)

Not so fast.

Can we reset the configure.in and Makefile.am svn:eol-style properties?
If these changes did not fix a problem, then I would like to see these
reverted to prevent future line-ending issues in these files.

> I've grepped the source tree and "guess-rev.sh" was the .sh
> file that is used during normal builds that was broken.

I am not sure what that means though.

> Don't know about this one though:
> 
> ./tools/uncrustify1.sh

Whose file is that?

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

Re: [Openocd-development] Problems with svn eol line endings and Cygwin when using Windows svn client

> Some more information about the subject:
>
>  http://www.cygwin.com/ml/cygwin/2008-12/msg00525.html
>
> I particularly like the postscript. :)  We are not alone here.

I'm just going to close my eyes and hope I never hear of this
again :-)

I've grepped the source tree and "guess-rev.sh" was the .sh
file that is used during normal builds that was broken.

Don't know about this one though:

./tools/uncrustify1.sh


-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Problems with svn eol line endings and Cygwin when using Windows svn client

On Tue, 2009-06-09 at 11:58 +0200, Øyvind Harboe wrote:
> I've had a bit of problems with Cygwin and svn eol native
> option.
> 
> I thought I understood what was going on and I went ahead and
> did some changes to svn head, but I have since discovered that
> I do *not* understand what's going on so svn head is a bit in
> limbo...
> 
> 1. "guess-rev.sh" was busted because Cygwin will fail to execute
> it when checked out with native. I ran dos2unix and removed the
> native option. It now works.
> 
> 2. I ran into problems with Makefile.am and configure.in not having
> Unix line endings and Cygwin failing to run "make maintainer-clean"
> deleting "ltmain.sh" and various other files.
> 
> I did some tests and it seemed that the problem "make maintainer-clean"
> problem was due to the svn native option and Cygwin getting confused.
> 
> "Great! I thought, I know how to fix that!" So I committed a fix to remove
> svn eol line endings for Makefile.am and configure.in.
> 
> Only it didn't fix the problem w/"make maintainer-clean"
> 
> So now I have a situation in Cygwin w/Eclipse/Windows svn client
> where:
> 
> - I don't know understand why ltmain.sh isn't removed during "make
> maintainer-clean"
> - I saw "ltmain.sh" being removed by "make maintainer-clean" but I
> don't know what I did to make that happen and I can't reproduce
> this behaviour under Cygwin.
> - Makefile.am and configure.in no longer has the svn native line endings
> under in svn head.
> - There is clear evidence that it is *wrong* to use svn eol native for
> .sh files but it is unclear what to do with other files that Cygwin
> reads...

Some more information about the subject:

  http://www.cygwin.com/ml/cygwin/2008-12/msg00525.html

I particularly like the postscript. :)  We are not alone here.

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

Re: [Openocd-development] make maintainer-clean is does not work when build != src dir

On Tue, Jun 9, 2009 at 12:24 PM, Zach Welch wrote:
> On Tue, 2009-06-09 at 12:00 +0200, Øyvind Harboe wrote:
>> I use a different build & openocd src dir, this means "make
>> maintainer-clean" does not work...
>>
>> Is this old news?
>>
>> This is reproduceable under Linux as well as Cygwin.
>>
>> I tricked myself into believing that "make maintainer-clean" worked from
>> the build directory at some point and confused that with the eol native
>> line issues
>
> Whoops!  I will commit a patch that fixes this shortly.

Works fine now. Thanks!

My remaining concern is that "bootstrap" does not do a "make
maintainer-clean"...

I'd want/expect the following sequence to *always* work:

- svn update
- boostrap
- configure
- make




-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Problems with svn eol line endings and Cygwin when using Windows svn client

2009-06-09 Thread Michael Bruck

IIRC I had to set

SHELLOPTS=igncr

globally to force cygwin bash to work with CRLF scripts. On the other
hand I suspect that option is what breaks the autotools generated
configure file for me. So I "correct" configure manually whenever it
is regenerated by replacing '\\r' (see full-text search) with $ac_cr.



Michael



On Tue, Jun 9, 2009 at 11:58 AM, Øyvind Harboe wrote:
> I've had a bit of problems with Cygwin and svn eol native
> option.
>
> I thought I understood what was going on and I went ahead and
> did some changes to svn head, but I have since discovered that
> I do *not* understand what's going on so svn head is a bit in
> limbo...
>
> 1. "guess-rev.sh" was busted because Cygwin will fail to execute
> it when checked out with native. I ran dos2unix and removed the
> native option. It now works.
>
> 2. I ran into problems with Makefile.am and configure.in not having
> Unix line endings and Cygwin failing to run "make maintainer-clean"
> deleting "ltmain.sh" and various other files.
>
> I did some tests and it seemed that the problem "make maintainer-clean"
> problem was due to the svn native option and Cygwin getting confused.
>
> "Great! I thought, I know how to fix that!" So I committed a fix to remove
> svn eol line endings for Makefile.am and configure.in.
>
> Only it didn't fix the problem w/"make maintainer-clean"
>
> So now I have a situation in Cygwin w/Eclipse/Windows svn client
> where:
>
> - I don't know understand why ltmain.sh isn't removed during "make
> maintainer-clean"
> - I saw "ltmain.sh" being removed by "make maintainer-clean" but I
> don't know what I did to make that happen and I can't reproduce
> this behaviour under Cygwin.
> - Makefile.am and configure.in no longer has the svn native line endings
> under in svn head.
> - There is clear evidence that it is *wrong* to use svn eol native for
> .sh files but it is unclear what to do with other files that Cygwin
> reads...
>
> --
> Øyvind Harboe
> Embedded software and hardware consulting services
> http://consulting.zylin.com
> ___
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
>
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] make maintainer-clean is does not work when build != src dir

On Tue, 2009-06-09 at 12:00 +0200, Øyvind Harboe wrote:
> I use a different build & openocd src dir, this means "make
> maintainer-clean" does not work...
> 
> Is this old news?
> 
> This is reproduceable under Linux as well as Cygwin.
> 
> I tricked myself into believing that "make maintainer-clean" worked from
> the build directory at some point and confused that with the eol native
> line issues

Whoops!  I will commit a patch that fixes this shortly.

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

[Openocd-development] make maintainer-clean is does not work when build != src dir

I use a different build & openocd src dir, this means "make
maintainer-clean" does not work...

Is this old news?

This is reproduceable under Linux as well as Cygwin.

I tricked myself into believing that "make maintainer-clean" worked from
the build directory at some point and confused that with the eol native
line issues

-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] Problems with svn eol line endings and Cygwin when using Windows svn client

I've had a bit of problems with Cygwin and svn eol native
option.

I thought I understood what was going on and I went ahead and
did some changes to svn head, but I have since discovered that
I do *not* understand what's going on so svn head is a bit in
limbo...

1. "guess-rev.sh" was busted because Cygwin will fail to execute
it when checked out with native. I ran dos2unix and removed the
native option. It now works.

2. I ran into problems with Makefile.am and configure.in not having
Unix line endings and Cygwin failing to run "make maintainer-clean"
deleting "ltmain.sh" and various other files.

I did some tests and it seemed that the problem "make maintainer-clean"
problem was due to the svn native option and Cygwin getting confused.

"Great! I thought, I know how to fix that!" So I committed a fix to remove
svn eol line endings for Makefile.am and configure.in.

Only it didn't fix the problem w/"make maintainer-clean"

So now I have a situation in Cygwin w/Eclipse/Windows svn client
where:

- I don't know understand why ltmain.sh isn't removed during "make
maintainer-clean"
- I saw "ltmain.sh" being removed by "make maintainer-clean" but I
don't know what I did to make that happen and I can't reproduce
this behaviour under Cygwin.
- Makefile.am and configure.in no longer has the svn native line endings
under in svn head.
- There is clear evidence that it is *wrong* to use svn eol native for
.sh files but it is unclear what to do with other files that Cygwin
reads...

-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] to extern, or not to extern?

Hi all,

I want to remove the 'extern' keyword from all function prototypes.
The extern keyword is redundant in such contexts, adds bulk, and
visually make its difficult to spot "real" extern declarations.

Some may have noticed that I have already stopped adding them to new
functions that I am defining, but I want to start removing them in
future patches.  This will help developers identify future variable
encapsulation opportunities, as searching for 'extern' will suffice.

Cheers,

Zach

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

[Openocd-development] Problems with make maintainer-clean

I've tried to figure out why ltmain.sh does not get deleted
when checking out OpenOCD using Eclipse and
building it under Cygwin.

For a while I thought it was because  Makefile.am used
svn native line endings, but that wasn't it.


I'll give up on this for now, but at least anyone else running
into this know that they are not alone. :-)

-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] assert vs. error messages

I'm satisfied that I've put the performance issue with checking at too
low a level on the radar.

I'll leave this to Zach's judgement (he's the one who's working on it
currently), but I'm reserving the right to raise an objection later based
on measured performance problems(referring to Rick pointing out
that performance should be dealt with by measurements and
not speculation).

I very few concerns that it will be fundamentally hard to address any
documented performance issues in this regard, unless something
radically new crops up in terms of doing *extensive* runtime checking.



-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] assert vs. error messages

On Monday 08 June 2009, Zach Welch wrote:
> Basically, the JTAG library should not make policy to abort, if it will
> be used by script commands. 

Right, it should not be possible for anything done by a client
to cause the server to crash.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] assert vs. error messages




On Jun 8, 2009, at 11:51 PM, Øyvind Harboe wrote:

On Tue, Jun 9, 2009 at 8:29 AM, Zach Welch  
wrote:

On Tue, 2009-06-09 at 07:57 +0200, Øyvind Harboe wrote:

How about a clearer policy of using assert()'s?

I'm thinking that error()'s should be reserved for "real" runtime  
errors.




   if (!tap_is_state_stable(path[num_states - 1]))
   {
   LOG_ERROR("BUG: TAP path doesn't finish in a  
stable state");

-   exit(-1);
+   jtag_set_error(ERROR_JTAG_NOT_STABLE_STATE);
+   return;
   }



The above should be an assert().


No.  I thought this issue over carefully.  The problem with using
asserts is that the program should not simply exit when the users  
issues

a bad command.  That is a _policy_.  The core JTAG module should
implement as few policies as possible, focusing on _mechanisms_.   
Thus,
I removed the "exit" policy error and used the error reporting  
mechanism

to make the pathmove mechanism work in more contexts.

If it will be possible for the user to script a call such that their
typos get translated to a bad pathmove call, then they should not
suddenly see OpenOCD stop running.  Furthermore, compiling with - 
DNDEBUG

_removes_ assertions so you want to disable error checking for
releases, do you?


I want assertions to be compiled out when:

- they are the type of errors that only occur due to programming  
errors.


But who's programming error is it?  An assert is appropriate if the  
error condition is solely contained within the library or program and  
can never be caused by a user.  In those cases, the asserts provide  
sanity checking for the developers of the library or program.  If a  
user can cause the condition, even if doing so is a programming error  
on their part, it should be returned as an error.  Otherwise the  
calling program or user doesn't know what happened and any in-progress  
work will be lost.


By deferring the policy decision to the caller, the _program_ can  
choose
to live or die when a potentially user-supplied parameter was  
incorrect.
This is the right move for creating a reusable JTAG library, as you  
must

assume the user will do things with the core that you did not intend.


The problem I have with this is where do you stop? Do we check if
pointers are valid?



Anything a user can do should not cause an unexpected termination.   
For a program, this is limited to the actions exposed via the UI or  
interpreter.  For a library, this is anything caused by a library  
entry point.  If the library's API includes pointer arguments, it is  
considered good style to check for NULL pointers if they are invalid  
for that function.  Otherwise the caller gets a crash at some point  
later that isn't necessarily easy to tie back to that arg.  If you  
program defensively, users don't get frustrated by the "crashy piece  
of crap that never works."   Instead they are told what is wrong so  
they can fix it.



I like clear programming errors to simply use asserts.



I agree when the programming error is on the part of an OpenOCD  
developer and not a user.



For example, this change allows an enterprising individual to begin
writing a TCL replacement of the Target layer, adding low-level  
pathmove

and scan commands for Jim (and so on... ad sanatorium).  Moreover, if
any command that builds on this function were to be able to be  
similarly
misused, the program should not exit -- the interpreter should  
report an

error, right?


Yes, but the error checks should not necessarily be done at the very  
lowest

level when it affects performance of embedded targets.



The rules of performance optimization are to measure, analyze, then  
optimize.  Speculation isn't part of that.  A few potential NOPs  
(untaken branches) have minimal performance impact.  Now, the checks  
on the args should be done at the user-visible entry point.  Once it  
has been checked there, it should be valid for anything else in the  
library/program.  I believe the intent in this case is to expose  
pathmove as part of the librar API and as a TCL command.  In both  
cases, the args should be validated in the entry point.  If other  
internal layers use the same method _and_ the checks are measured to  
incur significant overhead, then the checks can be moved to a separate  
method that is the external entry point and the guts of the method  
become an internal function.



P.S. In raising this point, you have exposed the fact that assert has
been used several throughout the JTAG module incorrectly.  Expect a
flurry of patches to fix these bugs this soon.


Don't do that please. At least we should have a way to distinguish
between what are programming errors (asserts) and what are
real user/environment errors.



If the error occurs because of a bad arg provided by a TCL script or a  
library call, it's an error.  If it's an invalid internal state or  
condition that isn't influenced by any args the user sent in, it's

Re: [Openocd-development] assert vs. error messages

jtag_add_pathmove() is not a high performance API, so here
runtime (debugging or otherwise) checks do not really affect
anything much.

A better example would be jtag_add_dr_out(). Here I don't want
lots of runtime checks as this is used in the innermost loops. All
checks on userdata must happen higher up.

I'm hesitant to add *lots* of checks to jtag_add_*_scan().

There needs to be a sanity checking wrapper for those fn's if you
want to pass through data from the outside world.

Generally I want checks as far down as possible, until they start
causing performance problems. Since OpenOCD supports embedded
targets, the this means we can't push them too far down.

-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] assert vs. error messages