Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal / OBJECTION

On Tue, Jun 21, 2011 at 2:45 PM, Laurent Gauch wrote: >> Latest version, 1.0.4. Same behaviour on both MacOSX and Linux. >> >> Sure. I'll ask if they would like to fix this problem. >> I will let you know what useful response I get. >> > > Great. > > But are you sure to have the correct libusb ver

Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal / OBJECTION

On 21/06/2011, at 4:45 PM, Laurent Gauch wrote: > Steve Bennett wrote: >> On 21/06/2011, at 3:59 PM, Laurent Gauch wrote: >> >> On 21/06/2011, at 1:07 AM, Laurent Gauch wrote: >> / />>/ >/ On Mon, Jun 20, 2011 at 1:00 PM, Steve Bennett > workware.net.au >>

Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal / OBJECTION

Steve Bennett wrote: On 21/06/2011, at 3:59 PM, Laurent Gauch wrote: On 21/06/2011, at 1:07 AM, Laurent Gauch wrote: / />>/ >/ On Mon, Jun 20, 2011 at 1:00 PM, Steve Bennett https://lists.berlios.de/mailman/listinfo/openocd-development>> wrote: />>/ />>/ On 20/06/2011, a

Re: [Openocd-development] Openocd release known issues

> > Try this: http://repo.or.cz/w/jimtcl.git/commit/fbc998db178da5c462e164b63da128a7d7412e37 > > With your recent changes, now 'make distcheck' works for me. > Many thanks :-) I am away on holiday at the moment so will not get time to look at this again until next week. Cheers Spen _

Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal / OBJECTION

On 21/06/2011, at 3:59 PM, Laurent Gauch wrote: >> On 21/06/2011, at 1:07 AM, Laurent Gauch wrote: >> >> >>/ />>/ >/ On Mon, Jun 20, 2011 at 1:00 PM, Steve Bennett > >>workware.net.au >> >>> wrote: >> />>/ />>/ On 20/06/2011, at 8:54

Re: [Openocd-development] RFC Release Cycle

On Tue, Jun 21, 2011 at 1:30 PM, Øyvind Harboe wrote: > After some consideration, I've changed my view to that the > release manager should have git access and that the master > branch developers *should* follow the release managers > marching orders and that we follow the cycle Jean-Christophe >

Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal / OBJECTION

On 21/06/2011, at 1:07 AM, Laurent Gauch wrote: >>/ />>/ >/ On Mon, Jun 20, 2011 at 1:00 PM, Steve Bennett https://lists.berlios.de/mailman/listinfo/openocd-development>> wrote: />>/ />>/ On 20/06/2011, at 8:54 PM, Øyvind Harboe wrote: />>/ />>/ />>>/ On Mon, Jun 20, 2011 at 12:50 PM, Steve Ben

Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT

Tomek CEDRO wrote: On Mon, Jun 20, 2011 at 9:19 PM, amotec-laurent_gauch wrote: Your TCL bitbang will control the port of the FTDI from an higher level than FT2232.c. OK but you TCL bitbang is specific to the layout used. How do you accept or not the use of the TCL procedure, if you do not h

Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT

On Mon, 20 Jun 2011 16:37:32 +, Tomek CEDRO wrote: > Laurent, > > 1. If you create cable that have ADC onboard (like KT-LINK) then it > is > easier to write simple TCL script to read ADC than rewrite whole > driver in the source code. Yes, easy but dangerous, because you are layout specific !!

Re: [Openocd-development] RFC Release Cycle

2011/6/21 Jon Povey : > Øyvind Harboe wrote: >> I am struggling a bit following the above, but I think we agree: >> >> - development goes on in master like it always has done >> - you create a fork at the openocd mirror and create a >> release branch there. >> You pick whatever you want from the ma

Re: [Openocd-development] RFC Release Cycle

Øyvind Harboe wrote: > I am struggling a bit following the above, but I think we agree: > > - development goes on in master like it always has done > - you create a fork at the openocd mirror and create a > release branch there. > You pick whatever you want from the master branch or whatever patche

Re: [Openocd-development] [PATCH] adding interface_signal and bitbang functionalities

On Mon, Jun 20, 2011 at 11:33 PM, Rodrigo Rosa wrote: > i found a bug in "interface_signal del", the name of the signal was > not passed down to the functions thats look for it, so it didn't work. > attached a patch  :) Tanks, I will take a look, but signal deletion worked for me.. > the first t

Re: [Openocd-development] [PATCH] adding interface_signal and bitbang functionalities

i found a bug in "interface_signal del", the name of the signal was not passed down to the functions thats look for it, so it didn't work. attached a patch :) since this stuff is not yet in the master branch (right?), i based this patch on openocd-ifsigbitbang@git://repo.or.cz/openocd/libswd.git

Re: [Openocd-development] [PATCH] adding interface_signal and bitbang functionalities

Here goes another patch to be applied on top of previous patches: -it fixes strnstr() problem - sorry for that, man says clearly it is FreeBSD specific! -it changes command mode to COMMAND_EXEC so 'bitbang' is only available after 'init' -some minor string and constants fixes Waiting for feedback

Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT

On Mon, Jun 20, 2011 at 9:19 PM, amotec-laurent_gauch wrote: > Your TCL bitbang will control the port of the FTDI from an higher level than > FT2232.c. OK but you TCL bitbang is specific to the layout used. How do you > accept or not the use of the TCL procedure, if you do not have the notion of >

Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal / OBJECTION

On 21/06/2011, at 1:07 AM, Laurent Gauch wrote: >> >> >/ On Mon, Jun 20, 2011 at 1:00 PM, Steve Bennett > >> wrote: >> />>/ On 20/06/2011, at 8:54 PM, Øyvind Harboe wrote: >> />>/ />>>/ On Mon, Jun 20, 2011 at 12:50 PM, Steve Bennett

Re: [Openocd-development] [PATCH] adding interface_signal and bitbang functionalities

I have found the issue - command "init" is mandatory for bitbang to work as it initialize the interface (pretty obvious). On another place I was using some configuration file that had this init inside and this is why it worked there, I mislooked that :-( So generally speaking the patches are worki

Re: [Openocd-development] [PATCH] adding interface_signal and bitbang functionalities

On Mon, Jun 20, 2011 at 8:18 PM, Øyvind Harboe wrote: >> Btw. is there any way in git to edit a commit? :-) > Yes: > git rebase -i origin/master Aaaarg, could have figured that myself ;-P Tanks! :-) I think I have found my problem - the bitbang can be used only after cable is initialized / after

Re: [Openocd-development] [PATCH] adding interface_signal and bitbang functionalities

> Btw. is there any way in git to edit a commit? :-) Yes: git rebase -i origin/master -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and fl

Re: [Openocd-development] [PATCH] adding interface_signal and bitbang functionalities

On Mon, Jun 20, 2011 at 7:46 PM, Rodrigo Rosa wrote: > i'm trying to apply these patches on the current head, and i get: > > bitbang.c: In function ‘handle_bitbang_command’: > bitbang.c:90: error: implicit declaration of function ‘strnstr’ > bitbang.c:90: error: assignment makes pointer from integ

Re: [Openocd-development] [PATCH] adding interface_signal and bitbang functionalities

i'm trying to apply these patches on the current head, and i get: bitbang.c: In function ‘handle_bitbang_command’: bitbang.c:90: error: implicit declaration of function ‘strnstr’ bitbang.c:90: error: assignment makes pointer from integer without a cast make[6]: *** [bitbang.lo] Error 1 i'm runnin

Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT

Hi Tomek, as I said, I don't know enough about this to say that this is a feature that we shouldn't have. It sounds like your primary concern is to get SWD done and to do that we need some bits and bobs in place first. I can accept that some bit-banging capability is required, but whether this is

Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT

On Mon, Jun 20, 2011 at 6:14 PM, Øyvind Harboe wrote: > (..) I would dearly like to see SWD done before > opening the floodgates to GPIO and other serial protocols. SWD is packed-based half-duplex bus that defines TRN operation for bus direction change and buffers reconfiguration. There is no SWD

Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT

On Mon, Jun 20, 2011 at 8:31 PM, Michael Schwingen wrote: > Am 06/20/2011 08:14 PM, schrieb Øyvind Harboe: >>> Please explain the dangers. >> If a driver can't implement a sane feature safely, then the driver shouldn't >> implement that feature > Fine. > > I *do* think hardware should be desig

Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT

Am 06/20/2011 08:14 PM, schrieb Øyvind Harboe: >> Please explain the dangers. > If a driver can't implement a sane feature safely, then the driver shouldn't > implement that feature Fine. I *do* think hardware should be designed in a way that it can not be damaged by software, but if existing

Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT

On Mon, Jun 20, 2011 at 8:26 PM, Phil Fong wrote: > (Resending since I forgot to cc the list) > > There is at least one useful end-user use case for bitbanging. There is no end of useful and possible to implement features. As a maintainer I draw the line at what we can follow up on in any reasona

Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT

(Resending since I forgot to cc the list) There is at least one useful end-user use case for bitbanging.  There are many IO lines unused on the FTDI port that can be used for GPIO.  Some dongles expose these and of course a custom FTDI interface that you integrate with your prototype can expos

Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT

> Please explain the dangers. If a driver can't implement a sane feature safely, then the driver shouldn't implement that feature One of the reasons I'm not excited about adding the IO features to OpenOCD is that we have barely enough maintainer resources as is. If a maintainer came out of th

Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT

Am 06/20/2011 02:44 PM, schrieb Laurent Gauch: >> only one transport option; autoselect 'jtag' >> > interface_signal list >> interface_signal list >> Interface Signal Name |Mask| Value >> -- >> > interface_signal add

Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT

Laurent, 1. If you create cable that have ADC onboard (like KT-LINK) then it is easier to write simple TCL script to read ADC than rewrite whole driver in the source code. 2. If you need to program I2C, SPI, or other kind of memory, you simply write simple TCL script to do so, no need to rewrite

Re: [Openocd-development] [PATCH] Implementation of a remote bitbang jtag driver

Thanks for the patch. Note that the community will be more interested in this work if comes with some host driver or description of application. If this is just one end of a mysterious application, then the incentive accept it and maintain it is very low. Please see about providing a git patch to

Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT

Hi Øyvind Harboe, Please refrain from shouting(using uppercase). It's more likely that people will ignore your email than read it. Thank you for the advice. As a maintainer, I'm not terribly excited about bitbanging and other non-CPU related protocols. Projects like UrJTAG pursue this sort

Re: [Openocd-development] [PATCH] Implementation of a remote bitbang jtag driver

Attached is an updated remote_bitbang patch with the additional error propagation. The remote_bitbang driver can be enabled and disabled by configure script (unless I'm missing something). If I get permission I'll answer the other questions that have been asked regarding the remote bitbang dri

Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT

Please refrain from shouting(using uppercase). It's more likely that people will ignore your email than read it. As a maintainer, I'm not terribly excited about bitbanging and other non-CPU related protocols. Projects like UrJTAG pursue this sort of avenue. I'd like to see OpenOCD focusing on CPUs

Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal / OBJECTION

>/ On Mon, Jun 20, 2011 at 1:00 PM, Steve Bennett https://lists.berlios.de/mailman/listinfo/openocd-development>> wrote: />>/ On 20/06/2011, at 8:54 PM, Øyvind Harboe wrote: />>/ />>>/ On Mon, Jun 20, 2011 at 12:50 PM, Steve Bennett https://lists.berlios.de/mailman/listinfo/openocd-development>>

Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT

Sergey Lapin wrote: On Mon, Jun 20, 2011 at 4:44 PM, Laurent Gauch wrote: only one transport option; autoselect 'jtag' > interface_signal list interface_signal list Interface Signal Name |Mask| Value -- > interf

Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT

On Mon, Jun 20, 2011 at 4:44 PM, Laurent Gauch wrote: >>  only one transport option; autoselect 'jtag' >>  > interface_signal list >>  interface_signal list >>      Interface Signal Name      |    Mask    |   Value >>  -- >>  > interface_sign

[Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT

only one transport option; autoselect 'jtag' > interface_signal list interface_signal list Interface Signal Name |Mask| Value -- > interface_signal add led 8000 interface_signal add led 8000 There are no signals de

Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal

> Nothing to do with hardware. It's a problem with the driver. > See > http://www.mail-archive.com/openocd-development@lists.berlios.de/msg15945.html So perhaps it does merit a comment? :-) -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / Internationa

Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal

On 20/06/2011, at 9:51 PM, Øyvind Harboe wrote: > On Mon, Jun 20, 2011 at 1:00 PM, Steve Bennett wrote: >> On 20/06/2011, at 8:54 PM, Øyvind Harboe wrote: >> >>> On Mon, Jun 20, 2011 at 12:50 PM, Steve Bennett >>> wrote: Instead, just produce a warning >>> >>> Why? >>> >>> It merits a

Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal

On Mon, Jun 20, 2011 at 1:00 PM, Steve Bennett wrote: > On 20/06/2011, at 8:54 PM, Øyvind Harboe wrote: > >> On Mon, Jun 20, 2011 at 12:50 PM, Steve Bennett >> wrote: >>> Instead, just produce a warning >> >> Why? >> >> It merits a comment at least? > > Seems self-evident to me. > Why should it

Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal

On 20/06/2011, at 8:54 PM, Øyvind Harboe wrote: > On Mon, Jun 20, 2011 at 12:50 PM, Steve Bennett > wrote: >> Instead, just produce a warning > > Why? > > It merits a comment at least? Seems self-evident to me. Why should it be fatal just because a value couldn't be read? Doesn't stop anythin

Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal

On Mon, Jun 20, 2011 at 12:50 PM, Steve Bennett wrote: > Instead, just produce a warning Why? It merits a comment at least? -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM

[Openocd-development] [PATCH 3/3] ft2232: Add casts to avoid warnings

The default is -Werror, so warnings become errors and stop the build. Might be better to simply #define FT_STATUS instead. Signed-off-by: Steve Bennett --- src/jtag/drivers/ft2232.c | 88 ++-- 1 files changed, 44 insertions(+), 44 deletions(-) diff --gi

[Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal

Instead, just produce a warning Signed-off-by: Steve Bennett --- src/jtag/drivers/ft2232.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/src/jtag/drivers/ft2232.c b/src/jtag/drivers/ft2232.c index 38ead56..2e0495d 100644 --- a/src/jtag/drivers/ft2232.c +++ b/src/jtag

[Openocd-development] [PATCH 1/3] ft2232: Fix configure --with-ftd2xx-linux-tardir

For libftd2xx1.0.4, which uses a different directory structure than libftd2xx0.4.16 Note that this does not fix --with-ftd2xx-lib=shared Also it assumes i386, not x86_64. Signed-off-by: Steve Bennett --- configure.in | 17 + 1 files changed, 9 insertions(+), 8 deletions(-) di

[Openocd-development] [PATCH 0/3] Fixes to build with latest ftd2xx

I needed these fixes to get libftd2xx1.0.4 building and running on Linux. Could still be improved for shared library support and detection of i386 vs x86_64. Steve Bennett (3): ft2232: Fix configure --with-ftd2xx-linux-tardir ft2232: Failure to get latency should not be fatal ft2232: Add cas