Re: [Openocd-development] New Flash Target: Atmel AT91SAM3 - Cortex M3
On Tuesday 23 June 2009, Duane Ellis wrote:
Author: duane
Date: 2009-06-24 04:01:14 +0200 (Wed, 24 Jun 2009)
New Revision: 2383
I get all kinds of build errors on Ubuntu 9.04/x86_32 where the
chip details banks get initialized. The errors made no sense to
me, and they went away when I changed the
.bank[0] = { ... },
.bank[1] = { ... },
to be
.bank = {{ ... }, { ... }},
Also, that sam3 flash file has lots of whitespace issues; Zach,
maybe you could run your scripts on it? My quickie fixes gave
src/flash/at91sam3.c | 1139 -
1 file changed, 564 insertions(+), 575 deletions(-)
totalling about 70 KB of fixups on that file.
- Dave
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] New Flash Target: Atmel AT91SAM3 - Cortex M3
On Wednesday 24 June 2009, David Brownell wrote:
I get all kinds of build errors on Ubuntu 9.04/x86_32 where the
chip details banks get initialized. The errors made no sense to
me, and they went away when I changed the
.bank[0] = { ... },
.bank[1] = { ... },
to be
.bank = {{ ... }, { ... }},
Ditto 8.04.2/x86_64 ...
at91sam3.c:316: warning: initialized field overwritten
at91sam3.c:316: warning: (near initialization for ‘all_sam3_details[0].bank’)
at91sam3.c:353: warning: initialized field overwritten
at91sam3.c:353: warning: (near initialization for ‘all_sam3_details[1].bank’)
at91sam3.c:391: warning: initialized field overwritten
at91sam3.c:391: warning: (near initialization for ‘all_sam3_details[2].bank’)
at91sam3.c:443: warning: initialized field overwritten
at91sam3.c:443: warning: (near initialization for ‘all_sam3_details[3].bank’)
at91sam3.c:480: warning: initialized field overwritten
at91sam3.c:480: warning: (near initialization for ‘all_sam3_details[4].bank’)
at91sam3.c:518: warning: initialized field overwritten
at91sam3.c:518: warning: (near initialization for ‘all_sam3_details[5].bank’)
make[3]: *** [at91sam3.lo] Error 1
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] License
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Zach Welch Sent: woensdag 24 juni 2009 1:10 To: Rick Altherr Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] License On Tue, 2009-06-23 at 15:45 -0700, Rick Altherr wrote: impact your mortgage or ability to make a living is false. You just seem to have a problem with someone else profiting from your free contribution regardless of what they have done to justify their price. Actually, I did not claim here that I myself am being hurt, merely that all of professional peers like me suffer from these exceptions because they provide a disincentive for the community to demand open solutions. So this is about *forcing* people/companies to pay in order to get open source projects fixed. (This is just a statement for clarification. It is not a judgement in any way!). I have offered my services repeatedly to those who need it to help resolve this situation with technical solutions. Instead, I am being asked to give up my GPL copyright claims on the work that I have done, without any compensation. Are you kidding me? Under what obligation am I required to help others that project from violating the GPL license? I think Magnus has a good point in saying that the exception for the FTDxx is already there. Not everything needs to be in writing in order to make it legal. If you allow something long enough then you are granting an extra right you can't suddenly revoke. I can see this going two ways: 1) adding the tcp/ip / named pipes interface which will allow connection to any closed source driver 2) grant *one* single explicit exception for the FTDxx driver Pick your poison :-))) Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] License
On Wed, 2009-06-24 at 09:46 +0200, Nico Coesel wrote: -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Zach Welch Sent: woensdag 24 juni 2009 1:10 To: Rick Altherr Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] License On Tue, 2009-06-23 at 15:45 -0700, Rick Altherr wrote: impact your mortgage or ability to make a living is false. You just seem to have a problem with someone else profiting from your free contribution regardless of what they have done to justify their price. Actually, I did not claim here that I myself am being hurt, merely that all of professional peers like me suffer from these exceptions because they provide a disincentive for the community to demand open solutions. So this is about *forcing* people/companies to pay in order to get open source projects fixed. (This is just a statement for clarification. It is not a judgement in any way!). No, it is about the GPL's design: to force developers to produce open solutions. No one is being forced to pay, but those who cannot develop have no other means at their disposal than diplomacy or bribery. ;) I do not care who does this work (or whether they are paid), but it seems rather clear that it needs to be done. I am ready and willing. I have offered my services repeatedly to those who need it to help resolve this situation with technical solutions. Instead, I am being asked to give up my GPL copyright claims on the work that I have done, without any compensation. Are you kidding me? Under what obligation am I required to help others that project from violating the GPL license? I think Magnus has a good point in saying that the exception for the FTDxx is already there. Not everything needs to be in writing in order to make it legal. right you can't suddenly revoke. Are you willing to defend this position in court? Do you think that others should take this assertion at face value? There are reason contracts are written down, and this kind of crap argument sums them up. I am really getting frustrated by the claim that everyone knew about the exception. I most certainly did not, and you will have an impossible case proving that I accepted these terms in face of the in-tree copy of the unadulterated GPL. Those are the terms I accepted, without any exceptions. I can see this going two ways: 1) adding the tcp/ip / named pipes interface which will allow connection to any closed source driver 2) grant *one* single explicit exception for the FTDxx driver Pick your poison :-))) I chose #1, because #2 is not strictly possible. And because it is the Right Thing To Do for the community, in strategic sense of those words. Now, I cannot be said to be a GPL fundamentalist with such a position, and I have always seen the value of such solutions. This is not new. Michael Fischer just contacted me off-list about this specific solution, which he sees as the best way to move forward out of this mess. I will help him, because of his proactive willingness to move forward on these issues in a constructive manner. Who else deserves such consideration? Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Departing
On Tue, 2009-06-23 at 19:53 -0700, Rick Altherr wrote: Not only do I have a lack of time to work on OpenOCD, but I've been dismayed by the arguments of late. I originally joined the project because my Luminary eval kit wasn't working properly with OpenOCD. Since then I've tried to help drive the foundations for better relations between developers and users. The recent trend for a minority to dictate the path and actively try to quash open discussion has caused me to lose the drive I had to work on this project. Dang, Rick. This is very disappointing, and I apologize for contributing to the arguments that caused your dismay. The dismay has been mutual, on occasions, but no hard feelings ever survived them on my part. Indeed, I would still enjoy discussing these issues over beer in the future. I relinquish all my claims of copyright on the OpenOCD code base and wish everyone well. If it is your decision to leave the project, then I wish you well too, but I wish you would reconsider and stick through it. Your voice has been valued, and your contributions would be missed. If you do decide that you must leave, then the community should be assured that I will work to ensure the 0.2.0 release will be delivered. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] License
On Wed, 2009-06-24 at 10:52 +0200, Nico Coesel wrote: -Original Message- From: Zach Welch [mailto:z...@superlucidity.net] Sent: woensdag 24 juni 2009 10:27 To: Nico Coesel Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] License On Wed, 2009-06-24 at 09:46 +0200, Nico Coesel wrote: -Original Message- I have offered my services repeatedly to those who need it to help resolve this situation with technical solutions. Instead, I am being asked to give up my GPL copyright claims on the work that I have done, without any compensation. Are you kidding me? Under what obligation am I required to help others that project from violating the GPL license? I think Magnus has a good point in saying that the exception for the FTDxx is already there. Not everything needs to be in writing in order to make it legal. right you can't suddenly revoke. Are you willing to defend this position in court? Do you think that others should take this assertion at face value? There are reason contracts are written down, and this kind of crap argument sums them up. It is not crap! If you deviate from a contract long enough then those deviations become part of the contract. Written or not. Over here there are several laws dealing with such situations. For instance: if you use a piece of land for more than 20 years and no-one claims or requires you to buy or rent that piece of land it is yours. Legally! Like it or not. This is not land. You can't stake a claim. The GPL has been in the repository since the very beginning, without an exception. It has been posted no trespassing since day one. I am really getting frustrated by the claim that everyone knew about the exception. I most certainly did not, and you will have an impossible case proving that I accepted these terms in face of the in-tree copy of the unadulterated GPL. Those are the terms I accepted, without any exceptions. Skeleton in the closet. Nothing to be done about that. You think you accepted the GPL terms, but you also accepted the exception. There is enough evidence that the exception existed when you started working on OpenOCD. 'I didn't know' and 'If I knew before' don't work in court. You are opening some seriously unpleasant areas of legal exploration. You have made me start to wonder if it would be possible to bring some sort of claim of misrepresentation against the project authors, were your suggestion to be taken by others. The COPYING file is the standard way of notifying potential authors of a project's license, so I think that I would have a good chance of proving that the authors neglected to inform authors -- whether by intention or accident. Either way, this demonstrates rather clear negligence on the part of the authors, which I believe will defeat your claims. Do you want to keep going down this road? There are more doors that probably remain to be opened, and we can explore them all if you insist. Personally, I want to be done with talking about these matters and start to move on to fix the problems for the community. Sound good? Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Summer coding project proposal
Simple project for a CS student. A wrapper with a libftdi interface calling libftd2xx, as a project using a LGPL license So any user can take their binary copy of OpenOCD linked against libftdi and simply replace the libftdi dll file, no need to play with system files or drivers. Is such a library illegal ? Who would have standing to complain ? - FTDI ? no their libray and driver is called in accordance with their documentation. - OpenOCD ? nobody has touched a single line of OpenOCD code - Copyright holders of libftdi, Intra2Net AG ? no, libftdi is LGPL and the new library would only use the header file in accordance with LGPL section 3. Would it work? with a bit of tweaking I would think so. Is this a blatant attempt just to work around the problems with OpenOCD, GPL and libftd2xx ? What do I know ? Maybe yes, but that does not make it illegal. Regards Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Openocd-svn] r2381 - trunk/src/helper
Hi, -Original Message- From: openocd-svn-boun...@lists.berlios.de [mailto:openocd-svn-boun...@lists.berlios.de] On Behalf Of du...@mail.berlios.de Sent: 24 June 2009 02:55 To: openocd-...@lists.berlios.de Subject: [Openocd-svn] r2381 - trunk/src/helper Author: duane Date: 2009-06-24 03:54:25 +0200 (Wed, 24 Jun 2009) New Revision: 2381 Added: trunk/src/helper/membuf.c trunk/src/helper/membuf.h Modified: trunk/src/helper/Makefile.am Log: Add a growable sprintf memory buffer library Modified: trunk/src/helper/Makefile.am strok_r is not available on win32 - strok is said to be reentrant on win32. Not near a dev pc at the moment so i thought i would point it out - i can make the change later if you do not have time. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Summer coding project proposal
But why should we go for such an inferior and specif solution when a more general one is proposed and worked on? -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Openocd-svn] r2381 - trunk/src/helper
Added: trunk/src/helper/membuf.c trunk/src/helper/membuf.h Modified: trunk/src/helper/Makefile.am Log: Add a growable sprintf memory buffer library Modified: trunk/src/helper/Makefile.am strok_r is not available on win32 - strok is said to be reentrant on win32. Not near a dev pc at the moment so i thought i would point it out - i can make the change later if you do not have time. I meant to say strtok not strok Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Summer coding project proposal
On Wed, 2009-06-24 at 11:18 +0200, Magnus Lundin wrote: Simple project for a CS student. A wrapper with a libftdi interface calling libftd2xx, as a project using a LGPL license So any user can take their binary copy of OpenOCD linked against libftdi and simply replace the libftdi dll file, no need to play with system files or drivers. Is such a library illegal ? Who would have standing to complain ? You are doing it to circumvent the GPL. I think that is illegal. You would be contravening this copyright holder's intention, which would make you liable for any possible infringement that I could show. Furthermore, I think individuals can be held liable for inducing infringement, which is where IANAL becomes useful in some respects. I have been repeatedly warning _against_ infringement and to consult with an attorney on any possible solutions that you intend to distribute in binary form. You should be too. - FTDI ? no their libray and driver is called in accordance with their documentation. - OpenOCD ? nobody has touched a single line of OpenOCD code - Copyright holders of libftdi, Intra2Net AG ? no, libftdi is LGPL and the new library would only use the header file in accordance with LGPL section 3. Would it work? with a bit of tweaking I would think so. Is this a blatant attempt just to work around the problems with OpenOCD, GPL and libftd2xx ? What do I know ? Maybe yes, but that does not make it illegal. It might. This is a very gray area. For the love of all that is sane, why do you want to keep pressing these fronts, when other options have been presented that will solve the problems without any objections? Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Summer coding project proposal
On Wed, Jun 24, 2009 at 11:30, Øyvind Harboeoyvind.har...@zylin.com wrote: But why should we go for such an inferior and specif solution when a more general one is proposed and worked on? What are the speed/roundtrip time implications of passing all data through the Windows socket interfaces for the TCP/IP solution? The dll wrappers (there are obviously two approaches which DLL is to be wrapped) seem to have the lower performance penalty. Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Summer coding project proposal
On Wed, 2009-06-24 at 11:46 +0200, Michael Bruck wrote: On Wed, Jun 24, 2009 at 11:30, Øyvind Harboeoyvind.har...@zylin.com wrote: But why should we go for such an inferior and specif solution when a more general one is proposed and worked on? What are the speed/roundtrip time implications of passing all data through the Windows socket interfaces for the TCP/IP solution? I have posited that they will be unkind to the driver, but I don't know. The dll wrappers (there are obviously two approaches which DLL is to be wrapped) seem to have the lower performance penalty. There are options. But it seems that FTD2XX will be the preferred solution on Windows, and it may take a performance penalty to do so. Such is the GPL. I believe the very best performance will come by fixing libusb+libftdi, which is another reason that I have lauded it since the start. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Summer coding project proposal
On Wed, Jun 24, 2009 at 11:48, Øyvind Harboeoyvind.har...@zylin.com wrote: On Wed, Jun 24, 2009 at 11:46 AM, Michael Bruckmbr...@digenius.de wrote: On Wed, Jun 24, 2009 at 11:30, Øyvind Harboeoyvind.har...@zylin.com wrote: But why should we go for such an inferior and specif solution when a more general one is proposed and worked on? What are the speed/roundtrip time implications of passing all data through the Windows socket interfaces for the TCP/IP solution? Possibily neglible as OpenOCD is already highly geared towards long latency interfaces. It would have to be measured. This may be valid for high-speed data transfers (but on arm11 for example only in the fast memwrite mode that replaces status polling with fixed delays). I doubt that for single-stepping, where the whole processor state is fetched register-by-register, the long-latency-optimizations make much of a difference. Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Summer coding project proposal
On Wed, Jun 24, 2009 at 12:23, Michael Bruckmbr...@digenius.de wrote: On Wed, Jun 24, 2009 at 11:42, Zach Welchz...@superlucidity.net wrote: On Wed, 2009-06-24 at 11:18 +0200, Magnus Lundin wrote: Simple project for a CS student. A wrapper with a libftdi interface calling libftd2xx, as a project using a LGPL license So any user can take their binary copy of OpenOCD linked against libftdi and simply replace the libftdi dll file, no need to play with system files or drivers. Is such a library illegal ? Who would have standing to complain ? You are doing it to circumvent the GPL. I think that is illegal. You would be contravening this copyright holder's intention, which would make you liable for any possible infringement that I could show. If a third party develops a libftdi.dll replacement then there is no reason a user can not use that replacement. The GPL license that applies to the user does not restrict at all what he does with the code or binary as long as he does not distribute binaries of it. Obviously to put the dll wrapper wrapper under a GPL+exceptions license it would have to be written from scratch rather than just copypasting GPLed libftdi header files (although one could ask the libfti author to re-license his/her files). I missed the part where it's LGPL, then it seems to fall under the definition of Application and the if the incorporated material is not limited to numerical parameters, data structure layouts and accessors, or small macros, clause applies. Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Summer coding project proposal
Michael Bruck wrote: If a third party develops a libftdi.dll replacement then there is no reason a user can not use that replacement. The GPL license that applies to the user does not restrict at all what he does with the code or binary as long as he does not distribute binaries of it. Obviously to put the dll wrapper wrapper under a GPL+exceptions license it would have to be written from scratch rather than just copypasting GPLed libftdi header files (although one could ask the libfti author to re-license his/her files). Yes, another developer could produce such a library. There might be GPL Gray areas, etc But the discussion would need to be some place else, not on this list. :) Tom ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] OpenOCD license
Hi all, In the face of Rick's abrupt departure, I feel that I need to provide more status and summary of the licensing situation. Each copyright holder has the right to dictate whether or not they will allow license terms to be changed in their derived works. That is immutable, and I do not feel guilty for asserting my rights here. I feel bad if some think that I have been dictating beyond those rights, more than just getting stuff done that needs to be done. Rick won the uN versus uintN_t debate by the end of it, so his feedback was always being heard and incorporated by me. I am steering with direction from the community, as I have made my clear responsibility since becoming a maintainer. However, those responsibilities do not affect my rights as a copyright holder, and here we see a conflict. Since my arrival, this OpenOCD list has often preferred talk over action too often, and I far prefer to engage in discussion on constructive issues like design, devices, and patches. I do not feel guilty for taking actions to fix the problems that seem apparent after inspection, because no one has been doing such work for the project Some decisions may prove to be wrong and need fixing, but others need executive order to be carried out while awaiting those fixes. I intend to carry on in this tradition, pro-actively addressing the community's needs and defending the terms of the GPL. Licensing violations are one such area where compliance action needs to be demanded immediately by the appropriate stakeholders, to preserve the overall legal integrity of the project. By protecting my own rights, I protect the rights of all free software users that do not want to see the GPL compromised. Given that even Rick conceded the past and current repository contents have been released under the GPL, further discussion is not a meaningful solution to violations of the license. The means to achieve compliance with technical solutions have been outlined and are wholly acceptable; any exception would apply only to a fork of the project, branched before any GPL-only revisions went into the repository. Because of my objections to an exception to the GPL, I will not allow a change to the license in the trunk of the repository, so compliance needs to be sought to ensure that distributors of binaries respect the limitations of the GPL. That seems like straightforward legal logic, not totalitarianism. The totalitarians are the FSF, who designed the legal language of the license to be this way; however, I think that is tantamount to saying the Founding Fathers were totalitarians seeking liberty, justice, and the American way. Sadly, those same people would be called terrorists in the US today; indeed, this should draw some meaningful parallels. These are the facts as I have come to understand them, and no one has given me any solid evidence to refute these points. I wish there were, because I tell you -- it sucks to have to be the one to push for license compliance like this. I do not like being seen as the enemy in the eyes of the community, but I feel it is necessary despite these consequences. Once the positive consequences have been seen and appreciated fully, maybe everyone will come around (or even thank me... I can dream). Until then, please feel free to hate me for sticking to my ideals and believing in the wisdom of foresight on these matters. I can take it. Otherwise, I am looking forward to seeing the community move past these issues and onto more constructive development matters. Cheers, Zach Welch Corvallis, OR ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Summer coding project proposal
On Wed, 2009-06-24 at 12:23 +0200, Michael Bruck wrote: On Wed, Jun 24, 2009 at 11:42, Zach Welchz...@superlucidity.net wrote: On Wed, 2009-06-24 at 11:18 +0200, Magnus Lundin wrote: Simple project for a CS student. A wrapper with a libftdi interface calling libftd2xx, as a project using a LGPL license So any user can take their binary copy of OpenOCD linked against libftdi and simply replace the libftdi dll file, no need to play with system files or drivers. Is such a library illegal ? Who would have standing to complain ? You are doing it to circumvent the GPL. I think that is illegal. You would be contravening this copyright holder's intention, which would make you liable for any possible infringement that I could show. If a third party develops a libftdi.dll replacement then there is no reason a user can not use that replacement. The GPL license that applies to the user does not restrict at all what he does with the code or binary as long as he does not distribute binaries of it. Obviously to put the dll wrapper wrapper under a GPL+exceptions license it would have to be written from scratch rather than just copypasting GPLed libftdi header files (although one could ask the libfti author to re-license his/her files). No matter how you want to call the legality of the situation, I hope that you will admit there is something clearly unethically about what you are proposing. I hope the libftdi author(s) would never allow re-licensing for such dubious efforts. Since it remains a legal gray area, it seems silly to go down this road when solutions exist that are compliant, without any kind of effective subterfuge. Furthermore, I think individuals can be held liable for inducing infringement, which is where IANAL becomes useful in some respects. I have been repeatedly warning _against_ infringement and to consult with an attorney on any possible solutions that you intend to distribute in binary form. You should be too. There is no infringement here, so there is nothing to debate. The issue gets a bit murky when the replacement dll is bundled with OpenOCD, but that is not really necessary, the user can load it from elsewhere. The intention to design this library for the purpose of circumventing the GPL is being documented on this list. Sure, it's murky, but the discussion only helps to build my case to defend against this option. The problem you will face: can anyone in this community show they were working on that option for us, before all of these issues came to light? Lacking a paper trail, how can you explain your motive for doing this? If there _is_ shown to be infringement, it will be plainly intentional, and that may mean some cash will be left over after paying the lawyers. By all means, show me this evidence and I will permit this option. If you cannot, then please drop it from further consideration, for the ethical considerations alone. Or are ethics an unrealistic position from which to make such a plea? Certainly, you _are_ free to ignore my ethical stance; likewise, do not expect me to help you in those efforts. I see them as sabotaging the free software community. Legal gray areas do not have GPL-compliant solutions. They take risks of being compliant or not. Risks are unacceptable for OpenOCD vendors, when there may exist potential threats. These risks can be avoided, because they disappear by embracing full and unarguable GPL-compliance. - FTDI ? no their libray and driver is called in accordance with their documentation. - OpenOCD ? nobody has touched a single line of OpenOCD code - Copyright holders of libftdi, Intra2Net AG ? no, libftdi is LGPL and the new library would only use the header file in accordance with LGPL section 3. Would it work? with a bit of tweaking I would think so. Is this a blatant attempt just to work around the problems with OpenOCD, GPL and libftd2xx ? What do I know ? Maybe yes, but that does not make it illegal. It might. This is a very gray area. For the love of all that is sane, why do you want to keep pressing these fronts, when other options have been presented that will solve the problems without any objections? TCP/IP will impose a speed penalty. It may be a nice extension for other purposes, but for daily work it is most likely not the best solution. In addition to that solution, I have pointed out that libusb and libftdi features and performance can be improved. The community can try to get FTDI to go LGPL with their code. There is also a build kit, which creates user-built binaries; this should produce the same binaries they were getting before this problem, so there would be zero performance impact to users (other than a longer install process). Altogether, this puts four options on the table, all of which still seem realistic to me. Can you show me concrete evidence to the contrary? The build kit solves the problem
[Openocd-development] Can we get back to forward progress?
As far as I can see there are two solutions being worked on: USB (winusb, libusb) and libftdi and tcpip/Sockets/pipes/ipc Can the person who is heading up each task start a NEW thread and identify who else is working with you and the state of the work. I for one will be willing to test anything. Tom ps. let's let the old threads die ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] License
On Wed, 2009-06-24 at 12:20 +0200, Dominic Rath wrote: This goes inentionally to you alone, feel free to bring it up on the list if you want... You have made me start to wonder if it would be possible to bring some sort of claim of misrepresentation against the project authors, were your suggestion to be taken by others. The COPYING file is the standard way of notifying potential authors of a project's license, so I think that I would have a good chance of proving that the authors neglected to inform authors -- whether by intention or accident. I suppose that means I have to remove all code you've contributed from the repository in order to protect myself from what you might or might not do. I will also have to ask all distributors to remove any version since january 2009. Actually, that would no longer be acceptable; you are welcome to fork the code, but I ask that you avoid making such changes. The license is and was GPL, and I am now a copyright holder, maintainer, and active contributor to the project. You would be taking a unilateral action that would not be uniformly supported by the OpenOCD community, whereas I am asserting my individual copyrights. I can do what I have done, but the community should vote to exile my changes. You have abdicated your authority in this community, and I resent your showing up here and making threats to remove my code. I have asserted my rights after making a clear case that I have earned the privilege to do so. You have effectively admitted to your own negligence with regards to licensing, which you must now accept like a grown-up. Sorry. I am trying to work with the community. What are you trying to do? Who is the totalitarian dictator here? Not that I think that any remotely sane court would consider your claim, but I certainly wont take this chance. You've been threatening me personally with potential legal actions at least twice, and this is nothing I'm willing to accept. I am threatening violators with action. Are you a violator? No, and I would not take action against you unless you violated my copyrights, which I have no reason to believe is the case or would be. Right? I will also say again that I am not interested in taking action for any past violations, but I am willing to defend my rights in the future. This position was made clear by me from the outset. Your opinion about what a remotely sane court would or would not consider is exactly that, and you need to decide whether you are willing to test it. Please get legal counsel before taking any action with the repository, unless you would like to help constructively move the community out of this morass. That will be my primary intention and focus. Please think about what you've just suggested and feel free to clarify your point. Ditto. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD license
it sucks to have to be the one to push for license compliance like this Then don't! I'm just a user of OpenOCD so you have all right to ignore what I'm saying as you'll find that I'm less important, but it's about time people here start to realize the real clients are users and not developers and users don't give a sh*t about GPL violations. Why would anyone want to waste time and effort on fixing this purely theoretic issue? Use the time to implement useful features like SWD or threadsupport instead. You're acting like you have no choice but to point out this issue and write 700 mails about it. You of all people can fix it easily. Give up your copyright or allow relicensing it under anything that is not as gray and debatable as GPL. As a sidenote I still don't see the issue. The spirit of GPL is to allow to make modifications to an application that is distributed in binary form. OpenOCD with FTD2xx allows this, no discussion! So stop using the FAQ of people holier then the pope to argument OpenOCD can't be released on Windows. I really don't get it. If OpenOCD were my baby I would like to see it get popular and loved around the world. What's the use of having a super-great application that nobody will use because some people are stubborn and don't see further then idealistic BS. Just my 2 cents but I'm quite sure a lot more people are getting tired of this. Change the license or ignore the theoretic violation and get the next version out there in binary form for Windows using FTD2xx. Please point out EXACTLY why you are so against a GPL exception? What's your hidden agenda cause I refuse to believe this is pure idealism. If I had something to say I would ask every contributor to state if they allow a relicense. If not, strip out their code and rewrite it. That can't take longer then making the workarounds people are discussing now. While we're at it, demand that contributors donate their copyright to the OpenOCD foundation or whatever, so these discussions are a thing of the past. I don't want to run a 2nd application to be able to use FTD2xx on windows. I already have to run OpenOCD and gdb, more then enough to keep track off. gr. Ronald Original Message Subject: [Openocd-development] OpenOCD license From: Zach Welch z...@superlucidity.net To: openocd-development openocd-development@lists.berlios.de Date: Wed Jun 24 2009 13:28:17 GMT+0200 (Romance Standard Time) Hi all, In the face of Rick's abrupt departure, I feel that I need to provide more status and summary of the licensing situation. Each copyright holder has the right to dictate whether or not they will allow license terms to be changed in their derived works. That is immutable, and I do not feel guilty for asserting my rights here. I feel bad if some think that I have been dictating beyond those rights, more than just getting stuff done that needs to be done. Rick won the uN versus uintN_t debate by the end of it, so his feedback was always being heard and incorporated by me. I am steering with direction from the community, as I have made my clear responsibility since becoming a maintainer. However, those responsibilities do not affect my rights as a copyright holder, and here we see a conflict. Since my arrival, this OpenOCD list has often preferred talk over action too often, and I far prefer to engage in discussion on constructive issues like design, devices, and patches. I do not feel guilty for taking actions to fix the problems that seem apparent after inspection, because no one has been doing such work for the project Some decisions may prove to be wrong and need fixing, but others need executive order to be carried out while awaiting those fixes. I intend to carry on in this tradition, pro-actively addressing the community's needs and defending the terms of the GPL. Licensing violations are one such area where compliance action needs to be demanded immediately by the appropriate stakeholders, to preserve the overall legal integrity of the project. By protecting my own rights, I protect the rights of all free software users that do not want to see the GPL compromised. Given that even Rick conceded the past and current repository contents have been released under the GPL, further discussion is not a meaningful solution to violations of the license. The means to achieve compliance with technical solutions have been outlined and are wholly acceptable; any exception would apply only to a fork of the project, branched before any GPL-only revisions went into the repository. Because of my objections to an exception to the GPL, I will not allow a change to the license in the trunk of the repository, so compliance needs to be sought to ensure that distributors of binaries respect the limitations of the GPL. That seems like straightforward legal logic, not totalitarianism. The totalitarians are the FSF, who designed the legal language of
Re: [Openocd-development] License
Hi Dominic, first of all: there is every evidence that the technical problems that USB are encountering these days will be resolved *LONG* before any change in license could be effecuated. I even believe that USB problems will be fixed before the community will have finished debating the ramifications of a specific license change proposal(none has been posted so far). About GPL that was there from the start: One of the *main* reasons I decided to get into OpenOCD at revision 214 (or was it before?) was that I felt confident that the GPL license protected my interests and that a pure GPL license *without* any exceptions was the least of evils. I saw downsides and upsides, but overall I felt that pure GPL was a good choice. There was/is lots of non-GPL alternatives out there that I would have considered instead of OpenOCD. Even more important, I knew that the license could not be changed after I and others had made non-trivial changes without me the community having an oportunity to veto it. After a while I saw that enough work was put down into the GPL license that changing it became impractical for better or worse. One of the nice things about GPL is that it is impossible to put GPL on a project first, then a couple of years later say Ha! I really intended not GPL but some other license Nobody will sue you if you stick to the GPL license that you put down in the first place, but if you start to say I really intended something else than I wrote down, then you're on a slippery slope. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] License
On Wed, 2009-06-24 at 12:20 +0200, Dominic Rath wrote: / This goes inentionally to you alone, feel free to bring it up on the list if you want... // // You have made me start to wonder if it would be possible to bring some // sort of claim of misrepresentation against the project authors, were // your suggestion to be taken by others. The COPYING file is the standard // way of notifying potential authors of a project's license, so I think // that I would have a good chance of proving that the authors neglected to // inform authors -- whether by intention or accident. // // I suppose that means I have to remove all code you've contributed from // the repository in order to protect myself from what you might or might // not do. I will also have to ask all distributors to remove any version // since january 2009. / Actually, that would no longer be acceptable; you are welcome to fork the code, but I ask that you avoid making such changes. The license is and was GPL, and I am now a copyright holder, maintainer, and active contributor to the project. You would be taking a unilateral action that would not be uniformly supported by the OpenOCD community, whereas I am asserting my individual copyrights. I can do what I have done, but the community should vote to exile my changes. You maybe are holder, maintainer, contributor ... but you are not the CREATOR / AUTHOR ! Please respect MR. Dominic Rath. He is the CREATOR of OpenOCD 2004 (with 1-2 years or more of intensive coding) I was myself a contributor to the project, but before there ais SVN ! Yes, strange for you. But I am a contributor too. What 'project contribution' means for you? - Adding a lot of patches - Donating hardware to end-users - Building binary for easy-of-use - Reading the forum - Writing to the forum - Documenting the project - ... All these tasks were needed to bring OpenOCD as it is actually. Each project/products needs manager - developer - tester - distributor - end-userS The end-users know what they need. OpenOCD has a success story as open source from 2004. Please respect the story ! Until now, the success story says D2XX is needed ! Sorry, it is. I am sure there will be better GPL code to push the D2XX out from the source. You will have a better GPL but a lot of regression regarding final speed. This is my opinion. - You have abdicated your authority in this community, and I resent your showing up here and making threats to remove my code. I have asserted my rights after making a clear case that I have earned the privilege to do so. You have effectively admitted to your own negligence with regards to licensing, which you must now accept like a grown-up. Sorry. I am trying to work with the community. What are you trying to do? Who is the totalitarian dictator here? / Not that I think that any remotely sane court would consider your // claim, but I certainly wont take this chance. You've been threatening // me personally with potential legal actions at least twice, and this is // nothing I'm willing to accept. / I am threatening violators with action. Are you a violator? No, and I would not take action against you unless you violated my copyrights, which I have no reason to believe is the case or would be. Right? I will also say again that I am not interested in taking action for any past violations, but I am willing to defend my rights in the future. This position was made clear by me from the outset. Your opinion about what a remotely sane court would or would not consider is exactly that, and you need to decide whether you are willing to test it. Please get legal counsel before taking any action with the repository, unless you would like to help constructively move the community out of this morass. That will be my primary intention and focus. / Please think about what you've just suggested and feel free to clarify // your point. / Ditto. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] License
On Wed, 2009-06-24 at 14:08 +0200, Øyvind Harboe wrote: Hi Dominic, first of all: there is every evidence that the technical problems that USB are encountering these days will be resolved *LONG* before any change in license could be effecuated. I even believe that USB problems will be fixed before the community will have finished debating the ramifications of a specific license change proposal(none has been posted so far). About GPL that was there from the start: One of the *main* reasons I decided to get into OpenOCD at revision 214 (or was it before?) was that I felt confident that the GPL license protected my interests and that a pure GPL license *without* any exceptions was the least of evils. I saw downsides and upsides, but overall I felt that pure GPL was a good choice. There was/is lots of non-GPL alternatives out there that I would have considered instead of OpenOCD. Even more important, I knew that the license could not be changed after I and others had made non-trivial changes without me the community having an oportunity to veto it. After a while I saw that enough work was put down into the GPL license that changing it became impractical for better or worse. One of the nice things about GPL is that it is impossible to put GPL on a project first, then a couple of years later say Ha! I really intended not GPL but some other license Nobody will sue you if you stick to the GPL license that you put down in the first place, but if you start to say I really intended something else than I wrote down, then you're on a slippery slope. This is an excellent point regarding the invalidity of I actually meant for the license to X. Would everyone be so keen to accept this if it were put into terms where X was take freedoms from all of you chumps? Coincidentally, that is exactly how I interpret the attempt to relicense the changes to allow an exception for proprietary linkage. At this point, there do not appear to exist any reasonable basis for arguing against this fact: the GPL was always the license for OpenOCD. Arguments to dispute this fact need to provide convincing evidence, and I think the repository justifies our position here -- not an exception. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] New Flash Target: Atmel AT91SAM3 - Cortex M3
Zach Welch wrote: Fixed. There were a few could be used uninitialized warnings too. These seem like they should have been covered by --enable-werror. Duane, are you building with that option before committing changes? I normally build with optimization disabled so that I can *debug* the code - with the optimizer disabled, the uninitialized errors will not occur. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] New Flash Target: Atmel AT91SAM3 - Cortex M3
David Brownell wrote:
I get all kinds of build errors on Ubuntu 9.04/x86_32 where the
chip details banks get initialized. The errors made no sense to
me, and they went away when I changed the
.bank[0] = { ... },
.bank[1] = { ... },
to be
.bank = {{ ... }, { ... }},
i thought the bank[0] = { } was valid C99 initialization.
I've been using cygwin, by default uses:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Perhaps something has changed I am unaware of .
-Duane.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Openocd-svn] r2381 - trunk/src/helper
Spencer Oliver wrote: strok_r is not available on win32 - strok is said to be reentrant on win32. Not near a dev pc at the moment so i thought i would point it out - i can make the change later if you do not have time. Hmm... Perhaps we should add strtok_r() to the replacments.c file. We could take an instance from Newlib - it has a BSD licensed implimentation. What do you think? -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] New Flash Target: Atmel AT91SAM3 - Cortex M3
On Wed, 2009-06-24 at 09:09 -0400, Duane Ellis wrote: Zach Welch wrote: Fixed. There were a few could be used uninitialized warnings too. These seem like they should have been covered by --enable-werror. Duane, are you building with that option before committing changes? I normally build with optimization disabled so that I can *debug* the code - with the optimizer disabled, the uninitialized errors will not occur. Thank you! That explains it completely. I was a bit confused. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] New Flash Target: Atmel AT91SAM3 - Cortex M3
On Wed, 2009-06-24 at 09:13 -0400, Duane Ellis wrote:
David Brownell wrote:
I get all kinds of build errors on Ubuntu 9.04/x86_32 where the
chip details banks get initialized. The errors made no sense to
me, and they went away when I changed the
.bank[0] = { ... },
.bank[1] = { ... },
to be
.bank = {{ ... }, { ... }},
i thought the bank[0] = { } was valid C99 initialization.
I've been using cygwin, by default uses:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Perhaps something has changed I am unaware of .
I just realized that I left out the '.bank = ' bits.
Sorry for that minor mess, but it compiled. :)
--Z
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] New Flash Target: Atmel AT91SAM3 - Cortex M3
David Brownell wrote:
I get all kinds of build errors on Ubuntu 9.04/x86_32 where the
[snip]
.bank[0] = { ... },
duane i thought the bank[0] = { } was valid C99 initialization.
zach I just realized that I left out the '.bank = ' bits.
zach Sorry for that minor mess, but it compiled. :)
Huh? What do you mean? Confused.
-Duane.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Summer coding project proposal
On Wed, Jun 24, 2009 at 13:29, Zach Welchz...@superlucidity.net wrote: On Wed, 2009-06-24 at 12:23 +0200, Michael Bruck wrote: On Wed, Jun 24, 2009 at 11:42, Zach Welchz...@superlucidity.net wrote: On Wed, 2009-06-24 at 11:18 +0200, Magnus Lundin wrote: Simple project for a CS student. A wrapper with a libftdi interface calling libftd2xx, as a project using a LGPL license So any user can take their binary copy of OpenOCD linked against libftdi and simply replace the libftdi dll file, no need to play with system files or drivers. Is such a library illegal ? Who would have standing to complain ? You are doing it to circumvent the GPL. I think that is illegal. You would be contravening this copyright holder's intention, which would make you liable for any possible infringement that I could show. If a third party develops a libftdi.dll replacement then there is no reason a user can not use that replacement. The GPL license that applies to the user does not restrict at all what he does with the code or binary as long as he does not distribute binaries of it. Obviously to put the dll wrapper wrapper under a GPL+exceptions license it would have to be written from scratch rather than just copypasting GPLed libftdi header files (although one could ask the libfti author to re-license his/her files). No matter how you want to call the legality of the situation, I hope that you will admit there is something clearly unethically about what you are proposing. I hope the libftdi author(s) would never allow re-licensing for such dubious efforts. I don't see what is unethical here. The ethical discussion might have more weight if it wasn't directed at a solution that in the eyes of many people has helped the open source software project OpenOCD to become more popular on the Windows platform. I corrected myself in a later mail on the relicensing. No relicensing is necessary because the use of headers is permitted under the LGPL. Even if it were not it would be only a minor obstacle that can be easily circumnavigated legally by recreating them from scratch. Since it remains a legal gray area, it seems silly to go down this road when solutions exist that are compliant, without any kind of effective subterfuge. I don't see a legal gray area there at all. The gray area might be when distributing the replacement DLL *with* the package. Furthermore, I think individuals can be held liable for inducing infringement, which is where IANAL becomes useful in some respects. I have been repeatedly warning _against_ infringement and to consult with an attorney on any possible solutions that you intend to distribute in binary form. You should be too. There is no infringement here, so there is nothing to debate. The issue gets a bit murky when the replacement dll is bundled with OpenOCD, but that is not really necessary, the user can load it from elsewhere. The intention to design this library for the purpose of circumventing the GPL is being documented on this list. Sure, it's murky, but the discussion only helps to build my case to defend against this option. Your premise is wrong. The user is not restricted in what he can do with the software on his PC. This is crystal clear from the license and the FAQ. You can do all sorts of kinky stuff with the software in the sanctity of your hard drive, if you want to flip all bits or increment all jump addresses by 13 or replace a DLL, that is your right under the GPL. The problem you will face: can anyone in this community show they were working on that option for us, before all of these issues came to light? Lacking a paper trail, how can you explain your motive for doing this? If there _is_ shown to be infringement, it will be plainly intentional, and that may mean some cash will be left over after paying the lawyers. This is not necessary. Your copyright on parts of OpenOCD does not preclude a third party or in fact this project from developing a libftdi.dll replacement for whatever purpose and under whatever license. By all means, show me this evidence and I will permit this option. If you cannot, then please drop it from further consideration, for the ethical considerations alone. Or are ethics an unrealistic position from which to make such a plea? Certainly, you _are_ free to ignore my ethical stance; likewise, do not expect me to help you in those efforts. I see them as sabotaging the free software community. FTD2XX.dll is not the enemy, OpenOCD has used it to great advantage. My company's contribution to this project was not based on ethics but on the calculation that contributions from other users would feed back into the program and be of benefit to us. The potential for such additions is greatest when the quality/performance/usability of the product is at its maximum so as to attract more users and developers. What you describe as the ethical position is detrimental to the goals
Re: [Openocd-development] Summer coding project proposal
Given that you are in the USA you could probably patent it as a business method and prevent anyone from using it or collecting money for it. This should have read: ... or you could collect money for it. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] New Flash Target: Atmel AT91SAM3 - Cortex M3
On Wed, 2009-06-24 at 09:56 -0400, Duane Ellis wrote:
David Brownell wrote:
I get all kinds of build errors on Ubuntu 9.04/x86_32 where the
[snip]
.bank[0] = { ... },
duane i thought the bank[0] = { } was valid C99 initialization.
zach I just realized that I left out the '.bank = ' bits.
zach Sorry for that minor mess, but it compiled. :)
Huh? What do you mean? Confused.
Well, I changed
.bank[0] = { ... },
.bank[1] = { ... },
to
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] New Flash Target: Atmel AT91SAM3 - Cortex M3
On Wed, 2009-06-24 at 07:28 -0700, Zach Welch wrote:
On Wed, 2009-06-24 at 09:56 -0400, Duane Ellis wrote:
David Brownell wrote:
I get all kinds of build errors on Ubuntu 9.04/x86_32 where the
[snip]
.bank[0] = { ... },
duane i thought the bank[0] = { } was valid C99 initialization.
zach I just realized that I left out the '.bank = ' bits.
zach Sorry for that minor mess, but it compiled. :)
Huh? What do you mean? Confused.
Well, I changed
.bank[0] = { ... },
.bank[1] = { ... },
to
{ { ... }, { ... } }.
but it should have been:
.bank = { { ... }, { ... } }
See? I missed the '.bank =' part and I hit send accidentally
before finishing this message. Sorry.
Cheers,
Zach
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] openocd.texi - fixes from sam3 update
Fix formatting bug in at91sam7 doc added with the at91sam3 support;
and some formatting issues with sam7 and stm32 keyword params.
Tweak at91sam3 docs. Remove ninth nibble from flash bank addresses,
clarify at91sam3 show variants and that the flash bank layout is
not needed as a parameter (unlike with sam7); formatting fixes.
---
doc/openocd.texi | 62 +
1 file changed, 35 insertions(+), 27 deletions(-)
Fix formatting bug in at91sam7 doc added with the at91sam3 support;
and some formatting issues with sam7 and stm32 keyword params.
Tweak at91sam3 docs. Remove ninth nibble from flash bank addresses,
clarify at91sam3 show variants and that the flash bank layout is
not needed as a parameter (unlike with sam7); formatting fixes.
---
doc/openocd.texi | 62 +
1 file changed, 35 insertions(+), 27 deletions(-)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -3376,57 +3376,66 @@ flash bank aduc702x 0 0 0 0 $_TARGETNAME
@deffn {Flash Driver} at91sam3
@cindex at91sam3
-All members of the AT91SAM3 (cortex-M3) microcontroller family from
-atmel include internal flash and use the Cortex-M3 core. The driver
+All members of the AT91SAM3 microcontroller family from
+Atmel include internal flash and use ARM's Cortex-M3 core. The driver
currently (6/22/09) recognizes the AT91SAM3U[1/2/4][C/E] chips. Note
that the driver was orginaly developed and tested using the
AT91SAM3U4E, using a SAM3U-EK eval board. Support for other chips in
-the family where cribbed from the data sheet [Note to future
+the family was cribbed from the data sheet. @emph{Note to future
readers/updaters: Please remove this worrysome comment after other
-chips are confirmed].
+chips are confirmed.}
The AT91SAM3U4[E/C] (256K) chips have 2 flash banks, the other chips
-(3U[1/2][E/C]) have 1 flash bank, in all cases the flash banks are at
-the following fixed locations.
+(3U[1/2][E/C]) have 1 flash bank. In all cases the flash banks are at
+the following fixed locations:
@example
# Flash bank 0 - all chips
-flash bank at91sam3 0x8 0 1 1 $_TARGETNAME
+flash bank at91sam3 0x0008 0 1 1 $_TARGETNAME
# Flash bank 1 - only 256K chips
-flash bank at91sam3 0x00010 0 1 1 $_TARGETNAME
+flash bank at91sam3 0x0010 0 1 1 $_TARGETNAME
@end example
-Internally, the AT91SAM3 flash memory is organized as follows:
+Internally, the AT91SAM3 flash memory is organized as follows.
+Unlike the AT91SAM7 chips, these are not used as parameters
+to the @command{flash bank} command:
@itemize
-...@item @var{N-Banks:} 256K chips have 2 banks, others have 1 bank.
-...@item @var{Bank Size:} 128K/64K Per flash bank
-...@item @var{Sectors:} 16 or 8 per bank
-...@item @var{SectorSize:} 8K Per Sector
-...@item @var{PageSize:} 256 bytes per page. Note that OpenOCD operates on 'sector' sizes, not page sizes.
+...@item @emph{N-Banks:} 256K chips have 2 banks, others have 1 bank.
+...@item @emph{Bank Size:} 128K/64K Per flash bank
+...@item @emph{Sectors:} 16 or 8 per bank
+...@item @emph{SectorSize:} 8K Per Sector
+...@item @emph{PageSize:} 256 bytes per page. Note that OpenOCD operates on 'sector' sizes, not page sizes.
@end itemize
-The AT91SAM3 driver adds an additional command:
+The AT91SAM3 driver adds some additional commands:
-...@deffn Command {at91sam3 gpnvm set|clear|show all|NUMBER}
-This command allows you to set, clear, or show the state of the GPNVM bits.
+...@deffn Command {at91sam3 gpnvm}
+...@deffnx Command {at91sam3 gpnvm clear} number
+...@deffnx Command {at91sam3 gpnvm set} number
+...@deffnx Command {at91sam3 gpnvm show} [...@option{all}|number]
+With no parameters, @command{show} or @command{show all},
+shows the status of all GPNVM bits.
+With @command{show} @var{number}, displays that bit.
+
+With @command{set} @var{number} or @command{clear} @var{number},
+modifies that GPNVM bit.
@end deffn
@deffn Command {at91sam3 info}
This command attempts to display information about the AT91SAM3
-chip. @b{First} it read the @var{CHIPID_CIDR} [address 0x400e0740, see
+chip. @emph{First} it read the @code{CHIPID_CIDR} [address 0x400e0740, see
Section 28.2.1, page 505 of the AT91SAM3U 29/may/2009 datasheet,
-document id: doc6430A] and decodes the values. @b{Second} it reads the
+document id: doc6430A] and decodes the values. @emph{Second} it reads the
various clock configuration registers and attempts to display how it
believes the chip is configured. By default, the SLOWCLK is assumed to
-be 32768 Hz, see the command @b{at91sam3 slowclk}.
+be 32768 Hz, see the command @command{at91sam3 slowclk}.
@end deffn
-...@deffn Command {at91sam3 slowclk [VALUE]}
+...@deffn Command {at91sam3 slowclk} [value]
This command shows/sets the slow clock frequency used in the
-...@b{at91sam3 info} command calculations above.
+...@command{at91sam3 info} command calculations above.
@end deffn
-
@end deffn
@deffn {Flash
Re: [Openocd-development] OpenOCD license
Hello: I'll just participate in this horrible flame once. On Wednesday 24 June 2009 14:02:26 Ronald Vanschoren wrote: it sucks to have to be the one to push for license compliance like this Then don't! I'm just a user of OpenOCD so you have all right to ignore what I'm saying as you'll find that I'm less important, but it's about time people here start to realize the real clients are users and not developers and users don't give a sh*t about GPL violations. You are not less important, you are just another kind. Clients are important as well, just that you (we) don't pay for using the software. Having said this I don't understand how you (or anyone sensible) could support violating licenses. Do you have the habit of breaking laws for the sake of it? Why would anyone want to waste time and effort on fixing this purely theoretic issue? Use the time to implement useful features like SWD or threadsupport instead. You're acting like you have no choice but to point out this issue and write 700 mails about it. You of all people can fix it easily. Give up your copyright or allow relicensing it under anything that is not as gray and debatable as GPL. I don't think enforcing one's rights is loosing time. This is not a theoretic issue. GPL is the license and it states that whatever you link against and distribute should respect GPL freedom, among others, being able to get the source code. You can do things about this, for instance persuading FTDI to free the FTD2xx driver source and relicense it with GPL or any other compatible license for the issue: adm...@ftdichip.com As a sidenote I still don't see the issue. The spirit of GPL is to allow to make modifications to an application that is distributed in binary form. OpenOCD with FTD2xx allows this, no discussion! So stop using the FAQ of people holier then the pope to argument OpenOCD can't be released on Windows. You wouldn't be able to do modifications on the FTD2xx library, so no point for this. I really don't get it. If OpenOCD were my baby I would like to see it get popular and loved around the world. What's the use of having a super-great application that nobody will use because some people are stubborn and don't see further then idealistic BS. If OpenOCD or whatever other is my baby, I would do what I would like with it. Trying to get it popular, maybe not, give it for free, get paid for it or even license it under GPL terms. In this case rules were dictated from the beginning. Just my 2 cents but I'm quite sure a lot more people are getting tired of this. Change the license or ignore the theoretic violation and get the next version out there in binary form for Windows using FTD2xx. If you (or others) are so interested in a license change, then answer this questions: · Have you contacted every copyright holder and ask for his opinion? · if (s)he is reluctant to change license what will give you in compensation? · Are you willing to pay money for the work they have done to change license? · Are you willing to accept anyone is not going to admit a license change? License is not democracy, not even meritocracy, is consensus. License is what it is and only an agreement of all copyright holders can change that. If I had something to say I would ask every contributor to state if they allow a relicense. If not, strip out their code and rewrite it. That can't take longer then making the workarounds people are discussing now. While we're at it, demand that contributors donate their copyright to the OpenOCD foundation or whatever, so these discussions are a thing of the past. I don't want to run a 2nd application to be able to use FTD2xx on windows. I already have to run OpenOCD and gdb, more then enough to keep track off. gr. Ronald What I don't understand so far is why it is so important to add an exception to the license instead of: · Improving free FTDI library · Asking FTDI to release and free the FTD2xx library · Make people interested in running FTD2xx build his own copy/binary of openocd Most of this options requires less work than tirelessly quarreling on the list. It is possible not using FTD2xx, it is also possible using it. Whoever is interested enough on any of those aspects should care for it, but not putting pressure or insulting(*) developers to do what they claim. Why is it easier to put pressure on developers who actually does a great job and not on a company that should encourage its products to be sell? (*) I don't refer you, Ronald. Regards, Pd: This e-mail express a strictly individual position. -- Raúl Sánchez Siles Departamento de Montaje INFOGLOBAL, S. A. * C/ Virgilio, 2. Ciudad de la Imagen. 28223 Pozuelo de Alarcón (Madrid), España * T: +34 91 506 40 00 * F: +34 91 506 40 01 ___ Openocd-development mailing list Openocd-development@lists.berlios.de
Re: [Openocd-development] FT2232 Windows - summary of options
David Brownell pisze: Notice the complete disregard of technical arguments here. That's a good sign that the person making the argument has no real contribution to make, beyond invective. That's probably because I'm a USER, not a contributor. Quite simple. Under the GPL. From the very first public release, that has been part of it. You download it, and the GPL is there. That brings along with it certain rules. GPL. GPL. GPL... How about Users, Users, Users? Again - The Most Important Qestion - Is OpenOCD meant for users to use, or just to be 100%-GPL-at-any-cost? You're the ONLY one advocating a we-don't-care-for-X mindset. Damn, I see that the opposite way - 5-10 ppl are 100% GPL (that's where you are) while everyone else is like why create artificial problems?. You're also *falsely attributing* a mindset to other people. That's often called lying. Whatever. 4\/3!! ___ 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
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. If the GPL-chain has to end on the system libs, what is the purpose of having GPL-with-exception? Such code clearly cannot be used in ANY GPL project, because such project would also have to have an exception for that GPL-with-exception. So what - now we would have an endless chain of exceptions? Either I'm too stupid to understand that, or the license is too stupid for normal person to understand this nonsense. Moreover - you are quoting the INTERPRETATION of the license found on the site, that has huge interest in the most extreme interpretation of all... Where does that say that in the license? The text alone, not The most extreme FAQ about GPL on this planet. See ... how your first no explanation whine was in fact fully addressed at the very beginning of the flamewar you have been feeding. Let's not forget who ignited that whole war. You. Are you a distributor? If so, why aren't you having this conversation with your own legal team? Again - I do not own a company, nor do I work for one that would make any money on OpenOCD. I'm just a Windows USER who wishes OpenOCD to be popular. That's it - nothing more, nothing less. While you see no problems with lack of installer with ftd2xx.dll, I see quite a lot. So our lack of understanding is mutual - I just don't get GPL, you just don't get libftdi+Windows problems. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 Windows - summary of options
On Wed, 2009-06-24 at 16:56 +0200, Freddie Chopin wrote: GPL. GPL. GPL... How about Users, Users, Users? Again - The Most Important Qestion - Is OpenOCD meant for users to use, or just to be 100%-GPL-at-any-cost? You're the ONLY one advocating a we-don't-care-for-X mindset. Damn, I see that the opposite way - 5-10 ppl are 100% GPL (that's where you are) while everyone else is like why create artificial problems?. Freddie, I have been involved with a number of distributed group projects and GPL is the best way to go to insure the collective work will survive the longest. Case and point. I wrote a Wireless X.25 packet switch in the 1980s, it was used world wide on Amateur Packet Radio. It was called The ROSE X.25 Packet Switch. It was not open source, I sold rights to it, ended up working on it for a year and then the project was flushed. I was burned out by this and no longer developed the switch and ROSE died. I was a core developer on osCommerce (aka The Exchange Project) that project seems to be all but dead as well, but there are many forks and some of them are still alive. Personally I still use it for one of my websites. (GPL) I have made a few changes to GNUBG (GNU Backgammon), nothing big, but every little bit helps. (GPL) I also play backgammon on FIBS (First Internet Backgammon Server) and for a while tried to get the clients used there modernized. Sadly none of them are really open source, I did get a few copies of source, but the most popular one the author will not allow it to be converted to GPL and they demand rights to any code I develop, with no rights to me (or others). (closed) I also took over a dead project that was a Tourney Robot for FIBS. The original author long lost interest, but because it was GPL and posted in a public place I was able to get the code and make improvements, after seeing those updates the author did get responsive to my questions, etc. The fact that I was able to get the source and do something without asking anyone for anything made it possible. As a developer I DO care about the license. If it is not GPL (or compatible) I will not waste my time. Now as a USER I also check the license, if it is GPL then I know I can become a developer, if needed. Could it be that the 5-10 people that are GPL 110% might just be the active developers? Tom ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Summer coding project proposal
On Wed, 2009-06-24 at 16:00 +0200, Michael Bruck wrote: On Wed, Jun 24, 2009 at 13:29, Zach Welchz...@superlucidity.net wrote: On Wed, 2009-06-24 at 12:23 +0200, Michael Bruck wrote: On Wed, Jun 24, 2009 at 11:42, Zach Welchz...@superlucidity.net wrote: [snip] There is no infringement here, so there is nothing to debate. The issue gets a bit murky when the replacement dll is bundled with OpenOCD, but that is not really necessary, the user can load it from elsewhere. The intention to design this library for the purpose of circumventing the GPL is being documented on this list. Sure, it's murky, but the discussion only helps to build my case to defend against this option. Your premise is wrong. The user is not restricted in what he can do with the software on his PC. This is crystal clear from the license and the FAQ. You can do all sorts of kinky stuff with the software in the sanctity of your hard drive, if you want to flip all bits or increment all jump addresses by 13 or replace a DLL, that is your right under the GPL. First, thank you! Yours has been one of the most pleasurable threads to engage in among these topics, and you have responded exactly as merited. Second, you win! You presented -- clearly -- the reasonable case for why this should be allowed. I sincerely apologize for taking the contrary view on this particular idea; your points above nailed me to the tree! It _is_ okay to produce a libftdi-ftd2xx wrapper package that is ABI compatible with the open source libftdi. Mea culpa. I am sorry to Magnus, you and the community for this unintentional oversight; I _really_ hope that I did not miss this suggestion from someone else, much earlier in these threads. You now have me second guessing myself on that! There has been too much action, and too many intentions to avoid the GPL entirely. Lacking such clear arguments, I may have shot them down prematurely, but I hope that is not the case. To be truthful, I think my original replies involved my continuing to think about the ftd2xx ABI, its restrictions, and a wrapper for that ABI (which doesn't even make sense, in hindsight). I am very glad that you pursued this matter to its fullest and kept my attention on it in a respectful way, and I am sorry if my earlier messages failed to return those favors. It was after 2am when I got the first message in this thread; it's 8am now. It has been a full day, and my desire to be highly responsive to the community has started to become a double-edged sword at this point. Even as such, you managed to help resolve this. I _really_ wish everyone would come at these issues with the same kind of lucidity as you have demonstrated. So, again, thank you. There is now another option for the community to consider, which is lower hanging and probably more appealing for most distributors. [snip] In addition to that solution, I have pointed out that libusb and libftdi features and performance can be improved. The community can try to get FTDI to go LGPL with their code. There is also a build kit, which creates user-built binaries; this should produce the same binaries they were getting before this problem, so there would be zero performance impact to users (other than a longer install process). Altogether, this puts four options on the table, all of which still seem realistic to me. Can you show me concrete evidence to the contrary? The build kit solves the problem completely, and that kind of tool does not seem like a difficult challenge for an experienced developer. Having to build OpenOCD yourself is a significant obstacle to wider distribution. The libusb improvements certainly sound interesting, however no one has stepped forward to implement them or to pay someone to implement them. They may or may not also require some reverse engineering plus extensive profiling that would make them more time-consuming than the wrapper. So they don't seem like a near-term solution at the moment. Others have stated emphatically that the specifications are open and available for the developers to take a whack at replacing their library. Unless it is incomplete or inaccurate, the matter should be straightforward enough. :) Heh. I would love to help fix it, but I am constrained in ways that I have previously expressed but will not repeat out of modesty and respect. I have come up with another new idea, but I need to vet it with the FSF before I suggest it here. I _may_ have found a new loophole (related to the build kit), but I am very uncertain about its legality. Heck, I may ask the FSF to pay me to bury it forever, if it is truly novel! ;) While it would improve things a little, I do not want to get hopes up. Given that you are in the USA you could probably patent it as a business method and prevent anyone from using it or collecting money for it. Good idea. Thanks Heh, just kidding. I'm fairly anti-patents, given
Re: [Openocd-development] FT2232 Windows - summary of options
On Wednesday 24 June 2009, Freddie Chopin wrote: Notice the complete disregard of technical arguments here. That's a good sign that the person making the argument has no real contribution to make, beyond invective. That's probably because I'm a USER, not a contributor. Quite simple. Users that have only invective to contribute aren't helping the community. They make things be unpleasant; which makes some people leave, or otherwise help less. On the other hand, some of the best development partners I've ever had were from the user side of the relationship. Needless to say, invective wasn't a primary contribution; nor were demands that all giving be onesided (me to them). ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD license
Having said this I don't understand how you (or anyone sensible) could support violating licenses. Do you have the habit of breaking laws for the sake of it? Please show me the exact lines in GPL v2 that _clearly_ say linking FTD2xx with OpenOCD is a violation of the license. If one binary version of OpenOCD can work without the library (using the other interfaces) and only enable FTD2XX support when the library is present there is NO issue. FTD2XX is NOT a derived work of OpenOCD so it should NOT be licensed as GPL, end of story! How did Java GPL applications work in the past then (before Java was open source)? It links to DLL's, a VM,... I couldn't make modifications to standard Java classes either. This has nothing to do with breaking the law for the sake of it, this has to do with people having hidden agendas and trying to hide behind the most gray are in software history. Be honest and tell us what this is all about. This is not a theoretic issue I really don't understand how this is not a theoretic issue. Is someone getting sued? If not, it's theoretic. GPL is the license and it states that whatever you link against and distribute should respect GPL freedom Again: show me the line in GPL v2. The whole license doesn't use the word "link" once. Don't even try to send a link to the FAQ, that's ONE interpretation, not legally binding whatsoever. You can do things about this, for instance persuading FTDI to free the FTD2xx driver source and relicense it with GPL Good luck, they don't care. You wouldn't be able to do modifications on the FTD2xx library, so no point for this. You also wouldn't be able to modify it using any of the options in the various threads. If you can live with working around the violation (at least what you interpret as a violation) then why bother? The end result will be the same: People will use OpenOCD and FTD2xx and FTD2xx will NOT be GPL. Why make it more difficult for people to do this? If you (or others) are so interested in a license change, then answer this questions: Personally I'm not asking for a license change. My interpretation of GPL says linking to FTD2xx is not a violation. What I don't understand so far is why it is so important to add an exception to the license instead of: Improving free FTDI library Please do, it'll take a long time as far as I understand the people who could know. Asking FTDI to release and free the FTD2xx library Never gonna happen... Make people interested in running FTD2xx build his own copy/binary of openocd That's actually what I do, I personally don't care about this discussion as worst case I'll build my own version. What does bother me is that other people will have to do the same and might not be able to. Also the risk is real that FTD2xx support will get lost over the years because nobody actively maintains/tests it as it's not an official feature. gr. Ronald Original Message Subject: [Openocd-development] OpenOCD license From: Ral Snchez Siles rsanch...@infoglobal.es To: openocd-development@lists.berlios.de Date: Wed Jun 24 2009 16:55:32 GMT+0200 (Romance Standard Time) Hello: I'll just participate in this horrible flame once. On Wednesday 24 June 2009 14:02:26 Ronald Vanschoren wrote: it sucks to have to be the one to push for license compliance like this Then don't! I'm just a user of OpenOCD so you have all right to ignore what I'm saying as you'll find that I'm less important, but it's about time people here start to realize the real "clients" are users and not developers and users don't give a sh*t about GPL violations. You are not less important, you are just another kind. "Clients" are important as well, just that you (we) don't pay for using the software. Having said this I don't understand how you (or anyone sensible) could support violating licenses. Do you have the habit of breaking laws for the sake of it? Why would anyone want to waste time and effort on fixing this purely theoretic issue? Use the time to implement useful features like SWD or threadsupport instead. You're acting like you have no choice but to point out this issue and write 700 mails about it. You of all people can fix it easily. Give up your copyright or allow relicensing it under anything that is not as gray and debatable as GPL. I don't think enforcing one's rights is loosing time. This is not a theoretic issue. GPL is the license and it states that whatever you link against and distribute should respect GPL freedom, among others, being able to get the source code. You can do things about this, for instance persuading FTDI to free the FTD2xx driver source and relicense it with GPL or any other compatible license for the issue: adm...@ftdichip.com As a sidenote I still don't see the issue. The spirit of GPL is to allow to make modifications to an application that is distributed
Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX
On Wednesday 24 June 2009, Freddie Chopin wrote: See ... how your first no explanation whine was in fact fully addressed at the very beginning of the flamewar you have been feeding. Let's not forget who ignited that whole war. You. Erm, not at all. *YOU* have been the primary flame-thrower. Confrontational, and very unpleasant. My original post on the question (cripes, only ten days ago) was: https://lists.berlios.de/pipermail/openocd-development/2009-June/007971.html I think that if you read that, you will notice nothing at all warlike ... just the simple observation -- which nobody has disproved -- that one distribution scheme violates the current license, so we should probably remove some text that suggests otherwise. Not confrontational. It was *your* contributions to that thread, and later ones, which started a flamefest from a simple doc bugfix. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Can we get back to forward progress?
On Wednesday 24 June 2009, Thomas A. Moulton wrote: ps. let's let the old threads die Good suggestions, all. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Summer coding project proposal
On Wed, 2009-06-24 at 08:34 -0700, Zach Welch wrote: On Wed, 2009-06-24 at 16:00 +0200, Michael Bruck wrote: On Wed, Jun 24, 2009 at 13:29, Zach Welchz...@superlucidity.net wrote: On Wed, 2009-06-24 at 12:23 +0200, Michael Bruck wrote: On Wed, Jun 24, 2009 at 11:42, Zach Welchz...@superlucidity.net wrote: [snip] There is no infringement here, so there is nothing to debate. The issue gets a bit murky when the replacement dll is bundled with OpenOCD, but that is not really necessary, the user can load it from elsewhere. The intention to design this library for the purpose of circumventing the GPL is being documented on this list. Sure, it's murky, but the discussion only helps to build my case to defend against this option. Your premise is wrong. The user is not restricted in what he can do with the software on his PC. This is crystal clear from the license and the FAQ. You can do all sorts of kinky stuff with the software in the sanctity of your hard drive, if you want to flip all bits or increment all jump addresses by 13 or replace a DLL, that is your right under the GPL. First, thank you! Yours has been one of the most pleasurable threads to engage in among these topics, and you have responded exactly as merited. Second, you win! You presented -- clearly -- the reasonable case for why this should be allowed. I sincerely apologize for taking the contrary view on this particular idea; your points above nailed me to the tree! It _is_ okay to produce a libftdi-ftd2xx wrapper package that is ABI compatible with the open source libftdi. Mea culpa. To the community: Just so everyone is absolutely clear: neither my original opinion nor this one have any legal weight regarding compliance. In fact, the FSF may _not_ agree with my interpretation of this very particular situation, though I would love to hear those arguments too. Personally, you have me convinced, so that should be enough for the community to move forward; however, anyone with a serious stake (i.e. commercial vendors) should assume that other copyright holders may later chose to try and cause trouble. My own present willingness to see this as valid should still be insufficient for the legally cautious. Others could come along, obtain their own GPL derived-work copyright claims, and then demand ransom from the community -- because you have allowed yourself to distribute a solution that cannot be defended in absolute terms. Gray areas suck. I would expect any lawyer working in your interests to advise you to avoid them. However, I again think that Michael made this solution black-and-white to me (or white-and-black?), but I hope no one simply takes our words for it. We're not lawyers. Clearly. We would be billing hours, not posting here! There is no defense other than full compliance, which needs to be fully vetted by your own independent legal counsel. Not me. If you want to protect yourself from future threats fully, you should be sure your measures will ensure you never have compliance problems again. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Creative summary of options for OpenOCD distros
OK - be creative. End the flames, throw some ideas. Here goes another summary of REALISTIC and ACCEPTABLE options, if ftd2xx.dll will still be censored in the distributions. 1. Any kind of network protocol that would talk to driver. PRO - Possibilities to use JTAGs over internet to debug remotely, possibility to use closed-source drivers (for me that's a pro [; ) CONS - latency of the medium, need to run another program on one's PC, someone has to create the program and that has to be more complicated than the one from option 2. 2. Modular OpenOCD which would allow binary drivers to be used (just as the drivers are used in Linux kernel) PRO - possibility to use closed-source drivers (same as above), no need for running additional software other than OpenOCD, no speed penalty of the medium CONS - someone would have to create the driver (this would be much easier than in option 1) 3. Creating a libftdi replacement dll that would mimic libftdi API but use ftd2xx.dll (propsed by Magnus Lundin in a separate thread) PRO - probably easiest of solutions, no speed penalty, no need for additional software CONS - user has to KNOW about that to use the replacement, APIs of ftd2xx.dll and libftdi.dll are probably not 100% compatible (?) (the PRO and CONS are not complete of course, just as there maybe more solutions). Personally I think that options 1 and 2 should be introduced anyway, because they are good (especially option 1 is very interesting!). For the short term solution I think option 3 would be quite OK, we can all agree to kill that once a better solutions exist. I'm willing to help with any of those, but - as I'm not a hard-core PC programmer, that help would probably by minor compared to others. Please - don't throw any suggestions like I'll do it for $$$ here. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Summer coding project proposal
Zach Welch z...@superlucidity.net writes: On Wed, 2009-06-24 at 11:18 +0200, Magnus Lundin wrote: Simple project for a CS student. A wrapper with a libftdi interface calling libftd2xx, as a project using a LGPL license So any user can take their binary copy of OpenOCD linked against libftdi and simply replace the libftdi dll file, no need to play with system files or drivers. Is such a library illegal ? Who would have standing to complain ? You are doing it to circumvent the GPL. I think that is illegal. IMO circumvent is indistinguishable from comply with. That is, it is a way of achieving some goals while remaining within the terms of the GPL. You would be contravening this copyright holder's intention, which would make you liable for any possible infringement that I could show. Now it you you who wants to ignore the actual terms of the license, and substitute your own intentions. Furthermore, I think individuals can be held liable for inducing infringement, which is where IANAL becomes useful in some respects. Have you considered a career with the RIAA?... [...] -- John Devereux ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] openocd.texi - fixes from sam3 update
Committed. Thanks! -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Summer coding project proposal
On Wed, 2009-06-24 at 17:53 +0100, John Devereux wrote: Zach Welch z...@superlucidity.net writes: On Wed, 2009-06-24 at 11:18 +0200, Magnus Lundin wrote: Simple project for a CS student. A wrapper with a libftdi interface calling libftd2xx, as a project using a LGPL license So any user can take their binary copy of OpenOCD linked against libftdi and simply replace the libftdi dll file, no need to play with system files or drivers. Is such a library illegal ? Who would have standing to complain ? You are doing it to circumvent the GPL. I think that is illegal. IMO circumvent is indistinguishable from comply with. That is, it is a way of achieving some goals while remaining within the terms of the GPL. You would be contravening this copyright holder's intention, which would make you liable for any possible infringement that I could show. Now it you you who wants to ignore the actual terms of the license, and substitute your own intentions. Furthermore, I think individuals can be held liable for inducing infringement, which is where IANAL becomes useful in some respects. Have you considered a career with the RIAA?... [...] Have you read my further replies to that thread? I recanted. Now... are you trolling, or was that an honest mistake? :) Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] License
On Wed, 2009-06-24 at 14:27 +0200, Laurent Gauch wrote: On Wed, 2009-06-24 at 12:20 +0200, Dominic Rath wrote: / This goes inentionally to you alone, feel free to bring it up on the list if you want... // // You have made me start to wonder if it would be possible to bring some // sort of claim of misrepresentation against the project authors, were // your suggestion to be taken by others. The COPYING file is the standard // way of notifying potential authors of a project's license, so I think // that I would have a good chance of proving that the authors neglected to // inform authors -- whether by intention or accident. // // I suppose that means I have to remove all code you've contributed from // the repository in order to protect myself from what you might or might // not do. I will also have to ask all distributors to remove any version // since january 2009. / Actually, that would no longer be acceptable; you are welcome to fork the code, but I ask that you avoid making such changes. The license is and was GPL, and I am now a copyright holder, maintainer, and active contributor to the project. You would be taking a unilateral action that would not be uniformly supported by the OpenOCD community, whereas I am asserting my individual copyrights. I can do what I have done, but the community should vote to exile my changes. You maybe are holder, maintainer, contributor ... but you are not the CREATOR / AUTHOR ! Are you any of those things, today? Is he contributing, today? Please respect MR. Dominic Rath. He is the CREATOR of OpenOCD 2004 (with 1-2 years or more of intensive coding) I do want to be clear that I do value and respect his contributions and his copyrights, and I welcome both of you to continue contributing to the OpenOCD community in the future. However, neither he nor you have contributed much constructive lately, which means you have effectively abdicated your authority in the community. In an open source community, that authority derives from being a responsible and active contributor. Does this seem reasonable? Tying back into copyright, your authority over the copyrights for your own respective contributions will continue to be respected, in so far as it was expressly written into the repository -- they were released under the GPL without any exceptions. If you or anyone provides sound legal arguments that can refute this claim, I will back off on this assertion. From what I now understand, you had been enjoying dual-licensing by the original author. Unfortunately, that arrangement appears to have ceased to have a legal foundation once the repository accepted contributions from others -- without securing copyright assignments. At that point, any binaries that were produced from those derived works appear to have violated the GPL. This is how it appears to me. As I have been trying to do for others for whom the OpenOCD project provides part of your revenue stream, I encourage you to discuss these matters with your legal counsel. I would be very interested if any responses from these individuals conflict with the assessment that I have been making of the situation; I will be asking the FSF for their opinions on these matters. I was myself a contributor to the project, but before there ais SVN ! Yes, strange for you. But I am a contributor too. I understand that you presently sell dongles and make money from them. Do you plan to contribute directly (with patches) or indirectly (with funding) to help the community solve the current problems? To be clear, you have no obligation to do so, just as we have no obligation to help commercial distributors fix the problems that this licensing SNAFU may have caused. However, I _am_ willing to help those who show an effort to work toward constructive solutions, as I do feel terrible for the angst that this situation has caused the community. I will be sure that we provide a solution for the community, but it may not be good enough for you to use in terms of delivery schedule or performance. What 'project contribution' means for you? - Adding a lot of patches - Donating hardware to end-users - Building binary for easy-of-use - Reading the forum - Writing to the forum - Documenting the project - ... Yup. All those things, and copyright protects all fixed works. All these tasks were needed to bring OpenOCD as it is actually. I have done all of those tasks myself to bring up free software communities. I know it is generally a lot of thankless work, so I do want to generously thank you and all those that helped the community make the project what it is today. Your work has been appreciated. Each project/products needs manager - developer - tester - distributor - end-userS The end-users know what they need. Not always, but the torches and pitchforks helped send a clear message. Saying end-users know what they need [in
Re: [Openocd-development] openocd, ftd2xx
Hello Zach, thank you for this posting. I was just formulating a reply to some of your last emails, but it's probably better if what I had to say remains in the privacy of my harddrive. On Wednesday 24 June 2009 18:30:09 Zach Welch wrote: Hi all, Here is the full list of GPL-compliant solutions for libftd2xx GPL compliance, after further review, consideration, and enumeration: 1) Documentation: build it yourself! 2) Build-Kit: automate the build on users' machines I fear those aren't options for the average Windows user of the OpenOCD. Michael's packages were extremely popular because they were very easy to use. 3) XXX: to be revealed, if legal Is this some particular solution or a placeholder for things we haven't yet thought of? 4) libftdi-ftd2xx: ABI compatible with libftdi, wraps ftd2xx How would ftd2xx be linked here? Via LoadLibrary (dlopen) and friends? I'd volunteer to create such a solution. 5) sockets: separate ftd2xx into their own process space I dislike this idea, and I seem to remember that you disliked it, too, because it opens doors for all kinds of GPL circumventions that we don't want. We may not be able to prevent someone from creating such a solution, but we can deny its upstream inclusion. 6) libusb+libftdi: The Right Thing To Do ;) Is this something that's future proof with Microsoft's signed-drivers-only policy coming up? I have lost track of who is doing what. Please check in here. :) Furthermore, I had originally hoped to make some money by volunteering here, then finding sponsors for further work. I now have serious doubt. I will not take any money for the current compliance effort. Sadly, I no longer think it would be safe to accept any compensation for such work, even if it were going to be offered to me. Sorry. Such could only aid others in baseless accusations of extortive motives being part of my intentions for enforcing the GPL at this juncture. That is simply not true, and I would point out that I did not even raise the original issue. Still, I will fall on my sword to do the right thing. To reiterate, I am now no longer willing to accept offers to do the work that I actually need to survive, to demonstrate that my motives here have no profit in them anymore. All previous offers for me to do paid work are now off the table, until all hostilities from the community have been ameliorated. I hope this action helps resolve some tensions. This is for you to decide. I'd actually appreciate if you were to rethink your position, because a developer whose able to make at least part of his living out of the project is definitely going to provide high qualtiy contributions. Best Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 Windows - summary of options
+++ Freddie Chopin [2009-06-24 16:56 +0200]: David Brownell pisze: Under the GPL. From the very first public release, that has been part of it. You download it, and the GPL is there. That brings along with it certain rules. GPL. GPL. GPL... How about Users, Users, Users? Again - The Most Important Qestion - Is OpenOCD meant for users to use, or just to be 100%-GPL-at-any-cost? The GPL protects _users_ rights (even over developer's rights, if you want to make a distinction) over the long term - that's why it's so popular. You're the ONLY one advocating a we-don't-care-for-X mindset. Damn, I see that the opposite way - 5-10 ppl are 100% GPL (that's where you are) while everyone else is like why create artificial problems?. I am 'just a user' of openOCD (I've contributed a good 6 lines of code/docs so far), and I think the GPL is important too. David Brownell has put the arguments very clearly and correctly (amongst others). So please don't count all users in your camp, and I think you'll find it's a lot more than 5-10. We need to just fix the problem for users (by getting a licence-compatible USB driver for windows people who currently don't have one). Please stop trying to pretend there isn't a problem and be grateful that there has been some laxness in the past - that's a benefit you've had to date. Now it's been noticed (perhaps an understatement!) you and others will find things slightly less convenient for a while, until a proper permanent fix is in place. That will happen a lot quicker if a) this discuession dies down and b) there is some incentive to get it fixed (i.e. using free code is more conventient than using non-free code). Wookey -- Principal hats: iEndian - Balloonboard - Toby Churchill - Emdebian http://wookware.org/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] License
On Wednesday 24 June 2009 19:04:37 Zach Welch wrote: Are you any of those things, today? Is he contributing, today? Please respect MR. Dominic Rath. He is the CREATOR of OpenOCD 2004 (with 1-2 years or more of intensive coding) I do want to be clear that I do value and respect his contributions and his copyrights, and I welcome both of you to continue contributing to the OpenOCD community in the future. However, neither he nor you have contributed much constructive lately, which means you have effectively abdicated your authority in the community. In an open source community, that authority derives from being a responsible and active contributor. Does this seem reasonable? The OpenOCD was and always will be my project. I'm constantly following the list, although I'm not able to read each and every post, especially when the number of messages explodes like it did recently. I'm voicing my concerns when I see changes that interfere with some key design ideas that were part of the original code I released. The last issue was the removal of the asynchronous in handlers, which were then reinstalled in a different way but achieving essentially the same goal which was fine with me. I do think it is important to point out how I wanted some things to be used when this isn't clear from the code. I saw speculations about what I might have intended which is when I first responded to the current issue. Being the one who followed the project from its very beginning I believe I do know some things that others may have missed or never heard about. Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Creative summary of options for OpenOCD distros
Freddie Chopin wrote: 2. Modular OpenOCD which would allow binary drivers to be used (just as the drivers are used in Linux kernel) PRO - possibility to use closed-source drivers (same as above), no need for running additional software other than OpenOCD, no speed penalty of the medium What kind of module interface do you envision that would avoid the problems which we currently have with the FTD2XX library? The drivers would have to run in a separate process space, which means Note: Linux kernel modules need to be GPL, too - the only way to have non-GPL drivers in Linux is to have userspace drivers, which are quite limited in capabilities. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] proposed FASTDATA bulk write optimization for mips_m4k file transfers
Attached is a proposed bulk write optimization for mips_m4k file transfers. The
motivation was to speed-up image loading on the mips_m4k target to reach similar
transfer times as the xscale target.
Files modified:
M2399 src/target/mips32.h
M2399 src/target/mips_ejtag.c
M2399 src/target/mips32_pracc.c
M2399 src/target/mips_ejtag.h
M2399 src/target/mips32_pracc.h
M2399 src/target/mips_m4k.c
Summary:
Bulk transfers are currently done with word accesses using the PrAcc data
register. This optimization uses a working-area, if available, to load a
download routine into ram. The download routine uses EJTAG FASTDATA transfers
to transfer the data. This greatly decreases load times because:
- code fetches are no longer through the PrAcc register, the code is executing
in ram.
- stack is also in the working-area
- Use of only the FASTDATA register minimizes JTAG access.
- the call to jtag_execute_queue() is made only after building the entire
buffer transfer queue.
The idea is taken from the xscale debug_handler loaded into a mini instruction
cache. The mips_m4k does not have a convenient place to load a download routine
like the xscale's mini IC. Instead this patch has been tested with a
working-area in system ram. This requires that the external memory controller be
initialized, most commonly in a board script. The alternative is to lock enough
ways in the instruction cache to make an internal code area. But the system ram
approach is simpler and allows full use of the cache for the program under
debugging.
If a working area is not defined, the code will work as before; bulk writes will
issue a series of word writes that uses the PrAcc data register.
This only affects bulk memory writes; byte, short and word accesses still use
the PrAcc data register.
There is support for FASTDATA bulk reads. However, there is currently no
bulk_read_memory equivalent for bulk_write_memory.
I have probably missed some problems with this approach or it's methods. Still
this code builds and runs and the result is file transfers times decrease
dramatically.
load_image boot-ram.bin 0xa050
mips32_pracc_fastdata_xfer using 0xa0001000 for write handler
253424 byte written at address 0xa050
downloaded 253424 byte in 3.110119s
- David
Index: src/target/mips32.h
===
--- src/target/mips32.h (revision 2399)
+++ src/target/mips32.h (working copy)
@@ -78,6 +78,7 @@
#define MIPS32_OP_ADDI 0x08
#define MIPS32_OP_AND 0x24
#define MIPS32_OP_COP0 0x10
+#define MIPS32_OP_JR 0x08
#define MIPS32_OP_LUI 0x0F
#define MIPS32_OP_LW 0x23
#define MIPS32_OP_LBU 0x24
@@ -104,6 +105,7 @@
#define MIPS32_B(off) MIPS32_BEQ(0, 0, off)
#define MIPS32_BEQ(src,tar,off)MIPS32_I_INST(MIPS32_OP_BEQ,
src, tar, off)
#define MIPS32_BNE(src,tar,off)MIPS32_I_INST(MIPS32_OP_BNE,
src, tar, off)
+#define MIPS32_JR(reg) MIPS32_R_INST(0, reg, 0, 0, 0,
MIPS32_OP_JR)
#define MIPS32_MFC0(gpr, cpr, sel) MIPS32_R_INST(MIPS32_OP_COP0,
MIPS32_COP0_MF, gpr, cpr, 0, sel)
#define MIPS32_MTC0(gpr,cpr, sel) MIPS32_R_INST(MIPS32_OP_COP0,
MIPS32_COP0_MT, gpr, cpr, 0, sel)
#define MIPS32_LBU(reg, off, base) MIPS32_I_INST(MIPS32_OP_LBU, base, reg,
off)
Index: src/target/mips_ejtag.c
===
--- src/target/mips_ejtag.c (revision 2399)
+++ src/target/mips_ejtag.c (working copy)
@@ -4,6 +4,8 @@
* *
* Copyright (C) 2008 by David T.L. Wong *
* *
+ * Copyright (C) 2009 by David N. Claffey dnclaf...@gmail.com *
+ * *
* This program is free software; you can redistribute it and/or modify *
* it under the terms of the GNU General Public License as published by *
* the Free Software Foundation; either version 2 of the License, or *
@@ -146,6 +148,46 @@
return ERROR_OK;
}
+int mips_ejtag_fastdata_scan(mips_ejtag_t *ejtag_info, int write, uint32_t
*data)
+{
+ jtag_tap_t *tap;
+ tap = ejtag_info-tap;
+
+ if (tap==NULL)
+ return ERROR_FAIL;
+
+ scan_field_t fields[2];
+ uint8_t spracc = 0;
+ uint8_t t[4] = { 0,0,0,0 };
+
+ /* fastdata 1-bit register */
+ fields[0].tap = tap;
+ fields[0].num_bits = 1;
+ fields[0].out_value = spracc;
+ fields[0].in_value = NULL;
+
+ /* processor access data register 32 bit */
+ fields[1].tap = tap;
+ fields[1].num_bits = 32;
+ fields[1].out_value = t;
+
+ if (write)
+ {
+ fields[1].in_value = NULL;
+
Re: [Openocd-development] proposed FASTDATA bulk write optimization for mips_m4k file transfers
I'm itching to apply any patches on MIPS4K, but I can't really dive into MIPS support and provide useful feedback Part of my job description in OpenOCD is to be a recruiter and we're desperately short on active MIPS target experts. So if anyone out there have opinions about MIPS target code, you've been warned that I'll give this a cursory look and then commit it if I hear nothing in a day or two. -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd, ftd2xx
On Wed, 2009-06-24 at 19:20 +0200, Dominic wrote: Hello Zach, thank you for this posting. I was just formulating a reply to some of your last emails, but it's probably better if what I had to say remains in the privacy of my harddrive. Since you have said that, I am intensely curious. Too many of mine die a similar death, and it could be something to share a laugh over... in a year or two. ;) On Wednesday 24 June 2009 18:30:09 Zach Welch wrote: Hi all, Here is the full list of GPL-compliant solutions for libftd2xx GPL compliance, after further review, consideration, and enumeration: 1) Documentation: build it yourself! 2) Build-Kit: automate the build on users' machines I fear those aren't options for the average Windows user of the OpenOCD. Michael's packages were extremely popular because they were very easy to use. I am not convinced; I really feel that a build-kit is doable. I feel confident, but it is by far not an realistic case for any serious deployments. The downloads would be unreasonably large... and all that wasted CPU time. And this, coming from a Gentoo user. ;) 3) XXX: to be revealed, if legal Is this some particular solution or a placeholder for things we haven't yet thought of? Very specific. I just thought of it as a result of these threads, but I do not want to get the community's hopes up in the event that it turns out to be false hope. However, I will warn that it is build-kit related and remains difficult to scale reasonably well; again, far from ideal. 4) libftdi-ftd2xx: ABI compatible with libftdi, wraps ftd2xx How would ftd2xx be linked here? Via LoadLibrary (dlopen) and friends? I'd volunteer to create such a solution. We build and distribute: OpenOCD - libftdi Users would download and install libftdi-ftd2xx *instead* of libftdi. Since they have the same ABI, the application cannot tell the difference between the open and closed versions. OpenOCD binaries cannot legally be distributed with the wrapper, only with the the normal libftdi. They should behave the same in all outward function ways; there cannot be any conditional code in OpenOCD to enable the wrapper library. I think that will work. I am not _entirely_ sure, but others can ACK. 5) sockets: separate ftd2xx into their own process space I dislike this idea, and I seem to remember that you disliked it, too, because it opens doors for all kinds of GPL circumventions that we don't want. We may not be able to prevent someone from creating such a solution, but we can deny its upstream inclusion. The genie is out of the bottle. We can create a GPL implementation, and force the proprietary versions to re-implement the driver-side handling themselves. It would be nicer to the FTD2XX folk if we licensed the driver-side bits under LGPL... but it appears that neither of us want to be nice on this matter. Hurray! We're on the same team. :) Go team! 6) libusb+libftdi: The Right Thing To Do ;) Is this something that's future proof with Microsoft's signed-drivers-only policy coming up? We can raise money to pay for the signing costs; presumably, they don't need to be signed during development testing. Personally, I think the broader community will end up footing these bills; however, these factors need to be considered by the community in complete detail once the technical details are worked out. After hearing all of the reports induced by the licensing threads, I am afraid that we may have a bit of work to do before we need to worry about signed drivers, sadly; however, I cannot judge the actual status -- our Windows developers need to do that. I asked Michael Fischer in a private e-mail to send me a patch for the TODO list to include all of the things we need to finish this support, but others on the list may have been more appropriate to ask. :) [snip] To reiterate, I am now no longer willing to accept offers to do the work that I actually need to survive, to demonstrate that my motives here have no profit in them anymore. All previous offers for me to do paid work are now off the table, until all hostilities from the community have been ameliorated. I hope this action helps resolve some tensions. This is for you to decide. I'd actually appreciate if you were to rethink your position, because a developer whose able to make at least part of his living out of the project is definitely going to provide high qualtiy contributions. I appreciate you allowing me to do so. I will post another message to restate my position in a way that should both better clarify my original intent but still allow me to survive. And it will take things to a whole... other level ;) :) Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd, ftd2xx
snip Here is the full list of GPL-compliant solutions for libftd2xx GPL compliance, after further review, consideration, and enumeration: 1) Documentation: build it yourself! 2) Build-Kit: automate the build on users' machines 3) XXX: to be revealed, if legal 4) libftdi-ftd2xx: ABI compatible with libftdi, wraps ftd2xx 5) sockets: separate ftd2xx into their own process space 6) libusb+libftdi: The Right Thing To Do ;) snip Just a thought on option 2 - the build kit. This would be a large download, and quite a lot of work for someone to put together. If the GPL violation happens in distributing code that is linked to FTD2XX, could the build kit have pre-compiled objects for openocd - that are then linked on the users machine. The pre-compiled objects, as distributed, would not be linked to FTD2XX. This would reduce the complexitiy of the build kit down to a much simpler 'link-kit'. It's function would be no different to the build kit. I haven't looked into it but maybe this could be as simple as a few object files, LD and a few MingW libraries along with a batch file. BR, Ian. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd, ftd2xx
On Wed, 2009-06-24 at 20:14 +0100, Ian Guffick wrote: snip Here is the full list of GPL-compliant solutions for libftd2xx GPL compliance, after further review, consideration, and enumeration: 1) Documentation: build it yourself! 2) Build-Kit: automate the build on users' machines 3) XXX: to be revealed, if legal 4) libftdi-ftd2xx: ABI compatible with libftdi, wraps ftd2xx 5) sockets: separate ftd2xx into their own process space 6) libusb+libftdi: The Right Thing To Do ;) snip Just a thought on option 2 - the build kit. This would be a large download, and quite a lot of work for someone to put together. If the GPL violation happens in distributing code that is linked to FTD2XX, could the build kit have pre-compiled objects for openocd - that are then linked on the users machine. The pre-compiled objects, as distributed, would not be linked to FTD2XX. This would reduce the complexitiy of the build kit down to a much simpler 'link-kit'. It's function would be no different to the build kit. I haven't looked into it but maybe this could be as simple as a few object files, LD and a few MingW libraries along with a batch file. I think it will take a little bit more effort than this (some autotools magic to ensure users can build different configurations), but this is a great idea for reducing the download sizes. In many ways, it sounds a bit like using ccache; once the cache is populated, you only ever link. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd, ftd2xx
On Wed, 2009-06-24 at 11:26 -0700, Zach Welch wrote: We can raise money to pay for the signing costs; presumably, they don't need to be signed during development testing. My IT guys said that in Vista unsigned drivers can be loaded if you enable a boot time option and it only lasts for that boot. Ok for development, ng for users. The signing problem is only Vista right? I have an unsigned driver we use with one of our products that just gives the warning message... hit continue and all is fine tom ___ 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] Creative summary of options for OpenOCD distros
Note: Linux kernel modules need to be GPL, too - the only way to have non-GPL drivers in Linux is to have userspace drivers, which are quite limited in capabilities. This is not correct. GPL v2 talks about derived work. It's well accepted (by Linus himself and most of the community except the holier then pope people) that binary kernel modules (so not releasing source code) is acceptable IF the original driver was NOT written for Linux. If it is merely ported to Linux, only the portation layer has to be released. I think the NVIDIA drivers are an example. I know a company who uses such binary drivers and was in contact with FSF who approved the approach. To stay on topic, following this (FSF approved) interpretation of GPL v2, FTD2XX is NOT a derived work of OpenOCD so it should not be released under GPL. gr. Ronald ___ 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
Interesting that you should bring up eCos. Look at what happened there. *LOTS* of closed source packages to eCos exists I'd hate to have closed source targets + interface drivers in OpenOCD and if you use the eCos license you'll get that for sure. I know there are hardware vendors who's aching for it. Look at the www.vinchip.com guys. Where is the OpenOCD source code that they wrote? You'd have to be careful as the devil to make a license allow FTDI non-GPL compliant code for the purposes of USB while not mentioning FTDI specifially and avoiding targets + interface closed source. Another stated policy of OpenOCD is that all hardware vendors are equal. So neither FTDI, nor USB could be mentioned in such an exception. It's a million times easier to just fix this technically than to try to solve this with licensing. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] License
On Wednesday 24 June 2009, Dominic wrote: Being the one who followed the project from its very beginning I believe I do know some things that others may have missed or never heard about. So maybe you can answer this ... What does the arp_ prefix in various commands represent? Address Resolution Protocol was my first reaction ... but that doesn't seem relevant to JTAG. ;) (yep, a non-license question!) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] proposed FASTDATA bulk write optimizationfor mips_m4k file transfers
I'm itching to apply any patches on MIPS4K, but I can't really dive into MIPS support and provide useful feedback Part of my job description in OpenOCD is to be a recruiter and we're desperately short on active MIPS target experts. If the PIC32 catches on you should see more MIPS experts. offtopic anti-PIC rant deleted So if anyone out there have opinions about MIPS target code, you've been warned that I'll give this a cursory look and then commit it if I hear nothing in a day or two. I could give the patches a spin on the MIPS platform I'm working with. I just don't know whether 'my' target has the FASTDATA register. I think I could give it a try for programming external flash first thing in the morning. I can't really promise anything though. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Question about the driver install structure for libftdi
Hello List, from Freddie I know that a mix mode installer is working. Here libftdi is used for the JTAG part of the FT2232 chip, and the FTD2XX driver is used for the COM port of the chip. Now I can confirm that the COM port of the Turtelizer is working. The installation is a little strange, because the user must point to two different folders. -driver |-ftdilib |-non-gpl |-turtelizer For the JTAG port to ftdilib and for the COM port to turtelizer under non-gpl. In the moment I do not know if this is intuitive. Here we can use one ftdilib file for all of the devices, but I want to prefer the following structure: -driver |-turtelizer |-jtag |-com |-jtagkey |-jtag and so on. This should be more intuitive for the user. The disadvantage is that we need for each libftdi device his own libftdi inf file. But this is easier for the user, and the user should be the priority. @Zach, this is one point for the TODO list. Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] License
Dominic, Since this followed your very constructive and friendly reply to my summary of the options and willingness to swear off profits, I have tried to interpret your response herein in the best possible light. Likewise, I hope you will grant me the same consideration, just in case it is needed. ;) On Wed, 2009-06-24 at 19:35 +0200, Dominic wrote: On Wednesday 24 June 2009 19:04:37 Zach Welch wrote: Are you any of those things, today? Is he contributing, today? Please respect MR. Dominic Rath. He is the CREATOR of OpenOCD 2004 (with 1-2 years or more of intensive coding) I do want to be clear that I do value and respect his contributions and his copyrights, and I welcome both of you to continue contributing to the OpenOCD community in the future. However, neither he nor you have contributed much constructive lately, which means you have effectively abdicated your authority in the community. In an open source community, that authority derives from being a responsible and active contributor. Does this seem reasonable? The OpenOCD was and always will be my project. I'm constantly following the list, although I'm not able to read each and every post, especially when the number of messages explodes like it did recently. If you mean it will always be yours in spirit, yes it will. You will always be the spiritual leader of the project. Your willingness to create this project and release it under the GPL has been appreciated by countless developers, and I never want to steal that thunder from you. You deserve to be enshrined in the OpenOCD community forever. However, you can simultaneously acknowledge that you have not been active on this list, so the authority that I spoke of your abdicating is of command authority. The authority to lead the project to where the community needs to go, to manage the infrastructure, and to make executive decisions. Clearly, that last item needs to be clarified between the two of us directly. You are aware that I have been acting as a pro forma leader here, and these recent events saw me moving to take executive actions that I have experience to know were necessary and sufficient to protect the integrity of the OpenOCD IP for all of its contributors. [[When it comes to protecting copyrights, they matter more than users, because the contributors own their the rights to the code.]] Unfortunately, this process was complicated when you entered the debate on the side of an exception. You are still given tacit command authority, with the result being that you nearly led the road down an indefensible legal path. Your off-list threat to remove all of my changes from the repository further demonstrated that you still believe that you can wield absolute power without suffering any consequences. As I have said before now, that is no longer the case. When you use your authority, you effectively override other contributors and maintainers that have been working hard on the project. The rest of us must try to earn (or demand) respect from the community on a periodic basis. That is not a pure meritocracy; this status quo needs to change, with you accepting the same means of attaining privilege: by working on the trunk (or current release branches) and with the user community. Between multiple copyright holders and the GPL, the _only_ fair way to describe OpenOCD would be to say that it is *our* project, with the most active contributors leading the way in authority and responsibilities. In the face of abdication of command authority, the community should hold the project leaders accountable -- or replace them with new active contributors with equivalent authority. That should hold true for you, me, or anyone. Your opinions should always matter and be considered, but you are not as close to the code today as you once were. Authority needs to be in the hands of those who are actively working to improve and maintain the code for the community. If you are not reading every message, then I think those who do should have more authority than you. Does this sound fair? I'm voicing my concerns when I see changes that interfere with some key design ideas that were part of the original code I released. The last issue was the removal of the asynchronous in handlers, which were then reinstalled in a different way but achieving essentially the same goal which was fine with me. I do think it is important to point out how I wanted some things to be used when this isn't clear from the code. I saw speculations about what I might have intended which is when I first responded to the current issue. Being the one who followed the project from its very beginning I believe I do know some things that others may have missed or never heard about. I positively did _not_ mean that you have abdicated your architectural authority or knowledge of the system based on your unique experience. That would have been very big insult, but I fear that may
[Openocd-development] The OpenOCD Foundation
On Wed, 2009-06-24 at 09:30 -0700, Zach Welch wrote: [snip] To reiterate, I am now no longer willing to accept offers to do the work that I actually need to survive, to demonstrate that my motives here have no profit in them anymore. All previous offers for me to do paid work are now off the table, until all hostilities from the community have been ameliorated. I hope this action helps resolve some tensions. Okay, with Dominic's encouragement, let me strike the above and replace it with something of much clearer intent -- and beneficial to the entire OpenOCD and free software communities. Happily, this also saves me from shooting my career in the foot. I hereby commit myself to donating all profits recovered in the pursuit of OpenOCD GPL violations on my behalf to a non-profit. I would prefer that the community create The OpenOCD Foundation to receive such funds and manage them along with the copyrights and trademarks on behalf the open source and free software communities. Should forming this type of organization haven proven intractable, I want any recovered monies to fund the Free Software Foundation instead. I have prepared a proposal to create The OpenOCD Foundation, which I can post in a new thread. It has been sitting in my Drafts box for weeks, prepared to be pitched to the community if the need arose. I would like to introduce it fully in the next day or two, after adjusting it to account for recent events, discussions, and pending community feedback. The arguments for such formal organization are indicated above: violation money comes from copyright violations, which can only be enforced by copyright holders. We have now seen this can turn into a real nightmare when it comes to taking action, simply by discussing a possible exception to the license. Can you imagine what would happen if anyone of us tried to sue each others customers for violations; even if those suits turned out to be frivolous, it would be a PITA to sort out for the community. Traumatic would not even begin to describe it. Without such a formal organization, I fear that too many stakeholders will be involved for the community to take decisive actions when they are required to defend the project's IP. From what I understand, a lack of rights-holder unity may hinder or derail some types of enforcement efforts in the future. Collective IP is an area where things become less clear to me. I know how to exercise my own rights as an individual far better than those of a project as a whole. Anyone else have insight? In any event, a foundation _is_ an individual, legally speaking, which is why the _legal_ issues are so much easier. Decisions... well, those will still be hard and should be community driven. With a non-profit means of contributing support (i.e. tax-deductable), the community could use money to buy new targets for developers -- and much more. I have laid out the benefits in fairly comprehensive vision based on my past experience in the area of non-profit entities, but my ideas need the community's input and support to succeed. Without biasing the community further than this, what would you expect from such an entity? As a user? Developer? Contributor? Vendor? Founder? Please provide feedback to this thread. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] first ftd2xx fix: documentation!
Hello, It remains somewhat unclear to me exactly how badly distributors need to see a solution today, when users (who are all developers, right?) should be able to compile the code themselves and use the FTD2XX driver. If Windows is the blocker, the first question that should be answered is: how do we build OpenOCD on Windows? Everything else goes from that. Thus, can someone explain why this cannot be solved by good build process documentation? No code, other than some command line examples. Just a good old fashioned HOWTO for building the MinGW32 distribution from scratch. Do we have these today in the tree? I cannot trivially locate them Why not? Same for CygWin, and I apologize if I missed either of these in-tree. If someone were to provide instructions for the setup steps (in-tree), someone can probably turn that into a build-kit script (in-tree). And someone else might be able to integrate that with the Qt helper already under development (which will be in-tree). Hurrah! Clarifying this somewhat, the required build process seems to be: 1) download(/compile)/install a MinGW32 toolchain 2) compile/install OpenOCD dependencies in temporary dir 3) this step intentionally left empty, because... I believe the last step (compile/install OpenOCD) will already be handled by the Qt wrapper, but I hope interested developers will work on the list to clarify these details. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd, ftd2xx
Zach Welch wrote: On Wed, 2009-06-24 at 20:14 +0100, Ian Guffick wrote: snip Here is the full list of GPL-compliant solutions for libftd2xx GPL compliance, after further review, consideration, and enumeration: 1) Documentation: build it yourself! 2) Build-Kit: automate the build on users' machines 3) XXX: to be revealed, if legal 4) libftdi-ftd2xx: ABI compatible with libftdi, wraps ftd2xx 5) sockets: separate ftd2xx into their own process space 6) libusb+libftdi: The Right Thing To Do ;) snip Just a thought on option 2 - the build kit. This would be a large download, and quite a lot of work for someone to put together. If the GPL violation happens in distributing code that is linked to FTD2XX, could the build kit have pre-compiled objects for openocd - that are then linked on the users machine. The pre-compiled objects, as distributed, would not be linked to FTD2XX. This would reduce the complexitiy of the build kit down to a much simpler 'link-kit'. It's function would be no different to the build kit. I haven't looked into it but maybe this could be as simple as a few object files, LD and a few MingW libraries along with a batch file. I think it will take a little bit more effort than this (some autotools magic to ensure users can build different configurations), but this is a great idea for reducing the download sizes. In many ways, it sounds a bit like using ccache; once the cache is populated, you only ever link. Cheers, Zach Actually this is a very nice approach. Making only linking process on the user side helps a lot in this case. I suspect this may be easier than we think. This can be even handled in installer scripts like nsis. On the other hand, I have a working build tool at hand, it currently: + Downloads FTD2XX libraries, + Fetches OpenOCD using SVN, + Configures, builds and installs openocd all with a simple wizard so no user interaction is mandatory. However, putting cygwin and gcc into kit makes it very huge in size. It is also possible to download cygwin components without user interaction(cygwin has an installer) however I couldn't manage it to work. I guess, in the end all will be needed on user side is some time and bandwidth. Thanks, Caglar P.S. Current SVN HEAD is not building on Windows, at least I cannot succeed. Configure is unable to test ftd2xx libraries but it is building if I disable checks. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Creative summary of options for OpenOCD distros
Ronald Vanschoren wrote: Note: Linux kernel modules need to be GPL, too - the only way to have non-GPL drivers in Linux is to have userspace drivers, which are quite limited in capabilities. This is not correct. GPL v2 talks about derived work. It's well accepted (by Linus himself and most of the community except the holier then pope people) that binary kernel modules (so not releasing source code) is acceptable IF the original driver was NOT written for Linux. If it is merely ported to Linux, only the portation layer has to be released. I think the NVIDIA drivers are an example. I know a company who uses such binary drivers and was in contact with FSF who approved the approach. It seems you are right, and I remembered (partially) wrong - this sums it up nice: http://lkml.indiana.edu/hypermail/linux/kernel/0312.0/0670.html However, this still means that if we implement a JTAG-cable module API, and you implement a JTAG cable driver that then calls FTD2XX, that module is probably still a derived work - you can't claim that such a module existed outside OpenOCD before and was just ported to OpenOCD. To stay on topic, following this (FSF approved) interpretation of GPL v2, FTD2XX is NOT a derived work of OpenOCD so it should not be released under GPL. Right. However, that is not the original problem that started the thread - the problem is that by linking OpenOCD with FTD2XX, you create a derived work which can not be distributed under GPL because the library is not GPL. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Openocd-svn] r2381 - trunk/src/helper
Spencer Oliver wrote: strok_r is not available on win32 - strok is said to be reentrant on win32. Not near a dev pc at the moment so i thought i would point it out - i can make the change later if you do not have time. Hmm... Perhaps we should add strtok_r() to the replacments.c file. We could take an instance from Newlib - it has a BSD licensed implimentation. What do you think? i think just using the win32 strtok will be fine - msdn state it as being thread safe. the other msdn choice is to use strtok_s, but that seesm to also be missing from mingw. http://social.msdn.microsoft.com/forums/en-US/vcgeneral/thread/963aac07-da1a -4612-be4a-faac3f1d65ca Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] proposed FASTDATA bulk write optimizationfor mips_m4k file transfers
I'm itching to apply any patches on MIPS4K, but I can't really dive into MIPS support and provide useful feedback Part of my job description in OpenOCD is to be a recruiter and we're desperately short on active MIPS target experts. So if anyone out there have opinions about MIPS target code, you've been warned that I'll give this a cursory look and then commit it if I hear nothing in a day or two. I will have a look over the next couple of days - using a pic32 target. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] proposed FASTDATA bulk write optimizationfor mips_m4k file transfers
The FASTDATA register is part of the EJTAG specification at least back to 3.10 (search for MD00047-2B-EJTAG-SPC-03.10.pdf to see the FASTDATA register). This patch optimizes any calls to target-type-bulk_write_memory() and I have only found the call in target.c. I don't know if flash programming will touch this code. - David Nico Coesel wrote: I'm itching to apply any patches on MIPS4K, but I can't really dive into MIPS support and provide useful feedback Part of my job description in OpenOCD is to be a recruiter and we're desperately short on active MIPS target experts. If the PIC32 catches on you should see more MIPS experts. offtopic anti-PIC rant deleted So if anyone out there have opinions about MIPS target code, you've been warned that I'll give this a cursory look and then commit it if I hear nothing in a day or two. I could give the patches a spin on the MIPS platform I'm working with. I just don't know whether 'my' target has the FASTDATA register. I think I could give it a try for programming external flash first thing in the morning. I can't really promise anything though. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Creative summary of options for OpenOCD distros
Michael Schwingen pisze: by linking OpenOCD with FTD2XX, you create a derived work which can not be distributed under GPL because the library is not GPL. You wouldn't link OpenOCD to anything at all. User would decide what file he/she would like to use, and that file has to provide full ABI that is required for JTAG operations. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] License
David Brownell wrote: On Wednesday 24 June 2009, Dominic wrote: Being the one who followed the project from its very beginning I believe I do know some things that others may have missed or never heard about. So maybe you can answer this ... What does the arp_ prefix in various commands represent? Address Resolution Protocol was my first reaction ... but that doesn't seem relevant to JTAG. ;) That name arp_ was coined by my self an Oyvind last year when we where trying to introduce Reset events and all the other Jim type events. The ARP - stood for: Advanced Reset Process - -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Creative summary of options for OpenOCD distros
Freddie Chopin wrote: Michael Schwingen pisze: by linking OpenOCD with FTD2XX, you create a derived work which can not be distributed under GPL because the library is not GPL. You wouldn't link OpenOCD to anything at all. User would decide what file he/she would like to use, and that file has to provide full ABI that is required for JTAG operations. I think we were talking about different things - that paragraph was meant as a clarification of the current situation. When talking about plugins/modules: Agreed, that works - *but* only if the file is *not* GPL, and that means you have to write it from scratch without taking the existing parts of the FTD2232 JTAG driver from OpenOCD. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd, ftd2xx
Zach Welch wrote: Hi all, Here is the full list of GPL-compliant solutions for libftd2xx GPL compliance, after further review, consideration, and enumeration: 1) Documentation: build it yourself! 2) Build-Kit: automate the build on users' machines 3) XXX: to be revealed, if legal 4) libftdi-ftd2xx: ABI compatible with libftdi, wraps ftd2xx 5) sockets: separate ftd2xx into their own process space 6) libusb+libftdi: The Right Thing To Do ;) You are missing (7) - WinUSB - the windows platform type solution that is simular to libusb. Sadly, it does not go back to Win2K - but - most (popular) others are solved. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Creative summary of options for OpenOCD distros
Freddie Chopin wrote: I'm not the first one to suggest such idea (modularity, drivers, ...) on this list. Right. And modules in the same address space are tricky license-wise. The drivers would have to run in a separate process space, which means You are going to check the process spaces on every single PC that is on this planet? Can we please stop this extremism? I won't check (I compile my own binaries on Linux), and I don't really care what users do - they may well link OpenOCD to the FTD2XX library and run that binary on their machine. However, as soon as a combination of OpenOCD + non-GPL plugin module is distributed as a single package/installer, you might again be in trouble with the GPL. IANAL, but anyone willing to distribute an installer package *should* be sure, and that means a proposed solution should be on the safe side. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Creative summary of options for OpenOCD distros
Michael Schwingen pisze: Freddie Chopin wrote: 2. Modular OpenOCD which would allow binary drivers to be used (just as the drivers are used in Linux kernel) What kind of module interface do you envision that would avoid the problems which we currently have with the FTD2XX library? This idea is identical to the tcp/ip idea, just without that [; There would be a Generic JTAG ABI defined, with some functions like reset(), write(), read(), identify(), do_sth() etc. The user would provide the library (.dll on windows) and run OpenOCD with parameters to use that file. Or OpenOCD may scan for files. Or whatever. The library handles the interface between JTAG and OpenOCD. Actually with clever implementation such a library could be used with tcp/ip idea - the library would not be loaded by OpenOCD but by some sotware that would work as a tcp/ip - library bridge. I'm not the first one to suggest such idea (modularity, drivers, ...) on this list. The drivers would have to run in a separate process space, which means You are going to check the process spaces on every single PC that is on this planet? Can we please stop this extremism? Note: Linux kernel modules need to be GPL, too - the only way to have non-GPL drivers in Linux is to have userspace drivers, which are quite limited in capabilities. Tell that to NVIDIA then [; Anyway - the tcp/ip idea is maily the same - the only problem is that user has to have another program which has to be running, with more configuration options and more potential problems for end-user. The driver idea just skips the network part. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Creative summary of options for OpenOCD distros
On Wed, 2009-06-24 at 21:36 +0200, Ronald Vanschoren wrote: Note: Linux kernel modules need to be GPL, too - the only way to have non-GPL drivers in Linux is to have userspace drivers, which are quite limited in capabilities. This is not correct. GPL v2 talks about derived work. It's well accepted (by Linus himself and most of the community except the holier then pope people) that binary kernel modules (so not releasing source code) is acceptable IF the original driver was NOT written for Linux. If it is merely ported to Linux, only the portation layer has to be released. I think the NVIDIA drivers are an example. I know a company who uses such binary drivers and was in contact with FSF who approved the approach. This is _very_ apt observation, and one I almost forgot myself. To stay on topic, following this (FSF approved) interpretation of GPL v2, FTD2XX is NOT a derived work of OpenOCD so it should not be released under GPL. As (I think) you say here, the Linux kernel module scenario does not affect the legality of a loadable module in the same user-space process as OpenOCD. The module still violates the GPL when distributed, since it would be derived in part from the type and API definitions provided by the driver interface header files. Thus, binaries of the driver module could not be distributed. However, I have mentioned that modular drivers could allow a build-kit to only produce that single driver from source, though the build requirements still get out of control. The latest link-kit idea would be perfect for this though! Modular drivers are still a Good Thing. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Creative summary of options for OpenOCD distros
Michael Schwingen pisze: However, as soon as a combination of OpenOCD + non-GPL plugin module is distributed as a single package/installer, you might again be in trouble with the GPL. IANAL, but anyone willing to distribute an installer package *should* be sure, and that means a proposed solution should be on the safe side. What would be the purpose of distributing every possible driver/module with OpenOCD installer? There would be a separate project/website/whatever that would have the drivers/modules ready for download Actually I think that OpenOCD should switch to dynamic library loading, because the need to have all possible usb libraries when you use Wiggler and OpenOCD version compiles with support for all possible dongles is not very convenient. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Creative summary of options for OpenOCD distros
Freddie Chopin pisze: Actually I think that OpenOCD should switch to dynamic library loading, because the need to have all possible usb libraries when you use Wiggler and OpenOCD version compiles with support for all possible dongles is not very convenient. ... OpenOCD version compile_D with ... S is really close to D, and it's late [; 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Creative summary of options for OpenOCD distros
Thanks for pointing out the system32 thing. I forgot about that. I'm an embedded developer, I don't do things like DLL's ;-) Bit confused here, what do you mean with "BOTH libraries" Original Message Subject: [Openocd-development] Creative summary of options for OpenOCD distros From: Freddie Chopin freddie_cho...@op.pl To: openocd-development openocd-development@lists.berlios.de Date: Thu Jun 25 2009 00:20:53 GMT+0200 (Romance Standard Time) Ronald Vanschoren pisze: Link-kit is definitely better then build-kit, but what are we doing here? Dynamic linking is also a "link-kit". In my interpretation of GPL, there is nothing illegal to distributing an OpenOCD binary that _CAN_ link to FTD2XX but doesn't require it. We (OpenOCD community) would not distribute FTD2XX ourselves, but point users to the FTDI download page and say "if you download the DLL and put it in the OpenOCD directory, something magic could happen". I'm assuming here it's not legal to distribute FTD2xx, I don't know about that as I don't know what license it's available under. This is not required, because when one installs the drivers for FTDI based device, the ftd2xx.dll is automatically copied from the "driver package" to windows/system32 folder. The library (dll) just has to be "somewhere" where it can be reached via PATH variable. So if one has FT2232 based dongle, one has the library somewhere on the system - no additional downloading and copying that anywhere is required. BTW in such scenario it would be best to modify the code so that it could use BOTH libraries, selectable somehow during runtime (automatically or manually). 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] The OpenOCD Foundation
+++ Zach Welch [2009-06-24 14:00 -0700]: On Wed, 2009-06-24 at 09:30 -0700, Zach Welch wrote: I hereby commit myself to donating all profits recovered in the pursuit of OpenOCD GPL violations on my behalf to a non-profit. I would prefer that the community create The OpenOCD Foundation to receive such funds and manage them along with the copyrights and trademarks on behalf the open source and free software communities. Should forming this type of organization haven proven intractable, I want any recovered monies to fund the Free Software Foundation instead. I have prepared a proposal to create The OpenOCD Foundation, which I can post in a new thread. I'm not sure a project of this size needs a whole foundation of its own. It might make more sense to look at using an institution like SPI which provides services like keeping money in pools for projects and legal advice, to Free Software projects. This requires little more than asking them to accept OpenOCD and set up a pool for project monies. Having a copyright assignment body might be useful. Wookey -- Principal hats: iEndian - Balloonboard - Toby Churchill - Emdebian http://wookware.org/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Creative summary of options for OpenOCD distros
On Thu, 2009-06-25 at 00:12 +0200, Ronald Vanschoren wrote: This is _very_ apt observation, and one I almost forgot myself. Thanks ;-) As (I think) you say here, the Linux kernel module scenario does not affect the legality of a loadable module in the same user-space process as OpenOCD. The module still violates the GPL when distributed, since it would be derived in part from the type and API definitions provided by the driver interface header files. Thus, binaries of the driver module could not be distributed. The situation with Linux is a little more gray and I was kinda hoping nobody would notice. Some API from Linux is outside GPL (like systemcalls and some other). This is probably how NVIDIA makes a full closed source kernel module. But even if it wasn't so, only the translation layer between Linux API and closed source library has to be released. The translation layer is obviously derived work, but anything past that obviously is not. This is basically the same OpenOCD would do: release everything up to FTD2XX API. However, I have mentioned that modular drivers could allow a build-kit to only produce that single driver from source, though the build requirements still get out of control. The latest link-kit idea would be perfect for this though! Modular drivers are still a Good Thing. Link-kit is definitely better then build-kit, but what are we doing here? Dynamic linking is also a link-kit. In my interpretation of GPL, there is nothing illegal to distributing an OpenOCD binary that _CAN_ link to FTD2XX but doesn't require it. We (OpenOCD community) would not distribute FTD2XX ourselves, but point users to the FTDI download page and say if you download the DLL and put it in the OpenOCD directory, something magic could happen. I'm assuming here it's not legal to distribute FTD2xx, I don't know about that as I don't know what license it's available under. It's all gray here, but won't somebody please think of the chil^H^H^H^H users. We must assume they are not very much into building/linking. Arg. The link kit suffers from the same deficiencies: what are distributed inside the ccache? The _binary_ object files. Mega-Duh. In hindsight, this particular solution is just unlinked binary distribution; it should be considered DOA. I probably missed that because I'm going on 26+ hours since sleeping. Sorry. As you might have noticed I'm one of the loose people regarding this GPL thing, but on the other hand I'm not too keen on binary modular drivers. At least the translation layer should be GPL'd and the binary part should be publicly available. This opens a lot of doors, but maybe some we don't want to open... Someone should present a complete design document. ;) Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] License
Zach Welch a écrit : Personally, I want to be done with talking about these matters and start to move on to fix the problems for the community. Sound good? Cheers, Zach Agreed! -- Tired of Microsoft's rebootive multitasking? then it's time to upgrade to Linux. http://home.comcast.net/~mcatudal ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] MIPS/EJTAG watchpoints support
Attached patch adds simple watchpoint support
for MIPS32/EJTAG (no value comparation yet).
--
gonzo
Index: src/target/mips_ejtag.h
===
--- src/target/mips_ejtag.h (revision 2400)
+++ src/target/mips_ejtag.h (working copy)
@@ -96,6 +96,11 @@
#define EJTAG_IBA10xFF301100
#define EJTAG_DBS0xFF302000
#define EJTAG_DBA10xFF302100
+#define EJTAG_DBCn_NOSB(1 13)
+#define EJTAG_DBCn_NOLB(1 12)
+#define EJTAG_DBCn_BLM_MASK 0xff
+#define EJTAG_DBCn_BLM_SHIFT 4
+#define EJTAG_DBCn_BE(1 0)
typedef struct mips_ejtag_s
{
Index: src/target/mips_m4k.c
===
--- src/target/mips_m4k.c (revision 2400)
+++ src/target/mips_m4k.c (working copy)
@@ -693,25 +693,132 @@
int mips_m4k_set_watchpoint(struct target_s *target, watchpoint_t *watchpoint)
{
- /* TODO */
+ mips32_common_t *mips32 = target-arch_info;
+ mips32_comparator_t * comparator_list = mips32-data_break_list;
+ int wp_num = 0;
+ /*
+ * watchpoint enabled, ignore all byte lanes in value register
+ * and exclude both load and store accesses from watchpoint
+ * condition evaluation
+ */
+ int enable = EJTAG_DBCn_NOSB | EJTAG_DBCn_NOLB | EJTAG_DBCn_BE |
+(0xff EJTAG_DBCn_BLM_SHIFT);
+
+ if (watchpoint-set)
+ {
+ LOG_WARNING(watchpoint already set);
+ return ERROR_OK;
+ }
+
+ while(comparator_list[wp_num].used (wp_num mips32-num_data_bpoints))
+ wp_num++;
+ if (wp_num = mips32-num_data_bpoints)
+ {
+ LOG_DEBUG(ERROR Can not find free FP Comparator);
+ LOG_WARNING(ERROR Can not find free FP Comparator);
+ exit(-1);
+ }
+
+ if (watchpoint-length != 4)
+ {
+ LOG_ERROR(Only watchpoints of length 4 are supported);
+ return ERROR_TARGET_UNALIGNED_ACCESS;
+ }
+
+ if (watchpoint-address % 4)
+ {
+ LOG_ERROR(Watchpoints address should be word aligned);
+ return ERROR_TARGET_UNALIGNED_ACCESS;
+ }
+
+ switch (watchpoint-rw)
+ {
+ case WPT_READ:
+ enable = ~EJTAG_DBCn_NOLB;
+ break;
+ case WPT_WRITE:
+ enable = ~EJTAG_DBCn_NOSB;
+ break;
+ case WPT_ACCESS:
+ enable = ~(EJTAG_DBCn_NOLB | EJTAG_DBCn_NOSB);
+ break;
+ default:
+ LOG_ERROR(BUG: watchpoint-rw neither read, write nor access);
+ }
+
+ watchpoint-set = wp_num + 1;
+ comparator_list[wp_num].used = 1;
+ comparator_list[wp_num].bp_value = watchpoint-address;
+ target_write_u32(target, comparator_list[wp_num].reg_address, comparator_list[wp_num].bp_value);
+ target_write_u32(target, comparator_list[wp_num].reg_address + 0x08, 0x);
+ target_write_u32(target, comparator_list[wp_num].reg_address + 0x10, 0x);
+ target_write_u32(target, comparator_list[wp_num].reg_address + 0x18, enable);
+ target_write_u32(target, comparator_list[wp_num].reg_address + 0x20, 0);
+ LOG_DEBUG(wp_num %i bp_value 0x% PRIx32 , wp_num, comparator_list[wp_num].bp_value);
+
return ERROR_OK;
}
int mips_m4k_unset_watchpoint(struct target_s *target, watchpoint_t *watchpoint)
{
- /* TODO */
+ /* get pointers to arch-specific information */
+ mips32_common_t *mips32 = target-arch_info;
+ mips32_comparator_t * comparator_list = mips32-data_break_list;
+
+ if (!watchpoint-set)
+ {
+ LOG_WARNING(watchpoint not set);
+ return ERROR_OK;
+ }
+
+ int wp_num = watchpoint-set - 1;
+ if ((wp_num 0) || (wp_num = mips32-num_data_bpoints))
+ {
+ LOG_DEBUG(Invalid FP Comparator number in watchpoint);
+ return ERROR_OK;
+ }
+ comparator_list[wp_num].used = 0;
+ comparator_list[wp_num].bp_value = 0;
+ target_write_u32(target, comparator_list[wp_num].reg_address + 0x18, 0);
+ watchpoint-set = 0;
+
return ERROR_OK;
}
int mips_m4k_add_watchpoint(struct target_s *target, watchpoint_t *watchpoint)
{
- /* TODO */
+ mips32_common_t *mips32 = target-arch_info;
+
+ if (mips32-num_data_bpoints_avail 1)
+ {
+ LOG_INFO(no hardware watchpoints available);
+ return ERROR_TARGET_RESOURCE_NOT_AVAILABLE;
+ }
+
+ mips32-num_data_bpoints_avail--;
+
+ mips_m4k_set_watchpoint(target, watchpoint);
return ERROR_OK;
}
int mips_m4k_remove_watchpoint(struct target_s *target, watchpoint_t *watchpoint)
{
- /* TODO */
+ /* get pointers to arch-specific information */
+ mips32_common_t *mips32 = target-arch_info;
+
+ if (target-state != TARGET_HALTED)
+ {
+ LOG_WARNING(target not halted);
+ return ERROR_TARGET_NOT_HALTED;
+ }
+
+ if (watchpoint-set)
+ {
+ mips_m4k_unset_watchpoint(target, watchpoint);
+ }
+
+ mips32-num_data_bpoints_avail++;
+
return ERROR_OK;
}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] Unbreak build for Mac OS X
Attached patch unbreaks build on MacOS X (I guess
on *BSD too):
- stdlib.h should be included instead of malloc.h for
better portability
- Eliminate r could be used uninitialized gcc warning
--
gonzo
Index: src/helper/membuf.c
===
--- src/helper/membuf.c (revision 2400)
+++ src/helper/membuf.c (working copy)
@@ -20,7 +20,7 @@
#include stdio.h
#include stdarg.h
-#include malloc.h
+#include stdlib.h
#include string.h
#include membuf.h
Index: src/flash/at91sam3.c
===
--- src/flash/at91sam3.c (revision 2400)
+++ src/flash/at91sam3.c (working copy)
@@ -2385,6 +2385,7 @@
if (0 == strcmp(show, argv[0])) {
if (who == -1) {
showall:
+ r = ERROR_OK;
for (x = 0 ; x pChip-details.n_gpnvms ; x++) {
r = FLASHD_GetGPNVM((pChip-details.bank[0]), x, v);
if (r != ERROR_OK) {
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] Unbreak build for Mac OS X
Oleksandr Tymoshenko wrote: Attached patch unbreaks build on MacOS X (I guess on *BSD too): - stdlib.h should be included instead of malloc.h for better portability - Eliminate r could be used uninitialized gcc warning COMMITED - Thanks. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Advanced Reset Process
On Thu, Jun 25, 2009 at 12:06 AM, David Brownelldavi...@pacbell.net wrote: On Wednesday 24 June 2009, Duane Ellis wrote: So maybe you can answer this ... What does the arp_ prefix in various commands represent? Address Resolution Protocol was my first reaction ... but that doesn't seem relevant to JTAG. ;) That name arp_ was coined by my self an Oyvind last year when we where trying to introduce Reset events and all the other Jim type events. The ARP - stood for: Advanced Reset Process - On Wednesday 24 June 2009, Ųyvind Harboe wrote: The idea is to have a prefix to low level fn's that the higher level tcl reset proc uses. As such the choice of prefix is arbitrary. OK, first question answered. Thanks. Next ... Does it seem to you like the reset process is flexible enough yet? The idea is that those targets where the tcl reset proc doesn't cut it would implement their own tcl reset proc from scratch. This avoids switching programming paradigm from procedural to event based, i.e. we could add events until the cows go home and still miss that crucial event for the next target. I don't believe that it is possible to *ever* add a reset event that is flexible enough for all future targets. I'm in favour of adapting OpenOCD as we go along rather than create a hugely complicated monster reset scheme that still won't catch the next jtag router from hell problems. I'm thinking .. no: - All those reset events go to debug targets ... but there's at least the ICEpick example, where a JRC needs 100+ TCK cycles after entering TLR, and it's easy to find others. Loading an FPGA, for one. Those aren't targets; so no events... I'm not even sure that the reset concept even applies to an FPGA. For Altera Nios I'd first like to program the FPGA, then reset the CPU. - I was looking at DM355 documentation and it clearly distinguishes cold resets -- both TRST and SRST get cycled -- from warm ones -- SRST only. We don't seem to have a clean way to do warm today. soft_reset_halt? [I've deleted those items where I had no useful input at this time] And I suspect that if I looked around a bit, I'd find more such cases where the reset model isn't (yet!) advanced enough. Thoughts? A target/board config file can reimplement the reset proc from scratch. How far does that get you? -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] The OpenOCD Foundation
Without biasing the community further than this, what would you expect from such an entity? As a user? Developer? Contributor? Vendor? Founder? I'd like to see an ability to collect money to pay a developer to do more tedious legwork of making more complete and well tested target support or otherwise crossing various chasms that is hard to do in small steps. Here are some targets I can think of that require a significant initial kickstart effort that I'm not expecting to crop up overnight or as a result of incremental patches: - Altera Nios - PowerPC - Cortex A8 - 64 bit target support - Non-JTAG physical interfaces. This includes written guidelines for interface vendors. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
