Re: [Openocd-development] assert vs. error messages
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?
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.
Basically, the JTAG library should not make policy to abort, if it will
be used by script commands. While this was effectively an 'assert'
before my changes, no one reported trouble with it. Further, none of
the higher layers appear to check jtag_error anyway, so this should not
cause unexpected new errors to appear from the new error codes.
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?
Cheers,
Zach
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.
___
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 Tue, Jun 9, 2009 at 8:29 AM, Zach Welchz...@superlucidity.net 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.
- they impact performance on embedded targets.
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?
I like clear programming errors to simply use asserts.
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.
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.
--
Ø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 build fail (no ftdi, -mno-cygwin)
Windows uses different line endings from Linux. But Cygwin doesn't! Consider a *common* situation. Use a Windows GUI to check out svn, but build under Cygwin. So if you use native line endings on .sh files, that breaks Cygwin! Arrrggh!!! That was Arrgh to Cygwin/Windows, not to you :-) -- Ø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] Cygwin/Windows hell do not use native line style for .sh scripts
I've reverted to not using native end style on guess-rev.sh. With native line style, Cygwin fails to execute guess-rev.sh if it has been checked out by a Windows GUI. oyv...@fury /cygdrive/c/workspace/openocd $ sh guess-rev.sh guess-rev.sh: line 3: $'\r': command not found guess-rev.sh: line 5: $'\r': command not found oyv...@fury /cygdrive/c/workspace/openocd $ dos2unix.exe guess-rev.sh guess-rev.sh: done. oyv...@fury /cygdrive/c/workspace/openocd $ sh guess-rev.sh 2152P -- Ø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 Tue, 2009-06-09 at 08:51 +0200, Øyvind Harboe wrote:
On Tue, Jun 9, 2009 at 8:29 AM, Zach Welchz...@superlucidity.net 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.
- they impact performance on embedded targets.
Then we are not talking about assertions. You do not get to define the
terms of assertions, assert.h does.
So, we are talking about debugging checks that can be compiled out for
performance. Well, there was no performance changed here.
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?
I like clear programming errors to simply use asserts.
Right, but my point is there is _no way to tell_ if it is a programming
error or a user error in a library. You would be presuming too much.
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.
Unfortunately, this is exactly where they belong in this method. Those
error checks must do validation of the path, which could well be fed to
the routine from a TCL script or other application that takes user
input. Guess what... jtag_add_pathmove is called by jtag_add_statemove
which is called by... SVF which opens this door wide open, doesn't it?
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.
That is exactly the problem though: if we want the JTAG layer of
libopenocd to be general purpose, then we cannot make assumptions about
the source of the errors in this data. Mind you, there are places that
assert is valid, but there are places where it is not:
static void jtag_checks(void)
{
assert(jtag_trst == 0);
}
As far as I can tell, this also needs to be changed to a run-time error,
_unless_ it is never possible for this value to be wrong by the user's
bad actions. If it does, then it would be desirable to abort the
current operation and allow the program to try and gracefully recover,
in the case that the user was silly enough to end up in this state.
Cheers,
Zach
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
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
On Jun 8, 2009, at 11:51 PM, Øyvind Harboe wrote:
On Tue, Jun 9, 2009 at 8:29 AM, Zach Welchz...@superlucidity.net
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
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
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] 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
[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 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] 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
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
Re: [Openocd-development] Problems with svn eol line endings and Cygwin when using Windows svn client
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 Harboeoyvind.har...@zylin.com 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, Jun 9, 2009 at 12:24 PM, Zach Welchz...@superlucidity.net 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
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] 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 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
On Tue, 2009-06-09 at 13:07 +0200, Øyvind Harboe wrote: On Tue, Jun 9, 2009 at 1:02 PM, Zach Welchz...@superlucidity.net 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
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
[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] 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
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 g...@gnu.ai.mit.edu, 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 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 g...@gnu.ai.mit.edu, 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 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 g...@gnu.ai.mit.edu, 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
Re: [Openocd-development] Idea on dr/irscan command handling
Ø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 Tue, Jun 9, 2009 at 7:37 PM, David Brownelldavi...@pacbell.net 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
On Tuesday 09 June 2009, Øyvind Harboe wrote: On Tue, Jun 9, 2009 at 7:37 PM, David Brownelldavi...@pacbell.net 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] 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
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
[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
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
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
[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
[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 openocd.c:144 handle_init_command(): target
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 b.hutch...@gmail.comwrote: 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
[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
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({1244582536, 329023}, NULL) = 0
gettimeofday({1244582536, 329079}, NULL) = 0
gettimeofday({1244582536, 329212}, NULL) = 0
[Openocd-development] Cygwin EOL settings - an idea..
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] 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
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 b.hutch...@gmail.com 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] Jlink not running under cygwin
On Tue, Jun 9, 2009 at 11:44 PM, Gene Smithg...@chartertn.net 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] 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] 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 z...@superlucidity.net wrote: On Tue, 2009-06-09 at 17:52 -0400, Brian Hutchinson wrote: On Tue, Jun 9, 2009 at 5:26 PM, Brian Hutchinson b.hutch...@gmail.com 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] [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] 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
