Menu
▾
▴
openocd-devel
|
From: Photo L. <pho...@ya...> - 2009-06-24 00:56:32
|
In other words, you have agree with what I said.
Accept the exception now. Once a usable replacement is available, remove the code/exception. The act of removing the code will make it "new code".
Thanks for disagreeing only to agree in the end.
________________________________
From: Magnus Lundin <lu...@ml...>
To: Photo Leecher <pho...@ya...>
Cc: ope...@li...
Sent: Tuesday, 23 June, 2009 23:52:02
Subject: Re: [Openocd-development] License
Photo Leecher wrote:
> Where does it say that you cannot revoke an exception in a new version/revision?
> That doesn't make sense???
>
Sure
But it only applies to new code since last release when other rights were granted.
This is NOT a GPL problem, it applies anytime you give somebody a time limited licence to anything.
And this goes for all FOSS licences. And all other valid licenses, open/free/commercial or whatever
/M
|
|
From: Thomas A. M. <to...@mo...> - 2009-06-24 00:55:04
|
On Tue, 2009-06-23 at 22:37 +0000, Photo Leecher wrote: > Oh really? > So one can no longer remove code that uses FTDI2xx in a newer > revision/version and remove it from the license? > You should get yourself a lawyer... That will be the day when one is > not allowed to DELETE CODE. > > Oh dear.... > > Well, you would have a hard time deleting the code from my computer and I would still be able to distribute it, so not it can not be totally removed. tom > |
|
From: Photo L. <pho...@ya...> - 2009-06-24 00:59:08
|
Your copy would have the exception because you got revision X.
Revision X+1 would not, and therefore you wouldn't be able to distribute FTDI2XX any longer as part of >= X+1.
People who want to keep revision X 5 years later can do so, but would no longer get the latest-and-greatest code.
________________________________
From: Thomas A. Moulton <to...@mo...>
To: Photo Leecher <pho...@ya...>
Cc: ope...@li...
Sent: Tuesday, 23 June, 2009 23:54:55
Subject: Re: [Openocd-development] License
On Tue, 2009-06-23 at 22:37 +0000, Photo Leecher wrote:
> Oh really?
> So one can no longer remove code that uses FTDI2xx in a newer
> revision/version and remove it from the license?
> You should get yourself a lawyer... That will be the day when one is
> not allowed to DELETE CODE.
>
> Oh dear....
>
>
Well, you would have a hard time deleting the code from my computer
and I would still be able to distribute it, so not it can not be totally
removed.
tom
>
|
|
From: Michael S. <rin...@di...> - 2009-06-24 01:00:05
|
Photo Leecher wrote: > Isn't it great that you are against a solution that would put a dent > in sales of your overpriced rip off 700€ hardware? > Gotta love the impartiality here... > The exception could be allowed now and then removed later once the > supposed new solutions are done and working. So, Mr. anonymous, what have you contributed to OpenOCD? Oyvind has contributed substantial parts that made OpenOCD much more useful (for example fixing IXP420 targets, which was very important for me), and he did not take any money for it, so he definitely deserves a vote (apart from the legal side, which means he holds part of the copyright and we can't change the license for the current version without him, like it or not). What have you contributed to OpenOCD? Why should we listen to *your* demands? cu Michael |
|
From: Zach W. <zw...@su...> - 2009-06-24 01:10:20
|
On Wed, 2009-06-24 at 00:44 +0200, Michael Schwingen wrote: > Photo Leecher wrote: > > Isn't it great that you are against a solution that would put a dent > > in sales of your overpriced rip off 700 hardware? > > Gotta love the impartiality here... > > The exception could be allowed now and then removed later once the > > supposed new solutions are done and working. > So, Mr. anonymous, > > what have you contributed to OpenOCD? > > Oyvind has contributed substantial parts that made OpenOCD much more > useful (for example fixing IXP420 targets, which was very important for > me), and he did not take any money for it, so he definitely deserves a > vote (apart from the legal side, which means he holds part of the > copyright and we can't change the license for the current version > without him, like it or not). > > What have you contributed to OpenOCD? Why should we listen to *your* > demands? Please stop feeding this troll. :) Cheers, Zach |
|
From: Photo L. <pho...@ya...> - 2009-06-24 01:16:14
|
Tell me where I have made any demands??? Nice fail, Herr TROLL. ________________________________ From: Michael Schwingen <rin...@di...> To: ope...@li... Sent: Tuesday, 23 June, 2009 23:44:15 Subject: Re: [Openocd-development] License Photo Leecher wrote: > Isn't it great that you are against a solution that would put a dent > in sales of your overpriced rip off 700€ hardware? > Gotta love the impartiality here... > The exception could be allowed now and then removed later once the > supposed new solutions are done and working. So, Mr. anonymous, what have you contributed to OpenOCD? Oyvind has contributed substantial parts that made OpenOCD much more useful (for example fixing IXP420 targets, which was very important for me), and he did not take any money for it, so he definitely deserves a vote (apart from the legal side, which means he holds part of the copyright and we can't change the license for the current version without him, like it or not). What have you contributed to OpenOCD? Why should we listen to *your* demands? cu Michael _______________________________________________ Openocd-development mailing list Ope...@li... https://lists.berlios.de/mailman/listinfo/openocd-development |
|
From: David B. <da...@pa...> - 2009-06-24 01:16:47
|
On Tuesday 23 June 2009, Magnus Lundin wrote: > The protocol to talk to MPSSE is well known/open (they do praise > developers of open alternatives on thier web site) , Though for the record ... the "bitbang" protocol for FT232 (not FT2232) is neither well-known nor open. If that were open, it would be possible to implement JTAG on other FTDI chips. Less efficiently, to be sure, but with easier 1.8V compatibility. - Dave |
|
From: David B. <da...@pa...> - 2009-06-24 01:22:56
|
On Tuesday 23 June 2009, Photo Leecher wrote: > Where does it say that you cannot revoke an exception > in a new version/revision? It doesn't... It's the same issue as any re-licensing. You can do it given agreement among all copyright holders. And it won't invalidate older source snapshots, with the previous license. |
|
From: Photo L. <pho...@ya...> - 2009-06-24 01:29:56
|
I'm sure that once a decent replacement is made available, it would be much much easier to have every (C) holder agree on removing FTDI2xx???
Many people already have older "illegal" snapshots, so that's hardly a problem. As OpenOCD gets more mature, people would want to upgrade and stop using the old versions (assuming the replacement is available).
________________________________
From: David Brownell <da...@pa...>
To: ope...@li...
Cc: Photo Leecher <pho...@ya...>
Sent: Wednesday, 24 June, 2009 0:22:54
Subject: Re: [Openocd-development] License
On Tuesday 23 June 2009, Photo Leecher wrote:
> Where does it say that you cannot revoke an exception
> in a new version/revision?
It doesn't... It's the same issue as any re-licensing.
You can do it given agreement among all copyright holders.
And it won't invalidate older source snapshots,
with the previous license.
|
|
From: Thomas A. M. <to...@mo...> - 2009-06-24 01:24:15
|
On Tue, 2009-06-23 at 22:59 +0000, Photo Leecher wrote: > Your copy would have the exception because you got revision X. > Revision X+1 would not, and therefore you wouldn't be able to > distribute FTDI2XX any longer as part of >= X+1. > > People who want to keep revision X 5 years later can do so, but would > no longer get the latest-and-greatest code. > I could merge any patches I wanted to and release... Like I said it would be complex.. That was my only point tom > |
|
From: Magnus L. <lu...@ml...> - 2009-06-24 01:27:04
|
David Brownell wrote: > On Tuesday 23 June 2009, Magnus Lundin wrote: > >> The protocol to talk to MPSSE is well known/open (they do praise >> developers of open alternatives on thier web site) , >> > > Though for the record ... the "bitbang" protocol > for FT232 (not FT2232) is neither well-known nor open. > > If that were open, it would be possible to implement > JTAG on other FTDI chips. Less efficiently, to be > sure, but with easier 1.8V compatibility. > > - Dave > I call BS. Do you know JTAG over FT232 ? Somer folks called you USB expert. The protocols available for FT232 are well published, it is not hard but unpleasant to implement JTAG on them, that is what interfaces like the Altera USB Blaster does. But JTAG over MPSSE is soo much nicer that nobody who has worked with this wants to go back to FT232 (without the extra 2), it is not a tecnical problem it is just a PITA. /M |
|
From: David B. <da...@pa...> - 2009-06-24 01:43:04
|
On Tuesday 23 June 2009, Magnus Lundin wrote: > > Though for the record ... the "bitbang" protocol > > for FT232 (not FT2232) is neither well-known nor open. > > > > If that were open, it would be possible to implement > > JTAG on other FTDI chips. Less efficiently, to be > > sure, but with easier 1.8V compatibility. > > > > - Dave > > > I call BS. > > Do you know JTAG over FT232 ? Somer folks called you USB expert. I've had to do SPI over FT232 and that's where I noticed that the documentation was seriously lacking. You can view JTAG as a combination of: (a) state transitions driven by TMS + TCK (b) SPI (TMS == chipselect) in the xRSHIFT states > The protocols available for FT232 are well published, it is not hard but > unpleasant to implement JTAG on them, that is what interfaces like the > Altera USB Blaster does. If they are "well published" that's news to me. I found significant holes. One example is just the differences between the FT232B and FT232R revisions. I think it was winter 2006-2007 where I did that; maybe docs have been fixed since then. The "Official Answer" from FTDI was to use D2XX library. Any "well published" docs related to that library, not to commands at the chip level. I suppose I could have stuck a USB sniffer on the wire and watched what their library did with each API call. The need for that level work highlights the doc holes > But JTAG over MPSSE is soo much nicer that nobody who has worked with > this wants to go back to FT232 (without the extra 2), it is not a > tecnical problem it is just a PITA. Agreed, JTAG over MPSSE is better. And a part of that is that the docs actually cover all the registers and commands you can issue, so you're not left guessing. - Dave |
|
From: Photo L. <pho...@ya...> - 2009-06-24 01:27:35
|
People can already do what you say... They can merge+build the latest and use FTDI2xx.
Amount of information: 0
________________________________
From: Thomas A. Moulton <to...@mo...>
To: Photo Leecher <pho...@ya...>
Cc: ope...@li...
Sent: Wednesday, 24 June, 2009 0:24:09
Subject: Re: [Openocd-development] License
On Tue, 2009-06-23 at 22:59 +0000, Photo Leecher wrote:
> Your copy would have the exception because you got revision X.
> Revision X+1 would not, and therefore you wouldn't be able to
> distribute FTDI2XX any longer as part of >= X+1.
>
> People who want to keep revision X 5 years later can do so, but would
> no longer get the latest-and-greatest code.
>
I could merge any patches I wanted to and release...
Like I said it would be complex.. That was my only point
tom
>
|
|
From: Thomas A. M. <to...@mo...> - 2009-06-24 01:30:36
|
LMAO That could be said for a lot of the recent messages on this list! A very LOW signal to Noise ratio Lets start talking about solutions tom On Tue, 2009-06-23 at 23:27 +0000, Photo Leecher wrote: > People can already do what you say... They can merge+build the latest > and use FTDI2xx. > Amount of information: 0 > > > > > ______________________________________________________________________ > From: Thomas A. Moulton <to...@mo...> > To: Photo Leecher <pho...@ya...> > Cc: ope...@li... > Sent: Wednesday, 24 June, 2009 0:24:09 > Subject: Re: [Openocd-development] License > > On Tue, 2009-06-23 at 22:59 +0000, Photo Leecher wrote: > > Your copy would have the exception because you got revision X. > > Revision X+1 would not, and therefore you wouldn't be able to > > distribute FTDI2XX any longer as part of >= X+1. > > > > People who want to keep revision X 5 years later can do so, but > would > > no longer get the latest-and-greatest code. > > > I could merge any patches I wanted to and release... > > Like I said it would be complex.. That was my only point > > tom > > > > > > _______________________________________________ > Openocd-development mailing list > Ope...@li... > https://lists.berlios.de/mailman/listinfo/openocd-development |
|
From: Laurent G. <lau...@am...> - 2009-06-24 14:26:42
|
> > 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-userSSSSSSSSS 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 |
|
From: Zach W. <zw...@su...> - 2009-06-24 19:04:40
|
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-userSSSSSSSSS > 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 OpenOCD]" is like saying "teenagers know what they need in a car". They may be the customer, but would would let them design the car? Or manage its production? How about QA? Distribution? Ah!! Gas station attendants! I am kidding, of course. No offense to any users. I live in Oregon, where it's illegal to pump your own gas; we have attendants at all stations, often staffed by -- you got it -- teenagers. :) I have acknowledged the fact that users demand a solution, and the solutions presented have been queued for eventual delivery. Someone will implement the suggestions that have been put forth, and life will go back to normal. > OpenOCD has a success story as open source from 2004. Please respect the > story ! And there will be a bigger success story in 2009, when all binary distributions of OpenOCD provide fully GPL-compliant solutions. Right? :) > Until now, the success story says D2XX is needed ! Sorry, it is. I have explained how this functionality does not need to be lost. You should be able to deliver exactly the same binary distribution that you have been distributing, except it would be produced from scratch on the user's machine. There may be other build-kit related solutions, which I have indicated that I am beginning to investigate. > 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. Thank you for providing your feedback. I hope you understand and will respect that we intend for the current project source code to remain under the GPL license. We will find solutions for users that solve these problems that comply with its terms. Cheers, Zach Welch Corvallis, OR |
|
From: Dominic <Dom...@gm...> - 2009-06-24 19:35:52
|
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 |
|
From: David B. <da...@pa...> - 2009-06-24 22:30:19
|
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!) |
|
From: Øyvind H. <oyv...@zy...> - 2009-06-24 22:32:38
|
On Wed, Jun 24, 2009 at 10:30 PM, David Brownell<da...@pa...> 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? That's actually "advanced reset process/procedure" or some such. Duane came up with it. 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. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com |
|
From: Zach W. <zw...@su...> - 2009-06-24 23:00:14
|
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 be how you may have interpreted my use of that word. I apologize if that is the case, as you can see that was not my intention. Language often gets me into trouble, I fear. However, I hope that you will allow me to continue to lead the project forward into a new gilded age for OpenOCD. Your advice will always be welcome, but I will be disinclined to continue as a leader here without your clear delegation of command authority. With that, I cannot do what is necessary to keep the project moving forward on track. No one can. We have "lost" a week to the license debate; these kinds of distractions serious detract from the health of the community. We lost another solid contributor as a consequence of "discussing" these matters; I will always wonder how things might have turned out had there been better leadership, from myself included. Incidentally, am I to assume that I finally convinced you that just going with the GPL was the easiest (or most legally safe) path? :) Surely, your position on the socket-based drivers seems very pro-GPL, so I am very curious to what extent you were capitulating to "mob rule" when faced with all those angry faces behind the torches and pitchforks (virtually speaking). If you feel like answering at all, we can take this line of discussion off-list; no sense in stirring up more trouble. Cheers, Zach |
|
From: Duane E. <op...@du...> - 2009-06-24 23:28:58
|
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. |
|
From: David B. <da...@pa...> - 2009-06-25 00:06:26
|
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? 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 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.
- In cases where there's no SRST available (*), there's
no alternate hook to trigger reset through JTAG. For
example, using JRC operations (I'm hoping to get some
documentation). Or with Cortex-M3, it seems that
some DAP operations can generate SRST too.
- Wondering why this old PXA255 board won't work with
current OpenOCD ... docs say that not only does it
need 35+ TCK cycles after entering TLR, but also
that the model is to keep SRST active while issuing
the first few JTAG commands. Current reset code
deactivates SRST at the same time as TRST.
- I found some TI docs talking about "Wait in Reset"
capability of some systems, triggered by changing
the EMU0/EMU1 signals (which OpenOCD doesn't know
about) from "pulled high" to "one driven low".
Same kind of model as those PXA255 docs describe.
- Even when SRST *does* exist, I can imagine debug
scenerios where using it is the wrong thing. You
may just want to reset one component, not the whole
system.
- Chasing that PXA thing I wanted to just issue a
reset with no target enabled. It didn't want to
do such a thing with only JTAG level stuff defined.
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?
- Dave
(*) As for example wherever TI's 14-pin JTAG connector
is used. My DM6446 board through 20-pin CTI to
14-pin level shifting adapter; OMAP3 BeagleBoard.
|
|
From: David B. <da...@pa...> - 2009-10-09 22:53:55
|
For the record ... I think the key open issue here is the need to refactor target code so that we have more general support for reset-without-SRST, using event handlers that know how to do that via JTAG (such as by forcing a watchdog reset). Maybe in 0.4.x ... Once that happens, the other open bits should be easy enough to solve. On Wednesday 24 June 2009, David Brownell wrote: > > Does it seem to you like the reset process is flexible > enough yet? 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... We seem to have this one addressed for now ... two more events go to TAPs, sufficient for ICEpick configuration. I can imagine the "setup" TAP event being used to load an FPGA and then enable the targets associated with some CPUs that just got instantiated. > - 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. We can do that now if we want, via custom reset_init. > - In cases where there's no SRST available (*), there's > no alternate hook to trigger reset through JTAG. For > example, using JRC operations (I'm hoping to get some > documentation). Or with Cortex-M3, it seems that > some DAP operations can generate SRST too. Not there yet, but there's a proposal for how to model it and let targets stop hard-wiring "use SRST". > - Wondering why this old PXA255 board won't work with > current OpenOCD ... docs say that not only does it > need 35+ TCK cycles after entering TLR, but also > that the model is to keep SRST active while issuing > the first few JTAG commands. Current reset code > deactivates SRST at the same time as TRST. Partly resolved. Controlling the "basic" hard reset call through a Tcl script lets us perform some of the right stuff at reset time, and get past the first roadblock. The parameter to that script can be used too. I'm thinking we may want to tweak the current reset event sequence, and model; see below. PXA for example is one of many platforms that doesn't look to need such a hard reset ... an SRST-only (warm) reset shouldn't need to reinitialize all the debug stuff a TRST+SRST (cold) reset requires. > - I found some TI docs talking about "Wait in Reset" > capability of some systems, triggered by changing > the EMU0/EMU1 signals (which OpenOCD doesn't know > about) from "pulled high" to "one driven low". > Same kind of model as those PXA255 docs describe. Re EMU0/EMU1, once we have support for e.g. XDS100 (v1 or v2) we can add such support via Tcl procedures. As with PXA255, I'm thinking the reset sequence and model might need to change. Today we issue TWO hard resets by default, using SRST ... one should suffice. And the state of things between those resets is kind of fuzzy. We should be able to issue just one reset; not be required to use SRST; have better treatment of the two main models (either we can talk JTAG while SRST is active ... or not); and in general, be able to rely less on both SRST and TRST. > - Even when SRST *does* exist, I can imagine debug > scenerios where using it is the wrong thing. You > may just want to reset one component, not the whole > system. ... see above. > - Chasing that PXA thing I wanted to just issue a > reset with no target enabled. It didn't want to > do such a thing with only JTAG level stuff defined. Not sure if this got addressed yet. > 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? > > - Dave > > (*) As for example wherever TI's 14-pin JTAG connector > is used. My DM6446 board through 20-pin CTI to > 14-pin level shifting adapter; OMAP3 BeagleBoard. > |
|
From: Øyvind H. <oyv...@zy...> - 2009-06-25 05:52:58
|
On Thu, Jun 25, 2009 at 12:06 AM, David Brownell<da...@pa...> 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 |
|
From: David B. <da...@pa...> - 2009-06-27 20:34:41
|
> > 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.
That seems undesirable when some key improvements can
be more generically available.
Like for starters, either a TAP event on TLR entry
or a settable parameter saying how many TCK cycles
must be issued in TLR before issuing JTAG commands.
What we have now is "jtag_ntrst_delay milliseconds",
without clocks going. "jtag_ntrst_clocks" would
address documented ICEpick and PXA255 constraints.
And there are no doubt other similar small tweaks.
Note the scaing problem with needing target-specific
rewrites of ocd_process_reset: it's impractical to
combine two such targets on one board...
> 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'd call the current reset "events" procedural
hooks, myself. Heck, they don't even accept
any parameters ... :)
> 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.
Routers weren't the only, or even the main, set
of motivating examples...
But you seem to agree that the reset process
still has holes that need fixing ("adapting");
so that question is answered.
> > 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.
If I've got an FPGA *not* programmed with a Nios core,
that model doesn't work. :)
That issue isn't entirely "reset". It's "initialization",
which is a separable chunk of reset processing. For a
Nios core you could have "system reset" requiring both
"FPGA init" loading the core, and then "core reset".
But other FPGA bitstreams might not have a target.
> > - 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?
No, that's a different beast. It applies to the current
target and doesn't involve SRST.
One reason to want a warm reset is that it leaves all
the debug/jtag stuff alone. Maybe you tweaked some
settings so that some things become observable during
the reset/reinit sequence.
> [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?
As a "user", way deeper into the undocumented innards
of OpenOCD than I want to be. ;)
As a developer, it's hard to say without doing it.
My initial reaction is that the reset processes are
not yet factored well enough to support everything
that I've happened across. But experimenting with
a few individual targets should help identify more
of the holes.
What I'd like to see is a kind of "reset toolkit"
which would make that practical. But it's not
really there yet. "Reimplement ocd_process_reset"
is not a scalable approach.
- Dave
|
Thanks for helping keep SourceForge clean.
X