Re: [Openocd-development] Build error with mingw32
On Sun, Aug 14, 2011 at 6:39 AM, Steve Bennett ste...@workware.net.au wrote: I pushed a change to jimtcl git which will use Sleep() if usleep() is unavailable on mingw32. Now building OpenOCD with latest jimtcl with mingw32 works for me. Thank you! Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] A fix (was Re: Git revision string missing from banner)
On Mon, Aug 15, 2011 at 9:35 AM, Spencer Oliver s...@spen-soft.co.uk wrote: On 15 August 2011 14:22, Eric Wetzel thewet...@gmail.com wrote: if test $cross_compiling = no; then # guess-rev.sh only exists in the repository, not in the released archives AC_CHECK_FILE($srcdir/guess-rev.sh, has_guess_rev=yes, has_guess_rev=no) We automatically assume that if we are cross-compiling that we are building a release. This section was last modified in July 2009, back in the SVN days, but the commit is here: http://repo.or.cz/w/openocd.git/commitdiff/00fad24996d6642c6a820cc951c197dddef5734a Actually it was introduced earlier http://repo.or.cz/w/openocd.git/commit/64e53c4fd8a5da944de57716b137a7dff5e67b63 This patch should fix it. Please review and merge if it's OK. Thank you! Jie From 281bc87c50fd108d43283b07ac1d3900767aba00 Mon Sep 17 00:00:00 2001 From: Jie Zhang jie.zh...@analog.com Date: Mon, 15 Aug 2011 10:52:11 -0400 Subject: [PATCH] show git commit number even when cross-compiling AC_CHECK_FILE will die when cross-compiling. So don't use it to test the existence of guess-rev.sh. --- configure.in | 16 +--- 1 files changed, 5 insertions(+), 11 deletions(-) diff --git a/configure.in b/configure.in index dfa1e8f..3c0056c 100644 --- a/configure.in +++ b/configure.in @@ -143,20 +143,14 @@ is_mingw=no is_win32=no is_darwin=no -if test $cross_compiling = no; then - # guess-rev.sh only exists in the repository, not in the released archives - AC_CHECK_FILE($srcdir/guess-rev.sh, has_guess_rev=yes, has_guess_rev=no) - - AC_MSG_CHECKING([whether to build a release]) - if test $has_guess_rev = no; then -build_release=yes - else -build_release=no - fi - AC_MSG_RESULT($build_release) +# guess-rev.sh only exists in the repository, not in the released archives +AC_MSG_CHECKING([whether to build a release]) +if test -f $srcdir/guess-rev.sh ; then + build_release=no else build_release=yes fi +AC_MSG_RESULT($build_release) # We are not *ALWAYS* being installed in the standard place. # We may be installed in a tool-build specific location. -- 1.7.5.4 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] A fix (was Re: Git revision string missing from banner)
On 15 August 2011 16:03, Jie Zhang jzhang...@gmail.com wrote: On Mon, Aug 15, 2011 at 9:35 AM, Spencer Oliver s...@spen-soft.co.uk wrote: On 15 August 2011 14:22, Eric Wetzel thewet...@gmail.com wrote: if test $cross_compiling = no; then # guess-rev.sh only exists in the repository, not in the released archives AC_CHECK_FILE($srcdir/guess-rev.sh, has_guess_rev=yes, has_guess_rev=no) We automatically assume that if we are cross-compiling that we are building a release. This section was last modified in July 2009, back in the SVN days, but the commit is here: http://repo.or.cz/w/openocd.git/commitdiff/00fad24996d6642c6a820cc951c197dddef5734a Actually it was introduced earlier http://repo.or.cz/w/openocd.git/commit/64e53c4fd8a5da944de57716b137a7dff5e67b63 This patch should fix it. Please review and merge if it's OK. Thank you! looks fine to me. thanks spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Add a configure option to enable/disable rtos support
Isn't there a way to make both live side-by-side? rtos w/BF561 is surely possible? -- Ø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/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] JLink woes
On Sun, Aug 14, 2011 at 10:29 PM, Eric Wetzel thewet...@gmail.com wrote: On Sun, Aug 14, 2011 at 9:01 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Mon, Aug 15, 2011 at 5:26 AM, Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com wrote: On 12:04 Sat 13 Aug , Carlson Gary wrote: Hi Eric, I have worked a little on the jlink stuff in the past and fixed a few problems with OpenOCD. I have a new project that is going to force me to buy an unrestricted Segger very shortly since my current jlink dongles are Atmel-only devices. Once I get my hands on a new one, I hopefully will be able to take a look at this problem also. I will try to contact Segger on Monday to see if they can shine some light on V8 communication details. I suspect whatever is wrong is probably minor, but will take a little persistence to identify a solution. I already contract Segger this year and their answer are we change nothing I put segger in Cc this time on the ML hope you will work with us to improve J-Link support on OpenOCD To be fair to Segger, I think they do not intentionally change anything in the firmware. After all, the firmware needs to be compatible with their own utility under Windows and Linux. On the other hand, they probably did not test OpenOCD since that was not their focus. From the usbmon log, Segger's Linux utility are consistent through different versions of J-Link. The main issue is that OpenOCD's J-Link initialization sequence is not the same as Segger's utility, as shown in Eric's previous email. I think Gary is probably correct that whatever is wrong (in OpenOCD) is probably minor. After piles of debugging today, I have determined that command 0x09 is EMU_CMD_REGISTER, which is undocumented in the J-Link USB Protocol manual. I don't know what parameters it sends or what data it receives. In addition, there are plenty of commands from the Capabilities table that are undocumented: EMU_CMD_RAWTRACE, EMU_CMD_TEST_NET_SPEED, EMU_CMD_INDICATORS, EMU_CMD_REGISTER, EMU_CMD_FILE_IO, EMU_CMD_UPDATE_FIRMWARE_EX, EMU_CMD_WRITE_DCC_EX, EMU_CMD_SWO, and EMU_CMD_READ_DCC. Regarding OpenOCD's J-Link initialiation sequence, I was going to start trying some things out, changing the order of some commands to make it more like Segger's, adding some of the missing ones (like EMU_CMD_GET_COUNTERS; Segger uses it, but I don't think OpenOCD does). I also noticed that where the usb_bulk_reads start to fail is when we start to issue EMU_CMD_HW_JTAG3; from Xiaofan's log above: Debug: 277 507 core.c:329 jtag_call_event_callbacks(): jtag event: TAP reset Debug: 278 510 jlink.c:1654 jlink_debug_buffer(): cf 00 07 00 7f 00 Debug: 279 511 jlink.c:1654 jlink_debug_buffer(): 7f Debug: 280 514 jlink.c:1654 jlink_debug_buffer(): 00 Debug: 281 514 core.c:1435 jtag_init_inner(): Init JTAG chain Debug: 282 514 core.c:329 jtag_call_event_callbacks(): jtag event: TAP reset Debug: 283 515 jlink.c:1654 jlink_debug_buffer(): cf 00 07 00 7f 00 Error: 284 518 jlink.c:1504 jlink_usb_message(): usb_bulk_read failed (requested=1, result=0) Error: 285 518 jlink.c:1367 jlink_tap_execute(): jlink_tap_execute, wrong result -107 (expected 1) Odd that the command succeeds, but sending the very same command again fails. I had a hunch that perhaps it's a data length thing in the V8 firmware. All of Segger's EMU_CMD_HW_JTAG3 commands are on the order of 194 bytes long, and we are sending command sequences that are less than 8 bits. There's already some funky behavior noted in the code for when J-Link returns an extra NULL when the incoming message size is a multiple of 64. It wouldn't be unprecedented, but I haven't investigated it yet. Well, that's a day's work for me. I tried query more parts of the hardware before I tried issuing JTAG commands today, but to no avail. I studied the information that Segger retrieves from the device and reordered it, removing repeats. The commands that I thought actually DO something I tried to keep in the same order and issue them before sending JTAG commands: EMU_CMD_SELECT_IF, deassert resets, set a reasonable clock speed (Segger sets 4 kHz and 100 kHz, alternately). Here is a log: Debug: 227 108 jlink.c:1608 jlink_usb_open(): usb ep in 81 Debug: 228 108 jlink.c:1608 jlink_usb_open(): usb ep out 02 Info : 229 108 jlink.c:431 jlink_init(): J-Link initialization started / target CPU reset initiated Debug: 230 109 jlink.c:1793 jlink_debug_buffer(): 01 Debug: 231 109 jlink.c:1793 jlink_debug_buffer(): 70 00 Debug: 232 109 jlink.c:1793 jlink_debug_buffer(): 4a 2d 4c 69 6e 6b 20 41 52 4d 20 56 38 20 63 6f Debug: 233 110 jlink.c:1793 jlink_debug_buffer(): 0010 6d 70 69 6c 65 64 20 4a 75 6c 20 32 36 20 32 30 Debug: 234 110 jlink.c:1793 jlink_debug_buffer(): 0020 31 31 20 31 37 3a 33 31 3a 32 34 00 43 6f 70 79 Debug: 235 110 jlink.c:1793 jlink_debug_buffer(): 0030 72 69 67 68 74 20 32 30 30 33 2d 32 30 30 39 20 Debug: 236
[Openocd-development] [PATCH] Rename configure.in as configure.ac
configure.ac is now preferred. So rename configure.in to make OpenOCD project look modern. Please review and merge if it's OK. Thank you! Jie From 97ef0e24eeb752f88e521376f41b8e1321db52a0 Mon Sep 17 00:00:00 2001 From: Jie Zhang jie.zh...@analog.com Date: Mon, 15 Aug 2011 15:35:30 -0400 Subject: [PATCH] rename configure.in as configure.ac --- configure.in = configure.ac |0 1 files changed, 0 insertions(+), 0 deletions(-) rename configure.in = configure.ac (100%) diff --git a/configure.in b/configure.ac similarity index 100% rename from configure.in rename to configure.ac -- 1.7.5.4 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Rename configure.in as configure.ac
On 15/08/2011 20:42, Jie Zhang wrote: configure.ac is now preferred. So rename configure.in to make OpenOCD project look modern. Please review and merge if it's OK. Thank you! cheers, no objections then i will commit. Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Add a configure option to enable/disable rtos support
On Mon, Aug 15, 2011 at 9:16 PM, Jie Zhang jzhang...@gmail.com wrote: On Mon, Aug 15, 2011 at 3:10 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: Isn't there a way to make both live side-by-side? rtos w/BF561 is surely possible? Since both will use threads, they cannot be supported in the same time. To debug a rtos on BF561, users have to choose using thread in GDB as a core or as a thread in rtos. eCos is an RTOS that supports multiple CPUs. I think it is reasonable to enable/disable threads as a way to choose between CPUs and a way to choose between RTOS threads, but I think that choice should happen during configuration runtime in the scripts and not at build time. -- Ø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/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Add a configure option to enable/disable rtos support
On Mon, Aug 15, 2011 at 4:42 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: On Mon, Aug 15, 2011 at 9:16 PM, Jie Zhang jzhang...@gmail.com wrote: On Mon, Aug 15, 2011 at 3:10 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: Isn't there a way to make both live side-by-side? rtos w/BF561 is surely possible? Since both will use threads, they cannot be supported in the same time. To debug a rtos on BF561, users have to choose using thread in GDB as a core or as a thread in rtos. eCos is an RTOS that supports multiple CPUs. I think it is reasonable to enable/disable threads as a way to choose between CPUs and a way to choose between RTOS threads, but I think that choice should happen during configuration runtime in the scripts and not at build time. Thanks for your comment. Runtime is surely better than configure time. But it will also be more difficult, thus need more time, to implement. I will try and see if I can do it in my schedule. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Add a configure option to enable/disable rtos support
Thanks for your comment. Runtime is surely better than configure time. But it will also be more difficult, thus need more time, to implement. I will try and see if I can do it in my schedule. I'd much rather wait and see this done properly. Time is not such an issue. If someone else feels differently, they can pitch in! :-) -- Ø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/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] A fix (was Re: Git revision string missing from banner)
On Mon, Aug 15, 2011 at 5:03 PM, Jie Zhang jzhang...@gmail.com wrote: On Mon, Aug 15, 2011 at 9:35 AM, Spencer Oliver s...@spen-soft.co.uk wrote: On 15 August 2011 14:22, Eric Wetzel thewet...@gmail.com wrote: if test $cross_compiling = no; then # guess-rev.sh only exists in the repository, not in the released archives AC_CHECK_FILE($srcdir/guess-rev.sh, has_guess_rev=yes, has_guess_rev=no) We automatically assume that if we are cross-compiling that we are building a release. This section was last modified in July 2009, back in the SVN days, but the commit is here: http://repo.or.cz/w/openocd.git/commitdiff/00fad24996d6642c6a820cc951c197dddef5734a Actually it was introduced earlier http://repo.or.cz/w/openocd.git/commit/64e53c4fd8a5da944de57716b137a7dff5e67b63 This patch should fix it. Please review and merge if it's OK. Thank you! Jie +if test -f $srcdir/guess-rev.sh ; then Great, but you should probably check if it's executable instead of just a regular file. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
