Re: [Openocd-development] pointers modification within functions
Uhm, I have found a solution :-) The problem is that C (or GCC) can only change variable out of function using *variable=value construct. This *variable syntax is essential. This is the only possible way of using pointer to pass information outside function. But this way it is only possible to pass the VALUE, not the pointer itself. That is why we need to use double pointer to pass out the address of the pointer from inside function, even though it seems rational and sensible to simply change the pointer content to point to another place in the memory. All this because GCC (or maybe all C compilers) use local variables to store pointers! So the pointer content operations does not propagate back to caller functions, they can only change the existing memory location marked before any function call! You can change some pointer inside function but the calling function will overwrite it with its local copy on return... For me this is one star too much, but that's how things are, maybe good for security. All this pointer stuff is necessary to access location of the queue after flush, to read back the result, but also to make sure we are reading correct response and this is done by comparison of result location with location stored when result location was created on the queue (as there are many others)... To sum up: single pointer parameter only gives chance to change value of the location set prior function call, but to get back the location itself you need a double pointer. 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] pointers modification within functions
Hmm, things seems to be more suble :-) I have tried a trick with using int *a; fun(int* a); and it indeed works but the address is trimmed no matter what type a is (int*, long*, void*) and this causes problems. 21 int a1=0, a2=0; (gdb) s 22 double *a3; (gdb) 23 a3=NULL; (gdb) f1 (pf11=0x7fffe71c, pf12=0x7fffe718, pf13=0x7fffe710) at pointertest.c:17 17 return f2(pf11, pf12, pf13); (gdb) f2 (pf21=0x7fffe71c, pf22=0x7fffe718, pf23=0x7fffe710) at pointertest.c:6 6stuff=calloc(1,sizeof(int)); (gdb) 7if (!stuff) exit(-1); (gdb) 8*stuff=0xDEADBEEF; (gdb) 9printf(stuff[@%X]=%X\n, stuff, *stuff); (gdb) p/x stuff $1 = 0x800a04090 (gdb) p/x *stuff $2 = 0xdeadbeef (gdb) s stuff[@A04090]=DEADBEEF 10 *pf21=stuff; (gdb) 11 *pf22=*stuff; The most important lines below: (gdb) 12 *pf23=stuff; (gdb) 13 return 0; (gdb) p/x pf23 $3 = 0x7fffe710 (gdb) p/x *pf23 $4 = 0xe6b0 (gdb) p/x stuff $5 = 0x7fffe6b0 stuff is the address of the memory location. I want to write that location to my pointer, but its trimmed although variable IS a pointer. Maybe this is because of a type The most interesting part is the *variable=value construct because without this we cannot get data out of the function. Even if we change the address contained within a pointer variable we will get the data from an old address!!! Note that below I did not use *variable=value but simple variable=value, variable changed but it still points to the old memory location (0x00 instead 0xdeadbeef) (gdb) p/x stuff $1 = 0x7fffe6b0 (gdb) p/x stuff $2 = 0x800a04090 (gdb) p/x *stuff $3 = 0xdeadbeef (gdb) s stuff[@A04090]=DEADBEEF 10 *pf21=stuff; (gdb) 11 *pf22=*stuff; (gdb) 12 pf23=stuff; (gdb) 13 return 0; (gdb) p/x pf23 $4 = 0x7fffe698 (gdb) p/x pf23 $5 = 0x7fffe6b0 (gdb) p/x *pf23 $6 = 0x0 I think this is some memory corruption protection mechanism implemented by a compiler... Well I have to live with double pointers ;-P -- 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] pointers modification within functions
With current design of OpenOCD it is impossible to queue read operations as results are returned using single pointers, the read operation needs to be performed inside of a function that will return a result, otherwise we can only get a value given at queue time but not a flush time. LibSWD can queue many read operations, but: -data are passed as double pointers and all become available after flush -data are read out manually from the queue after flush -user flush queue one by one and trace operation result log values (request/ack/data/parity). I have to perform execute queue on read operation. But this is current behavior anyway..? :-) -- 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] pointers modification within functions
On Thu, Nov 3, 2011 at 10:43 PM, Tomek CEDRO tomek.ce...@gmail.com wrote: I have to perform execute queue on read operation. Luckily it only requires minor change of SWD_OPERATION_ENQUEUE into SWD_OPERATION_EXECUTE parameter :-P :-) -- 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] include linux/scripts in OpenOCD project?
On Wed, Nov 2, 2011 at 8:03 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: Should we? What does these scripts do? Will they work on FreeBSD? :-P :-) -- 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] include linux/scripts in OpenOCD project?
On Wed, Nov 2, 2011 at 8:09 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: On Wed, Nov 2, 2011 at 9:06 PM, Tomek CEDRO tomek.ce...@gmail.com wrote: On Wed, Nov 2, 2011 at 8:03 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: Should we? What does these scripts do? Will they work on FreeBSD? :-P :-) They allow you to check patches for coding style, remove whitespace, automatically indent, etc. Aaah, ok, I finally upgraded my hardware so I can run VM and test stuff on/for other operating systems, this might be good option to have everything in one place :-) -- 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] pointers modification within functions
Hey,
I have some problems with pointers and need some support plz ;-)
int swd_bus_read_ack(swd_ctx_t *swdctx, swd_operation_t operation, char **ack){
swd_cmd_enqueue_miso_ack(swdctx, ack);
}
int swd_cmd_enqueue_miso_ack(swd_ctx_t *swdctx, char **ack){
if (swdctx==NULL) return SWD_ERROR_NULLCONTEXT;
int res;
swd_cmd_t *cmd;
cmd=(swd_cmd_t *)calloc(1,sizeof(swd_cmd_t));
if (cmd==NULL) return SWD_ERROR_OUTOFMEM;
if (ack!=NULL) *ack=cmd-ack;
cmd-bits=SWD_ACK_BITLEN;
cmd-cmdtype=SWD_CMDTYPE_MISO_ACK;
res=swd_cmd_enqueue(swdctx, cmd); //should be 1 on success
if (res1) free(cmd);
return res;
}
main(){
int *ack;
swd_bus_read_ack(swdctx, operation, ack);
}
The problem is:
1. I need to use double pointers to return back the address of the
queue element (*ack=cmd-ack).
2. If I use single pointer *ack the value of the ack is only changed
inside swd_cmd_enqueue_miso_ack() but after its return to
swd_bus_read_ack() the ack value is taken back to the state as it was
before swd_cmd_enqueue_miso_ack() call.
3. I have tried to use single pointer *ack and call
swd_bus_read_ack(swdctx, operation, ack) but is changes nothing.
This makes impossible to give back data on queue_dp_read(). There is
something wrong with these pointers!!! Help! :-)
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] pointers modification within functions
Hello Andreas :-)
On Thu, Nov 3, 2011 at 12:36 AM, Andreas Fritiofson
andreas.fritiof...@gmail.com wrote:
This won't even compile. You pass a pointer-to-int, but swd_bus_read_ack
expects a pointer-to-pointer-to-char.
naah this is only typo in mind-shortcut, code builds well, but i dont
get it why i cannot use single pointer to pass back a memory location
to function caller... this is what pointers exist..
i have constructed this simple program to test if this can work - it
can but i need to pass a address of a variable and write value to that
variable, playing with pointers require double pointer :-( ill try
this on more complex application :-)
#include stdlib.h
#include stdio.h
int f2(int *pf21, int *pf22){
int *stuff;
stuff=(int*)calloc(1,sizeof(int));
if (!stuff) exit(-1);
*stuff=0xDEADBEEF;
printf(stuff[@%X]=%X\n, stuff, *stuff);
*pf21=stuff;
*pf22=*stuff;
return 0;
}
int f1(int *pf11, int *pf12){
return f2(pf11, pf12);
}
int main(){
int a1=0,a2=0;
f1(a1,a2);
printf(a1[@%X]=%X\na2[@%X]=%X\n, a1, a1, a2, a2);
return 0;
}
--
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 patch: 96c3cbf cortex_m: add missing error checking
Hey does this code is related anyhow to arm_adi_v5 or this is totally alternative solution? -- 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] arm-jtag-ew + swd
On Thu, Oct 20, 2011 at 4:59 AM, Peter Stuge pe...@stuge.se wrote: 1. Continue what David Brownell worked on for FT2232-based adapters 2. Try Tomek's libswd, which I think works so far primarily with (only some?) FT2232-based adapters These are now joined into one :-) Transport and driver for ft2232 are now complete, just need to fix the target so not that much work left, damn im so multiplexed recently :-( 3. Use a Versaloon (e.g. Versaloon Mini, see http://www.versaloon.com/ ) and Simon's patches to OpenOCD Yup. it can upload firmware from what I saw in the logs :-) -- 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] arm-jtag-ew + swd
On Thu, Oct 20, 2011 at 1:49 AM, Peter Stuge pe...@stuge.se wrote: It might be really easy to make the device speak SWD. Devices already speaking SWD for some time, need some small support in Target implementation :-) -- 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] arm-jtag-ew + swd
On Thu, Oct 20, 2011 at 1:52 AM, Tomek CEDRO tomek.ce...@gmail.com wrote: On Thu, Oct 20, 2011 at 1:49 AM, Peter Stuge pe...@stuge.se wrote: It might be really easy to make the device speak SWD. JLink specification is open, from what Ive seen it should be relatively easy to implement generic (tranfer/bitbang functions) driver for this device :-) -- 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] arm-jtag-ew + swd
On Tue, Oct 18, 2011 at 2:47 AM, Michael Ashton d...@gtf.org wrote: Hi, I'm wondering if anyone can say whether it's possible, or might ever be possible, to use the Olimex ARM-JTAG-EW with SWD in OpenOCD? I can't find any mention of SWD in arm-jtag-ew.c, but I'm not sure whether that really means anything. thanks! --Michael Driver is generic for FT2232 devices, you can play with some resistor/diode to make JTAG interface work as SWD :-) -- 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] Change in openocd[master]: docs: update project url's
On Thu, Oct 13, 2011 at 9:47 PM, Uwe Hermann u...@hermann-uwe.de wrote: Please configure gerrit so that the full patch is posted on the mailing list additionally, as it used to be. I personally read lots of patches and discussions offline (e.g. in a train) in my mail client, and I'm pretty sure I'm not the only one who'd prefer if patches would still end up on the list (and in the list archive) in addition to gerrit. yup :-) and the direct reference to the code piece right inline :-) -- 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] gerrit hosting
On Sat, Oct 8, 2011 at 12:11 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: sourceforge does not offer gerrit. Is there a hosting service that does? It is possible to ask SF staff to install it on their servers, take a look at support page, also you can chat on IRC about this topic :-) -- 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] Show of hands for/against gerrit
On Fri, Oct 7, 2011 at 5:48 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: http://code.google.com/p/gerrit/ I have no idea what it does, but I'm very excited! :-) Looks interesting, I wonder if it has mailing list integration or simply use emails for notifications :-) I am a bit afraid of the *.war file extensions :-P -- 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] Atmel SAM3N with OpenOCD 0.5.0
On Thu, Oct 6, 2011 at 9:07 PM, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: That log doesn't show that OpenOCD hangs after accessing flash. The Flash bank access DONE part is wrong, the flash bank has only been set up in OpenOCD, there hasn't been any communication with the target yet. It obviously hangs during init, which could mean just about anything. It's impossible to tell without a debug log (-d3). Hey Andreas, you can try to use GDB and retrace issue (if it does not crash then simply hit the Ctrl+C and use backtrace to see how did this got into such situation) :-) 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] Atmel SAM3N with OpenOCD 0.5.0
On Thu, Oct 6, 2011 at 9:29 PM, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: Of course I could, if it was me having the problem. Which it's not. :) But it's a good idea, I'm sure Attila can try it if the debug log doesn't show anything useful. /Andreas Ah sorry, I only read that last post of yours :-) This is also why I have created separate function for SWD to be able to change debug level of the openocd and libswd independently, so even the bitstream could be retraced without an oscilloscope or the debugger, this comes handy in tracing the target execution and other details :-) I am sure that is is possible to configure and build openocd with debug jtag and/or debug io for more details, have you tried that Attila? :-) 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 mailing lists moving
On Tue, Oct 4, 2011 at 1:26 PM, Spencer Oliver s...@spen-soft.co.uk wrote: Due to the recent news about Berlios closure on 31.12.2011 we are moving the mailing list to sourceforge. http://lists.sourceforge.net/mailman/listinfo/openocd-devel - was http://lists.berlios.de/mailman/listinfo/openocd-development http://lists.sourceforge.net/mailman/listinfo/openocd-commit - was http://lists.berlios.de/mailman/listinfo/openocd-svn was? http://lists.sourceforge.net/mailman/listinfo/openocd-devel - is ? http://lists.berlios.de/mailman/listinfo/openocd-development - was ? http://lists.sourceforge.net/mailman/listinfo/openocd-commit - is ? http://lists.berlios.de/mailman/listinfo/openocd-svn - was ? ;-P -- 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 mailing lists moving
On Wed, Oct 5, 2011 at 1:08 PM, Spencer Oliver s...@spen-soft.co.uk wrote: mmm - must have been a long day Thanks for the correction Have a great evening Spen! :-) -- 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] Fwd: BerliOS will be closed on 31.12.2011
On Fri, Sep 30, 2011 at 5:47 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: FYI, My first instinct is to move the mailing list wholesale to sourceforge. sf.net if ok, i use it for some projects, urjtag use is as well. sad that another open source project meets void. -- 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] ft2232_transfer why bit-by-bit?
On Mon, Sep 26, 2011 at 10:03 AM, Akos Vandra axo...@gmail.com wrote: Is there a good reason why ft2232_transfer uses bit-by-bit mpsse transfer? If not, I would be happy to rewrite it to use bytewise transfer, if the number of bits to be transferred is divisable by 8. Might make things a *little* bit faster... This is the initial version introduced recently to the OpenOCD to allow generic transfers for transport other than JTAG (i.e. SWD), the speed is not that important at the moment because it was used to test the transport, now we need to build and test upper layer. If you like please apply some chunking and byte transfer followed with bit transfer of remaining stuff, but remember to remain API untouched, i.e. data are transferred in/out of the char table etc :-) You can verify the work by reading out the IDCODE register (performed by transport init command). You can freely set debug level of openocd (debug_level command) and libswd (swd loglevel command) to see what happens on the bus (even the bitstream) and/or what is openocd doing. Configuration file needs the interface (and transport) definitions, it also use TAP structure which now resembles the Test Access Port which in this case means a plug or connector to access the logical DAP (Debug Access Port) structure which is our Target, which makes it more backward compatible with existing OpenOCD architecture. Best regards, Tomek ps/2: I will take a look into swd_drv_* issues afternoon :-) -- 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] Fwd: SWD?
On Mon, Sep 26, 2011 at 11:48 AM, Peter Stuge pe...@stuge.se wrote: Akos Vandra wrote: I suspect it is because I have an x64 system where pointers are 64bits in size. The lines listed below try to cast a pointer to an int (signed 32bit), for producing log messages. I think %p should work. Yup, it works perfectly, thank you Peter! There are however some older places where I did not fix that, will happen this afternoon :-) 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] Fwd: ft2232_transfer why bit-by-bit?
On Mon, Sep 26, 2011 at 9:37 PM, Akos Vandra axo...@gmail.com wrote: Sorry, it seems like I wanted to do too much too fast. yup :-) it takes me few months already to do everything from scratch, if it was one day job it would have been (all)ready :-) now the road is straight - the openocd's target :-) Does anyone by chance have designs for such a programmer, that I could build myself? I find 50E too much for the kt_link. Naah this is the cheapest cable on the market with buffered lines for both JTAG and SWD. It is possible however to use standard JTAG cable to work with SWD with one or two resistors maybe some diode - try to guess how, you got the hint already, I wont break your fun :-) :-) 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] Fwd: SWD?
On Mon, Sep 26, 2011 at 9:27 AM, Akos Vandra axo...@gmail.com wrote: swd_libswd_drv_openocd.c: In function ‘swd_drv_mosi_8’: swd_libswd_drv_openocd.c:61: error: cast from pointer to integer of different size swd_libswd_drv_openocd.c:61: error: cast from pointer to integer of different size (..) Fixed, commit sent, thanks for verification! printf now use %p for (void*)pointer :-) -- 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] Fwd: ft2232_transfer why bit-by-bit?
On Mon, Sep 26, 2011 at 10:29 PM, Peter Stuge pe...@stuge.se wrote: I really like the Versaloon project. It supports SWD, and the main author in the project Simon is also quick to send OpenOCD patches for the device. Does Versaloon fully support ARM target, memory access and debug already? If so there is no need to double our work for ft2232, simply connect the drivers and targets :-) -- 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] Fwd: ft2232_transfer why bit-by-bit?
On Mon, Sep 26, 2011 at 10:55 PM, Peter Stuge pe...@stuge.se wrote: I haven't tried it yet, but I believe so. Simon has patches. I think this may be the most up to date source: http://www.versaloon.com/bbs/viewtopic.php?f=2t=2808 Hmm, looks interesting, mem_ap_read_buf_u32() in the openocd HEAD tree use hardcoded jtag for access. I need to take look at the patches :-) http://www.versaloon.com/bbs/download/file.php?id=118 (openocd_0.5.0_patch.zip) is the one to look inside, for openocd.patch. It abstracts this hardcode to instead call dap_queue_dp_scan(). On the other hand there is a not very pretty swd_mode global variable introduced. Hopefully that's easy to solve somehow though. It looks this is the different approach - less modular - globals, no transport, using the common queue for jtag and swd operations :-) I used transport that has its own routines and contex with queue, this is the road towards modules sharing commong api to easily extend functionalities in future... The good thing after reading the patch is that solving the WAIT / FAULT responses from the target seems to make everything work.. shame I have so many different tasks at the moment :-( 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] SWD?
Hello Akos :-) The transport layer is ready and functional using LibSWD[1]. I dont know about how well Versaloon supports the SWD, but I created dedicated driver for FT2232 so it should match your hardware, it is more versatile because it has some TCL interface. The current task is to make Target layer work with SWD because there were some JTAG-only parts of the code in the transport system. You are in the right place and time to help me with the Target and the SWO :-) There is a dedicated git fork for openocd+libswd [2]. You can see my scratchpad on SWD implementation since its beginnings. The current state of the code is that error handling and retransmission needs to be implemented in case target returns WAIT or FAULT response, this is your first task :-) Please ask if you need any additional information :-) The recommended order to get familiar with the organization is [3] [1] [2]. The documentation on the LibSWD website is a bit outdated as it used SVN and I have switched to GIT meanwhile, but I will try to sync repositories asap, you can clone the git repository and make doxygen to have a fresh copy at glance. Best regards :-) Tomek Cedro [1] http://libswd.sf.net [2] http://repo.or.cz/w/openocd/libswd.git [3] 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] Fwd: SWD?
Regarding the LibSWD and OpenOCD relationship: OpenOCD use LibSWD git submodule from the libswd git repository tag v0.2 which can differ a bit from the head. I am working on the v0.2 and periodically add those changes to head. v0.2 is meant to build off the shelf as it has configure scripts pre-compiled, so it will become libswd-0.2 release and it can be used direclty within OpenOCD without bootstrapping (or even autotools generation). You can clone libswd tag v0.2 and it should build right away after ./configure, please let me know if that works for you, if not then I need to fix the libswd, if it does then we need to check the openocd trunk sources (probalby the types.h file). -- 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] Fwd: SWD?
On Sun, Sep 25, 2011 at 4:39 PM, Akos Vandra axo...@gmail.com wrote: Bingo, I am working on Ubuntu 10.10, x64, gcc 4.4.5 (shipped with ubuntu). cool :-) i will prepare the vm then :-) ../../src/helper/types.h:140: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘be_to_h_u16’ exactly, types.h. Please take a look at the original openocd types.h maybe this is working and we will know what is wrong :-) I'll try to spam you less 'til mid october then, I have some work to finish myself, but I have to get going with my thesis as well. :) no problem, i can give you some hints almost right away but i can get to the code for serious in 2...3 weeks. I also finish my diploma, currently waiting for an exam, this is the last delay cause ;-) Also, should we spamming the developer list, or rather continue this discussion personally? I'm not familiar with opensource development *at all*, so I'm not familiar with list policies either. On one hand it may be good information source for other people that want to get into SWD/SWO, so we can post here. We can also post private to minimize the message amount. Let the other developers decide, both options are good for me :-) If you are not that familiar with the development I would also recommend to get into OpenOCD's internals first as it tool some considerable amount of time for me to guess whats going on :-) I can see the reason to better document the SWD work, I will do it in the openocd manual after my diploma exam :-) 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
[Openocd-development] openocd.cfg as symbolic link
Hello! :-) I have found some interesting issue that openocd does not want to use openocd.cfg that is a symbolic link. Are there any considerations behind that? :-) source openocd.cfg couldn't read file openocd.cfg: Too many levels of symbolic links 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] jtag dependendy removed from arm_adi_v5
that does not need to know the payload but only the command (also the command needs parameters so the payload is important) so the universal access with void * is provided. I would rather use it this way. The program structure is very important, for readability and extensibility in future with functionalities we now cannot predict (just as it was jtag centric and it was hard to implement swd). This organization is clean and elegant I think. When we start to mess transport beyond transport there is no need for transport :-) Also the description presented above can be the common API for bith high-level and low-level drivers..? I have already implemented this in dumb-driver ft2232 and also plan to do it with high-level rlink interface but there sooo many tasks on my head, it needs some time and I need a vacation ;-P Best regards! :-) Tomek Cedro -- 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] jtag dependendy removed from arm_adi_v5
I can take a look at this as I'm finishing to solder a hardware that I will finish the SWD implementation in upcoming days, but I would rather not change interface/jtag/transport layer until SWD is done. When its done and working then we can change internals, otherwise we will have two different forks and additional work to do. 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] Coding style
2011/8/29 Michel Catudal michelcatu...@gmail.com: Since we have bigger monitor than in the 70s and 80s why make the code unreadable? The only valid reason for using KR would be 1- You still expect to be stuck with a teletype at times and want to make sure you can see many lines of code at once 2- You can't get yourself to replace your VIC-20 or TRS-80. 3- You are still stuck with a tiny 13 inches or smaller screen. I like multiple commands per line and its not true that it always decrease code readability, sometimes it can allow to write one coherent piece of code in one line (less than 80 characters). This makes code more coherent and easy to edit with my favorite VIM :-) What I dont like about Python for instance is the one-command-per-line and the division code block with tabs - this is why I have started to indent code with one space, no matter what language (some editors can replace tab with multiple spaces and whole program structure is gone, who invented this sh$(# anyway). Just my sixteen in this interesting topic :-) Best regards :-) Tomek Btw. my 8-bit Atari has now 37' LCD HD 100Hz display and its not a teletype haha ;-P :-) :-) -- 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] Errors encountered programming an FPGA using 13MB SVF file
On Sat, Aug 27, 2011 at 3:25 PM, Jie Zhang jzhang...@gmail.com wrote: Maybe making OpenOCD use UrJTAG as a library is more worth the effort than just rewriting ftdi driver. Regards, Jie I proposed this about two years ago but the idea was rejected. In my opinion there is no sense in creating multiple applications with similar functionalities and different problems. Joining efforts would be nice, but as I have insight into both applications right now, they are completely different in design, it would be possible to use transport and drivers from UrJTAG and higher layers such as target from OpenOCD. Also UrJTAG goes into Python, while OpenOCD use JimTCL. This would require enormous effort and clear reorganization of OpenOCD though and this is not a job for one person.. 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] Errors encountered programming an FPGA using 13MB SVF file
On Sat, Aug 27, 2011 at 3:40 PM, Uwe Bonnes b...@elektron.ikp.physik.tu-darmstadt.de wrote: while not a cure for your openocd problem, what about xc3sprog? svn co https://xc3sprog.svn.sourceforge.net/svnroot/xc3sprog xc3sprog It is. I am using Xilinx FPGA right now and xc3sprog is great tool to avoid running iMPACT and sick USB cable organization based on windrv, this is why I recommended this before :-) If you need to use SVF UrJTAG was working for me with Amontec JTAGKey2P and Xilinx FPGA :-) There might be however some interest in fixing the svf parser in openocd - why not to use both sources from OpenOCD and UrJTAG and create a library? :-) 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] Errors encountered programming an FPGA using 13MB SVF file
On Fri, Aug 26, 2011 at 5:10 PM, Sam Jansen sam.jan...@starleaf.com wrote: In attempting to use openocd with an Amontec JTAG key to program a Xilinx FPGA, I encountered a series of issues I though others might be interested in. I don't have sensible proposed solutions for any of the problems I encountered, but perhaps someone on this mailing list is interested all the same. Sam, have you trier UrJTAG? There is support for both Amontec cables and SVF format, I used both with success on my Xilinx Spartan 3A-DSP board :-) You can also consider using XC3SPROG that can upload bitfile directly into FPGA so using iMPACT and SVF is not necessary anymore (there are some issues with SPI Flash though) :-) 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] Jlink SWD Support
Hello Gary :-)
On Tue, Aug 23, 2011 at 2:24 AM, Gary Carlson
gcarl...@carlson-minot.com wrote:
I have zero prior experience with the FT2232 so I took a very brief scan of
its driver code. I get the feeling that this type of device allows fairly
low-level access to interface port pins. If this is true I can see the
logic behind a bitbang function as this provides the generic abstraction
layer between any arbitrary signal name and its corresponding underlying
hardware I/O pin. In theory you can make this type of device sing with just
about anything.
Yes, exactly, this is general IO bridge and libswd is there to
construct packets/bitstream for this kind of device as the interface
knows nothing about transport. This is not true for interface with
some logic, but there might be some way to create general
bitbang/transfer functionalities so we can overcome their limitations
in matter of transport so it can perform operations on transports it
knows nothing about :-)
Libswd dirvers have 4 transfer functions and 2 dedicated TRN
functions. I hava named direction MISO and MOSI to be less confusing
where Master is the OpenOCD. There are functions:
-swd_drv_mosi_8 that send data out of the char array with selected
number of bits {1,..8} - write request, control and parity transfers
-swd_drv_mosi_32 that send data out of the int array with number of
bits {1,..,32} - write data transfers
-swd_drv_miso_8 that read data into char array with selected number of
bits {1,..,8} - read ack and parity transfers
-swd_drv_miso_32 that read data into int array with selected number of
bits {1,..,32} - read data transfters
-swd_drv_miso_trn - sets bus to input/miso
-swd_drv_mosi_trn - sets but to output/mosi
As you can see all those functions require at least only two functions
to work: transfer and bitbang. Maybe there are some high-level
commands to implement them using interface commands...
The transfer function on the other hand looks cursorily like it can be
implemented with the EMU_CMD_HW_JTAG3 command on jlink. Since I really have
not studied libswd in any depth what happens if a particular dongle can only
support the basic transfer but no bitbang command with respect to libswd?
Bitbang is mainly necessary to perform TRN operations, it can be
implemented as this only specific signal RnW (by sending come
interface command) support and return error for other signals. Bitbang
in general also gives ability to create external (tcl?) scripts that
make use of target device without need to hardcode the
functionalities.
Like I indicated in the beginning, I only took a very superficial look at
this, so I may be be missing information or other critical details. Feel
free to chime in with perspective or correct any of my assumptions.
Maybe it is not necessary to use libswd at all with interfaces that
can construct transport packets on their own so high-level-interface
would rather need to use target structure directly if it can. We
need to sort it out to create common API that would suit most
high-level-interfaces, or simply force them to pass our bitstream
generated with some external library (such as libswd) which seems more
versatile but can have some impact on speed..?
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] Jlink SWD Support
Hello Gary :-) On Tue, Aug 23, 2011 at 3:43 PM, Gary Carlson gcarl...@carlson-minot.com wrote: I think the solution with high-level interfaces is to allow them to do their bitstream magic directly if they have that capability and for low-level interfaces turn to libswd or other future libraries for other transports. I have doubts about the feasibility of trying to make most high-level interfaces behave like low-level devices. This would most certainly be a problem for jlink and I suspect for others as well. Personally I think that path is a non-starter. Sure thing this is why asked you what API design would fit best the high-level interfaces still to be common to low-level interfaces :-) Also think that using low-level libraries on high-level interface will allow to use transports that this interface does not support :-) This is why I created transfer and bitbang, but they are only implemented for FT2232 at the moment, I want to work out the RLink but I am critically overloaded with work so I will get to that probably in October :-) Ideally from my perspective the best solution would be to have each dongle -- regardless of the manufacturer -- behave like a high-level device at the OpenOCD driver level using a common unified API that enumerates what capabilities it supports but leaving each driver to decide how to handle bit-blasting activities under the hood. In the case of a high-level device like jlink, most of the driver code would provide pass-thru + necessary glue logic (pretty much what it does now). For low-level devices, this could call on existing libraries like libswd or even new ones for future transports. At the moment there was only jtag_interface structure that had execute() function performing data flush from jtag command queue into hardware in a manner specific to a hardware. This is jtag only and leaves no other option for other transports except we create execite_jtag() execute_swd() and other functions that will flush data from transport specific queue. This would result in having separate subsystem for each transport, which is messy, and that was the reason I have created generic transport and bitbang functions that can be used by any transport or tcl function. Each interface should have this implemented anyway. This way we only need to create small module for transport that would act as bridge between openocd_target and hardware_target. The question is how to do this without making a mess in existing code currently heavily-invested in jtag. I think whatever the API looks like needs to maintain backward compatibility with the existing approach by either providing a superset-based API or alternatively support both a legacy and advanced API. See above :-) I try to be as less invasive as possible but the current design is already messy and not easily extensible :-P The OpenOCD needs general restructurization and cleanup by diviging code into clean modules using common API you are right. I have given this task some months but it was too much work so I suspended it, I can take care of it after SWD if working because this is my main goal at the moment :-) We should use one common context and divide code into modules responsible for specific tasks like interface, transport, target, flash, cpu, os, core, etc. Now all this seems to be put in one place, so it needs really dedicated piece of work :-) Since you have spent a lot more time thinking about this then I have, what is your ideal API scheme in light of the various realities mentioned above? I haven't fiddled in the bowels of OpenOCD much outside the driver level so my ideas may have other problems when tested against reality. The transfer and bitbang allows some basic routines to work on the bus between interface and target DAP/TAP therefore I think all interfaces should have this obligatory, maybe not efficient (i.e. one bit per command, or no bitbang at all if interface sets directions automaticaly), but this would allow some fallback into working solution with all future OpenOCD functionalities, not only limited to those provided by interface logic/commandset. This dedicated functionalities would be interface specific and will provide superior efficiency compared to this generic stuff of course. I would have to take a look at example command set of high-level interface command set, maybe there is some tutorial on this? 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] Jlink SWD Support
In one sentence, as my preference for future extendability I have chosen approach that involves modular design with external submodules (just like in object programming) rather than extending one big structure (i.e. command queue) like it was done before. This should allow adding new functionalities easily and concentrate some people to work on their dedicated modules rather than knowing exactly everything about the whole code structure :-) Maybe bugs/features from one of modules will also have less impact on other modules this way :-) The good example here is the libswd or jimtcl itself that can be automatically fetched from external git submodule repository and provide some functionalities, while extending its functionalities does not change the program code a lot, it provides some external scripting, etc... 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] Jlink SWD Support
Hello Carlson and thank you for your support! :-) On Sun, Aug 21, 2011 at 9:09 PM, Carlson Gary gcarl...@carlson-minot.com wrote: I didn't realize there was a fork for SWD support, so my original attempt was based on the master branch. Nevertheless I cloned the fork that you indicated and immediately ran into a number of compiler issues trying to compile it on a Mac OS X platform. The patch attachment covers most of the changes necessary to address those problems. These should be neutral for other platforms, but you may want to make sure. (..) Thank you for your patches Ill take look at them, test and apply where possible, also update the libswd.h as you stated so its ready to use from submodule :-) The single change in the header plus those listed in the patch file allowed me to successfully compile openocd from the fork on OS X. But unfortunately the problems did not end there. After a successful build, running the tool gets a little further then before, but still bombs out fairly quickly: (..) Yes, as for now the transport-target integration is not yet complete (and the adi_v5_swd is not my code so I cannot confirm if its working, there were some things I didnt like about it), only the dirver-libswd to make transport work, stay tuned, work in progress :-) If you have good insight on JLink and maybe other high-level command-based devices (like RLink) please concentrate on implementing drivers API for those devices that will allow generic access to the bus with bitbang and transfer operations as implemented for FT2232 cables in interface structure. Only FT2232 cables are now capable to run SWD with libswd as all drivers were designed to work only with JTAG having jtag-specific calls I had to implement some generic functions that could allow transports other than JTAG - this is why bitbang (set selected bitmask on selected port pins) and transfer (send/receive data stored in *char) was created and should do the job for device with no logic that know nothing about SWD (or other transport). This is why we need to create drivers using bitbang and transfer for high-level interfaces, or something else that would allow generic access to the bus and transport implementation. This way we should be able to implement any possible transport on any possible interface :-) Please let me know if the bitbang and transfer is enough for high-level interfaces to implement the transport.. If so it would be nice to see bitbang and transfer implementation for interfaces other than FT2232. 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] Jlink SWD Support
Thank you for this hint on printing pointers! :-) Although there is no
word about %p in the manual, it works on FreeBSD so it should also
work on MacOSX as it is derivative :-)
With LOG_INFO(New SWD context initialized at %p, (void
*)jtag_interface-transport-ctx); we get:
%telnet localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
source [find interface/kt-link-swd.cfg]
only one transport option; autoselect 'swd'
New SWD context initialized at 0x2843b280
%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: /tmp/openocd/target/bin/openocd -c noinit
Open On-Chip Debugger 0.5.0-dev-g4e2a176-dirty (2011-08-22-03:42)
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 'swd'
Info : New SWD context initialized at 0x2843b280
^C
Program received signal SIGINT, Interrupt.
0x282e8fa3 in select () from /lib/libc.so.7
(gdb) p 0x2843b280
$1 = 675525248
(gdb) p (swd_ctx_t) *0x2843b280
$2 = {cmdq = 0x2844f760, config = {initialized = 1 '\001', trnlen = 1
'\001', maxcmdqlen = 1024, loglevel = SWD_LOGLEVEL_INFO},
driver = 0x2840d1b8, log = {dp = {ack = 0 '\0', parity = 0 '\0',
idcode = 0, abort = 0, ctrlstat = 0, wcr = 0, select = 0,
rdbuf = 0}, ap = {ack = 0 '\0', controlstatus = 0, tar = 0, drw
= 0, bd0 = 0, bd1 = 0, bd2 = 0, bd3 = 0, dromt = 0, idr = 0},
read = {request = 0 '\0', ack = 0 '\0', addr = 0 '\0', data = 0,
control = 0, parity = 0 '\0'}, write = {request = 0 '\0',
ack = 0 '\0', addr = 0 '\0', data = 0, control = 0, parity = 0 '\0'}}}
Thank you! :-)
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] Jlink SWD Support
On Fri, Aug 19, 2011 at 1:09 AM, Carlson Gary gcarl...@carlson-minot.com wrote: (...) Debug: 35 45 command.c:151 script_debug(): command - ocd_transport ocd_transport select swd Error: 36 45 target.c:435 get_current_target(): BUG: current_target out of bounds Hello Gary, did you try the openocd-libswd fork or the master branch? The first can already communicate with target, I will work on target implementation in upcoming days, it would be nice to have some support :-) [1] http://repo.or.cz/w/openocd/libswd.git 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] Jlink SWD Support
Some more information on details/usage in [1]. Target use TAP for JTAG and DAP for SWD, so we need to create union containing both inside with common API, or initialize only one of them at time and null other to let know which one is in use, or create null pointer and cast it based on transport type..? [1] 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] Please welcome Andreas Fritiofson as a new OpenOCD maintainer!
On Thu, Aug 11, 2011 at 10:08 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: Please give Andreas Fritiofson a warm welcome as a new OpenOCD maintainer! Hello Andreas! Glad to have you onboard! :-) Best regards, Tomek Cedro -- 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] 0.5.0 release
On Wed, Aug 10, 2011 at 3:40 PM, Vit Mares mares@gmail.com wrote: The FTD2232 can be used not only as a JTAG dongle but it is also very big helper for embedded developer. It can be used as a I2C or SPI bridge between your PC and uC board, it can be used for Lattice FPGA programming etc. and many of us use it on Windows with native FTDI driver support. The speed is not so important the drivers are. Hello Vit, I have implemented bitbang functionality that allows scripting high level buses (such as I2C, SPI, ...) in external scripts, so they are not hardcoded into binary and it works fine with open libftdi :-) No need to have closed source libftd2xx :-) You can check it out at http://repo.or.cz/w/openocd/libswd.git 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] 0.5.0 release
On Wed, Aug 10, 2011 at 4:13 PM, Manuel Borchers man...@matronix.de wrote: The point he was trying to make is, that one _may_ need (or want to stick to) the native FTDI drivers. This may be because one wants to use the other channel as a normal UART (speak use the virtual com port) or some other closed source tools or there may even be no possibility to install libftdi drivers to the machines (due to firm policies) and one _must_ stick to the FTDI drivers. Hello Manuel :-) This policy looks like must install Adobe Flash Player to view this image or table, but on some systems there is no flash player (nor libftd2xx) and so this is why we should stick to the open-source and promote open-source where possible. People don't even know that open-source alternative exist, or that some proprietary solutions only work on selected platforms, this is why we should change such ignorant policies where possible :-) 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] 0.5.0 release
If we don't constantly show that some work has been done by open-source some people will tend to think it was done for free, no effort and they start to demand more results with less funds in shorter time. This is why we should tell to develop open-source instead buy expensive closed solutions-per-problem because investing in open-source in fact can bring better results with smaller cost... Creating open-source is not free and it is time consuming. Some people does not understand this fact. If some laboratory or company use closed source solutions but for some reason they want use open-source they cannot at the same time block support for open-source, or they should consequently purchase _everything_ commercial and closed source and even don't touch the open-source to see how bad things will get with their work and funding :-) Closed source applications are also full of bugs and limited functionalities. There is nothing good with that except you get working solution instantly... but you cannot change or develop it anyway. If anyone wants to use additional channels of FTDI I would recommend creating that support in open-source rather than mix open-source with proprietary stuff. The same with transfer efficiency and everything else. People start to integrate open-source in their commercial products with nothing in return. This is not fair and we should not support such actions. This is why I fully support decision to give preference for open-source libftdi rather than libftd2xx (please not that there is no libftd2xx for my system). 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] 0.5.0 release
Ugh, why this is a release not RC3? We did not test RC to have go for a release... are we supposed to test on a release? :\ -- 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] 0.5.0 release
On Tue, Aug 9, 2011 at 8:53 AM, Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com wrote: On 07:50 Tue 09 Aug , Tomek CEDRO wrote: Ugh, why this is a release not RC3? We did not test RC to have go for a release... are we supposed to test on a release? :\ there was no patch during day so as I said no rc we get more than 4weeks of fix windows it's enough If some bug are found on the release we will create bugfix release 0.5.x OK then, seems there will be more releases with build/revision higher than 0 :-) Please provide correct/complete RC packages next time as this is also important for testing :-) 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] 0.5.0 release
On Tue, Aug 9, 2011 at 11:08 AM, Xiaofan Chen xiaof...@gmail.com wrote: If the project is willing to provide official Windows binary, that would be the best. But if not, a link to Freddie Chopin's website is still good. I vote for Freddie to have his own place/mirror at project repository, at least for one up-to-date binary per release :-) 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] Tutorial Material on Flash Drivers
Cool :-) Congrautlations Jim! We wanted to do something like that as more general wiki with Drasko, so now we have a place to develop :-) 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] Last call before release
Hello Jean, please provide full featured RC package (generated by make distcheck, containing configure scripts) to test it on FreeBSD, as for now bootstrap fails, so the status is no-go. 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 0.5.0-rc2 release
Hello! :-) Trying to bootstrap on FreeBSD 8.2-RELEASE fails with the 0.5.0-rc2 as given at: http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=snapshot;h=d4cd6f032015552f00bf4b5a90f25f5f958e9d9e;sf=tgz This should probably never happen with the real package as configure scripts are already there and no need for bootstrapping..? Best regards, Tomek %cd openocd-d4cd6f0 %ls AUTHORS Makefile.am README contrib testing AUTHORS.ChangeLog NEWSREADME.Win32doc tools BUGSNEWS-0.2.0 TODO ecosflash uncrustify.cfg COPYING NEWS-0.3.0 bootstrap guess-rev.sh ChangeLog NEWS-0.4.0 common.mk jimtcl Doxyfile.in NEWTAPS config_subdir.m4src HACKING PATCHES.txt configure.intcl %./bootstrap + aclocal /usr/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of AM_PATH_SMPEG /usr/local/share/aclocal/smpeg.m4:13: run info '(automake)Extending aclocal' /usr/local/share/aclocal/smpeg.m4:13: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal configure.in:28: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... /usr/local/share/aclocal/libtool.m4:1084: _LT_SYS_MODULE_PATH_AIX is expanded from... /usr/local/share/aclocal/libtool.m4:4207: _LT_LINKER_SHLIBS is expanded from... /usr/local/share/aclocal/libtool.m4:5339: _LT_LANG_C_CONFIG is expanded from... /usr/local/share/aclocal/libtool.m4:143: _LT_SETUP is expanded from... /usr/local/share/aclocal/libtool.m4:69: LT_INIT is expanded from... /usr/local/share/aclocal/libtool.m4:107: AC_PROG_LIBTOOL is expanded from... configure.in:28: the top level configure.in:28: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... /usr/local/share/aclocal/libtool.m4:4207: _LT_LINKER_SHLIBS is expanded from... /usr/local/share/aclocal/libtool.m4:5339: _LT_LANG_C_CONFIG is expanded from... /usr/local/share/aclocal/libtool.m4:143: _LT_SETUP is expanded from... /usr/local/share/aclocal/libtool.m4:69: LT_INIT is expanded from... /usr/local/share/aclocal/libtool.m4:107: AC_PROG_LIBTOOL is expanded from... configure.in:28: the top level + libtoolize --automake --copy + autoconf configure.in:28: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... aclocal.m4:1099: _LT_SYS_MODULE_PATH_AIX is expanded from... aclocal.m4:4222: _LT_LINKER_SHLIBS is expanded from... aclocal.m4:5354: _LT_LANG_C_CONFIG is expanded from... aclocal.m4:164: _LT_SETUP is expanded from... aclocal.m4:90: LT_INIT is expanded from... aclocal.m4:128: AC_PROG_LIBTOOL is expanded from... configure.in:28: the top level configure.in:28: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... aclocal.m4:4222: _LT_LINKER_SHLIBS is expanded from... aclocal.m4:5354: _LT_LANG_C_CONFIG is expanded from... aclocal.m4:164: _LT_SETUP is expanded from... aclocal.m4:90: LT_INIT is expanded from... aclocal.m4:128: AC_PROG_LIBTOOL is expanded from... configure.in:28: the top level + autoheader configure.in:28: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... aclocal.m4:1099: _LT_SYS_MODULE_PATH_AIX is expanded from... aclocal.m4:4222: _LT_LINKER_SHLIBS is expanded from... aclocal.m4:5354: _LT_LANG_C_CONFIG is expanded from... aclocal.m4:164: _LT_SETUP is expanded from... aclocal.m4:90: LT_INIT is expanded from... aclocal.m4:128: AC_PROG_LIBTOOL is expanded from... configure.in:28: the top level configure.in:28: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from...
Re: [Openocd-development] rename st32 flash drivers
On Thu, Jul 28, 2011 at 12:55 PM, Spencer Oliver s...@spen-soft.co.uk wrote: I sort of like the x - but the majority rules. Any more votes? I also like the xxx :-P :-) :-) -- 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] General SWD Support in OpenOCD
Good news - libswd-openocd driver bridge is now ready and functional [1] it reads out the IDCODE. I have already pushed the patches to the repository [2]. Right now have to multitask to another task but at weekend I will try to make arm_adi_v5 work with my swd target using crafted drivers and swd function set :-) Best regards! :-) Tomek [1] http://stm32primer2swd.sf.net/ [2] http://repo.or.cz/w/openocd/libswd.git This is the program invocation and debug messages output: %./openocd -c noinit Open On-Chip Debugger 0.5.0-dev-g7ad8d2e-dirty (2011-07-25-15:13) 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 'swd' Info : New SWD context initialized at 0x2843B280 10 kHz Info : KT-LINK SWD-Mode initialization complete... Info : max TCK change to: 3 kHz Info : clock speed 10 kHz SWD_I: Executing swd_dap_activate(0x2843b280, SWD_OPERATION_EXECUTE) SWD_I: Executing swd_dap_reset(0x2843b280, SWD_OPERATION_EXECUTE) SWD_I: Executing swd_dp_read_idcode(0x2843b280, SWD_OPERATION_EXECUTE) SWD_I: swd_dp_read_idcode() succeeds, IDCODE=EE2805D8 (111011100010110111011000) Info : SWD transport initialization complete. Found IDCODE=0xEE2805D8. Warn : gdb services need one or more targets defined User : 42 75811 command.c:557 command_print(): debug_level: 3 Debug: 43 78630 command.c:151 script_debug(): command - ocd_command ocd_command type ocd_transport init Debug: 44 78630 command.c:151 script_debug(): command - ocd_transport ocd_transport init Debug: 46 78630 transport.c:263 handle_transport_init(): handle_transport_init Debug: 47 78630 swd.c:129 oocd_swd_transport_init(): entering function... SWD_I: Executing swd_dap_activate(0x2843b280, SWD_OPERATION_EXECUTE) Debug: 48 78630 swd_libswd_drv_openocd.c:174 swd_drv_mosi_trn(): OpenOCD's swd_drv_mosi_trn(swdctx=@0x2843B280, bits=1) Debug: 49 78630 interface.c:41 oocd_interface_signal_find(): Searching for signal RnW Debug: 50 78630 interface.c:62 oocd_interface_signal_find(): Signal RnW already exists. Debug: 53 78631 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8(): OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432CA0, data=0x, bits=8, nLSBfirst=0x01) Debug: 70 78646 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8(): OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432CC0, data=0x, bits=8, nLSBfirst=0x01) Debug: 87 78662 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8(): OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432CE0, data=0x, bits=8, nLSBfirst=0x01) Debug: 104 78778 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8(): OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432D00, data=0x, bits=8, nLSBfirst=0x01) Debug: 121 78792 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8(): OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432D20, data=0x, bits=8, nLSBfirst=0x01) Debug: 138 78808 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8(): OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432D40, data=0x, bits=8, nLSBfirst=0x01) Debug: 155 78824 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8(): OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432D60, data=0x, bits=8, nLSBfirst=0x01) Debug: 172 78840 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8(): OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432D80, data=0x, bits=8, nLSBfirst=0x01) Debug: 189 78856 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8(): OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432DA0, data=0x0079, bits=8, nLSBfirst=0x01) Debug: 206 78872 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8(): OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432DC0, data=0xFFE7, bits=8, nLSBfirst=0x01) SWD_I: Executing swd_dap_reset(0x2843b280, SWD_OPERATION_EXECUTE) Debug: 223 7 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8(): OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432DE0, data=0x, bits=8, nLSBfirst=0x01) Debug: 240 78904 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8(): OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432E00, data=0x, bits=8, nLSBfirst=0x01) Debug: 257 78920 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8(): OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432E20, data=0x, bits=8, nLSBfirst=0x01) Debug: 274 78936 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8(): OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432E40, data=0x, bits=8, nLSBfirst=0x01) Debug: 291 78952 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8(): OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432E60, data=0x, bits=8, nLSBfirst=0x01) Debug: 308 78968 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8(): OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432E80, data=0x, bits=8, nLSBfirst=0x01) Debug: 325 78984 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8(): OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432EA0, data=0x, bits=8,
Re: [Openocd-development] General SWD Support in OpenOCD
Everything went to master of the repository - I have cleaned it up so i should be now easy to rebase with openocd/master when necessary. Thank you for all hints on using git this is very nice tool and I seem to get familiar with it already :-) 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] rename st32 flash drivers
On Thu, Jul 28, 2011 at 12:55 PM, Spencer Oliver s...@spen-soft.co.uk wrote: This is a good idea to clean that up. I think you can go one step further by dropping the 'x' (which has no meaning) in order to rename: - stm32x to stm32f1 - stm32f2xxx to stm32f2 Seriously speaking - no offense to xxx - if the stm32f1 and stm32f2 are different types of flash memories this f1 f2 nomenclature would be more precise as stm32x logically also contains stm32f2xxx (by containing stm32f) what can be misleading. F1 and F2 seems to be more accurate :-) 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] GDB always executes code on the first declared target in a multi-target configuration
Hello Drasko! :-) It would be perfect to modularize code and join all modules together in one openocd thread.. I have tried that but its too much work, first need to finish swd framework. However hving modular design, maybe even object-based, would improve readability and extend new functionalities - so target is an object with subobjects that has their own methods and settings.. don't you think it would improve future openocd use? :-) 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 0/7] RLink interface speedup, and fixes
On Fri, Jul 22, 2011 at 9:59 AM, Peter Horn peter.h...@bluewin.ch wrote: Besides the RLink I also have an Olimex ARM-USB-OCD adpater. On Windows, stepping with the Olimex is considerably faster than with the RLink. On Linux both adapters are on par. I'm Using the same STM32 board and OCD-Version in all cases, so the cause for the slow stepping must be related to the RLink driver. ...and the OS-specific USB stack or RLink architecture itself. If you chceck the timings on OpenOCD (windows/linux) and RIDE (windows) then comparison should reviel the driver and the os-usb-stack quality, but if the timings are similar that could be matter of device/firmware design. It would be nice to see such comparison :-) Also the SWD part of the protocol still waits to be solved [1] :-) Best regars! :-) Tomek [1] http://files.tomek.cedro.info/electronics/arm/cortex/stm32/rlinkre/ -- 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] libswd drivers question
On Thu, Jul 14, 2011 at 12:58 PM, Tomek CEDRO tomek.ce...@gmail.com wrote: (..) When I removed template drivers from libswd source tree so it can be linked with drivers already compiled and provided by openocd, there are some unresolved dependencies in libswd.la submodule. This is the only thing that keeps me from running libswd on openocd :-) It turned out that when I added libswd.la or libswd.a to openocd_LDADD (conditional in src/Makefile.am) there were unresolved dependencies, when passed libswd.so it links fine! Hope this is proper solution :-) Now only some bugs to be solved.. its going to be busy weekend :-) 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 0/7] RLink interface speedup and fixes
Hello Andreas! Do you know what is the difference between JTAG (on Stm32Primer) and SWD (on Stm32Primer2) RLink interface? Would they run on existing driver? Do you have some kind of manual or technical specification? 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
[Openocd-development] libswd drivers question
Hello! Sorry for cross-posting but this somehow touches both applications. LibSWD is a standalone library that can generate SWD operations, then flush them into device driver. This driver (some function set) is application specific, so it cannot be compiled in into libswd, but rather linked with libswd during application compilation. However libswd then complains about missing driver functions at linking time. For UrJTAG I have copied sources of libswd into application source tree and passed proper source file with driver functions to compile everything and then link with urjtag binary. This was fine until I included LibSWD as OpenOCD submodule, because now it requires its own empty drivers to compile, and those drivers override openocd's drivers. When I removed template drivers from libswd source tree so it can be linked with drivers already compiled and provided by openocd, there are some unresolved dependencies in libswd.la submodule. This is the only thing that keeps me from running libswd on openocd :-) So the question is - how to create/implement universal driver function set that would allow libswd to compile cleanly, but also allow external applications (such UrJTAG and OpenOCD) to provide its own driver functions. The only sensible way for me seems to be using function pointers that will be set at library initialization by the external function... Maybe there is some more smart approach? Best regads! :-) 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] SWD todo
On Tue, Jul 12, 2011 at 9:38 AM, simon qian simonqian.open...@gmail.com wrote: 4. Add SWD drivers, this should be the libswd. And call SWD drivers in adi_v5_swd. Hello Simon! This is almost done. Getting back to this today. When its done, then I get to higher layers. The basic concept is that both jtag and swd can use arm_adi_v5 calls, depending on transport selected. Transport select is done by selecting interface, then transport has its own select() and init() functions - select() prepares everything for use with swd, init() interrogates scan chain. I would highly suggest creating one common openocd context to store all settings in one place, then passing this context to all functions (like in libswd, libftdi, etc) - then we have everything in one place, not global, not replicated in many places. I have already expanded target structire with transport and driver pointer but this is a dirty hack to test functionalities and it should not stay this way on a release. Using oocd_ctx would also allow using multithread use :-) 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] SWD todo
On Tue, Jul 12, 2011 at 9:55 AM, Tomek CEDRO tomek.ce...@gmail.com wrote: The basic concept is that both jtag and swd can use arm_adi_v5 calls, depending on transport selected. To be more exact - the arm_adi_v5 is the wrapper for low level jtag or swd operations on jtag-dp or swd-dp. Target always use some standard arm_adi_v5 function set to access DP and AP. Those functions are defined and implemented by transport layer (with function pointers) :-) -- 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 0.5.0-rc2 release
On Sun, Jul 10, 2011 at 2:41 PM, Luca Bruno lu...@debian.org wrote: As a sidenote, publishing tarball for -rc helps testing in conditions similar to the final one, avoiding late bugs introduced by autotools packaging or similar. Totally agree on this - FreeBSD ports use automatic package download and extraction mechanism, so having tarball for RC2 would be great! Please let me know then its available :-) 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] adding interface_signal and bitbang functionalities
On Fri, Jul 8, 2011 at 5:59 PM, Rodrigo Rosa rodrigorosa...@gmail.com wrote: i'm currently using the merge i made of the bitbang stuff with openocd. (..) nice work! :) Thank you Rodrigo! Nice to hear you find it useful and that its working as supposed :-) :-) I have made some small progress on my repository and libswd also the bitbang stuff (mainly bitbang_deny field of layout as requested by Laurent and restricting bitbang command to COMMAND_EXECUTE state when everything is already set up), also found some bugs. I had some priority work to be done recently, but I think I will move forward the swd stuff a bit next week :-) Best regards! :-) Tomek ps/2: You can make perfect one layer pcb at home using photolitography (laser printer + standard laser foil + positive 20 + cleaner + philips halogen bulb type 14552 12V/75W only requires 1 minute to create perfect mask). Still I don't know any sensible method to make drills metalization at home to produce advanced two layer pcb... maybe you guys know some tricks? :-) -- 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] PCB tips and tricks
Hello Michael! :-) On Fri, Jul 8, 2011 at 8:18 PM, Michael Schwingen rincew...@discworld.dascon.de wrote: Am 07/08/2011 08:30 PM, schrieb Tomek CEDRO: (..) Still I don't know any sensible method to make drills metalization at home to produce advanced two layer pcb... maybe you guys know some tricks? :- Simply drill the holes and solder both sides - with a thin wire if there is no THT pin. This may be a bit painful, but works quite well if you take care during layout so that you do not place vias under parts. Yes, this is the obvious solution for low count VIAs, but I am wondering on making something more useful to connect both layers on PAD (that is when also some component use that hole) - this is especially painful on connectors or other parts that hide top layer when element is mounted... BTW: I found that PCB material that comes pre-coated with the photo mask works *way* better than positive-20, because you get consistent exposure times. Also, positive-20 tends to get bad shortly after the best before date, which was about a year when I used the stuff, while the pre-coated material can be stored a lot longer. Thank you for this advice - I am actually using small 100ml Positiv20 spray far beyond expiration (03/09) and it works fine ha! I noticed the NaOH must be fresh and the light source is very important (mentioned philips 14552 12V/75W halogen/uv lamp gives best results of all) and it can overcome Positive20 limitiations.. maybe thats also because I give thick layer of fotopositive (dry it in oven) and strong lamp. This photolitography method is really nice and far more reliable than thermal-transfer, its not expensive, I can recommend it to anyone that want to make precise pcb at home :-) For my applications this quality is enough, maybe pre-coated boards are better but also far more expensive... Still, no solution/idea on how to make pads metalization at home safely... there is a clear field for a patent, hey inventors wake up! :-) 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] PCB tips and tricks
On Fri, Jul 8, 2011 at 8:59 PM, Michael Schwingen rincew...@discworld.dascon.de wrote: Note: don't put vias *in* SMD pads - they will wick away the solder when doing automated production. Yup :-) Still, no solution/idea on how to make pads metalization at home safely... there is a clear field for a patent, hey inventors wake up! :-) I have not found a solution that works in a small-volume hobby setting. What is the solution? :-P -- 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] Please welcome Jean-Christophe as release manager
On Thu, Jun 30, 2011 at 6:23 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: Please give a warm welcome to Jean-Christophe as the release manager. Hello Jean-Christophe :-) You have been long awaited! Good luck and have fun with OpenOCD project! :-) Best regards! :-) Tomek Cedro -- 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] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
Cool, I will add new field into layout structure that will indicate forbidden bits to bitbang, this field will be zero by default so all bits are allowed, driver author can add some value of this field to the specific layout - that value AND port mask to set/bitbang will be checked in ft2232_bitbang(), if non-zero then error will be returned as user tried to access restricted port pins. Should be simple, elegant and safe enough..? This update should appear in my fork repository after weekend.. soo have a great weekend! :-) 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] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
On Tue, Jun 21, 2011 at 3:57 PM, Phil Fong fong...@yahoo.com wrote: I think there is an misunderstanding here. My reading of Tomek's emails indicates there is a layout specific mechanism to filter which pins can be bitbanged. The interface config file will define which pins can be bitbanged and how. Is this correct? Simple and true :-) Each interface has its own config file anyway, so this file can contain also signal definition for that interface. If interface has no signals defined, no signals will be defined, so there is no worry. User can define his/hers own signals by hand, but it is then his/hers choice :-) There can be some standard signals to be used by general TCL scripts as signals are recognised by name string :-) 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] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
Laurent, 1. If you create cable that have ADC onboard (like KT-LINK) then it is easier to write simple TCL script to read ADC than rewrite whole driver in the source code. 2. If you need to program I2C, SPI, or other kind of memory, you simply write simple TCL script to do so, no need to rewrite source code from scratch. 3. If you care not to short-cirtuit your internal buffers, put 27R resistor in series between FT2232 and buffer output. 4. No interface has hardcoded signals by default, so noone is obligated to use ANY pin configuration for their device. This functionality is meant to be placed inside interface configuration, or work on generic signals defined by the interface configuration (ie LED, RnW, MOSI, MISO, CLK, ...), so yes in fact external scripts also can work with interface-specific configuration :-) 5. I see no reason that non-aware users should block functionalities for people that need them and know how to use them, otherwise we need no development. If you have any additional questions of doubts feel free to ask :-) 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] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
On Mon, Jun 20, 2011 at 6:14 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: (..) I would dearly like to see SWD done before opening the floodgates to GPIO and other serial protocols. SWD is packed-based half-duplex bus that defines TRN operation for bus direction change and buffers reconfiguration. There is no SWD without bitbanging the pins responsible for that TRN switch. It can be implemented per-interface in a source code, or it can be more general and bring even more use to existing code/hardware. The main reason for writing the bitbang was driving RnW pin that is responsible for TRN bus operation. This RnW can be implemented as one bit, or as bitmask, and even more bitmask that require setting one bits high and other bits low. This is must-have for transport other than JTAG. I will not hardcore this functionality only for one interface, if it can be used for all others with even more elegant solution, because I don't like this approach and I find it too much in current source code - if it was already there I would not have to write it from scratch! With presented signal/bitbang API it is possible to easily create other transports using smart interfaces, I bet even JTAG-only interfaces will score, and it is totally backward compatibile. It will be possible to quickly write custom TCL scripts that will provide lots of more new features than hardcoding them for some specific solution with specific hardware. Do you need anything more? Just let me know and give some time! :-) 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] adding interface_signal and bitbang functionalities
On Mon, Jun 20, 2011 at 7:46 PM, Rodrigo Rosa rodrigorosa...@gmail.com wrote: i'm trying to apply these patches on the current head, and i get: bitbang.c: In function ‘handle_bitbang_command’: bitbang.c:90: error: implicit declaration of function ‘strnstr’ bitbang.c:90: error: assignment makes pointer from integer without a cast make[6]: *** [bitbang.lo] Error 1 i'm running: 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 i think this is because strnstr is in freeBSD but not in LSB... Hello Rodrigo! Yes, it looks that stsnstr is not standard function sorry, I got the same result on Arch Linux. I am sitting into this problem and proper merging bitbang with openocd/head. There is also some problem with cable initialization causing crash/error.. work in progress :-) Btw. is there any way in git to edit a commit? :-) -- 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] adding interface_signal and bitbang functionalities
On Mon, Jun 20, 2011 at 8:18 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: Btw. is there any way in git to edit a commit? :-) Yes: git rebase -i origin/master Aaaarg, could have figured that myself ;-P Tanks! :-) I think I have found my problem - the bitbang can be used only after cable is initialized / after calling init... which is pretty obvious, but have to be checked within bitbang call :-) work in progres... -- 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] adding interface_signal and bitbang functionalities
I have found the issue - command init is mandatory for bitbang to work as it initialize the interface (pretty obvious). On another place I was using some configuration file that had this init inside and this is why it worked there, I mislooked that :-( So generally speaking the patches are working. Note that I am using JTAG transport and old interface configuration file (with API upgraded in source code). Please wait few moments so I update them with init check and strnstr fix :-) Screenshots: 1. OpenOCD with no init invocation: %./openocd -c noinit 2. Telnet commandline: %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 There are no signals defined yet. interface_signal list Interface Signal Name |Mask| Value -- led | 0x8000 | 0x8000 init max TCK change to: 3 kHz An adapter speed is not selected in the init script. Insert a call to adapter_khz or jtag_rclk to proceed. in procedure 'init' adapter_khz 10 10 kHz init bitbang led=lo led=0x bitbang led=hi led=0x8000 -- 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] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
On Mon, Jun 20, 2011 at 9:19 PM, amotec-laurent_gauch amotec-laurent_ga...@mail.axianet.ch wrote: Your TCL bitbang will control the port of the FTDI from an higher level than FT2232.c. OK but you TCL bitbang is specific to the layout used. How do you accept or not the use of the TCL procedure, if you do not have the notion of layout in this function ??? Let's assume we want to use our specific interface to quickly flash the SPI memory because we have no time to get familiar with source code and complex program internals... some_very_specific_interface.cfg: (..) interface_signal MOSI 0x01 interface_signal MISO 0x02 interface_signal SCK 0x04 interface_signal EN 0x08 interface_signal SPI0 TCL script then can check if signal SPI is defined (no mask value, so no pin is driven, it is only informational), if so check if other signals are defined and proper value, if so work the SPI operation, if not return error because interface does not define/support necessary signals. If no such signals are defined by interface configuration file, there is no option to drive those signals on that specific interface, so there is no worry anything get broken. Again - signals are to be defined inside interface configuration file, so the signals are also layout specific. This is far more better solution than hardcoding them into source code... Btw. I have to add signal check interface to TCL command :-) How to make tcl command return some value that can be used for later calculation (i.e. interface_signal mask returns 0 for SPI signal, 1 for MOSI, 2 for MISO, ...) ? How does the ADC controlled from K T ? It is connected somehow to free IO pinf on the FT2232H port. 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] adding interface_signal and bitbang functionalities
Here goes another patch to be applied on top of previous patches: -it fixes strnstr() problem - sorry for that, man says clearly it is FreeBSD specific! -it changes command mode to COMMAND_EXEC so 'bitbang' is only available after 'init' -some minor string and constants fixes Waiting for feedback :-) Best regards, Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info 0009-INTERFACE-BITBANG-Fixed-strnstr-issue-command-is-now.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] adding interface_signal and bitbang functionalities
On Mon, Jun 20, 2011 at 11:33 PM, Rodrigo Rosa rodrigorosa...@gmail.com wrote: i found a bug in interface_signal del, the name of the signal was not passed down to the functions thats look for it, so it didn't work. attached a patch :) Tanks, I will take a look, but signal deletion worked for me.. the first time it doesn't work, but if i annoy it by trying again it will cooperate. Using JTAG interface also 'init' did not always work when starting opencd -c noinit. When created simple file with those commands and passed -f to openocd then 'init' works fine... Tanks for support Rodrigo! :-) -- 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 config error with libftdi-1.0
On Sun, Jun 19, 2011 at 12:52 PM, Xiaofan Chen xiaof...@gmail.com wrote: Just FYI, urjtag works fine with either libftdi or libftdi-1.0, it also works with libusb-1.0. Yes I remember such discussion some time ago ended with good solution, maybe worth copying.. although never tested is as I still use 0.1 in BSD implementation :-) -- 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 9:42 PM, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: 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. Nice to know, thanks! Is that true for all compilers? -- 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] RFC Release Cycle
On Fri, Jun 17, 2011 at 7:57 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: I am struggling a bit following the above, but I think we agree: - development goes on in master like it always has done - you create a fork at the openocd mirror and create a release branch there. You pick whatever you want from the master branch or whatever patches posted that you think should go in and generally run the release cycle. - once you're done with the release, I pull it from you and push it to the official openocd repository. I also agree on this approach! This won't block the patches sent on the fix cycle as the release can be done on a temporary fork intergrated into openocd/master as a tag/branch when its ready. It is also necessary to set the numbering scheme.. 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] segfault in ftdi_write_data / libusb
On Thu, Jun 16, 2011 at 7:56 PM, Hans Petter Selasky hsela...@c2i.net wrote: I was not able to reproduce the segfault. This happens only with this particular source code, it is a result of (non-finished) patching from my fork, that is working fine. Non-hinished patching means that there are some patches yet needed to me moved from my fork, but it looks interesting to break libusb this way... I don't have a FTDI device right here, but I tested a bit faking a device in libftdi and concluded that you need to run: jtag init before using the bitbang command. Else the FTDI device is not opened properly. Wow, you got so much insight in so short time, impressive! :-) The initialization routine for ft2232 based device is ft2232_init(). I will fix this issue shortly ofcourse as I have working version, but it looked to me as it can lead to local exploitation of the bsd system... if not, there is no problem :-) Best regards and thank you for your time Hans! :-) 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] segfault in ftdi_write_data / libusb
On Sat, Jun 18, 2011 at 12:32 PM, Tomek CEDRO tomek.ce...@gmail.com wrote: (..) but it looks interesting to break libusb this way... Short update on this - libusb (1.0.8-1) and libftdi (0.19-1) on linux (arch 2.6.39) does not have this ussue.. ddaamn ;-P source [find interface/kt-link.cfg] source [find interface/kt-link.cfg] only one transport option; autoselect 'jtag' interface_signal list interface_signal list Interface Signal Name |Mask| Value -- interface_signal add led 8000 interface_signal add led 8000 There are no signals defined yet. interface_signal list interface_signal list Interface Signal Name |Mask| Value -- led | 0x8000 | 0x8000 bitbang led=lo bitbang led=lo ftdi_write_data: USB device unavailable Unable to write signal: led in procedure 'bitbang' bitbang led bitbang led ftdi_write_data: USB device unavailable Unable to read signal: led in procedure 'bitbang' -- 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
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
[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
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 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] New development version of OpenOCD available at last!
On Wed, Jun 15, 2011 at 3: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 Good to hear! I was planing to make 0.4.1 as there are s many pepole interested in using is but noone even tare to try do the job :-) You have my support Jean :-) I would suggest to migrate interface_signal and bitbang yet before releasing 0.4.1 to give users time to play with that functionality and possible new features in 0.5.0 :-) Best regards! :-) Tomek Cedro -- 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] New development version of OpenOCD available at last!
On Wed, Jun 15, 2011 at 5:34 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: The swd is some time away from being merged with master, so I wouldn't want to see it in the next release of openocd, unless the release drags out. I would suggest 0.4.1 for the current code freeze, as there should be no issues. 0.5.0 for working swd..? :-) -- 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 release known issues
Hello Spencer :-) I would use git submodule and simply include JimTCL with OpenOCD build binary. This would save lots of problems and produce common distribution. Anyone who want to use external library can build his/her own binary. Ofcourse there is a situation to solve what to to when JimTCL is already installed on the system... However in future it would be nice to select library at runtime somehow.. 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] Implementation of a remote bitbang jtag driver
Hello Richard, Seems to be nice feature, however: It should be somehow related with interface driver bitbang..? It should be possible to enabled/disabled by configure script. Bets 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] New development version of OpenOCD available at last!
On Wed, Jun 15, 2011 at 8:57 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: 0.4.1 implies that it is a variant of 0.4. What we have now is *completely* different from 0.4, so 0.5.0 is better Yeah, isn't current HEAD somehow development/bugfix of 0.4.0? Are there any totally new features/design change since 0.4.0? If no, then it could be 0.4.1, which should be simple and accurate solution to have new release and tag for some master/head point in time..? That should do the job :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
