Re: [Openocd-development] [PATCH] Move jim-nvp to openocd
On 29/09/2011, at 4:43 PM, Øyvind Harboe wrote: > On Thu, Sep 29, 2011 at 8:42 AM, Steve Bennett wrote: >> It lives in both openocd and jimtcl, but openocd uses it's own version. > > Because --disable-nvp is used when building OpenOCD? --disable-nvp is the default I have added the local versions in src/helper/Makefile.am > > > -- > Øyvind Harboe - Can Zylin Consulting help on your project? > US toll free 1-866-980-3434 > http://www.zylin.com/ -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Move jim-nvp to openocd
It lives in both openocd and jimtcl, but openocd uses it's own version. On 29/09/2011, at 4:39 PM, Øyvind Harboe wrote: > So what happens in the transitional period? > > -- > Øyvind Harboe - Can Zylin Consulting help on your project? > US toll free 1-866-980-3434 > http://www.zylin.com/ -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Move jim-nvp to openocd
In an upcoming release, I plan to remove jim-nvp from jimtcl. This patch moves it to openocd where it is used. -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 0001-jim-nvp-is-moving-from-jimtcl-to-openocd.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Jim Tcl problems
On 05/09/2011, at 12:22 AM, Øyvind Harboe wrote: > aahhh I think perhaps the problem is that jimtcl fails w/make -j4? > > Have you tried building openocd & jimtcl w/-j4? Works for me. Still seems to me like you have something left lying around since the macros vs function change of Jim_Eval_Named() -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Jim Tcl problems
On 03/09/2011, at 12:58 AM, Øyvind Harboe wrote: >> Jim_Eval_Named is a macro. I don't know why it's not substituted when >> preprocessing. Maybe make clean will help you. Maybe you need to >> remove the ccache cache and try again. > > I've tried what I can think of: > > rm -rf ~/.ccache > git clean -f -x -d > ./bootstrap > ./configure --enable-dummy --enable-maintainer-mode It's definitely just a "clean" issue. Do you need to do the git clean in the jimtcl dir? > > > -- > Øyvind Harboe - Can Zylin Consulting help on your project? > US toll free 1-866-980-3434 > http://www.zylin.com/ > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On 16/08/2011, at 8:32 PM, Spencer Oliver wrote: > On 16 August 2011 11:13, Spencer Oliver wrote: >> On 16 August 2011 11:03, Steve Bennett wrote: >>> On 12/08/2011, at 11:12 PM, Xiaofan Chen wrote: >>> >>>> On Wed, Aug 10, 2011 at 3:39 PM, Xiaofan Chen wrote: >>>>> On Wed, Aug 10, 2011 at 3:34 PM, Olivier Schonken >>>>> 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! >>>>> >>>> >>> >>> 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 >>> >>> Cheers, >>> Steve >>> >> >> yah - i will update the openocd jim version >> > > just updated to latest jim master 645ed6fd4b6f9038c7e1d85d74c3872b3cb9a507 > get a jimtcl build error now on cygwin and linux - msys is working fine. > > cc -g -O2 -rdynamic -o jimsh jimsh.o _initjimsh.o libjim.a -ldl > _initjimsh.o: In function `Jim_initjimshInit': > /home/soliver/openocd/openocd-rel/jimtcl/_initjimsh.c:6: undefined > reference to `Jim_Eval_Named' > collect2: ld returned 1 exit status > make[2]: *** [jimsh] Error 1 Is this with a clean tree? Jim_Eval_Named() is now a macro rather than a function in jim.h Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ 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 12/08/2011, at 11:12 PM, Xiaofan Chen wrote: > On Wed, Aug 10, 2011 at 3:39 PM, Xiaofan Chen wrote: >> On Wed, Aug 10, 2011 at 3:34 PM, Olivier Schonken >> 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! >> > 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 Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ 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 14/08/2011, at 7:11 PM, Spencer Oliver wrote: > On Aug 14, 2011 10:01 AM, "Xiaofan Chen" wrote: > > > > On Sat, Aug 13, 2011 at 9:38 AM, Jie Zhang wrote: > > > On Fri, Aug 12, 2011 at 9:27 PM, Xiaofan Chen wrote: > > >> 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=sourcenames&keywords=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, it seems you are out of luck. The Debian MinGW32 > > maintainer seemed to think there is a licensing issue somewhere > > and refused to update. You may have to build your own > > 3.17 version as in the following thread. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498529 > > > > Ubuntu has it updated since 9.10 but still stuck with the > > same old MinGW gcc. Luckily the gcc version is not an > > issue. I am running 10.04 and 11.04 and have no problems > > with cross-build OpenOCD. > > http://changelogs.ubuntu.com/changelogs/pool/universe/m/mingw32-runtime/mingw32-runtime_3.15.2-0ubuntu1/changelog > > http://changelogs.ubuntu.com/changelogs/pool/universe/m/mingw32/ > > > > > > Openocd checks for usleep and already has a replacement if not found. See > replacements.h > > I pushed a change to jimtcl git which will use Sleep() if usleep() is unavailable on mingw32. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ 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 13/08/2011, at 6:41 AM, Jie Zhang wrote:
> The current HEAD cannot build with mingw32
>
> libtool: link: i586-mingw32msvc-gcc -std=gnu99 -g -O2
> -I/home/jie/installs/openocd/include -D__USE_MINGW_ANSI_STDIO -Wall
> -Wstrict-prototypes -Wformat-security -Wshadow -Wextra
> -Wno-unused-parameter -Wbad-function-cast -Wcast-align
> -Wredundant-decls -Werror -o openocd.exe main.o
> -L/home/jie/installs/openocd/lib ./.libs/libopenocd.a -lws2_32
> ../jimtcl/libjim.a
> ./.libs/libopenocd.a(libhelper_la-command.o): In function
> `process_jim_events':
> /home/jie/sources/openocd/src/helper/command.c:1398: undefined
> reference to `_Jim_ProcessEvents'
> collect2: ld returned 1 exit status
> make[4]: *** [openocd.exe] Error 1
> make[4]: Leaving directory `/home/jie/sources/openocd/src'
>
> Jim_ProcessEvents is defined in jimtcl/jim-eventloop.c.
>
> set needs(eventloop) {expr {[have-feature select] || [have-feature usleep]}}
>
> but
>
> Checking for select...not found
> Checking for usleep...not found
Can you send me jimtcl/config.log
This is on Linux, right?
--
µWeb: Embedded Web Framework - http://uweb.workware.net.au/
WorkWare Systems Pty Ltd
W: www.workware.net.au P: +61 434 921 300
E: ste...@workware.net.au F: +61 7 3391 6002
___
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 11/08/2011, at 8:17 PM, Xiaofan Chen wrote: > On Thu, Aug 11, 2011 at 5:16 PM, Xiaofan Chen wrote: >> On Thu, Aug 11, 2011 at 5:11 PM, Vit Mares 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 Yes. We are still working on the problem. It's taking a while because I can't reproduce it here. As a workaround you could try specifying --host=i686-pc-mingw32 --build=i686-pc-mingw32 Or alternatively try deleting jimtcl/autosetup/config.guess and jimtcl/autosetup/config.sub Hopefully we will have a fix soon. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Replace "script" with "source"
On 11/08/2011, at 11:39 AM, Jie Zhang wrote: > On Wed, Aug 10, 2011 at 8:27 PM, Steve Bennett wrote: >> On 09/08/2011, at 11:18 PM, Jie Zhang wrote: >> >>> Hi, >>> >>> Since we are in merge window now, how about merge this patch to >>> replace script with source: >>> >>> https://lists.berlios.de/pipermail/openocd-development/2011-July/020370.html >>> >>> If there is any issue, we still have enough time to revert this change. >> >> I don't see any advantage to removing 'script'. >> I think it is better to have script evaluate in global scope. >> > Then could you make a patch and merge it. I have no strong opinion on > this. Thank you! Please try the attached. If there are no problems we can ask for it to me merged. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 0001-Evaluate-script-in-the-global-scope.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Replace "script" with "source"
On 09/08/2011, at 11:18 PM, Jie Zhang wrote: > Hi, > > Since we are in merge window now, how about merge this patch to > replace script with source: > > https://lists.berlios.de/pipermail/openocd-development/2011-July/020370.html > > If there is any issue, we still have enough time to revert this change. I don't see any advantage to removing 'script'. I think it is better to have script evaluate in global scope. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ 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 10/08/2011, at 6:39 PM, Spencer Oliver wrote: > On 10 August 2011 07:11, Steve Bennett wrote: >> On 10/08/2011, at 3:03 PM, Xiaofan Chen wrote: >> >>> On Wed, Aug 10, 2011 at 11:44 AM, Steve Bennett >>> 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. >> >> Let us know how that goes. >> >>> >>>> 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? >> >> That is *not* true. >> The version of jimtcl in openocd-0.5.0 fully supports building on mingw/msys >> > > 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 -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ 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 10/08/2011, at 6:15 PM, Xiaofan Chen wrote: > On Wed, Aug 10, 2011 at 4:11 PM, Xiaofan Chen wrote: >> On Wed, Aug 10, 2011 at 2:11 PM, Steve Bennett >> 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. > Thanks. That's good enough for me. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ 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 10/08/2011, at 3:03 PM, Xiaofan Chen wrote: > On Wed, Aug 10, 2011 at 11:44 AM, Steve Bennett > 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. Let us know how that goes. > >> 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? That is *not* true. The version of jimtcl in openocd-0.5.0 fully supports building on mingw/msys Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ 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 10/08/2011, at 9:43 AM, Xiaofan Chen wrote: > On Tue, Aug 9, 2011 at 11:11 PM, Spencer Oliver wrote: >> On 9 August 2011 16:01, Xiaofan Chen wrote: >>> On Tue, Aug 9, 2011 at 10:20 PM, Spencer Oliver >>> 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 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 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. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] script vs source
On 29/07/2011, at 8:45 PM, Jie Zhang wrote:
> Hi,
>
> OpenOCD uses script command to execute config file passed through "-f"
> option. script command is defined as a function
>
> proc script {filename} {
>source [find $filename]
> }
>
> Thus when executing the config file, global variables defined in that
> config file is not global any more. If I define a global variable
>
> set foo 1
>
> in target config file, then trying to read its value by
>
> obj = Jim_GetGlobalVariableStr (interp, "foo", 0);
> Jim_GetLong(interp, obj, &foo);
>
> in OpenOCD will fail because "foo" is not defined in global namespace.
> And the following code in a target config file will not work as
> expected:
>
> set foo 1
> proc test { } {
>puts $::foo
> }
> test
>
> It's counterintuitive.
>
> Is this effect is by design or by accident? I can see that using
> "script" command can avoid name conflicts between config files. But it
> prevents config files from sharing global variables. It also prevents
> OpenOCD from accessing global variables defined in config files by
> Jim_GetGlobalVariableStr.
>
> Regards,
> Jie
Makes sense to me to change it to:
proc script {filename} {
uplevel #0 source [find $filename]
}
>
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] script command
On 29/07/2011, at 2:06 PM, Steve Bennett wrote: > On 29/07/2011, at 1:40 PM, Jie Zhang wrote: > >> Hi, >> >> Where is the "script" command defined? I greped in jimtcl and openocd >> source code, but could not find it. Thank you! >> >> Jie > > src/helper/startup.tcl line 57 And here's a trick for you. If you want to know when any Tcl procedure is defined, you can run a command like: info source [info body script] This will show where the proc 'script' is defined. Won't work for built-in commands, since there is no corresponding source location. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] script command
On 29/07/2011, at 1:40 PM, Jie Zhang wrote: > Hi, > > Where is the "script" command defined? I greped in jimtcl and openocd > source code, but could not find it. Thank you! > > Jie src/helper/startup.tcl line 57 > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 4/4] flash: add support for deprecated stm32 flash cmds
On 28/07/2011, at 9:52 PM, Spencer Oliver wrote:
> From: Spencer Oliver
>
> Issue warning when the old cmd is used and redirect to new supported one.
> These deprecated cmds will be removed at some point.
>
> Signed-off-by: Spencer Oliver
> ---
> src/flash/startup.tcl | 11 +++
> 1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/src/flash/startup.tcl b/src/flash/startup.tcl
> index 6cb7d8e..5f40e64 100644
> --- a/src/flash/startup.tcl
> +++ b/src/flash/startup.tcl
> @@ -1,2 +1,13 @@
> # Defines basic Tcl procs for OpenOCD flash module
>
> +# ease migration to updated flash driver
> +proc stm32x args {
> + echo "DEPRECATED! use 'stm32f1x $args' not 'stm32x $args'"
> + eval stm32f1x $args
> +}
> +
> +proc stm32f2xxx args {
> + echo "DEPRECATED! use 'stm32f2x $args' not 'stm32f2xxx $args'"
> + eval stm32f2x $args
> +}
I don't know what parameters may be passed to these procs, but if they could
contain
spaces, quotes or braces this could cause unexpected behaviour.
You might consider using the more correct form:
proc stm32f2xxx args {
echo "DEPRECATED! use 'stm32f2x $args' not 'stm32f2xxx $args'"
tailcall stm32f2x {*}$args
}
Cheers,
Steve
--
µWeb: Embedded Web Framework - http://uweb.workware.net.au/
WorkWare Systems Pty Ltd
W: www.workware.net.au P: +61 434 921 300
E: ste...@workware.net.au F: +61 7 3391 6002
___
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 27/07/2011, at 1:17 AM, Spencer Oliver wrote: > On 12 July 2011 15:01, Xiaofan Chen wrote: >> On Tue, Jul 12, 2011 at 9:51 PM, Spencer Oliver wrote: >>> Try my repo now i have pushed a fix for the warnings. >>> >> > > I have just attempted to build under cygwin and get warnings. > Seems this patch has broken windows - i am inclined to revert as > windows is more likely to use ftd2xx than linux. > > Looking into the issue i agree with Xiaofan the issue is caused by a > change to the wintypes.h > > old version (0.4.16) > typedef unsigned long DWORD; > typedef unsigned long ULONG; > > new version (1.04) > typedef unsigned int DWORD; > typedef unsigned int ULONG; > > for info long is 8bytes under linux64 - but win64 treats it as 4bytes. > I may get more time to look into next week. I believe that my original patch did not have this problem (see attached), but I was asked to change it to use PRIu32. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 0001-ft2232-Add-casts-to-avoid-warnings.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Building local bootstrap jimsh0 failed
On 15/07/2011, at 5:30 AM, Jie Zhang wrote: > On Thu, Jul 14, 2011 at 12:07 PM, Jie Zhang wrote: >> On Thu, Jul 14, 2011 at 6:17 AM, Steve Bennett >> wrote: >>> On 14/07/2011, at 7:19 PM, Spencer Oliver wrote: >>>> This is why i mentioned before about adding a configure option to >>>> jimtcl, something like --noinstall >>> >>> It seems weird to have a configure option which causes 'make install' >>> to not install. Seems like it will just confuse other users of jimtcl. >>> >> Maybe with a clear help documentation and a good default setting, it >> will not be so confusing. I think we can have >> --disable-install-jimtcl, default off, i.e, --enable-install-jimtcl, >> for jimtcl. Then turn it on in OpenOCD. The help documentation could >> be >> >> --disable-install-jimtcl controls installation of jimctl and related >> headers. >>usually used when jimctl is embeded in >> another program. >> >> I'm also wondering if it's a good idea to make jimtcl use automake, >> which should make implementing this easier. >> > Jim uses autosetup instead of autoconf. So it does not make much sense > to use automake. > > Anyway I think Spencer's idea about adding a configure option to > disable Jim installation is good. So I implemented it. I change the > option name to "--disable-install-jim" to save 3 characters. > > Three patches are attached: > > jim-configure-disable-install.diff is for upstream Jim > openocd-jim-configure-disable-install.diff is for Jim in OpenOCD > openocd-dont-install-jimtcl.diff makes OpenOCD to use the new added > configure option. If there is no way to make automake do this then I guess we have no choice. I have pushed something similar to git. Cheers, Steve > > Regards, > Jie > -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Building local bootstrap jimsh0 failed
On 14/07/2011, at 7:19 PM, Spencer Oliver wrote: > On 13 July 2011 22:53, Steve Bennett wrote: >> >> Hi Eric, >> >> Thanks for the report. >> This is caused by a couple of things. >> >> Firstly, the version of jimtcl used by openocd isn't fully functional >> when built under mingw. It's fine for openocd, but things like backslashes >> in paths and exec aren't handled properly. So the built jimsh isn't suitable >> for configure/autosetup. (Not that the latest version of jimtcl adds better >> support for mingw, but that version is not yet used by openocd) >> >> But, that wouldn't be a problem except for... >> >> Secondly, when openocd installs it also installs jimtcl. It really shouldn't. >> It uses jimtcl internally and doesn't need anything installed. >> > > I have looked into this and there is no easy way when using automake, Really? Then maybe we have the wrong approach of treating jimtcl as a subproject. Maybe it should be simply be a subdirectory where configure and make are run and the directory simply added to the search path for headers and libraries. > this is what libtool is for. I don't know how libtool relates to this. > This is why i mentioned before about adding a configure option to > jimtcl, something like --noinstall It seems weird to have a configure option which causes 'make install' to not install. Seems like it will just confuse other users of jimtcl. > > The only other solution is to override the jimtcl make using > GNUmakefile, but that is assuming everybody uses GNU make. > > Cheers > Spen > -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Building local bootstrap jimsh0 failed
On 14/07/2011, at 5:39 AM, Eric Wetzel wrote: > On Thu, Jul 7, 2011 at 8:07 AM, Eric Wetzel wrote: >> On Thu, Jul 7, 2011 at 6:40 AM, Spencer Oliver wrote: >>> On 7 July 2011 11:09, Steve Bennett wrote: >>>> >>>> ../../jimtcl/autosetup/find-tclsh: line 10: cc: command not found >>>> >>>> But no cc? >>>> >>>> If cygwin is installed, why no cc? >>> >>> That one confused me aswell, perhaps the cygwin tools need reinstalling. >>> >>> The cygwin-mingw cross compiler is relatively new and does have some >>> install issues: >>> http://www.cygwin.com/ml/cygwin-announce/2011-06/msg4.html >>> >>> Cheers >>> Spen >> >> That would do it. I didn't have Cygwin's gcc installed, only the mingw one. >> >> It built fine last week, with git ff640f1, but I guess the latest bump >> of JimTCL changed the way it builds. >> >> Thanks, >> ~Eric >> > > I have a new, but similar, issue with Jim now. After the last build > succeeded, I added OpenOCD's install directory to my Cygwin path, > which includes a mingw32-targetted Jim binary. Now, attempting to > rebuild OpenOCD from git results in this during the configure phase: > === configuring in jimtcl > (/home/ericwetz/local/src/openocd.git/build-win32/jimtcl) > configure: running /bin/sh ../../jimtcl/configure.gnu > --disable-option-checking '--prefix=/home/ericwetz/local' > '--enable-maintainer-mode' '--build=i686-pc-cygwin' > '--host=i686-pc-mingw32' '--enable-dummy' '--enable-jlink' > '--enable-ft2232_ftd2xx' > '--with-ftd2xx-win32-zipdir=/home/ericwetz/local/src/ftd2xx' > 'build_alias=i686-pc-cygwin' 'host_alias=i686-pc-mingw32' > --cache-file=/dev/null --srcdir=../../jimtcl > cygwin warning: > MS-DOS style path detected: > /home/ericwetz/local/bin/C:\cygwin\home\ericwetz\local\src\openocd.git\build-win32\jimtcl\x0D > Preferred POSIX equivalent is: > /home/ericwetz/local/bin/C:/cygwin/home/ericwetz/local/src/openocd.git/build-win32/jimtcl\x0D > CYGWIN environment variable option "nodosfilewarning" turns off this warning. > Consult the user's guide for more details about POSIX paths: >http://cygwin.com/cygwin-ug-net/using.html#using-pathnames > ../../jimtcl/configure: line 3: exec: > C:\cygwin\home\ericwetz\local\src\openocd.: not foundin32\jimtcl > configure: error: ../../jimtcl/configure.gnu failed for jimtcl > > Running the installed jimsh on jimtcl/autosetup/test-tclsh returns the > Windows path: > C:\cygwin\home\ericwetz\local\src\openocd.git\jimtcl > > It should be noted that running jimsh on an absolute Cygwin path > fails, complaining "No such file or directory", but that seems to be > typical of all native Windows applications. > > Removing jimsh from my path fixes this, as a new jimsh0 must be > bootstrapped (solved in this last post in this e-mail). > > I don't know what could be done to fix this; I'm not even sure it > deserves fixing. I acknowledge that the environments I'm trying to > build from and for are a little bit convoluted, but this is what I > have to work with. I don't have a Linux machine at work, and MinGW > always makes me kindof uncomfortable. Hi Eric, Thanks for the report. This is caused by a couple of things. Firstly, the version of jimtcl used by openocd isn't fully functional when built under mingw. It's fine for openocd, but things like backslashes in paths and exec aren't handled properly. So the built jimsh isn't suitable for configure/autosetup. (Not that the latest version of jimtcl adds better support for mingw, but that version is not yet used by openocd) But, that wouldn't be a problem except for... Secondly, when openocd installs it also installs jimtcl. It really shouldn't. It uses jimtcl internally and doesn't need anything installed. At some point openocd will use a newer version of jimtcl, so this will solve the first point. But I would also like to see openocd *not* install jimtcl. This needs to be done with some automake-foo in openocd. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD 0.5.0-rc2 release
On 13/07/2011, at 11:32 AM, Andrew Leech wrote: > On 11 July 2011 07:31, Jean-Christophe PLAGNIOL-VILLARD > wrote: rc2 http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=snapshot;h=d4cd6f032015552f00bf4b5a90f25f5f958e9d9e;sf=tgz > I'm assuming some testing would be good :-) I'm just moving into a firmware > project again, so a good opportunity, recompiling from this tgz now. I'm been > compiling from git occasionally for a long time now, it's been a while since > starting from a fresh release. using Windows 7 x64, cygwin compiling. > > Couple of comments: > Firstly, the docs in the tarball could do with some updating, sorry I don't > have time to do it just now. > > README.Win32 mentions "The Cygwin/Win32 ZIP file contains a directory named > ftd2xx.win32". This doesn't exist, will it be included in a proper release > tarball, or are these referring to the ftdi files that can't be distributed > legally? > > Similarly the ./bootstrap command is only mentioned at the end of README, > while I'm guessing that this wont be needed in a release tarball, if anyone > who does need it tried to follow the readme linearly they'll run into > problems before finally finding this down the bottom, I feel it should > probably be mentioned earlier up. > > Again just a release tarball issue, but the tarball from above doesn't work > properly, it needs bootstrap run to get jimtcl etc, but I get: > $ ./bootstrap > + aclocal > + libtoolize --automake --copy > + autoconf > + autoheader > + automake --gnu --add-missing --copy > configure.in:20: installing `./compile' > configure.in:28: installing `./config.guess' > configure.in:28: installing `./config.sub' > configure.in:8: installing `./install-sh' > configure.in:8: installing `./missing' > doc/Makefile.am:1: installing `doc/mdate-sh' > doc/Makefile.am:1: installing `doc/texinfo.tex' > src/Makefile.am: installing `./depcomp' > Makefile.am: installing `./INSTALL' > Setting up submodules > fatal: Not a git repository (or any parent up to mount parent /cygdrive) > Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). > > It expects the openocd dir to be a git repository, but this tarball isn't. > Nasty workaround I copied .git from my existing openocd source folder > into the tarball folder and that got me jimtcl and the rest of the way > through bootstrap. > > I think README.Win32 should be updated regarding gcc options, mentioning that > using default gcc will result in cygwin dependency, or alternately install > cygwin packages for mingw and then specify the full mingw gcc name as per > below or CC="gcc-3 -mno-cygwin" (which I haven't tested recently): > Using: $ ./configure --enable-maintainer-mode --enable-ft2232_ftd2xx > --with-ftd2xx-win32-zipdir=../ftdi CC="i686-pc-mingw32-gcc" > > I also had problems with jimtcl and dos line ends, the configure scripts and > autosetup files didn't work, spitting some nasty errors because of dos line > ends... this took me a while to debug. Could bootstrap have it's git commands > for pulling jimtcl changed to ensure it doesn't save in dos mode? > Once I did a $ fromdos jimtcl/* and $ fromdos jimtcl/autosetup* configure > passed just fine. > > make completed with no issues. > Debugging a lpc3131 (ARM926EJ-S) with a ft2232 jtagkey compatible dongle then > works fine! > > Cheers, > Andrew You are building with the wrong tarball. A release tarball is named something like openocd-0.5.0-dev.tar.gz and is built from the git repository with 'make dist' You should unpack this release tarball somewhere and just run ./configure You shouldn't be running bootstrap. In fact it doesn't exist in a proper release tarball. Cheers, Steve PS It's so easy to make one of these, I'm not sure why there is reluctance to do so. -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ 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 13/07/2011, at 6:23 AM, Spencer Oliver 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. From memory, I went with ftd2xx rather than ftdi because ftdi wanted to use the old /proc/bus/usb which isn't available on ubuntu. ftd2xx didn't have this problem. Although perhaps that's because I was using the ubuntu version of ftdi... -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ 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 12/07/2011, at 10:18 PM, Spencer Oliver wrote: > On 12 July 2011 13:08, Xiaofan Chen wrote: >> On Tue, Jul 12, 2011 at 7:14 PM, Steve Bennett >> 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' >> >> >> > > I think we do need this patch - or something similar. > > can we have a comment in the code, perhaps a todo then it will show up > in our nice eclipse editor. Sure. Just say exactly how the comment needs to be formatted. > Or even better check the driver version. No idea how to do this. > > Cheers > Spen > ___ 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 12/07/2011, at 9:11 PM, Spencer Oliver wrote: > On 12 July 2011 12:04, Steve Bennett wrote: >> For libftd2xx1.0.4, which uses a different directory structure >> than libftd2xx0.4.16 >> Without this fix the build fails with version 1.0.4 of the driver. >> >> Note that this does not fix --with-ftd2xx-lib=shared >> >> Signed-off-by: Steve Bennett >> --- > > That gets 64bit host through configure ok :) Great. The patch only promised to find the library, not fix the build. I already sent two different patches to fix the build problem and neither was accepted... > > I get a lot of warnings with the new lib however > ../../../../openocd/src/jtag/drivers/ft2232.c: In function ‘ft2232_write’: > ../../../../openocd/src/jtag/drivers/ft2232.c:518: error: format ‘%lu’ > expects type ‘long unsigned int’, but argument 6 has type ‘FT_STATUS’ > ../../../../openocd/src/jtag/drivers/ft2232.c: In function ‘ft2232_read’: > ../../../../openocd/src/jtag/drivers/ft2232.c:561: error: format ‘%lu’ > expects type ‘long unsigned int’, but argument 6 has type ‘FT_STATUS’ > ../../../../openocd/src/jtag/drivers/ft2232.c: In function > ‘ft2232_init_ftd2xx’: > ../../../../openocd/src/jtag/drivers/ft2232.c:2218: error: format > ‘%lu’ expects type ‘long unsigned int’, but argument 6 has type > ‘FT_STATUS’ > ../../../../openocd/src/jtag/drivers/ft2232.c:: error: format > ‘%lu’ expects type ‘long unsigned int’, but argument 6 has type > ‘FT_STATUS’ > ../../../../openocd/src/jtag/drivers/ft2232.c:2238: error: format > ‘%lu’ expects type ‘long unsigned int’, but argument 6 has type > ‘DWORD’ > ../../../../openocd/src/jtag/drivers/ft2232.c:2257: error: format > ‘%lu’ expects type ‘long unsigned int’, but argument 6 has type > ‘FT_STATUS’ > ../../../../openocd/src/jtag/drivers/ft2232.c:2263: error: format > ‘%lu’ expects type ‘long unsigned int’, but argument 6 has type > ‘FT_STATUS’ > ../../../../openocd/src/jtag/drivers/ft2232.c:2273: error: format > ‘%lu’ expects type ‘long unsigned int’, but argument 6 has type > ‘FT_STATUS’ > ../../../../openocd/src/jtag/drivers/ft2232.c:2279: error: format > ‘%lu’ expects type ‘long unsigned int’, but argument 6 has type > ‘FT_STATUS’ > ../../../../openocd/src/jtag/drivers/ft2232.c:2285: error: format > ‘%lu’ expects type ‘long unsigned int’, but argument 6 has type > ‘FT_STATUS’ > ../../../../openocd/src/jtag/drivers/ft2232.c:2295: error: format > ‘%lu’ expects type ‘long unsigned int’, but argument 6 has type > ‘FT_DEVICE’ > ../../../../openocd/src/jtag/drivers/ft2232.c:2296: error: format > ‘%lu’ expects type ‘long unsigned int’, but argument 6 has type > ‘DWORD’ > ../../../../openocd/src/jtag/drivers/ft2232.c: In function > ‘ft2232_purge_ftd2xx’: > ../../../../openocd/src/jtag/drivers/ft2232.c:2310: error: format > ‘%lu’ expects type ‘long unsigned int’, but argument 6 has type > ‘FT_STATUS’ > ../../../../openocd/src/jtag/drivers/ft2232.c: In function > ‘signalyzer_h_led_set’: > ../../../../openocd/src/jtag/drivers/ft2232.c:3631: error: format > ‘%lu’ expects type ‘long unsigned int’, but argument 6 has type > ‘FT_STATUS’ > ../../../../openocd/src/jtag/drivers/ft2232.c:3639: error: format > ‘%lu’ expects type ‘long unsigned int’, but argument 6 has type > ‘FT_STATUS’ > ../../../../openocd/src/jtag/drivers/ft2232.c:3647: error: format > ‘%lu’ expects type ‘long unsigned int’, but argument 6 has type > ‘FT_STATUS’ > ../../../../openocd/src/jtag/drivers/ft2232.c:3654: error: format > ‘%lu’ expects type ‘long unsigned int’, but argument 6 has type > ‘FT_STATUS’ > ../../../../openocd/src/jtag/drivers/ft2232.c: In function > ‘signalyzer_h_init’: > ../../../../openocd/src/jtag/drivers/ft2232.c:3743: error: format > ‘%lu’ expects type ‘long unsigned int’, but argument 6 has type > ‘FT_STATUS’ > ../../../../openocd/src/jtag/drivers/ft2232.c:3753: error: format > ‘%lu’ expects type ‘long unsigned int’, but argument 6 has type > ‘FT_STATUS’ > ../../../../openocd/src/jtag/drivers/ft2232.c:3767: error: format > ‘%lu’ expects type ‘long unsigned int’, but argument 6 has type > ‘FT_STATUS’ > ../../../../openocd/src/jtag/drivers/ft2232.c:3774: error: format > ‘%lu’ expects type ‘long unsigned int’, but argument 6 has type > ‘FT_STATUS’ > ../../../../openocd/src/jtag/drivers/ft2232.c:3781: error: format > ‘%lu’ expects type ‘long unsigned int’, but argument 6 has type > ‘FT_STATUS’ > ../../../../openocd/src/jtag/drivers/ft2232.c:3789: error: format > ‘%lu’ expects type ‘long unsigned int’, but argument 6 has type > ‘FT_STATUS’ > ../../../../openocd/src/jtag/drivers/ft2232.c:3796: error: format > ‘%lu’ expects type ‘long unsigned int’, but argument 6 has type > ‘FT_STATUS’ > ../../../../openocd/src/jt
Re: [Openocd-development] [PATCH 2/2] ft2232: Failure to get latency should not be fatal
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 :-) -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/3] ft2232: Fix configure --with-ftd2xx-linux-tardir
On 12/07/2011, at 9:04 PM, Spencer Oliver wrote: > On 12 July 2011 10:59, Øyvind Harboe wrote: >>> Great. >>> >>> Øyvind. What needs to be done to get this merged? >> >> I don't know this code. Is this a patch that should go into the current >> release? We're at rc2. >> >> Perhaps post a new message with the patch and why it should >> be included in the current release? >> >> Spencer knows more about this code, perhaps he'll bite? >> >> -- > > Only have a 64bit machine here. > Can we just not add 64bit support, only a matter of checking for host > - we already do this for --with-ftd2xx-win32-zipdir Please test the sent patch [1/2] and apply if it works on 64bit. -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 2/2] ft2232: Failure to get latency should not be fatal
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
---
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);
}
else
{
--
1.7.5.1
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 1/2] ft2232: Fix configure --with-ftd2xx-linux-tardir
For libftd2xx1.0.4, which uses a different directory structure
than libftd2xx0.4.16
Without this fix the build fails with version 1.0.4 of the driver.
Note that this does not fix --with-ftd2xx-lib=shared
Signed-off-by: Steve Bennett
---
configure.in | 25 +
1 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/configure.in b/configure.in
index de74ffa..8c77a25 100644
--- a/configure.in
+++ b/configure.in
@@ -873,14 +873,23 @@ if test $build_ft2232_ftd2xx = yes -o
$build_presto_ftd2xx = yes ; then
AC_MSG_ERROR([Option: --with-ftd2xx-linux-tardir appears wrong, cannot
find: ${FTD2XX_H}])
fi
CFLAGS="$CFLAGS -I$with_ftd2xx_linux_tardir"
-FTD2XX_LDFLAGS="-L$with_ftd2xx_linux_tardir"
-FTD2XX_LIB="-lftd2xx"
-if test $with_ftd2xx_lib != shared; then
- # Test #1 - Future proof - if/when ftdichip fixes their distro.
- # Try it with the simple ".a" suffix.
- FTD2XX_LIB="$with_ftd2xx_linux_tardir/static_lib/libftd2xx.a"
- if test -f "${FTD2XX_LIB}"; then
-FTD2XX_LDFLAGS="${FTD2XX_LDFLAGS}/static_lib"
+if test $with_ftd2xx_lib = shared; then
+ FTD2XX_LDFLAGS="-L$with_ftd2xx_linux_tardir"
+ FTD2XX_LIB="-lftd2xx"
+else
+ # Test #1 - v1.0.x
+ case "$host_cpu" in
+ i?86|x86_32)
+ dir=build/i386;;
+ amd64|x86_64)
+ dir=build/x86_64;;
+ *)
+ dir=none;;
+ esac
+ if test -f "$with_ftd2xx_linux_tardir/$dir/libftd2xx.a"; then
+ FTD2XX_LDFLAGS="-L$with_ftd2xx_linux_tardir/$dir"
+ # Also needs -lrt
+ FTD2XX_LIB="-lftd2xx -lrt"
else
# Test Number2.
# Grr.. perhaps it exists as a version number?
--
1.7.5.1
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/3] ft2232: Fix configure --with-ftd2xx-linux-tardir
On 11/07/2011, at 11:52 PM, Xiaofan Chen wrote:
> On Mon, Jul 11, 2011 at 8:14 PM, Steve Bennett wrote:
>> On 11/07/2011, at 10:03 PM, Xiaofan Chen wrote:
>>
>>> On Tue, Jun 28, 2011 at 1:48 PM, Xiaofan Chen wrote:
>>>> On Sun, Jun 26, 2011 at 10:14 PM, Øyvind Harboe
>>>> wrote:
>>>>> Can someone review this?
>>>>>
>>>>
>>>> Maybe it is good to fix for 64bit as well, similar to the case of
>>>> --with-ftd2xx-win32-zipdir where $host_cpu is checked to decide
>>>> which library to use (build/i386/libftd2xx.a or build/amd64/libftd2xx.a)
>>>>
>>>
>>> The patch works with the x86 build at least. And it does not
>>> make things worse for the old version of ftd2xx. So I think
>>> this should be committed.
>>
>> Hear, hear!
>>
>> And if someone has the appropriate environment to test and submit a fix for
>> 64bit,
>> that would be a useful later addition.
>>
>
> Following your x86 patch, at least the following patch is okay for x64 build
> (only tested the compiling under Ubuntu 10.10 64bit).
>
> Maybe you want to to detect the 32bit build and 64bit build under
> Linux and combine the patches into one.
Great.
Øyvind. What needs to be done to get this merged?
>
> diff --git a/configure.in b/configure.in
> index de74ffa..fd8eb11 100644
> --- a/configure.in
> +++ b/configure.in
> @@ -873,14 +873,15 @@ if test $build_ft2232_ftd2xx = yes -o
> $build_presto_ftd2xx
> AC_MSG_ERROR([Option: --with-ftd2xx-linux-tardir appears wrong, cannot
> find
> fi
> CFLAGS="$CFLAGS -I$with_ftd2xx_linux_tardir"
> -FTD2XX_LDFLAGS="-L$with_ftd2xx_linux_tardir"
> -FTD2XX_LIB="-lftd2xx"
> -if test $with_ftd2xx_lib != shared; then
> - # Test #1 - Future proof - if/when ftdichip fixes their distro.
> - # Try it with the simple ".a" suffix.
> - FTD2XX_LIB="$with_ftd2xx_linux_tardir/static_lib/libftd2xx.a"
> - if test -f "${FTD2XX_LIB}"; then
> -FTD2XX_LDFLAGS="${FTD2XX_LDFLAGS}/static_lib"
> +if test $with_ftd2xx_lib = shared; then
> + FTD2XX_LDFLAGS="-L$with_ftd2xx_linux_tardir"
> + FTD2XX_LIB="-lftd2xx"
> +else
> + # Test #1 - v1.0.x
> + if test -f "$with_ftd2xx_linux_tardir/build/x86_64/libftd2xx.a"; then
> +FTD2XX_LDFLAGS="-L$with_ftd2xx_linux_tardir/build/x86_64"
> +# Also needs -lrt
> +FTD2XX_LIB="-lftd2xx -lrt"
> else
> # Test Number2.
> # Grr.. perhaps it exists as a version number?
>
> There are warnings like the following though.
>
> libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I.
> -I../../../../git/openocd/src/jtag/drivers -I../../..
> -I../../../../git/openocd/src -I../../../src
> -DPKGDATADIR=\"/usr/local/share/openocd\"
> -DPKGLIBDIR=\"/usr/local/lib/openocd\"
> -I../../../../git/openocd/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 ft2232.lo -MD -MP -MF .deps/ft2232.Tpo -c
> ../../../../git/openocd/src/jtag/drivers/ft2232.c -o ft2232.o
> ../../../../git/openocd/src/jtag/drivers/ft2232.c: In function 'ft2232_write':
> ../../../../git/openocd/src/jtag/drivers/ft2232.c:518: warning: format
> '%lu' expects type 'long unsigned int', but argument 6 has type
> 'FT_STATUS'
> ../../../../git/openocd/src/jtag/drivers/ft2232.c: In function 'ft2232_read':
> ../../../../git/openocd/src/jtag/drivers/ft2232.c:561: warning: format
> '%lu' expects type 'long unsigned int', but argument 6 has type
> 'FT_STATUS'
> ../../../../git/openocd/src/jtag/drivers/ft2232.c: In function
> 'ft2232_init_ftd2xx':
> ../../../../git/openocd/src/jtag/drivers/ft2232.c:2218: warning:
> format '%lu' expects type 'long unsigned int', but argument 6 has type
> 'FT_STATUS'
> ../../../../git/openocd/src/jtag/drivers/ft2232.c:: warning:
> format '%lu' expects type 'long unsigned int', but argument 6 has type
> 'FT_STATUS'
> ../../../../git/openocd/src/jtag/drivers/ft2232.c:2238: warning:
> format '%lu' expects type 'long unsigned int', but argument 6 has type
> 'DWORD'
> ../../../../git/openocd/src/jtag/drivers/ft2232.c:2257: warning:
> format '%lu' expects type 'long un
Re: [Openocd-development] [PATCH 1/3] ft2232: Fix configure --with-ftd2xx-linux-tardir
On 11/07/2011, at 10:03 PM, Xiaofan Chen wrote: > On Tue, Jun 28, 2011 at 1:48 PM, Xiaofan Chen wrote: >> On Sun, Jun 26, 2011 at 10:14 PM, Øyvind Harboe >> wrote: >>> Can someone review this? >>> >> >> Maybe it is good to fix for 64bit as well, similar to the case of >> --with-ftd2xx-win32-zipdir where $host_cpu is checked to decide >> which library to use (build/i386/libftd2xx.a or build/amd64/libftd2xx.a) >> > > The patch works with the x86 build at least. And it does not > make things worse for the old version of ftd2xx. So I think > this should be committed. Hear, hear! And if someone has the appropriate environment to test and submit a fix for 64bit, that would be a useful later addition. -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Building local bootstrap jimsh0 failed
On 07/07/2011, at 7:44 PM, Spencer Oliver wrote:
> On 7 July 2011 00:56, Steve Bennett wrote:
>> On 07/07/2011, at 2:13 AM, Eric Wetzel wrote:
>>
>>> I pulled from origin and now my process is failing during configure.
>>> On ac43d7a69fca52df1ad287b51c44013653ad2f61, comping under Cygwin with
>>> MinGW compiler, I get this:
>>>
>>> === configuring in jimtcl
>>> (/home/ericwetz/local/src/openocd.git/build/jimtcl)
>>> configure: running /bin/sh ../../jimtcl/configure.gnu
>>> --disable-option-checking '--prefix=/home/ericwetz/local'
>>> '--enable-maintainer-mode' '--build=i686-pc-cygwin'
>>> '--host=i686-pc-mingw32' '--enable-dummy' '--enable-jlink'
>>> '--enable-ft2232_ftd2xx'
>>> '--with-ftd2xx-win32-zipdir=/home/ericwetz/local/src/ftd2xx'
>>> 'build_alias=i686-pc-cygwin' 'host_alias=i686-pc-mingw32'
>>> --cache-file=/dev/null --srcdir=../../jimtcl
>>> No installed jimsh or tclsh, building local bootstrap jimsh0
>>> ../../jimtcl/autosetup/find-tclsh: line 10: cc: command not found
>>> configure: error: ../../jimtcl/configure.gnu failed for jimtcl
>>>
>>> The line in question is:
>>> ${CC_FOR_BUILD:-cc} -o "$d/jimsh0" "$d/jimsh0.c" || exit 1
>>
>> jimtcl doesn't (yet) support building on mingw/msys
>> It will at some point, though.
>>
>
> Looking at that snippet he is cross compiling mingw under cygwin -
> working fine here.
> I would just try a simple native build, eg.
> ./openocd/configure --enable-maintainer-mode --enable-dummy
>
> Cheers
> Spen
>> ../../jimtcl/autosetup/find-tclsh: line 10: cc: command not found
But no cc?
>
If cygwin is installed, why no cc?___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Building local bootstrap jimsh0 failed
On 07/07/2011, at 2:13 AM, Eric Wetzel wrote:
> I pulled from origin and now my process is failing during configure.
> On ac43d7a69fca52df1ad287b51c44013653ad2f61, comping under Cygwin with
> MinGW compiler, I get this:
>
> === configuring in jimtcl (/home/ericwetz/local/src/openocd.git/build/jimtcl)
> configure: running /bin/sh ../../jimtcl/configure.gnu
> --disable-option-checking '--prefix=/home/ericwetz/local'
> '--enable-maintainer-mode' '--build=i686-pc-cygwin'
> '--host=i686-pc-mingw32' '--enable-dummy' '--enable-jlink'
> '--enable-ft2232_ftd2xx'
> '--with-ftd2xx-win32-zipdir=/home/ericwetz/local/src/ftd2xx'
> 'build_alias=i686-pc-cygwin' 'host_alias=i686-pc-mingw32'
> --cache-file=/dev/null --srcdir=../../jimtcl
> No installed jimsh or tclsh, building local bootstrap jimsh0
> ../../jimtcl/autosetup/find-tclsh: line 10: cc: command not found
> configure: error: ../../jimtcl/configure.gnu failed for jimtcl
>
> The line in question is:
> ${CC_FOR_BUILD:-cc} -o "$d/jimsh0" "$d/jimsh0.c" || exit 1
jimtcl doesn't (yet) support building on mingw/msys
It will at some point, though.
Cheers,
Steve
--
µWeb: Embedded Web Framework - http://uweb.workware.net.au/
WorkWare Systems Pty Ltd
W: www.workware.net.au P: +61 434 921 300
E: ste...@workware.net.au F: +61 7 3391 6002
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] static_lib directory missing?
On 06/07/2011, at 1:14 AM, Bill Traynor wrote:
> I'm attempting to compile OpenOCD (git:master branch) for use with the
> PandaBoard using the ftd2xx driver, and am experiencing the following:
>
> ./configure --enable-ft2232_ftd2xx
> --with-ftd2xx-linux-tardir=${HOME}/dev/libftd2xx1.0.4
> --prefix=/home/wmat/bin/openOCD
>
> Error:
> checking uninstalled ftd2xx distribution... ls: cannot access
> /home/wmat/dev/libftd2xx1.0.4/static_lib/libftd2xx.a.*.*.*: No such file or
> directory
> configure: error: Not found: , option: --with-ftd2xx-linux-tardir appears to
> be wrong
>
>
> The error is correct, as there is no dir: static_lib in the libftd2xx1.0.4
> tree. I am using the D2XX drivers for Linux x64(64-bit) found here:
> http://www.ftdichip.com/Drivers/D2XX.htm My host is a 64-bit Ubuntu 11.04
> system.
>
> Am I supposed to manually create the static_lib directory? I find no mention
> of that directory in the OpenOCD or libftd2xx docs. Searching the openocd
> mailing list archives don't turn up anything either.
>
> Thanks
> Bill
I posted patches to the list to fix this problem (starting here:
https://lists.berlios.de/pipermail/openocd-development/2011-June/019633.html),
but they have gone into limbo.
Not sure if/when they will be accepted.
Cheers,
Steve
--
µWeb: Embedded Web Framework - http://uweb.workware.net.au/
WorkWare Systems Pty Ltd
W: www.workware.net.au P: +61 434 921 300
E: ste...@workware.net.au F: +61 7 3391 6002
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Current master branch state
More detail please. On 02/07/2011, at 3:26 AM, Drasko DRASKOVIC wrote: > Hi all, > is current maser broken ? > > ./config breaks on jimtcl configuration > > BR, > Drasko > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Openocd release known issues
On 28/06/2011, at 6:32 PM, Spencer Oliver wrote: > On 27 June 2011 22:33, Steve Bennett wrote: > On 27/06/2011, at 10:07 PM, Spencer Oliver wrote: > >> On 27 June 2011 11:05, Spencer Oliver wrote: >> Thanks that solves all the problems i see with make distcheck. >> At some point i may look into a method of tweaking so we do not install >> unnecessary files, but all is good for the next openocd release. >> >> Cheers >> Spen >> >> Spoke to soon :) >> jimtcl head now fails to build under cygwin - ok under linux. >> >> After a full distclean i then get a segfault >> === configuring in jimtcl (/home/soliver/openocd/openocd-inline/jimtcl) >> configure: running /bin/sh ./configure.gnu --disable-option-checking >> '--prefix=/usr/local' '--enable-maintainer-mode' '--disable-shared' >> '--disable-werror' '--enable-parport' '--enable-jlink' '--enable-rlink' >> '--enable-ft2232_ftd2xx' 'CFLAGS=-O0 -g' --cache-file=/dev/null --srcdir=. >> No installed jimsh or tclsh, building local bootstrap jimsh0 >> ./configure.gnu: line 2: 2392 Segmentation fault (core dumped) $SHELL >> .././jimtcl/configure --with-jim-ext=nvp --disable-lineedit "$@" >> configure: error: ./configure.gnu failed for jimtcl >> >> The issue was introduced in commit f25d6276ee487d583e35c48f3125ef388c9f7d3f > > Try latest git. You will need to remove the old autosetup/jimsh0.exe > > > Steve, > > Another small observation cygwin does includes tclsh - tclsh.exe and > tclsh84.exe tclsh84 isn't "good enough". tclsh85 is OK, and it will be used if it is available. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Openocd release known issues
On 28/06/2011, at 6:24 PM, Spencer Oliver wrote: > On 27 June 2011 22:33, Steve Bennett wrote: > On 27/06/2011, at 10:07 PM, Spencer Oliver wrote: > >> On 27 June 2011 11:05, Spencer Oliver wrote: >> Thanks that solves all the problems i see with make distcheck. >> At some point i may look into a method of tweaking so we do not install >> unnecessary files, but all is good for the next openocd release. >> >> Cheers >> Spen >> >> Spoke to soon :) >> jimtcl head now fails to build under cygwin - ok under linux. >> >> After a full distclean i then get a segfault >> === configuring in jimtcl (/home/soliver/openocd/openocd-inline/jimtcl) >> configure: running /bin/sh ./configure.gnu --disable-option-checking >> '--prefix=/usr/local' '--enable-maintainer-mode' '--disable-shared' >> '--disable-werror' '--enable-parport' '--enable-jlink' '--enable-rlink' >> '--enable-ft2232_ftd2xx' 'CFLAGS=-O0 -g' --cache-file=/dev/null --srcdir=. >> No installed jimsh or tclsh, building local bootstrap jimsh0 >> ./configure.gnu: line 2: 2392 Segmentation fault (core dumped) $SHELL >> .././jimtcl/configure --with-jim-ext=nvp --disable-lineedit "$@" >> configure: error: ./configure.gnu failed for jimtcl >> >> The issue was introduced in commit f25d6276ee487d583e35c48f3125ef388c9f7d3f > > Try latest git. You will need to remove the old autosetup/jimsh0.exe > > > > Many Thanks again, that seems to fix the build (for cygwin and mingw) - i > will try functional testing later today. Thanks. > > One observation is that jimsh0 is built in the src dir, perhaps it would be > better to use the builddir. > I tend to build out of tree for various arch's and having jimsh0 built in the > src dir does create issues for this kind of setup. I will see if this is easily doable. > > Also it would be good if a distclean removed jimsh0 as it is generated by > configure. Yes. Good idea. > > Cheers > Spen -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Status of building using Mingw64?
On 28/06/2011, at 5:14 PM, Xiaofan Chen wrote: > On Tue, Jun 28, 2011 at 2:25 PM, Steve Bennett wrote: >> If you like, you can try the following two patches. >> To do this, you will need to first update jimtcl to the master branch. >> >> I have compile tested this, but I don't have anything to run it on. > > Just a minor thing. > > -#ifdef __MINGW32__ > -#define MKDIR_ONE_ARG > +#if defined(__MINGW32__) || defined(__MINGW64__) > +#define HAVE_MKDIR_ONE_ARG > > Actually MinGW-w64 (32bit or 64bit) also defines __MINGW32__. > > bash-4.1# x86_64-w64-mingw32-gcc -dD -E -x c /dev/null | grep MINGW64 > #define __MINGW64__ 1 > bash-4.1# x86_64-w64-mingw32-gcc -dD -E -x c /dev/null | grep MINGW32 > #define __MINGW32__ 1 > > In case you need to differentiate MinGW.org MINGW32 and > MinGW-w64, you can use __MINGW64_VERSION_MAJOR > which is defined in the file _mingw_mac.h for MinGW-w64. >#define __MINGW64_VERSION_MAJOR1 >#define __MINGW64_VERSION_MINOR1 Thanks. I was just being safe since the OP seemed to indicate that __MINGW32__ wasn't defined. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Status of building using Mingw64?
On 28/06/2011, at 9:26 AM, Rodrigo Rosa wrote: > i tried > ./configure --enable-mantainer-mode --enable-ft2232-libftdi > --host=x86_64-w64-mingw32 CFLAGS=-D__MINGW32__ > > and i got a bit further, now i'm stuck with this: > . > . > . > jim-eventloop.o jim-eventloop.c > jim-eventloop.c:53:21: error: windows.h: No such file or directory > jim-eventloop.c:54:21: error: winsock.h: No such file or directory > jim-eventloop.c: In function ‘JimELAfterCommand’: > jim-eventloop.c:637: warning: implicit declaration of function ‘Sleep’ > make[2]: *** [jim-eventloop.o] Error 1 > . > . > . > > can i solve that with another configure param? > the files are at > /usr/amd64-mingw32msvc/include/ > and at > /usr/i586-mingw32msvc/include/ > > and it does not complain about the Sleep if i change the define at > jim-eventloop.c:55 to: > #define msleep sleep > (instead of #define msleep Sleep) > If you like, you can try the following two patches. To do this, you will need to first update jimtcl to the master branch. I have compile tested this, but I don't have anything to run it on. -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 0001-Don-t-try-to-store-an-int-into-a-void.patch Description: Binary data 0002-Fix-support-for-64-bit-mingw.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Status of building using Mingw64?
On 28/06/2011, at 9:26 AM, Rodrigo Rosa wrote: > i tried > ./configure --enable-mantainer-mode --enable-ft2232-libftdi > --host=x86_64-w64-mingw32 CFLAGS=-D__MINGW32__ > > and i got a bit further, now i'm stuck with this: > . > . > . > jim-eventloop.o jim-eventloop.c > jim-eventloop.c:53:21: error: windows.h: No such file or directory > jim-eventloop.c:54:21: error: winsock.h: No such file or directory > jim-eventloop.c: In function ‘JimELAfterCommand’: > jim-eventloop.c:637: warning: implicit declaration of function ‘Sleep’ > make[2]: *** [jim-eventloop.o] Error 1 > . > . > . > > can i solve that with another configure param? > the files are at > /usr/amd64-mingw32msvc/include/ > and at > /usr/i586-mingw32msvc/include/ > > and it does not complain about the Sleep if i change the define at > jim-eventloop.c:55 to: > #define msleep sleep > (instead of #define msleep Sleep) > > thanks! It's obviously going to need some work. What platform are you building on? What mingw packages are you using? Cheers, Steve > > On Mon, Jun 27, 2011 at 3:11 PM, Steve Bennett wrote: >> On 28/06/2011, at 6:33 AM, Rodrigo Rosa wrote: >> >>> i'm trying to cross compile for win XP, with the following config: >>> ./configure --enable-mantainer-mode --enable-ft2232-libftdi >>> --host=x86_64-w64-mingw32 >>> >>> i get the following errors: >>> jim-win32compat.c: In function ‘gettimeofday’: >>> jim-win32compat.c:36: error: storage size of ‘tb’ isn’t known >>> jim-win32compat.c:38: warning: implicit declaration of functgpion ‘_ftime’ >>> jim-win32compat.c:36: warning: unused variable ‘tb’ >>> jim-win32compat.c: At top level: >>> jim-win32compat.c:58: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or >>> ‘__attribute__’ before ‘*’ token >>> jim-win32compat.c:91: error: expected ‘)’ before ‘*’ token >>> jim-win32compat.c:106: error: expected ‘)’ before ‘*’ token >>> >>> i've attached the configure output. >>> >>> i've never done cross compiling before, so any help is welcome. >>> >>> thanks! >> >> It seems that the __MINGW32__ symbol isn't defined. It should be. >> Perhaps add CFLAGS=-D__MING32__ to the configure line and see if that gets >> you any further. >> >> Cheers, >> Steve >> >>> On Mon, Jun 13, 2011 at 3:49 PM, Liam Redmond (Rock Software) >>> wrote: >>>> It has been a while and I think my msys is quite out of date. Have reverted >>>> to building on Linux. >>>> >>>> Thanks. >>>> >>>> - Original Message - From: "Freddie Chopin" >>>> To: >>>> Sent: Monday, June 13, 2011 4:22 PM >>>> Subject: Re: [Openocd-development] Status of building using Mingw64? >>>> >>>> >>>>> OpenOCD versions from my website ( www.freddiechopin.info ) - 32- and >>>>> 64-bit, the most recent one is a week old - are built with this compiler, >>>>> but with the most recent version (GCC 4.7.0) and on Linux, as I found that >>>>> easier than using Cygwin or MSYS directly in Windows. >>>>> >>>>> 4\/3!! >>>>> >>>>> >>>>> ___ >>>>> Openocd-development mailing list >>>>> Openocd-development@lists.berlios.de >>>>> https://lists.berlios.de/mailman/listinfo/openocd-development >>>> >>>> ___ >>>> Openocd-development mailing list >>>> Openocd-development@lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/openocd-development >>>> >>> >>> >>> >>> -- >>> Rodrigo. >>> ___ >>> Openocd-development mailing list >>> Openocd-development@lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/openocd-development >> >> -- >> µWeb: Embedded Web Framework - http://uweb.workware.net.au/ >> WorkWare Systems Pty Ltd >> W: www.workware.net.au P: +61 434 921 300 >> E: ste...@workware.net.au F: +61 7 3391 6002 >> >> >> >> >> >> > > > > -- > Rodrigo. > -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Status of building using Mingw64?
On 28/06/2011, at 6:33 AM, Rodrigo Rosa wrote: > i'm trying to cross compile for win XP, with the following config: > ./configure --enable-mantainer-mode --enable-ft2232-libftdi > --host=x86_64-w64-mingw32 > > i get the following errors: > jim-win32compat.c: In function ‘gettimeofday’: > jim-win32compat.c:36: error: storage size of ‘tb’ isn’t known > jim-win32compat.c:38: warning: implicit declaration of functgpion ‘_ftime’ > jim-win32compat.c:36: warning: unused variable ‘tb’ > jim-win32compat.c: At top level: > jim-win32compat.c:58: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or > ‘__attribute__’ before ‘*’ token > jim-win32compat.c:91: error: expected ‘)’ before ‘*’ token > jim-win32compat.c:106: error: expected ‘)’ before ‘*’ token > > i've attached the configure output. > > i've never done cross compiling before, so any help is welcome. > > thanks! It seems that the __MINGW32__ symbol isn't defined. It should be. Perhaps add CFLAGS=-D__MING32__ to the configure line and see if that gets you any further. Cheers, Steve > On Mon, Jun 13, 2011 at 3:49 PM, Liam Redmond (Rock Software) > wrote: >> It has been a while and I think my msys is quite out of date. Have reverted >> to building on Linux. >> >> Thanks. >> >> - Original Message - From: "Freddie Chopin" >> To: >> Sent: Monday, June 13, 2011 4:22 PM >> Subject: Re: [Openocd-development] Status of building using Mingw64? >> >> >>> OpenOCD versions from my website ( www.freddiechopin.info ) - 32- and >>> 64-bit, the most recent one is a week old - are built with this compiler, >>> but with the most recent version (GCC 4.7.0) and on Linux, as I found that >>> easier than using Cygwin or MSYS directly in Windows. >>> >>> 4\/3!! >>> >>> >>> ___ >>> Openocd-development mailing list >>> Openocd-development@lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/openocd-development >> >> ___ >> Openocd-development mailing list >> Openocd-development@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/openocd-development >> > > > > -- > Rodrigo. > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Openocd release known issues
On 27/06/2011, at 10:07 PM, Spencer Oliver wrote: > On 27 June 2011 11:05, Spencer Oliver wrote: > Thanks that solves all the problems i see with make distcheck. > At some point i may look into a method of tweaking so we do not install > unnecessary files, but all is good for the next openocd release. > > Cheers > Spen > > Spoke to soon :) > jimtcl head now fails to build under cygwin - ok under linux. > > After a full distclean i then get a segfault > === configuring in jimtcl (/home/soliver/openocd/openocd-inline/jimtcl) > configure: running /bin/sh ./configure.gnu --disable-option-checking > '--prefix=/usr/local' '--enable-maintainer-mode' '--disable-shared' > '--disable-werror' '--enable-parport' '--enable-jlink' '--enable-rlink' > '--enable-ft2232_ftd2xx' 'CFLAGS=-O0 -g' --cache-file=/dev/null --srcdir=. > No installed jimsh or tclsh, building local bootstrap jimsh0 > ./configure.gnu: line 2: 2392 Segmentation fault (core dumped) $SHELL > .././jimtcl/configure --with-jim-ext=nvp --disable-lineedit "$@" > configure: error: ./configure.gnu failed for jimtcl > > The issue was introduced in commit f25d6276ee487d583e35c48f3125ef388c9f7d3f Try latest git. You will need to remove the old autosetup/jimsh0.exe Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Openocd release known issues
On 27/06/2011, at 10:07 PM, Spencer Oliver wrote: > On 27 June 2011 11:05, Spencer Oliver wrote: > Thanks that solves all the problems i see with make distcheck. > At some point i may look into a method of tweaking so we do not install > unnecessary files, but all is good for the next openocd release. > > Cheers > Spen > > Spoke to soon :) > jimtcl head now fails to build under cygwin - ok under linux. > > After a full distclean i then get a segfault > === configuring in jimtcl (/home/soliver/openocd/openocd-inline/jimtcl) > configure: running /bin/sh ./configure.gnu --disable-option-checking > '--prefix=/usr/local' '--enable-maintainer-mode' '--disable-shared' > '--disable-werror' '--enable-parport' '--enable-jlink' '--enable-rlink' > '--enable-ft2232_ftd2xx' 'CFLAGS=-O0 -g' --cache-file=/dev/null --srcdir=. > No installed jimsh or tclsh, building local bootstrap jimsh0 > ./configure.gnu: line 2: 2392 Segmentation fault (core dumped) $SHELL > .././jimtcl/configure --with-jim-ext=nvp --disable-lineedit "$@" > configure: error: ./configure.gnu failed for jimtcl > > The issue was introduced in commit f25d6276ee487d583e35c48f3125ef388c9f7d3f Thanks. Will investigate. -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 3/3] ft2232: Add casts to avoid warnings
On 24/06/2011, at 2:04 AM, Michael Schwingen wrote: > On 23.06.2011 14:39, Laurent Gauch wrote: >>> />>/ I don't see how. >>> />/ />/ I haven't followed this(big discussions), but I've seen on the >>> list >>> />/ in the past that casting is frowned upon and using these >>> />/ macros is cheered... Anyway... I'm happy to follow the path >>> />/ of using these macros, I certainly don't want to become an >>> />/ expert! :-) >>> / >> We do not ask maintainers, as you, to be experts. >>> I guess I'm not quite sure what you want. >>> Feel free to apply a modified patch if you want, >>> as long as it removes the warnings. > >> I do not understand too ! >> Please explain us exactly what you want, or please merge the steve's >> patch asap. > > I think he did: using casts is no solution, since it only removes the > warnings on *some* systems. Using the PRxxx macros as done in other parts of > the code is the right way, so a new patch using the macros should be > submitted - this is not a task for a maintainer, but for the patch submitter. Then perhaps this is what you are after. I'm not sure if it is any more correct, since FT_STATUS is ULONG which is unsigned int (!), not uint32_t Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 0001-ft2232-Fix-warnings-when-building-against-D2XX.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 3/3] ft2232: Add casts to avoid warnings
On 23/06/2011, at 9:21 PM, Øyvind Harboe wrote: > On Thu, Jun 23, 2011 at 1:03 PM, Steve Bennett wrote: >> On 23/06/2011, at 8:59 PM, Øyvind Harboe wrote: >> >>> I don't think this is sufficient, as it will put up warnings on some >>> other platforms unless you use the macros that expand to the >>> correct formatting string. >>> >>> See C99 section: >>> >>> http://en.wikipedia.org/wiki/Printf >> >> Can you provide an example of a platform which produces warnings? >> I don't see how. > > I haven't followed this(big discussions), but I've seen on the list > in the past that casting is frowned upon and using these > macros is cheered... Anyway... I'm happy to follow the path > of using these macros, I certainly don't want to become an > expert! :-) I guess I'm not quite sure what you want. Feel free to apply a modified patch if you want, as long as it removes the warnings. Cheers, Steve > > -- > Øyvind Harboe - Can Zylin Consulting help on your project? > US toll free 1-866-980-3434 / International +47 51 87 40 27 > http://www.zylin.com/ > -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 3/3] ft2232: Add casts to avoid warnings
On 23/06/2011, at 8:59 PM, Øyvind Harboe wrote: > I don't think this is sufficient, as it will put up warnings on some > other platforms unless you use the macros that expand to the > correct formatting string. > > See C99 section: > > http://en.wikipedia.org/wiki/Printf Can you provide an example of a platform which produces warnings? I don't see how. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal
On 21/06/2011, at 5:22 PM, Steve Bennett wrote: > > On 21/06/2011, at 5:18 PM, Laurent Gauch wrote: > >> Steve Bennett wrote: >>> On 21/06/2011, at 5:01 PM, Xiaofan Chen wrote: >>> >>> >>>> On Tue, Jun 21, 2011 at 2:55 PM, Xiaofan Chen wrote: >>>> >>>>>> But are you sure to have the correct libusb version. On linux and mac, >>>>>> the >>>>>> libusb is the kernel driver for the d2xx. >>>>>> >>>>> This has been discussed before and I think in this case an exception >>>>> should >>>>> be granted and the patch should be accepted. >>>>> >>>>> Thread: >>>>> http://lists.berlios.de/pipermail/openocd-development/2011-March/018422.html >>>>> >>>>> I was suggesting the user to use the open source libftdi and libftdi-1.0 >>>>> under Linux instead but D2XX might still have some benefits so that >>>>> users may still want to use it. >>>>> >>>>> >>>> It is a long thread but I was able to reproduce the error. >>>> http://lists.berlios.de/pipermail/openocd-development/2011-March/018434.html >>>> "I think the latest d2xx library needs some fix from the OpenOCD >>>> side or from the d2xx side." >>>> >>>> It is more difficult to ask FTDI for a fix so it may better to fix this >>>> from >>>> OpenOCD side. Therefore I think the patch should be accepted. >>>> >>>> When FTDI fixes D2xx, then probably the patch can be reverted. >>>> >>> >>> I have reported the problem to FTDI, but in my experience we can not >>> expect a response soon, if ever. >>> I think there are two options, either apply the patch as a workaround >>> (note that the returned value is *never* used), or remove support for D2XX. >>> >> Thank you Steve, >> >> If you do not get any reply on next Monday, please let me know I will ask >> them. Amontec has good contacts to FTDI team. > > Will do. > >> Please apply the patch as a workaround. > > It is on the list. Perhaps some kind maintainer will do so. > >> >> But if the returned value is never used, there are no reason to give a >> warning ! > > Agreed. But it seemed less of a step from fatal error to warning than > ignoring it > completely. I take it all back! I got a very prompt reply from FTDI with a new version of the D2XX driver to test (1.0.5) which resolves this problem. Hopefully this version will become generally available soon. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal
On 21/06/2011, at 5:18 PM, Laurent Gauch wrote: > Steve Bennett wrote: >> On 21/06/2011, at 5:01 PM, Xiaofan Chen wrote: >> >> >>> On Tue, Jun 21, 2011 at 2:55 PM, Xiaofan Chen wrote: >>> >>>>> But are you sure to have the correct libusb version. On linux and mac, the >>>>> libusb is the kernel driver for the d2xx. >>>>> >>>> This has been discussed before and I think in this case an exception should >>>> be granted and the patch should be accepted. >>>> >>>> Thread: >>>> http://lists.berlios.de/pipermail/openocd-development/2011-March/018422.html >>>> >>>> I was suggesting the user to use the open source libftdi and libftdi-1.0 >>>> under Linux instead but D2XX might still have some benefits so that >>>> users may still want to use it. >>>> >>>> >>> It is a long thread but I was able to reproduce the error. >>> http://lists.berlios.de/pipermail/openocd-development/2011-March/018434.html >>> "I think the latest d2xx library needs some fix from the OpenOCD >>> side or from the d2xx side." >>> >>> It is more difficult to ask FTDI for a fix so it may better to fix this from >>> OpenOCD side. Therefore I think the patch should be accepted. >>> >>> When FTDI fixes D2xx, then probably the patch can be reverted. >>> >> >> I have reported the problem to FTDI, but in my experience we can not >> expect a response soon, if ever. >> I think there are two options, either apply the patch as a workaround >> (note that the returned value is *never* used), or remove support for D2XX. >> > Thank you Steve, > > If you do not get any reply on next Monday, please let me know I will ask > them. Amontec has good contacts to FTDI team. Will do. > Please apply the patch as a workaround. It is on the list. Perhaps some kind maintainer will do so. > > But if the returned value is never used, there are no reason to give a > warning ! Agreed. But it seemed less of a step from fatal error to warning than ignoring it completely. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal / OBJECTION
On 21/06/2011, at 5:01 PM, Xiaofan Chen wrote: > On Tue, Jun 21, 2011 at 2:55 PM, Xiaofan Chen wrote: >>> But are you sure to have the correct libusb version. On linux and mac, the >>> libusb is the kernel driver for the d2xx. >> >> This has been discussed before and I think in this case an exception should >> be granted and the patch should be accepted. >> >> Thread: >> http://lists.berlios.de/pipermail/openocd-development/2011-March/018422.html >> >> I was suggesting the user to use the open source libftdi and libftdi-1.0 >> under Linux instead but D2XX might still have some benefits so that >> users may still want to use it. >> > > It is a long thread but I was able to reproduce the error. > http://lists.berlios.de/pipermail/openocd-development/2011-March/018434.html > "I think the latest d2xx library needs some fix from the OpenOCD > side or from the d2xx side." > > It is more difficult to ask FTDI for a fix so it may better to fix this from > OpenOCD side. Therefore I think the patch should be accepted. > > When FTDI fixes D2xx, then probably the patch can be reverted. I have reported the problem to FTDI, but in my experience we can not expect a response soon, if ever. I think there are two options, either apply the patch as a workaround (note that the returned value is *never* used), or remove support for D2XX. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal / OBJECTION
On 21/06/2011, at 4:45 PM, Laurent Gauch wrote: > Steve Bennett wrote: >> On 21/06/2011, at 3:59 PM, Laurent Gauch wrote: >> >> >>>> On 21/06/2011, at 1:07 AM, Laurent Gauch wrote: >>>> >>>> >>>>>> / />>/ >/ On Mon, Jun 20, 2011 at 1:00 PM, Steve Bennett >>>>> workware.net.au >>>>>> <https://lists.berlios.de/mailman/listinfo/openocd-development>> wrote: >>>>>> >>>> />>/ />>/ On 20/06/2011, at 8:54 PM, Øyvind Harboe wrote: >>>> />>/ />>/ />>>/ On Mon, Jun 20, 2011 at 12:50 PM, Steve Bennett >>> workware.net.au >>>> <https://lists.berlios.de/mailman/listinfo/openocd-development>> wrote: >>>> />>/ />>>>/ Instead, just produce a warning >>>> />>/ />>>/ />>>/ Why? >>>> />>/ />>>/ />>>/ It merits a comment at least? >>>> />>/ />>/ />>/ Seems self-evident to me. >>>> />>/ />>/ Why should it be fatal just because a value couldn't be read? >>>> />>/ />>/ Doesn't stop anything from working. >>>> />>/ />/ />/ Why should we support broken hardware or drivers? >>>> />>/ />/ />/ Better the user is told to toss his busted dongle / hardware >>>> than to tangle >>>> />>/ />/ with subtle followon errors? >>>> />>/ / >>>> />>/ Nothing to do with hardware. It's a problem with the driver. >>>> />>/ See >>>> http://www.mail-archive.com/openocd-development@lists.berlios.de/msg15945.html >>>> />>/ />>/ >/ / >>>> />/ Objection ! >>>> />/ />/ If we cannot read this value back, this means we reach trouble >>>> with driver or device somewhere. >>>> />/ Also, this trouble could affect following access ... >>>> />/ This is why we stop with fatal error. >>>> / >>>> OK. So what alternative solution would you suggest to make this driver >>>> work? >>>> >>>> >>> What version of the driver do you use. If it really come from the driver >>> and if this is the last official driver, then ask the writer of the driver >>> to correct. >>> If no correction are done quickly by the writer of the driver, then yes, >>> you may just produce a warning. >>> >> >> http://www.ftdichip.com/Drivers/D2XX.htm >> >> Latest version, 1.0.4. Same behaviour on both MacOSX and Linux. >> >> Sure. I'll ask if they would like to fix this problem. >> I will let you know what useful response I get. >> > Great. > > But are you sure to have the correct libusb version. On linux and mac, the > libusb is the kernel driver for the d2xx. Yes. I am using the static library of libftd2xx which includes libusb. (openocd does not build with the shared library) Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal / OBJECTION
On 21/06/2011, at 3:59 PM, Laurent Gauch wrote: >> On 21/06/2011, at 1:07 AM, Laurent Gauch wrote: >> >> >>/ />>/ >/ On Mon, Jun 20, 2011 at 1:00 PM, Steve Bennett > >>workware.net.au >> >><https://lists.berlios.de/mailman/listinfo/openocd-development>> wrote: >> />>/ />>/ On 20/06/2011, at 8:54 PM, Øyvind Harboe wrote: >> />>/ />>/ />>>/ On Mon, Jun 20, 2011 at 12:50 PM, Steve Bennett > workware.net.au >> <https://lists.berlios.de/mailman/listinfo/openocd-development>> wrote: >> />>/ />>>>/ Instead, just produce a warning >> />>/ />>>/ />>>/ Why? >> />>/ />>>/ />>>/ It merits a comment at least? >> />>/ />>/ />>/ Seems self-evident to me. >> />>/ />>/ Why should it be fatal just because a value couldn't be read? >> />>/ />>/ Doesn't stop anything from working. >> />>/ />/ />/ Why should we support broken hardware or drivers? >> />>/ />/ />/ Better the user is told to toss his busted dongle / hardware >> than to tangle >> />>/ />/ with subtle followon errors? >> />>/ / >> />>/ Nothing to do with hardware. It's a problem with the driver. >> />>/ See >> http://www.mail-archive.com/openocd-development@lists.berlios.de/msg15945.html >> />>/ />>/ >/ / >> />/ Objection ! >> />/ />/ If we cannot read this value back, this means we reach trouble with >> driver or device somewhere. >> />/ Also, this trouble could affect following access ... >> />/ This is why we stop with fatal error. >> / >> OK. So what alternative solution would you suggest to make this driver work? >> > What version of the driver do you use. If it really come from the driver and > if this is the last official driver, then ask the writer of the driver to > correct. > If no correction are done quickly by the writer of the driver, then yes, you > may just produce a warning. http://www.ftdichip.com/Drivers/D2XX.htm Latest version, 1.0.4. Same behaviour on both MacOSX and Linux. Sure. I'll ask if they would like to fix this problem. I will let you know what useful response I get. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal / OBJECTION
On 21/06/2011, at 1:07 AM, Laurent Gauch wrote: >> >> >/ On Mon, Jun 20, 2011 at 1:00 PM, Steve Bennett > ><https://lists.berlios.de/mailman/listinfo/openocd-development>> wrote: >> />>/ On 20/06/2011, at 8:54 PM, Øyvind Harboe wrote: >> />>/ />>>/ On Mon, Jun 20, 2011 at 12:50 PM, Steve Bennett > workware.net.au >> <https://lists.berlios.de/mailman/listinfo/openocd-development>> wrote: >> />>>>/ Instead, just produce a warning >> />>>/ />>>/ Why? >> />>>/ />>>/ It merits a comment at least? >> />>/ />>/ Seems self-evident to me. >> />>/ Why should it be fatal just because a value couldn't be read? >> />>/ Doesn't stop anything from working. >> />/ />/ Why should we support broken hardware or drivers? >> />/ />/ Better the user is told to toss his busted dongle / hardware than to >> tangle >> />/ with subtle followon errors? >> / >> Nothing to do with hardware. It's a problem with the driver. >> See >> http://www.mail-archive.com/openocd-development@lists.berlios.de/msg15945.html >> >> >/ / > Objection ! > > If we cannot read this value back, this means we reach trouble with driver or > device somewhere. > Also, this trouble could affect following access ... > This is why we stop with fatal error. OK. So what alternative solution would you suggest to make this driver work? Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal
On 20/06/2011, at 9:51 PM, Øyvind Harboe wrote: > On Mon, Jun 20, 2011 at 1:00 PM, Steve Bennett wrote: >> On 20/06/2011, at 8:54 PM, Øyvind Harboe wrote: >> >>> On Mon, Jun 20, 2011 at 12:50 PM, Steve Bennett >>> wrote: >>>> Instead, just produce a warning >>> >>> Why? >>> >>> It merits a comment at least? >> >> Seems self-evident to me. >> Why should it be fatal just because a value couldn't be read? >> Doesn't stop anything from working. > > Why should we support broken hardware or drivers? > > Better the user is told to toss his busted dongle / hardware than to tangle > with subtle followon errors? Nothing to do with hardware. It's a problem with the driver. See http://www.mail-archive.com/openocd-development@lists.berlios.de/msg15945.html > > > -- > Øyvind Harboe > > Can Zylin Consulting help on your project? > > US toll free 1-866-980-3434 / International +47 51 87 40 27 > > http://www.zylin.com/zy1000.html > ARM7 ARM9 ARM11 XScale Cortex > JTAG debugger and flash programmer > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal
On 20/06/2011, at 8:54 PM, Øyvind Harboe wrote: > On Mon, Jun 20, 2011 at 12:50 PM, Steve Bennett > wrote: >> Instead, just produce a warning > > Why? > > It merits a comment at least? Seems self-evident to me. Why should it be fatal just because a value couldn't be read? Doesn't stop anything from working. Cheers, Steve > > > -- > Øyvind Harboe > > Can Zylin Consulting help on your project? > > US toll free 1-866-980-3434 / International +47 51 87 40 27 > > http://www.zylin.com/zy1000.html > ARM7 ARM9 ARM11 XScale Cortex > JTAG debugger and flash programmer > -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 3/3] ft2232: Add casts to avoid warnings
The default is -Werror, so warnings become errors
and stop the build.
Might be better to simply #define FT_STATUS instead.
Signed-off-by: Steve Bennett
---
src/jtag/drivers/ft2232.c | 88 ++--
1 files changed, 44 insertions(+), 44 deletions(-)
diff --git a/src/jtag/drivers/ft2232.c b/src/jtag/drivers/ft2232.c
index 2e0495d..59b1606 100644
--- a/src/jtag/drivers/ft2232.c
+++ b/src/jtag/drivers/ft2232.c
@@ -515,7 +515,7 @@ static int ft2232_write(uint8_t* buf, int size, uint32_t*
bytes_written)
if ((status = FT_Write(ftdih, buf, size, &dw_bytes_written)) != FT_OK)
{
*bytes_written = dw_bytes_written;
- LOG_ERROR("FT_Write returned: %lu", status);
+ LOG_ERROR("FT_Write returned: %lu", (unsigned long)status);
return ERROR_JTAG_DEVICE_ERROR;
}
else
@@ -558,7 +558,7 @@ static int ft2232_read(uint8_t* buf, uint32_t size,
uint32_t* bytes_read)
*bytes_read, &dw_bytes_read)) !=
FT_OK)
{
*bytes_read = 0;
- LOG_ERROR("FT_Read returned: %lu", status);
+ LOG_ERROR("FT_Read returned: %lu", (unsigned
long)status);
return ERROR_JTAG_DEVICE_ERROR;
}
*bytes_read += dw_bytes_read;
@@ -2215,11 +2215,11 @@ static int ft2232_init_ftd2xx(uint16_t vid, uint16_t
pid, int more, int* try_mor
if (more)
{
- LOG_WARNING("unable to open ftdi device (trying more):
%lu", status);
+ LOG_WARNING("unable to open ftdi device (trying more):
%lu", (unsigned long)status);
*try_more = 1;
return ERROR_JTAG_INIT_FAILED;
}
- LOG_ERROR("unable to open ftdi device: %lu", status);
+ LOG_ERROR("unable to open ftdi device: %lu", (unsigned
long)status);
status = FT_ListDevices(&num_devices, NULL,
FT_LIST_NUMBER_ONLY);
if (status == FT_OK)
{
@@ -2235,7 +2235,7 @@ static int ft2232_init_ftd2xx(uint16_t vid, uint16_t pid,
int more, int* try_mor
if (status == FT_OK)
{
- LOG_ERROR("ListDevices: %lu", num_devices);
+ LOG_ERROR("ListDevices: %lu", (unsigned
long)num_devices);
for (i = 0; i < num_devices; i++)
LOG_ERROR("%" PRIu32 ": \"%s\"", i,
desc_array[i]);
}
@@ -2254,13 +2254,13 @@ static int ft2232_init_ftd2xx(uint16_t vid, uint16_t
pid, int more, int* try_mor
if ((status = FT_SetLatencyTimer(ftdih, ft2232_latency)) != FT_OK)
{
- LOG_ERROR("unable to set latency timer: %lu", status);
+ LOG_ERROR("unable to set latency timer: %lu", (unsigned
long)status);
return ERROR_JTAG_INIT_FAILED;
}
if ((status = FT_GetLatencyTimer(ftdih, &latency_timer)) != FT_OK)
{
- LOG_WARNING("unable to get latency timer: %lu", status);
+ LOG_WARNING("unable to get latency timer: %lu", (unsigned
long)status);
}
else
{
@@ -2269,19 +2269,19 @@ static int ft2232_init_ftd2xx(uint16_t vid, uint16_t
pid, int more, int* try_mor
if ((status = FT_SetTimeouts(ftdih, 5000, 5000)) != FT_OK)
{
- LOG_ERROR("unable to set timeouts: %lu", status);
+ LOG_ERROR("unable to set timeouts: %lu", (unsigned long)status);
return ERROR_JTAG_INIT_FAILED;
}
if ((status = FT_SetBitMode(ftdih, 0x0b, 2)) != FT_OK)
{
- LOG_ERROR("unable to enable bit i/o mode: %lu", status);
+ LOG_ERROR("unable to enable bit i/o mode: %lu", (unsigned
long)status);
return ERROR_JTAG_INIT_FAILED;
}
if ((status = FT_GetDeviceInfo(ftdih, &ftdi_device, &deviceID,
SerialNumber, Description, NULL)) != FT_OK)
{
- LOG_ERROR("unable to get FT_GetDeviceInfo: %lu", status);
+ LOG_ERROR("unable to get FT_GetDeviceInfo: %lu", (unsigned
long)status);
return ERROR_JTAG_INIT_FAILED;
}
else
@@ -2291,8 +2291,8 @@ static int ft2232_init_ftd2xx(uint16_t vid, uint16_t pid,
int more, int* try_mor
unsigned no_of_known_types = ARRAY_SIZE(type_str) - 1;
unsigned type_index = ((unsigned)ftdi_device <=
no_of_known_types)
? ftdi_
[Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal
Instead, just produce a warning
Signed-off-by: Steve Bennett
---
src/jtag/drivers/ft2232.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/src/jtag/drivers/ft2232.c b/src/jtag/drivers/ft2232.c
index 38ead56..2e0495d 100644
--- a/src/jtag/drivers/ft2232.c
+++ b/src/jtag/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);
}
else
{
--
1.7.5.1
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 1/3] ft2232: Fix configure --with-ftd2xx-linux-tardir
For libftd2xx1.0.4, which uses a different directory structure
than libftd2xx0.4.16
Note that this does not fix --with-ftd2xx-lib=shared
Also it assumes i386, not x86_64.
Signed-off-by: Steve Bennett
---
configure.in | 17 +
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/configure.in b/configure.in
index cb62c85..22f9e4e 100644
--- a/configure.in
+++ b/configure.in
@@ -863,14 +863,15 @@ if test $build_ft2232_ftd2xx = yes -o
$build_presto_ftd2xx = yes ; then
AC_MSG_ERROR([Option: --with-ftd2xx-linux-tardir appears wrong, cannot
find: ${FTD2XX_H}])
fi
CFLAGS="$CFLAGS -I$with_ftd2xx_linux_tardir"
-FTD2XX_LDFLAGS="-L$with_ftd2xx_linux_tardir"
-FTD2XX_LIB="-lftd2xx"
-if test $with_ftd2xx_lib != shared; then
- # Test #1 - Future proof - if/when ftdichip fixes their distro.
- # Try it with the simple ".a" suffix.
- FTD2XX_LIB="$with_ftd2xx_linux_tardir/static_lib/libftd2xx.a"
- if test -f "${FTD2XX_LIB}"; then
-FTD2XX_LDFLAGS="${FTD2XX_LDFLAGS}/static_lib"
+if test $with_ftd2xx_lib = shared; then
+ FTD2XX_LDFLAGS="-L$with_ftd2xx_linux_tardir"
+ FTD2XX_LIB="-lftd2xx"
+else
+ # Test #1 - v1.0.x
+ if test -f "$with_ftd2xx_linux_tardir/build/i386/libftd2xx.a"; then
+FTD2XX_LDFLAGS="-L$with_ftd2xx_linux_tardir/build/i386"
+# Also needs -lrt
+FTD2XX_LIB="-lftd2xx -lrt"
else
# Test Number2.
# Grr.. perhaps it exists as a version number?
--
1.7.5.1
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 0/3] Fixes to build with latest ftd2xx
I needed these fixes to get libftd2xx1.0.4 building and running on Linux. Could still be improved for shared library support and detection of i386 vs x86_64. Steve Bennett (3): ft2232: Fix configure --with-ftd2xx-linux-tardir ft2232: Failure to get latency should not be fatal ft2232: Add casts to avoid warnings configure.in | 17 + src/jtag/drivers/ft2232.c | 89 ++--- 2 files changed, 53 insertions(+), 53 deletions(-) -- 1.7.5.1 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Openocd release known issues
On 19/06/2011, at 4:59 PM, Steve Bennett wrote: > On 17/06/2011, at 6:51 PM, Spencer Oliver wrote: > >> On 17 June 2011 01:11, Steve Bennett wrote: >> >> Yes, you're right. Try the attached patch. >> >> make distcheck mostly works for me, but the build fails for reasons which is >> nothing >> to do with jimtcl. Not sure if there are any more problems after this point. >> Does this work for you? >> >> >> Steve, >> >> Many thanks, that solves that problem :) >> I am just about to push some fixes to the openocd side of distcheck, this >> still leaves an issue with distcheck - attached log. >> >> The issue is related to the install part of distcheck, to be honest we do >> not really need to install jim as we use it inline. >> Can you think of a way of telling jim to not install - perhaps a configure >> option (--noinstall) that replaces the default install with a blank handler > > May be easiest to just add an uninstall target. > I'll take a look. Try this: http://repo.or.cz/w/jimtcl.git/commit/fbc998db178da5c462e164b63da128a7d7412e37 With your recent changes, now 'make distcheck' works for me. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Openocd release known issues
On 17/06/2011, at 6:51 PM, Spencer Oliver wrote: > On 17 June 2011 01:11, Steve Bennett wrote: > > Yes, you're right. Try the attached patch. > > make distcheck mostly works for me, but the build fails for reasons which is > nothing > to do with jimtcl. Not sure if there are any more problems after this point. > Does this work for you? > > > Steve, > > Many thanks, that solves that problem :) > I am just about to push some fixes to the openocd side of distcheck, this > still leaves an issue with distcheck - attached log. > > The issue is related to the install part of distcheck, to be honest we do not > really need to install jim as we use it inline. > Can you think of a way of telling jim to not install - perhaps a configure > option (--noinstall) that replaces the default install with a blank handler May be easiest to just add an uninstall target. I'll take a look. Cheers, Steve > > cc'd the list again as it must have got removed. > > Cheers > Spen > -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Openocd release known issues
Hmmm. Works for me. Can you send me first few lines of git log in the jimtcl dir and also the output of make distcheck? And also jimtcl/Makefile Cheers, Steve On 16/06/2011, at 6:33 PM, Spencer Oliver wrote: > On 16 June 2011 05:38, Steve Bennett wrote: > On 16/06/2011, at 7:49 AM, Spencer Oliver wrote: > >> >> On Jun 15, 2011 10:30 PM, "Øyvind Harboe" wrote: >> > >> > I think we should stick to distributing source packages only. >> > >> >> That's my plan >> - even that is not easy as Jim does not use autoconf etc. >> >> > > That sounds like an easy problem to fix. > Try the latest version of Jim. > I've added: > http://repo.or.cz/w/jimtcl.git/commit/142edb4e35a90c316564ec1aacf6dde9ec5861cb > > This should mean that 'make distcheck' works, but let me know if it doesn't. > > > Steve, > > I have just updated to latest jimtcl master in my local repo. > make distcheck still fails - this is because openocd expects jimtrcl to be in > its src dist archive. > This will not happen because jim does not create a distribution when make > dist is called. > > I personally want to release the openocd src and jimtcl src as one archive > that the use can just build. > This is always a problem when using submodules that doe not fully comply with > the automake stuff. > > The solution seems to be to get jim to create a src release when make dist in > called at top level. > Another option is to manually copy the jimtcl src into the openocd > distribution - but that is not very gnu and may put of packagers fir the > various linux distributions. > > Cheers > Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Openocd release known issues
On 16/06/2011, at 7:49 AM, Spencer Oliver wrote: > > On Jun 15, 2011 10:30 PM, "Øyvind Harboe" wrote: > > > > I think we should stick to distributing source packages only. > > > > That's my plan > - even that is not easy as Jim does not use autoconf etc. > > That sounds like an easy problem to fix. Try the latest version of Jim. I've added: http://repo.or.cz/w/jimtcl.git/commit/142edb4e35a90c316564ec1aacf6dde9ec5861cb This should mean that 'make distcheck' works, but let me know if it doesn't. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fwd: [Jim-devel] New release of Jim Tcl (0.71) soon
On 14/06/2011, at 3:45 PM, Øyvind Harboe wrote: > Hi Steve, > > I intend to upgrade OpenOCD to the latest release once it is > available. > > Thanks for your efforts! Sounds good. It wouldn't hurt to test it *before* the release, just in case there is a problem and I can include fix it before the release. Steve > > > -- > Øyvind Harboe > > Can Zylin Consulting help on your project? > > US toll free 1-866-980-3434 / International +47 51 87 40 27 > > http://www.zylin.com/zy1000.html > ARM7 ARM9 ARM11 XScale Cortex > JTAG debugger and flash programmer > -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Fwd: [Jim-devel] New release of Jim Tcl (0.71) soon
FYI. This release will include a number of bug fixes in addition to a small number of added features. It might be worth updating the version of Jim Tcl used by the OpenOCD. Cheers, Steve Begin forwarded message: > From: Steve Bennett > Date: 10 June 2011 2:55:01 PM AEST > To: Jim Devel > Subject: [Jim-devel] New release of Jim Tcl (0.71) soon > > Hi All, > > At this stage, all of the planned features for the next release > are now done. > > I plan to let things "settle" for a week or so and then announce > a release. > > Let me know if anything is broken or if anything else should be > included in this release. > > Cheers, > Steve > >> Hi All, >> >> I have a few things on my list that I would like to see go into the >> next release of Jim Tcl. >> >> Feedback is welcome. >> >> Boring Stuff >> >> - Bug fixes >> - Performance improvements >> - Size reduction >> - Clean up dlopen() handles on interpreter deletion >> >> Tcl 8.x Features >> >> - Add support for the [binary] command >> - Support for non-greedy quantifiers in [regexp] >> >> TclX Features >> - >> - Add the [loop] command >> >> Tcl 9 (Proposed) Features >> - >> - [expr] shorthand syntax: $(...) >> - Automatic upvars in prog args: &varname >> - Allow proc 'args' to be renamed >> >> Build System >> >> - Replace autoconf with Tcl-based autosetup >> (https://github.com/msteveb/autosetup) >> >> Other Enhancements >> -- >> - Ability to "push" a proc over the top of an existing proc >> to easily create a wrapper proc, including the ability >> to "upcall" the original proc. > -- > µWeb: Embedded Web Framework - http://uweb.workware.net.au/ > WorkWare Systems Pty Ltd > W: www.workware.net.au P: +61 434 921 300 > E: ste...@workware.net.au F: +61 7 3391 6002 > > > > > > ___ > Jim-devel mailing list > jim-de...@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/jim-devel -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] cygwin: git head jimsh compilation failed
On 05/04/2011, at 4:08 PM, Steve Bennett wrote: > On 05/04/2011, at 3:53 PM, Mathias K. wrote: > >> I was able to link openocd against libjim. There is only a problem to link >> jimsh against libjim. > > Strange. > Perhaps you can send me libjim.a and I'll take a look. For the benefit of the list, this turned out to be a bogus/left-over jimsh.o >> >> >> Regards, >> >> Mathias >> >> >> Am 02.04.2011 03:10, schrieb Steve Bennett: >>> On 10/03/2011, at 9:20 PM, Mathias K. wrote: >>> >>>> I have append it, it is only the linker output. >>>> >>>> Am 10.03.2011 11:47, schrieb Peter Stuge: >>>>> Mathias K. wrote: >>>>>> Any hints to solve this problem? >>>>> >>>>> Please send exact copy of error messages, otherwise any diagnosis is >>>>> impossible. >>> >>> It looks like something has gone wrong with the creation of libjim.a >>> and it is empty. >>> >>> Please post the output of: >>> >>> nm libjim.a >>> >>> -- >>> µWeb: Embedded Web Framework - http://uweb.workware.net.au/ >>> WorkWare Systems Pty Ltd >>> W: www.workware.net.au P: +61 434 921 300 >>> E: ste...@workware.net.au F: +61 7 3391 6002 >>> >>> >>> >>> >>> >>> >> >> > > -- > µWeb: Embedded Web Framework - http://uweb.workware.net.au/ > WorkWare Systems Pty Ltd > W: www.workware.net.au P: +61 434 921 300 > E: ste...@workware.net.au F: +61 7 3391 6002 > > > > > > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] cygwin: git head jimsh compilation failed
On 05/04/2011, at 3:53 PM, Mathias K. wrote: > I was able to link openocd against libjim. There is only a problem to link > jimsh against libjim. Strange. Perhaps you can send me libjim.a and I'll take a look. Cheers, Steve > > > Regards, > > Mathias > > > Am 02.04.2011 03:10, schrieb Steve Bennett: >> On 10/03/2011, at 9:20 PM, Mathias K. wrote: >> >>> I have append it, it is only the linker output. >>> >>> Am 10.03.2011 11:47, schrieb Peter Stuge: >>>> Mathias K. wrote: >>>>> Any hints to solve this problem? >>>> >>>> Please send exact copy of error messages, otherwise any diagnosis is >>>> impossible. >> >> It looks like something has gone wrong with the creation of libjim.a >> and it is empty. >> >> Please post the output of: >> >> nm libjim.a >> >> -- >> µWeb: Embedded Web Framework - http://uweb.workware.net.au/ >> WorkWare Systems Pty Ltd >> W: www.workware.net.au P: +61 434 921 300 >> E: ste...@workware.net.au F: +61 7 3391 6002 >> >> >> >> >> >> > > -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] cygwin: git head jimsh compilation failed
On 10/03/2011, at 9:20 PM, Mathias K. wrote: > I have append it, it is only the linker output. > > Am 10.03.2011 11:47, schrieb Peter Stuge: >> Mathias K. wrote: >>> Any hints to solve this problem? >> >> Please send exact copy of error messages, otherwise any diagnosis is >> impossible. It looks like something has gone wrong with the creation of libjim.a and it is empty. Please post the output of: nm libjim.a -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Proposal: update IXP42x config files
On 18/12/2010, at 6:30 AM, Michael Schwingen wrote:
> Hi,
>
> I did some work on the IXP42x config files, adding more known TAP IDs plus
> some helper functions and constants to make board config files simpler and
> easier to read.
>
> I have seen 3 of the 6 listed TAP IDs on real hardware, and the others are
> inferred from the documentation. There might be three more for rev. A0
> silicon, which I do not have and which is probably quite rare except on some
> eval boards.
>
> Since my TCL knowledge is basically zero, I am looking for suggestions how
> to improve this - for example, are those repeated "global" statements really
> necessary?
>
> cu
> Michael
I have basically zero knowledge of openocd, but I know Tcl :-)
My comments below.
>
>
>
> From 6da9b215b386714a61472665c642f31f726a6b37 Mon Sep 17 00:00:00 2001
> From: Michael Schwingen
> Date: Thu, 16 Dec 2010 23:48:12 +0100
> Subject: [PATCH] update IXP42x target / XBA board config
>
> ---
> tcl/board/actux3.cfg | 48 +++
> tcl/target/ixp42x.cfg| 96 ++
> tcl/target/xba_revA3.cfg | 88 --
> 3 files changed, 136 insertions(+), 96 deletions(-)
> create mode 100644 tcl/board/actux3.cfg
> delete mode 100644 tcl/target/xba_revA3.cfg
>
> diff --git a/tcl/board/actux3.cfg b/tcl/board/actux3.cfg
> new file mode 100644
> index 000..efdd702
> --- /dev/null
> +++ b/tcl/board/actux3.cfg
> @@ -0,0 +1,48 @@
> +# board config file for AcTux3/XBA IXP42x board
> +# Date: 2010-12-16
> +# Author: Michael Schwingen
> +
> +reset_config trst_and_srst separate
> +
> +adapter_nsrst_delay 100
> +jtag_ntrst_delay 100
> +
> +source [find target/ixp42x.cfg]
> +
> +$_TARGETNAME configure -work-area-phys 0x0002 -work-area-size 0x1
> -work-area-backup 0
> +
> +$_TARGETNAME configure -event reset-init { init_actux3 }
> +
> +proc init_actux3 { } {
> +
> ##
> +# setup expansion bus CS
> +
> ##
> +mww 0xc400 0xbd113842 #CS0 : Flash, write enabled @0x5000
> +mww 0xc404 0x94d10013 #CS1
> +mww 0xc408 0x95960003 #CS2
> +mww 0xc40c 0x #CS3
> +mww 0xc410 0x8093 #CS4
> +mww 0xc414 0x9d520003 #CS5
> +mww 0xc418 0x81860001 #CS6
> +mww 0xc41c 0x8093 #CS7
Tcl only recognises comments at the beginning of a command, so "#CS0" etc.
will be passed to the command. However I note that other config files do this
too, and I'm sure you've tried this, so there may be some "magic" in the openocd
command handling which allows this. Normally you would need to write ";#CS0..."
> +
> +global IXP42x_SDRAM_64MB_16Mx16_1BANK
> +ixp42x_init_sdram $IXP42x_SDRAM_64MB_16Mx16_1BANK 2100 3
You could do this one line instead:
+ixp42x_init_sdram $::IXP42x_SDRAM_64MB_16Mx16_1BANK 2100 3
> +
> +#mww 0xc420 0xee # CFG0: remove expansion bus boot flash mirror
> at 0x
> +
> +ixp42x_set_bigendian
> +
> +flash probe 0
> +}
> +
> +proc flash_boot { {FILE "/tftpboot/actux3/u-boot.bin"} } {
> +echo [format "writing bootloader: %s" $FILE ]
No need for format here. Just:
+echo "writing bootloader: $FILE"
> +flash write_image erase $FILE 0x5000 bin
> +}
> +
> +set _FLASHNAME $_CHIPNAME.flash
> +flash bank $_FLASHNAME cfi 0x5000 0x40 2 2 $_TARGETNAME
> +
> +init
> +reset init
> diff --git a/tcl/target/ixp42x.cfg b/tcl/target/ixp42x.cfg
> index 6d2ecb7..9dcaca5 100644
> --- a/tcl/target/ixp42x.cfg
> +++ b/tcl/target/ixp42x.cfg
> @@ -1,6 +1,5 @@
> #xscale ixp42x CPU
>
> -
> if { [info exists CHIPNAME] } {
>set _CHIPNAME $CHIPNAME
> } else {
> @@ -17,16 +16,97 @@ if { [info exists ENDIAN] } {
> if { [info exists CPUTAPID ] } {
>set _CPUTAPID $CPUTAPID
> } else {
> - # force an error till we get a good number
> - set _CPUTAPID 0x
> + set _CPUTAPID 0x19274013
> }
> +set _CPUTAPID2 0x19275013
> +set _CPUTAPID3 0x19277013
> +set _CPUTAPID4 0x29274013
> +set _CPUTAPID5 0x29275013
> +set _CPUTAPID6 0x29277013
>
> -#use combined on interfaces or targets that can?t set TRST/SRST separately
> -reset_config srst_only srst_pulls_trst
> -#jtag scan chain
> -
> -jtag newtap $_CHIPNAME cpu -irlen 7 -ircapture 0x1 -irmask 0x7f -expected-id
> $_CPUTAPID
> +jtag newtap $_CHIPNAME cpu -irlen 7 -ircapture 0x1 -irmask 0x7f -expected-id
> $_CPUTAPID -expected-id $_CPUTAPID2 -expected-id $_CPUTAPID3 -expected-id
> $_CPUTAPID4 -expected-id $_CPUTAPID5 -expected-id $_CPUTAPID6
>
> set _TARGETNAME $_CHIPNAME.cpu
> target create $_TARGETNAME xscale -endian $_ENDIAN -chain-position
> $_TARGETNAME -variant ixp42x
>
I suspect you can omit all of the global statements below here.
I think this script is already being evaluated at global scope.
> +
> +# register constan
Re: [Openocd-development] making the target scripts a bit less verbose
On 17/12/2010, at 4:11 PM, Øyvind Harboe wrote:
> On Fri, Dec 17, 2010 at 7:06 AM, Peter Stuge wrote:
>> Øyvind Harboe wrote:
>>> Which is better? (whatever "better" is)
>>>
>>> This:
>>>
>>> if {[info exists CHIPNAME]} {
>>>set _CHIPNAME $CHIPNAME
>>> } else {
>>>set _CHIPNAME at91r40008
>>> }
>>
>> All these blocks in the target files have really annoyed me.
>>
>>
>>> or this:
>>>
>>> set _CHIPNAME [defaultval $CHIPNAME at91r40008]
>>
>> Significantly better.
>
> It's trivial to do something shorter, like:
>
> defaultval CHIPNAME at91r40008
Yes, definitely better.
>
> The advantage of the more verbose syntax is that it
> is more self documenting:
>
> set _CHIPNAME [defaultval $CHIPNAME at91r40008]
In this example, you would need this to be:
set _CHIPNAME [defaultval CHIPNAME at91r40008]
There are a lot of areas where the Tcl API could be improved in
openocd config files.
Your load_target is just another example of this.
>
> Any preference?
>
> --
> Øyvind Harboe
>
> Can Zylin Consulting help on your project?
>
> US toll free 1-866-980-3434 / International +47 51 63 25 00
>
> http://www.zylin.com/zy1000.html
> ARM7 ARM9 ARM11 XScale Cortex
> JTAG debugger and flash programmer
> ___
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
--
µWeb: Embedded Web Framework - http://uweb.workware.net.au/
WorkWare Systems Pty Ltd
W: www.workware.net.au P: 0434 921 300
E: ste...@workware.net.au F: 07 3102 9221
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Aborted; stm32 with too high clock
On 14/12/2010, at 5:50 AM, Domen Puncer wrote:
> On Mon, Dec 13, 2010 at 20:32, Steve Bennett wrote:
>> On 13/12/2010, at 11:00 PM, Domen Puncer wrote:
>>
>>> On Mon, Dec 13, 2010 at 12:47, Steve Bennett wrote:
>>>>
>>>> Can we see the code being evaluated here?
>>>>> ==32465==by 0x4B6DB2: Jim_Eval_Named (jim.c:9644)
>>>>
>>>
>>> 9643 else {
>>> 9644 retval = Jim_EvalObj(interp, scriptObjPtr);
>>> 9645 }
>>> 9646 Jim_DecrRefCount(interp, scriptObjPtr);
>>> 9647 return retval;
>>> 9648 }
>>
>> Sorry, I meant the Tcl script that is being evaluated at that point.
>
> Oh, I don't know.
> How do I find out?
> It was after "verify_image" and "reset init" commands executed with
> too high clock (so there were some errors printed, as mentioned in
> original post).
Never mind. I see this in target.c:
sprintf(buf, "ocd_process_reset %s", n->name);
retval = Jim_Eval(cmd_ctx->interp, buf);
So it is executing a pretty simple script.
Is there any chance you can build just jim.c with '-g -O0' and rerun with
valgrind?
>
>
> --
> Domen
>
--
µWeb: Embedded Web Framework - http://uweb.workware.net.au/
WorkWare Systems Pty Ltd
W: www.workware.net.au P: 0434 921 300
E: ste...@workware.net.au F: 07 3102 9221
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Aborted; stm32 with too high clock
On 13/12/2010, at 11:00 PM, Domen Puncer wrote:
> On Mon, Dec 13, 2010 at 12:47, Steve Bennett wrote:
>>
>> On 13/12/2010, at 8:12 PM, Domen Puncer wrote:
>>>
>>> but code only allocates space for extra len-1 objects.
>>
>> There is already one "slot" allocated for the arg. If the arg expands to
>> 'len'
>> elements, we only need to allocate 'len-1' more.
>
> OK then, just seemed fishy.
>
>>
>> Can we see the code being evaluated here?
>>> ==32465==by 0x4B6DB2: Jim_Eval_Named (jim.c:9644)
>>
>
> 9643 else {
> 9644 retval = Jim_EvalObj(interp, scriptObjPtr);
> 9645 }
> 9646 Jim_DecrRefCount(interp, scriptObjPtr);
> 9647 return retval;
> 9648 }
Sorry, I meant the Tcl script that is being evaluated at that point.
>
>
> And the error happens (as the previous gdb backtrace shows) in
> Jim_Free, almost at the end of Jim_EvalObj:
>
>if (argv != sargv) {
>Jim_Free(argv);
>argv = sargv;
>}
>
> --
> Domen
>
--
µWeb: Embedded Web Framework - http://uweb.workware.net.au/
WorkWare Systems Pty Ltd
W: www.workware.net.au P: 0434 921 300
E: ste...@workware.net.au F: 07 3102 9221
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Aborted; stm32 with too high clock
On 13/12/2010, at 8:12 PM, Domen Puncer wrote:
> On Thu, Nov 25, 2010 at 15:45, Domen Puncer wrote:
>> I can reliably reproduce this one with:
>> jtag_khz 1000
>> verify_image my_image.elf
>> # some prints about too high clock
>> reset init
>> # openocd aborts
>
> Additional info.
>
> valgrind:
> ==32465== Invalid free() / delete / delete[]
> ==32465==at 0x4C270BD: free (vg_replace_malloc.c:366)
> ==32465==by 0x4B4CD9: Jim_EvalObj (jim.c:527)
> ==32465==by 0x4B6DB2: Jim_Eval_Named (jim.c:9644)
> ==32465==by 0x424AA4: handle_reset_command (target.c:505)
> ==32465==by 0x42F448: script_command_run (command.c:627)
> ==32465==by 0x4B4E30: Jim_EvalObj (jim.c:9398)
> ==32465==by 0x4B60E8: Jim_EvalCoreCommand (jim.c:11557)
> ==32465==by 0x4B4E30: Jim_EvalObj (jim.c:9398)
> ==32465==by 0x4B83CC: Jim_CatchCoreCommand (jim.c:12372)
> ==32465==by 0x4B4E30: Jim_EvalObj (jim.c:9398)
> ==32465==by 0x4B6F8B: Jim_EvalExpression (jim.c:8227)
> ==32465==by 0x4B7482: Jim_GetBoolFromExpr (jim.c:8269)
> ==32465== Address 0x7feffeb00 is on thread 1's stack
> ==32465==
>
> And it's really bugging me, because I can't figure out where exactly.
>
> It disappears if I configure jimtcl with ./configure CFLAGS=-g, also
> disappeared when I inserted some printfs in Jim_EvalObj.
>
> I do have some questions about some code:
> 1.
> In jim.c Jim_EvalObj there's a loop:
>
>/* Now copy in the expanded version */
>for (k = 0; k < len; k++) {
>argv[j++] = wordObjPtr->internalRep.listValue.ele[k];
>Jim_IncrRefCount(wordObjPtr->internalRep.listValue.ele[k]);
>}
>
> but code only allocates space for extra len-1 objects.
There is already one "slot" allocated for the arg. If the arg expands to 'len'
elements, we only need to allocate 'len-1' more.
Can we see the code being evaluated here?
> ==32465==by 0x4B6DB2: Jim_Eval_Named (jim.c:9644)
Cheers,
Steve
>
>
> 2.
> src/target/target.c:
> In handle_reg_command, there is:
> /* display a register */
> if ((CMD_ARGC == 1) || ((CMD_ARGC == 2) && !((CMD_ARGV[1][0] >= '0')
> && (CMD_ARGV[1][0] <= '9'
>
> it seems to be that should be written as:
> if ((CMD_ARGC == 1) || ((CMD_ARGC == 2) && !((CMD_ARGV[0][0] >= '0')
> && (CMD_ARGV[0][0] <= '9'
> ___
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
>
--
µWeb: Embedded Web Framework - http://uweb.workware.net.au/
WorkWare Systems Pty Ltd
W: www.workware.net.au P: 0434 921 300
E: ste...@workware.net.au F: 07 3102 9221
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jimtcl build on freebsd
On 05/12/2010, at 11:36 PM, 1 0 wrote: > Hello, > > I gotta problem with building GIT version of OpenOCD on my FreeBSD box > - there is some error with JimTcl and tclsh (should come from > jimtcl?): > > tclsh .././jimtcl/parse-unidata.tcl .././jimtcl/UnicodeData.txt >> unicode_mapping.c > tclsh: not found > > Here is the full build output: http://pastebin.com/cN1rPNcp > > # whereis tclsh > tclsh: > > Please advise, tclsh is used during building. jimsh isn't used because of the chicken-and-egg problem. Actually, in the normal case it isn't even needed. You could replace 'tclsh' with 'echo' as a workaround if you don't want to install Tcl. In any case, I've pushed a fix to the Jim Tcl git repository. Cheers, Steve > > -- > 0110001101100100 > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset halt segfault on Mac OS X
On 01/12/2010, at 2:42 PM, Piotr Esden-Tempski wrote: > Hi ho, > > On Nov 30, 2010, at 2:31 PM, Steve Bennett wrote: > >> On 01/12/2010, at 7:44 AM, Piotr Esden-Tempski wrote: >> >>> >>> On Nov 30, 2010, at 1:04 PM, Piotr Esden-Tempski wrote: >>>> On Nov 30, 2010, at 12:03 PM, Steve Bennett wrote: >>>> >>>>> On 01/12/2010, at 12:12 AM, Edgar Grimberg wrote: >>>>> >>>>>> On Tue, Nov 30, 2010 at 1:02 PM, Øyvind Harboe >>>>>> wrote: >>>>>>> 32 vs. 64 bit problem? >>>>>> >>>>>> Wouldn't that be interesting? :) >>>>>> Are there Linux 64 users out there that can try it out? >>>>> >>>>> I note that Domen Puncer is having a similar problem. >>>>> Also looks like 64 bit from the stack trace. >>>>> >>>>> Piotr, can you try building 32 bit? >>>>> Something like: >>>>> >>>>> ./configure ... CFLAGS="-arch i386 -O0 -g" >>>> >>>> >>>> Yes sir! I just tested the newest version in git of oocd with -m32 on Mac >>>> OS X Snow leopard and it does NOT crash. So it is definitely a 64 bit >>>> problem here. >>>> >>>> Thanks for pointing that out! >>>> >>>> I will try to find a 64bit linux machine and see if I get the same error >>>> there. (maybe also someone else can take a stab at it?) >>> >>> Ok I just tested on 64bit ubuntu linux machine. And "sadly" it works there. >>> :( So the only way to trigger the segfault currently is running 64 bit >>> openocd binary on Snow Leopard. :( >> >> Are you able to run under valgrind on 64bit linux and mac? >> Could be the problem is still there but doesn't show up. >> >> Also, on mac, do you have an installed version of Jim (e.g. >> /usr/local/include/jim-config.h)? >> I wonder if it could be conflicting... Excellent debugging! > > Here we go. :) > > I cleaned up truthfully after every build. (stow helps :) ) So dangling > jim-config.h was not present. Good. > > I generated two valgrind outputs, one for the failing Mac OS 64 bit version > and the working Linux 64bit version. I was unable to run valgrind on the Mac > OS 32bit binary though because valgrind refuses doing that being 64bit itself > and me being too lazy to fight with it too much. (I may try to fight with it > at a later time but... well) :) > > So attached you find the two valgrind outputs. > > So beside the fact that on Mac OS libusb seems to behave bit erratically and > on linux Yes. This is a known problem. > Jim seems to be having fun leaking memory (but maybe that is just the charm > of every interpreter in general :) ) No, that is a real memory leak in Jim. Thanks for finding that one. Will be fixed shortly. > what is drawing my attention is buf_set_buf. This function seems to be > copying bit by bit data from the jtag buffer to the output as far as I > understand. I don't know the implications of it but it is copying data into > the buffer created by jtag_build_buffer that is assuming some alignment of > memory things and the bit by bit copy code is probably also assuming things. > I did not have much time to look into that code but what I found so far is > that linux malloc does not assure memory alignment. The Mac OS API assures > double word 16byte memory alignment in the darwin malloc returns. I am again > not sure what that means to the openocd code but maybe there is something > wrong with these assumptions? ... Definitely that needs more investigation. I'm not sure. Could be just that ft2232_read_scan() isn't filling the whole buffer. Although the buffer was allocated with calloc() so it should be initialised to 0. Perhaps someone more knowledgeable could look at that. Possibly defining _DEBUG_JTAG_IO_ would help. > > Maybe you guys have some new ideas where to poke next. I will continue poking > as time permits. But as I can compile using -m32 my efforts may slow down a > little. :) If the above isn't the problem, there could be problems around command_unknown() interp->cmdPrivData = c->jim_handler_data; return (*c->jim_handler)(interp, count, start); Setting cmdPrivData explicitly is probably not a good idea. I'm concerned that there is some 32/64 bit alignment issue or truncation happening somewhere in there. Not sure yet. The way openocd interfaces with jim is a bit convoluted. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset halt segfault on Mac OS X
On 01/12/2010, at 7:44 AM, Piotr Esden-Tempski wrote: > > On Nov 30, 2010, at 1:04 PM, Piotr Esden-Tempski wrote: >> On Nov 30, 2010, at 12:03 PM, Steve Bennett wrote: >> >>> On 01/12/2010, at 12:12 AM, Edgar Grimberg wrote: >>> >>>> On Tue, Nov 30, 2010 at 1:02 PM, Øyvind Harboe >>>> wrote: >>>>> 32 vs. 64 bit problem? >>>> >>>> Wouldn't that be interesting? :) >>>> Are there Linux 64 users out there that can try it out? >>> >>> I note that Domen Puncer is having a similar problem. >>> Also looks like 64 bit from the stack trace. >>> >>> Piotr, can you try building 32 bit? >>> Something like: >>> >>> ./configure ... CFLAGS="-arch i386 -O0 -g" >> >> >> Yes sir! I just tested the newest version in git of oocd with -m32 on Mac OS >> X Snow leopard and it does NOT crash. So it is definitely a 64 bit problem >> here. >> >> Thanks for pointing that out! >> >> I will try to find a 64bit linux machine and see if I get the same error >> there. (maybe also someone else can take a stab at it?) > > Ok I just tested on 64bit ubuntu linux machine. And "sadly" it works there. > :( So the only way to trigger the segfault currently is running 64 bit > openocd binary on Snow Leopard. :( Are you able to run under valgrind on 64bit linux and mac? Could be the problem is still there but doesn't show up. Also, on mac, do you have an installed version of Jim (e.g. /usr/local/include/jim-config.h)? I wonder if it could be conflicting... -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset halt segfault on Mac OS X
On 01/12/2010, at 7:04 AM, Piotr Esden-Tempski wrote: > Hi, > > On Nov 30, 2010, at 12:03 PM, Steve Bennett wrote: > >> On 01/12/2010, at 12:12 AM, Edgar Grimberg wrote: >> >>> On Tue, Nov 30, 2010 at 1:02 PM, Øyvind Harboe >>> wrote: >>>> 32 vs. 64 bit problem? >>> >>> Wouldn't that be interesting? :) >>> Are there Linux 64 users out there that can try it out? >> >> I note that Domen Puncer is having a similar problem. >> Also looks like 64 bit from the stack trace. >> >> Piotr, can you try building 32 bit? >> Something like: >> >> ./configure ... CFLAGS="-arch i386 -O0 -g" > > > Yes sir! I just tested the newest version in git of oocd with -m32 on Mac OS > X Snow leopard and it does NOT crash. So it is definitely a 64 bit problem > here. Great. That's a start. Now to work out what the problem is on 64bit. > > Thanks for pointing that out! > > I will try to find a 64bit linux machine and see if I get the same error > there. (maybe also someone else can take a stab at it?) > > Cheers Esden > > -- > Blog: http://www.esden.net > Projects: > http://open-bldc.org > http://paparazziuav.org > http://github.org/esden/floss-jtag > http://github.org/esden/summon-arm-toolchain > > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset halt segfault on Mac OS X
On 01/12/2010, at 12:12 AM, Edgar Grimberg wrote: > On Tue, Nov 30, 2010 at 1:02 PM, Øyvind Harboe > wrote: >> 32 vs. 64 bit problem? > > Wouldn't that be interesting? :) > Are there Linux 64 users out there that can try it out? I note that Domen Puncer is having a similar problem. Also looks like 64 bit from the stack trace. Piotr, can you try building 32 bit? Something like: ./configure ... CFLAGS="-arch i386 -O0 -g" -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Config file format/line endings
On 17/11/2010, at 2:32 PM, Andrew Leech wrote: > On Wed, Nov 17, 2010 at 8:05 AM, Steve Bennett wrote: >> On 16/11/2010, at 11:36 AM, Andrew Leech wrote: >> >>> On Tue, Nov 16, 2010 at 12:19 PM, Steve Bennett >>> wrote: >>>> >>>> On 16/11/2010, at 11:15 AM, Øyvind Harboe wrote: >>>> >>>>> On Tue, Nov 16, 2010 at 2:06 AM, Steve Bennett >>>>> wrote: >>>>>> On 16/11/2010, at 9:27 AM, Andrew Leech wrote: >>>>>> >>>>>>> Hi all, >>>>>>> I've just found a compiling/usage difficulty with the git version on >>>>>>> cygwin. Apparently somewhere between 0.4.0 and mainline (possibly >>>>>>> jimtcl?) openocd no longer handles dos line endings on config files. >>>>>>> Apparently all my config files of my existing 0.4.0 installation have >>>>>>> dos line endings and I'd never realised or cared, but I compiled git >>>>>>> on cygwin and tried to use it with my existing openocd.cfg and was >>>>>>> treated to this error: >>>>>>> > > > >> >> Perhaps you could try the attached patch to Jim Tcl. It should >> allow for cfg files with dos line endings. >> >> > < 0001--source-now-opens-the-script-file-in-text-mode.patch > > > This patch works for me, openocd.exe now works with new config files > (unix line endings) and my old ones (dos line endings). Great. I've applied this in the latest version of Jim Tcl. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Config file format/line endings
On 16/11/2010, at 11:36 AM, Andrew Leech wrote: > On Tue, Nov 16, 2010 at 12:19 PM, Steve Bennett > wrote: >> >> On 16/11/2010, at 11:15 AM, Øyvind Harboe wrote: >> >>> On Tue, Nov 16, 2010 at 2:06 AM, Steve Bennett >>> wrote: >>>> On 16/11/2010, at 9:27 AM, Andrew Leech wrote: >>>> >>>>> Hi all, >>>>> I've just found a compiling/usage difficulty with the git version on >>>>> cygwin. Apparently somewhere between 0.4.0 and mainline (possibly >>>>> jimtcl?) openocd no longer handles dos line endings on config files. >>>>> Apparently all my config files of my existing 0.4.0 installation have >>>>> dos line endings and I'd never realised or cared, but I compiled git >>>>> on cygwin and tried to use it with my existing openocd.cfg and was >>>>> treated to this error: >>>>> >>>>> Open On-Chip Debugger 0.5.0-dev-00589-gfdae512-dirty (2010-11-16-10:00) >>>>> Licensed under GNU GPL v2 >>>>> For bug reports, read >>>>>http://openocd.berlios.de/doc/doxygen/bugs.html >>>>> Runtime Error: embedded:startup.tcl:57: >>>>> in procedure 'script' >>>>> at file "embedded:startup.tcl", line 57 >>>>> >>>>> This is a very un-user-friendly error message and had me stumped, I >>>>> though my build was broken or something. It took me a lot of stuffing >>>>> around with config files to realise it was just a dos2unix on my >>>>> config file away from working, and now I'm all good. >>>>> I personally don't have an issue with requiring unix line endings, >>>>> it's just that this is a nasty way to fail, a cleaner error message >>>>> would have been useful. >>>> >>>> I suspect the problem is here in src/helper/startup.tcl >>>> >>>>set errmsg [format "%s: command requires more arguments" \ >>>>[concat $name " " $args]] >>>> >>>> The backslash newline sequence will likely have a carriage return inserted. >>>> The easy solution is to ensure that these startup files are read in text >>>> mode >>>> or have the \r\n translated to \n before creating startup_tcl.c >>>> >>>> But it would also be nice if each startup script were evaluated >>>> independently >>>> with the original filename, and any error message shown. >>> >>> A large startup.tcl is generated by the makefiles from many smaller >>> startup.tcl scripts around the source tree. This startup.tcl is then >>> converted >>> to .c and linked into openocd. Why? Because it was felt that it was an >>> important >>> feature to be able to launch openocd without a dependency on the files that >>> openocd ships with. >> >> Nothing wrong with that. Jim Tcl does something similar to allow Tcl >> extensions >> to be linked in. For example, stdlib.tcl, tclcompat.tcl and glob.tcl >> >> The trick is to invoke Jim_Eval_Named() once for each file so that the >> original >> source file can be identified, and also to display any error which is >> generated. >> > > I don't know that the line ending problem is with (the compiled in) > startup.tcl. I only did the dos2unix on my openocd.cfg and associated > cfg text files, and then they worked fine with the same openocd > binary. > > Is openocd supposed to still work with dos format .cfg files? > > Andrew Perhaps you could try the attached patch to Jim Tcl. It should allow for cfg files with dos line endings. -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 0001--source-now-opens-the-script-file-in-text-mode.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Config file format/line endings
On 16/11/2010, at 11:36 AM, Andrew Leech wrote: > On Tue, Nov 16, 2010 at 12:19 PM, Steve Bennett > wrote: >> >> On 16/11/2010, at 11:15 AM, Øyvind Harboe wrote: >> >>> On Tue, Nov 16, 2010 at 2:06 AM, Steve Bennett >>> wrote: >>>> On 16/11/2010, at 9:27 AM, Andrew Leech wrote: >>>> >>>>> Hi all, >>>>> I've just found a compiling/usage difficulty with the git version on >>>>> cygwin. Apparently somewhere between 0.4.0 and mainline (possibly >>>>> jimtcl?) openocd no longer handles dos line endings on config files. >>>>> Apparently all my config files of my existing 0.4.0 installation have >>>>> dos line endings and I'd never realised or cared, but I compiled git >>>>> on cygwin and tried to use it with my existing openocd.cfg and was >>>>> treated to this error: >>>>> >>>>> Open On-Chip Debugger 0.5.0-dev-00589-gfdae512-dirty (2010-11-16-10:00) >>>>> Licensed under GNU GPL v2 >>>>> For bug reports, read >>>>>http://openocd.berlios.de/doc/doxygen/bugs.html >>>>> Runtime Error: embedded:startup.tcl:57: >>>>> in procedure 'script' >>>>> at file "embedded:startup.tcl", line 57 >>>>> >>>>> This is a very un-user-friendly error message and had me stumped, I >>>>> though my build was broken or something. It took me a lot of stuffing >>>>> around with config files to realise it was just a dos2unix on my >>>>> config file away from working, and now I'm all good. >>>>> I personally don't have an issue with requiring unix line endings, >>>>> it's just that this is a nasty way to fail, a cleaner error message >>>>> would have been useful. >>>> >>>> I suspect the problem is here in src/helper/startup.tcl >>>> >>>>set errmsg [format "%s: command requires more arguments" \ >>>>[concat $name " " $args]] >>>> >>>> The backslash newline sequence will likely have a carriage return inserted. >>>> The easy solution is to ensure that these startup files are read in text >>>> mode >>>> or have the \r\n translated to \n before creating startup_tcl.c >>>> >>>> But it would also be nice if each startup script were evaluated >>>> independently >>>> with the original filename, and any error message shown. >>> >>> A large startup.tcl is generated by the makefiles from many smaller >>> startup.tcl scripts around the source tree. This startup.tcl is then >>> converted >>> to .c and linked into openocd. Why? Because it was felt that it was an >>> important >>> feature to be able to launch openocd without a dependency on the files that >>> openocd ships with. >> >> Nothing wrong with that. Jim Tcl does something similar to allow Tcl >> extensions >> to be linked in. For example, stdlib.tcl, tclcompat.tcl and glob.tcl >> >> The trick is to invoke Jim_Eval_Named() once for each file so that the >> original >> source file can be identified, and also to display any error which is >> generated. >> > > I don't know that the line ending problem is with (the compiled in) > startup.tcl. I only did the dos2unix on my openocd.cfg and associated > cfg text files, and then they worked fine with the same openocd > binary. > > Is openocd supposed to still work with dos format .cfg files? Interesting. There hasn't been any change in Jim Tcl in this respect. I'm surprised it ever worked. Isn't there a global setting in cygwin for whether files are opened in binary mode or text mode by default? > > Andrew > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Config file format/line endings
On 16/11/2010, at 11:15 AM, Øyvind Harboe wrote: > On Tue, Nov 16, 2010 at 2:06 AM, Steve Bennett wrote: >> On 16/11/2010, at 9:27 AM, Andrew Leech wrote: >> >>> Hi all, >>> I've just found a compiling/usage difficulty with the git version on >>> cygwin. Apparently somewhere between 0.4.0 and mainline (possibly >>> jimtcl?) openocd no longer handles dos line endings on config files. >>> Apparently all my config files of my existing 0.4.0 installation have >>> dos line endings and I'd never realised or cared, but I compiled git >>> on cygwin and tried to use it with my existing openocd.cfg and was >>> treated to this error: >>> >>> Open On-Chip Debugger 0.5.0-dev-00589-gfdae512-dirty (2010-11-16-10:00) >>> Licensed under GNU GPL v2 >>> For bug reports, read >>>http://openocd.berlios.de/doc/doxygen/bugs.html >>> Runtime Error: embedded:startup.tcl:57: >>> in procedure 'script' >>> at file "embedded:startup.tcl", line 57 >>> >>> This is a very un-user-friendly error message and had me stumped, I >>> though my build was broken or something. It took me a lot of stuffing >>> around with config files to realise it was just a dos2unix on my >>> config file away from working, and now I'm all good. >>> I personally don't have an issue with requiring unix line endings, >>> it's just that this is a nasty way to fail, a cleaner error message >>> would have been useful. >> >> I suspect the problem is here in src/helper/startup.tcl >> >>set errmsg [format "%s: command requires more arguments" \ >>[concat $name " " $args]] >> >> The backslash newline sequence will likely have a carriage return inserted. >> The easy solution is to ensure that these startup files are read in text mode >> or have the \r\n translated to \n before creating startup_tcl.c >> >> But it would also be nice if each startup script were evaluated independently >> with the original filename, and any error message shown. > > A large startup.tcl is generated by the makefiles from many smaller > startup.tcl scripts around the source tree. This startup.tcl is then converted > to .c and linked into openocd. Why? Because it was felt that it was an > important > feature to be able to launch openocd without a dependency on the files that > openocd ships with. Nothing wrong with that. Jim Tcl does something similar to allow Tcl extensions to be linked in. For example, stdlib.tcl, tclcompat.tcl and glob.tcl The trick is to invoke Jim_Eval_Named() once for each file so that the original source file can be identified, and also to display any error which is generated. -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Config file format/line endings
On 16/11/2010, at 9:27 AM, Andrew Leech wrote: > Hi all, > I've just found a compiling/usage difficulty with the git version on > cygwin. Apparently somewhere between 0.4.0 and mainline (possibly > jimtcl?) openocd no longer handles dos line endings on config files. > Apparently all my config files of my existing 0.4.0 installation have > dos line endings and I'd never realised or cared, but I compiled git > on cygwin and tried to use it with my existing openocd.cfg and was > treated to this error: > > Open On-Chip Debugger 0.5.0-dev-00589-gfdae512-dirty (2010-11-16-10:00) > Licensed under GNU GPL v2 > For bug reports, read >http://openocd.berlios.de/doc/doxygen/bugs.html > Runtime Error: embedded:startup.tcl:57: > in procedure 'script' > at file "embedded:startup.tcl", line 57 > > This is a very un-user-friendly error message and had me stumped, I > though my build was broken or something. It took me a lot of stuffing > around with config files to realise it was just a dos2unix on my > config file away from working, and now I'm all good. > I personally don't have an issue with requiring unix line endings, > it's just that this is a nasty way to fail, a cleaner error message > would have been useful. I suspect the problem is here in src/helper/startup.tcl set errmsg [format "%s: command requires more arguments" \ [concat $name " " $args]] The backslash newline sequence will likely have a carriage return inserted. The easy solution is to ensure that these startup files are read in text mode or have the \r\n translated to \n before creating startup_tcl.c But it would also be nice if each startup script were evaluated independently with the original filename, and any error message shown. > > Cheers, > Andrew > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Build inline jimtcl
On 16/11/2010, at 6:05 AM, Spencer Oliver wrote: >> >> This looks like it is heading in the right direction. >> >>> >>> As mentioned above we are currently adding a hack so jimtcl builds inline - >>> this is fine for the standard configure/make case. >> >> Can you explain why you needed -DHAVE_NO_AUTOCONF? >> I tried with the latest version of jimtcl and it didn't need this. >> > > This is only required when using jim inline. > If using an external lib then all is ok, it is due to multiple defines: > It seesm due to the inclustion of jimautoconf.h from jim.h:94 > > In file included from ../../../openocd/jimtcl/jim.h:94, > [snip] > I have not tried jim git head - onlt the version that is linked to openocd > 0.63 As I suspected. This is fixed in: http://repo.or.cz/w/jimtcl.git/commit/5a9c9cdc1a0add1d0e6e63e64d5d7d7febc6d749 Please try at least this version and you can get rid of -DHAVE_NO_AUTOCONF which could lead to problems with 32 vs 64 bit integers on some platforms. > >>> >>> Running a few other tests shows that to use jimtcl inline the jimtcl build >>> system will need other updates to function as per openocd. >>> For example make dist/distcheck will fail as jimtcl does not support the >>> std autotools options. >> >> Tell me what you need these targets to do. >> > > i have noticed that jim only really uses autoconf, but does not use automake. > OpenOCD uses both and so expects the standard make targets, eg: > http://www.gnu.org/software/automake/manual/html_node/Third_002dParty-Makefiles.html#Third_002dParty-Makefiles > > we can work around this many ways depending on how much/little work you fancy > doing :) I won't use automake, but I can probably add all of these targets to be compatible. Most of them are likely to be nops. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Build inline jimtcl
On 13/11/2010, at 1:13 AM, Spencer Oliver wrote: > On 12/11/2010 14:31, Spencer Oliver wrote: >> Hi, >> >> Started a new thread as the others are getting bogged down. >> >> This defaults to building the jimtcl inline - only one configure step >> required, eg. >> ./configure --enable-maintainer-mode --with-jim-ext=nvp ... >> >> The only limitation is that we have to pass the jim options through >> openocd. autoconf currently does not allow project specific subconfigure >> options - this is being looked at. >> I have also added a temp hack so we do not get warnings due to the jim >> headers - this will need looking at. This looks like it is heading in the right direction. > > As mentioned above we are currently adding a hack so jimtcl builds inline - > this is fine for the standard configure/make case. Can you explain why you needed -DHAVE_NO_AUTOCONF? I tried with the latest version of jimtcl and it didn't need this. > > Running a few other tests shows that to use jimtcl inline the jimtcl build > system will need other updates to function as per openocd. > For example make dist/distcheck will fail as jimtcl does not support the std > autotools options. Tell me what you need these targets to do. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] How 2 build with new Jim???
On 12/11/2010, at 8:34 AM, Peter Stuge wrote: > Øyvind Harboe wrote: >> By default OpenOCD should build the Jim Tcl submodule >> automatically, but there should be an option to use the >> installed Jim Tcl. > > I disagree strongly with this. > > Moving Jim out into a separate package means that it should also be > treated as a separate package. (Which it is, so it makes perfect sense!) > [snip lots of detail about building] I think all this misses the point that *right now* people are trying to build openocd from git and failing. This means there is a problem which needs to be fixed. I don't think telling people to go create (.e.g.) cygwin projects to solve their problem is going to be popular. -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Simplify build with new jimtcl
On 11/11/2010, at 6:48 AM, Spencer Oliver wrote: > On 09/11/2010 07:13, Steve Bennett wrote: >> >> On 09/11/2010, at 5:10 PM, Øyvind Harboe wrote: >> >>> On Tue, Nov 9, 2010 at 8:08 AM, Steve Bennett >>> wrote: >>>> >>>> On 09/11/2010, at 4:59 PM, Øyvind Harboe wrote: >>>> >>>>> Why is " -I$(top_srcdir)/jimtcl \", that doesn't seem right. >>>>> >>>>> Shouldn't it be only the build dir? >>>> >>>> I modelled it on what was already there: >>>> >>>>-I$(top_srcdir)/src \ >>>>-I$(top_builddir)/src >>>> >>>> If you build out of tree, you will need both the static headers >>>> and the generated headers. >>> >>> Riiighhht. So this is a very different code path altogether than >>> installing >>> >>> The installation step never happens. I thought the installation step >>> happened, but that it was installed somewhere in the build folder... >> >> Correct >> > > Just as a comment may be worth adding a common.mk for standard includes etc. > Started a similar patch but not found time to work on it. > > This makes adding directory specific includes much simpler, eg. > http://repo.or.cz/w/openocd/ntfreak.git/commitdiff/04734c8d0dfcca040c8376a83bf58d9e2826a73f I agree. This is definitely the way to go. > > Cheers > Spen > -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Simplify build with new jimtcl
On 09/11/2010, at 5:10 PM, Øyvind Harboe wrote: > On Tue, Nov 9, 2010 at 8:08 AM, Steve Bennett wrote: >> >> On 09/11/2010, at 4:59 PM, Øyvind Harboe wrote: >> >>> Why is " -I$(top_srcdir)/jimtcl \", that doesn't seem right. >>> >>> Shouldn't it be only the build dir? >> >> I modelled it on what was already there: >> >>-I$(top_srcdir)/src \ >>-I$(top_builddir)/src >> >> If you build out of tree, you will need both the static headers >> and the generated headers. > > Riiighhht. So this is a very different code path altogether than > installing > > The installation step never happens. I thought the installation step > happened, but that it was installed somewhere in the build folder... Correct -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Build improvements with new Jim Tcl
On 09/11/2010, at 5:02 PM, Øyvind Harboe wrote: > On Tue, Nov 9, 2010 at 12:07 AM, Steve Bennett wrote: >> 1. The current openocd doesn't build on cygwin >> 2. The multi-step configure/install/build is inconvenient. >> >> The attached patch addresses these by configuring, building >> and using jimtcl in-place. >> >> Note that it should still be possible to use an installed jimtcl >> if required by overriding CPPFLAGS and LDFLAGS but I >> haven't tried it. > > Would that be robust? What if there is a file in the in-place jim-tcl > that isn't in the installed folder. Wouldn't OpenOCD then find the > file it shouldn't? > > I'd like to see a configure time option in openocd to choose between > using currently installed and building in-place. I think that's the best option too. I think I mentioned it before, something like --with-jim-tcl= as an option, but using the in-place version if not specified. But this is beyond my automake skills. Someone else will need to do it. (And I don't think Peter likes this option). > > > BTW, I very much appreciate that you patch and contribution on > the discussion here! This is most useful input, even if we're going > a few extra rounds to get this patch to cover every case. I don't > expect you to take it across the finish line as there are many > on the list with opinions about this topic. That's fine. openocd is a major user of Jim Tcl. I don't want anyone to feel that the new version is a step backwards because of some minor build issues. -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Simplify build with new jimtcl
On 09/11/2010, at 4:59 PM, Øyvind Harboe wrote: > Why is " -I$(top_srcdir)/jimtcl \", that doesn't seem right. > > Shouldn't it be only the build dir? I modelled it on what was already there: -I$(top_srcdir)/src \ -I$(top_builddir)/src If you build out of tree, you will need both the static headers and the generated headers. -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Build improvements with new Jim Tcl
On 09/11/2010, at 9:30 AM, Peter Stuge wrote: > Steve Bennett wrote: >> 1. The current openocd doesn't build on cygwin > > Why not? This should be fixed. Laurent Gauch reported on this some days ago. I agree it should be fixed. This is my attempt. You are welcome to fix it differently. > > >> 2. The multi-step configure/install/build is inconvenient. > > I disagree strongly. If you want. > > >> The attached patch addresses these by configuring, building >> and using jimtcl in-place. > > I disagree with it, but even so I'm not sure if the patch does it > right.. > > (since the patch wasn't sent as text/plain it's not included the > reply, too bad since I'd like to comment on it..) Resent. > > Does $topbuilddir work when building out of directory? I tried to make it work with building out of directory. I hope I succeeded. I am no automake expert. You are welcome to provide something better. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Simplify build with new jimtcl
Don't require Jim Tcl to be separately configured and installed. This fixes builds on cygwin. Signed-off-by: Steve Bennett --- Makefile.am |2 +- bootstrap|8 ++-- configure.in |2 ++ jimtcl |2 +- src/Makefile.am |6 -- src/flash/Makefile.am|4 +++- src/flash/nand/Makefile.am |4 +++- src/flash/nor/Makefile.am|4 +++- src/helper/Makefile.am |2 ++ src/jtag/Makefile.am |4 +++- src/jtag/drivers/Makefile.am |4 +++- src/pld/Makefile.am |4 +++- src/server/Makefile.am |2 ++ src/svf/Makefile.am |4 +++- src/target/Makefile.am |4 +++- src/xsvf/Makefile.am |4 +++- 16 files changed, 41 insertions(+), 19 deletions(-) diff --git a/Makefile.am b/Makefile.am index 7d42fd3..b346570 100644 --- a/Makefile.am +++ b/Makefile.am @@ -9,7 +9,7 @@ nobase_dist_pkgdata_DATA = \ contrib/libdcc/README \ contrib/openocd.udev -SUBDIRS = src doc +SUBDIRS = jimtcl src doc EXTRA_DIST = \ Doxyfile.in \ diff --git a/bootstrap b/bootstrap index 81c9804..d41adae 100755 --- a/bootstrap +++ b/bootstrap @@ -28,14 +28,10 @@ automake --gnu --add-missing --copy # otherwise the documentation will fail to build due to missing version.texi echo "Bootstrap complete. Quick start build instructions:" echo "" -echo "1. Build Jim Tcl" +echo "1. Update Jim Tcl" echo "" echo "git submodule init" echo "git submodule update" -echo "cd jimtcl" -echo "./configure --with-jim-ext=nvp" -echo "make" -echo "make install" echo "" echo "2. Configure" -echo "./configure --enable-maintainer-mode " +echo "./configure --enable-maintainer-mode --with-jim-ext=nvp " diff --git a/configure.in b/configure.in index a15b80a..c4e8505 100644 --- a/configure.in +++ b/configure.in @@ -26,6 +26,8 @@ AC_DISABLE_SHARED AC_PROG_LIBTOOL AC_SUBST(LIBTOOL_DEPS) +AC_CONFIG_SUBDIRS([jimtcl]) + dnl configure checks required for Jim files (these are obsolete w/ C99) AC_C_CONST diff --git a/jimtcl b/jimtcl index fbbc8e0..5a9c9cd 16 --- a/jimtcl +++ b/jimtcl @@ -1 +1 @@ -Subproject commit fbbc8e0b402adb4b0c8d3976015fe4a82c94560f +Subproject commit 5a9c9cdc1a0add1d0e6e63e64d5d7d7febc6d749 diff --git a/src/Makefile.am b/src/Makefile.am index b54161c..5d22c44 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -18,7 +18,7 @@ MAINFILE = main.c endif openocd_SOURCES = $(MAINFILE) -openocd_LDADD = libopenocd.la -ljim +openocd_LDADD = libopenocd.la -L$(top_builddir)/jimtcl -ljim libopenocd_la_SOURCES = \ hello.c \ @@ -33,7 +33,9 @@ noinst_HEADERS = \ # set the include path found by configure AM_CPPFLAGS = \ -I$(top_srcdir)/src \ - -I$(top_builddir)/src + -I$(top_builddir)/src \ + -I$(top_srcdir)/jimtcl \ + -I$(top_builddir)/jimtcl libopenocd_la_CPPFLAGS = -DPKGBLDDATE=\"`date +%F-%R`\" diff --git a/src/flash/Makefile.am b/src/flash/Makefile.am index 9d983a8..d79acf1 100644 --- a/src/flash/Makefile.am +++ b/src/flash/Makefile.am @@ -4,7 +4,9 @@ SUBDIRS = \ AM_CPPFLAGS = \ -I$(top_srcdir)/src \ - -I$(top_builddir)/src + -I$(top_builddir)/src \ + -I$(top_srcdir)/jimtcl \ + -I$(top_builddir)/jimtcl METASOURCES = AUTO noinst_LTLIBRARIES = libflash.la diff --git a/src/flash/nand/Makefile.am b/src/flash/nand/Makefile.am index 8ea7b36..ea052d6 100644 --- a/src/flash/nand/Makefile.am +++ b/src/flash/nand/Makefile.am @@ -1,6 +1,8 @@ AM_CPPFLAGS = \ -I$(top_srcdir)/src \ - -I$(top_builddir)/src + -I$(top_builddir)/src \ + -I$(top_srcdir)/jimtcl \ + -I$(top_builddir)/jimtcl noinst_LTLIBRARIES = libocdflashnand.la diff --git a/src/flash/nor/Makefile.am b/src/flash/nor/Makefile.am index eec6f50..b17db8b 100644 --- a/src/flash/nor/Makefile.am +++ b/src/flash/nor/Makefile.am @@ -1,6 +1,8 @@ AM_CPPFLAGS = \ -I$(top_srcdir)/src \ - -I$(top_builddir)/src + -I$(top_builddir)/src \ + -I$(top_srcdir)/jimtcl \ + -I$(top_builddir)/jimtcl noinst_LTLIBRARIES = libocdflashnor.la libocdflashnor_la_SOURCES = \ diff --git a/src/helper/Makefile.am b/src/helper/Makefile.am index c721881..670c1d1 100644 --- a/src/helper/Makefile.am +++ b/src/helper/Makefile.am @@ -1,6 +1,8 @@ AM_CPPFLAGS = \ -I$(top_srcdir)/src \ -I$(top_builddir)/src \ + -I$(top_srcdir)/jimtcl \ + -I$(top_builddir)/jimtcl \ -DPKGDATADIR=\"$(pkgdatadir)\" METASOURCES = AUTO diff --git a/src/jtag/Makefile.am b/src/jtag/Makefile.am index 59cd8ff..ca03952 100644 --- a/src/jtag/Makefile.am +++ b/src/jtag/Makefile.am @@ -1,6 +1,8 @@ AM_CPPFLAGS = \ -I$(top_srcdir)/src \ - -I$(top_builddir
Re: [Openocd-development] [Patch] New JIMTCL
On 09/11/2010, at 9:55 AM, Antonio Borneo wrote: > On Tue, Nov 9, 2010 at 7:08 AM, Steve Bennett wrote: >> Probably it is a good idea to use echo everywhere for consistency, >> but you could simply redefine puts in terms of echo. > > Hi Steve, > overriding puts is the simpler way to avoid replacing all the tcl scripts. > I have to admit I did not considered this opportunity. > > I'm unable to judge if such overriding can be an issue to someone, > but I don't think anyone could need the current behaviour of puts. > > On the other side, using echo everywhere make the picture simpler to newbies. > I remember I spent some time to check why tcl script mixes echo and > puts, before realize they share similar behaviour. > Now that echo and puts are not interchangeable anymore, is probably > the right time to clean-up tcl scripts. I agree. It was more of an FYI. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Build improvements with new Jim Tcl
1. The current openocd doesn't build on cygwin 2. The multi-step configure/install/build is inconvenient. The attached patch addresses these by configuring, building and using jimtcl in-place. Note that it should still be possible to use an installed jimtcl if required by overriding CPPFLAGS and LDFLAGS but I haven't tried it. This requires the latest version of jimtcl (5a9c9cdc1a0add1d0e6e63e64d5d7d7febc6d749) -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 0001-Simplify-build-with-new-jimtcl.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Patch] New JIMTCL
On 08/11/2010, at 7:46 PM, Antonio Borneo wrote:
> Hi,
>
> after the replacement of JIMTCL with the new version, the command
> "puts" does not work as before.
> It prints nothing in the telnet connection, while is still working in
> the default console.
> Looking at the code, the reason is that the new jimtcl only prints to stdout.
> Of course, it's possible to modify jimtcl library, but the
> modification is quite invasive, and we would diverge from the main
> branch.
>
> The solution I propose, is to switch away from "puts", in favour of "echo".
> The advantage is that "echo" is part of OpenOCD, so no change is
> required inside jimtcl.
>
> 1) the first patch in attachment enhances "echo" with the command
> option "-n", to replace "puts -nonewline"
>
> 2) this patch can be eventually skipped. Anyway, I would like your
> comments on it.
> In order to add help text to "echo" command, I have replaced the
> definition of the command inside the COMMAND_HANDLER syntax.
> Is this correct? In my tests it works properly. I do not know if there
> is any drawback.
>
> 3) this last patch replaces all the "puts" in the tcl files with "echo"
Probably it is a good idea to use echo everywhere for consistency,
but you could simply redefine puts in terms of echo.
proc puts {args} {
tailcall echo {*}$args
}
>
> Best Regards,
> Antonio Borneo
> <0001-JIM-Add-n-option-to-echo.patch><0002-JIM-document-echo-command.patch><0003-TCL-scripts-replace-puts-with-echo.patch.gz>___
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
--
µWeb: Embedded Web Framework - http://uweb.workware.net.au/
WorkWare Systems Pty Ltd
W: www.workware.net.au P: 0434 921 300
E: ste...@workware.net.au F: 07 3102 9221
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD master now uses Jim Tcl 0.63
On 03/11/2010, at 8:34 AM, Steve Bennett wrote: > On 03/11/2010, at 12:23 AM, Laurent Gauch wrote: > >> under Cygwin with external JIM TCL 0.63 in ./openocd/jimtcl, the make error >> is : >> >> ../../../src/helper/command.h:34:17: jim.h: No such file or directory > > Did you forget 'make install' in ./openocd/jimtcl? > > This is the symptom I see when that step is missed. > > (Although as someone pointed out, it would be nice to have > a single stage configure/build without needing to install jimtcl) Although the link step still fails for me on cygwin. make[4]: Entering directory `/src/openocd/src' /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 -Werror -o openocd.exe main.o libopenocd.la -ljim libtool: link: gcc -std=gnu99 -g -O2 -Wall -Wstrict-prototypes -Wformat-security -Wshadow -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -o openocd.exe main.o ./.libs/libopenocd.a -ljim /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld: cannot find -ljim collect2: ld returned 1 exit status make[4]: *** [openocd.exe] Error 1 make[4]: Leaving directory `/src/openocd/src' I'm no automake expert. It seems to me that it should be possible to add include and lib paths directly to the jimtcl directory under openocd, thus avoiding the need to 'make install' and addressing this link problem. > >> >>> checking whether standard drivers can be built... yes >>> checking for ftd2xx.lib exists (win32)... checking whether ftd2xx library >>> works. >>> .. Success! >>> checking for ftd2xx highspeed device support... yes >>> checking for environ in unistd.h and stdlib.h... yes >>> checking for a C compiler for build tools... gcc -mno-cygwin -std=gnu99 >>> checking for suffix of executable build tools... .exe >>> configure: creating ./config.status >>> config.status: creating Makefile >>> config.status: creating src/Makefile >>> config.status: creating src/helper/Makefile >>> config.status: creating src/jtag/Makefile >>> config.status: creating src/jtag/drivers/Makefile >>> config.status: creating src/xsvf/Makefile >>> config.status: creating src/svf/Makefile >>> config.status: creating src/target/Makefile >>> config.status: creating src/server/Makefile >>> config.status: creating src/flash/Makefile >>> config.status: creating src/flash/nor/Makefile >>> config.status: creating src/flash/nand/Makefile >>> config.status: creating src/pld/Makefile >>> config.status: creating doc/Makefile >>> config.status: creating config.h >>> config.status: executing depfiles commands >>> config.status: executing libtool commands >>> make all-recursive >>> make[1]: Entering directory >>> `/cygdrive/c/amontec/openocd-builder/git/openocd' >>> Making all in src >>> make[2]: Entering directory >>> `/cygdrive/c/amontec/openocd-builder/git/openocd/src >>> ' >>> cat helper/startup.tcl jtag/startup.tcl target/startup.tcl >>> flash/startup.tcl ser >>> ver/startup.tcl > startup.tcl >>> make all-recursive >>> make[3]: Entering directory >>> `/cygdrive/c/amontec/openocd-builder/git/openocd/src >>> ' >>> Making all in jtag >>> make[4]: Entering directory >>> `/cygdrive/c/amontec/openocd-builder/git/openocd/src >>> /jtag' >>> cp drivers/minidriver_imp.h minidriver_imp.h >>> make all-recursive >>> make[5]: Entering directory >>> `/cygdrive/c/amontec/openocd-builder/git/openocd/src >>> /jtag' >>> Making all in drivers >>> make[6]: Entering directory >>> `/cygdrive/c/amontec/openocd-builder/git/openocd/src >>> /jtag/drivers' >>> /bin/sh ../../../libtool --tag=CC --mode=compile gcc -mno-cygwin >>> -std=gnu99 -D >>> HAVE_CONFIG_H -I. -I../../.. -I../../../src -I../../../src -g -O2 >>> -I/cygdrive >>> /c/amontec/jtagkey/driver/d2xx/nt -Wall -Wstrict-prototypes >>> -Wformat-security -W >>> shadow -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align >>> -Wredundan >>> t-decls -MT driver.lo -MD -MP -MF .deps/driver.Tpo -c -o driver.lo driver.c >>> libtool: compile: gcc -mno-cygwin -std=gnu99 -DHAVE_CONFIG_H -I. >>> -I../../.. -I. >>> ./../../src -I../../../src -g -O2 >>> -I/cygdrive/c/amontec/jtagkey/
Re: [Openocd-development] OpenOCD master now uses Jim Tcl 0.63
On 03/11/2010, at 12:23 AM, Laurent Gauch wrote: > under Cygwin with external JIM TCL 0.63 in ./openocd/jimtcl, the make error > is : > > ../../../src/helper/command.h:34:17: jim.h: No such file or directory Did you forget 'make install' in ./openocd/jimtcl? This is the symptom I see when that step is missed. (Although as someone pointed out, it would be nice to have a single stage configure/build without needing to install jimtcl) > >> checking whether standard drivers can be built... yes >> checking for ftd2xx.lib exists (win32)... checking whether ftd2xx library >> works. >> .. Success! >> checking for ftd2xx highspeed device support... yes >> checking for environ in unistd.h and stdlib.h... yes >> checking for a C compiler for build tools... gcc -mno-cygwin -std=gnu99 >> checking for suffix of executable build tools... .exe >> configure: creating ./config.status >> config.status: creating Makefile >> config.status: creating src/Makefile >> config.status: creating src/helper/Makefile >> config.status: creating src/jtag/Makefile >> config.status: creating src/jtag/drivers/Makefile >> config.status: creating src/xsvf/Makefile >> config.status: creating src/svf/Makefile >> config.status: creating src/target/Makefile >> config.status: creating src/server/Makefile >> config.status: creating src/flash/Makefile >> config.status: creating src/flash/nor/Makefile >> config.status: creating src/flash/nand/Makefile >> config.status: creating src/pld/Makefile >> config.status: creating doc/Makefile >> config.status: creating config.h >> config.status: executing depfiles commands >> config.status: executing libtool commands >> make all-recursive >> make[1]: Entering directory `/cygdrive/c/amontec/openocd-builder/git/openocd' >> Making all in src >> make[2]: Entering directory >> `/cygdrive/c/amontec/openocd-builder/git/openocd/src >> ' >> cat helper/startup.tcl jtag/startup.tcl target/startup.tcl flash/startup.tcl >> ser >> ver/startup.tcl > startup.tcl >> make all-recursive >> make[3]: Entering directory >> `/cygdrive/c/amontec/openocd-builder/git/openocd/src >> ' >> Making all in jtag >> make[4]: Entering directory >> `/cygdrive/c/amontec/openocd-builder/git/openocd/src >> /jtag' >> cp drivers/minidriver_imp.h minidriver_imp.h >> make all-recursive >> make[5]: Entering directory >> `/cygdrive/c/amontec/openocd-builder/git/openocd/src >> /jtag' >> Making all in drivers >> make[6]: Entering directory >> `/cygdrive/c/amontec/openocd-builder/git/openocd/src >> /jtag/drivers' >> /bin/sh ../../../libtool --tag=CC --mode=compile gcc -mno-cygwin >> -std=gnu99 -D >> HAVE_CONFIG_H -I. -I../../.. -I../../../src -I../../../src -g -O2 >> -I/cygdrive >> /c/amontec/jtagkey/driver/d2xx/nt -Wall -Wstrict-prototypes >> -Wformat-security -W >> shadow -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align >> -Wredundan >> t-decls -MT driver.lo -MD -MP -MF .deps/driver.Tpo -c -o driver.lo driver.c >> libtool: compile: gcc -mno-cygwin -std=gnu99 -DHAVE_CONFIG_H -I. -I../../.. >> -I. >> ./../../src -I../../../src -g -O2 >> -I/cygdrive/c/amontec/jtagkey/driver/d2xx/nt - >> Wall -Wstrict-prototypes -Wformat-security -Wshadow -Wextra >> -Wno-unused-paramete >> r -Wbad-function-cast -Wcast-align -Wredundant-decls -MT driver.lo -MD -MP >> -MF . >> deps/driver.Tpo -c driver.c -o driver.o >> In file included from ../../../src/helper/log.h:29, >> from ../../../src/jtag/jtag.h:27, >> from driver.c:34: >> ../../../src/helper/command.h:34:17: jim.h: No such file or directory >> ../../../src/helper/command.h:35:21: jim-nvp.h: No such file or directory > > Regards, > Laurent > http://www.amontec.com > > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: 0434 921 300 E: ste...@workware.net.au F: 07 3102 9221 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
