[Openocd-development] Oenocd git building under Mac OS X Lion
The Sourceforge Mailing List does not seem to work so I send again to this old mailing list. I am have two problems building openocd git head under my newly bought Mac Mini running Mac OS X Lion. The main problem is related to jimtcl. I am not so sure why options like --enable-jlink --enable-ft2232_libftdi --disable-werror are passed to jimtcl and apparently jimtcl does not like these options under Mac OS X. Under Ubuntu 11.10, things works since the top level configure is passing --disable-option-checking to the jimtcl configure. Not so sure why this does not work under Mac OS X. BTW, I am not using Macports or Fink, but rather homebrew. So the tools mostly come from XCode. mcuee@GX620Ubuntu:~/Desktop/build/openocd/openocd/build$ ... === configuring in jimtcl (/home/mcuee/Desktop/build/openocd/openocd/build/jimtcl) configure: running /bin/bash ../../jimtcl/configure.gnu --disable-option-checking '--prefix=/usr/local' '--enable-maintainer-mode' '--enable-jlink' '--enable-ft2232_libftdi' '--disable-werror' '--disable-shared' --cache-file=/dev/null --srcdir=../../jimtcl ... There is also a strange problem related to libusb-1.0 but that may be a separate issue. BTW, 0.5.0 release has no problem. Xiaofans-Mac-mini:build_libftdi xiaofanc$ ../configure --enable-maintainer-mode --enable-jlink --enable-ft2232_libftdi --disable-werror --disable-shared ... checking Build Link with libftdi.. Success checking for libftdi highspeed device support... yes checking libusb-1.0/libusb.h usability... yes checking libusb-1.0/libusb.h presence... yes checking for libusb-1.0/libusb.h... yes checking for environ in unistd.h and stdlib.h... no checking for extern environ... yes checking for a C compiler for build tools... gcc -std=gnu99 checking for suffix of executable build tools... configure: creating ./config.status config.status: creating Makefile ... config.status: creating config.h config.status: executing depfiles commands config.status: executing libtool commands === configuring in jimtcl (/Users/xiaofanc/work/openocd/openocd/build_libftdi/jimtcl) configure: running /bin/sh ../../jimtcl/configure.gnu '--prefix=/usr/local' '--enable-maintainer-mode' '--enable-jlink' '--enable-ft2232_libftdi' '--disable-werror' '--disable-shared' --cache-file=/dev/null --srcdir=../../jimtcl Host System...x86_64-apple-darwin11.2.0 Build System...x86_64-apple-darwin11.2.0 C compiler... cc -g -O2 C++ compiler... c++ -g -O2 Build C compiler...cc Checking for stdlib.h...ok Error: Unknown option --werror Try: 'configure --help' for options configure: error: ../../jimtcl/configure.gnu failed for jimtcl Xiaofans-Mac-mini:build_libftdi xiaofanc$ cd jimtcl/ Xiaofans-Mac-mini:jimtcl xiaofanc$ /bin/sh ../../jimtcl/configure.gnu '--prefix=/usr/local' '--enable-maintainer-mode' '--disable-shared' This works. Xiaofans-Mac-mini:jimtcl xiaofanc$ cd .. Xiaofans-Mac-mini:build_libftdi xiaofanc$ make ... /bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99 -g -O2 -Wall -Wstrict-prototypes -Wformat-security -Wshadow -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -o openocd main.o libopenocd.la ../jimtcl/libjim.a -lftdi -lusb libtool: link: gcc -std=gnu99 -g -O2 -Wall -Wstrict-prototypes -Wformat-security -Wshadow -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -o openocd main.o ./.libs/libopenocd.a -L/usr/local/Cellar/libusb/1.09rc3/lib /usr/local/lib/libusb-1.0.0.0.0.dylib ../jimtcl/libjim.a -lftdi /usr/local/Cellar/libusb-compat/0.1/lib/libusb.dylib /usr/local/Cellar/libusb/1.09rc3/lib/libusb-1.0.0.1.0.dylib -lobjc -pthread i686-apple-darwin11-llvm-gcc-4.2: /usr/local/lib/libusb-1.0.0.0.0.dylib: No such file or directory make[4]: *** [openocd] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 I am not so sure why it asks for /usr/local/lib/libusb-1.0.0.0.0.dylib, there is no such file. Change that one and I can build openocd git. Xiaofans-Mac-mini:build_libftdi xiaofanc$ ls /usr/local/lib/libusb* /usr/local/lib/libusb-0.1.4.dylib /usr/local/lib/libusb-1.0.la /usr/local/lib/libusb-1.0.0.1.0.dylib /usr/local/lib/libusb.a /usr/local/lib/libusb-1.0.0.dylib /usr/local/lib/libusb.dylib /usr/local/lib/libusb-1.0.a /usr/local/lib/libusb.la /usr/local/lib/libusb-1.0.dylib Xiaofans-Mac-mini:build_libftdi xiaofanc$ cd src/ Xiaofans-Mac-mini:src xiaofanc$ gcc -std=gnu99 -g -O2 -Wall -Wstrict-prototypes -Wformat-security -Wshadow -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -o openocd main.o ./.libs/libopenocd.a -L/usr/local/Cellar/libusb/1.09rc3/lib /usr/local/lib/libusb-1.0.0.1.0.dylib ../jimtcl/libjim.a -lftdi /usr/local/Cellar/libusb-compat/0.1/lib/libusb.dylib /usr/local/Cellar/libusb/1.09rc3/lib/libusb-1.0.0.1.0.dylib -lobjc -pthread Xiaofans-Mac-mini:src xiaofanc$ ./openocd -v Open On-Chip Debugger 0.6.0-dev-00287-g886ea0b
Re: [Openocd-development] [OpenOCD-devel] Request For Help
On Thu, Nov 24, 2011 at 3:59 AM, Mashal al-shboul shboul8...@yahoo.com wrote: Hi Xiaofan ,Thanks for replying i use libftd2xx0.4.16 and openOCD 0.5.0 actually my target is to run make intelmote2 install openocd which halts at starting openOCD i installed the follwoing packages(from software center) : libftdi1,libftdi1-dev, libftdipp-dev,libftdipp1,libftdipp1-dbg, but still halting at starting openocd... and by : openocd -f /usr/local/etc/arm-usb-tiny.cfg command i get: Error: The specified debug interface was not found (ft2232) The following debug interfaces are available: Runtime Error: /usr/local/etc/arm-usb-tiny.cfg:19: in procedure 'script' at file embedded:startup.tcl, line 58 in procedure 'interface' called at file /usr/local/etc/arm-usb-tiny.cfg, line 19 regarding the link you gave, i downloaded it, but i already have the same folder openOCD 0.5.0 ,should i replace it even though?. Ah you are using Linux. In that case, the link I provided does not apply since it is for Windows. In the case of Linux, please try to avoid ftd2xx as it does not really offer much benefits compared to libftdi. You should try to build with libftdi and see if that helps. If you use ftd2xx, you need to follow the instructions of the ftd2xx package to install the files to the correct directory. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Still J-Link problems
On Thu, Nov 3, 2011 at 4:42 PM, Vaclav Peroutka vacla...@seznam.cz wrote:
I updated FW, but it was rolled back to some older version from Sep 2008.
Whenever I run JLink commander, I am getting the message about old FW. I run
updater:
SEGGER J-Link Commander V4.35h ('?' for help)
Compiled Sep 27 2011 18:09:42
Updating firmware: J-Link ARM V8 compiled Sep 22 2011 16:23:23
Replacing firmware: J-Link ARM V8 compiled Sep 17 2008 21:12:23
Waiting for new firmware to boot
New firmware booted successfully
DLL version V4.35h, compiled Sep 27 2011 18:09:27
Firmware: J-Link ARM V8 compiled Sep 22 2011 16:23:23
S/N: 20100214
Feature(s): RDI,FlashDL,FlashBP,JFlash,GDBFull
J-Link
But then I exit JLink commander, again start it and still, FW version is the
older one.
4.35h is a beta version, probably you can try the new release version
which is 4.36g.
http://www.segger.com/jlink-software.html
Or you can try to the old version to get OpenOCD to work again.
http://www.segger.com/j-link-older-versions.html
--
Xiaofan
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Does openocd support cortex A5?
On Wed, Oct 26, 2011 at 11:04 AM, Richard LIU richard.liu...@gmail.com wrote: Does openocd support cortex A5? The answer seems to be no. Any public resource for A5 chips in real world other than the information from ARM? The only one seems to be from Freescale, A5 + M4 hybrid core. http://www.engadget.com/2011/10/25/freescale-joins-arm-a5-and-m4-cores-at-the-hip-for-performance-a/ -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Does openocd support cortex A5?
On Thu, Oct 27, 2011 at 10:14 AM, Richard LIU richard.liu...@gmail.com wrote: Thanks a lot, xiaofan. My chip is MSM7x27A. If it does not support, I try to port it. Ah I see. This seems to be a very new chip and indeed seems to be based on Cortex A5 core based on Google. http://forum.beyond3d.com/showthread.php?t=60402 -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] status of cortex-m0
On Thu, Oct 27, 2011 at 11:24 AM, Christopher Harvey ch...@basementcode.com wrote: I read a thread about somebody who apparently got cortex m0 cores working with OpenOCD. (based on the m3 code). Did that patch ever get posted somewhere? Anybody following/working on m0 right now? The Cortex M0 support will most likely depend on the SWD support which is now on progress. Reference thread. http://lists.berlios.de/pipermail/openocd-development/2011-June/019303.html Not so sure about the status on Versaloon's swd implementation. You can check with Simon Qian. http://www.versaloon.com/index.html http://lists.berlios.de/pipermail/openocd-development/2011-April/018838.html -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Command-line paths problem in Windows
On Sat, Oct 22, 2011 at 4:05 PM, Freddie Chopin freddie_cho...@op.pl wrote: The change that Steve Bennett suggested me in email is now posted to Gerrit and it solves the problem. uplevel #0 [list source [find $filename]] Great, hopefully this will get committed soon. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Gerrit background
On Fri, Oct 21, 2011 at 1:15 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: That is of course right. But that does not answer my question. I think it is good to change the wording of -1 to something like some changes are necessary before this patch can be accepted. I think most people will understand that this is a textstring within Gerrit. I am not among that most people and I think majority of the people here would not bother to look at the codes of Gerrit. It is just a tool after all. Perhaps you can talk to the developers upstream? OpenOCD just uses Gerrit. What you've find may be a beauty spot depending on who you ask. I understand that. I think this is not a big problem so I would not bother to talk to upstream people about this. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Command-line paths problem in Windows
On Fri, Oct 21, 2011 at 7:06 PM, Spencer Oliver s...@spen-soft.co.uk wrote: On 20 October 2011 17:04, Freddie Chopin freddie_cho...@op.pl wrote: The only working version that I've found is: openocd -f ../interface/jtagkey.cfg -f ../target/stm32.cfg i cannot reproduce this problem, any more details. I can reproduce the issue with the latest git, build under Windows with MinGW/MSys. For version 0.5.0, the following two commands work and I use only either of them. openocd.exe -f board\ek-lm3s1968.cfg openocd.exe -f board/ek-lm3s1968.cfg For latest git, none of the following commands work. openocd.exe -f board\ek-lm3s1968.cfg openocd.exe -f board/ek-lm3s1968.cfg openocd.exe -f board\\ek-lm3s1968.cfg openocd.exe -f board//ek-lm3s1968.cfg openocd.exe -f ..\board\ek-lm3s1968.cfg Example running log. C:\work\openocd\binary\binopenocd.exe -f board//ek-lm3s1968.cfg Open On-Chip Debugger 0.6.0-dev-snapshot (2011-10-21-21:26) Licensed under GNU GPL v2 For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.html Runtime Error: embedded:startup.tcl:58: couldn't read file C:workopenocinarin.. /board//ek-lm3s1968.cfg: No such file or directory in procedure 'script' at file embedded:startup.tcl, line 58 C:\work\openocd\binary\binopenocd.exe -f ..\board\ek-lm3s1968.cfg Open On-Chip Debugger 0.6.0-dev-snapshot (2011-10-21-21:26) Licensed under GNU GPL v2 For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.html Runtime Error: embedded:startup.tcl:58: couldn't read file .oardek-lm3s1968.cfg : No such file or directory in procedure 'script' at file embedded:startup.tcl, line 58 Double backslash seems to fix it. That helps. The following commands work. openocd.exe -f ..\\board\\ek-lm3s1968.cfg openocd.exe -f ..//board//ek-lm3s1968.cfg The following command also works. openocd.exe -f ../board/ek-lm3s1968.cfg -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Command-line paths problem in Windows
On Fri, Oct 21, 2011 at 11:06 PM, Peter Stuge pe...@stuge.se wrote: So there are two differences in behavior versus 0.5: 1. \ in -f parameters get evaluated one time extra by Jim tcl 2. paths in -f parameters are now relative to a different directory, one level down from previously 2. is most likely caused by another commit. Yes you are right. I moved openocd.exe out of bin directory to make it in the same directory of the scripts files (board, interface, etc) and 2 will go away. C:\work\openocd\binaryopenocd -f board/ek-lm3s1968.cfg Open On-Chip Debugger 0.6.0-dev-snapshot (2011-10-21-21:26) Licensed under GNU GPL v2 For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' 500 kHz ... The other command used to work for version 0.5.0 still does not work. C:\work\openocd\binaryopenocd -f board\ek-lm3s1968.cfg Open On-Chip Debugger 0.6.0-dev-snapshot (2011-10-21-21:26) Licensed under GNU GPL v2 For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.html Runtime Error: embedded:startup.tcl:58: couldn't read file boardek-lm3s1968.cfg: No such file or directory in procedure 'script' at file embedded:startup.tcl, line 58 -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Command-line paths problem in Windows
On Fri, Oct 21, 2011 at 11:37 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Fri, Oct 21, 2011 at 11:06 PM, Peter Stuge pe...@stuge.se wrote: So there are two differences in behavior versus 0.5: 1. \ in -f parameters get evaluated one time extra by Jim tcl 2. paths in -f parameters are now relative to a different directory, one level down from previously 2. is most likely caused by another commit. Yes you are right. I moved openocd.exe out of bin directory to make it in the same directory of the scripts files (board, interface, etc) and 2 will go away. C:\work\openocd\binaryopenocd -f board/ek-lm3s1968.cfg Open On-Chip Debugger 0.6.0-dev-snapshot (2011-10-21-21:26) Licensed under GNU GPL v2 For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' 500 kHz ... The other command used to work for version 0.5.0 still does not work. C:\work\openocd\binaryopenocd -f board\ek-lm3s1968.cfg Open On-Chip Debugger 0.6.0-dev-snapshot (2011-10-21-21:26) Licensed under GNU GPL v2 For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.html Runtime Error: embedded:startup.tcl:58: couldn't read file boardek-lm3s1968.cfg: No such file or directory in procedure 'script' at file embedded:startup.tcl, line 58 The following does work now. C:\work\openocd\binaryopenocd -f board\\ek-lm3s1968.cfg Open On-Chip Debugger 0.6.0-dev-snapshot (2011-10-21-21:26) Licensed under GNU GPL v2 For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' 500 kHz ... -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Command-line paths problem in Windows
On Sat, Oct 22, 2011 at 1:52 AM, Freddie Chopin freddie_cho...@op.pl wrote: Why can't we revert a change, fixing a bug and wait for a real jimtcl-expert (Steve) to discuss other alternatives while in the meantime OpenOCD would work as expected for Windows users? The problem is that Windows paths now cannot be used normally and OpenOCD cannot be used as before. Global variables thing which this patch (supposedly) improves is just an improvement, because you could use globals before anyway, just had to add global NAME before. Please revert to fix a real problem (removing backslashes from Windows paths). We can deal with improvement while at the same time OpenOCD works as it should. I have to agree with you here. Make things work first, nice to have but not essential things can come later. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Gerrit background
On Thu, Oct 20, 2011 at 3:23 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: First of all, I'd like everybody to stand up and give a big hand to Spencer who's through his efforts has saved OpenOCD from a slow torturous demise! ... Who knows what percentage of fixes to OpenOCD that ever make it into the repository. 10%? 5%? 50%? With Gerrit we've raised it from 0% to n%. Again! I'd like everybody to give a big round of applause to Spencer who's spent the time fixing the OpenOCD process by reading up on and setting up the Gerrit+Jenkins server I agree, this is great work. I am not a programmer myself and I can only contribute by testing or provide some suggestions based on my experiences with testing of other projects (libusb, libusb-win32, libftdi, etc). So I am kind of an outsider of this git/gerrit stuff (I admit I know very little of git, even less about gerrit), but from what I see so far, I think this is a good move. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Gerrit background
On Thu, Oct 20, 2011 at 3:33 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: I agree, this is great work. I am not a programmer myself and I can only contribute by testing or provide some suggestions based on my experiences with testing of other projects (libusb, libusb-win32, libftdi, etc). So I am kind of an outsider of this git/gerrit stuff (I admit I know very little of git, even less about gerrit), but from what I see so far, I think this is a good move. Still you can get a Gerrit account to read over patches and give comments! All you need is a web browser, you can do it on the train using your cell phone if you're a commuter :-) If you give a patch your approval, then that input will be very much appreciated and result in real improvements to code and patches being committed more rapidly. Done. Just post my first comment. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Gerrit background
On Thu, Oct 20, 2011 at 7:59 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Thu, Oct 20, 2011 at 3:33 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: Still you can get a Gerrit account to read over patches and give comments! All you need is a web browser, you can do it on the train using your cell phone if you're a commuter :-) If you give a patch your approval, then that input will be very much appreciated and result in real improvements to code and patches being committed more rapidly. Done. Just post my first comment. I feel the following category is too coarse. +1 Looks good to me, but someone else must approve 0 No score -1 I would prefer that you didn't submit this I would like to have something like, Looks pretty good, but some enhancements are needed. -1 is too harsh in the case of the J-Link libusb-1.0 patch. 0 rather says nothing. And I do not want to give 1 in this case since I think some changes are necessary. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Gerrit background
On Thu, Oct 20, 2011 at 9:14 PM, Peter Stuge pe...@stuge.se wrote: Xiaofan Chen wrote: -1 is too harsh in the case of the J-Link libusb-1.0 patch. I think it fits, because: I think some changes are necessary. This is what you say with -1. You don't think this should be added exactly as-is. It can sometimes be nice to use the comment field in addition to inline comments, to expand a little in general on the chosen scoring and what needs further improvement, if that isn't clear from inline comments already. -1 isn't Never ever but rather Not yet. The what is missing has to be explained manually, which I think is a very important step. (Ie. writing concrete comments, as you did.) Then please change the wording of -1 +1 Looks good to me, but someone else must approve 0 No score -1 I would prefer that you didn't submit this If the contributor see a -1 and refer to the above, I do not think it is that encouraging. :-). -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Gerrit background
On Fri, Oct 21, 2011 at 12:32 AM, Peter Stuge pe...@stuge.se wrote: Xiaofan Chen wrote: Then please change the wording of -1 +1 Looks good to me, but someone else must approve 0 No score -1 I would prefer that you didn't submit this If the contributor see a -1 and refer to the above, I do not think it is that encouraging. :-). I think it is very important to always write some explanations for why a change should not be submitted (which is the Gerrit term for adding the change into the public repository), so that the contributor knows why the change is not yet acceptable. That is of course right. But that does not answer my question. I think it is good to change the wording of -1 to something like some changes are necessary before this patch can be accepted. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm-jtag-ew + swd
On Thu, Oct 20, 2011 at 11:54 AM, Michael Ashton d...@gtf.org wrote: JLink specification is open, from what Ive seen it should be relatively easy to implement generic (tranfer/bitbang functions) driver for this device :-) I noticed that too. Segger's GDB server is Windows-only, which can be inconvenient. Their documentation for their USB protocol looks very complete. Once you start to work with J-Link, you will know how incomplete it is. The main issue is that there are many different versions of J-Link with a bit different in the behaviour. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Change in openocd[master]: jlink libusb1 driver with libusb1 common driver interface.
On Wed, Oct 19, 2011 at 11:55 PM, Spencer Oliver s...@spen-soft.co.uk wrote: On 19 October 2011 16:38, Mauro Gamba maurill...@gmail.com wrote: Sorry for patch errors. I started to patch the jlink driver to use libusb-1 because libusb-0 is not developed further. I haven't done speed tests until now. http://openocd.zylin.com/33 adds libusb-1.0 support to the jlink. Just wondering if anyone had any input on this ? I believe the approach to only uss libusb-1.0 for J-Link is not a good approach. My idea is to have both options, just like urjtag. When libusb-1.0 is available and specified by the user, it should use libusb-1.0, other wise, it will fall back to libusb-0.1. Benefits of providing both: 1) Make the regression testing easier. 2) Make J-Link to work on platforms where libusb-1.0 is not available, like Solaris/NetBSD/OpenBSD, and older version of FreeBSD, and maybe some embedded Linux platform, and Windows 2000. 3) Make users who prefer to use libusb-0.1 can use libusb-0.1, say Windows users who prefer to keep both Segger driver (to use IAR/Keil/etc) and OpenOCD -- they can use libusb-win32 filter driver. Take note libusb-1.0 Windows does not support libusb0.sys backend now and that makes it not working with the filter driver. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Change in openocd[master]: jlink libusb1 driver with libusb1 common driver interface.
On Thu, Oct 20, 2011 at 1:02 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Wed, Oct 19, 2011 at 11:55 PM, Spencer Oliver s...@spen-soft.co.uk wrote: http://openocd.zylin.com/33 adds libusb-1.0 support to the jlink. Just wondering if anyone had any input on this ? I believe the approach to only uss libusb-1.0 for J-Link is not a good approach. My idea is to have both options, just like urjtag. When libusb-1.0 is available and specified by the user, it should use libusb-1.0, other wise, it will fall back to libusb-0.1. Benefits of providing both: 1) Make the regression testing easier. 2) Make J-Link to work on platforms where libusb-1.0 is not available, like Solaris/NetBSD/OpenBSD, and older version of FreeBSD, and maybe some embedded Linux platform, and Windows 2000. 3) Make users who prefer to use libusb-0.1 can use libusb-0.1, say Windows users who prefer to keep both Segger driver (to use IAR/Keil/etc) and OpenOCD -- they can use libusb-win32 filter driver. Take note libusb-1.0 Windows does not support libusb0.sys backend now and that makes it not working with the filter driver. Again, I will point the link to urjtag. http://urjtag.git.sourceforge.net/git/gitweb.cgi?p=urjtag/urjtag;a=tree;f=urjtag/src/tap/usbconn;hb=HEAD In terms of the simple wrapper of libusb-1.0, I think this is a good first try. On the other hand, the function jtag_libusb_match() can probably take one more parameter serial_number so that some debuggers can benefits from the support of multiple units. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fwd: [PATCH] Start porting of usb jtag drivers to libusb-1.0 instead of libusb.0.1
On Tue, Oct 11, 2011 at 6:37 AM, Peter Stuge pe...@stuge.se wrote:
+ AC_CHECK_HEADERS([libusb-1.0/libusb.h],[],
+ [AC_MSG_ERROR([libusb.h is required to build some OpenOCD driver(s)])])
Please use pkg-config.
pkg-config(1) http://linux.die.net/man/1/pkg-config mentions the
autoconf macro to use:
PKG_CHECK_MODULES(VARIABLE-PREFIX,MODULES[,ACTION-IF-FOUND,[ACTION-IF-NOT-FOUND]])
as well as the added variables that will be available. Suggest use:
PKG_CHECK_MODULES([LIBUSB1], [libusb-1.0 = 1.0.8])
Please also consider where pkg_config is usually not available, like in the
case of MinGW under Windows.
@@ -1426,7 +1425,7 @@ static struct jlink* jlink_usb_open()
#if IS_WIN32 == 0
- usb_reset(dev);
+ libusb_reset_device(devh);
Unsure. libusb_reset_device() shouldn't really need to be used in the
common case..
I remember this was necessary last time some of us were
testing OpenOCD with J-Link.
On the other hand, this may well be not necessary now
but the best is to look at Segger J-Link utility and see
if it issues a reset in the beginning or not.
(Also, libusb-1.0 works to some degree on Windows.)
http://www.libusb.org/wiki/windows_backend#KnownRestrictions
libusb_reset_device() does not work with the current WinUSB
backend for libusb-1.0 Windows.
The following codes are obviously hacky but you can see that
any changes in these codes deserve great scrutiny.
/* BE ***VERY CAREFUL*** ABOUT MAKING CHANGES IN THIS
* AREA!!! The behavior of libusb is not completely
* consistent across Windows, Linux, and Mac OS X platforms.
* The actions taken in the following compiler conditionals may
* not agree with published documentation for libusb, but were
* found to be necessary through trials and tribulations. Even
* little tweaks can break one or more platforms, so if you do
* make changes test them carefully on all platforms before
* committing them!
*/
#if IS_WIN32 == 0
usb_reset(dev);
#if IS_DARWIN == 0
int timeout = 5;
/* reopen jlink after usb_reset
* on win32 this may take a second or two to re-enumerate */
int retval;
while ((retval = jtag_usb_open(vids, pids, dev)) != ERROR_OK)
{
usleep(1000);
timeout--;
if (!timeout) {
break;
}
}
if (ERROR_OK != retval)
return NULL;
#endif
#endif
@@ -1460,27 +1459,46 @@ static struct jlink* jlink_usb_open()
..
+ dev = libusb_get_device(devh);
+ struct libusb_config_descriptor *config;
+ libusb_get_config_descriptor(dev, 0, config);
+
+ const struct libusb_interface *inter;
+ const struct libusb_interface_descriptor *interdesc;
+ const struct libusb_endpoint_descriptor *epdesc;
+
+ for(int i=0; i(int)config-bNumInterfaces; i++)
+ for(int j=0; jinter-num_altsetting; j++)
+ for(int k=0; k(int)interdesc-bNumEndpoints; k++)
Is this necessary? Aren't the endpoint addresses always the same?
No, not always the same.
Or does the driver support so many jlink devices with so many different
USB interface variants that there's no way to get around it?
That is right, there are different version of J-Link with different
endpoints configuration.
I'm thinking a little about how to best get your work into OpenOCD.
I think the best way is to start with one driver, and send a patch
that changes only that one driver over to use libusb-1.0, but leaves
the existing ones untouched. This means that you may need to create
some duplicated functionality outside the driver, for drivers which
use libusb-1.0, but I think this is OK, it will not likely be any
significant amount of code, so be fairly quick to create, and not
take much place. Once it is in place, you and others can more easily
work on moving other drivers to libusb-1.0 in parallel. It's not at
all necessary that you are the only doing that work.
I agree with this approach.
UrJtag can be a reference as well, since it support either libusb-1.0,
libusb-0.x/libusb-win32, or mix. It also supports either libftdi-1.0 or
libftdi-0.x.
http://urjtag.git.sourceforge.net/git/gitweb.cgi?p=urjtag/urjtag;a=tree
--
Xiaofan
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fwd: [PATCH] Start porting of usb jtag drivers to libusb-1.0 instead of libusb.0.1
On Tue, Oct 11, 2011 at 12:24 PM, Peter Stuge pe...@stuge.se wrote: Xiaofan Chen wrote: Or does the driver support so many jlink devices with so many different USB interface variants that there's no way to get around it? That is right, there are different version of J-Link with different endpoints configuration. With the same vidpid? Meh. :( Yes, different output endpoint used but with the same VID/PID. For example, with V3 J-Link, the following is the output of USBView (under Windows now). V4 may be the same (I have not seen V1/V2/V4). Device Descriptor: bcdUSB: 0x0110 bDeviceClass: 0x00 bDeviceSubClass: 0x00 bDeviceProtocol: 0x00 bMaxPacketSize0: 0x08 (8) idVendor: 0x1366 idProduct: 0x0101 bcdDevice: 0x0001 iManufacturer:0x01 iProduct: 0x02 iSerialNumber:0x03 bNumConfigurations: 0x01 ConnectionStatus: DeviceConnected Current Config Value: 0x01 Device Bus Speed: Full Device Address: 0x01 Open Pipes: 2 Endpoint Descriptor: bEndpointAddress: 0x81 IN Transfer Type:Bulk wMaxPacketSize: 0x0040 (64) bInterval:0x00 Endpoint Descriptor: bEndpointAddress: 0x01 OUT Transfer Type:Bulk wMaxPacketSize: 0x0040 (64) bInterval:0x00 With V7, the output is like this. V6/V8/Pro should be the same. Probably V5 as well. I have not seen a V5 or an Ultra yet. Device Descriptor: bcdUSB: 0x0110 bDeviceClass: 0x00 bDeviceSubClass: 0x00 bDeviceProtocol: 0x00 bMaxPacketSize0: 0x08 (8) idVendor: 0x1366 idProduct: 0x0101 bcdDevice: 0x0001 iManufacturer:0x01 iProduct: 0x02 iSerialNumber:0x03 bNumConfigurations: 0x01 ConnectionStatus: DeviceConnected Current Config Value: 0x01 Device Bus Speed: Full Device Address: 0x01 Open Pipes: 2 Endpoint Descriptor: bEndpointAddress: 0x81 IN Transfer Type:Bulk wMaxPacketSize: 0x0040 (64) bInterval:0x00 Endpoint Descriptor: bEndpointAddress: 0x02 OUT Transfer Type:Bulk wMaxPacketSize: 0x0040 (64) bInterval:0x00 -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fwd: [PATCH] Start porting of usb jtag drivers to libusb-1.0 instead of libusb.0.1
On Tue, Oct 11, 2011 at 10:22 AM, Xiaofan Chen xiaof...@gmail.com wrote: On Tue, Oct 11, 2011 at 6:37 AM, Peter Stuge pe...@stuge.se wrote: I'm thinking a little about how to best get your work into OpenOCD. I think the best way is to start with one driver, and send a patch that changes only that one driver over to use libusb-1.0, but leaves the existing ones untouched. This means that you may need to create some duplicated functionality outside the driver, for drivers which use libusb-1.0, but I think this is OK, it will not likely be any significant amount of code, so be fairly quick to create, and not take much place. Once it is in place, you and others can more easily work on moving other drivers to libusb-1.0 in parallel. It's not at all necessary that you are the only doing that work. I agree with this approach. UrJtag can be a reference as well, since it support either libusb-1.0, libusb-0.x/libusb-win32, or mix. It also supports either libftdi-1.0 or libftdi-0.x. http://urjtag.git.sourceforge.net/git/gitweb.cgi?p=urjtag/urjtag;a=tree I think urjtag's approach is good, to abstract libusb-1.0 and libusb, as well as libftdi-1.0/libftdi/libftd2xx. http://urjtag.git.sourceforge.net/git/gitweb.cgi?p=urjtag/urjtag;a=tree;f=urjtag/src/tap/usbconn;hb=HEAD -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fwd: Re: JLink woes
On Fri, Aug 19, 2011 at 9:03 PM, Antonio Borneo borneo.anto...@gmail.com wrote: On Fri, Aug 19, 2011 at 6:36 PM, Xiaofan Chen xiaof...@gmail.com wrote: [...] Thanks a lot for the updates. Yes I can confirm that V4.33h beta firmware fixed the issue with OpenOCD for V8 version of J-Link. Thanks for the help again. Very good news! Since the issue seams identified, can Segger suggest how to fix OpenOCD to support the versions after V4.14g and before V4.33h ? That would be nice. Otherwise I propose to let OpenOCD detect the incompatible versions and quit after an error message. Maybe this is the way to go for now. I think that the only way to check firmware version is through the date in the string Info : J-Link ARM V8 compiled Aug 18 2011 19:52:49 correct? Seems to be the case. Eg: From J-Link Commander under Windows. J-Linkf Firmware: J-Link ARM Lite V8 compiled Jan 31 2011 18:38:46 Hardware: V8.00 -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fwd: Re: JLink woes
On Fri, Aug 19, 2011 at 2:29 PM, SEGGER - Support J-Link (AG) support_jl...@segger.com wrote: On Fri, Aug 19, 2011 at 3:17 AM, SEGGER - Support J-Link (AG) support_jl...@segger.com wrote: Hi Eric, We have built a new beta version (V4.33h) which comes with a new firmware for J-Link in which the problem regarding OpenOCD has been fixed. Could you please give the new version a try and provide some feedback? Download-Link: http://www.segger.com/download_jlink_beta.html For now we only updated the firmware of the standard J-Link products (V8, Pro, Ultra, ...) which are directly sold to the customer. Firmware fixes for J-Link OB and Lite will follow shortly. Thanks a lot for the updates. Yes I can confirm that V4.33h beta firmware fixed the issue with OpenOCD for V8 version of J-Link. Thanks for the help again. D:\work\openocd\openocd_0.5.0_mingw\binopenocd_d2xx.exe -f ek-lm3s1968_jlink.cfg Open On-Chip Debugger 0.5.0 (2011-08-12-12:04) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Warn : Adapter driver 'jlink' did not declare which transports it allows; assuming legacy JTAG-only Info : only one transport option; autoselect 'jtag' 500 kHz Info : J-Link initialization started / target CPU reset initiated Info : J-Link ARM V8 compiled Aug 18 2011 19:52:49 Info : J-Link caps 0xb9ff7bbf Info : J-Link hw version 8 Info : J-Link hw type J-Link Info : J-Link max mem block 9424 Info : J-Link configuration Info : USB-Address: 0x0 Info : Kickstart power on JTAG-pin 19: 0xff01 Info : Vref = 3.222 TCK = 1 TDI = 0 TDO = 1 TMS = 0 SRST = 0 TRST = 0 Info : J-Link JTAG Interface ready Info : clock speed 500 kHz Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fwd: Re: JLink woes
On Fri, Aug 19, 2011 at 3:17 AM, SEGGER - Support J-Link (AG) support_jl...@segger.com wrote: Hi Eric, We have built a new beta version (V4.33h) which comes with a new firmware for J-Link in which the problem regarding OpenOCD has been fixed. Could you please give the new version a try and provide some feedback? Download-Link: http://www.segger.com/download_jlink_beta.html Best regards Alexander Grüner - J-Link Development / Support I will try with a real V8. But for a V8 Lite, the new version does not contain the new firmware and thus OpenOCD will still fail. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] couldn't read enough bytes from FT2232 device (0 81)
On Tue, Aug 16, 2011 at 9:18 PM, Eric Wetzel thewet...@gmail.com wrote: I'm not sure if Freddie's OpenOCD is built using libftdi-1.0, which previous e-mails indicate may solve this problem. As a last-ditch effort to try libftdi-1.0, I replaced the libfti.dll in Freddie's bin directory with the libftdi.dll from Xiaofan's build (http://code.google.com/p/picusb/downloads/detail?name=libftdi1_17July2011_mingw32_mingw64.zipcan=2q=). I get the same result. Hmm, interesting to know that would work. Freddie's OpenOCD binary and my binary are both using libftdi-0.19 and libusb-win32. Anybody have any hints? Is anybody else successfully using a Blackhawk USB100v2? I don't really think it's the interface itself because I get the same failure on a completely different target board using OpenOCD built from git on Linux at home... I think. From the past history, it seems that ftd2xx may help. So you may want to build with FTDI's latest D2xx library to see if that helps. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On Tue, Aug 16, 2011 at 6:13 PM, Spencer Oliver s...@spen-soft.co.uk wrote: On 16 August 2011 11:03, Steve Bennett ste...@workware.net.au wrote: Good news. Spencer and I sorted out the jimtcl build problem on mingw. The fix is in the jimtcl git repo. See: http://repo.or.cz/w/jimtcl.git/commit/645ed6fd4b6f9038c7e1d85d74c3872b3cb9a507 yah - i will update the openocd jim version Thanks now building under MinGW/MSys works fine. Thanks a lot. I also tested with cross 32bit MinGW build under 64bit Ubuntu 11.04 and it works fine as well. If there is going to be a 5.01 release, this should probably be included. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] JLink woes
On Mon, Aug 15, 2011 at 5:26 AM, Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com wrote: On 12:04 Sat 13 Aug , Carlson Gary wrote: Hi Eric, I have worked a little on the jlink stuff in the past and fixed a few problems with OpenOCD. I have a new project that is going to force me to buy an unrestricted Segger very shortly since my current jlink dongles are Atmel-only devices. Once I get my hands on a new one, I hopefully will be able to take a look at this problem also. I will try to contact Segger on Monday to see if they can shine some light on V8 communication details. I suspect whatever is wrong is probably minor, but will take a little persistence to identify a solution. I already contract Segger this year and their answer are we change nothing I put segger in Cc this time on the ML hope you will work with us to improve J-Link support on OpenOCD To be fair to Segger, I think they do not intentionally change anything in the firmware. After all, the firmware needs to be compatible with their own utility under Windows and Linux. On the other hand, they probably did not test OpenOCD since that was not their focus. From the usbmon log, Segger's Linux utility are consistent through different versions of J-Link. The main issue is that OpenOCD's J-Link initialization sequence is not the same as Segger's utility, as shown in Eric's previous email. I think Gary is probably correct that whatever is wrong (in OpenOCD) is probably minor. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD 0.5.0 for Windows
On Thu, Aug 11, 2011 at 1:59 AM, Freddie Chopin freddie_cho...@op.pl wrote: Hi! I've just posted Windows packages with OpenOCD 0.5.0 on my website - http://www.freddiechopin.info/ - enjoy (; BTW, your 64bit build will not work with those parallel port based dongles. The issue is the driver used, as far as I know there are no 64bit giveio.sys, and 32bit drivers will not work for 64bit Windows. Moreover, 64bit Windows Vista/Win7 (or 2008/2008R2) will require the driver to be signed (Kernel Mode Code Signing). http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/dc5bfae6-21d6-4e70-a7c1-4f548b607625/ I mentioned this issue back in 2009 but I think 64bit PCs usually do not have parallel port so nobody has tested your binary and find it does not work. :-) http://lists.berlios.de/pipermail/openocd-development/2009-July/009570.html Now that winring0 is gone, one potential replacement is this one. http://www.highrez.co.uk/Downloads/InpOut32/default.htm Google also find another one as well. http://www.downtowndougbrown.com/2010/10/sivava-willem-eprom-programmer-on-windows-7-64-bit/ -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Build error with mingw32
On Sat, Aug 13, 2011 at 9:38 AM, Jie Zhang jzhang...@gmail.com wrote: On Fri, Aug 12, 2011 at 9:27 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Sat, Aug 13, 2011 at 9:00 AM, Jie Zhang jzhang...@gmail.com wrote: Another option is to drop mingw32 and require mingw-w64. Do not do that. usleep is fine with later version of MinGW.org Win32API package. This is probably because you have a very old version of MinGW and MinGW Win32-API. Seems to be a problem with Debian. http://sourceforge.net/projects/mingw/files/MinGW/BaseSystem/RuntimeLibrary/Win32-API/ Debian seems to ship a 3-year old MinGW Win32-API. http://packages.debian.org/search?searchon=sourcenameskeywords=mingw32 Hmm, good point. I have written an email to the mingw32-runtime package maintainer of Debian to see if he has any plan to update it to the latest version. Hmm, I just test under Ubuntu 11.04 and cross compile the latest git works fine. It comes with mingw32-runtime version 3.15.2.0ubuntu1 and usleep is there. Supposedly Debian testing should come with newer version of packages than ubuntu. mcuee@Ubuntu:~/Desktop/build/openocd/build-win32-libftdi$ cat myconfig-win32-libftdi.sh ../openocd/configure --host=i586-mingw32msvc --build=i686-pc-linux-gnu --enable-maintainer-mode --disable-shared --disable-werror --enable-jlink --enable-ft2232_libftdi --enable-presto_libftdi --enable-usbprog --enable-vsllink --enable-usb_blaster_libftdi --enable-arm-jtag-ew --enable-rlink configure:12133: checking for gettimeofday configure:12133: i586-mingw32msvc-gcc -std=gnu99 -o conftest.exe -g -O2 conftest.c 5 configure:12133: $? = 0 configure:12133: result: yes configure:12144: checking for usleep configure:12144: i586-mingw32msvc-gcc -std=gnu99 -o conftest.exe -g -O2 conftest.c 5 configure:12144: $? = 0 configure:12144: result: yes BTW, your config.log seems to be quite strange. I do not see those things in my config.log. I only see jimtcl mentioned briefly. configure:16681: === configuring in jimtcl (/home/mcuee/Desktop/build/openocd/build-win32-libftdi/jimtcl) configure:16744: running /bin/bash ../../openocd/jimtcl/configure.gnu --disable-option-checking '--prefix=/usr/local' '--host=i586-mingw32msvc' '--build=i686-pc-linux-gnu' '--enable-maintainer-mode' '--disable-shared' '--disable-werror' '--enable-jlink' '--enable-ft2232_libftdi' '--enable-presto_libftdi' '--enable-usbprog' '--enable-vsllink' '--enable-usb_blaster_libftdi' '--enable-arm-jtag-ew' '--enable-rlink' 'build_alias=i686-pc-linux-gnu' 'host_alias=i586-mingw32msvc' --cache-file=/dev/null --srcdir=../../openocd/jimtcl -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] JLink woes
On Sat, Aug 13, 2011 at 10:59 PM, Eric Wetzel thewet...@gmail.com wrote: Alright, I didn't get around to trying your method yet; I've been capturing things from Segger's J-Link Linux program. Here's what I found. Segger's program sends two commands that are undocumented by the J-Link USB Protocol Reference Manual. The first is 0xE6, which returns 256 bytes of data. The first four bytes returned are the serial number of my unit, and the next row, starting from byte 16, is a null-terminated string of the OEM's name (in my case 'IAR'). The next undocumented command is 0x09. It seems to consist of 14 bytes and returns 76 bytes (but for some reason, my usbmon log is being truncated to just 64 bytes). Neither the command nor the response seem to contain ASCII strings. For my test cases, I ran the J-Link program, waited for it to stabilize, then exitted. I tested conditions like the first execution after plugging in the J-Link and successive executions, and having a target connected or not. Here are the forms of the 0x09 commands (responses not included): jlink-trace.txt: 0964a20c jlink-trace.txt: 0964a20c 0300 jlink-trace.txt: 0964a20c 0300 jlink-trace.txt: 0965a20c 0300 segger-after-plug-no-target.txt: 0964850e segger-after-plug-no-target.txt: 0964850e 0200 segger-after-plug-no-target.txt: 0965850e 0200 segger-after-plug-target.txt: 0964890e segger-after-plug-target.txt: 0964890e 0300 segger-after-plug-target.txt: 0964890e 0300 segger-after-plug-target.txt: 0965890e 0300 segger-first-plug-no-target.txt: 09647f0e segger-first-plug-no-target.txt: 09647f0e 0100 segger-first-plug-no-target.txt: 09657f0e 0100 segger-first-plug-target.txt: 0964970e segger-first-plug-target.txt: 0964970e 0100 segger-first-plug-target.txt: 0964970e 0100 segger-first-plug-target.txt: 0965970e 0100 Just want to say that I did some capture under Linux as well adn the result is similar to what you have. usbmon txt interface will truncate the data to 32 bytes. You can try to use the binary interface. http://www.mjmwired.net/kernel/Documentation/usb/usbmon.txt http://kerneltrap.org/mailarchive/linux-usb/2010/6/2/6261760/thread http://people.redhat.com/zaitcev/linux/index.html Pete Zaitcev is the author and he has the usbmon-6 program you can try out. Man file for usbmon-6. http://www.linuxcertif.com/man/8/usbmon/ -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] ST-Link support
I just came across this one and I am not so sure if it is in a good state or not. http://code.google.com/p/rio-source/source/browse/trunk/openocd-0.4.0-tag-stlink/src/jtag/drivers/stlink.c The protocol of st-link seems to be relatively clear now. https://github.com/texane/stlink http://capitanio.org/mlink/ (citing Spen's name) https://github.com/afaerber/stlink -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] JLink woes
On Sun, Aug 14, 2011 at 7:19 AM, Xiaofan Chen xiaof...@gmail.com wrote: On Sat, Aug 13, 2011 at 10:59 PM, Eric Wetzel thewet...@gmail.com wrote: Alright, I didn't get around to trying your method yet; I've been capturing things from Segger's J-Link Linux program. Here's what I found. Segger's program sends two commands that are undocumented by the J-Link USB Protocol Reference Manual. The first is 0xE6, which returns 256 bytes of data. The first four bytes returned are the serial number of my unit, and the next row, starting from byte 16, is a null-terminated string of the OEM's name (in my case 'IAR'). http://lists.berlios.de/pipermail/openocd-development/2009-May/006781.html ReadOTS (OTP Structure) input: 0xE6 (1 byte) output: OTS buffer (256 bytes) +0x00 4 serial no +0x10 16 OEM string +0x20 16 feature string 1 +0x30 16 feature string 2 ... +0x90 16 feature string 8 The next undocumented command is 0x09. It seems to consist of 14 bytes and returns 76 bytes (but for some reason, my usbmon log is being truncated to just 64 bytes). Neither the command nor the response seem to contain ASCII strings. For my test cases, I ran the J-Link program, waited for it to stabilize, then exitted. I tested conditions like the first execution after plugging in the J-Link and successive executions, and having a target connected or not. Here are the forms of the 0x09 commands (responses not included): jlink-trace.txt: 0964a20c jlink-trace.txt: 0964a20c 0300 jlink-trace.txt: 0964a20c 0300 jlink-trace.txt: 0965a20c 0300 segger-after-plug-no-target.txt: 0964850e segger-after-plug-no-target.txt: 0964850e 0200 segger-after-plug-no-target.txt: 0965850e 0200 segger-after-plug-target.txt: 0964890e segger-after-plug-target.txt: 0964890e 0300 segger-after-plug-target.txt: 0964890e 0300 segger-after-plug-target.txt: 0965890e 0300 segger-first-plug-no-target.txt: 09647f0e segger-first-plug-no-target.txt: 09647f0e 0100 segger-first-plug-no-target.txt: 09657f0e 0100 segger-first-plug-target.txt: 0964970e segger-first-plug-target.txt: 0964970e 0100 segger-first-plug-target.txt: 0964970e 0100 segger-first-plug-target.txt: 0965970e 0100 Just want to say that I did some capture under Linux as well adn the result is similar to what you have. usbmon txt interface will truncate the data to 32 bytes. You can try to use the binary interface. http://www.mjmwired.net/kernel/Documentation/usb/usbmon.txt http://kerneltrap.org/mailarchive/linux-usb/2010/6/2/6261760/thread http://people.redhat.com/zaitcev/linux/index.html Pete Zaitcev is the author and he has the usbmon-6 program you can try out. Man file for usbmon-6. http://www.linuxcertif.com/man/8/usbmon/ -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] JLink woes
On Sun, Aug 14, 2011 at 7:51 AM, Xiaofan Chen xiaof...@gmail.com wrote: On Sat, Aug 13, 2011 at 12:45 AM, Xiaofan Chen xiaof...@gmail.com wrote: Actually I think a easier way is now that you know 4.14g and lower firmware versions work whereas 4.14h and higher version firmware versions do not work. So a debug capture from OpenOCD may be already good enough to pinpoint the problem (with the --enable-verbose-usb-comms build option). An example from Spen last time. You can see that thread helped. http://lists.berlios.de/pipermail/openocd-development/2009-May/007464.html Here is the zip file which contains the connection logs of V3, V6, V7 and V8 J-Link (to a TI/Luminary EK-LM3S1968 demo board). The V7 is an ADI OEM version, the V3, V6 and V8 are all IAR OEM version, all have been updated to their latest supported firmware version under Windows. The logs are captured with OpenOCD-0.5.0 release under 32bit Ubuntu 11.04. http://code.google.com/p/picusb/downloads/detail?name=Openocd_usblog_Jlink.zip The init sequence is apparently quite different from Segger's own utility. However, the good logs (V3, V6 and V7) are almost the same as the bad one at the beginning. And here is a zip file containing the initial connection usbmon log for different versions of J-Link using Segger's Linux utility. http://code.google.com/p/picusb/downloads/detail?name=usbmon_jlink_linux.zip -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ST-Link support
On Sun, Aug 14, 2011 at 7:35 AM, Xiaofan Chen xiaof...@gmail.com wrote: I just came across this one and I am not so sure if it is in a good state or not. http://code.google.com/p/rio-source/source/browse/trunk/openocd-0.4.0-tag-stlink/src/jtag/drivers/stlink.c Hmm, a closer look shows that this is not using the original ST-Link2 firmware, but using the author's own firmware (in the stlink_openocd directory). The protocol of st-link seems to be relatively clear now. https://github.com/texane/stlink http://capitanio.org/mlink/ (citing Spen's name) https://github.com/afaerber/stlink -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On Wed, Aug 10, 2011 at 3:39 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Wed, Aug 10, 2011 at 3:34 PM, Olivier Schonken olivier.schon...@gmail.com wrote: Hi Xiaofan In my case I struggled with the same problem for a day or two. That is why I need to know if it is the checkout of the version, or the updating of the mingw32 compiler that fixed the problem. After doing the ./bootstrap command, the head revision of JimTCL is cloned from its repository - afaik. Thus, to get version 0.63 checked out do the following cd jimtcl git tag -l (Gives you a list of the tags for the jimtcl repository) git checkout 0.63 The version of Jimtcl in the directory should now be 0.63. To view the tags of the openocd source, and checkout for instance 0.5.0-rc2 the same procedure is used. Hopefully this helps, cause I've been trying to replicate the problem without success for a while now. This is clear now. I will make sure that my MinGW/Cygwin setup are up to date and see if that helps. If not, I will follow your suggestion and downgrade jimtcl to see if that help. Thanks for the helps! For my Vista 32bit MinGW setup where the 0.5.0 release does not work, downgrading jimtcl to 0.63 does help -- now it works. There are lots of warnings about jimautoconf.h but in the end it works. ../../../jimtcl/jimautoconf.h:113:0: warning: PACKAGE_BUGREPORT redefined ../../../config.h:231:0: note: this is the location of the previous definition ../../../jimtcl/jimautoconf.h:116:0: warning: PACKAGE_NAME redefined ../../../config.h:234:0: note: this is the location of the previous definition ../../../jimtcl/jimautoconf.h:119:0: warning: PACKAGE_STRING redefined ../../../config.h:237:0: note: this is the location of the previous definition ../../../jimtcl/jimautoconf.h:122:0: warning: PACKAGE_TARNAME redefined ../../../config.h:240:0: note: this is the location of the previous definition ../../../jimtcl/jimautoconf.h:128:0: warning: PACKAGE_VERSION redefined ../../../config.h:246:0: note: this is the location of the previous definition For those who do not use git, you can download the jimtcl 0.63 zip file from github mirror. Replace the jimtcl with this version and then you should be able to build with MinGW. https://github.com/msteveb/jimtcl/zipball/0.63 But I think this is just a temp workaround. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] JLink woes
On Fri, Aug 12, 2011 at 10:04 PM, Xiaofan Chen xiaof...@gmail.com wrote: Then I came across this one thread in Sparkfun. The change seems to make sense as well so I gave it a try. http://forum.sparkfun.com/viewtopic.php?f=18t=24946 It does not seem to help either. But then I find out actually my V8 J-Link works once in about 3 times for EK-LM3S1968 demo board. It works even though that there are still quite a bit of error message but it seems to work. With the on-board TI/Luminary interface, OpenOCD always works. Then I also check out V3/V6/V7 and they all work fine. D:\work\openocd\openocd_0.5.0_mingw\binopenocd.exe -f ek-lm3s1968_jlink.cfg Open On-Chip Debugger 0.5.0 (2011-08-11-13:48) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Warn : Adapter driver 'jlink' did not declare which transports it allows; assumi ng legacy JTAG-only Info : only one transport option; autoselect 'jtag' 500 kHz Info : J-Link initialization started / target CPU reset initiated Info : J-Link compiled Feb 20 2006 18:20:20 -- Update -- Info : J-Link caps 0x3 Info : J-Link hw version 3 Info : J-Link hw type J-Link Info : Vref = 3.290 TCK = 1 TDI = 1 TDO = 1 TMS = 1 SRST = 0 TRST = 255 Info : J-Link JTAG Interface ready Info : clock speed 500 kHz Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0x ba00, ver: 0x3) Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints D:\work\openocd\openocd_0.5.0_mingw\binopenocd.exe -f ek-lm3s1968_jlink.cfg Open On-Chip Debugger 0.5.0 (2011-08-11-13:48) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Warn : Adapter driver 'jlink' did not declare which transports it allows; assumi ng legacy JTAG-only Info : only one transport option; autoselect 'jtag' 500 kHz Info : J-Link initialization started / target CPU reset initiated Info : J-Link ARM V6 compiled Feb 1 2011 14:28:14 Info : J-Link caps 0x99ff7bbf Info : J-Link hw version 6 Info : J-Link hw type J-Link Info : J-Link max mem block 8864 Info : J-Link configuration Info : USB-Address: 0xff Info : Kickstart power on JTAG-pin 19: 0xff01 Info : Vref = 3.209 TCK = 1 TDI = 0 TDO = 1 TMS = 0 SRST = 0 TRST = 0 Info : J-Link JTAG Interface ready Info : clock speed 500 kHz Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0x ba00, ver: 0x3) Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints D:\work\openocd\openocd_0.5.0_mingw\binopenocd.exe -f ek-lm3s1968_jlink.cfg Open On-Chip Debugger 0.5.0 (2011-08-11-13:48) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Warn : Adapter driver 'jlink' did not declare which transports it allows; assumi ng legacy JTAG-only Info : only one transport option; autoselect 'jtag' 500 kHz Info : J-Link initialization started / target CPU reset initiated Info : J-Link ARM V7 compiled Feb 15 2011 11:03:33 Info : J-Link caps 0xb9ff7bbf Info : J-Link hw version 7 Info : J-Link hw type J-Link Info : J-Link max mem block 9000 Info : J-Link configuration Info : USB-Address: 0xff Info : Kickstart power on JTAG-pin 19: 0x Info : Vref = 3.196 TCK = 1 TDI = 0 TDO = 1 TMS = 0 SRST = 0 TRST = 0 Info : J-Link JTAG Interface ready Info : clock speed 500 kHz Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0x ba00, ver: 0x3) Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] JLink woes
On Sat, Aug 13, 2011 at 12:02 AM, Eric Wetzel thewet...@gmail.com wrote: I'm going to try to use the Linux software from Segger with the kernel's usbmon to capture some commands and see what Segger's doing that we're not. (I've never done any of that before, so I don't expect good results). I think this may be a good method for now -- reverse engineering. On the Segger J-Link Linux utility side, you can use usbmon. On the OpenOCD Linux side, you can use usbmon as well but you may want to use the --enable-verbose-usb-comms build option which enables verbose USB communication messages for USB communication debugging. Actually I think a easier way is now that you know 4.14g and lower firmware versions work whereas 4.14h and higher version firmware versions do not work. So a debug capture from OpenOCD may be already good enough to pinpoint the problem (with the --enable-verbose-usb-comms build option). An example from Spen last time. You can see that thread helped. http://lists.berlios.de/pipermail/openocd-development/2009-May/007464.html At that time, a lot of work were done to help bring J-Link to better working status. And it worked much better with Gary's patches including the patches in this thread. http://lists.berlios.de/pipermail/openocd-development/2009-July/009397.html So hopefully more people will jump in this time to fix this V8 issue. :-) -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Build error with mingw32
On Sat, Aug 13, 2011 at 9:38 AM, Jie Zhang jzhang...@gmail.com wrote: On Fri, Aug 12, 2011 at 9:27 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Sat, Aug 13, 2011 at 9:00 AM, Jie Zhang jzhang...@gmail.com wrote: Another option is to drop mingw32 and require mingw-w64. Do not do that. usleep is fine with later version of MinGW.org Win32API package. This is probably because you have a very old version of MinGW and MinGW Win32-API. Seems to be a problem with Debian. http://sourceforge.net/projects/mingw/files/MinGW/BaseSystem/RuntimeLibrary/Win32-API/ Debian seems to ship a 3-year old MinGW Win32-API. http://packages.debian.org/search?searchon=sourcenameskeywords=mingw32 Hmm, good point. I have written an email to the mingw32-runtime package maintainer of Debian to see if he has any plan to update it to the latest version. BTW, there are other problems with the Linux MinGW packages in Debian/Ubuntu. This is one of them which does not affect C based programs like OpenOCD but it will affect C++ based programs. http://comments.gmane.org/gmane.comp.gnu.mingw.user/36693 Basically MinGW.org native compiler and the Cygwin i686-pc-ming32 cross compiler are built with --disable-sjlj-exceptions whereas many Linux MinGW cross compilers are built with a default option which is --enable-sjlj-exceptions. That is the case with MinGW package inside Ubuntu 11.04. On the other hand, MinGW-w64 packages inside Ubuntu is also not that usable since it is quite old (even for the upcoming 11.10). So I always use other versions. But Debian Sid seems to be better in this aspect. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Build error with mingw32
On Sat, Aug 13, 2011 at 11:56 AM, Jie Zhang jzhang...@gmail.com wrote: On Fri, Aug 12, 2011 at 10:15 PM, Xiaofan Chen xiaof...@gmail.com wrote: BTW, there are other problems with the Linux MinGW packages in Debian/Ubuntu. This is one of them which does not affect C based programs like OpenOCD but it will affect C++ based programs. http://comments.gmane.org/gmane.comp.gnu.mingw.user/36693 Basically MinGW.org native compiler and the Cygwin i686-pc-ming32 cross compiler are built with --disable-sjlj-exceptions whereas many Linux MinGW cross compilers are built with a default option which is --enable-sjlj-exceptions. That is the case with MinGW package inside Ubuntu 11.04. In GCC, the default is --disable-sjlj-exceptions. So I'm confused. Maybe the word default is too overloaded. But anyway, the thing is that Linux distros are not following the upstream recommendation of MinGW. In Debian testing, mingw32 is configured with --enable-sjlj-exceptions. mingw-w64 is configured without --enable-sjlj-exceptions. But if we compile all code, including libraries, with one compiler, it should be safe. Yes that is true. On the other hand, MinGW-w64 packages inside Ubuntu is also not that usable since it is quite old (even for the upcoming 11.10). So I always use other versions. But Debian Sid seems to be better in this aspect. I use Debian. That is better but I would still consider as not that good. MinGW-w64 Sourceforge website is a mess but the personal build of sezero is good if you want to use it under Linux (or Windows). http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/sezero_20110510/ http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/sezero_20110510/ If you use Windows, then TDM64 is also good. http://tdm-gcc.tdragon.net/download I use mainly TDM64 under Windows and the following build under Linux, http://code.google.com/p/mingw-w64-dgn/downloads/list -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD 0.5.0 for Windows
On Thu, Aug 11, 2011 at 9:26 AM, Xiaofan Chen xiaof...@gmail.com wrote: On Thu, Aug 11, 2011 at 1:59 AM, Freddie Chopin freddie_cho...@op.pl wrote: Hi! I've just posted Windows packages with OpenOCD 0.5.0 on my website - http://www.freddiechopin.info/ - enjoy (; This is great. Thanks. Here is another test binary build of OpenOCD-0.5.0. http://code.google.com/p/picusb/downloads/detail?name=openocd_0.5.0_mingw_new.zip The main differences between this one and Freddie's binary are the following. 1) Build using MinGW.org 32bit compiler, not MinGW-w64 project's compiler. I personally think MinGW.org compilers are more stable. This binary has better chance to work under Windows 2k but YMMV. MinGW-w64 project does not support Win2k. But recent release of MinGW might not have good support of Win2k either. 2) The binary does not support parallel port based Jtag debuggers. 3) The binary provides the libusb-win32 and libftdi-0.19 development kit for those who want to build their own openocd binaries under 32bit MinGW. 4) The binary does not provide the inf file for the USB Jtag debuggers since I recommend the users to use the GUI Inf-wizard or the GUI Filter wizard provides by the libusb-win32 project. So probably Freddie's binary will be more suitable for more users. This is a test build of OpenOCD-0.5.0 release under MinGW. YMMV. Take note that OpenOCD is licensed under GPL. The source codes of OpenOCD-0.5.0 can be downloaded from its website. http://sourceforge.net/projects/openocd/files/openocd/0.5.0/ The build is configured with the following option so that only the following hardware are supported. ../configure --enable-ft2232_libftdi --enable-presto_libftdi \ --enable-arm-jtag-ew --enable-jlink --enable-rlink \ --enable-usbprog --enable-vsllink --enable-usb_blaster_libftdi \ --disable-shared --disable-werror I also include relevant files for libftdi-0.19 and libusb-win32 1.2.5.0 release. Please refer to the Readme.txt file within the libftdi_libusb-win32 directory. In particular, it talks about driver installation options for FTDI based hardware. * I include this one in the zip file as well. http://code.google.com/p/picusb/downloads/detail?name=libftdi_0.19_devkit_MinGW32_26July2011.zip ** This is for developers who want to use libftdi-0.19 under Windows using MinGW. It includes libusb-win32 (1.2.5.0 release) driver installer from libusb-win32 project. It includes the following. 1) include file for libftdi-0.19 and libusb-win32 2) MinGW 32bit dll for libftdi-0.19 3) MinGW import and static library for libftdi-0.19 4) MinGW 32 bit build of libftdi-0.19 examples. 5) libusb-win32 device driver and filter driver installer which work under 32bit/64bit Windows. System requirements: Windows 2000, XP 32bit/64bit, Vista 32bit/64bit, Windows 7 32bit/64bit. 32bit/64bit Windows 2003/2008/2008R2 should also work. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD 0.5.0 for Windows
On Thu, Aug 11, 2011 at 4:33 PM, Vit Mares mares@gmail.com wrote: what is the actual directeory when you run ../configure DOTDOT/configure mkdir build cd build ../configure --xx How did you manage the jimtcl problem on MinGW, I still end with === configuring in jimtcl (/home/maresv/openocd-0.5.0/jimtcl) configure: running /bin/sh ./configure.gnu --disable-option-checking '--prefix=/home/maresv/openocd_dist_050' '--enable -parport' '--enable-parport-giveio' '--enable-ft2232_ftd2xx' '--with-ftd2xx-win32-zipdir=/home/maresv/drivers_ftdi' --ca che-file=/dev/null --srcdir=. The system cannot find the path specified. autosetup/system.tcl:150: Error: in procedure 'use' called at file auto.def, line 5 in procedure 'use' called at file autosetup/cc.tcl, line 29 in procedure 'config_guess' called at file autosetup/system.tcl, line 150 Try: 'configure --debug' for a full stack trace configure: error: ./configure.gnu failed for jimtcl It is still a myth to me. I have one PC working (XP Pro SP3) and two other PCs not working (Vista 32bit Home and Win7 32bit Ultimate), all with updated MinGW.org MinGW distribution. I think Spen and Steve are working on the fix. https://lists.berlios.de/pipermail/openocd-development/2011-August/020537.html -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD 0.5.0 for Windows
On Thu, Aug 11, 2011 at 5:16 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Thu, Aug 11, 2011 at 5:11 PM, Vit Mares mares@gmail.com wrote: Thank you very much but no success. It is on Windows XP Pro SP3 and fresh MinGW instalation. I think we have to wait for the fix from Spen and Steve. In any case, you can use the binary from Freddie Chopin to start using OpenOCD. Or you can use my binary. Or you can use Linux to cross build the binary, it is always faster and easier to build OpenOCD (and libftdi) under Linux using MinGW. That is what Freddie is doing and is also what I usually do to build libftdi and OpenOCD. Yet the other solution is to use Cygwin if you do not want to use Linux. Take note the new Cygwin MinGW.org cross compiler is called mingw-gcc (i686-pc-ming32-gcc) http://cygwin.com/packages/mingw-gcc/ Eg from Spen using ftd2xx. https://lists.berlios.de/pipermail/openocd-development/2011-August/020472.html ./configure --build=i686-pc-cygwin --host=i686-pc-mingw32 --disable-shared --disable-werror --enable-ft2232_ftd2xx Another eg using libusb-win32 and libftdi. ./configure --build=i686-pc-cygwin --host=i686-pc-mingw32 --disable-shared --disable-werror --enable-ft2232_libftdi --enable-jlink -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] JLink woes
On Sun, Jul 10, 2011 at 8:38 PM, Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com wrote: Unfortunately this is a known issue. https://lists.berlios.de/pipermail/openocd-development/2011-July/020046.html Basically 4.10i and below works, 4.20 and above does not work. Hopefully this will be fixed with some reverse-engineering or contacting Segger. It seems Segger knows the problem and may want to work with OpenOCD developers to fix the problem. http://www.segger2.com/index.php?page=ThreadthreadID=869 I try to get in Contact with them already hope they will reply soon Any updates? I came across this post in SparkFun forum and it might ring some bell. http://forum.sparkfun.com/viewtopic.php?f=18t=28923sid=bc50d79d7c9cc1e96e5b0d99a43008aa *** I have some update. I run logic analyzer and noticed that Segger GDB server does not use nor nSRST neither nTRST during JTAG init. And Segger SW connects to target MCU properly. Just after RESET, I am getting zero on TDO. If I desoldered nSRST and nTRST, now I can connect to the AT91SAM9263. But do not understand, why. Can TDO signal be disabled after RESET ? reset_config does not work properly for JLink interface in my version of OpenOcd. Even if I use reset_config none, on LA I see that RESET signals are both used with some default values. Is it repaired in some newer version of OpenOcd ? ** -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] JLink woes
On Fri, Aug 12, 2011 at 11:17 AM, Antonio Borneo
borneo.anto...@gmail.com wrote:
in Jlink code in src/jtag/drivers/jlink.c
there is the following:
static int jlink_init(void)
{
/*
* The next three instructions were added after discovering a problem
* while using an oscilloscope.
* For the V8 SAM-ICE dongle (and likely other j-link device variants),
* the reset line to the target microprocessor was found to cycle only
* intermittently during emulator startup (even after encountering the
* downstream reset instruction later in the code).
* This was found to create two issues:
* 1) In general it is a bad practice to not reset a CPU to a known
* state when starting an emulator and
* 2) something critical happens inside the dongle when it does the
* first read following a new USB session.
* Keeping the processor in reset during the first read collecting
* version information seems to prevent errant
* J-Link command EMU_CMD_VERSION failed issues.
*/
LOG_INFO(J-Link initialization started / target CPU reset initiated);
jlink_simple_command(EMU_CMD_HW_TRST0);
jlink_simple_command(EMU_CMD_HW_RESET0);
usleep(1000);
During JLink initialization OpenOCD forces nTRST and nSRST.
Personally I do not like it, since I use to attach OpenOCD on running
boards and I want to start debugging without resetting the CPU.
In my personal build of OpenOCD I always comment the nSRST part.
I never got the problem reported in the comment above, but I only have
JLink version 5 and 6.
What about removing these two code lines instead of cutting nTRST and
nSRST wires?
Thanks a lot for the information.
I will try to borrow a V8 from my colleague and try this out over the
weekend.
--
Xiaofan
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD 0.5.0 for Windows
On Fri, Aug 12, 2011 at 5:45 AM, Steve Bennett ste...@workware.net.au wrote: On 11/08/2011, at 8:17 PM, Xiaofan Chen wrote: I think we have to wait for the fix from Spen and Steve. Yes. We are still working on the problem. It's taking a while because I can't reproduce it here. Yes it is quite strange. I just checked with my XP PC again and it works fine with different build options (with ft2232_libftdi or ft2232_ftd2xx). I do not see anything different from my other PC with Vista in terms of MinGW setup. In both setups, I used mingw-get to upgrade all the packages I have to the latest. But in the other PC with Vista, I got the same errors as others. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On Wed, Aug 10, 2011 at 3:34 PM, Olivier Schonken olivier.schon...@gmail.com wrote: Hi Xiaofan In my case I struggled with the same problem for a day or two. That is why I need to know if it is the checkout of the version, or the updating of the mingw32 compiler that fixed the problem. After doing the ./bootstrap command, the head revision of JimTCL is cloned from its repository - afaik. Thus, to get version 0.63 checked out do the following cd jimtcl git tag -l (Gives you a list of the tags for the jimtcl repository) git checkout 0.63 The version of Jimtcl in the directory should now be 0.63. To view the tags of the openocd source, and checkout for instance 0.5.0-rc2 the same procedure is used. Hopefully this helps, cause I've been trying to replicate the problem without success for a while now. This is clear now. I will make sure that my MinGW/Cygwin setup are up to date and see if that helps. If not, I will follow your suggestion and downgrade jimtcl to see if that help. Thanks for the helps! -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On Wed, Aug 10, 2011 at 2:11 PM, Steve Bennett ste...@workware.net.au wrote: On 10/08/2011, at 3:03 PM, Xiaofan Chen wrote: FYI: I build the release tarball on windows/mingw without any problems. Glad to know that. As per the previous answer from Spen that MinGW/Msys is not supported by jimtcl. Is that not true? That is *not* true. The version of jimtcl in openocd-0.5.0 fully supports building on mingw/msys Seems this is true and it works without using Cygwin. Thanks for the information. /c/cygwin/home/xfchen/openocd/openocd-0.5.0/build_mingw_direct $ ../configure --enable-jlink --enable-ft2232_libftdi checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.exe checking for suffix of executables... .exe checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for gcc option to accept ISO C99... -std=gnu99 checking whether gcc -std=gnu99 and cc understand -c and -o together... yes checking for ranlib... ranlib checking build system type... i686-pc-mingw32 checking host system type... i686-pc-mingw32 checking how to print strings... printf checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for fgrep... /bin/grep -F checking for ld used by gcc -std=gnu99... c:/mingw/mingw32/bin/ld.exe checking if the linker (c:/mingw/mingw32/bin/ld.exe) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /mingw/bin/nm checking the name lister (/mingw/bin/nm) interface... BSD nm checking whether ln -s works... no, using cp -p checking the maximum length of command line arguments... 8192 checking whether the shell understands some XSI constructs... yes checking whether the shell understands +=... yes checking how to convert i686-pc-mingw32 file names to i686-pc-mingw32 format... func_convert_file_msys_to_w32 checking how to convert i686-pc-mingw32 file names to toolchain format... func_c onvert_file_msys_to_w32 checking for c:/mingw/mingw32/bin/ld.exe option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... file_magic ^x86 archive import| ^x86 DLL checking for dlltool... dlltool checking how to associate runtime and link libraries... func_cygming_dll_for_imp lib checking for ar... ar checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... (cached) ranlib checking command to parse /mingw/bin/nm output from gcc -std=gnu99 object... ok checking for sysroot... no checking for mt... no checking if : is a manifest tool... no checking how to run the C preprocessor... gcc -std=gnu99 -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... no checking for objdir... .libs checking if gcc -std=gnu99 supports -fno-rtti -fno-exceptions... no checking for gcc -std=gnu99 option to produce PIC... -DDLL_EXPORT -DPIC checking if gcc -std=gnu99 PIC flag -DDLL_EXPORT -DPIC works... yes checking if gcc -std=gnu99 static flag -static works... yes checking if gcc -std=gnu99 supports -c -o file.o... yes checking if gcc -std=gnu99 supports -c -o file.o... (cached) yes checking whether the gcc -std=gnu99 linker (c:/mingw/mingw32/bin/ld.exe) support s shared libraries... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... no checking whether to build static libraries... yes checking for an ANSI C-conforming const... yes checking for long long int... yes checking for library containing ioperm... no checking for library containing dlopen... no checking sys/socket.h usability... no checking sys/socket.h presence... no checking for sys/socket.h... no checking for arpa/inet.h... no checking elf.h usability... no checking elf.h presence... no checking for elf.h... no checking dirent.h usability... yes checking dirent.h presence... yes checking for dirent.h... yes checking fcntl.h
Re: [Openocd-development] 0.5.0 MinGW configure failure
On Wed, Aug 10, 2011 at 4:11 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Wed, Aug 10, 2011 at 2:11 PM, Steve Bennett ste...@workware.net.au wrote: On 10/08/2011, at 3:03 PM, Xiaofan Chen wrote: FYI: I build the release tarball on windows/mingw without any problems. Glad to know that. As per the previous answer from Spen that MinGW/Msys is not supported by jimtcl. Is that not true? That is *not* true. The version of jimtcl in openocd-0.5.0 fully supports building on mingw/msys Seems this is true and it works without using Cygwin. Thanks for the information. Cygwin build of 0.5.0 also works in this PC (XP SP3). Cross MinGW build under Cygwin (up to date installation of Cygwin) still fails but with a different error. But I am happy now since direct MinGW build works and direct Cygwin build also works. bash-4.1# ../configure --build=i686-pc-mingw32 --enable-jlink --enable-ft2232_libftdi checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.exe checking for suffix of executables... .exe checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for gcc option to accept ISO C99... -std=gnu99 checking whether gcc -std=gnu99 and cc understand -c and -o together... yes checking for ranlib... ranlib checking build system type... i686-pc-mingw32 checking host system type... i686-pc-mingw32 checking how to print strings... printf checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for ld used by gcc -std=gnu99... /usr/i686-pc-cygwin/bin/ld.exe checking if the linker (/usr/i686-pc-cygwin/bin/ld.exe) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 8192 checking whether the shell understands some XSI constructs... yes checking whether the shell understands +=... yes checking how to convert i686-pc-mingw32 file names to i686-pc-mingw32 format... func_convert_file_msys_to_w32 checking how to convert i686-pc-mingw32 file names to toolchain format... func_c onvert_file_msys_to_w32 checking for /usr/i686-pc-cygwin/bin/ld.exe option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... file_magic ^x86 archive import| ^x86 DLL checking for dlltool... dlltool checking how to associate runtime and link libraries... func_cygming_dll_for_imp lib checking for ar... ar checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... (cached) ranlib checking command to parse /usr/bin/nm -B output from gcc -std=gnu99 object... ok checking for sysroot... no checking for mt... no checking if : is a manifest tool... no checking how to run the C preprocessor... gcc -std=gnu99 -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc -std=gnu99 supports -fno-rtti -fno-exceptions... no checking for gcc -std=gnu99 option to produce PIC... -DDLL_EXPORT -DPIC checking if gcc -std=gnu99 PIC flag -DDLL_EXPORT -DPIC works... yes checking if gcc -std=gnu99 static flag -static works... no checking if gcc -std=gnu99 supports -c -o file.o... yes checking if gcc -std=gnu99 supports -c -o file.o... (cached) yes checking whether the gcc -std=gnu99 linker (/usr/i686-pc-cygwin/bin/ld.exe) supp orts shared libraries... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... no checking whether to build static libraries... yes checking for an ANSI C-conforming const... yes checking for long long int... yes checking for library containing ioperm... -lioperm checking for library containing dlopen... none required
Re: [Openocd-development] 0.5.0 MinGW configure failure
On Wed, Aug 10, 2011 at 4:22 PM, Steve Bennett ste...@workware.net.au wrote: On 10/08/2011, at 6:15 PM, Xiaofan Chen wrote: But I am happy now since direct MinGW build works and direct Cygwin build also works. Thanks. That's good enough for me. Just for those who can not wait for Freddie Chopin's binary, here is a test binary build of OpenOCD-0.5.0. http://code.google.com/p/picusb/downloads/detail?name=openocd_0.5.0_mingw.zip This is a test build of OpenOCD-0.5.0 release under MinGW. YMMV. Take note that OpenOCD is licensed under GPL. The source codes of OpenOCD-0.5.0 can be downloaded from the project website. http://sourceforge.net/projects/openocd/files/openocd/0.5.0/ The build is configured with the following option so that only J-Link and FT2232_libftdi hardware are supported. ../configure --enable-jlink --enable-ft2232_libftdi I also include relevant files for libftdi-0.19 and libusb-win32 1.2.5.0 release. Please refer to the Readme.txt file within the libftdi_libusb-win32 directory. In particular, it talks about driver installation options for FTDI based hardware. * I include this one in the zip file as well. http://code.google.com/p/picusb/downloads/detail?name=libftdi_0.19_devkit_MinGW32_26July2011.zip ** This is for developers who want to use libftdi-0.19 under Windows using MinGW. It includes libusb-win32 (1.2.5.0 release) driver installer from libusb-win32 project. It includes the following. 1) include file for libftdi-0.19 and libusb-win32 2) MinGW 32bit dll for libftdi-0.19 3) MinGW import and static library for libftdi-0.19 4) MinGW 32 bit build of libftdi-0.19 examples. 5) libusb-win32 device driver and filter driver installer which work under 32bit/64bit Windows. System requirements: Windows 2000, XP 32bit/64bit, Vista 32bit/64bit, Windows 7 32bit/64bit. 32bit/64bit Windows 2003/2008/2008R2 should also work. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On Wed, Aug 10, 2011 at 5:12 PM, Olivier Schonken olivier.schon...@gmail.com wrote: Could you try building with ../configure --host=i686-pc-mingw32 --enable-jlink --enable-ft2232_libftdi in stead of ../configure --build=i686-pc-mingw32 --enable-jlink --enable-ft2232_libftdi Afaik, --host specifies the cross-compiler i.e. the target system, while --build specifies the system it is being built on - cygwin etc. Remember to do a make clean beforehand to clear any old object files. This might solve the path errors with building JimTCL. You are absolutely right. I made a mistake here and I will try again. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On Wed, Aug 10, 2011 at 6:35 PM, Spencer Oliver s...@spen-soft.co.uk wrote: On 10 August 2011 11:15, Steve Bennett ste...@workware.net.au wrote: for me jimtcl has never built under msys since the update. log is attached below, for info jimsh0.exe is built ok. No installed jimsh or tclsh, building local bootstrap jimsh0 The system cannot find the path specified. autosetup/system.tcl:150: Error: in procedure 'use' called at file auto.def, line 5 in procedure 'use' called at file autosetup/cc.tcl, line 29 in procedure 'config_guess' called at file autosetup/system.tcl, line 150 Try: 'configure --debug' for a full stack trace configure: error: ./configure.gnu failed for jimtcl It is failing while trying to run config.guess. What do you get when you run: sh jimtcl/autosetup/config.guess i686-pc-mingw32 just installed a fresh copy of msys/mingw - still same error. I can reproduce here at a Vista 32bit installation of MinGW/MSys. It is a myth now that I have the other PC working (XP SP3). I have updated both MinGW/MSys installation to the latest. === configuring in jimtcl (/d/work/openocd/openocd-0.5.0/build_mingw/jimtcl) configure: running /bin/sh ../../jimtcl/configure.gnu --disable-option-checking '--prefix=/usr/local' '--enable-jlink' '--enable-ft2232_libftdi' --cache-file=/ dev/null --srcdir=../../jimtcl No installed jimsh or tclsh, building local bootstrap jimsh0 The system cannot find the path specified. ../../jimtcl/autosetup/system.tcl:150: Error: in procedure 'use' called at file ../../jimtcl/auto.def, line 5 in procedure 'use' called at file ../../jimtcl/autosetup/cc.tcl, line 29 in procedure 'config_guess' called at file ../../jimtcl/autosetup/system.tcl, line 150 Try: 'configure --debug' for a full stack trace configure: error: ../../jimtcl/configure.gnu failed for jimtcl -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD 0.5.0 for Windows
On Thu, Aug 11, 2011 at 1:59 AM, Freddie Chopin freddie_cho...@op.pl wrote: Hi! I've just posted Windows packages with OpenOCD 0.5.0 on my website - http://www.freddiechopin.info/ - enjoy (; This is great. Thanks. Below I post the news article associated with this files OpenOCD 0.5.0 finally published! Almost one and a half year passed since last stable OpenOCD release... During this time 0.4.0 Windows installer was downloaded from this website over 16000 times and packages with development versions from this period - over 5000 times. This proves that a Windows binary is quite important for Windows users. This time Windows version of the application was published - just as development versions - as a compressed .zip archive, not as .msi installer - I hope this won't be a problem for you, it's easier and faster to create such package instead of playing with installers (; . In Download Software OpenOCD you can download 32- and 64-bit version. Extract anywhere and you are ready to go (; I agree that zip archive is fine. The msi installer is sleek but I think most Windows users of OpenOCD can handle zip file. :-) You can find highlights of major changes in NEWS file associated with this release in OpenOCD repository. There are not many of them, because this release should be treated as a stable update, without any revolutionary changes. What next? The most anticipated feature - SWD (Serial Wire Debug) interface support, two-wire interface used in most recent Cortex chips - is in advanced stage. While you could use both classic JTAG and modern SWD in bigger chips like STM32 or LPC17xx, the smallest chips - like LPC11xx - can be debugged only via SWD. You can find more details on OpenOCD mailing list. Let's hope that test versions will be available soon! Stay tuned! SWD would be nice to have now that Cortex M0 device are getting quite some attentions. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 release
On Wed, Aug 10, 2011 at 11:40 PM, Vit Mares mares@gmail.com wrote: The FTD2232 can be used not only as a JTAG dongle but it is also very big helper for embedded developer. It can be used as a I2C or SPI bridge between your PC and uC board, it can be used for Lattice FPGA programming etc. and many of us use it on Windows with native FTDI driver support. The speed is not so important the drivers are. You can continue to use the FTDI drivers and those I2C/SPI/UART functions and at the same time libftdi/OpenOCD. The solution here is to use libusb-win32 filter driver. Install libusb-win32 and then launch the GUI filter wizard. Install the filter for the particular device (eg: J-Link, for FT2232x, usually interface 0 of the device) you have, then you can use OpenOCD built on top of libftdi and libusb-win32. And you can still use the existing driver based application (like IAR, Keil or Rowley), and your serial port for FT2232x's 2nd interface if that is used as a USB virtual serial port. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 release
On Tue, Aug 9, 2011 at 6:52 PM, Spencer Oliver s...@spen-soft.co.uk wrote: Just for info i have also pushed files onto berlios and updated website with release news. Once Freddie Chopin is ready with the 0.5.0 Windows binary, I wonder if it is possible to put a link in OpenOCD Berlios site to mention that. I think many Windows users would like to get the Windows binary (not source) and Freddie's is the best one (using libftdi-0.19 and libusb-win32). If the project is willing to provide official Windows binary, that would be the best. But if not, a link to Freddie Chopin's website is still good. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On Tue, Aug 9, 2011 at 9:25 PM, Spencer Oliver s...@spen-soft.co.uk wrote: On 9 August 2011 13:48, Vit Mares mares@gmail.com wrote: it doesn't seem so, jimsh0.exe is built during configure and is runable. When I start it in MSYS console I get the dot prompt. It has been a while since i looked however: Building jimsh0 is not the problem, running it is - the scripts look for jimsh0 and under msys this should be jimsh0.exe. Just wondering if this could be fixed. I think many Windows users would like to be able to build under MinGW/MSys instead of Cygwin (quite slow). -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On Tue, Aug 9, 2011 at 9:27 PM, Spencer Oliver s...@spen-soft.co.uk wrote: The issue is building using msys under windoze. Using cygwin or linux to build native win32 (mingw) is not an issue. I remember there were no issues to build MinGW binary under Cygwin with the cross compiler with OpenOCD git. But it seems that there are problems with the 0.5.0 release tar ball. Actually build under Cygwin is also problematic. mcuee@mcuee-PC-Win7 /cygdrive/d/work/openocd/openocd-0.5.0/build_mingw_cross $ ../configure --build=i686-pc-mingw32 --enable-jlink --enable-ft2232_libftdi checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.exe checking for suffix of executables... .exe checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for gcc option to accept ISO C99... -std=gnu99 checking whether gcc -std=gnu99 and cc understand -c and -o together... yes checking for ranlib... ranlib checking build system type... i686-pc-mingw32 checking host system type... i686-pc-mingw32 checking how to print strings... printf checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for ld used by gcc -std=gnu99... /usr/i686-pc-cygwin/bin/ld.exe checking if the linker (/usr/i686-pc-cygwin/bin/ld.exe) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 8192 checking whether the shell understands some XSI constructs... yes checking whether the shell understands +=... yes checking how to convert i686-pc-mingw32 file names to i686-pc-mingw32 format... func_convert_file_msys_to_w32 checking how to convert i686-pc-mingw32 file names to toolchain format... func_c onvert_file_msys_to_w32 checking for /usr/i686-pc-cygwin/bin/ld.exe option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... file_magic ^x86 archive import| ^x86 DLL checking for dlltool... dlltool checking how to associate runtime and link libraries... func_cygming_dll_for_imp lib checking for ar... ar checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... (cached) ranlib checking command to parse /usr/bin/nm -B output from gcc -std=gnu99 object... ok checking for sysroot... no checking for mt... no checking if : is a manifest tool... no checking how to run the C preprocessor... gcc -std=gnu99 -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc -std=gnu99 supports -fno-rtti -fno-exceptions... no checking for gcc -std=gnu99 option to produce PIC... -DDLL_EXPORT -DPIC checking if gcc -std=gnu99 PIC flag -DDLL_EXPORT -DPIC works... yes checking if gcc -std=gnu99 static flag -static works... no checking if gcc -std=gnu99 supports -c -o file.o... yes checking if gcc -std=gnu99 supports -c -o file.o... (cached) yes checking whether the gcc -std=gnu99 linker (/usr/i686-pc-cygwin/bin/ld.exe) supp orts shared libraries... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... no checking whether to build static libraries... yes checking for an ANSI C-conforming const... yes checking for long long int... yes checking for library containing ioperm... -lioperm checking for library containing dlopen... none required checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking for arpa/inet.h... yes checking elf.h usability... yes checking elf.h presence... yes checking for elf.h... yes checking dirent.h usability... yes checking dirent.h presence... yes checking for dirent.h... yes checking
Re: [Openocd-development] 0.5.0 MinGW configure failure
On Tue, Aug 9, 2011 at 9:47 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Tue, Aug 9, 2011 at 9:27 PM, Spencer Oliver s...@spen-soft.co.uk wrote: The issue is building using msys under windoze. Using cygwin or linux to build native win32 (mingw) is not an issue. I remember there were no issues to build MinGW binary under Cygwin with the cross compiler with OpenOCD git. But it seems that there are problems with the 0.5.0 release tar ball. Actually build under Cygwin is also problematic. Luckily git tree is still okay for Cygwin native build and Cygwin MinGW cross build. mcuee@mcuee-PC-Win7 /cygdrive/d/work/openocd/openocd/build-crossmingw $ ../configure --enable-maintainer-mode --build=i686-pc-mingw32 --enable-jlink --enable-ft2232_libftdi checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.exe checking for suffix of executables... .exe checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for gcc option to accept ISO C99... -std=gnu99 checking whether gcc -std=gnu99 and cc understand -c and -o together... yes checking for ranlib... ranlib checking build system type... i686-pc-mingw32 checking host system type... i686-pc-mingw32 checking how to print strings... printf checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for ld used by gcc -std=gnu99... /usr/i686-pc-cygwin/bin/ld.exe checking if the linker (/usr/i686-pc-cygwin/bin/ld.exe) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 8192 checking whether the shell understands some XSI constructs... yes checking whether the shell understands +=... yes checking how to convert i686-pc-mingw32 file names to i686-pc-mingw32 format... func_convert_file_msys_to_w32 checking how to convert i686-pc-mingw32 file names to toolchain format... func_c onvert_file_msys_to_w32 checking for /usr/i686-pc-cygwin/bin/ld.exe option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... file_magic ^x86 archive import| ^x86 DLL checking for dlltool... dlltool checking how to associate runtime and link libraries... func_cygming_dll_for_imp lib checking for ar... ar checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... (cached) ranlib checking command to parse /usr/bin/nm -B output from gcc -std=gnu99 object... ok checking for sysroot... no checking for mt... no checking if : is a manifest tool... no checking how to run the C preprocessor... gcc -std=gnu99 -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc -std=gnu99 supports -fno-rtti -fno-exceptions... no checking for gcc -std=gnu99 option to produce PIC... -DDLL_EXPORT -DPIC checking if gcc -std=gnu99 PIC flag -DDLL_EXPORT -DPIC works... yes checking if gcc -std=gnu99 static flag -static works... no checking if gcc -std=gnu99 supports -c -o file.o... yes checking if gcc -std=gnu99 supports -c -o file.o... (cached) yes checking whether the gcc -std=gnu99 linker (/usr/i686-pc-cygwin/bin/ld.exe) supp orts shared libraries... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... no checking whether to build static libraries... yes checking for an ANSI C-conforming const... yes checking for long long int... yes checking for library containing ioperm... -lioperm checking for library containing dlopen... none required checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking for arpa/inet.h... yes checking elf.h
Re: [Openocd-development] 0.5.0 MinGW configure failure
On Tue, Aug 9, 2011 at 10:05 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Tue, Aug 9, 2011 at 9:47 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Tue, Aug 9, 2011 at 9:27 PM, Spencer Oliver s...@spen-soft.co.uk wrote: The issue is building using msys under windoze. Using cygwin or linux to build native win32 (mingw) is not an issue. I remember there were no issues to build MinGW binary under Cygwin with the cross compiler with OpenOCD git. But it seems that there are problems with the 0.5.0 release tar ball. Actually build under Cygwin is also problematic. Luckily git tree is still okay for Cygwin native build and Cygwin MinGW cross build. But only Cygwin native build is okay. $ openocd -v Open On-Chip Debugger 0.6.0-dev-2-gdb87a2f-dirty (2011-08-09-22:03) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html MinGW cross build under Cygwin fails because of jimtcl. mcuee@mcuee-PC-Win7 /cygdrive/d/work/openocd/openocd/build-crossmingw $ make make all-recursive make[1]: Entering directory `/cygdrive/d/work/openocd/openocd/build-crossmingw' Making all in jimtcl make[2]: Entering directory `/cygdrive/d/work/openocd/openocd/build-crossmingw/j imtcl' /cygdrive/d/work/openocd/openocd/build-crossmingw/jimtcl/../../jimtcl/autosetup/ jimsh0 ../../jimtcl/make-load-static-exts.tcl aio array clock eventloop exec fil e load nvp package posix readdir regexp signal syslog glob stdlib tclcompat _lo ad-static-exts.c || ( rm _load-static-exts.c; exit 1) cc -g -O2 -D_GNU_SOURCE -Wall -Werror -I. -I../../jimtcl -c -o _load-static-ex ts.o _load-static-exts.c cc -g -O2 -D_GNU_SOURCE -Wall -Werror -I. -I../../jimtcl -c -o jim-subcmd.o .. /../jimtcl/jim-subcmd.c cc -g -O2 -D_GNU_SOURCE -Wall -Werror -I. -I../../jimtcl -c -o jim-interactive .o ../../jimtcl/jim-interactive.c cc -g -O2 -D_GNU_SOURCE -Wall -Werror -I. -I../../jimtcl -c -o jim-format.o .. /../jimtcl/jim-format.c cc -g -O2 -D_GNU_SOURCE -Wall -Werror -I. -I../../jimtcl -c -o jim.o ../../jim tcl/jim.c cc -g -O2 -D_GNU_SOURCE -Wall -Werror -I. -I../../jimtcl -c -o utf8.o ../../ji mtcl/utf8.c cc -g -O2 -D_GNU_SOURCE -Wall -Werror -I. -I../../jimtcl -c -o jimregexp.o ../ ../jimtcl/jimregexp.c cc -g -O2 -D_GNU_SOURCE -Wall -Werror -I. -I../../jimtcl -c -o jim-win32compat .o ../../jimtcl/jim-win32compat.c cc1: warnings being treated as errors ../../jimtcl/jim-win32compat.c: In function ‘dlopen’: ../../jimtcl/jim-win32compat.c:9: error: implicit declaration of function ‘LoadLibraryA’ ../../jimtcl/jim-win32compat.c: In function ‘dlclose’: ../../jimtcl/jim-win32compat.c:14: error: implicit declaration of function ‘FreeLibrary’ ../../jimtcl/jim-win32compat.c:14: error: ‘HANDLE’ undeclared (first use in this function) ../../jimtcl/jim-win32compat.c:14: error: (Each undeclared identifier is reported only once ../../jimtcl/jim-win32compat.c:14: error: for each function it appears in.) ../../jimtcl/jim-win32compat.c:14: error: expected ‘)’ before ‘handle’ ../../jimtcl/jim-win32compat.c: In function ‘dlsym’: ../../jimtcl/jim-win32compat.c:20: error: implicit declaration of function ‘GetProcAddress’ ../../jimtcl/jim-win32compat.c:20: error: ‘HMODULE’ undeclared (first use in this function) ../../jimtcl/jim-win32compat.c:20: error: expected ‘)’ before ‘handle’ ../../jimtcl/jim-win32compat.c:20: error: return makes pointer from integer without a cast ../../jimtcl/jim-win32compat.c: In function ‘dlerror’: ../../jimtcl/jim-win32compat.c:26: error: implicit declaration of function ‘FormatMessageA’ ../../jimtcl/jim-win32compat.c:26: error: ‘FORMAT_MESSAGE_FROM_SYSTEM’ undeclared (first use in this function) ../../jimtcl/jim-win32compat.c:26: error: implicit declaration of function ‘GetLastError’ ../../jimtcl/jim-win32compat.c:27: error: ‘LANG_NEUTRAL’ undeclared (first use in this function) make[2]: *** [jim-win32compat.o] Error 1 make[2]: Leaving directory `/cygdrive/d/work/openocd/openocd/build-crossmingw/jimtcl' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/cygdrive/d/work/openocd/openocd/build-crossmingw' make: *** [all] Error 2 mcuee@mcuee-PC-Win7 /cygdrive/d/work/openocd/openocd/build-crossmingw $ i686-pc-mingw32-gcc -v Using built-in specs. COLLECT_GCC=i686-pc-mingw32-gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-mingw32/4.5.2/lto-wrapper.exe Target: i686-pc-mingw32 Configured with: /usr/src/packages/mingw-gcc/mingw-gcc-4.5.2-1/src/gcc-4.5.2/con figure --srcdir=/usr/src/packages/mingw-gcc/mingw-gcc-4.5.2-1/src/gcc-4.5.2 --pr efix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir= /usr/lib --datadir=/usr/share --localstatedir=/var --sysconfdir=/etc --datarootd ir=/usr/share --docdir=/usr/share/doc/mingw-gcc -C --build=i686-pc-cygwin --host =i686-pc-cygwin --target=i686-pc-mingw32 --with-sysroot=/usr/i686-pc-mingw32/sys -root --with-build-sysroot=/usr/i686-pc-mingw32/sys-root --disable-multilib --di sable-win32-registry --enable-languages=c,c++,fortran
Re: [Openocd-development] 0.5.0 release
On Tue, Aug 9, 2011 at 7:15 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: I do not particularly like the idea of being responsible, directly or indirectly for binaries as a maintainer. We have our hands full getting a release out in the first place with the resources we have, let alone figuring out if we can recommend a binary. I fear it's a slippery slope. I understand that. Maybe a link is still good to have. You can probably qualify the Windows binary as unofficial or unsupported or experimental or things like that. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On Tue, Aug 9, 2011 at 10:20 PM, Spencer Oliver s...@spen-soft.co.uk wrote: Just tested building native windoze under cygwin and working fine here. I used the release tarball and the following configure line: ./configure --build=i686-pc-cygwin --host=i686-pc-mingw32 --disable-shared --disable-werror --enable-ft2232_ftd2xx Try build in a separate build directory and see if that is okay or not. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Jlink Question
On Wed, Aug 10, 2011 at 1:48 AM, Carlson Gary gcarl...@carlson-minot.com wrote: Hi Xiaofan, Your response was much appreciated! :) Gary Gary Carlson Gary Carlson, MSEE Principal Engineer Carlson-Minot Inc. You are welcome. Hopefully the issue will be fixed in the near future. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On Tue, Aug 9, 2011 at 11:11 PM, Spencer Oliver s...@spen-soft.co.uk wrote: On 9 August 2011 16:01, Xiaofan Chen xiaof...@gmail.com wrote: On Tue, Aug 9, 2011 at 10:20 PM, Spencer Oliver s...@spen-soft.co.uk wrote: Just tested building native windoze under cygwin and working fine here. I used the release tarball and the following configure line: ./configure --build=i686-pc-cygwin --host=i686-pc-mingw32 --disable-shared --disable-werror --enable-ft2232_ftd2xx Try build in a separate build directory and see if that is okay or not. works fine in/out of src tree. Just to be sure i also deleted the release src tree between builds. are your cygwin tools upto date? It was not up to date but very close. Anyway, I just updated it and the issue is still there with the release zip file. I will try the git tree later. === configuring in jimtcl (/cygdrive/d/work/openocd/openocd-0.5.0/build_mingw_cr oss/jimtcl) configure: running /bin/sh ../../jimtcl/configure.gnu --disable-option-checking '--prefix=/usr/local' '--build=i686-pc-mingw32' '--enable-jlink' '--enable-ft22 32_libftdi' 'build_alias=i686-pc-mingw32' --cache-file=/dev/null --srcdir=../../ jimtcl ../../jimtcl/configure: line 3: D:/work/openocd/openocd-0.5.0/jimtcl/autosetup/j : No such file or directory ../../jimtcl/configure: line 3: exec: D:/work/openocd/openocd-0.5.0/jimtcl/autos : cannot execute: No such file or directory configure: error: ../../jimtcl/configure.gnu failed for jimtcl -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On Tue, Aug 9, 2011 at 11:26 PM, Olivier Schonken olivier.schon...@gmail.com wrote: Hi Xiaofan I also experienced the same build error a while ago. To fix it I manually checked out version 0.63 of JimTCL, Just wondering how you do that? and after that, the build went on without any problems. I did a git clone of openocd just-now, and I did a --host=i686-w64-mingw32 build on a Windows 7 installation of cygwin, and it compiled without a hitch. Please let me know if this doesn't help. I tried the 64bit cross build and it is still the same issue. The error messages are quite strange though. cc -g -O2 -D_GNU_SOURCE -Wall -Werror -I. -I../../jimtcl -c -o jim-win32compat .o ../../jimtcl/jim-win32compat.c cc1: warnings being treated as errors ../../jimtcl/jim-win32compat.c: In function ‘dlopen’: ../../jimtcl/jim-win32compat.c:9: error: implicit declaration of function ‘Load LibraryA’ ../../jimtcl/jim-win32compat.c: In function ‘dlclose’: ../../jimtcl/jim-win32compat.c:14: error: implicit declaration of function ‘Fre eLibrary’ ../../jimtcl/jim-win32compat.c:14: error: ‘HANDLE’ undeclared (first use in th is function) ../../jimtcl/jim-win32compat.c:14: error: (Each undeclared identifier is reporte d only once ../../jimtcl/jim-win32compat.c:14: error: for each function it appears in.) ../../jimtcl/jim-win32compat.c:14: error: expected ‘)’ before ‘handle’ ../../jimtcl/jim-win32compat.c: In function ‘dlsym’: ../../jimtcl/jim-win32compat.c:20: error: implicit declaration of function ‘Get ProcAddress’ ../../jimtcl/jim-win32compat.c:20: error: ‘HMODULE’ undeclared (first use in t his function) ../../jimtcl/jim-win32compat.c:20: error: expected ‘)’ before ‘handle’ ../../jimtcl/jim-win32compat.c:20: error: return makes pointer from integer with out a cast ../../jimtcl/jim-win32compat.c: In function ‘dlerror’: ../../jimtcl/jim-win32compat.c:26: error: implicit declaration of function ‘For matMessageA’ ../../jimtcl/jim-win32compat.c:26: error: ‘FORMAT_MESSAGE_FROM_SYSTEM’ undecla red (first use in this function) ../../jimtcl/jim-win32compat.c:26: error: implicit declaration of function ‘Get LastError’ ../../jimtcl/jim-win32compat.c:27: error: ‘LANG_NEUTRAL’ undeclared (first use in this function) make[2]: *** [jim-win32compat.o] Error 1 make[2]: Leaving directory `/cygdrive/d/work/openocd/openocd/build-crossmingw64/ jimtcl' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/cygdrive/d/work/openocd/openocd/build-crossmingw64' make: *** [all] Error 2 -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On Wed, Aug 10, 2011 at 7:59 AM, Xiaofan Chen xiaof...@gmail.com wrote: On Tue, Aug 9, 2011 at 11:26 PM, Olivier Schonken olivier.schon...@gmail.com wrote: Hi Xiaofan I also experienced the same build error a while ago. To fix it I manually checked out version 0.63 of JimTCL, Just wondering how you do that? I mean to ask the following question. Do you check out 0.63 version of JimTCL and replace the JimTCL in 0.5.0 release (or latest git) with the 0.63 version of JimTCL? -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On Wed, Aug 10, 2011 at 11:44 AM, Steve Bennett ste...@workware.net.au wrote: On 10/08/2011, at 9:43 AM, Xiaofan Chen wrote: It was not up to date but very close. Anyway, I just updated it and the issue is still there with the release zip file. I will try the git tree later. === configuring in jimtcl (/cygdrive/d/work/openocd/openocd-0.5.0/build_mingw_cr oss/jimtcl) configure: running /bin/sh ../../jimtcl/configure.gnu --disable-option-checking '--prefix=/usr/local' '--build=i686-pc-mingw32' '--enable-jlink' '--enable-ft22 32_libftdi' 'build_alias=i686-pc-mingw32' --cache-file=/dev/null --srcdir=../../ jimtcl ../../jimtcl/configure: line 3: D:/work/openocd/openocd-0.5.0/jimtcl/autosetup/j : No such file or directory ../../jimtcl/configure: line 3: exec: D:/work/openocd/openocd-0.5.0/jimtcl/autos : cannot execute: No such file or directory configure: error: ../../jimtcl/configure.gnu failed for jimtcl You have something weird going on there. Note how the lines are truncated. For example: ../../jimtcl/configure: line 3: D:/work/openocd/openocd-0.5.0/jimtcl/autosetup/j : No such file or directory Yes I agree that the error message is quite strange. It is directly copy and paste from the Cygwin prompt. I will check again. The other errors under MinGW are also quite strange. I think I will try another setup. Or is that your cut and paste of the error messages? If so, please add the errors as an attachment instead. FYI: I build the release tarball on windows/mingw without any problems. Glad to know that. As per the previous answer from Spen that MinGW/Msys is not supported by jimtcl. Is that not true? -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Jlink Question
On Tue, Aug 9, 2011 at 2:01 AM, Carlson Gary gcarl...@carlson-minot.com wrote: A while back I vaguely remember seeing something on this forum that the latest jlink dongles were having some problems running with OpenOCD. Now I can¹t seem to find the post when I need it the most. I was hoping other jlink users might be able to quickly jog my memory as to what the issue was and the resolution ‹ if any. I currently have an Atmel SAM-ICE which is basically a restricted jlink with older firmware. For the most part this has ran fine in OpenOCD. Unfortunately I have a new project that requires a processor from a different manufacturer and obviously won¹t work with the SAM-ICE dongles I current have. Before I buy one of the unrestricted Segger devices I figured it might be a prudent thing to do a quick investigation first. Yes OpenOCD has some problems with the later firmware version of J-Link (V8). You can however downgrade the J-Link firmware to an older version to use OpenOCD. http://marc.info/?l=openocd-developmentm=131220636316948w=2 -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Invitation to connect on LinkedIn
LinkedIn I'd like to add you to my professional network on LinkedIn. - Xiaofan Xiaofan Chen Staff Engineer at Rockwell Automation Singapore Confirm that you know Xiaofan Chen https://www.linkedin.com/e/-kctfi4-gr1w3nfu-36/isd/3781281894/mL3mFidZ/ -- (c) 2011, LinkedIn Corporation___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Invitation to connect on LinkedIn
On Sun, Aug 7, 2011 at 6:48 PM, Xiaofan Chen xiaof...@gmail.com wrote: LinkedIn I'd like to add you to my professional network on LinkedIn. Please ignore this. I accidentally click a yes... Sorry! -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Windows 7 J-Link Problems
On Mon, Aug 1, 2011 at 9:45 PM, Eric Wetzel thewet...@gmail.com wrote:
I did a rather tedious bisection on the J-Link firmwares released by
Segger. Here is where the defect is introduced:
V4.14h: Bad (tested) J-Link ARM V8 compiled Aug 4 2010 19:16:19
The last good version was:
V4.14g: Good (tested) J-Link ARM V8 compiled Dec 1 2009 11:42:48
Their Release Notes aren't very consistent in these packages, being
labeled Release notes for J-Flash ARM V4.08a and having version
information only up until V4.12. But who knows what they could have
changed in 8 months.
And I tested the latest version (V4.32) to ensure that the problem
wasn't corrected on their end, and it was not.
I only tested this on my V8 J-Link, but Xiaofan said that the V7 works fine.
I just tried V6 and it seems to work as well.
SEGGER J-Link Commander V4.32 ('?' for help)
Compiled Jul 29 2011 18:38:14
DLL version V4.32, compiled Jul 29 2011 18:37:55
Firmware: J-Link ARM V6 compiled Feb 1 2011 14:28:14
Hardware: V6.00
S/N: xx
OEM: IAR
J-Linkf
Firmware: J-Link ARM V6 compiled Feb 1 2011 14:28:14
Hardware: V6.00
J-Linkst
VTarget=3.274V
ITarget=109mA
TCK=1 TDI=0 TDO=1 TMS=0 TRES=1 TRST=1
Supported JTAG speeds:
- 48 MHz/n, (n=4). = 12000kHz, 9600kHz, 8000kHz, ...
- Adaptive clocking
J-Linki
JTAG Id: 0x4F1F0F0F Version: 0x4 Part no: 0xf1f0 Man. Id: 0787
J-Linktestrspeed
Speed test: Reading 8 * 8kb from address 0x Info: RTCK reaction time is
approx. 126ns
Info: Auto JTAG speed: Adaptive
8 kByte read in 82ms ! (99.8 KByte/sec)
J-Linktestrspeed
Speed test: Reading 8 * 128kb from address 0x
128 kByte read in 1197ms ! (109.5 KByte/sec)
C:\temp\openocd-0.5rc1\binopenocd-0.5.0-rc1.exe -f
interface\jlink.cfg -f target\lpc2468.cfg
(note: this is not proper config, I am testing with an IAR LPC-2468 KS board).
Open On-Chip Debugger 0.5.0-dev (2011-07-11-21:12)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Warn : Adapter driver 'jlink' did not declare which transports it allows; assumi
ng legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
init_targets
Warning - assuming default core clock 4MHz! Flashing may fail if
actual core clock is different.
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
500 kHz
Info : J-Link initialization started / target CPU reset initiated
Info : J-Link ARM V6 compiled Feb 1 2011 14:28:14
Info : J-Link caps 0x99ff7bbf
Info : J-Link hw version 6
Info : J-Link hw type J-Link
Info : J-Link max mem block 8864
Info : J-Link configuration
Info : USB-Address: 0xff
Info : Kickstart power on JTAG-pin 19: 0xff01
Info : Vref = 3.274 TCK = 1 TDI = 0 TDO = 1 TMS = 0 SRST = 1 TRST = 0
Info : J-Link JTAG Interface ready
Info : clock speed 500 kHz
Info : JTAG tap: lpc2468.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787,
part: 0xf1f0, ver: 0x4)
Info : Embedded ICE version 7
Error: EmbeddedICE v7 handling might be broken
Info : lpc2468.cpu: hardware has 2 breakpoint/watchpoint units
Just wondering who has a nice board file for IAR LPC-2468 KS?
--
Xiaofan
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] rename st32 flash drivers
On Thu, Jul 28, 2011 at 8:55 PM, Spencer Oliver s...@spen-soft.co.uk wrote: I sort of like the x - but the majority rules. Any more votes? I like the x as well. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] JLink woes
2011/7/17 Michel Catudal michelcatu...@gmail.com: Isn't the Atmel ICE a cheaper and limited version of Jlink? Isn't possible that the software change was made to make sure that it would not work with OpenOCD? This is probably not true. Atmel Sam-ICE is an OEM version of Segger J-Link which limits it to the Atmel MCU/MPUs. There are OEM versions which have some limitations. IAR's OEM version has the least limitations (not working inside Keil MDK but works for all vendors' device). http://www.segger.com/cms/terms-of-use.html If you can get OpenOCD to work with the cheaper version then you are hurting Segger's profits. I would be suprised if they would agree to not be in full control of their hardware. OpenOCD does break some limitations of the OEM versions of J-Link since it does not limit them to a specific vendor's device. I am not so sure if this is a big problem for Segger or not. If it is, probably they will request OpenOCD to put in the limitation codes (detect the J-Link and detect the target), so far I have not seen anything like that. If Segger keeps up nonsense like that wouldn't the solution be to ignore them and go with something like Versaloon or any other manufacturer who doesn't make it a routine to break our code? Many of us have various version of J-Link. So that is probably the best incentive to support it. It is a good one in terms of capability. Similarly there are desires to support vendor's proprietary Jtag hardware like ST-Link, LPC-Link simply because many of us got them even though they are not as open as Versaloon. Can you reflash the Jlink that have issues with an older software version or is it new hardware? Yes you can and that is the current work-around for J-Link V8. Probably it will be the same story for J-Link Pro and J-Link Ultra. It does not seem to affect V7/V6 or below. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD libftdi and ftd2xx benchmark
On Sat, Jul 16, 2011 at 7:46 PM, Uwe Bonnes b...@elektron.ikp.physik.tu-darmstadt.de wrote: B.t.w. a question to those working with WinUSB: Is it possible to map the calls to winusb.dll to libusb at all? How much work will be involved? The reason why I ask: If we can map all calls to winusb to libusb, a replacement dll can be written for Wine and winusb programs can be run on Linux and other systems that can run Wine/libusb. I have writte a similar replacement-dll for ftd2xx. I could run FTDI mprog.exe on Linux with it. I tried to integrate into official Wine, but patch requests got by unnotices/uncommented/unappied. I see. I tend to think this is pretty difficult. http://msdn.microsoft.com/en-us/library/ff540046%28v=vs.85%29.aspx#winusb Some of the calls are not possible to map to libusb right now. Eg 1: pipe policy http://msdn.microsoft.com/en-us/library/ff728833%28v=vs.85%29.aspx Eg 2: power policy http://msdn.microsoft.com/en-us/library/ff540309%28v=vs.85%29.aspx This may not be easy as well: async I/O for Windows is pretty different http://msdn.microsoft.com/en-us/library/ff540263%28v=vs.85%29.aspx -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD libftdi and ftd2xx benchmark
On Sat, Jul 16, 2011 at 1:21 PM, Peter Stuge pe...@stuge.se wrote: I did some tests for libftdi-1.0 last time and it did not offer any speed improvement for OpenOCD since OpenOCD has not taken the advantage of the libftdi-1.0 async API. Yes, I also don't expect speed advantages without rewrite, but rather usability advantages basically thanks to libwdi and libusb-1/WinUSB. That is arguable. Yes libwdi/Zadig makes it easier to replace FTD2xx driver with WinUSB so as to use libusb-1.0/libftdi-1.0. On the other hand, libusb-win32's GUI Inf-Wizard is also easy to use so that user can replace ftd2xx driver with libusb0.sys so as to use libusb-win32/libftdi-0.1x under Windows. Moreover, libusb-win32's GUI Filter Wizard makes it very easy to add filter driver on top of the existing ftd2xx driver in order to use libftdi-0.1x. The user does not even need to repace the ftd2xx driver so they can continue to use other tools relying on the ftd2xx driver. The libusb-win32 filter driver is also perfect for use with other Jtag device like J-Link. You can keep using Segger's driver so that you can continue using IAR/Keil/etc. And you can add the filter driver in order to use OpenOCD. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD libftdi and ftd2xx benchmark
On Sat, Jul 16, 2011 at 10:55 AM, Xiaofan Chen xiaof...@gmail.com wrote: On Sat, Jul 16, 2011 at 10:31 AM, Xiaofan Chen xiaof...@gmail.com wrote: Actually the result is pretty close for the LPC-P2148 based test. jtag_khz = 1500 KHz, 38.927 KiB/s (ftd2xx) versus 38.754 KiB/s. The above is for Amontec JtagKey2 which is high speed USB. The J-Link under OpenOCD (full speed USB but with intelligence in it) seems much slower than Amontec JtagKey2. The speed is 18.813 KiB/s at the same 1500KHz jtag_khz for J-Link (V6, IAR OEM). On the other hand, J-Link can be much faster when not using OpenOCD but Segger's own gdb server. So OpenOCD has a long way to go to match that one. Reference: http://www.yagarto.de/projects/jtagspeed/index.html Other historical reference, it seems OpenOCD is getting faster and faster with each release. So it is good. http://comments.gmane.org/gmane.comp.debugging.openocd.devel/7425 Overall, I think Øyvind Harboe's thoughts are good. https://lists.berlios.de/pipermail/openocd-development/2010-October/016724.html Somebody just has to step up and do the work to profile the Cortex-M3 flash programming case and rewrite the higher level codes and performance should be dramatically improved. From a maintenance point of view, I believe it would be *MUCH* more economical to simply fix the higher level OpenOCD code to be more robust towards longer latencies. That code can be tested on *all* interfaces. If OpenOCD can get maintainable code that runs at 50% maximum theoretical throughput, then I think we should be very pleased. More performance is better, but at 50% throughput, I wouldn't trade much for reduced maintainability. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD libftdi and ftd2xx benchmark
On Sat, Jul 16, 2011 at 8:58 AM, Xiaofan Chen xiaof...@gmail.com wrote: For the USB 2.0 Jtagkey2, using the WHQL driver and ftd2xx is only about 5% faster than using libftdi and libusb-win32 filter driver on top of the WHQL driver. jtag_khz = 1200 KHz, 11.826 KiB/s (ftd2xx) versus 11.296 KiB/s (libftdi), (4.7% faster) jtag_khz = 3000 KHz, 12.729 KiB/s (ftd2xx) versus 12.096 KiB/s (libftdi), (5.2% faster) But I will finish the test under Linux first. Since I got not good result under Ubuntu Linux, ..., I will probably go back to Ubuntu to see whether I might have done something differently. I rebuilt everything (libusb-stuge, libftdi-1.0 and OpenOCD) under Ubuntu 11.04 (to try out libftdi-1.0) and now the result under Ubuntu is more in line with other test results. The test shows that ftd2xx does not offer any advantages compared to libftdi under this test. On the other hand, after the higher level codes are sorted out, then probably the lower level codes can be more important in the future. The test also shows OpenOCD's speed get better with bigger binary size. For smaller binary of 123904 Bytes. jtag_khz = 1200 KHz, 11.294 KiB/s (ftd2xx) versus 11.296 KiB/s (libftdi) jtag_khz = 3000 KHz, 12.080 KiB/s (ftd2xx) versus 12.086 KiB/s (libftdi) For bigger binary of 262144 Bytes. jtag_khz=3000 KHz, 17.518 KiB/s (ftd2xx) versus 17.520 KiB/s (libftdi) mcuee@Ubuntu:~/Desktop/build/openocd/lm3s1968$ openocd -f luminary_jtagkey2.cfgOpen On-Chip Debugger 0.5.0-dev-00956-ge7269e3-dirty (2011-07-17-07:47) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' 500 kHz Info : max TCK change to: 3 kHz Info : clock speed 500 kHz Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints Info : accepting 'telnet' connection from 500 kHz cortex_m3 reset_config sysresetreq Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x0100 pc: 0x0001e340 msp: 0x2200 1200 kHz flash 'stellaris' found at 0x auto erase enabled wrote 123904 bytes from file demo.bin in 10.711829s (11.296 KiB/s) 3000 kHz flash 'stellaris' found at 0x auto erase enabled wrote 123904 bytes from file demo.bin in 10.011832s (12.086 KiB/s) flash 'stellaris' found at 0x auto erase enabled wrote 262144 bytes from file demobig.bin in 14.611854s (17.520 KiB/s) 500 kHz cortex_m3 reset_config sysresetreq Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) shutdown command invoked mcuee@Ubuntu:~/Desktop/build/openocd/lm3s1968$ openocd-d2xx -f luminary_jtagkey2.cfg Open On-Chip Debugger 0.5.0-dev-00956-ge7269e3-dirty (2011-07-17-07:48) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' 500 kHz Error: unable to get latency timer: 0 Error: ftd2xx 1.04 detected - this has known issues with FT_GetLatencyTimer, upgrade to a newer version Info : device: 6 2232H Info : deviceID: 67358712 Info : SerialNumber: 53T9XDR4A Info : Description: Amontec JTAGkey-2 A Info : max TCK change to: 3 kHz Info : clock speed 500 kHz Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints Info : accepting 'telnet' connection from 500 kHz cortex_m3 reset_config sysresetreq Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x0100 pc: 0x0001df0c msp: 0x2300 1200 kHz flash 'stellaris' found at 0x auto erase enabled wrote 123904 bytes from file demo.bin in 10.713832s (11.294 KiB/s) 3000 kHz flash 'stellaris' found at 0x auto erase enabled wrote 123904 bytes from file demo.bin in 10.016835s (12.080 KiB/s) auto erase enabled wrote 262144 bytes from file demobig.bin in 14.613848s (17.518 KiB/s) 500 kHz cortex_m3 reset_config sysresetreq Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) shutdown command invoked -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Profiling OpenOCD performance
https://lists.berlios.de/pipermail/openocd-development/2010-October/016725.html Øyvind Harboe wrote on Tue Oct 19 2010, As a start for debugging delay issues, type help jtag_flush_queue_sleep. Plot the performance of 0, 10 and 100ms of an operation. It should allow you to guestimate how much of the performance hit is due to long latencies. Here are the results. Does this mean that jtag interface latency does play a big part in performance? 1ms latency does not play a big part here. But from 2ms onwards, the performance dropped significantly. DelayFlash write speed 0ms 17.544 KiB/s 1ms 17.370 KiB/s 2ms 10.304 KiB/s 5ms6.457 KiB/s 10ms 3.916 KiB/s 100ms0.487KiB/s (seems to take forever) Tested under Ubuntu 11.04, EK-LM3S1968 demo board, JtagKey2 (FT2232H based high speed USB interface). mcuee@Ubuntu:~/Desktop/build/openocd/lm3s1968$ openocd -f luminary_jtagkey2.cfg Open On-Chip Debugger 0.5.0-dev-00956-ge7269e3-dirty (2011-07-17-07:47) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' 500 kHz Info : max TCK change to: 3 kHz Info : clock speed 500 kHz Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints Info : accepting 'telnet' connection from 500 kHz cortex_m3 reset_config sysresetreq Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x0100 pc: 0x0001e340 msp: 0x2200 3000 kHz flash 'stellaris' found at 0x ... Open On-Chip Debugger init reset halt 500 kHz cortex_m3 reset_config sysresetreq JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x0100 pc: 0x0001e340 msp: 0x2200 jtag_khz 3000 3000 kHz flash probe 0 flash 'stellaris' found at 0x help jtag_flush_queue_sleep jtag_flush_queue_sleep [sleep in ms] For debug purposes(simulate long delays of interface) to test performance or change in behavior. Default 0ms. (command valid any time) flash write_image erase demobig.bin auto erase enabled wrote 262144 bytes from file demobig.bin in 14.591845s (17.544 KiB/s) jtag_flush_queue_sleep jtag_flush_queue_sleep [sleep in ms] in procedure 'jtag_flush_queue_sleep' jtag_flush_queue_sleep 10 flash probe 0 flash 'stellaris' found at 0x flash write_image erase demobig.bin auto erase enabled wrote 262144 bytes from file demobig.bin in 65.373260s (3.916 KiB/s) jtag_flush_queue_sleep 100 flash write_image erase demobig.bin auto erase enabled wrote 262144 bytes from file demobig.bin in 525.208435s (0.487 KiB/s) jtag_flush_queue_sleep 1 flash write_image erase demobig.bin auto erase enabled wrote 262144 bytes from file demobig.bin in 14.737774s (17.370 KiB/s) jtag_flush_queue_sleep 2 flash write_image erase demobig.bin auto erase enabled wrote 262144 bytes from file demobig.bin in 24.845686s (10.304 KiB/s) jtag_flush_queue_sleep 5 flash write_image erase demobig.bin auto erase enabled wrote 262144 bytes from file demobig.bin in 39.648533s (6.457 KiB/s) -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Profiling OpenOCD performance
On Sun, Jul 17, 2011 at 9:05 AM, Xiaofan Chen xiaof...@gmail.com wrote: https://lists.berlios.de/pipermail/openocd-development/2010-October/016725.html Øyvind Harboe wrote on Tue Oct 19 2010, As a start for debugging delay issues, type help jtag_flush_queue_sleep. Plot the performance of 0, 10 and 100ms of an operation. It should allow you to guestimate how much of the performance hit is due to long latencies. Here are the results. Does this mean that jtag interface latency does play a big part in performance? 1ms latency does not play a big part here. But from 2ms onwards, the performance dropped significantly. Delay Flash write speed 0ms 17.544 KiB/s 1ms 17.370 KiB/s 2ms 10.304 KiB/s 5ms 6.457 KiB/s 10ms 3.916 KiB/s 100ms 0.487KiB/s (seems to take forever) Tested under Ubuntu 11.04, EK-LM3S1968 demo board, JtagKey2 (FT2232H based high speed USB interface). The other advice from Øyvind Harboe's is also quite good but I do not know how to modify the codes. https://lists.berlios.de/pipermail/openocd-development/2010-October/016727.html One interesting modification to OpenOCD might be to add some profiling metrics on inter-jtag_execute_queue() times. If there are large inter-jtag_execute_queue() times then I'd expect an async interface to help. Yet the other suggestion is to reduce the number of JTAG_EXECUTE by issuing longer clock/in out sequences. https://lists.berlios.de/pipermail/openocd-development/2010-October/016711.html https://lists.berlios.de/pipermail/openocd-development/2010-October/016722.html -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD libftdi and ftd2xx benchmark
On Thu, Jul 14, 2011 at 10:47 PM, Xiaofan Chen xiaof...@gmail.com wrote: Then I did similar test under Windows with libftdi-0.19 (with Liminary's FTDI driver and libusb-win32 filter driver). The speed is faster than under Linux. Kind of interesting. I will try the ftd2xx Windows build later. D:\work\openocd\build_cxf\openocd_14Jul2011_mingw32\binopenocd.exe -f board\ek-lm3s1968.cfg Open On-Chip Debugger 0.5.0-dev-00954-g0ea76bc-dirty (2011-07-14-21:37) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' 500 kHz Info : clock speed 500 kHz Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints Info : accepting 'telnet' connection from 500 kHz cortex_m3 reset_config sysresetreq Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x0100 pc: 0x0001e340 msp: 0x2200 1200 kHz flash 'stellaris' found at 0x auto erase enabled wrote 123904 bytes from file ./demo.bin in 11.093000s (10.908 KiB/s) Interestingly increasing the jtag_khz value does not help too much. This is with a different PC and with Freddie Chopin's binary but the result is similar. C:\cygwin\home\xfchen\openocd\openocd-0.5.0-rc1\tcl\binopenocd-0.5.0-rc1.exe -f board\ek-lm3s1968.cfg Open On-Chip Debugger 0.5.0-dev (2011-07-11-21:12) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' 500 kHz Info : clock speed 500 kHz Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints Info : accepting 'telnet' connection from 500 kHz cortex_m3 reset_config sysresetreq Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0x ba00, ver: 0x3) target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x0100 pc: 0x0001df0c msp: 0x2300 1200 kHz flash 'stellaris' found at 0x auto erase enabled wrote 123904 bytes from file demo.bin in 10.984515s (11.016 KiB/s) 6000 kHz flash 'stellaris' found at 0x auto erase enabled wrote 123904 bytes from file demo.bin in 10.499905s (11.524 KiB/s) -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD libftdi and ftd2xx benchmark
On Fri, Jul 15, 2011 at 4:32 PM, Freddie Chopin freddie_cho...@op.pl wrote: On 2011-07-15 10:29, Xiaofan Chen wrote: Interestingly increasing the jtag_khz value does not help too much. This is with a different PC and with Freddie Chopin's binary but the result is similar. Most probably you reached the limit with flash programming. To test just the throughput you could try uploads to RAM. You are probably right. I have not built the latest binary with ftd2xx. So I used your 0.4.0 binary and the d2xx 0.4.0 binary I built last time. The speed is basically the same for libftdi and d2xx in this case (10.760KB/sec versus 10.900 KB/sec at jtag_khz=1200 KHz) D:\work\openocd\binary_chopin\OpenOCD\0.4.0\binopenocd.exe -f board/ek-lm3s1968.cfg Open On-Chip Debugger 0.4.0 (2010-02-22-19:05) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html 3000 kHz jtag_nsrst_delay: 100 srst_only separate srst_gates_jtag srst_open_drain Info : clock speed 3000 kHz Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints Info : accepting 'telnet' connection from 0 Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x0100 pc: 0x0001df88 msp: 0x2200 1200 kHz flash 'stellaris' found at 0x auto erase enabled Warn : not enough working area available(requested 8192, free 8152) wrote 123904 bytes from file demo.bin in 11.245000s (10.760 kb/s) Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) D:\work\openocd\binary_chopin\OpenOCD\0.4.0\binopenocd_d2xx -f board/ek-lm3s1968.cfg Open On-Chip Debugger 0.4.0 (2010-09-13-20:47) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html 3000 kHz jtag_nsrst_delay: 100 srst_only separate srst_gates_jtag srst_open_drain Info : device: 4 2232C Info : deviceID: 67353817 Info : SerialNumber: 070200A1A Info : Description: Stellaris Evaluation Board A Info : clock speed 3000 kHz Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints Info : accepting 'telnet' connection from 0 Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x0100 pc: 0x0001df0c msp: 0x2300 1200 kHz flash 'stellaris' found at 0x auto erase enabled Warn : not enough working area available(requested 8192, free 8152) wrote 123904 bytes from file demo.bin in 11.101000s (10.900 kb/s) 6000 kHz flash 'stellaris' found at 0x auto erase enabled Warn : not enough working area available(requested 8192, free 8152) wrote 123904 bytes from file demo.bin in 10.358000s (11.682 kb/s) -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD libftdi and ftd2xx benchmark
On Fri, Jul 15, 2011 at 5:36 PM, Laurent Gauch laurent.ga...@amontec.com wrote: Do you have a Amontec JTAGkey-2 (High-speed USB 2.0) ? Yes. If yes, please do the same comparaison with libusb and d2xx on Linux and windows, and with the Amontec JTAGkey D2XX device driver package WHQL certified . No problem. I will do it after I build the d2xx binary for Windows. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD libftdi and ftd2xx benchmark
On Fri, Jul 15, 2011 at 6:02 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Fri, Jul 15, 2011 at 5:36 PM, Laurent Gauch laurent.ga...@amontec.com wrote: Do you have a Amontec JTAGkey-2 (High-speed USB 2.0) ? Yes. If yes, please do the same comparaison with libusb and d2xx on Linux and windows, and with the Amontec JTAGkey D2XX device driver package WHQL certified . No problem. I will do it after I build the d2xx binary for Windows. Anyway here is the test with libftdi driver first. I think Freddie is probably right. There is still a bit of bump compared to the on-board ftdi2232C based Luminary-ICDI interface. jtag_khz = 1200 KHz, 11.820 KiB/s versus 11.016 KiB/s jtag_khz = max supported, 12.729 KiB/s versus 11.524 KiB/s D:\work\openocd\binary_chopin\openocd-0.5.0-rc1\tcl\binopenocd-0.5.0-rc1.exe -f ek-lm3s1968_jtagkey2.cfg Open On-Chip Debugger 0.5.0-dev (2011-07-11-21:12) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' 500 kHz Info : max TCK change to: 3 kHz Info : clock speed 500 kHz Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints Info : accepting 'telnet' connection from 500 kHz cortex_m3 reset_config sysresetreq Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x0100 pc: 0x0001df0c msp: 0x2300 1200 kHz flash 'stellaris' found at 0x auto erase enabled wrote 123904 bytes from file demo.bin in 10.237000s (11.820 KiB/s) 3000 kHz flash 'stellaris' found at 0x auto erase enabled wrote 123904 bytes from file demo.bin in 9.506000s (12.729 KiB/s) -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD libftdi and ftd2xx benchmark
On Fri, Jul 15, 2011 at 6:29 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Fri, Jul 15, 2011 at 6:02 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Fri, Jul 15, 2011 at 5:36 PM, Laurent Gauch laurent.ga...@amontec.com wrote: Do you have a Amontec JTAGkey-2 (High-speed USB 2.0) ? Yes. If yes, please do the same comparaison with libusb and d2xx on Linux and windows, and with the Amontec JTAGkey D2XX device driver package WHQL certified . No problem. I will do it after I build the d2xx binary for Windows. Anyway here is the test with libftdi driver first. I think Freddie is probably right. There is still a bit of speed bump compared to the on-board ftdi2232C based Luminary-ICDI interface. jtag_khz = 1200 KHz, 11.820 KiB/s versus 11.016 KiB/s jtag_khz = max supported, 12.729 KiB/s versus 11.524 KiB/s (10% faster) For the USB 2.0 Jtagkey2, using the WHQL driver and ftd2xx is only about 5% faster than using libftdi and libusb-win32 filter driver on top of the WHQL driver. jtag_khz = 1200 KHz, 11.826 KiB/s (ftd2xx) versus 11.296 KiB/s (libftdi), (4.7% faster) jtag_khz = 3000 KHz, 12.729 KiB/s (ftd2xx) versus 12.096 KiB/s (libftdi), (5.2% faster) Probably I will try another target to see the flash download difference. D:\work\openocd\build_cxf\openocd_15Jul2011\binopenocd_libftdi_mingw.exe -f ek-lm3s1968_jtagkey2.cfg Open On-Chip Debugger 0.5.0-dev-00956-ge7269e3-dirty (2011-07-15-22:00) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' 500 kHz Info : max TCK change to: 3 kHz Info : clock speed 500 kHz Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints Info : accepting 'telnet' connection from 500 kHz cortex_m3 reset_config sysresetreq Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x0100 pc: 0x0001df0c msp: 0x2300 1200 kHz flash 'stellaris' found at 0x auto erase enabled wrote 123904 bytes from file demo.bin in 10.712000s (11.296 KiB/s) 3000 kHz flash 'stellaris' found at 0x auto erase enabled wrote 123904 bytes from file demo.bin in 10.003000s (12.096 KiB/s) D:\work\openocd\build_cxf\openocd_15Jul2011\binopenocd_mingw_d2xx.exe -f ek-lm3s1968_jtagkey2.cfg Open On-Chip Debugger 0.5.0-dev-00956-ge7269e3-dirty (2011-07-15-21:46) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' 500 kHz Info : device: 6 2232H Info : deviceID: 67358712 Info : SerialNumber: 53T9XDR4A Info : Description: Amontec JTAGkey-2 A Info : max TCK change to: 3 kHz Info : clock speed 500 kHz Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints Info : accepting 'telnet' connection from 500 kHz cortex_m3 reset_config sysresetreq Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x0100 pc: 0x0001df0c msp: 0x2300 1200 kHz flash 'stellaris' found at 0x auto erase enabled wrote 123904 bytes from file demo.bin in 10.232000s (11.826 KiB/s) 3000 kHz flash 'stellaris' found at 0x auto erase enabled wrote 123904 bytes from file demo.bin in 9.506000s (12.729 KiB/s) -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD libftdi and ftd2xx benchmark
On Fri, Jul 15, 2011 at 10:28 PM, Laurent Gauch laurent.ga...@amontec.com wrote: Xiaofan Chen wrote: I think Freddie is probably right. There is still a bit of speed bump compared to the on-board ftdi2232C based Luminary-ICDI interface. jtag_khz = 1200 KHz, 11.820 KiB/s versus 11.016 KiB/s jtag_khz = max supported, 12.729 KiB/s versus 11.524 KiB/s (10% faster) For the USB 2.0 Jtagkey2, using the WHQL driver and ftd2xx is only about 5% faster than using libftdi and libusb-win32 filter driver on top of the WHQL driver. jtag_khz = 1200 KHz, 11.826 KiB/s (ftd2xx) versus 11.296 KiB/s (libftdi), (4.7% faster) jtag_khz = 3000 KHz, 12.729 KiB/s (ftd2xx) versus 12.096 KiB/s (libftdi), (5.2% faster) Probably I will try another target to see the flash download speed difference. I think Freddie is right that the speed is rather limited by the Flash. On a USB 2.0 High-Speed port or under USB HUB full-speed ? On a USB 2.0 High-Speed port. This is with a 3-year old PC running Windows 7 Ultimate 32bit (Core 2 Duo E4700, 2GB RAM). Output from USBView. http://www.ftdichip.com/Support/Utilities.htm Take note of the Device Bus Speed: High and the fact that bulk endpoint size is 512B. Device Descriptor: bcdUSB: 0x0200 bDeviceClass: 0x00 bDeviceSubClass: 0x00 bDeviceProtocol: 0x00 bMaxPacketSize0: 0x40 (64) idVendor: 0x0403 (Future Technology Devices International Limited) idProduct: 0xCFF8 bcdDevice: 0x0700 iManufacturer:0x01 iProduct: 0x02 iSerialNumber:0x03 bNumConfigurations: 0x01 ConnectionStatus: DeviceConnected Current Config Value: 0x01 Device Bus Speed: High Device Address: 0x01 Open Pipes: 4 Endpoint Descriptor: bEndpointAddress: 0x81 IN Transfer Type:Bulk wMaxPacketSize: 0x0200 (512) bInterval:0x00 Endpoint Descriptor: bEndpointAddress: 0x02 OUT Transfer Type:Bulk wMaxPacketSize: 0x0200 (512) bInterval:0x00 Endpoint Descriptor: bEndpointAddress: 0x83 IN Transfer Type:Bulk wMaxPacketSize: 0x0200 (512) bInterval:0x00 Endpoint Descriptor: bEndpointAddress: 0x04 OUT Transfer Type:Bulk wMaxPacketSize: 0x0200 (512) bInterval:0x00 -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD libftdi and ftd2xx benchmark
Historical reference back in June 2009. Under Linux, Dominic found no much difference between libftdi and ftd2xx. https://lists.berlios.de/pipermail/openocd-development/2009-June/008846.html My test results support this conclusion under Linux. Under Windows, Freddie found that ftd2xx is significantly faster than libftdi. I will try to use LPC-P2148 to see if that is still the case now. https://lists.berlios.de/pipermail/openocd-development/2009-June/008193.html Tested with a ~29kB image on LPC2103 (upload to flash): libftdi: Start address 0x3c, load size 29640 Transfer rate: 6 KB/sec, 14820 bytes/write. ftd2xx: Start address 0x3c, load size 29640 Transfer rate: 15 KB/sec, 14820 bytes/write. So: libftdi is 2.5x slower Tested with ~114kB image on STM32 (upload to flash): libftdi: Start address 0x8000134, load size 114432 Transfer rate: 8 KB/sec, 16347 bytes/write. ftd2xx: Start address 0x8000134, load size 114432 Transfer rate: 11 KB/sec, 16347 bytes/write. Again slower, this time only about 30%, but still, that's nowhere to comparable -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD libftdi and ftd2xx benchmark
On Sat, Jul 16, 2011 at 12:23 AM, Uwe Bonnes b...@elektron.ikp.physik.tu-darmstadt.de wrote: hello, a short view into jtag/drivers/ft2232.c shows, that the asynchronous api of libftdi-1 is not used. ftd2xx however uses a second thread to continous poll the FTDI chip for data to read. So on ft2232_read(), ftd2xx can start to deliver data, while the libftdi patch has to first send the read usb request and then wait for data. That is exactly right. This is one potential improvement in the future but the change may require quite a bit of work. Now that both you (the current main driver of libftdi-1.0 and developer of xc3sprog) and Jie Zhang (original author of libftdi-1.0 and contributor to urjtag) are here, maybe somethings can be done. :-) However, as per Øyvind Harboe, it is probably more important to profile some upper level OpenOCD codes first. So there is room for improvement with libftdi. But beware, to my knowledge, libftdi-1 on Win32 needs much user fiddling because of libusb-1 on win32, if it is fit for purpose at all. I see two problems here. Firstly even for Linux, there is no official release for libftdi-1.0 yet. Secondly you are right that libusb-1.0.9 (first release to include Windows support) has not been released. It also requires the user to switch to WinUSB driver but I think that is not a big problem because of GUI driver switching utility (Zadig/libwdi). -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD libftdi and ftd2xx benchmark
On Fri, Jul 15, 2011 at 10:24 PM, Xiaofan Chen xiaof...@gmail.com wrote: I think Freddie is probably right. There is still a bit of speed bump compared to the on-board ftdi2232C based Luminary-ICDI interface. jtag_khz = 1200 KHz, 11.820 KiB/s versus 11.016 KiB/s jtag_khz = max supported, 12.729 KiB/s versus 11.524 KiB/s (10% faster) For the USB 2.0 Jtagkey2, using the WHQL driver and ftd2xx is only about 5% faster than using libftdi and libusb-win32 filter driver on top of the WHQL driver. jtag_khz = 1200 KHz, 11.826 KiB/s (ftd2xx) versus 11.296 KiB/s (libftdi), (4.7% faster) jtag_khz = 3000 KHz, 12.729 KiB/s (ftd2xx) versus 12.096 KiB/s (libftdi), (5.2% faster) Probably I will try another target to see the flash download difference. But I will finish the test under Linux first. Since I got not good result under Ubuntu Linux (which still uses libusb-0.1), I switched to Arch Linux which is usually a bit faster than Ubuntu (but Gnome 3 is in the same league as Unity, both are worse than Gnome 2). I will probably go back to Ubuntu to see whether I might have done something differently. Then I get similar result as Windos under Linux. Interestingly the speed is almost the same in Arch Linux as compared to Windows 7. ftd2xx-1.04 is faster than libftdi-0.19 by about 5%. That is what I expected since ftd2xx-1.04 uses libusb-1.0.8's async API feature under Linux. jtag_khz = 1200 KHz, 11.826 KiB/s (ftd2xx) versus 11.296 KiB/s (libftdi), (4.7% faster) jtag_khz = 3000 KHz, 12.729 KiB/s (ftd2xx) versus 12.093 KiB/s (libftdi), (5.2% faster) [mcuee@myhost lm3s1968]$ openocd -f ek-lm3s1968_jtagkey2.cfg Open On-Chip Debugger 0.5.0-dev-00956-ge7269e3 (2011-07-16-08:25) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' 500 kHz Info : max TCK change to: 3 kHz Info : clock speed 500 kHz Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints Info : accepting 'telnet' connection from 500 kHz cortex_m3 reset_config sysresetreq Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x0100 pc: 0x0001df0c msp: 0x2300 1200 kHz flash 'stellaris' found at 0x auto erase enabled wrote 123904 bytes from file demo.bin in 10.711820s (11.296 KiB/s) 3000 kHz flash 'stellaris' found at 0x auto erase enabled wrote 123904 bytes from file demo.bin in 10.005830s (12.093 KiB/s) [mcuee@myhost lm3s1968]$ openocd-d2xx -f ek-lm3s1968_jtagkey2.cfg Open On-Chip Debugger 0.5.0-dev-00956-ge7269e3 (2011-07-16-08:28) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' 500 kHz Error: unable to get latency timer: 0 Error: ftd2xx 1.04 detected - this has known issues with FT_GetLatencyTimer, upgrade to a newer version Info : device: 6 2232H Info : deviceID: 67358712 Info : SerialNumber: 53T9XDR4A Info : Description: Amontec JTAGkey-2 A Info : max TCK change to: 3 kHz Info : clock speed 500 kHz Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints Info : accepting 'telnet' connection from 500 kHz cortex_m3 reset_config sysresetreq Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x0100 pc: 0x0001df0c msp: 0x2300 1200 kHz flash 'stellaris' found at 0x auto erase enabled wrote 123904 bytes from file demo.bin in 10.231838s (11.826 KiB/s) 3000 kHz flash 'stellaris' found at 0x auto erase enabled wrote 123904 bytes from file demo.bin in 9.505806s (12.729 KiB/s) 500 kHz cortex_m3 reset_config sysresetreq Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD libftdi and ftd2xx benchmark
On Fri, Jul 15, 2011 at 10:38 PM, Xiaofan Chen xiaof...@gmail.com wrote: Historical reference back in June 2009. Under Windows, Freddie found that ftd2xx is significantly faster than libftdi. I will try to use LPC-P2148 to see if that is still the case now. https://lists.berlios.de/pipermail/openocd-development/2009-June/008193.html Tested with a ~29kB image on LPC2103 (upload to flash): libftdi: Start address 0x3c, load size 29640 Transfer rate: 6 KB/sec, 14820 bytes/write. ftd2xx: Start address 0x3c, load size 29640 Transfer rate: 15 KB/sec, 14820 bytes/write. So: libftdi is 2.5x slower Tested with ~114kB image on STM32 (upload to flash): libftdi: Start address 0x8000134, load size 114432 Transfer rate: 8 KB/sec, 16347 bytes/write. ftd2xx: Start address 0x8000134, load size 114432 Transfer rate: 11 KB/sec, 16347 bytes/write. Again slower, this time only about 30%, but still, that's nowhere to comparable Actually the result is pretty close for the LPC-P2148 based test. jtag_khz = 1500 KHz, 38.927 KiB/s (ftd2xx) versus 38.754 KiB/s. D:\work\openocd\build_cxf\openocd_15Jul2011\binopenocd_mingw_d2xx.exe -f olimex_lpc_p2148_jtagkey2.cfg Open On-Chip Debugger 0.5.0-dev-00956-ge7269e3-dirty (2011-07-15-21:46) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' Warning - assuming default core clock 12MHz! Flashing may fail if actual core clock is different. trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain adapter_nsrst_delay: 100 jtag_ntrst_delay: 100 1500 kHz Info : device: 6 2232H Info : deviceID: 67358712 Info : SerialNumber: 53T9XDR4A Info : Description: Amontec JTAGkey-2 A Info : max TCK change to: 3 kHz Info : clock speed 1500 kHz Info : JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4) Info : Embedded ICE version 4 Info : lpc2148.cpu: hardware has 2 breakpoint/watchpoint units Info : accepting 'telnet' connection from Info : JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4) target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x00d3 pc: 0x Warn : NOTE! DCC downloads have not been enabled, defaulting to slow memory writes. Type 'help dcc Warn : NOTE! Severe performance degradation without fast memory access enabled. Type 'help fast'. fast memory access is enabled dcc downloads are enabled erased sectors 0 through 26 on flash bank 0 in 0.446000s wrote 232748 bytes from file lpc2148.hex in 5.839000s (38.927 KiB/s) D:\work\openocd\build_cxf\openocd_15Jul2011\binopenocd_libftdi_mingw.exe -f olimex_lpc_p2148_jtagkey2.cfg Open On-Chip Debugger 0.5.0-dev-00956-ge7269e3-dirty (2011-07-15-22:00) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' Warning - assuming default core clock 12MHz! Flashing may fail if actual core clock is different. trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain adapter_nsrst_delay: 100 jtag_ntrst_delay: 100 1500 kHz Info : max TCK change to: 3 kHz Info : clock speed 1500 kHz Info : JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4) Info : Embedded ICE version 4 Info : lpc2148.cpu: hardware has 2 breakpoint/watchpoint units Info : accepting 'telnet' connection from Info : JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4) target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x00d3 pc: 0x Warn : NOTE! DCC downloads have not been enabled, defaulting to slow memory writes. Type 'help dcc' Warn : NOTE! Severe performance degradation without fast memory access enabled. Type 'help fast'. fast memory access is enabled dcc downloads are enabled erased sectors 0 through 26 on flash bank 0 in 0.446000s wrote 232748 bytes from file lpc2148.hex in 5.865000s (38.754 KiB/s) -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD libftdi and ftd2xx benchmark
On Sat, Jul 16, 2011 at 10:31 AM, Xiaofan Chen xiaof...@gmail.com wrote: Actually the result is pretty close for the LPC-P2148 based test. jtag_khz = 1500 KHz, 38.927 KiB/s (ftd2xx) versus 38.754 KiB/s. The above is for Amontec JtagKey2 which is high speed USB. The J-Link under OpenOCD (full speed USB but with intelligence in it) seems much slower than Amontec JtagKey2. The speed is 18.813 KiB/s at the same 1500KHz jtag_khz for J-Link (V6, IAR OEM). D:\work\openocd\build_cxf\openocd_15Jul2011\binopenocd_libftdi_mingw.exe -f olimex_lpc_p2148_jlink.cfg Open On-Chip Debugger 0.5.0-dev-00956-ge7269e3-dirty (2011-07-15-22:00) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Warn : Adapter driver 'jlink' did not declare which transports it allows; assuming legacy JTAG-only Info : only one transport option; autoselect 'jtag' Warning - assuming default core clock 12MHz! Flashing may fail if actual core clock is different. trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain adapter_nsrst_delay: 100 jtag_ntrst_delay: 100 1500 kHz Info : J-Link initialization started / target CPU reset initiated Info : J-Link ARM V6 compiled Feb 1 2011 14:28:14 Info : J-Link caps 0x99ff7bbf Info : J-Link hw version 6 Info : J-Link hw type J-Link Info : J-Link max mem block 8864 Info : J-Link configuration Info : USB-Address: 0xff Info : Kickstart power on JTAG-pin 19: 0xff01 Info : Vref = 3.280 TCK = 1 TDI = 0 TDO = 0 TMS = 0 SRST = 0 TRST = 0 Info : J-Link JTAG Interface ready Info : clock speed 1500 kHz Info : JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4) Info : Embedded ICE version 4 Info : lpc2148.cpu: hardware has 2 breakpoint/watchpoint units Info : accepting 'telnet' connection from Info : JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4) target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x00d3 pc: 0x fast memory access is enabled dcc downloads are enabled wrote 232748 bytes from file lpc2148.hex in 12.082000s (18.813 KiB/s) -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD libftdi and ftd2xx benchmark
On Sat, Jul 16, 2011 at 10:49 AM, Peter Stuge pe...@stuge.se wrote: Many thanks for making these tests! Awesome! Xiaofan Chen wrote: Actually the result is pretty close for the LPC-P2148 based test. jtag_khz = 1500 KHz, 38.927 KiB/s (ftd2xx) versus 38.754 KiB/s. So in conclusion there is almost no difference in performance between OpenOCD using libftdi-0.19 and ftd2xx, or did I overlook something? Yes ftd2xx is only slightly faster based on my limited tests. Freddie, Laurant and others may have more inputs If not, I would suggest to only use libftdi in OpenOCD. I think it is still good to have both options. Uwe, do you see a possibility to port libftdi-0 over to use the libusb-1 API? If only synchronous is used it should be straight forward. I'm not saying that *you* must do it, but am rather asking how much effort it might be. libftdi-1.0 is based on libusb-1.0 and uses both sync API and a bit of async API. It is right now API compatible with libftdi-0.19. http://developer.intra2net.com/git/?p=libftdi-1.0 The benefit for OpenOCD would be that it can use libusb-1 on Windows without first having to rewrite the ft2232 driver. That is right. It is actually not difficult to switch to libftdi-1.0 since the current 1.0 API is compatible with libftdi-0.1x. That rewrite is absolutely desirable, but it seems that everyone agrees that the driver deserves and needs a thorough job, so would be nice to be able to punt on that and still be able to start using WinUSB and libusb-1. I did some tests for libftdi-1.0 last time and it did not offer any speed improvement for OpenOCD since OpenOCD has not taken the advantage of the libftdi-1.0 async API. http://lists.berlios.de/pipermail/openocd-development/2010-February/014895.html http://lists.berlios.de/pipermail/openocd-development/2010-February/014896.html -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Supported FTDI SWD layouts
On Thu, Jul 14, 2011 at 8:33 PM, Uwe Bonnes b...@elektron.ikp.physik.tu-darmstadt.de wrote: Hello, are there any other published FTDI-SWD hardware setup beside KTLINL http://sourceforge.net/apps/mediawiki/stm32primer2swd/index.php?title=File:Ktlink-buffers.png that support SWD and are supported by openocd? Maybe that is the only one. This one may be possible as well. http://www.seeedstudio.com/depot/bus-blaster-v2-jtag-debugger-p-807.html http://dangerousprototypes.com/docs/Bus_Blaster_v2_buffer_logic -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] OpenOCD libftdi and ftd2xx benchmark
On Wed, Jul 13, 2011 at 10:55 PM, Xiaofan Chen xiaof...@gmail.com wrote: Under Linux, ftd2xx 1.04 (based on libusb-1.0.8) does not seem to offer any advantage than libftdi (tested with 0.19) This is the same as reported last time. mcuee@Ubuntu:~/Desktop/build/openocd/lm3s1968$ openocd-d2xx -f board/ek-lm3s1968.cfg Open On-Chip Debugger 0.5.0-dev-00954-g0ea76bc (2011-07-13-20:28) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' 500 kHz Error: unable to get latency timer: 0 Error: ftd2xx 1.04 detected - this has known issues with FT_GetLatencyTimer, upgrade to a newer version Info : device: 4 2232C Info : deviceID: 67353817 Info : SerialNumber: 070200A1A Info : Description: Stellaris Evaluation Board A Info : clock speed 500 kHz Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints Info : accepting 'telnet' connection from 500 kHz cortex_m3 reset_config sysresetreq Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x0100 pc: 0x0001e340 msp: 0x2200 flash 'stellaris' found at 0x auto erase enabled wrote 262144 bytes from file ./demo.bin in 50.572987s (5.062 KiB/s) 500 kHz cortex_m3 reset_config sysresetreq Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x0100 pc: 0x0001e340 msp: 0x2200 1200 kHz flash 'stellaris' found at 0x auto erase enabled wrote 262144 bytes from file ./demo.bin in 42.674957s (5.999 KiB/s) ^C mcuee@Ubuntu:~/Desktop/build/openocd/lm3s1968$ openocd -f board/ek-lm3s1968.cfg Open On-Chip Debugger 0.5.0-dev-00954-g0ea76bc (2011-07-13-20:21) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' 500 kHz Info : clock speed 500 kHz Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints Info : accepting 'telnet' connection from 500 kHz cortex_m3 reset_config sysresetreq Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x0100 pc: 0x0001e340 msp: 0x2200 1200 kHz flash 'stellaris' found at 0x auto erase enabled wrote 262144 bytes from file ./demo.bin in 42.677986s (5.998 KiB/s) ^C Then I did similar test under Windows with libftdi-0.19 (with Liminary's FTDI driver and libusb-win32 filter driver). The speed is faster than under Linux. Kind of interesting. I will try the ftd2xx Windows build later. D:\work\openocd\build_cxf\openocd_14Jul2011_mingw32\binopenocd.exe -f board\ek-lm3s1968.cfg Open On-Chip Debugger 0.5.0-dev-00954-g0ea76bc-dirty (2011-07-14-21:37) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' 500 kHz Info : clock speed 500 kHz Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints Info : accepting 'telnet' connection from 500 kHz cortex_m3 reset_config sysresetreq Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x0100 pc: 0x0001e340 msp: 0x2200 1200 kHz flash 'stellaris' found at 0x auto erase enabled wrote 123904 bytes from file ./demo.bin in 11.093000s (10.908 KiB/s) -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] bootstrap wrarning under Ubuntu 11.04
I have seen some warnings when doing bootstrap. I am not so sure if this is a bug with Ubuntu autotools or with configure.in. The same problem exists in Ubuntu 10.10 and 10.04. mcuee@Ubuntu:~/Desktop/build/openocd/openocd$ ./bootstrap + aclocal configure.in:2: warning: AC_INIT: not a literal: OpenOCD Mailing List openocd-development@lists.berlios.de + libtoolize --automake --copy + autoconf configure.in:2: warning: AC_INIT: not a literal: OpenOCD Mailing List openocd-development@lists.berlios.de + autoheader configure.in:2: warning: AC_INIT: not a literal: OpenOCD Mailing List openocd-development@lists.berlios.de + automake --gnu --add-missing --copy configure.in:2: warning: AC_INIT: not a literal: OpenOCD Mailing List openocd-development@lists.berlios.de Setting up submodules Bootstrap complete. Quick build instructions: ./configure --enable-maintainer-mode mcuee@Ubuntu:~/Desktop/build/openocd/openocd$ autoconf --version autoconf (GNU Autoconf) 2.67 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+/Autoconf: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html, http://gnu.org/licenses/exceptions.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. mcuee@Ubuntu:~/Desktop/build/openocd/openocd$ automake --version automake (GNU automake) 1.11.1 Copyright (C) 2009 Free Software Foundation, Inc. License GPLv2+: GNU GPL version 2 or later http://gnu.org/licenses/gpl-2.0.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by Tom Tromey tro...@redhat.com and Alexandre Duret-Lutz a...@gnu.org. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/2] ft2232: Failure to get latency should not be fatal
On Wed, Jul 13, 2011 at 6:26 PM, Spencer Oliver s...@spen-soft.co.uk wrote: On 12 July 2011 20:41, Spencer Oliver s...@spen-soft.co.uk wrote: On 12/07/2011 16:03, Spencer Oliver wrote: I have pushed a fix for this issue - it checks the ftd2xx version etc. http://repo.or.cz/w/openocd/ntfreak.git If i do not here any objections i am going to push this to master. It should be included in the 0.5 release committed Yes this is good. Under Linux, ftd2xx 1.04 (based on libusb-1.0.8) does not seem to offer any advantage than libftdi (tested with 0.19) mcuee@Ubuntu:~/Desktop/build/openocd/lm3s1968$ openocd-d2xx -f board/ek-lm3s1968.cfg Open On-Chip Debugger 0.5.0-dev-00954-g0ea76bc (2011-07-13-20:28) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' 500 kHz Error: unable to get latency timer: 0 Error: ftd2xx 1.04 detected - this has known issues with FT_GetLatencyTimer, upgrade to a newer version Info : device: 4 2232C Info : deviceID: 67353817 Info : SerialNumber: 070200A1A Info : Description: Stellaris Evaluation Board A Info : clock speed 500 kHz Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints Info : accepting 'telnet' connection from 500 kHz cortex_m3 reset_config sysresetreq Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x0100 pc: 0x0001e340 msp: 0x2200 flash 'stellaris' found at 0x auto erase enabled wrote 262144 bytes from file ./demo.bin in 50.572987s (5.062 KiB/s) 500 kHz cortex_m3 reset_config sysresetreq Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x0100 pc: 0x0001e340 msp: 0x2200 1200 kHz flash 'stellaris' found at 0x auto erase enabled wrote 262144 bytes from file ./demo.bin in 42.674957s (5.999 KiB/s) ^C mcuee@Ubuntu:~/Desktop/build/openocd/lm3s1968$ openocd -f board/ek-lm3s1968.cfg Open On-Chip Debugger 0.5.0-dev-00954-g0ea76bc (2011-07-13-20:21) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' 500 kHz Info : clock speed 500 kHz Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints Info : accepting 'telnet' connection from 500 kHz cortex_m3 reset_config sysresetreq Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x0100 pc: 0x0001e340 msp: 0x2200 1200 kHz flash 'stellaris' found at 0x auto erase enabled wrote 262144 bytes from file ./demo.bin in 42.677986s (5.998 KiB/s) ^C -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/2] ft2232: Failure to get latency should not be fatal
On Tue, Jul 12, 2011 at 7:14 PM, Steve Bennett ste...@workware.net.au wrote: On 12/07/2011, at 9:10 PM, Øyvind Harboe wrote: If this problem eventually goes away, then I think it would make sense not to leave cruft in OpenOCD that we have to remove later? The workaround is available on the mailing list... I don't maintain or know much about ft2232, just a general comment. I have the fix, so I don't mind either way. But I will let you help the next person who complains on the mailing list that it doesn't work :-) Like this. :-) mcuee@ubuntu64:~$ openocd-d2xx -f board/ek-lm3s1968.cfg Open On-Chip Debugger 0.5.0-dev-00950-g898dd3a-dirty (2011-07-11-21:42) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' 500 kHz Error: unable to get latency timer: 4 in procedure 'init' -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/2] ft2232: Fix configure --with-ftd2xx-linux-tardir
On Tue, Jul 12, 2011 at 8:11 PM, Spencer Oliver s...@spen-soft.co.uk wrote: Could not apply your patch so had to do it manually. I have pushed changes to my testing repo: http://repo.or.cz/w/openocd/ntfreak.git No objections i will commit This is good, tested under Ubuntu 10.10 64bit (with the latency patch from Steve). mcuee@ubuntu64:~$ openocd-d2xx -f board/ek-lm3s1968.cfg Open On-Chip Debugger 0.5.0-dev-gb238735-dirty (2011-07-12-21:11) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' 500 kHz Warn : unable to get latency timer: 4 Info : device: 4 2232C Info : deviceID: 67353817 Info : SerialNumber: 070200A1A Info : Description: Stellaris Evaluation Board A Info : clock speed 500 kHz Info : JTAG tap: lm3s1968.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : lm3s1968.cpu: hardware has 6 breakpoints, 4 watchpoints There is no warnings for ft2232.c, but there are some warnings for /usb_blaster.c. ../git/ntfreak/configure --enable-maintainer-mode --disable-werror --enable-jlink --enable-ft2232_ftd2xx --enable-usb_blaster_ftd2xx --enable-parport --enable-dummy --with-ftd2xx-linux-tardir=/home/mcuee/Desktop/build/openocd/d2xx/libftd2xx1.0.4 libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../../../git/ntfreak/src/jtag/drivers -I../../.. -I../../../../git/ntfreak/src -I../../../src -DPKGDATADIR=\/usr/local/share/openocd\ -DPKGLIBDIR=\/usr/local/lib/openocd\ -I../../../../git/ntfreak/jimtcl -I../../../jimtcl -g -O2 -I/home/mcuee/Desktop/build/openocd/d2xx/libftd2xx1.0.4 -Wall -Wstrict-prototypes -Wformat-security -Wshadow -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -MT usb_blaster.lo -MD -MP -MF .deps/usb_blaster.Tpo -c ../../../../git/ntfreak/src/jtag/drivers/usb_blaster.c -o usb_blaster.o ../../../../git/ntfreak/src/jtag/drivers/usb_blaster.c: In function 'usb_blaster_buf_write': ../../../../git/ntfreak/src/jtag/drivers/usb_blaster.c:138: warning: format '%lu' expects type 'long unsigned int', but argument 6 has type 'FT_STATUS' ../../../../git/ntfreak/src/jtag/drivers/usb_blaster.c: In function 'usb_blaster_buf_read': ../../../../git/ntfreak/src/jtag/drivers/usb_blaster.c:171: warning: format '%lu' expects type 'long unsigned int', but argument 6 has type 'FT_STATUS' ../../../../git/ntfreak/src/jtag/drivers/usb_blaster.c: In function 'usb_blaster_init': ../../../../git/ntfreak/src/jtag/drivers/usb_blaster.c:387: warning: format '%lu' expects type 'long unsigned int', but argument 6 has type 'FT_STATUS' ../../../../git/ntfreak/src/jtag/drivers/usb_blaster.c:405: warning: format '%lu' expects type 'long unsigned int', but argument 6 has type 'DWORD' ../../../../git/ntfreak/src/jtag/drivers/usb_blaster.c:424: warning: format '%lu' expects type 'long unsigned int', but argument 6 has type 'FT_STATUS' ../../../../git/ntfreak/src/jtag/drivers/usb_blaster.c:431: warning: format '%lu' expects type 'long unsigned int', but argument 6 has type 'FT_STATUS' ../../../../git/ntfreak/src/jtag/drivers/usb_blaster.c:439: warning: format '%lu' expects type 'long unsigned int', but argument 6 has type 'FT_STATUS' mv -f .deps/usb_blaster.Tpo .deps/usb_blaster.Plo -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/2] ft2232: Fix configure --with-ftd2xx-linux-tardir
On Tue, Jul 12, 2011 at 9:51 PM, Spencer Oliver s...@spen-soft.co.uk wrote: Try my repo now i have pushed a fix for the warnings. Thanks. The warnings are gone now for usb_blaster.c. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/2] ft2232: Failure to get latency should not be fatal
On Tue, Jul 12, 2011 at 7:04 PM, Steve Bennett ste...@workware.net.au wrote:
Although this problem is fixed in the latest libftd2xx1.0.5,
that version is not yet publically available.
Without this fix, the ftd2xx aborts with a fatal error and
is thus unusable.
Signed-off-by: Steve Bennett ste...@workware.net.au
---
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/drivers/ft2232.c
@@ -2260,8 +2260,7 @@ static int ft2232_init_ftd2xx(uint16_t vid, uint16_t
pid, int more, int* try_mor
if ((status = FT_GetLatencyTimer(ftdih, latency_timer)) != FT_OK)
{
- LOG_ERROR(unable to get latency timer: %lu, status);
- return ERROR_JTAG_INIT_FAILED;
+ LOG_WARNING(unable to get latency timer: %lu, status);
BTW, this will produce a warning for 64bit Linux.
src/jtag/drivers/ft2232.c: In function 'ft2232_init_ftd2xx':
src/jtag/drivers/ft2232.c:2263: warning: format '%lu' expects type
'long unsigned int', but argument 6 has type 'FT_STATUS'
mv -f .deps/ft2232.Tpo .deps/ft2232.Plo
}
else
{
--
1.7.5.1
--
Xiaofan
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/2] ft2232: Failure to get latency should not be fatal
On Wed, Jul 13, 2011 at 4:23 AM, Spencer Oliver s...@spen-soft.co.uk wrote: On 12/07/2011 20:56, Peter Stuge wrote: Spencer Oliver wrote: Why are we duplicating effort on two different libraries that accomplish exactly the same thing? Main reason is that ftd2xx works better/faster on windoze. Is it known how much, and why? off the top of my head no - the list archive has quite a few threads on this subject. Xiaofan will probably be able to help here. I have not done benchmark comparison recently. However, Freddie and Laurent have done some benchmarks last time and ftd2xx is significantly faster. https://lists.berlios.de/pipermail/openocd-development/2009-June/008193.html I will try to do some benchmarks over the weekend. I can think of several reasons why using ftd2xx is faster and better for Windows users. I like libftdi and libusb myself. :-) 1) OpenOCD still uses libftdi-0.1x and does not use the async capability of libftdi-1.0. libftdi-1.0 has not been officially released. libusb-1.0 Windows too has not been officially released (1.0.9 release is not yet there). (ft2232.c) 382 #if BUILD_FT2232_FTD2XX == 1 383 #define FT2232_BUFFER_READ_QUEUE_SIZE (64*64) 384 #else 385 #define FT2232_BUFFER_READ_QUEUE_SIZE (64*4) 386 #endif The above codes also favor ftd2xx. 2) To use libftdi, the user has to use libusb-win32 driver. With the release of libusb-win32 1.2.x and the GUI Filter Driver Wizard, this becomes less an issue now but still it is one step for the user. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
