-------- 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 Chopin<freddie_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
