Re: [Openocd-development] Charset choice for OpenOCD

2009-07-14 Thread Øyvind Harboe
Oopsss.. pressed send to early. I forgot to mention that I've retired
the first Eclipse .settings directory I committed.



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


Re: [Openocd-development] Charset choice for OpenOCD

2009-07-14 Thread Øyvind Harboe
How's this then:


- UTF-8
- add a contrib/eclipse/.settings directory as example
- add UTF-8 to developer doc somewhere


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


[Openocd-development] About thee open-ocd & FT2232

2009-07-14 Thread Qiang Wang
hello ,every one
Nice to meet you here.
I am studying the open-ocd and the JTAG also.
I know that this project use the FT2232 chip.
But I can not get the clear architecture about the open-ocd ,FT2232
and the target .
Can somebody tell me or give some document link.

Thank you very much.

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


[Openocd-development] Parallel Port Driver Replacement for Vista 64

2009-07-14 Thread Xiaofan Chen
On Wed, Jul 15, 2009 at 8:37 AM, Zach Welch wrote:
>> By the way, I believe parport_giveio is not working for Vista 64bit.
>> This is similar to the issues of libusb-win32 (driver signing).
>> Maybe this can be added to the README file.
>
> Yes, but I think the TODO is a better place for bugs.  Send a patch. :)
>

I am familiar with the libusb-win32 issue. But I am not that familiar
with the parallel port driver options for Windows. Actually I have
an Olimex Wiggler clone but my desktop does not have a parallel
port.

Anyway, I just did some Google search and it seems that there
are at least two Open Source options for the giveio driver
replacement. Both may need some codes rewrite but the
driver signing issue has been solved.

1) InpOut32 and InpOutx64
I think this is also widely used.
http://www.highrez.co.uk/Downloads/InpOut32/default.htm
A nice guy helped signed the driver so it is now working
under Vista 64bit.

2) WinRing0
This is less well-known.
http://sourceforge.net/projects/winring0/
According to the website, it is also digitally signed and
work under Vista 64.

Any one here are familiar with the above drivers?

So hopefully some nice guys will also help signed
the libusb-win32 driver. ;-)

-- 
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] Compiling from svn on ubuntu 8.04 fails...

2009-07-14 Thread Alain Mouette

David Brownell escreveu:
>>> ... where your_script_name.cfg sources files for the interface
>>> and board decls, says "init", issues the commands you like,
>>> then says "shutdown".
> 
> See above about adding "init" first.  That's important.
> See the User's Guide about the "configuration stage".
> 
> Before that stage is terminated (by "init" etc), you
> can't run "halt".

T H A N K S, very very much.

I have read the manual many times, by now... that part was not clear to 
me and reading many examples (including other achitectures) I found not 
one with the init command.

Now all is running fine.

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


Re: [Openocd-development] 0.2.0 released

2009-07-14 Thread Zach Welch
On Wed, 2009-07-15 at 07:47 +0800, Xiaofan Chen wrote:
> On Wed, Jul 15, 2009 at 4:10 AM, Zach Welch wrote:
> > On Tue, 2009-07-14 at 17:49 +0200, Freddie Chopin wrote:
> >> 0.2.0 release cannot be build on Windows (MinGW + MSYS) with parport 
> >> support
> >>
> >> ./configure --enable-parport --enable-parport_giveio
> >> make
> >
> > Add --disable-parport-ppdev
> 
> This is quite counter-intuitive. Hopefully this can be fixed in the
> next version. What Freddie did will be common users do
> under Windows.

Yes, it will be fixed.  Spencer just posted a patch that fixes this for
CygWin and MinGW32 builds, such that it is disabled automatically.  More
work should allow automatic detection of all such options.

> By the way, I believe parport_giveio is not working for Vista 64bit.
> This is similar to the issues of libusb-win32 (driver signing).
> Maybe this can be added to the README file.

Yes, but I think the TODO is a better place for bugs.  Send a patch. :)

Cheers,

Zach

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


Re: [Openocd-development] [Openocd-svn] r2514 - trunk

2009-07-14 Thread Zach Welch
On Tue, 2009-07-14 at 12:21 +0100, Spencer Oliver wrote:
> >
> > In this respect, I think all of the drivers should be enabled 
> > by default.  Developers could disable them by choice, but 
> > their underlying libraries are being detected such that we 
> > can add new checks to disable the drivers when their 
> > dependencies are missing.
> > 
> > The goal is to allow our users to simply run './configure' 
> > without having to give any messy options.  Everything should 
> > be detected automatically, picking "sane" default settings if 
> > possible.  While that may not be 100% possible, we should be 
> > able to do _much_ better than the 0.2.0 configure script 
> > manages to accomplish.
> >
> 
> That sounds like a good plan, urjtag use a similar behaviour for detecting
> usb stuff.
>  
> > > Surely let the developer enable what he wants?
> > 
> > The non-x86 developer does not have a choice; the configure 
> > script always forced it to be enabled.  The developer still 
> > has the choice to disable it, so a choice is still there -- 
> > it's just backwards now.
> > It's broken either way, really.
> > 
> > Clearly, the configure script needs to be revisited during 0.3.0.
> > We need to figure out when and where these options are 
> > required, and we can test in the script for those required 
> > conditions.  These is are easy to script, once we know what they are.
> > 
> 
> attached patch fixes ppdev and win32 platforms - no objections and i will
> commit?

A "real" fix will require more work, but this fix could be merged for
0.2.1 -- if we need to produce such a release.  This issue is not
sufficient to demand such given there is an easy workaround, but I am
very sorry that I caused it at the last minute before the release.
To be safe, I should have changed the documentation to reflect the code.

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


Re: [Openocd-development] Charset choice for OpenOCD

2009-07-14 Thread Zach Welch
On Tue, 2009-07-14 at 22:41 +0200, Øyvind Harboe wrote:
> On Tue, Jul 14, 2009 at 9:22 PM, Spencer Oliver wrote:
> >> >
> >> > This also changes my personal setting's when using ecplise - can we
> >> > revert this patch?
> >>
> >> Yes and no.
> >>
> >> We should choose *one* charset that is the standard charset,
> >> no matter which charset that is.
> >>
> >> I don't care what charset it is, much.
> >>
> >>
> >
> > Choosing a charset is not the issue - i use other project settings that are
> > saved in the prefs file.
> > Just add the charset info to the dev guide.
> 
> I'm OK with reverting the change, but I would like to have the charset
> nailed.

I agree with Spencer about this; we should not have this kind of support
in the main repository.  The arguments against providing IDE
configurations are nearly the same as for editor preferences.
So, yeah, this stuff should be removed from where it is, but I think it
could be suitable to move into contrib/ as a referenced example.

> UTF-8?

I do agree that a convention for the character set would be useful,
along with the commands for setting it properly in common cases.
I think UTF-8 is a better choice.

Altogether, this should be added somewhere in the Developer Manual,
preferably with links to contrib/ files that can be used.

Cheers,

Zach

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


Re: [Openocd-development] Charset choice for OpenOCD

2009-07-14 Thread David Brownell
On Tuesday 14 July 2009, Øyvind Harboe wrote:
> I'm OK with reverting the change, but I would like to have the charset
> nailed.
> 
> UTF-8?

A *MUCH* better choice.


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


Re: [Openocd-development] Compiling from svn on ubuntu 8.04 fails...

2009-07-14 Thread David Brownell
On Tuesday 14 July 2009, Alain Mouette wrote:
> 
> David Brownell escreveu:
> > On Tuesday 14 July 2009, Alain Mouette wrote:
> >> Back to my original question: How to I insert and execute that script 
> >> automaticaly, just like I did with the old scripts???
> > 
> > openocd -f your_script_name.cfg
> > 
> > ... where your_script_name.cfg sources files for the interface
> > and board decls, says "init", issues the commands you like,
> > then says "shutdown".
> 
> Please be patient, I have been trying for the last 40 years to make 
> myself understood, but it seems to get more difficult by the day :(
> 
> I have a config file (it is listed bellow), if I add "halt" at the end, 
> I get an error:
>Runtime error, file "myfile.cfg", line 60:
>  Unknown command: halt

See above about adding "init" first.  That's important.
See the User's Guide about the "configuration stage".

Before that stage is terminated (by "init" etc), you
can't run "halt".

> I believe that I should provably have a tcl procedure and invoque it 
> from the command line with something like -c "write_my_flash", but it 
> still complains about Unknown command: halt
> 
> Sorry if I may seem stupid, I am a developer and most of the time I can 
> do pretty complex stuff :) but something here is missing...
> 
> Thanks,
> Alain
> BTW: I am preparing a document with my experience with compiling and 
> using OpenOCD... It may help some others :)
> 
> --- myfile.cfg ---
> # script for luminary lm3s6965
> 
> #daemon configuration
> telnet_port 
> gdb_port 
> 
> #interface TURTELIZER
> interface ft2232
> ft2232_device_desc "Turtelizer JTAG/RS232 Adapter A"
> ft2232_layout "turtelizer2"
> ft2232_vid_pid 0x0403 0xbdc8
> 
> if { [info exists CHIPNAME] } {
> set  _CHIPNAME $CHIPNAME
> } else {
> set  _CHIPNAME lm3s6965
> }
> 
> if { [info exists ENDIAN] } {
> set  _ENDIAN $ENDIAN
> } else {
># this defaults to a little endian
> set  _ENDIAN little
> }
> 
> if { [info exists CPUTAPID ] } {
> set _CPUTAPID $CPUTAPID
> } else {
># force an error till we get a good number
>set _CPUTAPID 0x3ba00477
> }
> 
> # jtag speed
> jtag_khz 500
> 
> jtag_nsrst_delay 100
> jtag_ntrst_delay 100
> 
> #LM3S6965 Evaluation Board has only srst
> reset_config srst_only
> #reset_config srst_only separate
> 
> 
> #jtag scan chain
> jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 1 -irmask 0xf 
> -expected-id $_CPUTAPID
> 
> # the luminary variant causes a software reset rather than asserting SRST
> # this stops the debug registers from being cleared
> # this will be fixed in later revisions of silicon
> set _TARGETNAME [format "%s.cpu" $_CHIPNAME]
> target create $_TARGETNAME cortex_m3 -endian $_ENDIAN -chain-position 
> $_TARGETNAME -variant lm3s
> 
> # 4k working area at base of ram
> $_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x2000 
> -work-area-size 0x4000 -work-area-backup 0
> 
> #flash configuration
> flash bank stellaris 0 0 0 0 0
> 
> --
> ___
> 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] 0.2.0 released

2009-07-14 Thread Xiaofan Chen
On Wed, Jul 15, 2009 at 4:10 AM, Zach Welch wrote:
> On Tue, 2009-07-14 at 17:49 +0200, Freddie Chopin wrote:
>> 0.2.0 release cannot be build on Windows (MinGW + MSYS) with parport support
>>
>> ./configure --enable-parport --enable-parport_giveio
>> make
>
> Add --disable-parport-ppdev

This is quite counter-intuitive. Hopefully this can be fixed in the
next version. What Freddie did will be common users do
under Windows.

By the way, I believe parport_giveio is not working for Vista 64bit.
This is similar to the issues of libusb-win32 (driver signing).
Maybe this can be added to the README file.

-- 
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] [Openocd-svn] r2514 - trunk

2009-07-14 Thread Uwe Hermann
On Tue, Jul 14, 2009 at 11:46:59AM +0200, Øyvind Harboe wrote:
> > Or do you mean to say that --disable-parport-ppdev does not work??
> 
> 
> I had to specify --disable-parport-ppdev before my parport interface
> would work under Ubuntu 9.04.

Hm, that would be strange. Did you do 'modprobe ppdev'?


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] Charset choice for OpenOCD

2009-07-14 Thread Øyvind Harboe
On Tue, Jul 14, 2009 at 9:22 PM, Spencer Oliver wrote:
>> >
>> > This also changes my personal setting's when using ecplise - can we
>> > revert this patch?
>>
>> Yes and no.
>>
>> We should choose *one* charset that is the standard charset,
>> no matter which charset that is.
>>
>> I don't care what charset it is, much.
>>
>>
>
> Choosing a charset is not the issue - i use other project settings that are
> saved in the prefs file.
> Just add the charset info to the dev guide.

I'm OK with reverting the change, but I would like to have the charset
nailed.

UTF-8?


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


Re: [Openocd-development] 0.2.0 released

2009-07-14 Thread Zach Welch
On Tue, 2009-07-14 at 17:49 +0200, Freddie Chopin wrote:
> 0.2.0 release cannot be build on Windows (MinGW + MSYS) with parport support
> 
> ./configure --enable-parport --enable-parport_giveio
> make

Add --disable-parport-ppdev


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


Re: [Openocd-development] Charset choice for OpenOCD

2009-07-14 Thread Spencer Oliver
> >
> > This also changes my personal setting's when using ecplise - can we 
> > revert this patch?
> 
> Yes and no.
> 
> We should choose *one* charset that is the standard charset, 
> no matter which charset that is.
> 
> I don't care what charset it is, much.
> 
> 

Choosing a charset is not the issue - i use other project settings that are
saved in the prefs file.
Just add the charset info to the dev guide.

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


Re: [Openocd-development] Charset choice for OpenOCD

2009-07-14 Thread Øyvind Harboe
On Tue, Jul 14, 2009 at 9:14 PM, Spencer Oliver wrote:
>
>> Committed.
>>
>> These are the Eclipse settings w/Cp1252 charset.
>>
>> Perhaps the charset should be defined/documented otherwise,
>> but it's nice to have the these settings saved for those(me
>> :-) that use Eclipse to check out and work on OpenOCD
>>
>
> This also changes my personal setting's when using ecplise - can we revert
> this patch?

Yes and no.

We should choose *one* charset that is the standard charset, no
matter which charset that is.

I don't care what charset it is, much.



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


Re: [Openocd-development] Charset choice for OpenOCD

2009-07-14 Thread Spencer Oliver

> Committed.
> 
> These are the Eclipse settings w/Cp1252 charset.
> 
> Perhaps the charset should be defined/documented otherwise, 
> but it's nice to have the these settings saved for those(me 
> :-) that use Eclipse to check out and work on OpenOCD
> 

This also changes my personal setting's when using ecplise - can we revert
this patch?

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


[Openocd-development] Charset choice for OpenOCD

2009-07-14 Thread Øyvind Harboe
Committed.

These are the Eclipse settings w/Cp1252 charset.

Perhaps the charset should be defined/documented otherwise, but it's nice to
have the these settings saved for those(me :-) that use Eclipse to check
out and work on OpenOCD




-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
### Eclipse Workspace Patch 1.0
#P openocd
Index: .settings/org.eclipse.core.resources.prefs
===
--- .settings/org.eclipse.core.resources.prefs  (revision 0)
+++ .settings/org.eclipse.core.resources.prefs  (revision 0)
@@ -0,0 +1,3 @@
+#Tue Jul 14 20:27:34 CEST 2009
+eclipse.preferences.version=1
+encoding/=Cp1252
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] [patch] README - mention udev, and correct D2XX speed mentions

2009-07-14 Thread Øyvind Harboe
Committed.

Thanks!



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


Re: [Openocd-development] Compiling from svn on ubuntu 8.04 fails...

2009-07-14 Thread Alain Mouette

David Brownell escreveu:
> On Tuesday 14 July 2009, Alain Mouette wrote:
>> Back to my original question: How to I insert and execute that script 
>> automaticaly, just like I did with the old scripts???
> 
> openocd -f your_script_name.cfg
> 
> ... where your_script_name.cfg sources files for the interface
> and board decls, says "init", issues the commands you like,
> then says "shutdown".

Please be patient, I have been trying for the last 40 years to make 
myself understood, but it seems to get more difficult by the day :(

I have a config file (it is listed bellow), if I add "halt" at the end, 
I get an error:
   Runtime error, file "myfile.cfg", line 60:
 Unknown command: halt

I believe that I should provably have a tcl procedure and invoque it 
from the command line with something like -c "write_my_flash", but it 
still complains about Unknown command: halt

Sorry if I may seem stupid, I am a developer and most of the time I can 
do pretty complex stuff :) but something here is missing...

Thanks,
Alain
BTW: I am preparing a document with my experience with compiling and 
using OpenOCD... It may help some others :)

--- myfile.cfg ---
# script for luminary lm3s6965

#daemon configuration
telnet_port 
gdb_port 

#interface TURTELIZER
interface ft2232
ft2232_device_desc "Turtelizer JTAG/RS232 Adapter A"
ft2232_layout "turtelizer2"
ft2232_vid_pid 0x0403 0xbdc8

if { [info exists CHIPNAME] } {
set  _CHIPNAME $CHIPNAME
} else {
set  _CHIPNAME lm3s6965
}

if { [info exists ENDIAN] } {
set  _ENDIAN $ENDIAN
} else {
   # this defaults to a little endian
set  _ENDIAN little
}

if { [info exists CPUTAPID ] } {
set _CPUTAPID $CPUTAPID
} else {
   # force an error till we get a good number
   set _CPUTAPID 0x3ba00477
}

# jtag speed
jtag_khz 500

jtag_nsrst_delay 100
jtag_ntrst_delay 100

#LM3S6965 Evaluation Board has only srst
reset_config srst_only
#reset_config srst_only separate


#jtag scan chain
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 1 -irmask 0xf 
-expected-id $_CPUTAPID

# the luminary variant causes a software reset rather than asserting SRST
# this stops the debug registers from being cleared
# this will be fixed in later revisions of silicon
set _TARGETNAME [format "%s.cpu" $_CHIPNAME]
target create $_TARGETNAME cortex_m3 -endian $_ENDIAN -chain-position 
$_TARGETNAME -variant lm3s

# 4k working area at base of ram
$_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x2000 
-work-area-size 0x4000 -work-area-backup 0

#flash configuration
flash bank stellaris 0 0 0 0 0

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


Re: [Openocd-development] Version 3 test patch for jlink.c

2009-07-14 Thread Gary Carlson



On 7/14/09 7:55 AM, "Alan Carvalho de Assis"  wrote:

> Hi Gary,
> 
> On 7/13/09, Gary Carlson  wrote:
>> 
>> I think your board is being held in reset by something other then the J-link
>> dongle.  If the board is in reset and the jlink device can't free it, your
>> will get the problem you described.  You can prove that by taking your
>> working board and holding the reset button down while you start the openocd.
>> It will break 100% of the time too.
>> 
>> Have you looked at your board reset signals on a scope?
>> 
> 
> I think there is not issue with reset signal because the board can to
> start its bootloader correctly when there is not JTAG attached. Anyway
> I will investigate the reset signals.
> 
> Thank you very much,
> 
> Regards,
> 
> Alan


That may be a possibility.  The JTAG dongle itself may not be clearing the
reset signal.  If definitely is worth confirming the state of the reset
signals by inspection because I still suspect that may be factoring into
your problems.

I am not familiar with your board and what I am going to mention may not
apply.  One of the other things that can trip up people using debuggers is
watch-dog timers.  Does this board have any external devices (i.e. FPGA or
dedicated WDT) that can activate the reset signal(s) to the CPU?  Those can
cause a great deal of grief also.

In any case I am pretty sure that your specific problem is different then
recent patches were put in place to address.

Gary







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


Re: [Openocd-development] Compiling from svn on ubuntu 8.04 fails...

2009-07-14 Thread David Brownell
On Tuesday 14 July 2009, Alain Mouette wrote:
> Back to my original question: How to I insert and execute that script 
> automaticaly, just like I did with the old scripts???

openocd -f your_script_name.cfg

... where your_script_name.cfg sources files for the interface
and board decls, says "init", issues the commands you like,
then says "shutdown".


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


Re: [Openocd-development] 0.2.0 released

2009-07-14 Thread David Brownell
On Tuesday 14 July 2009, Freddie Chopin wrote:
> Recently there was a "build guide" in the pdf manual. It had all the 
> --enable-xxx options and stuff like that. Now this section is not 
> present in the user guide and the doxygen manual without a search 
> functions is pretty much worthless IMHO...

It's in the README.  A User's Guide is not addressed to
packagers or other roles which need to build the software.  :)

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


Re: [Openocd-development] 0.2.0 released

2009-07-14 Thread Freddie Chopin
0.2.0 release cannot be build on Windows (MinGW + MSYS) with parport support

./configure --enable-parport --enable-parport_giveio
make

because:
[...]

parport.c:45:27: linux/parport.h: No such file or directory
parport.c:46:25: linux/ppdev.h: No such file or directory
parport.c:48:23: sys/ioctl.h: No such file or directory
parport.c: In function `parport_read':
parport.c:163: warning: implicit declaration of function `ioctl'
parport.c:163: error: `PPRSTATUS' undeclared (first use in this function)
parport.c:163: error: (Each undeclared identifier is reported only once
parport.c:163: error: for each function it appears in.)
parport.c: In function `parport_write_data':
parport.c:163: warning: redundant redeclaration of 'ioctl'
parport.c:163: warning: previous implicit declaration of 'ioctl' was here
parport.c:180: error: `PPWDATA' undeclared (first use in this function)
parport.c: In function `parport_init':
parport.c:163: warning: redundant redeclaration of 'ioctl'
parport.c:163: warning: previous implicit declaration of 'ioctl' was here
parport.c:347: error: `PPCLAIM' undeclared (first use in this function)
parport.c:354: error: `PARPORT_MODE_COMPAT' undeclared (first use in 
this function)
parport.c:355: error: `PPSETMODE' undeclared (first use in this function)
parport.c:362: error: `IEEE1284_MODE_COMPAT' undeclared (first use in 
this function)
parport.c:363: error: `PPNEGOT' undeclared (first use in this function)
parport.c: At top level:
parport.c:261: warning: 'parport_get_giveio_access' defined but not used
make[3]: *** [parport.lo] Error 1
make[3]: Leaving directory `/home/chopin/openocd/0.2.0/src/jtag'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/chopin/openocd/0.2.0/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/chopin/openocd/0.2.0'
make: *** [all] Error 2

What's interesting is the fact that parport.c wasn't changed for some 
time now and I was able to compile recent revisions without problems, so 
the problem is probably somewhere in the build configurations.

In the future I think it would be smart to allow some testing of the 
relase (release candidates) before posting that online. That was how 
Rick made the first release.

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


Re: [Openocd-development] 0.2.0 released

2009-07-14 Thread Freddie Chopin
Recently there was a "build guide" in the pdf manual. It had all the 
--enable-xxx options and stuff like that. Now this section is not 
present in the user guide and the doxygen manual without a search 
functions is pretty much worthless IMHO...

Can this section be found anywhere or is that gone forever and the 
knowledge how to build openocd (the "easy" task that every windows user 
has to perform by oneself) becomes one of the urban legends?

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


Re: [Openocd-development] Compiling from svn on ubuntu 8.04 fails...

2009-07-14 Thread Alain Mouette
Hi,

I think that I did not make myself clear. *my system is now WORKING*

BUT, I have to manualy insert the script to write the flash in the 
TELNET terminal.

Back to my original question: How to I insert and execute that script 
automaticaly, just like I did with the old scripts???

I read the manual, studied many sample scripts, made a lot of tests but 
there is something that I am missing... And I cannot find ANY example of 
a config file to just _write the flash and exit_

--- old question follow-up ---
Xiaofan Chen escreveu:
> It is much better to use udev rules than using setuid bit.

I already had the udev rules installed...

> https://lists.berlios.de/pipermail/openocd-development/2009-July/009454.html
> https://lists.berlios.de/pipermail/openocd-development/2009-July/009456.html

Thanks, these have some very interesting possibilities. And it is very 
hard to get usefull information on udev rules.

Thanks again,
Alain

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


Re: [Openocd-development] Version 3 test patch for jlink.c

2009-07-14 Thread Alan Carvalho de Assis
Hi Gary,

On 7/13/09, Gary Carlson  wrote:
>
> I think your board is being held in reset by something other then the J-link
> dongle.  If the board is in reset and the jlink device can't free it, your
> will get the problem you described.  You can prove that by taking your
> working board and holding the reset button down while you start the openocd.
> It will break 100% of the time too.
>
> Have you looked at your board reset signals on a scope?
>

I think there is not issue with reset signal because the board can to
start its bootloader correctly when there is not JTAG attached. Anyway
I will investigate the reset signals.

Thank you very much,

Regards,

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


Re: [Openocd-development] Version 3 test patch for jlink.c

2009-07-14 Thread Alan Carvalho de Assis
Hi Xiaofan,

On 7/13/09, Xiaofan Chen  wrote:
> On Tue, Jul 14, 2009 at 6:39 AM, Alan Carvalho de
> Assis wrote:
>> Then I think this issue just happen when using OpenOCD + JLink +
>> i.MX27ADS board.
>
> I am not so sure if your problem have something to do with this
> thread and maybe you want to try that fix as well.
> https://lists.berlios.de/pipermail/openocd-development/2009-July/009473.html
>
> From the mailing list, i.MX27 target in OpenOCD still has quite
> some issues.
> https://lists.berlios.de/pipermail/openocd-development/2009-July/thread.html
>

Commenting out those lines in jlink_reset didn't solve the issue.

Any other suggestion will be appreciated.

Regards,

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


Re: [Openocd-development] [Openocd-svn] r2514 - trunk

2009-07-14 Thread Spencer Oliver
>
> In this respect, I think all of the drivers should be enabled 
> by default.  Developers could disable them by choice, but 
> their underlying libraries are being detected such that we 
> can add new checks to disable the drivers when their 
> dependencies are missing.
> 
> The goal is to allow our users to simply run './configure' 
> without having to give any messy options.  Everything should 
> be detected automatically, picking "sane" default settings if 
> possible.  While that may not be 100% possible, we should be 
> able to do _much_ better than the 0.2.0 configure script 
> manages to accomplish.
>

That sounds like a good plan, urjtag use a similar behaviour for detecting
usb stuff.
 
> > Surely let the developer enable what he wants?
> 
> The non-x86 developer does not have a choice; the configure 
> script always forced it to be enabled.  The developer still 
> has the choice to disable it, so a choice is still there -- 
> it's just backwards now.
> It's broken either way, really.
> 
> Clearly, the configure script needs to be revisited during 0.3.0.
> We need to figure out when and where these options are 
> required, and we can test in the script for those required 
> conditions.  These is are easy to script, once we know what they are.
> 

attached patch fixes ppdev and win32 platforms - no objections and i will
commit?

Cheers
Spen 


win32_ppdev.patch
Description: Binary data
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


[Openocd-development] Parport error output fix

2009-07-14 Thread Øyvind Harboe
Output errno, very slightly useful when debugging problems with connecting
to parport.

Comments?

-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/jtag/parport.c
===
--- src/jtag/parport.c  (revision 2522)
+++ src/jtag/parport.c  (working copy)
@@ -337,7 +337,8 @@
 
if (device_handle < 0)
{
-   LOG_ERROR("cannot open device. check it exists and that user 
read and write rights are set");
+   int err = errno;
+   LOG_ERROR("cannot open device. check it exists and that user 
read and write rights are set. errno=%d", err);
return ERROR_JTAG_INIT_FAILED;
}
 
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


[Openocd-development] 0.2.0 released

2009-07-14 Thread Zach Welch
Hi all,

The OpenOCD 0.2.0 source release should now be available from the
BerliOS download page:

  
https://developer.berlios.de/project/showfiles.php?group_id=4148&release_id=16455

The trunk is now open for new development patches, and a branch is
available to take critical bug fixes in the event that we need 0.2.1.

I urge all non-contributing developers to try to use the release, rather
than continuing to follow the Subversion repository.

I look forward to seeing what we can do for 0.3.0.  Please plan for its
release window to start sometime in August.

Cheers,

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


Re: [Openocd-development] [Openocd-svn] r2514 - trunk

2009-07-14 Thread Zach Welch
On Tue, 2009-07-14 at 10:24 +0100, Spencer Oliver wrote:
> > On Tue, 2009-07-14 at 10:11 +0100, Spencer Oliver wrote:
> > > > Modified:
> > > >trunk/configure.in
> > > > Log:
> > > > Make the parport-ppdev option enabled by default.  This 
> > may require 
> > > > giving --disable-parport-ppdev to configure on some platform(s).
> > > > 
> > > > 
> > > 
> > > Any reason why as it breaks win32 build - why not leave as 
> > disabled by
> > > default?
> > 
> > My understanding is that both x86 Linux and Darwin require it enabled;
> > moreover, it is forced enabled on all non-x86 platforms.  Nico pointed
> > out that the help text was wrong.
> > 
> > Or do you mean to say that --disable-parport-ppdev does not work??
> > 
> 
> No --disable-parport-ppdev does work but my point is why does it need
> enabling by default?

The configure script should provide "sensible" defaults for options.
This option seems to either be required or forced for most platforms, so
it seems "sensible" for this option to be enabled by default.

In this respect, I think all of the drivers should be enabled by
default.  Developers could disable them by choice, but their underlying
libraries are being detected such that we can add new checks to disable
the drivers when their dependencies are missing.

The goal is to allow our users to simply run './configure' without
having to give any messy options.  Everything should be detected
automatically, picking "sane" default settings if possible.  While that
may not be 100% possible, we should be able to do _much_ better than the
0.2.0 configure script manages to accomplish.

> Surely let the developer enable what he wants?

The non-x86 developer does not have a choice; the configure script
always forced it to be enabled.  The developer still has the choice to
disable it, so a choice is still there -- it's just backwards now.
It's broken either way, really.

Clearly, the configure script needs to be revisited during 0.3.0.
We need to figure out when and where these options are required, and we
can test in the script for those required conditions.  These is are
easy to script, once we know what they are.

Cheers,

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


Re: [Openocd-development] [Openocd-svn] r2514 - trunk

2009-07-14 Thread Øyvind Harboe
> Or do you mean to say that --disable-parport-ppdev does not work??


I had to specify --disable-parport-ppdev before my parport interface
would work under Ubuntu 9.04.

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


Re: [Openocd-development] [Openocd-svn] r2514 - trunk

2009-07-14 Thread Spencer Oliver
> On Tue, 2009-07-14 at 10:11 +0100, Spencer Oliver wrote:
> > > Modified:
> > >trunk/configure.in
> > > Log:
> > > Make the parport-ppdev option enabled by default.  This 
> may require 
> > > giving --disable-parport-ppdev to configure on some platform(s).
> > > 
> > > 
> > 
> > Any reason why as it breaks win32 build - why not leave as 
> disabled by
> > default?
> 
> My understanding is that both x86 Linux and Darwin require it enabled;
> moreover, it is forced enabled on all non-x86 platforms.  Nico pointed
> out that the help text was wrong.
> 
> Or do you mean to say that --disable-parport-ppdev does not work??
> 

No --disable-parport-ppdev does work but my point is why does it need
enabling by default?
Surely let the developer enable what he wants?

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


Re: [Openocd-development] [Openocd-svn] r2514 - trunk

2009-07-14 Thread Zach Welch
On Tue, 2009-07-14 at 10:11 +0100, Spencer Oliver wrote:
> > Modified:
> >trunk/configure.in
> > Log:
> > Make the parport-ppdev option enabled by default.  This may 
> > require giving --disable-parport-ppdev to configure on some 
> > platform(s).
> > 
> > 
> 
> Any reason why as it breaks win32 build - why not leave as disabled by
> default?

My understanding is that both x86 Linux and Darwin require it enabled;
moreover, it is forced enabled on all non-x86 platforms.  Nico pointed
out that the help text was wrong.

Or do you mean to say that --disable-parport-ppdev does not work??

Cheers,

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


Re: [Openocd-development] [Openocd-svn] r2514 - trunk

2009-07-14 Thread Spencer Oliver

> Modified:
>trunk/configure.in
> Log:
> Make the parport-ppdev option enabled by default.  This may 
> require giving --disable-parport-ppdev to configure on some 
> platform(s).
> 
> 

Any reason why as it breaks win32 build - why not leave as disabled by
default?

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


Re: [Openocd-development] [patch] README - mention udev, and correct D2XX speed mentions

2009-07-14 Thread Xiaofan Chen
On Tue, Jul 14, 2009 at 5:02 PM, David Brownell wrote:
> Under "Installing OpenOCD" mention that Linux users likely need to
> set up some /etc/udev file, maybe using contrib/udev.rules if that
> works on their distro.
>
> Say point-blank that the D2XX code is faster on Windows; but that
> it's no faster on Linux.
> ---
>  README |   11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
>

This is good.


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


[Openocd-development] [patch] README - mention udev, and correct D2XX speed mentions

2009-07-14 Thread David Brownell
Under "Installing OpenOCD" mention that Linux users likely need to
set up some /etc/udev file, maybe using contrib/udev.rules if that
works on their distro.

Say point-blank that the D2XX code is faster on Windows; but that
it's no faster on Linux.
---
 README |   11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

Under "Installing OpenOCD" mention that Linux users likely need to
set up some /etc/udev file, maybe using contrib/udev.rules if that
works on their distro.

Say point-blank that the D2XX code is faster on Windows; and that
it's no faster on Linux.
---
 README |   11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

--- a/README
+++ b/README
@@ -64,6 +64,12 @@ you can build the in-tree documentation.
 Installing OpenOCD
 ==
 
+On Linux, you may have permissions problems to address.  The best
+way to do this is to use the contrib/udev.rules file.  It probably
+belongs somewhere in /etc/udev/rules.d, but consult your operating
+system documentation to be sure.  In particular, make sure that it
+matches the syntax used by your operating system's version of udev.
+
 A Note to OpenOCD Users
 ---
 
@@ -325,7 +331,7 @@ Then type ``make'', and perhaps ``make i
 Using FTDI's FTD2XX
 ---
 
-Some claim the (closed) FTDICHIP.COM solution is faster, which
+The (closed source) FTDICHIP.COM solution is faster on MS-Windows.  That
 is the motivation for supporting it even though its licensing restricts
 it to non-redistributable OpenOCD binaries, and it is not available for
 all operating systems used with OpenOCD.  You may, however, build such
@@ -370,6 +376,9 @@ the following:
 --with-ft2xx-linux-tardir=../libftd2xx0.4.16 \
 	... other options ...
 
+Note that on Linux there is no good reason to use these FTDI binaries;
+they are no faster (on Linux) than libftdi, and cause licensing issues.
+
 =
 Obtaining OpenOCD From Subversion
 -
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] Compiling from svn on ubuntu 8.04 fails...

2009-07-14 Thread David Brownell
On Tuesday 14 July 2009, Xiaofan Chen wrote:
> It is much better to use udev rules than using setuid bit.

Hmmm, right.  I put together a quickie patch to the README so
that this gets mentioned as an install issue for Linux.

- Dave

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


[Openocd-development] 0.2.0 release, in progress

2009-07-14 Thread Zach Welch
Hi all,

I have started the 0.2.0 release process, and the repository now has the
branch and tag created.  Unfortunately, my script failed in the middle
of the process due to an untestable bug in the SVN steps that I missed.
So, I am going to have to work out a few steps by hand and finish it.
Please expect the release to be finished and available on BerliOS soon,
then we can resume committing to trunk.

Thanks,

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


Re: [Openocd-development] Unable to halt after reset LPC-2148

2009-07-14 Thread Øyvind Harboe
Also, you should try the builtin OpenOCD script rather than
the monolithic scripts you find on the web. Especially when
these scripts can contain obsolete commands and be out
of sync with the OpenOCD version you are using.

 openocd -f interface/parport.cfg -f target/lpc2148.cfg



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


Re: [Openocd-development] Unable to halt after reset LPC-2148

2009-07-14 Thread Øyvind Harboe
Try svn head, 0.1 is too old for this mailing list.

Note that srst_pulls_trst so it's not possible to reset the LPC2148
into the halted state. This is by design of LPC2148 impossible
(for IP protection purposes?).

What OpenOCD svn head will do is to reset the target, then halt it.

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


[Openocd-development] Unable to halt after reset LPC-2148

2009-07-14 Thread openocd
I seem unable to halt my LPC-2148 device, anyone knows what's  
wrong/what I am doing wrong? Thanks a bunch in advance.

openocd using olimex arm-usb-ocd, openocd log:
Open On-Chip Debugger 1.0 (2008-10-04-10:00) svn:exported
$URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $
Debug:   5 0 command.c:432 command_run_line(): script  
C:\gccfd\projects\demoproject\armusbocd.cfg
Debug:   6 0 configuration.c:87 open_file_from_path(): opened  
C:\gccfd\projects\demoproject\armusbocd.cfg
Debug:   8 0 command.c:432 command_run_line(): telnet_port 
Debug:   10 0 command.c:432 command_run_line(): gdb_port 
Debug:   12 0 command.c:432 command_run_line(): interface ft2232
Debug:   14 0 command.c:432 command_run_line(): ft2232_device_desc  
"Olimex OpenOCD JTAG A"
Debug:   16 1 command.c:432 command_run_line(): ft2232_layout "olimex-jtag"
Debug:   18 1 command.c:432 command_run_line(): ft2232_vid_pid 0x15BA 0x0003
Debug:   20 1 command.c:432 command_run_line(): jtag_speed 2
Debug:   21 1 jtag.c:1863 handle_jtag_speed_command(): handle jtag speed
Info:22 1 options.c:50 configuration_output_handler(): jtag_speed: 2, 2
Debug:   24 1 command.c:432 command_run_line(): reset_config  
trst_and_srst separate
Debug:   26 1 command.c:432 command_run_line(): jtag_device 4 0x1 0xf 0xe
Debug:   28 1 command.c:432 command_run_line(): daemon_startup reset
Info:29 1 options.c:50 configuration_output_handler(): Open  
On-Chip Debugger 1.0 (2008-10-04-10:00) svn:exported
Debug:   31 1 command.c:432 command_run_line(): target arm7tdmi little  
run_and_halt 0 arm7tdmi-s_r4
Debug:   33 1 command.c:432 command_run_line(): run_and_halt_time 0 30
Debug:   35 1 command.c:432 command_run_line(): working_area 0  
0x4000 0x4 nobackup
Debug:   37 1 command.c:432 command_run_line(): flash bank lpc2000 0x0  
0x7D000 0 0 0 lpc2000_v2 12000 calc_checksum
Debug:   39 1 command.c:432 command_run_line(): init
Debug:   40 2 openocd.c:102 handle_init_command(): target init complete
Debug:   41 2 ft2232.c:1374 ft2232_init_ftd2xx(): 'ft2232' interface  
using FTD2XX with 'olimex-jtag' layout (15ba:0003)
Debug:   42 30 ft2232.c:1463 ft2232_init_ftd2xx(): current latency timer: 2
Debug:   43 32 ft2232.c:1810 olimex_jtag_init(): 80 08 1b
Debug:   44 33 ft2232.c:1853 olimex_jtag_init(): 82 09 0f
Debug:   45 34 ft2232.c:253 ft2232_speed(): 86 02 00
Debug:   46 50 openocd.c:109 handle_init_command(): jtag interface  
init complete
Debug:   47 50 jtag.c:1537 jtag_init_inner(): Init JTAG chain
Debug:   48 50 jtag.c:326 jtag_call_event_callbacks(): jtag event:  
JTAG controller reset (TLR or TRST)
Debug:   49 50 jtag.c:1295 jtag_reset_callback(): -
Debug:   50 52 jtag.c:326 jtag_call_event_callbacks(): jtag event:  
JTAG controller reset (TLR or TRST)
Debug:   51 52 jtag.c:1295 jtag_reset_callback(): -
Error:   52 56 jtag.c:1351 jtag_examine_chain(): JTAG communication  
failure, check connection, JTAG interface, target power etc.
Error:   53 56 jtag.c:1556 jtag_init_inner(): trying to validate  
configured JTAG chain anyway...
Debug:   54 56 jtag.c:326 jtag_call_event_callbacks(): jtag event:  
JTAG controller reset (TLR or TRST)
Debug:   55 56 jtag.c:1295 jtag_reset_callback(): -
Error:   56 57 jtag.c:1444 jtag_validate_chain(): Error validating  
JTAG scan chain, IR mismatch, scan returned 0x3f
Debug:   57 67 jtag.c:326 jtag_call_event_callbacks(): jtag event:  
JTAG controller reset (TLR or TRST)
Debug:   58 67 jtag.c:1295 jtag_reset_callback(): -
Error:   59 70 jtag.c:1444 jtag_validate_chain(): Error validating  
JTAG scan chain, IR mismatch, scan returned 0x3f
Debug:   60 80 jtag.c:326 jtag_call_event_callbacks(): jtag event:  
JTAG controller reset (TLR or TRST)
Debug:   61 80 jtag.c:1295 jtag_reset_callback(): -
Error:   62 82 jtag.c:1444 jtag_validate_chain(): Error validating  
JTAG scan chain, IR mismatch, scan returned 0x3f
Debug:   63 92 jtag.c:326 jtag_call_event_callbacks(): jtag event:  
JTAG controller reset (TLR or TRST)
Debug:   64 92 jtag.c:1295 jtag_reset_callback(): -
Error:   65 93 jtag.c:1444 jtag_validate_chain(): Error validating  
JTAG scan chain, IR mismatch, scan returned 0x3f
Debug:   66 103 jtag.c:326 jtag_call_event_callbacks(): jtag event:  
JTAG controller reset (TLR or TRST)
Debug:   67 103 jtag.c:1295 jtag_reset_callback(): -
Error:   68 105 jtag.c:1444 jtag_validate_chain(): Error validating  
JTAG scan chain, IR mismatch, scan returned 0x3f
Debug:   69 115 jtag.c:326 jtag_call_event_callbacks(): jtag event:  
JTAG controller reset (TLR or TRST)
Debug:   70 115 jtag.c:1295 jtag_reset_callback(): -
Error:   71 117 jtag.c:1444 jtag_validate_chain(): Error validating  
JTAG scan chain, IR mismatch, scan returned 0x3f
Error:   72 117 jtag.c:1565 jtag_init_inner(): Could not validate JTAG  
chain, exit
Debug:   73 117 jtag.c:1581 jtag_init_reset(): Trying to bring the  
JTAG controller to life by asserting TRST / TLR
Debug:   74 117 jtag.c:996 jtag_add_reset(): SRST line released
Debug:   75

Re: [Openocd-development] why --disable-parport-ppdev ?

2009-07-14 Thread Michael Schwingen
Zach Welch wrote:
> Since I changed that text, I clearly meant for it to be enabled by
> default on x86; it always gets set on other hosts.  When I factored that
> configure code, I also changed the help text.  I thought that I got the
> logic right, but I just verified it to see if it was correct.  It's not.
>
> The attached patch ensures this feature has been enabled when the user
> does not pass either option to the configure script.  This may force
> some developers to add --disable-parport-ppdev, though I am not sure
> which platform(s) will require that.
>
> If others will ACK this, I can shove it into the trunk for 0.2.0.  This
> seems like it could be a regression that I caused, and the fix appears
> easy and obvious.
>   
OK from me.

cu
Michael

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


Re: [Openocd-development] Compiling from svn on ubuntu 8.04 fails...

2009-07-14 Thread Xiaofan Chen
On Tue, Jul 14, 2009 at 5:39 AM, Alain Mouette wrote:
>> Did you try run as sudo?
>
> After a good and restfull weekend, I found that the file had lost it's
> suid bit during the tests, amongst a few other things.
>

It is much better to use udev rules than using setuid bit.
The contrib directory has the udev rules. If that does not
work, you can refer to this thread as well.

https://lists.berlios.de/pipermail/openocd-development/2009-July/009454.html
https://lists.berlios.de/pipermail/openocd-development/2009-July/009456.html


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