Re: [Openocd-development] Tcl low level API rules

2008-07-14 Thread Øyvind Harboe
However, are there any low-level commands which would require several pieces of information from cmd_ctx? The nasty remaining problem is LOG_XXX() and command_print. I was wondering whether the low level tcl API's should take a call back proc. Probably should according to my reasoning. --

Re: [Openocd-development] Tcl low level API callbacks

2008-07-14 Thread Ville Voipio
Duane Ellis wrote: Øyvind whether the low level tcl API's should take a call back proc. ville Callback to what and how? How do you call back to a script? Øyvind In terms of implementing(don't know of a case where we need them yet) I am confused - can you give me a better example of

Re: [Openocd-development] [EMAIL PROTECTED]: Bug#489785: please addsample config file for cortex M3 target]

2008-07-14 Thread Uwe Hermann
On Wed, Jul 09, 2008 at 12:49:50PM +0100, Spen wrote: Could you clean it up a bit exclude interface specific stuff? LM3S8962 does not match LM3S811... I don't know what that means. The problem is more related to ftdi drivers ftdi own drivers require ft2232_device_desc Stellaris

Re: [Openocd-development] Tcl low level API callbacks

2008-07-14 Thread Øyvind Harboe
On Mon, Jul 14, 2008 at 5:25 PM, Ville Voipio [EMAIL PROTECTED] wrote: Øyvind Harboe wrote: On Mon, Jul 14, 2008 at 3:58 PM, Ville Voipio [EMAIL PROTECTED] wrote: I'd rather make it the responsibility of the client to implement support for this. This can be done via multithreading or using a

Re: [Openocd-development] Jim TCL

2008-07-14 Thread Dominic Rath
On Monday 14 July 2008 19:34:06 you wrote: This is work in progress. Development happens on trunk and we'll have to cut stable branches if need be. There is a great need to synchronize work because many people are involved. Both scripting people and C people. Once the dust settles(give it a

Re: [Openocd-development] Jim TCL

2008-07-14 Thread Jonathan Larmour
Øyvind Harboe wrote: - Jim is licensed under Apache license V2, which is listed as being incompatible with GPLv2 on the FSF page. Large parts of the OpenOCD are licensed under the terms of GPLv2 or later. jifl on ecos-discuss is looking into this, so it will get sorted one way or another

Re: [Openocd-development] Jim TCL

2008-07-14 Thread Øyvind Harboe
The issue is not the same with eCos and OpenOCD unfortunately. eCos is in a better situation because eCos does not have a vanilla GPL, but has a special exception clause which means that stuff linked with it does not also have to be GPL'd. OpenOCD does not have that. So people using Jim in

Re: [Openocd-development] Jim TCL

2008-07-14 Thread Øyvind Harboe
That's not true for OpenOCD. So what's the best way to proceed here? Make Jim Tcl + LGPL? Also, we don't need to link Jim Tcl into OpenOCD, but it's less hazzle. There are many ways forward. Including ditching Jim Tcl. The scripting work that is being done with Jim Tcl specifically applies

Re: [Openocd-development] stm32 - cortex -problems

2008-07-14 Thread Spen
#2 has stm32f103zet6 22089vc mlt 3r816 512k flash part. (I include the added info - because it is probably a date code and that might matter here) Dumping memory @ 0x17e0 gives: mdw 0x17e0 16 0x17e0: fffc