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. lol wut? From http://sourceforge.net/about: SourceForge.net is owned and operated by Geeknet, Inc., a publicly traded US-based company. -a___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
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 GCC handles its external dependencies (MPFR etc.) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
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 then have to manually reenable polling. Isn't the problem the log spam rather than the polling, i.e. wouldn't it be better to change the logging system not to print out the same message say more than once per second? -anders ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
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 anders.monto...@iki.fi wrote: 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 then have to manually reenable polling. Isn't the problem the log spam rather than the polling, i.e. wouldn't it be better to change the logging system not to print out the same message say more than once per second? How would the logging system know how to tell which messages are spam? Having same message repeated tens or hundreds of times per second because the server goes bananas it is not useful to anyone, and can easily be automatically suppressed. Handling this in the logging system means it needs to be done only once instead of in every place it can happen. If you want to make the thresholds tunable it's also easier if it's handled in one place. -anders ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
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 http://ecos.sourceware.org/license-overview.html . The use case is different, but it is a functioning license. libstdc ++-v3 has a similar exception in its license. Regards, Anders ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
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 times already. It is one of the terms of the GPLv2 license that OpenOCD uses. See http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#MereAggregation. Where can I find the FTD2XX license? Presumably somewhere on FTDI's webpages. Regards, Anders ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
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 says that GPL-chain has to be infinite. Really - quote that for me, if the explanations are so simple. 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. 2. I also haven't seen any explanation about the binary patch, that would be marked as Non-GPL. Maybe I remember this violates GPL, period. explanation, so sorry - I'm not convinced either. Section 2 of the GPLv2 states: 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: ... and section 4: 4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. ... Since section 4 mentions modification separately, my interpretation is that you may not even modify a private copy unless it is done according to the terms of the GPL. Other people may interpret it differently. Anyway, with the amount of people who have expressed their concerns about the Windows version it shouldn't take that long to develop a proper, legally unambiguous solution to this problem rather than trying to hack around it rather than just complaining. Regards, Anders ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
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 always, the GPL FAQ is a recommended read. So that is impossible to have a GPL with exception project. Such project could not be used by any other GPL project, thus making such code worthless... There is no problems in using GPL code together with GPL+exception code. Combining all of that with with code under some third license depends on a number of things. Again, see the GPL FAQ. 4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. ... I wouldn't be distributing any Program, not it's modified version (Modification). Just a patch that would enable user to change his executable to some other executable. 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 no room for interpretation. Since section 4 mentions modification separately, my interpretation is that you may not even modify a private copy unless it is done according to the terms of the GPL. Other people may interpret it differently. Indeed which brings the next question? Why do you the most extreme interpretation take as the one that is true, and the softer interpretation as false? Why do you consider it OK to ignore a license just because it inconveniences you? Do you hold the same view regarding things you create? Anyway, with the amount of people who have expressed their concerns about the Windows version it shouldn't take that long to develop a proper, legally unambiguous solution to this problem rather than trying to hack around it rather than just complaining. Again - not everyone here is a developer, there are many users here, who just wish OpenOCD to be what is was, not another Uber-GPL code for l33t users. Everyone who uses OpenOCD is a developer in some capacity. Like all community software, development happens on a voluntary basis. If you want something done you must be prepared to either do it yourself or hire someone to do it. Look at it as an opportunity to learn some new skills. Regards, Anders ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
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 declared ALL GPL software illegal to use in Windows. Why? Because in most systems, there will be many DLLs that are 3rd party NON-system that are injected into many processes, independently of the original executable directly or indirectly requesting that DLL. The software is not linked against those libraries, nor does it need them to run. Regards, Anders ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
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 no room for interpretation. Still I don't see that as a distribution. The patch by itself is WORTHLESS it needs an executable, moreover - a RIGHT executable. It's not about distribution. The patched binary obviously doesn't satisfy the terms of the GPL, so by my interpretation you no longer have the license to use it. This renders the patch pointless. Why do you consider it OK to overinterpret the license just because it inconveniences you? In things I create I take the pragmatic view - when something is given for free (like the ftd2xx.dll library) than it is meant to be used, for free - I'm not creating artificial problems that would prevent me to use that something. My opinion is that if some software uses a certain license then you have to follow it. This is partly out of respect for the authors, partly because of the categorical imperative and partly out of a sense of self-preservation. If you can't obey the terms of the license then you don't use it. Sometimes that means you can't take the easy way out and that you don't get everything for free, but that's just the way it is. Everyone who uses OpenOCD is a developer in some capacity. Perfectly true, but you agree that using USB on Windows in C++ is not very much like writing code for bare-metal ARM7 in ANSI-C? Yes - both of those are programming... If you're a firmware engineer, the odds are sooner or later you'll be tasked with working with a device that communicates over USB. At that point it is extremely useful to be able to write even some bare-bones communications software without having to wait for some driver developer to do their bit. Look at it as an opportunity to learn some new skills. I'd love to, but I'm affraid that before I'd do anything Windows 7 will be very much out-dated. The problem is that a solution (a good solution!) is required now, not in months or years. Ah, but just think about all those hordes of Windows OpenOCD users who will be waiting to shower you with gratitude.. Regards, Anders ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX
On Jun 23, 2009, at 23:53, John Devereux wrote: Anders Montonen anders.monto...@iki.fi 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* distribute the Program (emphasis added). If it just concerned distribution then there would be no room for interpretation. Still I don't see that as a distribution. The patch by itself is WORTHLESS it needs an executable, moreover - a RIGHT executable. It's not about distribution. The patched binary obviously doesn't satisfy the terms of the GPL, so by my interpretation you no longer have the license to use it. This renders the patch pointless. I may have lost track of the argument here, but surely the GPL is all about distribution? Are you claiming it also restricts use? You're right, that was poor reading on my part. Regards, Anders ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 9/11] Transform 'u64' to 'uint64_t'
On Jun 18, 2009, at 13:47, Zach Welch wrote: On Thu, 2009-06-18 at 03:17 -0700, David Brownell wrote: On x86_64 builds I now get: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../src/helper - I../../src/jtag -I../../src/xsvf -I/usr/local/include -Wall - Wstrict-prototypes -Wformat-security -Wextra -Wno-unused-parameter - Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -MT trace.lo -MD -MP -MF .deps/trace.Tpo -c trace.c -o trace.o cc1: warnings being treated as errors trace.c: In function ‘handle_trace_point_command’: trace.c:63: warning: format ‘%lld’ expects type ‘long long int’, but argument 4 has type ‘uint64_t’ make[3]: *** [trace.lo] Error 1 make[3]: *** Waiting for unfinished jobs Making it %llu doesn't help. I guess this is one of the ways that the previous u64 behaved differently from uint64_t... I found this myself and just committed a patch to fix it, but I simply use a cast. There probably is a better way, but this fixes the build for now. Fortunately, 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, these formatting specifiers are described in section 7.8. Regards, Anders Montonen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 libftdi and ftd2xx performance
On May 29, 2009, at 19:40, Magnus Lundin wrote: The accepted wisdom seems to be that libftdi is slower than ftd2xx, and when performance is low change to ftd2xx. Is this true or a myth ? I don't think OpenOCD's USB usage is such that the used driver has any noticeable effect. 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. Regards, Anders Montonen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] resubmit lost works!
On May 17, 2009, at 11:06, Freddie Chopin wrote: Zach Welch pisze: They should have been treated to 'svn mv', because this would have preserved the history available from 'svn log'. First of all - I've tied to do that this way, but TortoiseSVN 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.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
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 to libtoolize. But at the end, I got a ld error like: ld: duplicated symbol _Jim_SetResult_sprintf Same here: ld: duplicate symbol _Jim_SetResult_sprintf in .libs/ libopenocd.lax/libxsvf.a/xsvf.o and .libs/libopenocd_la-openocd.o. This was a fresh source tree, built in a separate directory out of the source tree, so no chance of stale object files. It seems Fink sets up the libtoolize-glibtoolize symlink automatically, but it would be nice if the configuration mechanism would pick up this by itself. Regards, -Anders ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Remove in_handler usage in arm_adi_v5.c
On May 8, 2009, at 9:04, Øyvind Harboe wrote: For the sake of argument: if 16 roundtrips was the total # of roundtrips for a step, then I'd have to see real world numbers before I believed that that was observable. If I remember the USB spec correctly, the lowest achievable round-trip time (ie. one OUT transfer followed by one IN transfer) is two milliseconds for low- and full-speed devices. This is somewhat mitigated by the fact that transfers can be pipelined so the OUT transfer overlaps the previous IN transfer, but that will require support 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] 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 acas...@gmail.com 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) and HC(S) uC. How old are these CPUs? What was the last release date of a CPU with a BDM protocol? If these are CPUs firmly in the past, perhaps we should ignore them I think the newest ColdFire parts are from last year, I don't know about the 8/16-bit MCU lines. They are by no means dead. Do modern Coldfire/PowerPC CPUs use JTAG or BDM? The big ColdFire parts use JTAG for boundary scan and BDM for debugging. The new small, low-power parts seem to have only the new reduced-pin BDM interface. Regards, Anders Montonen___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Build problem with r1588, jim.c
On May 2, 2009, at 21:25, Michael Bruck wrote: If it is a GNU specific thing then assuming that more often than not this package is used with glibc I would suggest keeping #if !HAVE_UNISTD_H || IS_DARWIN rather than listing all variations that have environ in unistd.h. As an alternative a test in ./configure would be a solution. There are more systems than OS X that don't declare environ in unistd.h (eg. all users of the BSD libc). The Linux manpage for environ states that This variable must be declared in the user program, but is declared in 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 a possibility. Regards, Anders Montonen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Build problem with r1588, jim.c
On May 2, 2009, at 15:36, Michael Fischer wrote: the new version r1589 do not solve the problem, becasue the unistd.h looks like: #define getpagesize() PAGE_SIZE No information about environ here. I believe declaring environ in unistd.h is a glibc-ism and on other 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
