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] 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-swd merging
On Wed, Jun 15, 2011 at 11:06 PM, Rodrigo Rosa rodrigorosa...@gmail.com 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. the idea is to become transport independent, so the context and queue will be now part of given transport. 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. this must be fixed after transport is functional, 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... Best regards! :-) Tomek btw. maybe automatically executing autoreconf for libswd submodule will fix the problem you mentioned.. i have created configure script to avoid this, but there seems to be someissues with that.. will have to take closer look :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] openocd-swd merging
hi! i've spamming tomek's personal email, switching to here to share a bit more :) i'm having some problems with the opencd-swd branch. i had to copy aclocal and other stuff from /usr/share/ to /usr/local/share/ to get bootstrap to work correctly. this is probably because of freeBSD vs LSD stuff (don't know much about the differences) these patches are based on the openocd-swd branch at git://repo.or.cz/openocd/libswd.git: 0001-edits-to-compile: this patch is what i need to do after: git clone -b openocd-swd git://repo.or.cz/openocd/libswd.git test_swd to get stuff to compile. 0002-added-my-test-stuff.patch this is some code i added/modified to test my stuff. it basically adds a copy of the ktlink_swd but with a different name. the plan was to play around with it to get it to suite my needs. at this point i can get the pre-swd stuff working, but when trying to use the interface minimodule_swd.cfg i get a runtime error: ../tcl/target/dsp568013.cfg:29: invalid command name jtag in procedure 'script' at file embedded:startup.tcl, line 58 at file ../tcl/target/dsp568013.cfg, line 29 the same target config works fine with a ft2232 layout instead of a ft2232_swd layout (for example minimodule.cfg). my system: cat /proc/version Linux version 2.6.32-32-generic (buildd@roseapple) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #62-Ubuntu SMP Wed Apr 20 21:54:21 UTC 2011 cat /etc/issue Ubuntu 10.04.2 LTS \n \l any ideas on how to debug this? i'm finding it hard to get to the error, not sure how to dig down from the tcl layer. thanks! -- Rodrigo. 0001-edits-to-compile.patch Description: Binary data 0002-added-my-test-stuff.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd-swd merging
Hello Rodrigo :-) On Tue, Jun 14, 2011 at 7:12 PM, Rodrigo Rosa rodrigorosa...@gmail.com wrote: i had to copy aclocal and other stuff from /usr/share/ to /usr/local/share/ to get bootstrap to work correctly. this is probably because of freeBSD vs LSD stuff (don't know much about the differences) Hmm, try runing the autogen.sh at submodules/libswd, this will run autotools and recreate configure script, maybe the configure scripts somehow depend on my system (FreeBSD) or there is something wrong with the Ubintu ;-P these patches are based on the openocd-swd branch at git://repo.or.cz/openocd/libswd.git: 0001-edits-to-compile: this patch is what i need to do after: git clone -b openocd-swd git://repo.or.cz/openocd/libswd.git test_swd to get stuff to compile. helper/types.h seems to be openocd issue. i also commented part definig the _Bool. PCMD_SIZE is a good idea, although I would put it in bitbang.h and rename it into something more readable, like PARAM_COMMAND_MAX_LEN, I'll fix that, thanks :-) 0002-added-my-test-stuff.patch this is some code i added/modified to test my stuff. it basically adds a copy of the ktlink_swd but with a different name. the plan was to play around with it to get it to suite my needs. I'll add the patch for MINIMODULE as it is now for you to be able to test some stuff :-) I am considering total inetrface initialization from configuration script - this way there would be no need to recompile binary to add new interface/layout. This is now possible with interface_signal and bitbang :-) at this point i can get the pre-swd stuff working, but when trying to use the interface minimodule_swd.cfg i get a runtime error: ../tcl/target/dsp568013.cfg:29: invalid command name jtag in procedure 'script' at file embedded:startup.tcl, line 58 at file ../tcl/target/dsp568013.cfg, line 29 the same target config works fine with a ft2232 layout instead of a ft2232_swd layout (for example minimodule.cfg). Please note that I did not get into TARGET yet, so this is the possible cause! Program is trying to call jtag target routines from swd transport because it does not know the swd yet... although there is backend ready to do this. Ill do it as my first step after new rebasing :-) any ideas on how to debug this? i'm finding it hard to get to the error, not sure how to dig down from the tcl layer. Well, using GDB to debug TCL commands can be tricky, you should place breakpoints in important places then continue from one to another.. this is how I do the stuff, maybe there is some better way. It would be easier with clean program flow. Maybe you should try at transport-init() this is the first place where SWD bus is being interrogated for targets. Still, ft2232-transfer() is not yet verified. Good luck! :-) Tomek ps/2: Please move to general swd support in openocd as this discussion is not really about rebasing/merging :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
