Re: [Openocd-development] Fwd: BerliOS will be closed on 31.12.2011

On Oct 1, 2011, at 17:34, Peter Stuge wrote: > Øyvind Harboe wrote: >> My first instinct is to move the mailing list wholesale to sourceforge. > I agree strongly with this. ... > I am personally very strongly against depending on companies based in > the US for open source project infrastructure.

Re: [Openocd-development] OpenOCD master now uses Jim Tcl 0.63

On Nov 3, 2010, at 11:13, Peter Stuge wrote: > It could assume that jim was built and installed into some default > prefix, but really, since jim is standalone, it would make sense to > me to have it installed separately in the system even if it is linked > statically into openocd. Look at how GC

Re: [Openocd-development] disable polling when polling fails

On Aug 8, 2010, at 21:50, Øyvind Harboe wrote: > On Sun, Aug 8, 2010 at 8:41 PM, Anders Montonen > wrote: >> On Aug 8, 2010, at 9:14, Øyvind Harboe wrote: >> >>> Currently OpenOCD will ignore failure to poll the target. >>> >>> This can result in

Re: [Openocd-development] disable polling when polling fails

On Aug 8, 2010, at 9:14, Øyvind Harboe wrote: > Currently OpenOCD will ignore failure to poll the target. > > This can result in a situation where errors are being spewed out. > > I am considering making a change to OpenOCD where polling > is automatically disabled when it fails. The user would

Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX

On Jun 24, 2009, at 18:13, Freddie Chopin wrote: > David Brownell pisze: >> [so called "full explanation"] > You are wrong, because I just still don't get it how a > GPL-with-exception can exist. For an example of a GPL+exception license, see the eCos license at

Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX

On Jun 23, 2009, at 23:53, John Devereux wrote: > Anders Montonen writes: > On Jun 23, 2009, at 21:20, Freddie Chopin wrote: >>> Anders Montonen pisze: >>>> Right, but section four says "You may not copy, modify, sublicense, >>>> *or* >>>&

Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX

On Jun 23, 2009, at 21:20, Freddie Chopin wrote: > Anders Montonen pisze: >> Right, but section four says "You may not copy, modify, sublicense, >> *or* >> distribute the Program" (emphasis added). If it just concerned >> distribution then there would be

Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX

> On Jun 23, 2009, at 22:05, Photo Leecher wrote: > The general rule is that if the binaries run in the same process and/ > or > memory space it forms a "combined work", which must be licensed > under the > GPL. As always, the GPL FAQ is a recommended read. >> Congratulations, you have just dec

Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX

On Jun 23, 2009, at 19:54, Freddie Chopin wrote: > Anders Montonen pisze: >> The general rule is that if the binaries run in the same process >> and/or >> memory space it forms a "combined work", which must be licensed >> under the >> GPL. As alwa

Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX

On Tue, 23 Jun 2009, Freddie Chopin wrote: > 1. Why a "wrapper" library which would be GPL-with-exception-for-ftd2xx > cannot be linked with OpenOCD? I don't see ANY phrase in GPL that says > that GPL can be linked only to 100%-GPL-stuff-without-exceptions. > Moreover - I see no sentence which say

Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX

On Tue, 23 Jun 2009, Ronald Vanschoren wrote: > I haven't read all 700 emails related to this issue, but can someone > please explain to me why this statement holds? >> - Binaries linking to FTD2XX may NOT be distributed. You should read the previous mails, as this has been explained several ti

Re: [Openocd-development] FT2232 & Windows - summary of options

On Jun 22, 2009, at 8:40, Xiaofan Chen wrote: > You may want to use reply to all. This is not as convenient but it > is the way > OpenOCD mailing list is running. Thanks. That was my intention, but I forgot to change the to-address. Sorry about that. > libusb-win32's development branch (libu

Re: [Openocd-development] [PATCH 9/11] Transform 'u64' to 'uint64_t'

ortunately, this is the only variable in the tree that uses > the uint64_t type, so the consequences should be minor. The stardands-conforming formatting string would be "%" PRIu64 (eg. printf("var is %" PRIu64 "\n", mybigvar); ) In the C99 standard draft

Re: [Openocd-development] FT2232 libftdi and ftd2xx performance

fect. In another project where the FT2232 was used as a synchronous serial port I had no troubles reaching sustained transfer speeds of over 120 kilobytes/second using libftdi (the remote device's serial port was the limiting factor). This was on a 1.4 GHz PPC Mac. Reg

Re: [Openocd-development] RFC: uint32_t vrs u32 - et al

e difficult to type are just utterly bogus. > And Linux makes for a big example where plenty of odd naming > collisions is simply not an issue in practice When the Linux kernel was started, the very idea of having a language standard was a novel concept. Regards

Re: [Openocd-development] resubmit lost works!

does not > offer such option. It does, but not in an immediately obvious way: <http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-copy.html > Regards, Anders Montonen ___ Openocd-development mailing list Openocd-development@lists.

Re: [Openocd-development] Build problem with 1770 and Mac OS X

On May 14, 2009, at 0:06, Michael Fischer wrote: > Hello list, > > please can some one test if it is possible > to build the 1770 on Mac OS X? > Here I need libtoolize, but this was not found, > even if I install libtool over mac port. > I only found glibtoolize, therefore I set a symbolic > link

Re: [Openocd-development] Remove in_handler usage in arm_adi_v5.c

ort for asynchronous transfers (so eg. pre-1.0 versions of libusb are out). Regards, Anders Montonen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] jim.c no longer compiles warning free under Cygwin

d(__GNU_LIBRARY__) >>>extern char **environ; >>> #endif >>> I have a configure test almost done that will address this portably. > With r1610, this issue should be resolved once and for all. The autoconf failure message should probably read "Could *not*

Re: [Openocd-development] The List (of OpenOCD Tasks) for r1587

On Mon, 4 May 2009, Øyvind Harboe wrote: On Mon, May 4, 2009 at 3:03 PM, Alan Carvalho de Assis wrote: There is two types of BDM interfaces. The old interface is used on some microcontrollers like Coldfire V2 (MCF5272, MCF5282, etc) and other (with less wires) used on Coldfire V1 (MCF51JM, etc

Re: [Openocd-development] Build problem with r1588, jim.c

n the header file unistd.h in case the header files came from libc4 > or libc5, and in case they came from glibc and _GNU_SOURCE was > defined. Unless there is a need to support libc4 or libc5 the test could then be changed to an #ifdef _GNU_SOURCE. Using autoconf is of course also

Re: [Openocd-development] Build problem with r1588, jim.c

systems you have to declare it yourself. Regards, Anders Montonen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] add -std=c99 or -std=gnu99?

reports useless as the users can't generate a meaningful backtrace. The space savings are so small this is really entering ricer territory. Besides, if you really need the space you can strip the binaries yourself, but you can't put the symbols back in again. Regards, Anders M