Re: [Openocd-development] Dynamic library loading
FWIW, this will not bring GPL-compliance. Is that the goal, or just loadable library support? I am in favor of this later, but I thought you were pushing for the former. Under Windows an executable will fail to load if it links implicitly to a dll even if that dll is not used. It's prefectly legitimate to have a GPL compliant dll that may not be present on the system. So far so good. Transparent attempts at circumventing GPL lie down this same path, so keep your eyes peeled :-) -- Ø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] bug report automation
I *HIGHLY* recommend the following approach: - generate a .txt file - have users email that .txt file as an attachment to an email address using an email program of their choice I believe adding code in OpenOCD to talk directly to the internet would be a Bad Idea because firewalls will stop a huge audience from reporting. These firewalls are paranoid about everything: HTTP, SMTP, ftp, etc. You name it! :-) Better a smaller more representative sampling than a huge skewed one. The ZY1000 web interface uses a similar approach: - genereate a page with lots of info - users copy paste that information into an email sent to supp...@zylin.com Previously we had some more fancy scheme that used a HTTP POST directly to www.zylin.com, but that turned out to be a non-starter. -- Ø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] [patch] openocd.texi - svf and xsvf commands
Committed. Thanks! -- Ø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] platform survey
On Thu, Jun 25, 2009 at 10:54 AM, Zach Welchz...@superlucidity.net wrote: Hi all, Michael Fischer posted the following survey on the SparkFun forum: http://forum.sparkfun.com/viewtopic.php?t=16044 I use linux and might want to use openocd on some embedded target(ramdon arm board). Greetings ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] FT2232 Windows - license consideration
Hello Øyvind and the list, Øyvind Harboe napsal(a): welcome back it's been a while! I hope that you'll stick around to submit some more good patches. You've contributed lots of nice stuff in the past! I am still here, monitoring the forum and I surely also do have future plans to contribute to OpenOCD in the future. GPL stops closed source target interface for OpenOCD. Sure, I understand that and I have to say I am not arguing about this. I like open source, it is just I really do not like if suddenly appears someone literally interpreting a legal document making a problem from something which has not been problem for years - I believed that ftd2xx.dll is linked per design by the will of the original author, giving me an impression that in such case it is not a license infringement. Anyway, as I noted in my post, it is better to (technically) solve this for good rather than argue forever, I suppose you see it the same way. But we shall not become GPL slaves, solving how to pass literal interpretation of the license instead of pushing OpenOCD further. That's one of the *main* reasons I got involved with OpenOCD in the first place. Actually me to, I am not for closed interfaces, and PRESTO is also open. The only closed thing is ftd2xx, a hw driver wrapper with rather trivial API which is mostly the same as OS file I/O API so the discussion about this seems to me a bit ridiculous. Open interface to FTDI chips does not make much sense without the chip itself, noone is going to implement a compatible silicon, that is why I consider ftd2xx as part of the hw and why I see the discussion pointless, bringing no real benefit to the project itself I also knew that since the project was GPL to start with, it wouldn't switch to another license once a sufficient # of contributors had signed up. At least not without *everybody* agreeing to a license change. This ensures that any license change won't be full of holes. Agreed. Too late, too complicated these days. I *know* there are hardware vendors out there that are aching to use OpenOCD together with closed source target support, and they *would* find any tiny loophole and throw money at lawyers to exploit it. Actually, this is not what I want. But I also do not like the silly madness about ftd2xx. BTW I like Linux, but what I really hate on it is lack of binary driver interface making many problems with hw compatibility - this is simply not the right way to do it, single word: interoperability. GPL does not mean the project shall not be able to communicate with non-free world and the attempt GPL made to classify allowed and forbidden ways of communication is far from ideal solution, neither does it guarantee freedom: binary communication over socket may be non-transparent in such a fashion that the code actually is not free (liberty) despite it is open. So this is what I was pointing at in my post: it is necessary to see the the principles of the license, its real meaning, so that we choose the right way, not just a technical workaround which passes the rules. Now, I *know* you can fix these USB problems with both hands tied behind your back in your sleep with a modest effort. The acceptable solutions have been outlined. For sure it's a million times easier for you to solve this technically than legally. You are right. You stand out amongst the hardware vendors because you have made *very* significant contributions in the past. Thank you very much. Personally I do no think it was such a big contribution. Without having the OpenOCD sources I would not have courage to start working on ARM JTAG debug solution, neither I have had time to program it from scratch. That is what I like on open source. Hopefully there will be more contribution from me (or us as company). How about using the bitq stuff forl a generic JTAG over TCP/IP solution? ;-) Surely possible, but not much convenient, another process running on users computer, however, speed shall not be a big deal, probably a way to go. What I really would like is to separate all the JTAG logic from all low level drivers (if all drivers make use of bitbang or bitq). I am not sure about current status, I have not looked into recent source for an extensive period. On contrary, creating socket bitq interface would make it easier for vendors selling proprietary JTAG interfaces without giving any contribution, they would just implement the other side of the pipe. As you see every coin has two sides - implementing socket bitq would comply with literally interpreted GPL but at the same time, it would undermine its principles. Binary compatible libftdi-ftd2xx is also fine but opposite solution might be even more interesting: reimplement ftd2xx.dll using libftdi, giving a free solution also for other projects which use ftd2xx. In other words to take ftd2xx ABI as a standard and reimplement it to get fully free solution to fully comply with the license. Either way, I like the
Re: [Openocd-development] [windows + openocd] GPL implementation of libd2xx.dll ?
Hello Maciej, Maciej Grela napsal(a): A friend of mine pointed me to the threads concerning GPL/windows/building/libftdi/libusb/libd2xx. After reading all this an idea came to my head - what if we implement our own GPL/LGPL version of libd2xx.dll ? This is also an option, but there are problems mainly in maintainance of compatibility - these days there is more than just a single version of the chip while FTDI keeps compatible API - I am not sure whether the compatibility is maintained in the driver or the DLL but I experienced a situation after driver update that different versions of driver and DLL are not necessarily compatible. From my investigation it seems, that the driver does all the hard work, the DLL itself just calls some ioctls. However, this is completely undocumented. Also, the driver is the only thing, that needs to be signed if I understand correctly. Yes, you are right. Obviously, GPL code can communicate with drivers using system calls so I don't suspect any traps. Correct, despite (as stated in my previous post) I really do not like the qualification of communication to GPL allowed and GPL prohibited, GPL speaks so. Also, Freddie, can I ask for more details about your performance comparisons ? You've said, that libd2xx performs better than libftdi but is this only under windows ? What is the speed difference between libftdi + libusb under linux, libftdi + libusb under windows and libd2xx + native windows driver ? I'm trying to figure out if the windows driver does some magic to speed up the transfers or does libusb suckiness on win32 cause it's inferior performance. The problem with libftdi used to be that it was not able to do async I/O operations, which meant that data was not read from the chip during writing larger block to it - this might cause buffer overflow. Because of that there had to be quick write/read turnarounds with small block sizes - what fits into the on-chip buffer. However when I looked into recent libftdi sources I assume this is no longer true, so the performance difference shall not be that significant these days - in theory. Best regards, Pavel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 Windows - license consideration
But we shall not become GPL slaves, solving how to pass literal interpretation of the license instead of pushing OpenOCD further. GPL is our most vital line of defense against closed source target/interface support in OpenOCD. If the maintainers and contributors do not respect and follow the GPL license, then why should we expect anybody else to do so? Further we have to be rather stubborn and nit-picking about it, lest closed source target support makers are going to try to go for the loopholes... Closed source target support makes no sense to me for OpenOCD. There are plenty of excellent closed source target solutions out there, that's not OpenOCD's job/mission nor do I think that OpenOCD has anything unique to contribute in that regard. We use proprietary closed source hardware debuggers every day. Works fine! I'm all for closed source target support, but that's not what OpenOCD is about. That's one of the *main* reasons I got involved with OpenOCD in the first place. Actually me to, I am not for closed interfaces, and PRESTO is also open. You guys have a lot of closed source target programming support as well as OpenOCD support! Good for you! ;-) I've checked out your web site and it looks like really neat stuff. I'd get nightmares about trying to set up a complete test setup of all those combinations. The only closed thing is ftd2xx, a hw driver wrapper with rather trivial API which is mostly the same as OS file I/O API so the discussion about this seems to me a bit ridiculous. It is, isn't it? Especially considering that a technical solution is forthcoming. The whole USB problem is a red herring. It will be gone long before can get around to sue anybody :-) *After* the USB problem is solved, it will be unacceptable to continue to breach GPL. The clock is ticking. Nobody can really claim to have been unaware of this. It's now time to pitch in and help solve the problem at the technical level. We want to make it perfectly clear that we *WILL* nit-pick about GPL stuff because open target/interface support is what OpenOCD is about. Closed source target support has been done to death. The point about nitpicking about GPL is to make sure that everybody understands that we really mean it when we say we want open source target support and nothing else. Open interface to FTDI chips does not make much sense without the chip itself, noone is going to implement a compatible silicon, that is why I consider ftd2xx as part of the hw and why I see the discussion pointless, bringing no real benefit to the project itself The whole USB/FTDI thing is a red herring. This is really about sticking GPL on OpenOCD for the purposes of getting open source target support. Some technical hazzle with drivers is a *small* price to pay for open source target support. -- Ø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] Dynamic library loading
Hi Øyvind, Originally I intended to let the discussion settle and see how things develop. Looks like there are still misunderstandings and I can't resist... Øyvind Harboe wrote: Under Windows an executable will fail to load if it links implicitly to a dll even if that dll is not used. When using LoadLibrary, the executable will be loaded and will run, even if the loaded library is not available. It's prefectly legitimate to have a GPL compliant dll that may not be present on the system. So far so good. It's perfectly legitimate to _distribute_ a *GPL compliant* DLL with GPL'ed executables. It's perfectly legitimate to _run_ a *non GPL compliant* DLL with GPL'ed executables. The intention of GPL is to explicitly give users the freedom to use GPL software in any way they see fit. Transparent attempts at circumventing GPL lie down this same path, so keep your eyes peeled :-) AFAIK, adding support for a non-compliant DLL in GPL code is not circumventing any GPL clause that I know of, neither directly not indirectly. Harald ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [windows + openocd] GPL implementation of libd2xx.dll ?
2009/6/26 Pavel Chromy chr...@asix.cz: Hello Maciej, Maciej Grela napsal(a): A friend of mine pointed me to the threads concerning GPL/windows/building/libftdi/libusb/libd2xx. After reading all this an idea came to my head - what if we implement our own GPL/LGPL version of libd2xx.dll ? This is also an option, but there are problems mainly in maintainance of compatibility - these days there is more than just a single version of the chip while FTDI keeps compatible API - I am not sure whether the compatibility is maintained in the driver or the DLL but I experienced a situation after driver update that different versions of driver and DLL are not necessarily compatible. From my investigation it seems, that the driver does all the hard work, the DLL itself just calls some ioctls. However, this is completely undocumented. I can try to reverse engineer the library and produce the documentation about this interface if people will want to use it in openocd. The compatibility issue you mentioned would be likely the most painful part of maintaining such documentation/library though. Br, Maciej Grela ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] ftd2xx - libftdi
Hi all, Having had time to reflect quietly about the FTD2XX situation, I have started to grow concerned about the numerous options that have been proposed to address the FTD2XX distribution issue. All these efforts -- in N directions at once -- most trying to solve one single problem, and this issue is not even central to our in-tree code. Except for the socket driver, the rest all seem like workarounds for the proper solution. Only libusb+libftdi serves our long-term interests. What other solution offers as much value -- in the _strategic_ sense of that word? All of the other ideas are short- or medium-term fixes, designed to workaround the fact that the free software solution cannot provide parity with the proprietary driver today. If that sums it up, we have the source code for libusb and libftdi along with the impetus to top its performance. The free libraries can probably surpass the closed driver benchmarks over time, and it can be distributed with OpenOCD when linked as a static binary. Furthermore, we could be exploiting the many eyeballs phenomenon, when we appear to be doing the exact opposite: N solutions, each preferred by their own followers for individual reasons. There is nothing wrong with everyone doing their own thing, by the way. This is simply my observation of our situation, meshed with experience from the matrix of open source and free software universes (i.e. the bazaar). Let me go through the solutions again, this time classifying each proposal as a workaround or long-term solutions, with pros and cons: Short-term: 0) documentation: in-tree recipes for building on all platforms - Pros: no code! - Cons: ditto 1) build kit: automatic building tools - Pros: distribution-compliant, developer-friendly - Cons: needs full toolchain; not good for windows _users_ 2) ... (still pending approval from the FSF) ... (compliant???)** - Pros: user-friendly, - Cons: slow, non-standard, yuck, yuck, yuck ;) 3) libftdi+ftd2xx+wrapper: ABI compatible with libftdi to wrap ftd2xx - Pros: a low-hanging fruit - Cons: still uses FTD2XX (not GPL), requires separate install, may be hard to emulate libftdi with proprietary library Middle-term: 4) socket-based driver: - Pros: nice to have anyway... binary distributable! - Cons: performance hits? Long-term: 5) libusb+libftdi: *** in theory, should be the best - Pros: can provide full performance, and best binary distribution - Cons: Windows-only problems? no experts? no specs? it's hard? 6) FTDI releases FTD2XX under BSD/LGPL/GPL-compatible terms - Pros: easiest technical solution - Cons: hardest legal solution If we are pursuing all of these at one time, our collective resources are not being used efficiently. It's nice to see all the activity, but I think we could make more productive use of our collective time. Now, I am *not* asking anyone to change what they are doing, but what if _everyone_ just buckles down and focuses on fixing libusb and libftdi? As I said at the start of all of this, this option seems like the best use of the community's resources: (a) It will be the best contribution to the free software community. (b) We would start to leverage the many eyeballs phenomenon here. (c) We should be able to make it outperform the closed implementation. (d) It removes all doubts about binary distribution. (e) All of the above -- these each bear reading again. After the weekend, I will try to put a list of outstanding problems with the free solutions in the TODO list, because this is where I want to focus my own attention in these matters. Others appear to be pursuing the socket-driver approach, and there is little point in duplicating that work. I now want to show that the free solution will be superior. Developers: are there others that want to follow this same path? Users: I think _your_ best solution is a free one, for the reasons that I have given but deserve to be restated here clearly: 1) FREE allows a _single_ binary installer to deliver *all* components, without entering into any GPL-compliance gray areas. 2) FREE *may* be made to _outperform_ the closed solution, but we *can* make it perform _equally_ well. 3) FREE *will* be supported _better_ by the community and contributors. Distributors: do you want to deliver this solution to your users, if not today then someday? Will you contribute to making it happen? I have done USB, async I/O, and reverse engineering; I can fix the performance. Windows fixes must be obtained elsewhere, as I don't use that; however, any engineer with similar experience and confidence could do both tasks. Cheers, Zach Welch Corvallis, OR ** If the FSF is responsive to other inquiries, but fails to respond to my inquiry about a loophole, is that a tacit confirmation of it? :) ___ Openocd-development mailing list Openocd-development@lists.berlios.de
Re: [Openocd-development] ftd2xx - libftdi
Hello Zach and the list, Zach Welch napsal(a): If we are pursuing all of these at one time, our collective resources are not being used efficiently. It's nice to see all the activity, but I think we could make more productive use of our collective time. Now, I am *not* asking anyone to change what they are doing, but what if _everyone_ just buckles down and focuses on fixing libusb and libftdi? As I said at the start of all of this, this option seems like the best use of the community's resources: This path is IMHO very far from best solution, remember that FTDI chips evolve, there are several variants on the market today. Is it really a good idea to maintain compatibility with future chips? Is this not exactly the task for a device driver? Be the answer yes or no (I assume yes) this is definitely not a task for OpenOCD itself. FTDI delivers a solution which is so popular _mainly_ for the fact that it is easy to use without necessity to implement low level USB stuff. Maintaining a driver for hw solution which is still _closed_ and noone knows for how long it will be produced is _totally_pointless_ - especially when speaking about long term solution. Moreover FTDI is not the only USB chip in the world. And finally libusb is a hack which moves driver to userspace, and it may be necessary to digitally sign it (Windows). Who is going to pay for a signing certificate? If we want OpenOCD to support various JTAG interfaces, even commercial ones (I see no problem in that, it is the same as buying computer hardware) the _only_ option is to create a _single_standard_ interface between OpenOCD and JTAG hw driver. I see support for commercially sold JTAG interfaces as very good thing, it brings to the community those people who prefer having professional JTAG interface over soldering together some free circuitry. So if this has to happen I vote for vendor neutral solution: a) adding controlled interface http://www.gnu.org/licenses/gpl-faq.html#LinkingOverControlledInterface which is probably legally complitated b) use suitable communication method like sockets, may be easily built on top of bitq.c (a) It will be the best contribution to the free software community. And even better contribution to FTDI - why shall we prefer any single manufacturer? Developers: are there others that want to follow this same path? For myself - no. 1 Distributors: do you want to deliver this solution to your users, if not today then someday? Again, not all JTAG interafaces which may be potentially used woth OpenOCD have to be built using FTDI. Best regards, Pavel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Dynamic library loading
Hi Pavel, Pavel Chromy wrote: AFAIK, adding support for a non-compliant DLL in GPL code is not circumventing any GPL clause that I know of, neither directly not indirectly. so is your belief that it is GPL compliant to also distribute GPLed binary that includes support for a closed DLL which is actually not required to use the binary, as there is a free alternative compiled in? (e.g. bitbang parallel port driver or libtfdi support) Exactly. At my current state of knowledge I'd have no problem to distribute such a binary, _without_ FTD2XX libraries, of course. As you may know and Freddie can probably confirm: Moving to dynamic loading at runtime is a quite simple modification of the current trunk. Harald ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Dynamic library loading
Harald Kipp napsal(a): AFAIK, adding support for a non-compliant DLL in GPL code is not circumventing any GPL clause that I know of, neither directly not indirectly. so is your belief that it is GPL compliant to also distribute GPLed binary that includes support for a closed DLL which is actually not required to use the binary, as there is a free alternative compiled in? (e.g. bitbang parallel port driver or libtfdi support) Exactly. At my current state of knowledge I'd have no problem to distribute such a binary, _without_ FTD2XX libraries, of course. Thank you, Harald, this is what I was pointing at in my previous posts: find the real meaning, the original idea of GPL and defend that, not some disputable literal interpretation. Best regards, Pavel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ftd2xx - libftdi
Zach Welch wrote: Only libusb+libftdi serves our long-term interests. Wrong. libusb is a *blocking* issue that we cannot control, fix, nor whatever. LIBUSB is not supported by *newer* windows platforms. Unless and until it is supported it becomes a dead end solution, period, end of story. I believe the WinUSB solution is a solution, that for some reason keeps being left off your list. http://msdn.microsoft.com/en-us/library/aa476426.aspx -duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [windows + openocd] GPL implementation of libd2xx.dll ?
Maciej Grela pisze: You've said, that libd2xx performs better than libftdi but is this only under windows ? What is the speed difference between libftdi + libusb under linux, libftdi + libusb under windows and libd2xx + native windows driver ? I don't use linux, so I've just tested ftd2xx.dll vs libusb0.dll + libftdi.a 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ftd2xx - libftdi
On Fri, Jun 26, 2009 at 11:15 PM, Duane Ellisopen...@duaneellis.com wrote: Zach Welch wrote: Only libusb+libftdi serves our long-term interests. Wrong. libusb is a *blocking* issue that we cannot control, fix, nor whatever. LIBUSB is not supported by *newer* windows platforms. Unless and until it is supported it becomes a dead end solution, period, end of story. I believe the WinUSB solution is a solution, that for some reason keeps being left off your list. http://msdn.microsoft.com/en-us/library/aa476426.aspx I agree with you that WinUSB is a solution for OpenOCD. It is actually a solution for libusb-win32 as well. ;-) On the other hand, libusb-win32+libftdi may still need to be the solution for Windows 2000 users (and maybe 98SE and Win ME). -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ftd2xx - libftdi
Original Message Subject: [Openocd-development] ftd2xx - libftdi From: Xiaofan Chen xiaof...@gmail.com To: open...@duaneellis.com Cc: openocd-development openocd-development@lists.berlios.de Date: Fri Jun 26 2009 17:27:36 GMT+0200 (Romance Standard Time) On Fri, Jun 26, 2009 at 11:15 PM, Duane Ellisopen...@duaneellis.com wrote: Zach Welch wrote: Only libusb+libftdi serves our long-term interests. Wrong. "libusb" is a *blocking* issue that we cannot control, fix, nor whatever. LIBUSB is not supported by *newer* windows platforms. Unless and until it is supported it becomes a dead end solution, period, end of story. I believe the "WinUSB" solution is a solution, that for some reason keeps being left off your list. http://msdn.microsoft.com/en-us/library/aa476426.aspx I agree with you that WinUSB is a solution for OpenOCD. It is actually a solution for libusb-win32 as well. ;-) On the other hand, libusb-win32+libftdi may still need to be the solution for Windows 2000 users (and maybe 98SE and Win ME). I have only taken a quick look at WinUSB, but if I understand the concept correctly there might be an issue. I'm not sure of what I'm saying here so shout if it's complete nonsense. To work with WinUSB, your USB device has to indicate that WinUsb.sys is its driver. In the case of e.g. a Luminary eval board this can probably be done by making the correct .inf file or whatever (again, I'm not an expert in this). The problem I see is that all other tools using FTD2xx (like the Luminary Flash tool (I suppose)) will no longer be able to connect to the board as it is not "linked" to the FTD2xx driver. Does this make sense? And does this apply to libusb+libftdi as well? My apologies if you wasted 2 minutes of your life and want them back ;-) gr. Ronald ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ftd2xx - libftdi
Ronald Vanschoren pisze: I have only taken a quick look at WinUSB, but if I understand the concept correctly there might be an issue. I'm not sure of what I'm saying here so shout if it's complete nonsense. To work with WinUSB, your USB device has to indicate that WinUsb.sys is its driver. In the case of e.g. a Luminary eval board this can probably be done by making the correct .inf file or whatever (again, I'm not an expert in this). The problem I see is that all other tools using FTD2xx (like the Luminary Flash tool (I suppose)) will no longer be able to connect to the board as it is not linked to the FTD2xx driver. Does this make sense? And does this apply to libusb+libftdi as well? That's perfectly true - you have to use 2 different drivers for software based on ftd2xx.dll and WinUSB. That's why that's not so perfect... /; 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Dynamic library loading
Pavel Chromy pisze: Harald Kipp napsal(a): AFAIK, adding support for a non-compliant DLL in GPL code is not circumventing any GPL clause that I know of, neither directly not indirectly. so is your belief that it is GPL compliant to also distribute GPLed binary that includes support for a closed DLL which is actually not required to use the binary, as there is a free alternative compiled in? (e.g. bitbang parallel port driver or libtfdi support) Exactly. At my current state of knowledge I'd have no problem to distribute such a binary, _without_ FTD2XX libraries, of course. Thank you, Harald, this is what I was pointing at in my previous posts: find the real meaning, the original idea of GPL and defend that, not some disputable literal interpretation. First of all - my work towards dynamic library loading on Windows (maybe on Linux too, but I don't have knowledge about that system, so I'd rather pass that one to someone else) is not for doing-whatever with GPL. I just think that it would be a good addition for OpenOCD, as the need for libraries one doesn't use is not quite obvious for normal user. About posts by Herald and Pavel - I personally agree totally with you, but - as you've already noticed - some maintainers just don't share our point of view, and I think there is no way of convincing them - they just don't want to be convinced. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ftd2xx - libftdi
On Fri, Jun 26, 2009 at 11:49 PM, Freddie Chopinfreddie_cho...@op.pl wrote: Ronald Vanschoren pisze: I have only taken a quick look at WinUSB, but if I understand the concept correctly there might be an issue. I'm not sure of what I'm saying here so shout if it's complete nonsense. To work with WinUSB, your USB device has to indicate that WinUsb.sys is its driver. In the case of e.g. a Luminary eval board this can probably be done by making the correct .inf file or whatever (again, I'm not an expert in this). The problem I see is that all other tools using FTD2xx (like the Luminary Flash tool (I suppose)) will no longer be able to connect to the board as it is not linked to the FTD2xx driver. Does this make sense? And does this apply to libusb+libftdi as well? That's perfectly true - you have to use 2 different drivers for software based on ftd2xx.dll and WinUSB. That's why that's not so perfect... /; If you use WinUSB or libusb-win32 device driver to replace the original driver (FTDI driver), the original driver will no longer work. That is a disadvantage of using an alternative driver in place of the official driver (especially a WHQL driver). Sometimes Windows will refuse to let a driver to load to replace a WHQL driver. That is why I think to use the FTDI driver and FTD2xx DLL is still the best for Windows users in terms of ease of use. Still now that the GPL issue makes this best solution not possible (for binary distribution). Therefore the 2nd best solution for Windows user may be to get a GPL-compatible re-implementation of D2XX (or get FTDI to change the license to GPL-compatible which is more difficult IMHO). You can not based this DLL on libftdi or libusb because of the underling driver issue. After that, the solution will be to use WinUSB (or libusb-win32 1.0 if it can be released within a reasonable time frame). In this world, there is always difficult to get the best optimum solution. So we need to get working solutions first and live with the limitations. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ftd2xx - libftdi
On Friday 26 June 2009 17:15:12 Duane Ellis wrote: Zach Welch wrote: Only libusb+libftdi serves our long-term interests. Wrong. libusb is a *blocking* issue that we cannot control, fix, nor whatever. LIBUSB is not supported by *newer* windows platforms. Unless and until it is supported it becomes a dead end solution, period, end of story. I believe the WinUSB solution is a solution, that for some reason keeps being left off your list. http://msdn.microsoft.com/en-us/library/aa476426.aspx -duane. I've been investigating the Windows USB mess a little yesterday. Maybe someone can help fill in the uncertainties, here's what I have collected so far. o libusb-win32 is API compatible with libusb 0.1, but is capable of somethings that libusb 0.1 can't o libftdi apparently works with libusb-win32's API (see for example Freddie's post) o libusb-win32 comes with 3 (maybe 4) backends - a libusb driver and a libusb filter driver (not sure if this differenciation is still correct) - a HID backend (I've seen something like that with Keil's ULINK I guess, which looks like a HID to Windows, and thus needs no driver) - a WinUSB backend o libusb-win32's drivers are supposed to be a dead end because they wont work with 64-bit windows (and probably not with Windows 7), but they do work for older versions that don't have WinUSB support (particularly 2000... leaving 98/ME behind doesn't sound overly disturbing to me) o the FTDI chips are not HID, so the HID backend is dead for our purposes o the WinUSB backend brings a WHQL signed driver, which is good, because it runs on all windows versions that required signed drivers (Vista 64-bit, Windows 7) o The WinUSB How-To says that you need to get the whole driver package including the .inf file signed. Some postings to newsgroups suggest that this is not necessary. It might be that you get a warning, which shouldn't be that much of a problem. o libusb-win32's development seems sporadic if not stalled Conclusions + libusb-win32 would be good, because it works on all present windows platforms, and because it's supposed to work on upcoming versions, too + libusb-win32 would be good, because it allows us to use libftdi, which implements all the FTDI-chip specific USB communication. Using the information available in libftdi wouldn't be much of a problem, but it's certainly a lot of coding work that is mostly unrelated to OpenOCD - I have no idea about how stable and reliable libusb-win32 is o (Re-)writing libftdi with plain WinUSB should be possible and would remove the uncertainties of libusb-win32, but would burden the OpenOCD project with the task of keeping it stable and up to date. It would also leave out Windows 2000 and before. Best Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ftd2xx - libftdi
On Fri, Jun 26, 2009 at 11:56 PM, Dominicdominic.r...@gmx.de wrote: I've been investigating the Windows USB mess a little yesterday. Maybe someone can help fill in the uncertainties, here's what I have collected so far. o libusb-win32 is API compatible with libusb 0.1, but is capable of somethings that libusb 0.1 can't libusb-win32 has two development branches. libusb-win32 0.1 is API compatible with libusb 0.1 and adds isochronous transfer and asynchronous I/O support specific to Windows. o libftdi apparently works with libusb-win32's API (see for example Freddie's post) Yes. o libusb-win32 comes with 3 (maybe 4) backends - a libusb driver and a libusb filter driver (not sure if this differenciation is still correct) - a HID backend (I've seen something like that with Keil's ULINK I guess, which looks like a HID to Windows, and thus needs no driver) - a WinUSB backend This is libusb-win32 1.0 branch. Unfortunately it is not working yet and I do not know when the author will get time to get it working. Several people suggested WinUSB backend to fix Vista 64 issues. I suggested the HID backend since there are issues to use libusb-win32 with HID device. o libusb-win32's drivers are supposed to be a dead end because they wont work with 64-bit windows (and probably not with Windows 7), but they do work for older versions that don't have WinUSB support (particularly 2000... leaving 98/ME behind doesn't sound overly disturbing to me) o the FTDI chips are not HID, so the HID backend is dead for our purposes The HID backend is for other device. There are many HID based device. Typically we use native HID API to access HID device. But many programs use libusb to access HID device under Linux. o the WinUSB backend brings a WHQL signed driver, which is good, because it runs on all windows versions that required signed drivers (Vista 64-bit, Windows 7) o The WinUSB How-To says that you need to get the whole driver package including the .inf file signed. Some postings to newsgroups suggest that this is not necessary. It might be that you get a warning, which shouldn't be that much of a problem. It is ok to load the driver even though there is a warning. You can do the same with libusb-win32 device driver if somebody can pay the digital signature (not so expensive). One company already got their libusb-win32 based device driver certified by WHQL but they renamed all the driver name to their own name. o libusb-win32's development seems sporadic if not stalled You can say it is stalled right now since the SVN is 22 months old. Conclusions + libusb-win32 would be good, because it works on all present windows platforms, and because it's supposed to work on upcoming versions, too + libusb-win32 would be good, because it allows us to use libftdi, which implements all the FTDI-chip specific USB communication. Using the information available in libftdi wouldn't be much of a problem, but it's certainly a lot of coding work that is mostly unrelated to OpenOCD - I have no idea about how stable and reliable libusb-win32 is Based on my experiences it is quite good. The filter driver can cause many problems (including serious BSOD and lost of all USB device) and is no longer recommended by the author. The device driver has never caused problem for me. o (Re-)writing libftdi with plain WinUSB should be possible and would remove the uncertainties of libusb-win32, but would burden the OpenOCD project with the task of keeping it stable and up to date. It would also leave out Windows 2000 and before. You can always use libusb-win32+libftdi for Windows 2k. If possible, some people with Windows knowledge can look at the libusb-win32 1.0 branch to judge how mature (or im-mature) it is. WinUSB is a good solution with or without libusb-win32. If libusb-win32's WinUSB backend can be made to work, it is of course better since it will benefit other open source projects as well. But a WinUSB based solution specific to OpenOCD (for FTDI) device may be easier. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ftd2xx - libftdi
Original Message Subject: [Openocd-development] ftd2xx - libftdi From: Xiaofan Chen xiaof...@gmail.com To: Freddie Chopin freddie_cho...@op.pl Cc: openocd-development openocd-development@lists.berlios.de Date: Fri Jun 26 2009 17:54:25 GMT+0200 (Romance Standard Time) On Fri, Jun 26, 2009 at 11:49 PM, Freddie Chopinfreddie_cho...@op.pl wrote: Ronald Vanschoren pisze: I have only taken a quick look at WinUSB, but if I understand the concept correctly there might be an issue. I'm not sure of what I'm saying here so shout if it's complete nonsense. To work with WinUSB, your USB device has to indicate that WinUsb.sys is its driver. In the case of e.g. a Luminary eval board this can probably be done by making the correct .inf file or whatever (again, I'm not an expert in this). The problem I see is that all other tools using FTD2xx (like the Luminary Flash tool (I suppose)) will no longer be able to connect to the board as it is not linked to the FTD2xx driver. Does this make sense? And does this apply to libusb+libftdi as well? That's perfectly true - you have to use 2 different drivers for software based on ftd2xx.dll and WinUSB. That's why that's not so perfect... /; If you use WinUSB or libusb-win32 device driver to replace the original driver (FTDI driver), the original driver will no longer work. That is a disadvantage of using an alternative driver in place of the official driver (especially a WHQL driver). Sometimes Windows will refuse to let a driver to load to replace a WHQL driver. That is why I think to use the FTDI driver and FTD2xx DLL is still the best for Windows users in terms of ease of use. Still now that the GPL issue makes this best solution not possible (for binary distribution). Therefore the 2nd best solution for Windows user may be to get a GPL-compatible re-implementation of D2XX (or get FTDI to change the license to GPL-compatible which is more difficult IMHO). You can not based this DLL on libftdi or libusb because of the underling driver issue. After that, the solution will be to use WinUSB (or libusb-win32 1.0 if it can be released within a reasonable time frame). In this world, there is always difficult to get the best optimum solution. So we need to get working solutions first and live with the limitations IMHO, this makes any solution NOT based on FTD2xx unacceptable. People will not be willing to give up all their other tooling to run OpenOCD, instead they might find other solutions and stop using OpenOCD. I haven't read all the mails related to this issue, but this is new information for me at the moment. I'm not going to repeat my interpretation of GPL, you'll have to read up one of my other replies for the details, but looking at all the disadvantages of any other solution/workaround I really hope we can agree to allow distribution of FTD2xx based binaries for Windows. I agree that a GPL-compatible re-implementation is a valid solution, but really, who is going to make and more importantly maintain that? You have to test compatibility with a lot of other applications and that will cost valuable time that is better spend on improving OpenOCD. Don't underestimate the maintenance of such a driver. What if FTDI adds a feature to it's DLL? Will we reverse engineer everything and keep in sync? What's an acceptable delay to update the GPL FTD2xx version to include these updates? And there's still the WHQL thing outlined above. All messy and stressful if you ask me. I would still require the LoadLibrary patches to make OpenOCD run even if FTD2xx is not installed. Again, FTD2xx is NOT a derived work of OpenOCD so it doesn't need to be GPL'd. Adding FTD2xx support does NOT open any doors to closed source interfaces (and note that in the spirit of GPL I am against closed source interfaces). So: Who exactly is against FTD2xx based binary distributions of OpenOCD and in the face of all these downsides, isn't there anything we can do to convince you otherwise? gr. Ronald ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ftd2xx - libftdi
On Sat, Jun 27, 2009 at 12:19 AM, Ronald Vanschorenyahoogro...@lieron.be wrote: IMHO, this makes any solution NOT based on FTD2xx unacceptable. People will not be willing to give up all their other tooling to run OpenOCD, instead they might find other solutions and stop using OpenOCD. I haven't read all the mails related to this issue, but this is new information for me at the moment. I'm not going to repeat my interpretation of GPL, you'll have to read up one of my other replies for the details, but looking at all the disadvantages of any other solution/workaround I really hope we can agree to allow distribution of FTD2xx based binaries for Windows. You can easily switch between two drivers. You can use the FTDI driver together with the other tools you have. You can use the libusb-win32/WinUSB for OpenOCD. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ftd2xx - libftdi
On Sat, Jun 27, 2009 at 12:10 AM, Xiaofan Chenxiaof...@gmail.com wrote: On Fri, Jun 26, 2009 at 11:56 PM, Dominicdominic.r...@gmx.de wrote: I've been investigating the Windows USB mess a little yesterday. Maybe someone can help fill in the uncertainties, here's what I have collected so far. o libusb-win32 is API compatible with libusb 0.1, but is capable of somethings that libusb 0.1 can't libusb-win32 has two development branches. libusb-win32 0.1 is API compatible with libusb 0.1 and adds isochronous transfer and asynchronous I/O support specific to Windows. o libftdi apparently works with libusb-win32's API (see for example Freddie's post) Yes. o libusb-win32 comes with 3 (maybe 4) backends - a libusb driver and a libusb filter driver (not sure if this differenciation is still correct) - a HID backend (I've seen something like that with Keil's ULINK I guess, which looks like a HID to Windows, and thus needs no driver) - a WinUSB backend This is libusb-win32 1.0 branch. Unfortunately it is not working yet and I do not know when the author will get time to get it working. Several people suggested WinUSB backend to fix Vista 64 issues. I suggested the HID backend since there are issues to use libusb-win32 with HID device. o libusb-win32's drivers are supposed to be a dead end because they wont work with 64-bit windows (and probably not with Windows 7), but they do work for older versions that don't have WinUSB support (particularly 2000... leaving 98/ME behind doesn't sound overly disturbing to me) o the FTDI chips are not HID, so the HID backend is dead for our purposes The HID backend is for other device. There are many HID based device. Typically we use native HID API to access HID device. But many programs use libusb to access HID device under Linux. o the WinUSB backend brings a WHQL signed driver, which is good, because it runs on all windows versions that required signed drivers (Vista 64-bit, Windows 7) Just one more clarification. libusb-win32 can be made to support Vista 64bit and Windows 7 as well with a digital signature. It already works under XP 64bit. Vendors can also use libusb-win32 as their default device and get it WHQLed with their particular VID/PID if they want to do that. In that case, it will actually take precedence than the non-WHQLed FTDI driver+Vendor VID/PID combination. The FTDI WHQLed driver is for unmodified VID/PID. o The WinUSB How-To says that you need to get the whole driver package including the .inf file signed. Some postings to newsgroups suggest that this is not necessary. It might be that you get a warning, which shouldn't be that much of a problem. It is ok to load the driver even though there is a warning. You can do the same with libusb-win32 device driver if somebody can pay the digital signature (not so expensive). One company already got their libusb-win32 based device driver certified by WHQL but they renamed all the driver name to their own name. o libusb-win32's development seems sporadic if not stalled You can say it is stalled right now since the SVN is 22 months old. Conclusions + libusb-win32 would be good, because it works on all present windows platforms, and because it's supposed to work on upcoming versions, too + libusb-win32 would be good, because it allows us to use libftdi, which implements all the FTDI-chip specific USB communication. Using the information available in libftdi wouldn't be much of a problem, but it's certainly a lot of coding work that is mostly unrelated to OpenOCD - I have no idea about how stable and reliable libusb-win32 is Based on my experiences it is quite good. The filter driver can cause many problems (including serious BSOD and lost of all USB device) and is no longer recommended by the author. The device driver has never caused problem for me. o (Re-)writing libftdi with plain WinUSB should be possible and would remove the uncertainties of libusb-win32, but would burden the OpenOCD project with the task of keeping it stable and up to date. It would also leave out Windows 2000 and before. You can always use libusb-win32+libftdi for Windows 2k. If possible, some people with Windows knowledge can look at the libusb-win32 1.0 branch to judge how mature (or im-mature) it is. WinUSB is a good solution with or without libusb-win32. If libusb-win32's WinUSB backend can be made to work, it is of course better since it will benefit other open source projects as well. But a WinUSB based solution specific to OpenOCD (for FTDI) device may be easier. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ftd2xx - libftdi
On Friday 26 June 2009 18:10:56 Xiaofan Chen wrote: o libftdi apparently works with libusb-win32's API (see for example Freddie's post) Yes. o libusb-win32 comes with 3 (maybe 4) backends - a libusb driver and a libusb filter driver (not sure if this differenciation is still correct) - a HID backend (I've seen something like that with Keil's ULINK I guess, which looks like a HID to Windows, and thus needs no driver) - a WinUSB backend This is libusb-win32 1.0 branch. Unfortunately it is not working yet and I do not know when the author will get time to get it working. Several people suggested WinUSB backend to fix Vista 64 issues. I suggested the HID backend since there are issues to use libusb-win32 with HID device. Is the libusb-win32 1.0 branch compatible with libftdi (i.e. is it compatible with libusb 0.1)? o libusb-win32's drivers are supposed to be a dead end because they wont work with 64-bit windows (and probably not with Windows 7), but they do work for older versions that don't have WinUSB support (particularly 2000... leaving 98/ME behind doesn't sound overly disturbing to me) o the FTDI chips are not HID, so the HID backend is dead for our purposes The HID backend is for other device. There are many HID based device. Typically we use native HID API to access HID device. But many programs use libusb to access HID device under Linux. Not sure if I understood you correctly here - the HID backend is for HID-class devices, right? Specifically it is not for the FTDI chips? o the WinUSB backend brings a WHQL signed driver, which is good, because it runs on all windows versions that required signed drivers (Vista 64-bit, Windows 7) o The WinUSB How-To says that you need to get the whole driver package including the .inf file signed. Some postings to newsgroups suggest that this is not necessary. It might be that you get a warning, which shouldn't be that much of a problem. It is ok to load the driver even though there is a warning. Is this true for all existig and upcoming Windows versions? You can do the same with libusb-win32 device driver if somebody can pay the digital signature (not so expensive). One company already got their libusb-win32 based device driver certified by WHQL but they renamed all the driver name to their own name. You seem to know the signature and WHQL stuff. As I understand it there are at least two issues: - WHQL certification for the driver (.sys) - Signature for the driver package (.cab), including the .inf file that will need to be modified whenever we add a new VID/PID I'm not sure if WHQL certification and the driver signature are the same thing? Does digital signature mean for example a VeriSign issued signature? Would Windows accept self-signed signatures? Can we create root certificates of our own for this purpose? I dislike the idea of paying for any of this because because some of these costs might be recurring (digital signatures might expire?), and because it would mean the project would have to cover costs for mostly commercial dongles. o libusb-win32's development seems sporadic if not stalled You can say it is stalled right now since the SVN is 22 months old. Conclusions + libusb-win32 would be good, because it works on all present windows platforms, and because it's supposed to work on upcoming versions, too + libusb-win32 would be good, because it allows us to use libftdi, which implements all the FTDI-chip specific USB communication. Using the information available in libftdi wouldn't be much of a problem, but it's certainly a lot of coding work that is mostly unrelated to OpenOCD - I have no idea about how stable and reliable libusb-win32 is Based on my experiences it is quite good. The filter driver can cause many problems (including serious BSOD and lost of all USB device) and is no longer recommended by the author. The device driver has never caused problem for me. The advantage of the filter driver is that it runs in parallel with other installed drivers, e.g. FTDI's D2XX, right? o (Re-)writing libftdi with plain WinUSB should be possible and would remove the uncertainties of libusb-win32, but would burden the OpenOCD project with the task of keeping it stable and up to date. It would also leave out Windows 2000 and before. You can always use libusb-win32+libftdi for Windows 2k. Having to maintain multiple different Windows drivers puts a pretty heavy burden on the Windows packagers. If possible, some people with Windows knowledge can look at the libusb-win32 1.0 branch to judge how mature (or im-mature) it is. WinUSB is a good solution with or without libusb-win32. If libusb-win32's WinUSB backend can be made to work, it is of course better since it will benefit other open source projects as well. But a WinUSB based solution specific to OpenOCD (for FTDI) device may be easier. Regards, Dominic
Re: [Openocd-development] ftd2xx - libftdi
Original Message Subject: [Openocd-development] ftd2xx - libftdi From: Xiaofan Chen xiaof...@gmail.com To: Ronald Vanschoren yahoogro...@lieron.be Cc: openocd-development openocd-development@lists.berlios.de Date: Fri Jun 26 2009 18:30:22 GMT+0200 (Romance Standard Time) On Sat, Jun 27, 2009 at 12:19 AM, Ronald Vanschorenyahoogro...@lieron.be wrote: IMHO, this makes any solution NOT based on FTD2xx unacceptable. People will not be willing to give up all their other tooling to run OpenOCD, instead they might find other solutions and stop using OpenOCD. I haven't read all the mails related to this issue, but this is new information for me at the moment. I'm not going to repeat my interpretation of GPL, you'll have to read up one of my other replies for the details, but looking at all the disadvantages of any other solution/workaround I really hope we can agree to allow distribution of FTD2xx based binaries for Windows. You can easily switch between two drivers. You can use the FTDI driver together with the other tools you have. You can use the libusb-win32/WinUSB for OpenOCD. How do you switch? Something like Start-Setting-Control Panel-System-Hardware-Device Manager-Select Device-Right Click-Select Update Driver-Run through the whole wizard... For historic reasons I use the Luminary flash tool to get images on my board. Only thing I have to do is shutdown OpenOCD, start the tool, flash, start OpenOCD again. If I have to go through the whole driver switch every time I'll go insane... Anything else then FTD2xx will make it harder for users to use OpenOCD. gr. Ronald ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Dynamic library loading
On Friday 26 June 2009, Harald Kipp wrote: The intention of GPL is to explicitly give users the freedom to use GPL software in any way they see fit. Assuming use doesn't include depriving others of such freedoms ... that's just *ONE* of its intentions Another is to be able to *keep doing* that even in the face of, say, a manufacturer changing support policies when an OS upgrade or new model happens. Recall that one of the original motivations for the Free Software movement was hardware related: the manufacturer of a printer changed policies to remove some of those Freedoms. ISTR for example the ability to run a driver that notified about job completion, which mattered a lot to people on other floors. And that's why GPL restricts distribution of GPL software with non-Free libraries. If it didn't, then the users relying on the non-Free code would not have the full set of Freedoms intended by GPL. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Dynamic library loading
Freddie Chopin wrote: About posts by Herald and Pavel - I personally agree totally with you, but - as you've already noticed - some maintainers just don't share our point of view, and I think there is no way of convincing them - they just don't want to be convinced. Freddie, first of all many thanks that you jumped in and started this work. I'd welcome, if you finally post a patch in this list. Even if none of the maintainers commit it (which I can't imagine), it would be still of great value to many of us. Harald ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Dynamic library loading
Hello David, David Brownell napsal(a): And that's why GPL restricts distribution of GPL software with non-Free libraries. If it didn't, then the users relying on the non-Free code would not have the full set of Freedoms intended by GPL. however, here we speak about distributing binary WITHOUT non-free library. A binary which does not depend on a non-free library. If there is a free option compiled in, such binary may be used without non-free driver and thus user has CHOICE to use free or non-free driver. There is nothing wrong in distributing binary compiled for a non-free CPU (a core not released under GPL) so with all the respect to GPL, I do not understand why is it wrong to distribute binary having (beside others) just SUPPORT for a non-free hw? Another matter is a binary dependent on a non-free library, but this is not the case. Best regards, Pavel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ftd2xx - libftdi
On Sat, Jun 27, 2009 at 12:35 AM, Dominicdominic.r...@gmx.de wrote: Firstly I am not a Windows driver expert and I do not and can not code for live. But I know quite a bit of USB under Linux/Windows, especially libusb and libusb-win32. Is the libusb-win32 1.0 branch compatible with libftdi (i.e. is it compatible with libusb 0.1)? From what I know, yes. It is a development branch so things can change. For Linux, libusb 1.0 is not API compatible with libusb-0.1. Not sure if I understood you correctly here - the HID backend is for HID-class devices, right? Specifically it is not for the FTDI chips? Right. It is not for FTDI chips. o the WinUSB backend brings a WHQL signed driver, which is good, because it runs on all windows versions that required signed drivers (Vista 64-bit, Windows 7) o The WinUSB How-To says that you need to get the whole driver package including the .inf file signed. Some postings to newsgroups suggest that this is not necessary. It might be that you get a warning, which shouldn't be that much of a problem. It is ok to load the driver even though there is a warning. Yes. I do not have XP/Vista 64 but the reports confirms this. You can do the same with libusb-win32 device driver if somebody can pay the digital signature (not so expensive). One company already got their libusb-win32 based device driver certified by WHQL but they renamed all the driver name to their own name. You seem to know the signature and WHQL stuff. As I understand it there are at least two issues: - WHQL certification for the driver (.sys) - Signature for the driver package (.cab), including the .inf file that will need to be modified whenever we add a new VID/PID Rather: 1) KMCS digital signature of the core driver 2) WHQL of the driver package (including the INF file) The WIndows built-in WinUSB and usbser.sys are examples of 1. You still need an INF file to load the driver. You still need to submit the packages for WHQL. I'm not sure if WHQL certification and the driver signature are the same thing? They are not. Does digital signature mean for example a VeriSign issued signature? Would Windows accept self-signed signatures? Can we create root certificates of our own for this purpose? VeriSign is once of them. You can use only a few CAs -- you have to pay. http://www.microsoft.com/whdc/winlogo/drvsign/kmcs_walkthrough.mspx I dislike the idea of paying for any of this because because some of these costs might be recurring (digital signatures might expire?), and because it would mean the project would have to cover costs for mostly commercial dongles. It is said that you need to get the digital signature only once. This is good for libusb-win32 and many projects which use libusb-win32. WinUSB does not have this problem. Based on my experiences it is quite good. The filter driver can cause many problems (including serious BSOD and lost of all USB device) and is no longer recommended by the author. The device driver has never caused problem for me. The advantage of the filter driver is that it runs in parallel with other installed drivers, e.g. FTDI's D2XX, right? Yes. But it is more difficult to get a proper filter driver. o (Re-)writing libftdi with plain WinUSB should be possible and would remove the uncertainties of libusb-win32, but would burden the OpenOCD project with the task of keeping it stable and up to date. It would also leave out Windows 2000 and before. You can always use libusb-win32+libftdi for Windows 2k. Having to maintain multiple different Windows drivers puts a pretty heavy burden on the Windows packagers. Maybe not that bad if a proper package can be created to give the user a selection. Hope this helps. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Dynamic library loading
David Brownell wrote: On Friday 26 June 2009, Harald Kipp wrote: The intention of GPL is to explicitly give users the freedom to use GPL software in any way they see fit. Assuming use doesn't include depriving others of such freedoms ... that's just *ONE* of its intentions Another is to be able to *keep doing* that even in the face of, say, a manufacturer changing support policies when an OS upgrade or new model happens. IMHO, freedom of use doesn't mean freedom for a limited time period. Anyway, I agree without reservation. And that's why GPL restricts distribution of GPL software with non-Free libraries. If it didn't, then the users relying on the non-Free code would not have the full set of Freedoms intended by GPL. There has been no intention to distribute GPL code with non-free libraries. At least not in this thread or by any of my postings. I'd further suggest to add a note to OpenOCD, telling the user that using non-free libraries like FTD2XX may be risky and may cut free usage. Harald ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ftd2xx - libftdi
On Friday 26 June 2009 19:26:38 Xiaofan Chen wrote: Hope this helps. It does. Thanks a lot for your patience and your valuable information. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ftd2xx - libftdi
For Vista / Win7 64bit editions, driver files (.sys) must be signed to even load. Signing the .inf tells the user that the driver has gone thru some testing to insure some quality. For WinUSB, Microsoft already signed the .sys portion for us. You only have to customize the .inf. If you do not sign the .inf, you will receive a This driver has not been signed/tested/blabla by manufacturer blabla. But it will still work. Signing of .inf is not necessary, only ideal. From: Dominic dominic.r...@gmx.de To: openocd-development@lists.berlios.de Sent: Friday, 26 June, 2009 17:35:41 Subject: Re: [Openocd-development] ftd2xx - libftdi On Friday 26 June 2009 18:10:56 Xiaofan Chen wrote: o libftdi apparently works with libusb-win32's API (see for example Freddie's post) Yes. o libusb-win32 comes with 3 (maybe 4) backends - a libusb driver and a libusb filter driver (not sure if this differenciation is still correct) - a HID backend (I've seen something like that with Keil's ULINK I guess, which looks like a HID to Windows, and thus needs no driver) - a WinUSB backend This is libusb-win32 1.0 branch. Unfortunately it is not working yet and I do not know when the author will get time to get it working. Several people suggested WinUSB backend to fix Vista 64 issues. I suggested the HID backend since there are issues to use libusb-win32 with HID device. Is the libusb-win32 1.0 branch compatible with libftdi (i.e. is it compatible with libusb 0.1)? o libusb-win32's drivers are supposed to be a dead end because they wont work with 64-bit windows (and probably not with Windows 7), but they do work for older versions that don't have WinUSB support (particularly 2000... leaving 98/ME behind doesn't sound overly disturbing to me) o the FTDI chips are not HID, so the HID backend is dead for our purposes The HID backend is for other device. There are many HID based device. Typically we use native HID API to access HID device. But many programs use libusb to access HID device under Linux. Not sure if I understood you correctly here - the HID backend is for HID-class devices, right? Specifically it is not for the FTDI chips? o the WinUSB backend brings a WHQL signed driver, which is good, because it runs on all windows versions that required signed drivers (Vista 64-bit, Windows 7) o The WinUSB How-To says that you need to get the whole driver package including the .inf file signed. Some postings to newsgroups suggest that this is not necessary. It might be that you get a warning, which shouldn't be that much of a problem. It is ok to load the driver even though there is a warning. Is this true for all existig and upcoming Windows versions? You can do the same with libusb-win32 device driver if somebody can pay the digital signature (not so expensive). One company already got their libusb-win32 based device driver certified by WHQL but they renamed all the driver name to their own name. You seem to know the signature and WHQL stuff. As I understand it there are at least two issues: - WHQL certification for the driver (.sys) - Signature for the driver package (.cab), including the .inf file that will need to be modified whenever we add a new VID/PID I'm not sure if WHQL certification and the driver signature are the same thing? Does digital signature mean for example a VeriSign issued signature? Would Windows accept self-signed signatures? Can we create root certificates of our own for this purpose? I dislike the idea of paying for any of this because because some of these costs might be recurring (digital signatures might expire?), and because it would mean the project would have to cover costs for mostly commercial dongles. o libusb-win32's development seems sporadic if not stalled You can say it is stalled right now since the SVN is 22 months old. Conclusions + libusb-win32 would be good, because it works on all present windows platforms, and because it's supposed to work on upcoming versions, too + libusb-win32 would be good, because it allows us to use libftdi, which implements all the FTDI-chip specific USB communication. Using the information available in libftdi wouldn't be much of a problem, but it's certainly a lot of coding work that is mostly unrelated to OpenOCD - I have no idea about how stable and reliable libusb-win32 is Based on my experiences it is quite good. The filter driver can cause many problems (including serious BSOD and lost of all USB device) and is no longer recommended by the author. The device driver has never caused problem for me. The advantage of the filter driver is that it runs in parallel with other installed drivers, e.g. FTDI's D2XX, right? o (Re-)writing libftdi with plain WinUSB should be possible and would remove the uncertainties of libusb-win32, but would burden the OpenOCD project with the task of keeping it stable and up
Re: [Openocd-development] ftd2xx - libftdi
snip Just one more clarification. libusb-win32 can be made to support Vista 64bit and Windows 7 as well with a digital signature. It already works under XP 64bit. Vendors can also use libusb-win32 as their default device and get it WHQLed with their particular VID/PID if they want to do that. In that case, it will actually take precedence than the non-WHQLed FTDI driver+Vendor VID/PID combination. The FTDI WHQLed driver is for unmodified VID/PID. Another issue to consider: Any manufacturers that have already had their VID/PID combination signed WHQL'd (I dont know if this applies to any?), would not be able to get another driver signed and WHQL'd with the same VID/PID. They would then have to sell a FTD2XX version with one VID/PID, and a libusb version with another VID/PID. Although they are the same hardware they would not be compatible. Ian. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Dynamic library loading
Pavel Chromy escreveu: David Brownell napsal(a): And that's why GPL restricts distribution of GPL software with non-Free libraries. If it didn't, then the users relying on the non-Free code would not have the full set of Freedoms intended by GPL. however, here we speak about distributing binary WITHOUT non-free library. I believe that here is a *very important small point*: if OpenOCD uses dinamic linking to libftdxx, not a bit of non GNU software is present in the distribution. and more: no liberty os *modifying OpenOCD* is being limited. So, IMHO, dinamic linking with libftdxx is *100% GNU acceptable* Alain ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ftd2xx - libftdi
On Fri, 2009-06-26 at 11:15 -0400, Duane Ellis wrote: Zach Welch wrote: Only libusb+libftdi serves our long-term interests. Wrong. libusb is a *blocking* issue that we cannot control, fix, nor whatever. LIBUSB is not supported by *newer* windows platforms. Unless and until it is supported it becomes a dead end solution, period, end of story. I believe the WinUSB solution is a solution, that for some reason keeps being left off your list. http://msdn.microsoft.com/en-us/library/aa476426.aspx I am not ignoring it. I remember reading on another thread that WinUSB support has been added to libusb-win32 SVN? If that is true, than I have covered your option in mine, but OpenOCD will use the same API. I hope that I was not wrong in these assumptions, but I apologize if I was mistaken. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [windows + openocd] GPL implementation of libd2xx.dll ?
On Fri, 2009-06-26 at 16:32 +0200, Pavel Chromy wrote: [snip] No offense but isn't this sort of GPL madness? Yes. This is completely insane: that you would continue to ask me for advice that should be best answered by legal counsel. I am not a lawyer and cannot give you the advice that you need, but virtually everything that you saw thrown at this argument from me was received from one long ago (and I paid the bills). This community has received nothing but free advice on this topic from me, in consideration of your feelings. I am under no obligation to educate you, and I am getting increasingly frustrated by the fact that everyone seems to think they are right. Each individual must now measure my commitment to the GPL and judge how willing I am going to be to try to defend my rights in OpenOCD, in light of the understanding that I have have presented to date on this list. Please. The debate is over; legal counsel is unavoidable for you, unless you wish to demonstrate _further_ negligence. I do not care what any individual here thinks any longer; unless _you_ are licensed to practice law, you need a qualified lawyers to assess this situation and give you real advice. I have been relaying what I paid mine to tell me years ago, you are getting that knowledge for free, but it is being challenged and questioned. Fine: go pay for your own legal advice. Again, you will continue to be negligent should anyone making money from OpenOCD do anything less than this. I can assure you that they will tell you -- very clearly -- that you should try to avoid any gray areas in the GPL. You are welcome to disregard our advice in this area, but it would be taking a big risk to do so. You could be putting you long-term business interests in legal jeopardy, and I am actually helping to protect your interests in this regard. I should be thanked. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] chaining targets
Hi all, While reviewing some of the recent documentation improvements, I started thinking about daisy chaining two (or more) of my targets together into a single scan chain, allowing me to write a script that flashes each unit in turn. In theory, I think this could just work today, assuming that I could figure out how to wire things up correctly and write the script(s). From what I can tell, this setup could also allow debuggers to be attached to each target, allowing each to be debugged independently of the other... right? :) Personally, flashing would be sufficient for me in most cases, with debugging of a single target required less often. I wouldn't know what to do myself if I could debug two units at once. If the bypassed targets would not affect performance much, this seems like a good setup to use for incremental firmware development and testing of a gang of identical network devices Is anyone already doing this? If I spent the time to wire up two targets, could I expect it to work out as I have hypothesized? Any tips for handling N RTCK signals, other than my brute force use part(s) of a 7400 series IC or plain simply don't approaches? Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] chaining targets
On Friday 26 June 2009, Zach Welch wrote: Any tips for handling N RTCK signals, other than my brute force use part(s) of a 7400 series IC or plain simply don't approaches? I found some info in a TI presentation when I was searching for 1149.7 or maybe ICEpick information ... ICEPick has some RTCK smarts, and TI has some VHDL they'll send you. Apply Google... Basically, you want want RTCK(out) to be high only once *all* RTCK(i) input values are high. And then you want it to go low as soon as *any* RTCK(i) input goes low. I think there was some other nuance too; the VHDL probably captures some timing constraints, like minimum high and low times. The combine N RTCK signals issue comes up both at chip and board level integration. With a JRC, you've also got to gate each RTCK so that it's not included in the RTCK(out) computation unless it's actually part of the scan chain. - Dave p.s. Yes, most targets should just work. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] chaining targets
On Fri, 2009-06-26 at 17:04 -0700, David Brownell wrote: On Friday 26 June 2009, Zach Welch wrote: Any tips for handling N RTCK signals, other than my brute force use part(s) of a 7400 series IC or plain simply don't approaches? I found some info in a TI presentation when I was searching for 1149.7 or maybe ICEpick information ... ICEPick has some RTCK smarts, and TI has some VHDL they'll send you. Apply Google... Basically, you want want RTCK(out) to be high only once *all* RTCK(i) input values are high. And then you want it to go low as soon as *any* RTCK(i) input goes low. I think there was some other nuance too; the VHDL probably captures some timing constraints, like minimum high and low times. The combine N RTCK signals issue comes up both at chip and board level integration. With a JRC, you've also got to gate each RTCK so that it's not included in the RTCK(out) computation unless it's actually part of the scan chain. Thanks for this great explanation. Would you mind retouching the RTCK FAQ in the The User's Guide? There is already a little information there (which was not as immediately helpful as I needed it to be), and some of the details you provided here might supplement it nicely. p.s. Yes, most targets should just work. Cool. I need to do something like this to remind myself that it's possible to have some fun with these tools. :/ Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ftd2xx - libftdi
Dominic a écrit : o the WinUSB backend brings a WHQL signed driver, which is good, because it runs on all windows versions that required signed drivers (Vista 64-bit, Windows 7) Out of curiosity, do you mean to say that the driver will not load at all if not signed under vista 64 and Win 7? This would be a serious reason for me not to let IS change my system from XP. I have several very expensive pieces of software at work that are not signed but installed fine except for the annoying messages that the driver was not signed. Michel -- 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
Re: [Openocd-development] ftd2xx - libftdi
2009/6/27 Michel Catudal michelcatu...@gmail.com: Out of curiosity, do you mean to say that the driver will not load at all if not signed under vista 64 and Win 7? This would be a serious reason for me not to let IS change my system from XP. I have several very expensive pieces of software at work that are not signed but installed fine except for the annoying messages that the driver was not signed. http://www.microsoft.com/whdc/winlogo/drvsign/drvsign.mspx x64 versions of Windows Vista and Windows Server 2008 require Kernel Mode Code Signing (KMCS) in order to load kernel-mode software. More details: http://www.microsoft.com/whdc/winlogo/drvsign/kmsigning.mspx http://www.microsoft.com/whdc/winlogo/drvsign/kmcs_walkthrough.mspx Driver is part of kernel-mode software. From the above links: 'Using the F8 option. An F8 Advanced Boot Option introduced with Windows Vista—“Disable Driver Signature Enforcement”—is available to disable the kernel-signing enforcement only for the current boot session. This setting does not persist across boot sessions.' There are hacks to disable this Vista 64 feature permanently. But it is not recommended. BTW, why go for 64 bit? -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Breakpoints do not work for LM3S6918 / Eclipse
Now I have completely taken Eclipse out of the picture, and am just using openOCD and GDB 6.8. I still am stuck and no breaky points ! I am following a template that was provided, this was helpfull but is not my solution it seems. // Joe, Try adding this to your configuration file # gdb_memory_map enable # This tells openocd to inform GDB where 'flash lives' - thus GDB will attempt to use hardware breakpoints. = Specify the ELF file... = (gdb) file ./bin/basic-internalflash-project-at91sam3u-ek-at91sam3u4-flash.elf Reading symbols from /home/duane/cortex/b/basic-internalflash-project-at91sam3u-ek/basic-internalflash-project/bin/bas ic-internalflash-project-at91sam3u-ek-at91sam3u4-flash.elf...done. = Specify the target = (gdb) target remote 192.168.0.100: Remote debugging using 192.168.0.100: 0x in ?? () !! in my case (gdb) target remote localhost: = Tell openocd to HALT the target = (gdb) mon halt = Tell openocd to RESET the target. = (gdb) mon reset JTAG tap: sam3.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4) JTAG Tap/device matched = And i tell it to halt again... = (gdb) mon halt target state: halted target halted due to debug-request, current mode: Handler BusFault xPSR: 0x2105 pc: 0x000817dc = Load my program - this actually programs the flash = (gdb) load Loading section .fixed, size 0x133c lma 0x8 Loading section .relocate, size 0xf4 lma 0x8133c Start address 0x811dc, load size 5168 Transfer rate: 4 KB/sec, 2584 bytes/write. = Set a breakpoint at main() = (gdb) break main Breakpoint 1 at 0x800c0: file main.c, line 168. = Tell GDB to continue - see the NOTE from GDB... = (gdb) cont Continuing. Note: automatically using hardware breakpoints for read-only addresses. = I hit my breakpoint.. = Breakpoint 1, main () at main.c:168 168 TRACE_CONFIGURE(DBGU_STANDARD, 115200, BOARD_MCK); (gdb) = Works for me :-) = // Does not work for me, yet anyways. Please check out my attachements, incuded is 1) June26AttemptsB1.pdf== Screen shots of exactly what I sent to gdb. 2) openocdLog26B1.txt== Level 3 debug trace, for tracking communications between gdb and openOCD. 3) ConfigFiles_June26Attempt.7z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Breakpoints do not work for LM3S6918 / Eclipse
Looks like my .cfg files were in a 7zip format I will send them individually so they are more visible to more people In some cases I did not use UploadPgmAtZero.cfg when I used (gdb) load instead... Sincerley, Joe On Fri, Jun 26, 2009 at 6:39 PM, Joseph Kuss jmk.engin...@gmail.com wrote: Gmail sent without my promised attachments. Please check them out. Sincerely, Joe 1) June26AttemptsB1.pdf== Screen shots of exactly what I sent to gdb. 2) openocdLog26B1.txt== Level 3 debug trace, for communications between gdb and openOCD. 3) ConfigFiles_June26Attempt.7z == All my openOCD config files for 0.1.0 On Fri, Jun 26, 2009 at 6:32 PM, Joseph Kuss jmk.engin...@gmail.comwrote: Now I have completely taken Eclipse out of the picture, and am just using openOCD and GDB 6.8. I still am stuck and no breaky points ! I am following a template that was provided, this was helpfull but is not my solution it seems. // Joe, Try adding this to your configuration file # gdb_memory_map enable # This tells openocd to inform GDB where 'flash lives' - thus GDB will attempt to use hardware breakpoints. = Specify the ELF file... = (gdb) file ./bin/basic-internalflash-project-at91sam3u-ek-at91sam3u4-flash.elf Reading symbols from /home/duane/cortex/b/basic-internalflash-project-at91sam3u-ek/basic-internalflash-project/bin/bas ic-internalflash-project-at91sam3u-ek-at91sam3u4-flash.elf...done. = Specify the target = (gdb) target remote 192.168.0.100: Remote debugging using 192.168.0.100: 0x in ?? () !! in my case (gdb) target remote localhost: = Tell openocd to HALT the target = (gdb) mon halt = Tell openocd to RESET the target. = (gdb) mon reset JTAG tap: sam3.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4) JTAG Tap/device matched = And i tell it to halt again... = (gdb) mon halt target state: halted target halted due to debug-request, current mode: Handler BusFault xPSR: 0x2105 pc: 0x000817dc = Load my program - this actually programs the flash = (gdb) load Loading section .fixed, size 0x133c lma 0x8 Loading section .relocate, size 0xf4 lma 0x8133c Start address 0x811dc, load size 5168 Transfer rate: 4 KB/sec, 2584 bytes/write. = Set a breakpoint at main() = (gdb) break main Breakpoint 1 at 0x800c0: file main.c, line 168. = Tell GDB to continue - see the NOTE from GDB... = (gdb) cont Continuing. Note: automatically using hardware breakpoints for read-only addresses. = I hit my breakpoint.. = Breakpoint 1, main () at main.c:168 168 TRACE_CONFIGURE(DBGU_STANDARD, 115200, BOARD_MCK); (gdb) = Works for me :-) = // Does not work for me, yet anyways. Please check out my attachements, incuded is 1) June26AttemptsB1.pdf== Screen shots of exactly what I sent to gdb. 2) openocdLog26B1.txt== Level 3 debug trace, for tracking communications between gdb and openOCD. 3) ConfigFiles_June26Attempt.7z Eagle100_jtag_tiny-setup.cfg Description: Binary data DebugPgm.cfg Description: Binary data ErasePgm.cfg Description: Binary data UploadPgmAtZero.cfg Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ftd2xx - libftdi
Xiaofan Chen a écrit : 2009/6/27 Michel Catudal michelcatu...@gmail.com: Out of curiosity, do you mean to say that the driver will not load at all if not signed under vista 64 and Win 7? This would be a serious reason for me not to let IS change my system from XP. I have several very expensive pieces of software at work that are not signed but installed fine except for the annoying messages that the driver was not signed. http://www.microsoft.com/whdc/winlogo/drvsign/drvsign.mspx x64 versions of Windows Vista and Windows Server 2008 require Kernel Mode Code Signing (KMCS) in order to load kernel-mode software. More details: http://www.microsoft.com/whdc/winlogo/drvsign/kmsigning.mspx http://www.microsoft.com/whdc/winlogo/drvsign/kmcs_walkthrough.mspx Driver is part of kernel-mode software. From the above links: 'Using the F8 option. An F8 Advanced Boot Option introduced with Windows Vista—“Disable Driver Signature Enforcement”—is available to disable the kernel-signing enforcement only for the current boot session. This setting does not persist across boot sessions.' There are hacks to disable this Vista 64 feature permanently. But it is not recommended. BTW, why go for 64 bit? I don't think that they want us to move to vista 64 bit as most of the drivers for our hardware would not work but there is a point where we may be forced to move to vista or windows 7 and isn't windows 7 only 64 bits. Isn't that shit going to finally convince people that windows needs to be dumped in favor of Linux or FreeBSD? On home Linux I am switching to 64 bits now that most of it work fine. At work I have a dual boot with Ubuntu 9.04 64 bits and Windows XP 32 bits. For my embedded Linux project I decided to work from Ubuntu instead of windows. I wasn't willing to use colinux. My collegues at the France and UK branches use colinux, what the heck is that? That sounds like crap, cooperative Linux ... -- 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
Re: [Openocd-development] Breakpoints do not work for LM3S6918 / Eclipse
Continued call for help !
It still seems that these are hard to read on the posting, I will just
inline them here
1)
Eagle100_jtag_tiny-setup.cfg===
# From Source file: olimex-jtag-tiny-a.cfg
# REFERENCE: http://www.olimex.com/dev/arm-usb-tiny.html
interface ft2232
ft2232_device_desc Olimex OpenOCD JTAG TINY A
ft2232_layout olimex-jtag
#--
# From Source file: joes_Eagle100BoardTrial1.cfg--
# My test board has a Rev1 tap id.
set BSTAPID 0x16410041
# source [find target/jmk_lm3s6918.cfg] (will just include into this..)
#--
# From Source file: jmk_lm3s6918.cfg (in target directory)
# script for luminary lm3s6918
if { [info exists CHIPNAME] } {
set _CHIPNAME $CHIPNAME
} else {
set _CHIPNAME lm3s6918
}
if { [info exists ENDIAN] } {
set _ENDIAN $ENDIAN
} else {
# this defaults to a little endian
set _ENDIAN little
}
if { [info exists CPUTAPID ] } {
set _CPUTAPID $CPUTAPID
} else {
# force an error till we get a good number
set _CPUTAPID 0x3ba00477
}
# jtag speed
jtag_khz 500
jtag_nsrst_delay 100
jtag_ntrst_delay 100
#LM3S6918 Evaluation Board has only srst
reset_config srst_only
#jtag scan chain
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 1 -irmask 0xf -expected-id
$_CPUTAPID
# THIS WAS IN THE makeController-debug.cfg but is deprecated in
openOCD0.10
#daemon startup reset
#this config option has been removed, simply adding `init' and `reset halt'
to the end
#of your config script will give the same behaviour as using `daemon_startup
reset'
#and `target cortex_m3 little reset_halt 0'.
#
# the luminary variant causes a software reset rather than asserting SRST
# this stops the debug registers from being cleared
# this will be fixed in later revisions of silicon
set _TARGETNAME [format %s.cpu $_CHIPNAME]
target create $_TARGETNAME cortex_m3 -endian $_ENDIAN -chain-position
$_TARGETNAME -variant lm3s
# 4k working area at base of ram
$_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x2000
-work-area-size 0x4000 -work-area-backup 0
#flash configuration
flash bank stellaris 0 0 0 0 0
#recommded by Duane Ellis of openOCD
#This tells openocd to inform GDB where 'flash lives' - thus GDB will
attempt to#use hardware breakpoints.
#
gdb_memory_map enable
#
Eagle100_jtag_tiny-setup.cfg===
Then the following of these is sent next to openOCD:
2) DebugPgm.cfg:
telnet_port
gdb_port
init
reset
Or
3) ErasePgm.cfg
#define our ports
telnet_port
gdb_port
tcl_port
echo before init
init
halt
sleep 200
wait_halt
flash probe 0
flash erase_check 0
# This cmd below seems not to work (but it did not really matter):
# Error: failed setting protection for areas 8 to 255 (-901)
#flash protect 0 8 255 off
# But this did work:
flash erase_sector 0 0 255
sleep 200
#
flash erase_check 0
reset run
shutdown
If the chip was already programmed:
openocd -d 3 -f Eagle100_jtag_tiny-setup.cfg -f DebugPgm.cfg -l
openocdLogj26.txt
To see if gdb could directly program a blank chip - this did work.
openocd -d 3 -f Eagle100_jtag_tiny-setup.cfg -f ErasePgm.cfg -l
openocdLogErase.txt
Then I open gdb in a separate dos window.. and got stuck with no
working breakpoints as described.
Joe
On Fri, Jun 26, 2009 at 7:00 PM, Joseph Kuss jmk.engin...@gmail.com wrote:
Looks like my .cfg files were in a 7zip format I will send them
individually so they are more
visible to more people
In some cases I did not use UploadPgmAtZero.cfg when I used (gdb) load
instead...
Sincerley,
Joe
On Fri, Jun 26, 2009 at 6:39 PM, Joseph Kuss jmk.engin...@gmail.comwrote:
Gmail sent without my promised attachments.
Please check them out.
Sincerely,
Joe
1) June26AttemptsB1.pdf== Screen shots of exactly what I sent to
gdb.
2) openocdLog26B1.txt== Level 3 debug trace,
for communications between gdb and openOCD.
3) ConfigFiles_June26Attempt.7z == All my openOCD config files for
0.1.0
On Fri, Jun 26, 2009 at 6:32 PM, Joseph Kuss jmk.engin...@gmail.comwrote:
Now I have completely taken Eclipse out of the picture, and am just using
openOCD and GDB 6.8.
I still am stuck and no breaky points !
I am following a template that was provided, this was helpfull but is not
my solution it seems.
//
Joe,
Try adding this to your configuration file
#
gdb_memory_map enable
#
This tells openocd to inform GDB where 'flash lives' - thus GDB will
attempt to use hardware breakpoints.
=
Specify the ELF file...
=
(gdb) file
./bin/basic-internalflash-project-at91sam3u-ek-at91sam3u4-flash.elf
Reading symbols from
/home/duane/cortex/b/basic-internalflash-project-at91sam3u-ek/basic-internalflash-project/bin/bas
Re: [Openocd-development] ftd2xx - libftdi
2009/6/27 Michel Catudal michelcatu...@gmail.com: I don't think that they want us to move to vista 64 bit as most of the drivers for our hardware would not work but there is a point where we may be forced to move to vista or windows 7 and isn't windows 7 only 64 bits. No. Windows 7 has 32bit version as well. http://en.wikipedia.org/wiki/Windows_7 http://www.engadget.com/2009/02/03/windows-7-skus-announced-yes-your-worst-nightmare-has-come-to/2 Isn't that shit going to finally convince people that windows needs to be dumped in favor of Linux or FreeBSD? There are all kinds of reasons why Linux is not ready at many people's workplace. FreeBSD is even far away. Apple Mac OS X is closer but still not there. So the simple truth is that the switching is not going to happen any time soon, especially for work. I use mainly Linux at home since it does most of the things non-work related. But for work, XP is the one OS we are using and it works well. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] openocd.texi - various missing commands
Add various commands that had not previously been documented, which
were found courtesy of grep -r register_command:
- exit
- lpc2000 part_id
- str7x disable_jtag
- test_image
- trace history
- trace point
- version
- virt2phys
- most of the optional ioutil commands
The largest changes by volume were to describe the tracing support; then
the ioutil stuff. There are a few more undocumented commands using that
registration scheme, mostly dongle-specific commands. (Vendors, chip in!)
---
doc/openocd.texi | 162 +
1 file changed, 150 insertions(+), 12 deletions(-)
Add various commands that had not previously been documented, which
were found courtesy of grep -r register_command:
- exit
- lpc2000 part_id
- str7x disable_jtag
- test_image
- trace history
- trace point
- version
- virt2phys
- most of the optional ioutil commands
The largest changes by volume were to describe the tracing support; then
the ioutil stuff. There are a few more undocumented commands using that
registration scheme, mostly dongle-specific commands. (Vendors, chip in!)
---
doc/openocd.texi | 164 +
1 file changed, 152 insertions(+), 12 deletions(-)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -987,7 +987,9 @@ that the @code{reset-init} event handler
Likewise, the @command{arm9tdmi vector_catch} command (or
its @command{xscale vector_catch} sibling) can be a timesaver
during some debug sessions, but don't make everyone use that either.
-Keep those kinds of debugging aids in your user config file.
+Keep those kinds of debugging aids in your user config file,
+along with messaging and tracing setup.
+(@xref{Software Debug Messages and Tracing}.)
TCP/IP port configuration is another example of something which
is environment-specific, and should only appear in
@@ -1360,6 +1362,7 @@ if @{ [info exists CPUTAPID ] @} @{
set _CPUTAPID 0x3f0f0f0f
@}
@end example
+...@c but 0x3f0f0f0f is for an str73x part ...
@emph{Remember:} Board config files may include multiple target
config files, or the same target file multiple times
@@ -1473,7 +1476,7 @@ Some ARM cores are equipped with trace s
examination of the instruction and data bus activity. Trace
activity is controlled through an ``Embedded Trace Module'' (ETM)
on one of the core's scan chains. The ETM emits voluminous data
-through a ``trace port''. (@xref{ARM Tracing}.)
+through a ``trace port''. (@xref{ARM Hardware Tracing}.)
If you are using an external trace port,
configure it in your board config file.
If you are using an on-chip ``Embedded Trace Buffer'' (ETB),
@@ -3359,6 +3362,7 @@ wide on a sixteen bit bus:
flash bank cfi 0x 0x0100 2 2 $_TARGETNAME
flash bank cfi 0x0100 0x0100 2 2 $_TARGETNAME
@end example
+...@c cfi part_id disabled
@end deffn
@subsection Internal Flash (Microcontrollers)
@@ -3521,6 +3525,11 @@ LPC flashes don't require the chip and b
flash bank lpc2000 0x0 0x7d000 0 0 $_TARGETNAME \
lpc2000_v2 14765 calc_checksum
@end example
+
+...@deffn {Command} {lpc2000 part_id} bank
+Displays the four byte part identifier associated with
+the specified flash @var{bank}.
+...@end deffn
@end deffn
@deffn {Flash Driver} lpc288x
@@ -3625,6 +3634,11 @@ which is either @code{STR71x}, @code{STR
@example
flash bank str7x 0x4000 0x0004 0 0 $_TARGETNAME STR71x
@end example
+
+...@deffn Command {str7x disable_jtag} bank
+Activate the Debug/Readout protection mechanism
+for the specified flash bank.
+...@end deffn
@end deffn
@deffn {Flash Driver} str9x
@@ -4250,6 +4264,10 @@ port is .
@section Daemon Commands
+...@deffn {Command} exit
+Exits the current telnet session.
+...@end deffn
+
@deffn Command sleep msec [...@option{busy}]
Wait for at least @var{msec} milliseconds before resuming.
If @option{busy} is passed, busy-wait instead of sleeping.
@@ -4406,16 +4424,62 @@ state.
These commands are available when
OpenOCD is built with @option{--enable-ioutil}.
-They are mainly useful on embedded targets;
-PC type hosts have complementary tools.
+They are mainly useful on embedded targets,
+notably the ZY1000.
+Hosts with operating systems have complementary tools.
@emph{Note:} there are several more such commands.
+...@deffn Command append_file filename [string]*
+Appends the @var{string} parameters to
+the text file @file{filename}.
+Each string except the last one is followed by one space.
+The last string is followed by a newline.
+...@end deffn
+
+...@deffn Command cat filename
+Reads and displays the text file @file{filename}.
+...@end deffn
+
+...@deffn Command cp src_filename dest_filename
+Copies contents from the file @file{src_filename}
+into @file{dest_filename}.
+...@end deffn
+
+...@deffn Command ip
+...@emph{no description provided.}
+...@end deffn
+
+...@deffn Command ls
+...@emph{no description provided.}
+...@end deffn
+
+...@deffn Command mac
Re: [Openocd-development] ftd2xx - libftdi
On Sat, Jun 27, 2009 at 6:14 AM, Zach Welchz...@superlucidity.net wrote: On Fri, 2009-06-26 at 11:15 -0400, Duane Ellis wrote: Zach Welch wrote: Only libusb+libftdi serves our long-term interests. Wrong. libusb is a *blocking* issue that we cannot control, fix, nor whatever. LIBUSB is not supported by *newer* windows platforms. Unless and until it is supported it becomes a dead end solution, period, end of story. I believe the WinUSB solution is a solution, that for some reason keeps being left off your list. http://msdn.microsoft.com/en-us/library/aa476426.aspx I am not ignoring it. I remember reading on another thread that WinUSB support has been added to libusb-win32 SVN? If that is true, than I have covered your option in mine, but OpenOCD will use the same API. Yes that the WinUSB backend support is in the SVN which is 22 months old. I believe that the author still wants to finish it but I do not know the timeframe. On the other hand, it may be easier to create a WinUSB backend for OpenOCD which covers the needs for OpenOCD (or libftdi) and OpenOCD (or libftdi) only. You may not need to be a Windows driver developer to do this. libusb-win32 is more generic and IMHO you really need to be a good Windows driver developer to make the WinUSB backend happen. WinUSB backend will only be one of the backend for libusb-win32. WinUSB can not replace libusb-win32. For example, it can not support Win2k and it does not support isochronous transfer. WinUSB has other limitations. Here is one interesting one. I am not sure about the implications though. The following are answers from Jan Axelson. https://www.usb.org/phpbb/viewtopic.php?t=14353view=next winusb.sys supports multiple handles, but the winusb.dll API supports a single open handle. https://www.usb.org/phpbb/viewtopic.php?p=47636 I believe multiple devices are supported but not multiple handles to the same device. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ftd2xx - libftdi
On Friday 26 June 2009, Duane Ellis wrote: I believe the WinUSB solution is a solution, that for some reason keeps being left off your list. http://msdn.microsoft.com/en-us/library/aa476426.aspx Technically, I'm beginning to think that's correct. Just write directly to WinUSB instead of to the D2XX calls. But that's only part of a solution. We'd need someone to code it. And folk to shake out all the install bugs. One reason that solution sounds good to me is that the coding would be simpler than fixing the libftdi/libusb mess on MS-Windows ... and so would the install issues. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ftd2xx - libftdi
On Friday 26 June 2009, Xiaofan Chen wrote: On the other hand, it may be easier to create a WinUSB backend for OpenOCD which covers the needs for OpenOCD (or libftdi) and OpenOCD (or libftdi) only. You may not need to be a Windows driver developer to do this. Correct me if I'm wrong here: currently, the *ENTIRE* reason to care about the D2XX library is to get simpler Windows support. If that's so ... wouldn't it make the most sense just to rip out all the D2XX code, and replace it with WinUSB calls? On the plus side: no GPL worries, and simpler stories for distributors and end users. No waiting for someone to fix the holes in libusb on MS-Windows, which have already been languishing for two years. On the minus side: lose support for now-obsolete MS-Windows versions (but why care about older-than-XP?); forgoes the notion of a 100% identical programming interface (in just one file, go cry me a river); and some remove old driver stuff may need to be done. Mmm? - Dave p.s. Another plus. This is probably very doable by one person, the classic man on a mission. I've seen harder things done in less than two weeks, even with MS-Windows obstacles in the way. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ftd2xx - libftdi
David Brownell a écrit : On Friday 26 June 2009, Xiaofan Chen wrote: On the other hand, it may be easier to create a WinUSB backend for OpenOCD which covers the needs for OpenOCD (or libftdi) and OpenOCD (or libftdi) only. You may not need to be a Windows driver developer to do this. Correct me if I'm wrong here: currently, the *ENTIRE* reason to care about the D2XX library is to get simpler Windows support. Windows is not the only platform so you can't just rip that stuff off Many people still want to create their binaries with calls to D2XX library so it would not make sense to remove it. I can understand the need to get a windows binary but you don't do that by messing up the code for those who haven't crossed over or are not willing to do so. Michel -- 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
Re: [Openocd-development] ftd2xx - libftdi
On Sat, Jun 27, 2009 at 11:24 AM, David Brownelldavi...@pacbell.net wrote: On Friday 26 June 2009, Xiaofan Chen wrote: On the other hand, it may be easier to create a WinUSB backend for OpenOCD which covers the needs for OpenOCD (or libftdi) and OpenOCD (or libftdi) only. You may not need to be a Windows driver developer to do this. Correct me if I'm wrong here: currently, the *ENTIRE* reason to care about the D2XX library is to get simpler Windows support. Not so sure about the word ENTIRE. I think it certainly is the main reason. There may be people who run Linux and Mac OS X and want to use the FTDI D2XX library due to the perceived performance reasons. If that's so ... wouldn't it make the most sense just to rip out all the D2XX code, and replace it with WinUSB calls? Yes this is the way to go. I think it is better to have both possibility. On the plus side: no GPL worries, and simpler stories for distributors and end users. No waiting for someone to fix the holes in libusb on MS-Windows, which have already been languishing for two years. On the minus side: lose support for now-obsolete MS-Windows versions (but why care about older-than-XP?); forgoes the notion of a 100% identical programming interface (in just one file, go cry me a river); and some remove old driver stuff may need to be done. There are people who are still using Windows 2000, and even 98SE. As for Windows ME which even Microsoft wanted to forget, I do not know. ;-) All in all, IMHO libusb-win32+libftdi should still be a possibility for Windows users (except 64bit). And the build option of D2XX should still be kept for Windows and other users who want to build their own binary. Mmm? - Dave p.s. Another plus. This is probably very doable by one person, the classic man on a mission. I've seen harder things done in less than two weeks, even with MS-Windows obstacles in the way. I tend to agree with this. WinUSB API is relatively simple and clean from what I see. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
