Re: [Openocd-development] couldn't read enough bytes from FT2232 device (0 < 81)
On Tue, Aug 16, 2011 at 9:23 AM, Xiaofan Chen wrote: > On Tue, Aug 16, 2011 at 9:18 PM, Eric Wetzel wrote: > >> I'm not sure if Freddie's OpenOCD is built using libftdi-1.0, which >> previous e-mails indicate may solve this problem. As a last-ditch >> effort to try libftdi-1.0, I replaced the libfti.dll in Freddie's bin >> directory with the libftdi.dll from Xiaofan's build >> (http://code.google.com/p/picusb/downloads/detail?name=libftdi1_17July2011_mingw32_mingw64.zip&can=2&q=). >> I get the same result. > > Hmm, interesting to know that would work. > > Freddie's OpenOCD binary and my binary are both using libftdi-0.19 > and libusb-win32. > >> Anybody have any hints? Is anybody else successfully using a Blackhawk >> USB100v2? I don't really think it's the interface itself because I get >> the same failure on a completely different target board using OpenOCD >> built from git on Linux at home... I think. > > From the past history, it seems that ftd2xx may help. So you may want to > build with FTDI's latest D2xx library to see if that helps. > Strangely, I am having the same problem with FTD2XX, but the timeouts are taking much longer: Debug: 236 158 ft2232.c:2478 ft2232_init(): ft2232 interface using shortest path jtag state transitions Debug: 237 158 ft2232.c:2158 ft2232_init_ftd2xx(): 'ft2232' interface using FTD2XX with 'xds100v2' layout (0403:a6d0) Debug: 238 194 ft2232.c:2285 ft2232_init_ftd2xx(): current latency timer: 2 Info : 239 194 ft2232.c:2315 ft2232_init_ftd2xx(): device: 6 "2232H" Info : 240 194 ft2232.c:2316 ft2232_init_ftd2xx(): deviceID: 67348176 Info : 241 194 ft2232.c:2317 ft2232_init_ftd2xx(): SerialNumber: USB100V2A Info : 242 195 ft2232.c:2318 ft2232_init_ftd2xx(): Description: Texas Instruments Inc.XDS100 Ver 2.0 A Debug: 243 195 ft2232.c:2435 ft2232_set_data_bits_low_byte(): 80 3a 7b Debug: 244 195 ft2232.c:2455 ft2232_set_data_bits_high_byte(): 82 00 59 Debug: 245 195 ft2232.c:2455 ft2232_set_data_bits_high_byte(): 82 86 59 Info : 246 196 ft2232.c:648 ft2232h_ft4232h_clk_divide_by_5(): max TCK change to: 3 kHz Debug: 247 197 core.c:1602 adapter_khz_to_speed(): convert khz to interface specific speed value Debug: 248 197 core.c:1606 adapter_khz_to_speed(): have interface set up Debug: 249 197 ft2232.c:616 ft2232h_ft4232h_adaptive_clocking(): 96 Debug: 250 197 core.c:1602 adapter_khz_to_speed(): convert khz to interface specific speed value Debug: 251 197 core.c:1606 adapter_khz_to_speed(): have interface set up Info : 252 197 core.c:1424 adapter_init(): RCLK (adaptive clock speed) Debug: 253 197 openocd.c:137 handle_init_command(): Debug Adapter init complete Debug: 254 197 command.c:151 script_debug(): command - ocd_command ocd_command type ocd_transport init Debug: 255 198 command.c:151 script_debug(): command - ocd_transport ocd_transport init Debug: 257 198 transport.c:255 handle_transport_init(): handle_transport_init Debug: 258 198 ft2232.c:1750 xds100v2_reset(): trst: 0, srst: 0, high_output: 0x96, high_direction: 0x59 Debug: 259 198 ft2232.c:816 ft2232_send_and_recv(): write buffer (size 3): Debug: 260 198 ft2232.c:797 ft2232_debug_dump_buffer(): 82 96 59 Debug: 261 198 core.c:713 jtag_add_reset(): SRST line released Debug: 262 198 core.c:737 jtag_add_reset(): TRST line released Debug: 263 198 core.c:329 jtag_call_event_callbacks(): jtag event: TAP reset Debug: 264 199 command.c:151 script_debug(): command - ocd_command ocd_command type ocd_jtag arp_init Debug: 265 199 command.c:151 script_debug(): command - ocd_jtag ocd_jtag arp_init Debug: 266 199 core.c:1435 jtag_init_inner(): Init JTAG chain Debug: 267 199 core.c:329 jtag_call_event_callbacks(): jtag event: TAP reset Debug: 268 199 ft2232.c:816 ft2232_send_and_recv(): write buffer (size 3): Debug: 269 199 ft2232.c:797 ft2232_debug_dump_buffer(): 4b 04 1f Debug: 270 199 core.c:1055 jtag_examine_chain(): DR scan interrogation for IDCODE/BYPASS Debug: 271 199 core.c:329 jtag_call_event_callbacks(): jtag event: TAP reset Debug: 272 199 ft2232.c:816 ft2232_send_and_recv(): write buffer (size 94): Debug: 273 200 ft2232.c:791 ft2232_debug_dump_buffer(): 4b 06 17 39 4e 00 ff 00 00 00 ff 00 00 00 ff 00 Debug: 274 200 ft2232.c:791 ft2232_debug_dump_buffer(): 00 00 ff 00 00 00 ff 00 00 00 ff 00 00 00 ff 00 Debug: 275 200 ft2232.c:791 ft2232_debug_dump_buffer(): 00 00 ff 00 00 00 ff 00 00 00 ff 00 00 00 ff 00 Debug: 276 200 ft2232.c:791 ft2232_debug_dump_buffer(): 00 00 ff 00 00 00 ff 00 00 00 ff 00 00 00 ff 00 Debug: 277 200 ft2232.c:791 ft2232_debug_dump_buffer(): 00 00 ff 00 00 00 ff 00 00 00 ff 00 00 00 ff 00 Debug: 278 200 ft2232.c:797 ft2232_debug_dump_buffer(): 00 00 ff 00 00 3b 06 00 6b 01 01 4b 04 1f Error: 279 25203 ft2232.c:591 ft2232_read(): couldn't read enough bytes from FT2232 device (0 < 81) Error: 280 25203 ft2232.c:846 ft2232_send_and_recv(): couldn't read from FT2232 Error: 281 25203 core.c:1479 jtag_init_inner(): Trying to use configured scan chain anyway... Debug: 282 25203 core.c:1219 jtag_validate_ircap
Re: [Openocd-development] [PATCH] A fix (was Re: Git revision string missing from banner)
On Tue, Aug 16, 2011 at 4:19 PM, Jie Zhang wrote: > On Mon, Aug 15, 2011 at 6:21 PM, Andreas Fritiofson > wrote: > > > +if test -f $srcdir/guess-rev.sh ; then > > Great, but you should probably check if it's executable instead of just a > > regular file. > > I considered if we should check this. But I finally decided it would > be better to just check if it's a regular file. my reason is: > > We decide if we are building for release or not by the existence of > guess-rev.sh, not by the existence of an executable guess-rev.sh. So > > 1. guess-rev.sh exists and is executable: checking regular file is > same as checking executable file. > 2. guess-rev.sh does not exist: checking regular file is same as > checking executable file. > 3. guess-rev.sh exists but is not executable: there must be something > wrong. If we check regular file, user will be given an error when > guess-rev.sh is going to be executed on compiler time. If we check > executable file, building for release is assumed and user will notice > it only in run time. > Agreed, failure is probably the better option if the permissions are botched. I'll leave it as is. /Andreas ___ 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 6:21 PM, Andreas Fritiofson wrote: > > +if test -f $srcdir/guess-rev.sh ; then > Great, but you should probably check if it's executable instead of just a > regular file. I considered if we should check this. But I finally decided it would be better to just check if it's a regular file. my reason is: We decide if we are building for release or not by the existence of guess-rev.sh, not by the existence of an executable guess-rev.sh. So 1. guess-rev.sh exists and is executable: checking regular file is same as checking executable file. 2. guess-rev.sh does not exist: checking regular file is same as checking executable file. 3. guess-rev.sh exists but is not executable: there must be something wrong. If we check regular file, user will be given an error when guess-rev.sh is going to be executed on compiler time. If we check executable file, building for release is assumed and user will notice it only in run time. Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.5.0 MinGW configure failure
On Tue, Aug 16, 2011 at 6:13 PM, Spencer Oliver wrote: > On 16 August 2011 11:03, Steve Bennett wrote: >> Good news. Spencer and I sorted out the jimtcl build problem on mingw. >> The fix is in the jimtcl git repo. >> See: >> http://repo.or.cz/w/jimtcl.git/commit/645ed6fd4b6f9038c7e1d85d74c3872b3cb9a507 >> > > yah - i will update the openocd jim version Thanks now building under MinGW/MSys works fine. Thanks a lot. I also tested with cross 32bit MinGW build under 64bit Ubuntu 11.04 and it works fine as well. If there is going to be a 5.01 release, this should probably be included. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] couldn't read enough bytes from FT2232 device (0 < 81)
On Tue, Aug 16, 2011 at 9:18 PM, Eric Wetzel wrote: > I'm not sure if Freddie's OpenOCD is built using libftdi-1.0, which > previous e-mails indicate may solve this problem. As a last-ditch > effort to try libftdi-1.0, I replaced the libfti.dll in Freddie's bin > directory with the libftdi.dll from Xiaofan's build > (http://code.google.com/p/picusb/downloads/detail?name=libftdi1_17July2011_mingw32_mingw64.zip&can=2&q=). > I get the same result. Hmm, interesting to know that would work. Freddie's OpenOCD binary and my binary are both using libftdi-0.19 and libusb-win32. > Anybody have any hints? Is anybody else successfully using a Blackhawk > USB100v2? I don't really think it's the interface itself because I get > the same failure on a completely different target board using OpenOCD > built from git on Linux at home... I think. >From the past history, it seems that ftd2xx may help. So you may want to build with FTDI's latest D2xx library to see if that helps. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] couldn't read enough bytes from FT2232 device (0 < 81)
On Tue, Aug 16, 2011 at 9:18 AM, Eric Wetzel wrote: > This problem again. I see plenty of e-mails in the past supposedly > addressing it, but none worked for me. > > I'm trying to use a TI/Blackhawk USB100v2, which I think is supposed > to be identical to an XDS100v2, so I am using the > interface/xds100v2.cfg file. I'm using Freddie's OpenOCD 0.5.0 build > under Windows 7. > > Debug: 231 123 ft2232.c:2469 ft2232_init(): ft2232 interface using > shortest path jtag state transitions > Debug: 232 123 ft2232.c:2342 ft2232_init_libftdi(): 'ft2232' interface > using libftdi with 'xds100v2' layout (0403:a6d0) > Debug: 233 129 ft2232.c:2389 ft2232_init_libftdi(): current latency timer: 2 > Debug: 234 130 ft2232.c:2400 ft2232_init_libftdi(): FTDI chip type: 4 "2232H" > Debug: 235 131 ft2232.c:2426 ft2232_set_data_bits_low_byte(): 80 3a 7b > Debug: 236 131 ft2232.c:2446 ft2232_set_data_bits_high_byte(): 82 00 59 > Debug: 237 132 ft2232.c:2446 ft2232_set_data_bits_high_byte(): 82 86 59 > Info : 238 132 ft2232.c:647 ft2232h_ft4232h_clk_divide_by_5(): max TCK > change to: 3 kHz > Debug: 239 134 core.c:1602 adapter_khz_to_speed(): convert khz to > interface specific speed value > Debug: 240 134 core.c:1606 adapter_khz_to_speed(): have interface set up > Debug: 241 135 ft2232.c:615 ft2232h_ft4232h_adaptive_clocking(): 96 > Debug: 242 135 core.c:1602 adapter_khz_to_speed(): convert khz to > interface specific speed value > Debug: 243 136 core.c:1606 adapter_khz_to_speed(): have interface set up > Info : 244 136 core.c:1424 adapter_init(): RCLK (adaptive clock speed) > Debug: 245 137 openocd.c:137 handle_init_command(): Debug Adapter init > complete > Debug: 246 137 command.c:151 script_debug(): command - ocd_command > ocd_command type ocd_transport init > Debug: 247 138 command.c:151 script_debug(): command - ocd_transport > ocd_transport init > Debug: 249 138 transport.c:255 handle_transport_init(): handle_transport_init > Debug: 250 139 ft2232.c:1749 xds100v2_reset(): trst: 0, srst: 0, > high_output: 0x96, high_direction: 0x59 > Debug: 251 139 core.c:713 jtag_add_reset(): SRST line released > Debug: 252 140 core.c:737 jtag_add_reset(): TRST line released > Debug: 253 140 core.c:329 jtag_call_event_callbacks(): jtag event: TAP reset > Debug: 254 141 command.c:151 script_debug(): command - ocd_command > ocd_command type ocd_jtag arp_init > Debug: 255 141 command.c:151 script_debug(): command - ocd_jtag > ocd_jtag arp_init > Debug: 256 142 core.c:1435 jtag_init_inner(): Init JTAG chain > Debug: 257 142 core.c:329 jtag_call_event_callbacks(): jtag event: TAP reset > Debug: 258 143 core.c:1055 jtag_examine_chain(): DR scan interrogation > for IDCODE/BYPASS > Debug: 259 143 core.c:329 jtag_call_event_callbacks(): jtag event: TAP reset > Error: 260 4140 ft2232.c:590 ft2232_read(): couldn't read enough bytes > from FT2232 device (0 < 81) > Error: 261 4140 ft2232.c:845 ft2232_send_and_recv(): couldn't read from FT2232 > Error: 262 4141 core.c:1479 jtag_init_inner(): Trying to use > configured scan chain anyway... > Debug: 263 4141 core.c:1219 jtag_validate_ircapture(): IR capture > validation scan > Error: 264 8140 ft2232.c:590 ft2232_read(): couldn't read enough bytes > from FT2232 device (0 < 2) > Error: 265 8140 ft2232.c:845 ft2232_send_and_recv(): couldn't read from FT2232 > Debug: 266 8141 core.c:329 jtag_call_event_callbacks(): jtag event: TAP reset > Warn : 267 8141 core.c:1503 jtag_init_inner(): Bypassing JTAG setup > events due to errors > Debug: 268 8142 openocd.c:150 handle_init_command(): Examining targets... > Debug: 269 8142 command.c:151 script_debug(): command - ocd_command > ocd_command type ocd_flash init > Debug: 270 8143 command.c:151 script_debug(): command - ocd_flash ocd_flash > init > Debug: 271 8143 log.c:437 keep_alive(): keep_alive() was not invoked > in the 1000ms timelimit (8143). This may cause trouble with GDB > connections. > Debug: 274 8144 tcl.c:912 handle_flash_init_command(): Initializing > flash devices... > Debug: 275 8145 command.c:151 script_debug(): command - ocd_command > ocd_command type ocd_mflash init > Debug: 276 8145 command.c:151 script_debug(): command - ocd_mflash > ocd_mflash init > Debug: 278 8146 mflash.c:1331 handle_mflash_init_command(): > Initializing mflash devices... > Debug: 279 8146 command.c:151 script_debug(): command - ocd_command > ocd_command type ocd_nand init > Debug: 280 8147 command.c:151 script_debug(): command - ocd_nand ocd_nand init > Debug: 282 8147 tcl.c:521 handle_nand_init_command(): Initializing > NAND devices... > Debug: 283 8148 command.c:151 script_debug(): command - ocd_command > ocd_command type ocd_pld init > Debug: 284 8149 command.c:151 script_debug(): command - ocd_pld ocd_pld init > Debug: 286 8149 pld.c:232 handle_pld_init_command(): Initializing PLDs... > > I'm not sure if Freddie's OpenOCD is built using libftdi-1.0, which > previous e-mails indicate may solve this problem. As a last-ditch > effort to try libftdi-1.0, I replaced th
[Openocd-development] couldn't read enough bytes from FT2232 device (0 < 81)
This problem again. I see plenty of e-mails in the past supposedly addressing it, but none worked for me. I'm trying to use a TI/Blackhawk USB100v2, which I think is supposed to be identical to an XDS100v2, so I am using the interface/xds100v2.cfg file. I'm using Freddie's OpenOCD 0.5.0 build under Windows 7. Debug: 231 123 ft2232.c:2469 ft2232_init(): ft2232 interface using shortest path jtag state transitions Debug: 232 123 ft2232.c:2342 ft2232_init_libftdi(): 'ft2232' interface using libftdi with 'xds100v2' layout (0403:a6d0) Debug: 233 129 ft2232.c:2389 ft2232_init_libftdi(): current latency timer: 2 Debug: 234 130 ft2232.c:2400 ft2232_init_libftdi(): FTDI chip type: 4 "2232H" Debug: 235 131 ft2232.c:2426 ft2232_set_data_bits_low_byte(): 80 3a 7b Debug: 236 131 ft2232.c:2446 ft2232_set_data_bits_high_byte(): 82 00 59 Debug: 237 132 ft2232.c:2446 ft2232_set_data_bits_high_byte(): 82 86 59 Info : 238 132 ft2232.c:647 ft2232h_ft4232h_clk_divide_by_5(): max TCK change to: 3 kHz Debug: 239 134 core.c:1602 adapter_khz_to_speed(): convert khz to interface specific speed value Debug: 240 134 core.c:1606 adapter_khz_to_speed(): have interface set up Debug: 241 135 ft2232.c:615 ft2232h_ft4232h_adaptive_clocking(): 96 Debug: 242 135 core.c:1602 adapter_khz_to_speed(): convert khz to interface specific speed value Debug: 243 136 core.c:1606 adapter_khz_to_speed(): have interface set up Info : 244 136 core.c:1424 adapter_init(): RCLK (adaptive clock speed) Debug: 245 137 openocd.c:137 handle_init_command(): Debug Adapter init complete Debug: 246 137 command.c:151 script_debug(): command - ocd_command ocd_command type ocd_transport init Debug: 247 138 command.c:151 script_debug(): command - ocd_transport ocd_transport init Debug: 249 138 transport.c:255 handle_transport_init(): handle_transport_init Debug: 250 139 ft2232.c:1749 xds100v2_reset(): trst: 0, srst: 0, high_output: 0x96, high_direction: 0x59 Debug: 251 139 core.c:713 jtag_add_reset(): SRST line released Debug: 252 140 core.c:737 jtag_add_reset(): TRST line released Debug: 253 140 core.c:329 jtag_call_event_callbacks(): jtag event: TAP reset Debug: 254 141 command.c:151 script_debug(): command - ocd_command ocd_command type ocd_jtag arp_init Debug: 255 141 command.c:151 script_debug(): command - ocd_jtag ocd_jtag arp_init Debug: 256 142 core.c:1435 jtag_init_inner(): Init JTAG chain Debug: 257 142 core.c:329 jtag_call_event_callbacks(): jtag event: TAP reset Debug: 258 143 core.c:1055 jtag_examine_chain(): DR scan interrogation for IDCODE/BYPASS Debug: 259 143 core.c:329 jtag_call_event_callbacks(): jtag event: TAP reset Error: 260 4140 ft2232.c:590 ft2232_read(): couldn't read enough bytes from FT2232 device (0 < 81) Error: 261 4140 ft2232.c:845 ft2232_send_and_recv(): couldn't read from FT2232 Error: 262 4141 core.c:1479 jtag_init_inner(): Trying to use configured scan chain anyway... Debug: 263 4141 core.c:1219 jtag_validate_ircapture(): IR capture validation scan Error: 264 8140 ft2232.c:590 ft2232_read(): couldn't read enough bytes from FT2232 device (0 < 2) Error: 265 8140 ft2232.c:845 ft2232_send_and_recv(): couldn't read from FT2232 Debug: 266 8141 core.c:329 jtag_call_event_callbacks(): jtag event: TAP reset Warn : 267 8141 core.c:1503 jtag_init_inner(): Bypassing JTAG setup events due to errors Debug: 268 8142 openocd.c:150 handle_init_command(): Examining targets... Debug: 269 8142 command.c:151 script_debug(): command - ocd_command ocd_command type ocd_flash init Debug: 270 8143 command.c:151 script_debug(): command - ocd_flash ocd_flash init Debug: 271 8143 log.c:437 keep_alive(): keep_alive() was not invoked in the 1000ms timelimit (8143). This may cause trouble with GDB connections. Debug: 274 8144 tcl.c:912 handle_flash_init_command(): Initializing flash devices... Debug: 275 8145 command.c:151 script_debug(): command - ocd_command ocd_command type ocd_mflash init Debug: 276 8145 command.c:151 script_debug(): command - ocd_mflash ocd_mflash init Debug: 278 8146 mflash.c:1331 handle_mflash_init_command(): Initializing mflash devices... Debug: 279 8146 command.c:151 script_debug(): command - ocd_command ocd_command type ocd_nand init Debug: 280 8147 command.c:151 script_debug(): command - ocd_nand ocd_nand init Debug: 282 8147 tcl.c:521 handle_nand_init_command(): Initializing NAND devices... Debug: 283 8148 command.c:151 script_debug(): command - ocd_command ocd_command type ocd_pld init Debug: 284 8149 command.c:151 script_debug(): command - ocd_pld ocd_pld init Debug: 286 8149 pld.c:232 handle_pld_init_command(): Initializing PLDs... I'm not sure if Freddie's OpenOCD is built using libftdi-1.0, which previous e-mails indicate may solve this problem. As a last-ditch effort to try libftdi-1.0, I replaced the libfti.dll in Freddie's bin directory with the libftdi.dll from Xiaofan's build (http://code.google.com/p/picusb/downloads/detail?name=libftdi1_17July2011_mingw32_mingw64.zip&can=2&q=). I get the same result. Anybody have any hin
Re: [Openocd-development] Versaloon driver update fix, and about jtag_usb_open
On 11 July 2011 19:03, simon qian wrote: > Is this attached patch OK? > > About SWD support, I can check the current OpenOCD code today > and provide a todo list according to my OpenOCD swd patch which > has been tested for a long time. > > 2011/7/11 simon qian >> >> OK, I'll try fix it soon. >> >> 2011/7/11 Peter Stuge >>> >>> simon qian wrote: >>> > Attachment is the versaloon driver update, please commit if no problem. >>> >>> Thanks! i will commit i hear no objections Spen ___ 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 August 2011 11:42, Steve Bennett wrote: > 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 > working fine with a clean tree - thanks. Spen ___ 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] [PATCH] A fix (was Re: Git revision string missing from banner)
On 15 August 2011 23:21, Andreas Fritiofson
wrote:
>
>
> On Mon, Aug 15, 2011 at 5:03 PM, Jie Zhang wrote:
>>
>> On Mon, Aug 15, 2011 at 9:35 AM, Spencer Oliver
>> wrote:
>> > On 15 August 2011 14:22, Eric Wetzel 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
>
true, feel free to update
Spen
___
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 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 Spen ___ 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 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 Spen ___ 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
