Re: [Openocd-development] openocd-swd merging
On Wed, Jun 15, 2011 at 11:06 PM, Rodrigo Rosa rodrigorosa.lg at gmail.com https://lists.berlios.de/mailman/listinfo/openocd-development wrote: / i'm not sure i'm getting this right, i think i know very little about // how this stuff works... // // i had modified ft2232.c // in ft2232_execute_queue, instead of doing layout-blink was using some // mpsse commands to set/clear read/write gpio pins available on the // ft2232, which are not used by jtag. / SWD and other transports will use bitbang() and transfer() new interface methods to work on the bus. queue_flush() / execute_queue() is jtag only function and should not be used for transports other than jtag, as it is too jtag-only as it works on commands queued on CMD_CTX, but these are jtag only. BAD ! and WHY it is too JTAG-ONLY? For me the queue_flush and execute_queue should be the mechanism to be used for ALL transport, JTAG and new one as SWD. As you can see, the queue management is done in the DRIVERs, since it is dongle specific. I remember when I helped Dominic Rath, the author of openocd, about to enqueue command for having a better download speed. OpenOCD start with JTAG transport, but the mechanism of queue should be present for any king of transport. If not, we will degrade the transport speed. We ALL know the pure bitbang is really bad when we talk about USB-x-transport due to the latency of the USB. There are ways to have both SWD and JTAG passed in a queue of command, and the same queue. By definition, a queue of commands is not related to any transport. The command queue just pack the command bytes to have a better speed, larger byte packets. the idea is to become transport independent, so the context and queue will be now part of given transport. SWD is specific data transport protocol as the JTAG, as the I2C, as the 1-WIRE.. If libswd is transport independent, why do you call it libswd. Or do you want to provide libjtag libswd libi2c lib1wire. In this case openocd has jtag.c why not a swd.c ? libswd for instance has swd_ctx holding all settings and queue, each libswd function works on this context, so there may be many different contexts in use with no collisions. this swd_ctx will be hold by void pointer in transport structure (void so any other context can be used as well). / i need is some way to type my_function_in_ft2232.c some_arg in the // telnet interface so that the function my_function in ft2232.c gets // called... // i managed to make the chip do what i needed without using swd. // maybe i can get around with some patch on ft2232.c and jtag interface... // // how are you testing stuff without the jtag command in the cfg files? / target operations are not yet ready. jtag functions are jtag only. agree there is a mess because i am using some functions or structures having jtag in their name only because some time ago noone considered other transports than jtag, so instead oocd_interface there is jtag_interface etc. Why did you not copy/paste and rename the the JTAG_ by SWD_ and call the SWD_ from you libswd, instead to call JTAG functions from you libswd. OK, this will duplicate the code in the driver, but that's will help to introduce the SWD API. this must be fixed after transport is functional, This should be a priority. i wanted to rename this stuff before but it took too much time, so i decided to first make transport working and later reorganize openocd interals as time is limited... OK, time is limited. But, the bad thing is that the SWD API is not yet specified. With Dominic Rath, we have specified the JTAG API before implementing the specific driver ... ft2232 specifc comment: The ft2232.c must have specific SWD functions, but we cannot write it before we specify the SWD API. We cannot imagine to have a libswd making itself a kind of specifc bitbang calls, just because a specific ft2232 layout (K T Link) needs to tristate the SWD TMSIO signal, by bitbangging the ft2232. The how we tristate the TMSIO is not the job of the libswd, but is the job of the specific driver. Or your libswd should be called libswdmpssebitbangkt. As first step, the openocd should have a swd.c (maybe something like your libswd) as we have jtag.c, with a well defined API. Then each specific driver, as the ft2232, should integrate the SWD API calls. For the ft2232.c, the SWD will certainly be coupled with the specifc layout. Example, the Amontec JTAGkey-3 will come with an other layout than k T Link, so there will be specific SWD transfer for each layout. More, the Amontec JTAGkey-3 will not need to bitbang the FT2232 to tristate the SWD TMSIO, but will use pure mpsse shift only :-) .) Maybe my comments could be again a little bit negative to you, sorry. But I try to be objective and to help the discussion. Regards, Laurent Gauch http://www.amontec.com/jtagkey.shtml Amontec JTAGkey-2 HIGH-SPEED USB JTAG INTERFACE ADAPTERS CABLES Best regards! :-) Tomek
Re: [Openocd-development] New development version of OpenOCD available at last!
Am 06/16/2011 12:56 AM, schrieb Spencer Oliver: On Jun 15, 2011 11:40 PM, Tomek CEDRO tomek.ce...@gmail.com mailto:tomek.ce...@gmail.com wrote: So is there anyone else wanting to release 0.4.1 (or any other) from the current source tree?? There were so many people interested... I am all for a 0.50 release. AOL mee to. /AOL I think the long time (with lots of minro improvements) since the last release warrants a 0.5 version, even if ist does not have a big new feature. Version numbers are cheap - SWD can be 0.6. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd-swd merging
Hello Laurent :-) On Thu, Jun 16, 2011 at 7:25 AM, Laurent Gauch laurent.ga...@amontec.com wrote: BAD ! and WHY it is too JTAG-ONLY? ask guys that wrote it, you mentioned helped in this ;-) For me the queue_flush and execute_queue should be the mechanism to be used for ALL transport, JTAG and new one as SWD. As you can see, the queue management is done in the DRIVERs, since it is dongle specific. should be, but if you look at the source code you will understand why creating generic bitstream and signal driving routines was more useful to implement ANY transport in a clean fashion rather than further expanding switch/case and additional structures. urjtag had this done from begining and it was almost trivial to implement swd and it is trivial to implement an other transport.. except its less use of it than in openocd. I remember when I helped Dominic Rath, the author of openocd, about to enqueue command for having a better download speed. OpenOCD start with JTAG transport, but the mechanism of queue should be present for any king of transport. who said there is no queue and there can be no optimalization in transfer()? If not, we will degrade the transport speed. We ALL know the pure bitbang is really bad when we talk about USB-x-transport due to the latency of the USB. for ft2232 its using mpsse so there is one layer of data queueing in program memeory queue and then in mpsse chip buffer. if functionality is verified and functional you are entitled to optimise its efficiency.. now i concentrate to create clean and versatile design that works :-) There are ways to have both SWD and JTAG passed in a queue of command, and the same queue. By definition, a queue of commands is not related to any transport. The command queue just pack the command bytes to have a better speed, larger byte packets. again noone said there is no queue. openocd commands are queued as they were, calling commands that call driver to flush data :-) the idea is to become transport independent, so the context and queue will be now part of given transport. SWD is specific data transport protocol as the JTAG, as the I2C, as the 1-WIRE.. If libswd is transport independent, why do you call it libswd. libswd is a standalone library that implements low level swd transport. the bridge between libswd and openocd (and its higher layers as target) must comply with current openocd design. libswd was already inegrated with urjtag using ONLY 4 functions (!). the case with openocd is different because organization of the program is different, much more complex. the modular design and independence of each of the components means that we have functional boxes that can be tied together, with no fear that when we remove one box the others wont work. Or do you want to provide libjtag libswd libi2c lib1wire. In this case openocd has jtag.c why not a swd.c ? yes! each transport will hava its own subdirectory or even library. there is still jtag.c because full code redesign and rewrite of openocd will take few months to accomplish, i have mentioned that, while as for now i just want o make swd work least invasive as possible. Why did you not copy/paste and rename the the JTAG_ by SWD_ and call the SWD_ from you libswd, instead to call JTAG functions from you libswd. OK, this will duplicate the code in the driver, but that's will help to introduce the SWD API. when the job is finished i can respond to such questions, right now i am repeating myself on things that are unfinished and might change soon :-) i wanted to rename this stuff before but it took too much time, so i decided to first make transport working and later reorganize openocd interals as time is limited... OK, time is limited. But, the bad thing is that the SWD API is not yet specified. With Dominic Rath, we have specified the JTAG API before implementing the specific driver the api is selected by ADIv5 and existing target implementation in a form of arm_adi_v5.c. just as it works for jtag iam working to make it work with swd. why it is undocummented like the rest of the code? ask the authors :-) if you want the api/reference to the libswd take look at the project website :-) Best regards, Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd-swd merging
One more time - SWD transport and implementation is not yet finished! The sources are available for you to get familiar the direction changes are going, but they may change slightly as the work progress... :-) You know the interface signals invention and the bitband, so you can work on new transports in the source code or even tcl scripts that can make them happen. In my opinion this is nice improvement :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd-swd merging
Patches for new features to be integrated into openocd/master are ready in most part. Its working in my trunk but does not yet in openocd master, probably this is the problem with rebasing Oyvind mentioned... work in progres.. the solution will appear as next patch: http://repo.or.cz/w/openocd/libswd.git/shortlog/refs/heads/openocd-ifsigbitbang btw. I also have to play this game of everyday life so i cannot sit on this 150% time :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd-swd merging
More information on SWD work in general can be found at http://stm32primer2swd.sf.net/ -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd-swd merging
btw. I also have to play this game of everyday life so i cannot sit on this 150% time :-) My goal as a maintainer with your SWD work, is to get it into a form where others can work on it effectively. Unless we can do this, it will be pretty much worthless to the OpenOCD community. This means continuing your work to make the patches palatable, moving stuff into the master branch that are prerequisites, but unrelated to swd and rebasing your work on the OpenOCD master branch. -- Ø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] Openocd release known issues
On 16 June 2011 05:38, Steve Bennett ste...@workware.net.au wrote: On 16/06/2011, at 7:49 AM, Spencer Oliver wrote: On Jun 15, 2011 10:30 PM, Øyvind Harboe oyvind.har...@zylin.com 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
[Openocd-development] [PATCH] adding interface_signal and bitbang functionalities
This is the patch pack that should add interface_signal() and bitbang() functionality (binary backend + tcl frontend) to the interface API + example implementation for FT2232 interfaces (layout independent). Patches can be applied on top of the current GIT HEAD. Please verify their functionality as this is result of stripped patching from my work-in-progress-fork. The example usage is following: %telnet localhost Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Open On-Chip Debugger interface_signal add RnW 0x1000 interface_signal add LED 0x8000 interface_signal add srst 0x0a00 interface_signal list Interface Signal Name |Mask| Value -- RnW | 0x1000 | 0x1000 LED | 0x8000 | 0x8000 srst | 0x0A00 | 0x0A00 bitbang led=hi LED=0x8000 bitbang led=lo LED=0x bitbang led=hi LED=0x8000 interface_signal list Interface Signal Name |Mask| Value -- RnW | 0x1000 | 0x1000 LED | 0x8000 | 0x8000 srst | 0x0A00 | 0x0A00 bitbang led=lo LED=0x interface_signal list Interface Signal Name |Mask| Value -- RnW | 0x1000 | 0x1000 LED | 0x8000 | 0x srst | 0x0A00 | 0x0A00 interface_signal Bad syntax! interface_signal (add|del|list) signal_name [mask] in procedure 'interface_signal' Best regards, Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info 0001-INTERFACE-Adding-new-place-for-generic-interface-dri.patch Description: Binary data 0002-JTAG_INTERFACE-Extended-jtag_interface-API-with-addi.patch Description: Binary data 0003-INTERFACE-Integrating-generic-interface-from-src-int.patch Description: Binary data 0005-ADAPTER-Implemented-TCL-support-for-interface-signal.patch Description: Binary data 0006-OPENOCD-Register-bitbang-TCL-command.patch Description: Binary data 0008-FT2232_DRIVER-Added-bitbang-implementation-backend-t.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] transport selection fix
This patch fixes transport selection mechanism - if transport is defined it will be selected. Before 'jtag' was always selected no matter what transport in fact was supposed to be used. -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info 0004-ADAPTER-Fixed-transport-selection-mechanism-to-suppo.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] minor rename to suggest thread support in future
This patch renames main2() in openocd.c into openocd_thread() that is called from within openocd_main(). This minor function change may suggest thread support/organization in future. -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info 0007-OPENOCD-Renamed-ambiguous-main2-into-openocd_thread-.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] segfault in ftdi_write_data / libusb
On Thu, Jun 16, 2011 at 4:20 PM, Tomek CEDRO tomek.ce...@gmail.com wrote: Did anyone had similar problem? Was anything changed recenlty in the code regarding usb/libusb/libftdi/ft2232? Program received signal SIGSEGV, Segmentation fault. 0x281eaf67 in libusb20_dev_get_speed () from /usr/lib/libusb.so.2 This library is only for FreeBSD. I know this from the name libusb20. libusb and libusb-1.0 on FreeBSD 8.0 and later are just wrapper on top of the FreeBSD libusb20 library. (gdb) bt #0 0x281eaf67 in libusb20_dev_get_speed () from /usr/lib/libusb.so.2 #1 0x281e5357 in usb_get_descriptor_by_endpoint () from /usr/lib/libusb.so.2 #2 0x281de7ad in ftdi_write_data () from /usr/local/lib/libftdi.so.18 #3 0x0808a010 in ft2232_write (buf=0xbfbfd8c9 \200, size=3, bytes_written=0xbfbfd8bc) at ft2232.c:531 #4 0x0808a2c8 in ft2232_bitbang (device=0x0, signal_name=0x819bfa0 led, GETnSET=0, value=0x28455308) at ft2232.c:660 #5 0x08055d56 in handle_bitbang_command (cmd=0xbfbfd934) at bitbang.c:126 I tend to think this may well be a FreeBSD libusb issue. You may want to add USB debug information. And you may also want to update to the latest FreeBSD kernel. I no longer try to use FreeBSD myself. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] segfault in ftdi_write_data / libusb
Yeah, probably I have triggered some but in libusb / freebsd usb stack :-( According to enormous backtrace history this may be one of the race conditions Peter is fighting against...? There is as much information on this: http://pastebin.com/wp3ng0n4 The interesting is that stuff on my fork works fine even on older FreeBSD 8.1 ! Probably I stripped to much stuff, or has changed since I started my fork. My FreeBSD 8.2 is up to date. Will download and install Arch linux and try on that one, then let you know afternoon (I wont install ubuntu as this is evil and will not work without replacing my bootloader to grub2 lol). On Thu, Jun 16, 2011 at 8:53 AM, Xiaofan Chen xiaof...@gmail.com wrote: On Thu, Jun 16, 2011 at 4:20 PM, Tomek CEDRO tomek.ce...@gmail.com wrote: Did anyone had similar problem? Was anything changed recenlty in the code regarding usb/libusb/libftdi/ft2232? Program received signal SIGSEGV, Segmentation fault. 0x281eaf67 in libusb20_dev_get_speed () from /usr/lib/libusb.so.2 This library is only for FreeBSD. I know this from the name libusb20. libusb and libusb-1.0 on FreeBSD 8.0 and later are just wrapper on top of the FreeBSD libusb20 library. (gdb) bt #0 0x281eaf67 in libusb20_dev_get_speed () from /usr/lib/libusb.so.2 #1 0x281e5357 in usb_get_descriptor_by_endpoint () from /usr/lib/libusb.so.2 #2 0x281de7ad in ftdi_write_data () from /usr/local/lib/libftdi.so.18 #3 0x0808a010 in ft2232_write (buf=0xbfbfd8c9 \200, size=3, bytes_written=0xbfbfd8bc) at ft2232.c:531 #4 0x0808a2c8 in ft2232_bitbang (device=0x0, signal_name=0x819bfa0 led, GETnSET=0, value=0x28455308) at ft2232.c:660 #5 0x08055d56 in handle_bitbang_command (cmd=0xbfbfd934) at bitbang.c:126 I tend to think this may well be a FreeBSD libusb issue. You may want to add USB debug information. And you may also want to update to the latest FreeBSD kernel. I no longer try to use FreeBSD myself. -- Xiaofan -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] segfault in ftdi_write_data / libusb
On Thu, Jun 16, 2011 at 5:09 PM, Tomek CEDRO tomek.ce...@gmail.com wrote: Yeah, probably I have triggered some but in libusb / freebsd usb stack :-( According to enormous backtrace history this may be one of the race conditions Peter is fighting against...? I do not think so. libusb codes under FreeBSD 8.0 and later are not maintained by the libusb project but by FreeBSD project. So Peter is out. :-) There is as much information on this: http://pastebin.com/wp3ng0n4 The interesting is that stuff on my fork works fine even on older FreeBSD 8.1 ! Probably I stripped to much stuff, or has changed since I started my fork. My FreeBSD 8.2 is up to date. Will download and install Arch linux and try on that one, then let you know afternoon (I wont install ubuntu as this is evil and will not work without replacing my bootloader to grub2 lol). If it works under Arch Linux and then you probably have to ask in the FreeBSD USB mailing list. Hans Petter Selasky is the author of the new USB stack for FreeBSD 8.0 and later and the author of the libusb20 library. He is very helpful there. -- Xiaofan ___ 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 s...@spen-soft.co.uk wrote: On 16 June 2011 05:38, Steve Bennett ste...@workware.net.au wrote: On 16/06/2011, at 7:49 AM, Spencer Oliver wrote: On Jun 15, 2011 10:30 PM, Øyvind Harboe oyvind.har...@zylin.com 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 June 2011 13:02, Steve Bennett ste...@workware.net.au wrote: 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 I think there is some confusion again. openocd and jimtcl build ok - even after updating to jimtcl git master. The problem is when make distcheck is run at top level. jim has dummy calls for dist/distcheck and because of that the openocd tarball will have an empty jimtcl dir. So running make distcheck from the openocd dir will fail - it has been like this since we started using jim as a submodule. The solution as mentioned is to either get the user to download jim and install in the jimtcl dir of openocd or we tweak jim to work with make dist. I have been making a few tweaks and got it working, but it is a bodge - life would be simpler if automake was used in jimtcl :) Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Olimex STM32 P107 and H107 board configuration file
Merged. Thanks! -- Ø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] minor rename to suggest thread support in future
Merged. Thanks! -- Ø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] segfault in ftdi_write_data / libusb
On Thu, Jun 16, 2011 at 9:55 AM, Hans Petter Selasky wrote: On Thursday 16 June 2011 11:09:19 Tomek CEDRO wrote: Hi, Hello Hans! Thank you for fast response! :-) Are you using 8-stable? %uname -a FreeBSD c2. 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Fri Feb 18 02:24:46 UTC 2011 r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 Is the issue reproducable? Yes, as you are more familiar with usb design inside FreeBSD and probably have already test environment you can build code from git repository at http://repo.or.cz/w/openocd/libswd.git branch openocd-ifsigbitbang, then: * launch the program with gdb: %gdb ./openocd GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... (gdb) run -c noinit Starting program: /mnt/stuff1200/tmp/swd/target/bin/openocd -c noinit Open On-Chip Debugger 0.5.0-dev-00927-g37eeba8-dirty (2011-06-16-07:31) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : accepting 'telnet' connection from Info : only one transport option; autoselect 'jtag' Interface Signal Name |Mask| Value -- Interface Signal Name |Mask| Value -- led | 0x8000 | 0x8000 bitbang led=lo Program received signal SIGSEGV, Segmentation fault. 0x281eaf67 in libusb20_dev_get_speed () from /usr/lib/libusb.so.2 * launch telnet and do the following to cause crash: %telnet localhost Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Open On-Chip Debugger source [find interface/kt-link.cfg] only one transport option; autoselect 'jtag' interface_signal list Interface Signal Name |Mask| Value -- interface_signal add led 8000 interface_signal list Interface Signal Name |Mask| Value -- led | 0x8000 | 0x8000 bitbang led=lo Connection closed by foreign host. Are you reading and writing data from separate threads? No. The usb communication is done with FT2232H device using libftdi 0.17_1 Are any buffers located on the stack? None of my intent ;-) The backtrace looks suspicious anyway: #1257 0xbfbfef15 in ?? () No symbol table info available #1258 0xbfbfef24 in ?? (). No symbol table info available. #1259 0xbfbfef2f in ?? () No symbol table info available. #1260 0xbfbfef40 in ?? () No symbol table info available. #1261 0xbfbfef4c in ?? () No symbol table info available. #1262 0xbfbfef5f in ?? () No symbol table info available. #1263 0x in ?? () No symbol table info available. #1264 0x0003 in ?? () No symbol table info available. #1265 0x08048034 in ?? () No symbol table info available. #1266 0x0004 in ?? () No symbol table info available. #1267 0x0020 in ?? () No symbol table info available. #1268 0x0005 in ?? () No symbol table info available. #1269 0x0007 in ?? () No symbol table info available. #1270 0x0006 in ?? () No symbol table info available. #1271 0x1000 in ?? () No symbol table info available. #1272 0x0008 in ?? () No symbol table info available. #1273 0x in ?? () No symbol table info available. #1274 0x0009 in ?? () No symbol table info available. #1275 0x0804afb0 in ?? () No symbol table info available. #1276 0x0007 in ?? () No symbol table info available. #1277 0x28191000 in ?? () No symbol table info available. #1278 0x000f in ?? () Please let me know if this is enough information to trace that bug. You can reproduce it easily with the program from the repository I have prodived (git clone git://repo.or.cz/openocd/libswd.git -b openocd-ifsigbitbang openocd-ifsigbitbang; cd openocd-ifsigbitbang; ./bootstrap; ./configure ... ) Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] transport selection fix
On Thu, Jun 16, 2011 at 5:50 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: I take it is just a bugfix? Yes - it changes: retval = allow_transports(CMD_CTX, jtag_interface-transports ? : jtag_only); into: retval = allow_transports(CMD_CTX, jtag_interface-transports ? jtag_interface-transports : jtag_only); Which was obvious mistake or cautious precaution :-) :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] transport selection fix
Merged. -- Ø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] transport selection fix
On Thu, Jun 16, 2011 at 8:02 PM, Tomek CEDRO tomek.ce...@gmail.com wrote: On Thu, Jun 16, 2011 at 5:50 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: I take it is just a bugfix? Yes - it changes: retval = allow_transports(CMD_CTX, jtag_interface-transports ? : jtag_only); into: retval = allow_transports(CMD_CTX, jtag_interface-transports ? jtag_interface-transports : jtag_only); Which was obvious mistake or cautious precaution :-) :-) Not true! Your patch doesn't fix a bug, because there is none. a ? : b is equivalent to a ? a : b, unless evaluating a has side-effects or if a is volatile, since it's only evaluated once in the former case and twice in the latter. I don't think jtag_interface-transports is neither volatile nor a macro with side-effects. So, in the name of portability (?: is a GCC extension [1]) and clarity, I'd say this patch is valid, but not for the reasons given in the patch comment. /Andreas [1] http://gcc.gnu.org/onlinedocs/gcc/Conditionals.html ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Openocd release known issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Spencer Oliver scrisse: The solution as mentioned is to either get the user to download jim and install in the jimtcl dir of openocd or we tweak jim to work with make dist. I have been making a few tweaks and got it working, but it is a bodge - life would be simpler if automake was used in jimtcl :) Given that jimctl is a third-party package, IMHO its hypothetical dist target won't work anyway (wouldn't it just create a tarball-in-tarball?). I think you really need something along the line of the following patch. Let me know if it works for your make dist needs (after a fresh autotool-ization), if so I can cook a proper git commit out of it. Cheers, Luca diff --git a/Makefile.am b/Makefile.am index b31bcea..5187f7b 100644 - --- a/Makefile.am +++ b/Makefile.am @@ -18,6 +18,7 @@ endif SUBDIRS += src doc EXTRA_DIST = \ + jimtcl \ Doxyfile.in \ tools/logger.pl - -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 3BFB9FB3 `- http://www.debian.org | Debian GNU/Linux Developer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk36hOwACgkQRqobajv7n7PQ8ACgsWIL8i0NjGj7yPHFDeIo3fq+ vSMAnjX5Zm4nYdUrFl8O+ohipIB40+QY =rH3O -END PGP SIGNATURE- ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] New development version of OpenOCD available at last!
On 18:05 Wed 15 Jun , Øyvind Harboe wrote: On Wed, Jun 15, 2011 at 5:33 PM, Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com wrote: On 23:04 Tue 07 Jun , Ųyvind Harboe wrote: Nobody has stepped up to do the work of being a release manager. If no-one do it I'll Much appreciated! You can read up on the scripts to produce releases in openocd and post your plan to the list. ok give me one day and I prepare a release plan proposition Best Regards, J. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] RFC Release Cycle
Hi all, I'd like to propose the following release cycle For the people familiar with Linux kernel its basically the same 2 development window: merge window fix window We will get 2 weeks of merge window where any code can be merge in the master branch. After will start the fix window of 6 weeks to stabilized the code. During the first week of the fix window reviewed patches that are not too much intrusive could be merged if they miss the merge window. Otherwise ONLY fix will be merge in the master branch. We will get 1 RC per week so 6 RC for each release. If the release is enough stable or need more time to be stabilized the fix window could reduced or extended based on the need. At the same time of the opening of the fix-window a next branch will be created where the new development will be done and will be merged at the beginning of the next merge window. At the same time of the opening of the merge window a stable branch will be created to accept ONLY bug fix a specific release. Specific work flow: If highly intrusive patch need to be merged they must go first during the merge window and must be present in the next branch for at least 2 weeks. Release number scheme 0.x.0 for the release 0.x.0-rcx for the rc 0.x.y for the stable branch as example the 0.5.0 release it will be 0.5.0-rc1 for the first RC 0.5.0 for the release 0.5.1 for the stable first release Next release plan: Merge window close this sunday 17th june relase 0.5.0 plan for the 29th July Best Regards, J. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
