Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
Xiaofan Chen wrote: Yes this is a possible solution. But then will you use it if you are a Vista 64 user and there is a good alternative using private build with FTD2XX? The real fix is to get libusb-win32 working on Vista 64 (with digital signing). Sure - I am all in favour of getting the 100% open-source solution working. I was just pointing out that there *is* a possible path for 64-bit Windows users that is freely distributable. The consensus here seems to be that most windows users do not want to build openocd themselves, even if it provides better performance. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
On Sat, Jun 20, 2009 at 8:05 PM, Michael Schwingenrincew...@discworld.dascon.de wrote: Zach Welch wrote: BTW: one possible solution for 64-bit windows would be to ship an openocd appliance - ie. a VM image containing a minimal linux system together with openocd libraries. Users would need to install VMware player or SUN Virtualbox to use that, but would get a clean, 100% legal and working solution without the need to compile/install anything beside the VM. With OpenOCD linked to the FTD2XX driver inside the image? That would be a GPL violation too. No, with OpenOCD linked to libusb/libftdi, running on 32-bit linux, only inside a VM. I am quite sure that *is* fully legal. Why not just offer a pre-configured linux-VM that cross-compiles for mingw or cygwin on the user's PC? Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
Michael Schwingen pisze: The consensus here seems to be that most windows users do not want to build openocd themselves, even if it provides better performance. It's not that they (we?) don't want to do something. Building OpenOCD from source on Windows using MinGW + MSYS really IS complicated. Building libusb and libftdi is even more complicated /; The process alone may not be hard (mostly configure + make), but you have to set up the environment, and that is not MinGW and MSYS alone, but like a dozen of addons (autoconf, automake and stuff like that). 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Debug from flash, with breakpts, with GDB/Eclipse/ARM-USB-TINY
On Sun, Jun 21, 2009 at 1:28 AM, Joseph Kuss jmk.engin...@gmail.com wrote: Also by the way, what do these error messages mean ?: Error: SWJ-DP STICKY ERROR Error: dcb_dhcsr 0x30003, nvic_shcsr 0x2, nvic_cfsr 0x0, nvic_bfar 0xe000edf8 On Sat, Jun 20, 2009 at 4:19 PM, Joseph Kuss jmk...@sbcglobal.net wrote: Dear sirs, I have a Luminary LM3S6918 with 64k ram, 256k flash, Has anyone been successful at running a program from flash and using Eclipse to set breakpoints. My JTAG is ARM-USB-TINY. Also I have two versions of eclipse one with Zylin embedded CDT plug in (very hard to get this package presently) Could you elaborate a bit on what you mean by this? one with GDB Hardware debugging plug ins. In both case I am not seeing breakpoints working in flash loaded program is this possible to set up ? Joe ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
Michael Bruck wrote: Why not just offer a pre-configured linux-VM that cross-compiles for mingw or cygwin on the user's PC? Because (a) that promotes linking against a non-GPL library, even if the binary is not distributed, and (b) because it still won't help on 64-bit windows. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD + libftdi on Windows
Thomas A. Moulton pisze: In the example above 114k file at 8KB/sec is 14 seconds vs 11KB/sec is 10 seconds - a difference of 4 seconds - I for one do not care and my flash is smaller than that! Indeed - flash upload speed is not the most important speed, but the stepping speed is 100% proportional to upload speed and - believe me - stepping speed matters. That's a difference when you have to wait for a step to be complete for 10 seconds or just 2. You upload a program to flash like a couple of times a day, but how many steps you make in that time? And do remember that on LPC2000 the speed decrease with libftdi is DRAMATICAL. And to answer who could be sued? Well if a business takes a non-GPL complaint tool and redistributes it, then they could be at risk. So yes the developers are right to be GPL purists, it does matter! Sued by who? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] FT2232 Windows - summary of options
As no satisfying solution has been decided I will try to summarise the options I think are fine for Windows users. Please - put away your linux windows attitude aside for a moment and do keep in mind three things before proceeding: 1. Windows users usually have no knowledgle of linux and linux tools 2. Windows users expect a software package to work out of the box 3. Windows users are not familiar with open-source and GPL ideas Because of 1. a solution with VM running OpenOCD on linux is bad, because instead of questions how to use libftdi version we will be flooded with how to use linux VM version. Because of 1. it is naive to expect more than 1% Windows user to be able to compile OpenOCD for private use. Becaue of 1. it is not a solution to distribute a VM with linux crosscompiler and apropriate scripts. Because of 2. it is bad to ship OpenOCD with libftdi which expects user to create custom drivers (there are NO libusb drivers for FT2232 posted on vendor's websites), download a hacked version of libusb0.sys and overwrite the original and so on... Because of 3. Windows users see nothing wrong in using a freely aviable ftd2xx library that is faster and supports virtual COM ports. So in reality I see only two solutions: 1. A ftd2xx.dll wrapper library, which would be published under GPL with exception for ftd2xx.dll. Such library would dynamically link ftd2xx and - as an open-source solution - could be linked with OpenOCD. This is a very good proposal made by Herald Kipp and described in detail here: https://lists.berlios.de/pipermail/openocd-development/2009-June/008265.html 2. A binary patch which would convert a libusb+libftdi based executable to ftd2xx based one. Me and Michael Fisher managed to produce such patch with bsdiff/bspatch. The patch is 30kB in size and works. Now, it's obvious that option 1 requires some work. The library has to be created and OpenOCD code has to be modified to work with that. As the libary would be a wrapper the change in OpenOCD would be merely a name replacement FT_... = OpenFT_... (or whatever name would be chosen). Before such work can be started it would be nice for anybody to comment on what Herald wrote in the post I linked above. I took some time yesterday to browse gnu.org website and I think that this solution would not violate GPL. Moreover - _maybe_ such library could also provide a method to switch ftd2xx to libftdi so that it would be up to user to decide what he/she wishes to use (libftdi and ftd2xx are more or less compatible). This way OpenOCD would not require a decision of library at compile time. The most obvious problem with that solution is that it requires time and this would not be finished until 0.2.0 (which I hope is coming soon). Maybe even a bigger problem is your attitude towards such solution... The second solution can be used right away. Nothing needs to be changed. The major concern is - will you allow a patch, patch tool and instructions to use that to be included in the installer in a folder named - for example - Non-GPL? (I'm asking this for the third time and I'd really like to hear the answer). Some will say that there is a third solution - improve libftdi and libusb to work as good ad ftd2xx. That solution is very GPL friendly, but... I think I would be able to create a wrapper library with some (a lot [; ) help, but improving libusb and libftdi code is way beyond my capabilities. I also haven't seen any volunteers that could do that job. That's why I suggest to first use the patch solution, than wrapper library while waiting for libftdi/libusb improvements, because these may be complete in a month, in a year or in ten years... Currently There are many arguments against libftdi and libusb on windows, most important of them: 1. speed, 2. no support for serial ports on the second channel, 3. lack of vendor provided drivers online, 4. no support for composite devices in published libusb code (need for hacked libusb0.sys). That's why I think that without a good solution OpenOCD is more or less dead for most of Windows users. So please - put at least half of spaces vs. tabs energy in this discussion. This way we can find a solution that is satisfactory for both parties, because now it's a win-lose in GPL vs. windows users. Or maybe you just wish to ignore Windows and it's n00b users - if that's the case, state that out loud, and we will be gone and stop bothering you with our problems. Regards! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
On Sun, Jun 21, 2009 at 3:58 PM, Freddie Chopinfreddie_cho...@op.pl wrote: It's not that they (we?) don't want to do something. Building OpenOCD from source on Windows using MinGW + MSYS really IS complicated. Building libusb and libftdi is even more complicated /; The process alone may not be hard (mostly configure + make), but you have to set up the environment, and that is not MinGW and MSYS alone, but like a dozen of addons (autoconf, automake and stuff like that). All in all, I think you are right to say that it is not so easy to expect average Windows users to build OpenOCD under Windows and there will be a lot of support issues. But here are some comments to your above assertions. Using MinGW/Msys may be complicated. But it is not that difficult to use Cygwin. Installaing Cygwin it can be an issue for average Windows users though. libusb-win32 device driver has the binary distribution. It is also very easy to build the svn version under Cygwin or MinGW/Msys. I believe you do not need the hacked libusb0.sys file. I think you just need to create the INF file for the whole device in stead of individual device. But I need to get an FT2232x based JTAG tools to prove that. Or Gene Smith can test that. Michael has a nice tutorial here on building OpenOCD with different configurations here. http://forum.sparkfun.com/viewtopic.php?t=11221 It needs some updates. 1) The FTD2XX build configuration is now changed with the latest OpenOCD SVN. $ ./configure --enable-ft2232_ftd2xx --with-ftd2xx-win32-zipdir=/home/mcuee/mcu /openocd/CDM-2.04.16 CC=gcc -mno-cygwin You need to replace /home/mcuee/mcu/openocd/CDM-2.04.16 with the unzip directory of the FTDI Windows Driver ZIP file. 2) libftdi can be build under Cygwin pretty easily. Michael's SparkFun post mentioned that there would be errors. But with the latest libftdi 0.16 version, there are no errors any more. -- 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] Will the next release 0.2.0 build on FTD2XX support?
Xiaofan Chen pisze: Using MinGW/Msys may be complicated. But it is not that difficult to use Cygwin. Installaing Cygwin it can be an issue for average Windows users though. So it's complicated anyway [; libusb-win32 device driver has the binary distribution. It is also very easy to build the svn version under Cygwin or MinGW/Msys. You need to know what to do with the created libraries - that's not a Windows kind of knowledge. I believe you do not need the hacked libusb0.sys file. I think you just need to create the INF file for the whole device in stead of individual device. But I need to get an FT2232x based JTAG tools to prove that. Or Gene Smith can test that. I've checked that now, and normal libusb0.sys seems to work fine, but you can never be sure, maybe after reset I will stop working or sth... 2) libftdi can be build under Cygwin pretty easily. Michael's SparkFun post mentioned that there would be errors. But with the latest libftdi 0.16 version, there are no errors any more. The most recent libftdi cannot be build under MSYS - the build fails, but the library is created. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
On Sun, Jun 21, 2009 at 6:00 PM, Freddie Chopinfreddie_cho...@op.pl wrote: Xiaofan Chen pisze: Using MinGW/Msys may be complicated. But it is not that difficult to use Cygwin. Installaing Cygwin it can be an issue for average Windows users though. So it's complicated anyway [; Yes Windows is complicated. ;-) Linux is actually more complicated. I consider myself power user of Windows and Linux. Other than not able to code (my biggest program ever written for work is two 2K word PIC16C72A and PIC16F872 program back in 2000-2002), I am very good at messing with the OS (using Windows since 1997 and Linux since 1998). Therefore I can build many complicated programs. But I do not expect many Windows users to be able to go through all the process. I believe you do not need the hacked libusb0.sys file. I think you just need to create the INF file for the whole device in stead of individual device. But I need to get an FT2232x based JTAG tools to prove that. Or Gene Smith can test that. I've checked that now, and normal libusb0.sys seems to work fine, but you can never be sure, maybe after reset I will stop working or sth... Glad to hear that. Try to reset the computer and see if that works. ;-) Or take a rest and wait for tomorrow and see it that still works. ;-) 2) libftdi can be build under Cygwin pretty easily. Michael's SparkFun post mentioned that there would be errors. But with the latest libftdi 0.16 version, there are no errors any more. The most recent libftdi cannot be build under MSYS - the build fails, but the library is created. Even though I like MinGW/Msys than Cygwin, it is a bit too limited. So I will take the more practical approach and use Cygwin when necessary. -- 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] Will the next release 0.2.0 build on FTD2XX support?
I've checked that now, and normal libusb0.sys seems to work fine, but you can never be sure, maybe after reset I will stop working or sth... I could not install my ftd2xx device here the normal way. I must use a composite version of the inf file. Regards, Michael -Ursprungliche Nachricht- Von: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de]im Auftrag von Freddie Chopin Gesendet: Sonntag, 21. Juni 2009 12:01 An: openocd-development Betreff: Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support? Xiaofan Chen pisze: Using MinGW/Msys may be complicated. But it is not that difficult to use Cygwin. Installaing Cygwin it can be an issue for average Windows users though. So it's complicated anyway [; libusb-win32 device driver has the binary distribution. It is also very easy to build the svn version under Cygwin or MinGW/Msys. You need to know what to do with the created libraries - that's not a Windows kind of knowledge. I believe you do not need the hacked libusb0.sys file. I think you just need to create the INF file for the whole device in stead of individual device. But I need to get an FT2232x based JTAG tools to prove that. Or Gene Smith can test that. I've checked that now, and normal libusb0.sys seems to work fine, but you can never be sure, maybe after reset I will stop working or sth... 2) libftdi can be build under Cygwin pretty easily. Michael's SparkFun post mentioned that there would be errors. But with the latest libftdi 0.16 version, there are no errors any more. The most recent libftdi cannot be build under MSYS - the build fails, but the library is created. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
On Sun, Jun 21, 2009 at 6:23 PM, Michael Fischerfische...@t-online.de wrote: I've checked that now, and normal libusb0.sys seems to work fine, but you can never be sure, maybe after reset I will stop working or sth... I could not install my ftd2xx device here the normal way. I must use a composite version of the inf file. Try this. Gene Smith confirmed that it is working. https://lists.berlios.de/pipermail/openocd-development/2009-June/008220.html libusb-win32-device-bin-0.1.12.1\binc:\windows\sys tem32\rundll32 libusb0.dll,usb_install_driver_np_rundll jtagkey.inf -- 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] Will the next release 0.2.0 build on FTD2XX support?
Hello Xiaofan, if the installer support more than FT2232 device, it must install all the driver this way. I think it is not a good idea, and the user should point to the directory where the driver exist. Like the normal way of installing driver. Regards, Michael -Ursprüngliche Nachricht- Von: Xiaofan Chen [mailto:xiaof...@gmail.com] Gesendet: Sonntag, 21. Juni 2009 12:27 An: Michael Fischer Cc: Freddie Chopin; openocd-development Betreff: Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support? On Sun, Jun 21, 2009 at 6:23 PM, Michael Fischerfische...@t-online.de wrote: I've checked that now, and normal libusb0.sys seems to work fine, but you can never be sure, maybe after reset I will stop working or sth... I could not install my ftd2xx device here the normal way. I must use a composite version of the inf file. Try this. Gene Smith confirmed that it is working. https://lists.berlios.de/pipermail/openocd-development/2009-June/008220.html libusb-win32-device-bin-0.1.12.1\binc:\windows\sys tem32\rundll32 libusb0.dll,usb_install_driver_np_rundll jtagkey.inf -- 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] Will the next release 0.2.0 build on FTD2XX support?
On Sun, Jun 21, 2009 at 6:38 PM, Xiaofan Chenxiaof...@gmail.com wrote: On Sun, Jun 21, 2009 at 6:33 PM, Michael Fischerfische...@t-online.de wrote: if the installer support more than FT2232 device, it must install all the driver this way. I think it is not a good idea, and the user should point to the directory where the driver exist. Like the normal way of installing driver. I see what you mean. Unfortunately this is sometimes the only way to install the libusb-win32 device driver based on my past experience. Windows will favor the existing WHQL based FTDI driver and refused to install the non-certified libusb-win32 driver. This is part of the complication of using libusb-win32 and libftdi under Windows. I agree with Freddie, FDT2xx is the nature choices for Windows user. The solution can be to build a binary package to automatically do this. libusb-win32 has an example of using NSIS. It is also possible to use other open source installers. http://libusb-win32.svn.sourceforge.net/viewvc/libusb-win32/trunk/libusb/examples/ http://nsis.sourceforge.net/Main_Page -- 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] Will the next release 0.2.0 build on FTD2XX support?
Hello List, an hacked version of libusb0.sys is not needed anymore. With the hacked version it is still not allowed to distribute it because how should the user create the hacked version? I could build a libusb driver based on SVN trunk version 161, under MinGW. The drivers version is 1.0.0.0. This driver will support the setting of composite devices in the inf file. Unfortunately I could only build the x32 verison and no x64. Btw, this will not solve the need of the FTD2XX, but now we can distribute a libusb composite version. Best regards, Michael -Ursprüngliche Nachricht- Von: Xiaofan Chen [mailto:xiaof...@gmail.com] Gesendet: Sonntag, 21. Juni 2009 12:46 An: Michael Fischer Cc: Freddie Chopin; openocd-development Betreff: Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support? On Sun, Jun 21, 2009 at 6:38 PM, Xiaofan Chenxiaof...@gmail.com wrote: On Sun, Jun 21, 2009 at 6:33 PM, Michael Fischerfische...@t-online.de wrote: if the installer support more than FT2232 device, it must install all the driver this way. I think it is not a good idea, and the user should point to the directory where the driver exist. Like the normal way of installing driver. I see what you mean. Unfortunately this is sometimes the only way to install the libusb-win32 device driver based on my past experience. Windows will favor the existing WHQL based FTDI driver and refused to install the non-certified libusb-win32 driver. This is part of the complication of using libusb-win32 and libftdi under Windows. I agree with Freddie, FDT2xx is the nature choices for Windows user. The solution can be to build a binary package to automatically do this. libusb-win32 has an example of using NSIS. It is also possible to use other open source installers. http://libusb-win32.svn.sourceforge.net/viewvc/libusb-win32/trunk/libusb/exa mples/ http://nsis.sourceforge.net/Main_Page -- 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] Will the next release 0.2.0 build on FTD2XX support?
On Sun, Jun 21, 2009 at 7:08 PM, Michael Fischerfische...@t-online.de wrote: Hello List, an hacked version of libusb0.sys is not needed anymore. With the hacked version it is still not allowed to distribute it because how should the user create the hacked version? I could build a libusb driver based on SVN trunk version 161, under MinGW. The drivers version is 1.0.0.0. This driver will support the setting of composite devices in the inf file. Unfortunately I could only build the x32 verison and no x64. Btw, this will not solve the need of the FTD2XX, but now we can distribute a libusb composite version. That is great. I can help build the 64bit version of libusb-win32 svn version and send it to you later. You can also try to build it by yourself. 1) You can download the old DDK version here. http://www.microsoft.com/whdc/devtools/ddk/default.mspx 2) You can get latest WDK here. You need to use Microsoft Connect. http://www.microsoft.com/whdc/DevTools/WDK/WDKpkg.mspx -- 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] Add config for CS351x CPUs
Adds configuration for Cortina Systems CS351x CPUs.
They are based on FA526 core.
Index: tcl/target/cs351x.cfg
===
--- tcl/target/cs351x.cfg (revision 0)
+++ tcl/target/cs351x.cfg (revision 0)
@@ -0,0 +1,30 @@
+if { [info exists CHIPNAME] } {
+ set _CHIPNAME $CHIPNAME
+} else {
+ set _CHIPNAME cs351x
+}
+
+if { [info exists ENDIAN] } {
+ set _ENDIAN $ENDIAN
+} else {
+ set _ENDIAN little
+}
+
+if { [info exists CPUTAPID ] } {
+ set _CPUTAPID $CPUTAPID
+} else {
+ set _CPUTAPID 0x00526fa1
+}
+
+jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id
$_CPUTAPID
+
+# Create the GDB Target.
+set _TARGETNAME [format %s.cpu $_CHIPNAME]
+target create $_TARGETNAME fa526 -endian $_ENDIAN -chain-position $_TARGETNAME
-variant fa526
+# There is 16K of SRAM on this chip
+# FIXME: flash programming is not working by using this work area. So comment
this out for now.
+#$_TARGETNAME configure -work-area-virt 0x -work-area-phys 0x
-work-area-size 0x4000 -work-area-backup 1
+
+# This chip has a DCC ... use it
+arm7_9 dcc_downloads enable
+
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
On Sun, Jun 21, 2009 at 7:15 PM, Xiaofan Chenxiaof...@gmail.com wrote: On Sun, Jun 21, 2009 at 7:08 PM, Michael Fischerfische...@t-online.de wrote: Hello List, an hacked version of libusb0.sys is not needed anymore. With the hacked version it is still not allowed to distribute it because how should the user create the hacked version? I could build a libusb driver based on SVN trunk version 161, under MinGW. The drivers version is 1.0.0.0. This driver will support the setting of composite devices in the inf file. Unfortunately I could only build the x32 verison and no x64. Btw, this will not solve the need of the FTD2XX, but now we can distribute a libusb composite version. That is great. I can help build the 64bit version of libusb-win32 svn version and send it to you later. You can also try to build it by yourself. 1) You can download the old DDK version here. http://www.microsoft.com/whdc/devtools/ddk/default.mspx 2) You can get latest WDK here. You need to use Microsoft Connect. http://www.microsoft.com/whdc/DevTools/WDK/WDKpkg.mspx The moot point is that the 64bit libusb-win32 driver is only working under Windows XP 64 bit which does not have many users. It is not working under Vista 64 without some hacking. And I am not sure if OpenOCD built with MinGW can be used with the driver built with DDK/WDK (using compiler similar to Visual C++) for XP 64. I am not sure we can build OpenOCD with Visual C++ as of now. Moreover, I do not have XP 64 or Vista 64 to test it. So I guess it is better not to distribute 64bit libusb-win32 driver. -- 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] [patch 3/5] beagle config file updates
David Brownell wrote: On Friday 19 June 2009, Dirk Behme wrote: Seems to work :) THANKS!! Good. I look forward to seeing more things start to work there ... and the next release after 0.2.0 having some support for Cortex-A8! :) Don't hesitate to send everything you like to get tested :) Best regards Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
Moreover, I do not have XP 64 or Vista 64 to test it. So I guess it is better not to distribute 64bit libusb-win32 driver. We do not want to distribute libusb, we want to distribute OpenOCD. And here libftdi is not working under 64 bit, is this correct? Regards, Michael -Ursprüngliche Nachricht- Von: Xiaofan Chen [mailto:xiaof...@gmail.com] Gesendet: Sonntag, 21. Juni 2009 13:55 An: Michael Fischer Cc: Freddie Chopin; openocd-development Betreff: Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support? On Sun, Jun 21, 2009 at 7:15 PM, Xiaofan Chenxiaof...@gmail.com wrote: On Sun, Jun 21, 2009 at 7:08 PM, Michael Fischerfische...@t-online.de wrote: Hello List, an hacked version of libusb0.sys is not needed anymore. With the hacked version it is still not allowed to distribute it because how should the user create the hacked version? I could build a libusb driver based on SVN trunk version 161, under MinGW. The drivers version is 1.0.0.0. This driver will support the setting of composite devices in the inf file. Unfortunately I could only build the x32 verison and no x64. Btw, this will not solve the need of the FTD2XX, but now we can distribute a libusb composite version. That is great. I can help build the 64bit version of libusb-win32 svn version and send it to you later. You can also try to build it by yourself. 1) You can download the old DDK version here. http://www.microsoft.com/whdc/devtools/ddk/default.mspx 2) You can get latest WDK here. You need to use Microsoft Connect. http://www.microsoft.com/whdc/DevTools/WDK/WDKpkg.mspx The moot point is that the 64bit libusb-win32 driver is only working under Windows XP 64 bit which does not have many users. It is not working under Vista 64 without some hacking. And I am not sure if OpenOCD built with MinGW can be used with the driver built with DDK/WDK (using compiler similar to Visual C++) for XP 64. I am not sure we can build OpenOCD with Visual C++ as of now. Moreover, I do not have XP 64 or Vista 64 to test it. So I guess it is better not to distribute 64bit libusb-win32 driver. -- 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] Will the next release 0.2.0 build on FTD2XX support?
On Sun, Jun 21, 2009 at 8:02 PM, Michael Fischerfische...@t-online.de wrote: Moreover, I do not have XP 64 or Vista 64 to test it. So I guess it is better not to distribute 64bit libusb-win32 driver. We do not want to distribute libusb, we want to distribute OpenOCD. And here libftdi is not working under 64 bit, is this correct? I am sure libusb-win32 will not work under Vista 64 bit (without some hacking) and thus libftdi/OpenOCD will not work under Vista 64. I am not 100% sure about XP 64 situation. libusb-win32 works under XP 64. I am not sure about libftdi and OpenOCD. The DDK/WDK build of libusb-win32 will create libusb.lib (for Visual C++) and not libusb.a (for gcc). In the end, XP64/Vista64 users are better served by the private build using FTD2XX. -- 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] Will the next release 0.2.0 build on FTD2XX support?
On Sun, Jun 21, 2009 at 5:45 PM, Xiaofan Chenxiaof...@gmail.com wrote: Michael has a nice tutorial here on building OpenOCD with different configurations here. http://forum.sparkfun.com/viewtopic.php?t=11221 It needs some updates. Michael Fischer has since updated the instruction and he tested it with OpenOCD SVN2348 and the updated build instruction works. I also tried to build SVN2348 and I can build both the FTD2xx version and libftdi version using his instruction. The remaining update to be done is the instruction to install the libusb-win32 driver. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] FT2232 Windows - summary of options
Hello List, No response, no windows user here which need FTD2XX support? Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 Windows - summary of options
On Sun, 2009-06-21 at 15:00 +0200, Michael Fischer wrote: Hello List, No response, no windows user here which need FTD2XX support? Best regards, Michael Well 2 points come to mind... 1 - as pointed out before, most of us windows users are interested in plug and play 2 - this is a developers list... (svn commits and all) so it is not likely we know we need it... now... if the question is: Can we live without Serial Port support I would say maybe... but then again I am only needing production flash programming, not debugging, so I can only speak for a small minority. tom ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
On Sun, Jun 21, 2009 at 7:08 PM, Michael Fischerfische...@t-online.de wrote: Hello List, an hacked version of libusb0.sys is not needed anymore. With the hacked version it is still not allowed to distribute it because how should the user create the hacked version? I could build a libusb driver based on SVN trunk version 161, under MinGW. The drivers version is 1.0.0.0. This driver will support the setting of composite devices in the inf file. Unfortunately I could only build the x32 verison and no x64. Btw, this will not solve the need of the FTD2XX, but now we can distribute a libusb composite version. Oops, I forgot to mention that libusb-win32 1.0 SVN branch (named libusb1) is not working yet. So your version 1.0.0.0 is not ready yet. You should build the 0.1 branch (named libusb). There are two branches here: http://libusb-win32.svn.sourceforge.net/viewvc/libusb-win32/trunk/ The libusb branch is the stable branch and should work. DLL version:0.1.12.1 Driver version: 0.1.12.1 The libusb1 branch is the development branch and has WinUSB and HID backend along with the libusb-win32 device driver backend. But it is not working as far as I know. DLL version:1.0.0.0 Driver version: -1.-1.-1.-1 -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Universal ft2232 .inf file for windows/libusb-win32
I attach a patch which adds a universal .inf file for FT2232 based JTAGs
to the tree in \contrib\libusb-win32_ft2232_driver\. Currently it has 3
different devices inside:
- normal FT2232
- Amontec JTAGkey
- Egnite Turtelizer 2
Of course some more devices should be added to make that truly
universal, that's why I suggest putting that in the tree, so that
anyone could add more devices to that file.
I don't know if the path that I've chosen is good - if not I'm open to
suggestions [;
If you don't think it should be included in the tree - tell me, I'll
just post the file as an attachment as a reference for others.
4\/3!!
Index: contrib/libusb-win32_ft2232_driver/libusb-win32_ft2232_driver.inf
===
--- contrib/libusb-win32_ft2232_driver/libusb-win32_ft2232_driver.inf
(revision 0)
+++ contrib/libusb-win32_ft2232_driver/libusb-win32_ft2232_driver.inf
(revision 0)
@@ -0,0 +1,165 @@
+[Version]
+Signature = $Chicago$
+provider = %manufacturer%
+DriverVer = 03/20/2007,0.1.12.1
+CatalogFile = libusb-win32_ft2232_driver.cat
+CatalogFile.NT = libusb-win32_ft2232_driver.cat
+CatalogFile.NTAMD64 = libusb-win32_ft2232_driver_x64.cat
+
+Class = LibUsbDevices
+ClassGUID = {EB781AAF-9C70-4523-A5DF-642A87ECA567}
+
+[ClassInstall]
+AddReg=libusb_class_install_add_reg
+
+[ClassInstall32]
+AddReg=libusb_class_install_add_reg
+
+[libusb_class_install_add_reg]
+HKRLibUSB-Win32 Devices
+HKR,,Icon,,-20
+
+[Manufacturer]
+%manufacturer%=Devices,NT,NTAMD64
+
+;--
+; Files
+;--
+
+[SourceDisksNames]
+1 = Libusb-Win32 Driver Installation Disk,,
+
+[SourceDisksFiles]
+libusb0.sys = 1,,
+libusb0.dll = 1,,
+libusb0_x64.sys = 1,,
+libusb0_x64.dll = 1,,
+
+[DestinationDirs]
+libusb_files_sys = 10,system32\drivers
+libusb_files_sys_x64 = 10,system32\drivers
+libusb_files_dll = 10,system32
+libusb_files_dll_wow64 = 10,syswow64
+libusb_files_dll_x64 = 10,system32
+
+[libusb_files_sys]
+libusb0.sys
+
+[libusb_files_sys_x64]
+libusb0.sys,libusb0_x64.sys
+
+[libusb_files_dll]
+libusb0.dll
+
+[libusb_files_dll_wow64]
+libusb0.dll
+
+[libusb_files_dll_x64]
+libusb0.dll,libusb0_x64.dll
+
+;--
+; Device driver
+;--
+
+[LIBUSB_DEV]
+CopyFiles = libusb_files_sys, libusb_files_dll
+AddReg= libusb_add_reg
+
+[LIBUSB_DEV.NT]
+CopyFiles = libusb_files_sys, libusb_files_dll
+
+[LIBUSB_DEV.NTAMD64]
+CopyFiles = libusb_files_sys_x64, libusb_files_dll_wow64, libusb_files_dll_x64
+
+[LIBUSB_DEV.HW]
+DelReg = libusb_del_reg_hw
+AddReg = libusb_add_reg_hw
+
+[LIBUSB_DEV.NT.HW]
+DelReg = libusb_del_reg_hw
+AddReg = libusb_add_reg_hw
+
+[LIBUSB_DEV.NTAMD64.HW]
+DelReg = libusb_del_reg_hw
+AddReg = libusb_add_reg_hw
+
+[LIBUSB_DEV.NT.Services]
+AddService = libusb0, 0x0002, libusb_add_service
+
+[LIBUSB_DEV.NTAMD64.Services]
+AddService = libusb0, 0x0002, libusb_add_service
+
+[libusb_add_reg]
+HKR,,DevLoader,,*ntkern
+HKR,,NTMPDriver,,libusb0.sys
+
+; Older versions of this .inf file installed filter drivers. They are not
+; needed any more and must be removed
+[libusb_del_reg_hw]
+HKR,,LowerFilters
+HKR,,UpperFilters
+
+; Device properties
+[libusb_add_reg_hw]
+HKR,,SurpriseRemovalOK, 0x00010001, 1
+
+;--
+; Services
+;--
+
+[libusb_add_service]
+DisplayName= LibUsb-Win32 - Kernel Driver 03/20/2007, 0.1.12.1
+ServiceType= 1
+StartType = 3
+ErrorControl = 0
+ServiceBinary = %12%\libusb0.sys
+
+;--
+; Devices
+;--
+
+[Devices]
+FTDI FT2232=LIBUSB_DEV, USB\VID_0403PID_6001
+FTDI FT2232 (Channel A)=LIBUSB_DEV, USB\VID_0403PID_6001MI_00
+FTDI FT2232 (Channel B)=LIBUSB_DEV, USB\VID_0403PID_6001MI_01
+
+Amontec JTAGkey=LIBUSB_DEV, USB\VID_0403PID_cff8
+Amontec JTAGkey (Channel A)=LIBUSB_DEV, USB\VID_0403PID_cff8MI_00
+Amontec JTAGkey (Channel B)=LIBUSB_DEV, USB\VID_0403PID_cff8MI_01
+
+Egnite Turtelizer 2=LIBUSB_DEV, USB\VID_0403PID_bdc8
+Egnite Turtelizer 2 (Channel A)=LIBUSB_DEV, USB\VID_0403PID_bdc8MI_00
+Egnite Turtelizer 2 (Channel B)=LIBUSB_DEV, USB\VID_0403PID_bdc8MI_01
+
+[Devices.NT]
+FTDI FT2232=LIBUSB_DEV, USB\VID_0403PID_6001
+FTDI FT2232 (Channel A)=LIBUSB_DEV, USB\VID_0403PID_6001MI_00
+FTDI FT2232 (Channel B)=LIBUSB_DEV, USB\VID_0403PID_6001MI_01
+
+Amontec JTAGkey=LIBUSB_DEV, USB\VID_0403PID_cff8
+Amontec JTAGkey (Channel A)=LIBUSB_DEV, USB\VID_0403PID_cff8MI_00
+Amontec JTAGkey (Channel B)=LIBUSB_DEV, USB\VID_0403PID_cff8MI_01
+
+Egnite Turtelizer 2=LIBUSB_DEV,
Re: [Openocd-development] FT2232 Windows - summary of options
On Sun, Jun 21, 2009 at 5:28 PM, Freddie Chopinfreddie_cho...@op.pl wrote: So in reality I see only two solutions: 1. A ftd2xx.dll wrapper library, which would be published under GPL with exception for ftd2xx.dll. Such library would dynamically link ftd2xx and - as an open-source solution - could be linked with OpenOCD. This is a very good proposal made by Herald Kipp and described in detail here: https://lists.berlios.de/pipermail/openocd-development/2009-June/008265.html 2. A binary patch which would convert a libusb+libftdi based executable to ftd2xx based one. Me and Michael Fisher managed to produce such patch with bsdiff/bspatch. The patch is 30kB in size and works. Here is my two cents as a non-developer and as a OS neutral guy. I think Option 2 is the best if it does not fail to comply with GPL. Again I am not a lawyer. Option 1 is also acceptable if the license holders think it is ok. These two options are not as good as re-licensing but I guess idea of re-licensing (GPL with FTD2xx exception) is already killed by some prominent developers. The developers really need to chime in and express their opinions. -- 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] Universal ft2232 .inf file for windows/libusb-win32
2009/6/21 Freddie Chopin freddie_cho...@op.pl: I attach a patch which adds a universal .inf file for FT2232 based JTAGs to the tree in \contrib\libusb-win32_ft2232_driver\. Currently it has 3 different devices inside: - normal FT2232 - Amontec JTAGkey - Egnite Turtelizer 2 Of course some more devices should be added to make that truly universal, that's why I suggest putting that in the tree, so that anyone could add more devices to that file. I don't know if the path that I've chosen is good - if not I'm open to suggestions [; If you don't think it should be included in the tree - tell me, I'll just post the file as an attachment as a reference for others. If it works, it should be included. Have you tried this with all of the three JTAG tools? It seems to me that you are using libusb-win32 with individual interfaces and I am not sure that would work. Do you used the hacked libusb0.sys? -- 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] Will the next release 0.2.0 build on FTD2XX support?
Hi Xiaofan, many thanks for this hint. The 1.0.0.0 was not working here with OpenOCD. The libusb build based on 0.1.12.1 is working now. But this is the same version which the user can download from sourcefore. Perhaps someone should create a 0.1.12.2 for using with OpenOCD? Regards, Michael -Ursprüngliche Nachricht- Von: Xiaofan Chen [mailto:xiaof...@gmail.com] Gesendet: Sonntag, 21. Juni 2009 16:59 An: Michael Fischer Cc: Freddie Chopin; openocd-development Betreff: Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support? On Sun, Jun 21, 2009 at 7:08 PM, Michael Fischerfische...@t-online.de wrote: Hello List, an hacked version of libusb0.sys is not needed anymore. With the hacked version it is still not allowed to distribute it because how should the user create the hacked version? I could build a libusb driver based on SVN trunk version 161, under MinGW. The drivers version is 1.0.0.0. This driver will support the setting of composite devices in the inf file. Unfortunately I could only build the x32 verison and no x64. Btw, this will not solve the need of the FTD2XX, but now we can distribute a libusb composite version. Oops, I forgot to mention that libusb-win32 1.0 SVN branch (named libusb1) is not working yet. So your version 1.0.0.0 is not ready yet. You should build the 0.1 branch (named libusb). There are two branches here: http://libusb-win32.svn.sourceforge.net/viewvc/libusb-win32/trunk/ The libusb branch is the stable branch and should work. DLL version:0.1.12.1 Driver version: 0.1.12.1 The libusb1 branch is the development branch and has WinUSB and HID backend along with the libusb-win32 device driver backend. But it is not working as far as I know. DLL version:1.0.0.0 Driver version: -1.-1.-1.-1 -- 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] Will the next release 0.2.0 build on FTD2XX support?
On Sun, Jun 21, 2009 at 11:20 PM, Michael Fischerfische...@t-online.de wrote: many thanks for this hint. The 1.0.0.0 was not working here with OpenOCD. The libusb build based on 0.1.12.1 is working now. But this is the same version which the user can download from sourcefore. Perhaps someone should create a 0.1.12.2 for using with OpenOCD? The SVN version is slightly updated than the released 0.1.12.1 even though the version number is the same. Did you try the released version of libusb-win32 which is 0.1.12.1. I think it should work as well. -- 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] Universal ft2232 .inf file for windows/libusb-win32
Xiaofan Chen pisze: Have you tried this with all of the three JTAG tools? Nope [; I only have JTAGkey here, but the only difference visible to drivers is the VID/PID combination [; It seems to me that you are using libusb-win32 with individual interfaces and I am not sure that would work. It works for me - I can install the drivers and OpenOCD compiled with libftdi support is able to communicate with the core. Do you used the hacked libusb0.sys? Currently no, but I was using that a while ago, so I'm not sure whether it's not loaded in the RAM or something. I can upload openocd executable with libftdi support somewhere and post a download link for others to test. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
Did you try the released version of libusb-win32 which is 0.1.12.1. I think it should work as well. This was the version I used at the beginning. And here I need the hacked version from the page I send the info about the composite devices. Regards, Michael -Ursprüngliche Nachricht- Von: Xiaofan Chen [mailto:xiaof...@gmail.com] Gesendet: Sonntag, 21. Juni 2009 17:24 An: Michael Fischer Cc: Freddie Chopin; openocd-development Betreff: Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support? On Sun, Jun 21, 2009 at 11:20 PM, Michael Fischerfische...@t-online.de wrote: many thanks for this hint. The 1.0.0.0 was not working here with OpenOCD. The libusb build based on 0.1.12.1 is working now. But this is the same version which the user can download from sourcefore. Perhaps someone should create a 0.1.12.2 for using with OpenOCD? The SVN version is slightly updated than the released 0.1.12.1 even though the version number is the same. Did you try the released version of libusb-win32 which is 0.1.12.1. I think it should work as well. -- 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] Universal ft2232 .inf file for windows/libusb-win32
Xiaofan Chen pisze: It seems to me that you are using libusb-win32 with individual interfaces and I am not sure that would work. I'm not sure I understand you correctly, but if there are no entries for individual channels (...MI_00 and ...MI_01) OpenOCD doesn't work. I think that the master entry (the one without the channel info) is not required, but that has to be tested. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Universal ft2232 .inf file forwindows/libusb-win32
Hello Freddie, what is the md5sum from your libusb0.sys file under: \windows\system32\drivers The original file from the binary distribution libusb-win32-device-bin-0.1.12.1 is: 34d6730e198a5b0fce0790a6b4769ef2 *libusb0.sys Regards, Michael -Ursprungliche Nachricht- Von: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de]im Auftrag von Freddie Chopin Gesendet: Sonntag, 21. Juni 2009 17:26 An: openocd-development Betreff: Re: [Openocd-development] Universal ft2232 .inf file forwindows/libusb-win32 Xiaofan Chen pisze: Have you tried this with all of the three JTAG tools? Nope [; I only have JTAGkey here, but the only difference visible to drivers is the VID/PID combination [; It seems to me that you are using libusb-win32 with individual interfaces and I am not sure that would work. It works for me - I can install the drivers and OpenOCD compiled with libftdi support is able to communicate with the core. Do you used the hacked libusb0.sys? Currently no, but I was using that a while ago, so I'm not sure whether it's not loaded in the RAM or something. I can upload openocd executable with libftdi support somewhere and post a download link for others to test. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Universal ft2232 .inf file forwindows/libusb-win32
Michael Fischer pisze: what is the md5sum from your libusb0.sys file under: \windows\system32\drivers The original file from the binary distribution libusb-win32-device-bin-0.1.12.1 is: 34d6730e198a5b0fce0790a6b4769ef2 *libusb0.sys 880e67f337c7940d3a3b9b843300a6a4 *libusb0.sys ... uuups [; It seems that there has been a little mess-up in my system : Sorry for my mistake! So I've uninstalled the drivers, restarted my PC, deleted all libusb0.sys variations from the system32/drivers/ and installed the drivers again. Now there is a clean version of libusb0.sys. I've installed two drivers - for channel A and channel B. OpenOCD is not working... So - I keep my previous statements - you NEED a hacked version of libusb0.sys. Yesterday I was installing just the master driver - without the channel a and channel b stuff, and it wasn't working too. Replacing libusb0.sys fixes the problem - OpenOCD works. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Universal ft2232 .inf fileforwindows/libusb-win32
Michael Fischer pisze: here is the driver which was build from the SVN r161 (libusb). Please test it, it should work with composite devices too. Works here. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 Windows - summary of options
Should we take silence as an agreement? That's pretty interesting - so many posts about such insignificant cases like whitespaces or type-names, so little posts about such significant case as ftd2xx... 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 Windows - summary of options
On Sun, Jun 21, 2009 at 6:30 PM, Freddie Chopinfreddie_cho...@op.pl wrote: Should we take silence as an agreement? No. (Wasn't this summary posted yesterday?) This debate is still alive, give the community time to consider the options and come up with ideas. I haven't followed this debate terribly closely, I'm just waiting for the dust to settle. A few things appear to be clear at this point: - OpenOCD was, is and will remain GPL. Maintainers of OpenOCD will not encourage or facilitate methods to breach or circumvent GPL. - Prior violations are irrelevant and when such violations are discovered, then efforts by maintainers will start to immediatly stop violating GPL. Even if this affects current users and there is no short term solution. - Method of linking is irrelevant according to GPL and more importantly by several of the maintainers/contributors. - There are viable technical alternatives that resolve these issues without violating GPL, but they take work. As always: discussions and patches are greatly appreciated. I don't know the details, but I suspect these issues will be resolved in a month or two from what I skimmed through. (I'm not working on USB stuff so I don't know much about the technical details) -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 Windows - summary of options
On Jun 21, 2009, at 9:30 AM, Freddie Chopin freddie_cho...@op.pl wrote: Should we take silence as an agreement? Of course not. That's pretty interesting - so many posts about such insignificant cases like whitespaces or type-names, so little posts about such significant case as ftd2xx... Personally I don't use windows, but I do maintain the code and fix bugs. Thus D2xx is insignificant to me while code style and type-names make a large impact on my day to day. My commentary is provided accordingly. That and I find license issues to be annoying especially when the authors knowingly chose a license that is unnecessarily complex and restrictive. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] amtjtagaccel reports incorrect chip ID's
First I want to say that I am very happy with the OpenOCD-software! I like it very much. I have a Chameleon POD from Amontec. This dongle can be programmed to act as a Wiggler-cable, but also as a JTAG Accelerator interface. I use it in combination with an ARM processor and a FPGA. Both are supplied by Propox. When I use the Wiggler JTAG interface, I get the following information: Info : JTAG tap: at91sam9260.cpu tap/device found: 0x0792603f (Manufacturer: 0x01f, Part: 0x7926, Version: 0x0) When I use the Amontec JTAG Accelerator Interface, I get the following information: Info : JTAG tap: at91sam9260.cpu tap/device found: 0x03c9301f (Manufacturer: 0x00f, Part: 0x3c93, Version: 0x0) It looks like the whole word is shifted 1 bit. I think the Wiggler interface is correct. I also tried my FPGA module and got the following ID's: Manuf. Chipwiggler amtjtagaccel Processor: Atmel AT91SAM9260 0x0792603f 0x03c9301f Platform Flash: Xilinx XCF01S 0xF5044093 0x7A822049 FPGA: Xilinx XC3S200 0x01414093 0x80A0A049 The ID of the FPGA is not only shifted 1 bit to the right, but is also OR-ed with 0x8000 The wiggler ID is correct Can you correct this? Kind regards, Ferdinand Postema (The Netherlands) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 Windows - summary of options
On Sunday 21 June 2009, Xiaofan Chen wrote: Maybe you can create a new poll there for the FTD2XX support. I think the Windows users will need the FTD2XX support. It is not that easy to get OpenOCD+libusb-win32+libftdi working under Windows after all. To repeat: anyone wanting D2XX support must build it themselves. But we have to respect the copyright owners and GPL as well. I was hoping more core developers can chime in and state their opinions but most of them seem to choose to keep silent. All of them have *ALREADY* spoken by submitting under the terms of the GNU GPL. There's nothing more that needs to be said. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 Windows - summary of options
On Sun, Jun 21, 2009 at 4:00 PM, Michael Fischerfische...@t-online.de wrote: Hello List, No response, no windows user here which need FTD2XX support? I am Windows user, and I do need FTD2xx support, unless GPL-compatible alternatives allows dual inteface (I use Olimex ARM-USB-OCD and I appreciate it having serial port besides JTAG). I use a notebook that lacks serial ports and is short of USBs. I, although having experience with linux and it's tools, also prefer plug'n'play software behaviour due to very limited time constraints - I prefer spending time to develop software for my targets than spending hours trying to figure how to install tools. While I endorse pure GPL compatibility, I prefer quick and hassle-free installation and usage of OpenOCD, be it fully- or conditionally- GPL compatible. I did setup OpenOCD building environment (Cygwin) - this is trivial, but still it takes precious time. Even more would take to install libusb-win32 co. I can also second Xiaofan, who offers distribution of .zip file with Cygwin building environment set up, probably with shell script that does `./bootstrap`, `./configure --with-ftd2xx-blahblah` and `make` there, so that Windows users with (almost) no linux experience could build openocd themselves in minutes. Kind regards, Audrius P.S. Michael - sorry for private posting: forum rules require group-reply, I just can't get used to this :-/ Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 Windows - summary of options
On Sunday 21 June 2009, Freddie Chopin wrote: Should we take silence as an agreement? Of course not. It was posted maybe twelve hours ago, but you got impatient after only seven. Plus, there's not really anything to be said except that both of your options violate the licensing. At this point I'm surely not alone in wanting you to focus on options that could stand a prayer of really being supported Two other threads covered such options, neither of which were in your summary. No surprise that nobody agreed. * The thread about a Universal INF file seemed much more productive. Sure, more adapters need to be covered, and the library binaries that get bundled into the MSI file will need to be the right versions (libusb, libftdi). * Even the thread about getting good Win32 build instructions was more productive. It's probably time that some build script starts packaging alpha builds on Windows, with install/uninstall options, if such builds are going to be released on Berlios. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Add config for CS351x CPUs
On Sunday 21 June 2009, Paulius Zaleckas wrote:
+
+if { [info exists ENDIAN] } {
+ set _ENDIAN $ENDIAN
+} else {
+ set _ENDIAN little
+}
+
Can this chip actually override its endianness?
If not, I suggest removing that...
I think it's counterproductive to support that
particular idiom except on those rare chips
where the endianness *CAN* change. The default
in OpenOCD is little endian.
Hmm ... I'll send some relevant patches along
soonish.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
On Sunday 21 June 2009, Xiaofan Chen wrote: On Sun, Jun 21, 2009 at 5:45 PM, Xiaofan Chenxiaof...@gmail.com wrote: Michael has a nice tutorial here on building OpenOCD with different configurations here. http://forum.sparkfun.com/viewtopic.php?t=11221 Michael Fischer has since updated the instruction and he tested it with OpenOCD SVN2348 and the updated build instruction works. I also tried to build SVN2348 and I can build both the FTD2xx version and libftdi version using his instruction. This is good news. Now I'm wondering whether such build instructions shouldn't be (a) included in the source tree (b) updated as necessary (c) referenced on the web page Maybe (c) suffices, referncing that forum link. This stuff is not User's Guide material, but build instructions deserve accurate documentation. - Dave The remaining update to be done is the instruction to install the libusb-win32 driver. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 Windows - summary of options
On Sunday 21 June 2009, Audrius Urmanavičius wrote: I can also second Xiaofan, who offers distribution of .zip file with Cygwin building environment set up, probably with shell script that does `./bootstrap`, `./configure --with-ftd2xx-blahblah` and `make` there, so that Windows users with (almost) no linux experience could build openocd themselves in minutes. I can't see any particular issue with such a build kit. Of course it shouldn't include binaries of any kind. It should however be exactly equivalent to carefully written build instructions that include fetching the source (maybe both release 0.2.0 or SVN-head options) and libraries. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
Harald, Thank you for taking the time to participate in this discussion. On Sat, 2009-06-20 at 12:53 +0200, Harald Kipp wrote: Zach Welch wrote: On Fri, 2009-06-19 at 18:26 +0200, Harald Kipp wrote: Dynamic linking to proprietary libraries by adding LoadLibrary and GetProcAddress to OpenOCD is a gray area. While the FSF would not allow this, some lawyers may have a different view. The big problem with gray areas is that you can be sued anyway, and -- even if you have lots of money -- you will have no idea as to whether or not you will be able to defend the legality of your actions. Same view here. That's why I suggested a different solution, which avoids direct static linking of a proprietary library to GPL code. Static or shared, linked directly or through other libraries: it makes no difference with the GPL. IMHO, the best solution is to create a new DLL, which is distributed under LGPL or GPL with a special exception (may be even BSDL). It should not provide any problems to link OpenOCD with this new library. And for this library it should be no problem to link to FTD2XX.dll. OpenOCD(GPL) - links - OpenFTD2XX(LGPL) - links - FTD2XX(Closed) I would be just as opposed to such circumvention as I would to linking to it directly, but I believe the legality of this strategy is suspect. Quite simply, an exception to the LGPL would create a new license, and the modified legal verbiage would no longer be compatible with the GPL. Sorry, if I didn't explain this clearly enough. LGPL won't need an exception, it explicitly allows linking to proprietary code. I think you need to get legal counsel to confirm your point; I believe this case is no different than the GPL. AFAICT, you must distribute the source to the library, which cannot be done legally with the FTD2XX library. You end up in the same place as we find ourselves now with the GPL, with a new library that tries to obfuscate this fact. The actual difference from the GPL is that you can link LGPL libraries into proprietary applications. When you turn it the other way around, they treat linking proprietary bits into the library binaries the same: you must provide all of the source code to reproduce the binary you shipped under compatible terms. Others may affirm or disavow this interpretation, but this is what I recall from my own past research. The FTD2XX library necessarily imposes additional restrictions, which prohibit it from being GPL-compatible. Referring to pure GPL: It explicitly allows exceptions and in reality there are many Open Source projects make use of this. In fact GPL itself makes an exception (V2, clause 3, last but one paragraph). Otherwise no GPL program would ever be able to run on Windows. But all copyright holders must agree to adding one. I do not. This makes OpenOCD pure GPL, and you will have a challenging burden of proof defending distribution of binaries linked to FTD2XX. Personally, I believe the FTD2XX driver components fail to meet the conditions for exemption under the terms of the paragraph you specify. We may also consider to ask the FSF directly to confirm a specific exception. If we are able to provide good reasons, they will probably agree. The problem is that there is no good reason: libusb+libftdi does the same job and can be made to be equivalent. They would never grant an exception, even if they had standing -- which they do not; as far as I know, no one in the OpenOCD community has assigned their individual copyrights to the FSF. Only through unanimous action could OpenOCD's copyright holders make changes to the license; my dissenting vote precludes any such change. Anyway, for the intermediate library LGPL is IMHO the better solution. Under the terms of the GPL as I understand them, I believe that libusb and libftdi is the only legally distributable solution. To reiterate my earlier statements on this subject, I will consider distribution of any OpenOCD binary that links to FTD2XX to be a violation of the GPL. If the libftd2xx library loads in the OpenOCD process, then distributing the binary would violate the GPL. Same view here. That's why I suggested linking OpenOCD to LGPL, which in turn links to FTD2XX. The best solution is to fix libftdi; it is a replacement for FTD2XX. Would you agree, that the best solution depends on one's attitude? My present definition revolves around legality. The best solution will be one that is legal to distribute. OpenOCD binaries linked to FTD2XX drivers could never be distributed legally, even if no one was called out on it until now. This is not about attitude, other than compliance with the language of the license in the manner which its authors intended. Did you stop to consider that -- by ensuring GPL compliance -- we are preventing copyright holders from launching submarine copyright attacks for non-compliance? It could be that I have just foiled a potentially
Re: [Openocd-development] FT2232 Windows - summary of options
On Sun, 2009-06-21 at 11:28 +0200, Freddie Chopin wrote: As no satisfying solution has been decided I will try to summarise the options I think are fine for Windows users. Please - put away your linux windows attitude aside for a moment and do keep in mind three things before proceeding: 1. Windows users usually have no knowledgle of linux and linux tools 2. Windows users expect a software package to work out of the box 3. Windows users are not familiar with open-source and GPL ideas Because of 1. a solution with VM running OpenOCD on linux is bad, because instead of questions how to use libftdi version we will be flooded with how to use linux VM version. Because of 1. it is naive to expect more than 1% Windows user to be able to compile OpenOCD for private use. Becaue of 1. it is not a solution to distribute a VM with linux crosscompiler and apropriate scripts. Because of 2. it is bad to ship OpenOCD with libftdi which expects user to create custom drivers (there are NO libusb drivers for FT2232 posted on vendor's websites), download a hacked version of libusb0.sys and overwrite the original and so on... Because of 3. Windows users see nothing wrong in using a freely aviable ftd2xx library that is faster and supports virtual COM ports. So in reality I see only two solutions: 1. A ftd2xx.dll wrapper library, which would be published under GPL with exception for ftd2xx.dll. Such library would dynamically link ftd2xx and - as an open-source solution - could be linked with OpenOCD. This is a very good proposal made by Herald Kipp and described in detail here: https://lists.berlios.de/pipermail/openocd-development/2009-June/008265.html 2. A binary patch which would convert a libusb+libftdi based executable to ftd2xx based one. Me and Michael Fisher managed to produce such patch with bsdiff/bspatch. The patch is 30kB in size and works. Now, it's obvious that option 1 requires some work. The library has to be created and OpenOCD code has to be modified to work with that. As the libary would be a wrapper the change in OpenOCD would be merely a name replacement FT_... = OpenFT_... (or whatever name would be chosen). Before such work can be started it would be nice for anybody to comment on what Herald wrote in the post I linked above. I took some time yesterday to browse gnu.org website and I think that this solution would not violate GPL. Moreover - _maybe_ such library could also provide a method to switch ftd2xx to libftdi so that it would be up to user to decide what he/she wishes to use (libftdi and ftd2xx are more or less compatible). This way OpenOCD would not require a decision of library at compile time. The most obvious problem with that solution is that it requires time and this would not be finished until 0.2.0 (which I hope is coming soon). Maybe even a bigger problem is your attitude towards such solution... The second solution can be used right away. Nothing needs to be changed. The major concern is - will you allow a patch, patch tool and instructions to use that to be included in the installer in a folder named - for example - Non-GPL? (I'm asking this for the third time and I'd really like to hear the answer). Some will say that there is a third solution - improve libftdi and libusb to work as good ad ftd2xx. That solution is very GPL friendly, but... I think I would be able to create a wrapper library with some (a lot [; ) help, but improving libusb and libftdi code is way beyond my capabilities. I also haven't seen any volunteers that could do that job. That's why I suggest to first use the patch solution, than wrapper library while waiting for libftdi/libusb improvements, because these may be complete in a month, in a year or in ten years... Currently There are many arguments against libftdi and libusb on windows, most important of them: 1. speed, 2. no support for serial ports on the second channel, 3. lack of vendor provided drivers online, 4. no support for composite devices in published libusb code (need for hacked libusb0.sys). That's why I think that without a good solution OpenOCD is more or less dead for most of Windows users. So please - put at least half of spaces vs. tabs energy in this discussion. This way we can find a solution that is satisfactory for both parties, because now it's a win-lose in GPL vs. windows users. Or maybe you just wish to ignore Windows and it's n00b users - if that's the case, state that out loud, and we will be gone and stop bothering you with our problems. Please DO NOT try to cheat the GPL license. You do not understand how far I am willing to take these matters, and I believe any form of binary distribution to be a violation: a DLL wrapper, a binary patch, anything! Fix the problems with libusb and libfdti. Period. Cheers, Zach ___ Openocd-development
Re: [Openocd-development] [PATCH] Add config for CS351x CPUs
David Brownell wrote:
On Sunday 21 June 2009, Paulius Zaleckas wrote:
+
+if { [info exists ENDIAN] } {
+ set _ENDIAN $ENDIAN
+} else {
+ set _ENDIAN little
+}
+
Can this chip actually override its endianness?
If not, I suggest removing that...
Yes, it can. By bootstrap pin and even by software
writing some special register.
I think it's counterproductive to support that
particular idiom except on those rare chips
where the endianness *CAN* change. The default
in OpenOCD is little endian.
Hmm ... I'll send some relevant patches along
soonish.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
Zach Welch z...@superlucidity.net writes: Harald, Thank you for taking the time to participate in this discussion. On Sat, 2009-06-20 at 12:53 +0200, Harald Kipp wrote: Zach Welch wrote: On Fri, 2009-06-19 at 18:26 +0200, Harald Kipp wrote: Dynamic linking to proprietary libraries by adding LoadLibrary and GetProcAddress to OpenOCD is a gray area. While the FSF would not allow this, some lawyers may have a different view. The big problem with gray areas is that you can be sued anyway, and -- even if you have lots of money -- you will have no idea as to whether or not you will be able to defend the legality of your actions. Same view here. That's why I suggested a different solution, which avoids direct static linking of a proprietary library to GPL code. Static or shared, linked directly or through other libraries: it makes no difference with the GPL. There must be *some* limit to how far this principle can extend. For example, a non-GPLed FTDI server communicating via sockets (or via some other messaging). [...] -- John Devereux ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Add config for CS351x CPUs
Committed. Thanks! -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
There must be *some* limit to how far this principle can extend. For example, a non-GPLed FTDI server communicating via sockets (or via some other messaging). Also, I have never read the fine print in GPL that stops Windows from becoming GPL when GPL code is run under Windows. -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 Windows - summary of options
On Sun, 2009-06-21 at 13:20 -0700, David Brownell wrote: On Sunday 21 June 2009, Audrius Urmanavičius wrote: I can also second Xiaofan, who offers distribution of .zip file with Cygwin building environment set up, probably with shell script that does `./bootstrap`, `./configure --with-ftd2xx-blahblah` and `make` there, so that Windows users with (almost) no linux experience could build openocd themselves in minutes. I can't see any particular issue with such a build kit. Of course it shouldn't include binaries of any kind. It should however be exactly equivalent to carefully written build instructions that include fetching the source (maybe both release 0.2.0 or SVN-head options) and libraries. Finally!! Someone came up with one of the legal workarounds! A build script can be distributed that automatically fetches every single component (including the compilers, if necessary) and builds all of the source code from scratch. This is simply a matter of doing the work, but I have done this for past projects for exactly these same reasons. This may seem like extra work, but the resulting distribution complies with the terms of the GPL. If we had fully modular drivers, it would even be possible to distribute a build kit that compiles _only_ the FTD2XX driver, which can be installed into OpenOCD's (forthcoming) driver module directory. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 Windows - summary of options
Zach Welch pisze: Fix the problems with libusb and libfdti. Period. This is starting to get ridiculous... As I already wrote somewhere - I really would like to, but... I cannot. I'm not a PC programmer, in fact I'm a newbie in embedded world too, so - sorry, I won't fix libftdi and libusb, because that is simply beyond me. Period. See it that way: I have no interest in OpenOCD being popular. I can build my own executable and that will use ftd2xx until open-sources will be equivalent (they are currently not, so...). In fact, that is all I really need. I see that most of developers here do not care about OpenOCD popularity either... CrossWorks is cheap and provides full and fast support for FT2232 chips via ftd2xx. I bet that it's cheaper than your time to fix libftdi and libusb. RIDE, Keil and IAR have free versions with support for limited code size. That will do for many users. You are effectivelly killing OpenOCD for Windows, you just don't want to see that right now. Fine. It's your decision... If you want to write code just for yourself that's also fine for me. GPL-or-die... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
On Sunday 21 June 2009, Øyvind Harboe wrote: Also, I have never read the fine print in GPL that stops Windows from becoming GPL when GPL code is run under Windows. See the bit about system libraries. If they're part of the OS, it's OK to link with them. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
On Sun, 2009-06-21 at 22:05 +0100, John Devereux wrote: Zach Welch z...@superlucidity.net writes: Harald, Thank you for taking the time to participate in this discussion. On Sat, 2009-06-20 at 12:53 +0200, Harald Kipp wrote: Zach Welch wrote: On Fri, 2009-06-19 at 18:26 +0200, Harald Kipp wrote: Dynamic linking to proprietary libraries by adding LoadLibrary and GetProcAddress to OpenOCD is a gray area. While the FSF would not allow this, some lawyers may have a different view. The big problem with gray areas is that you can be sued anyway, and -- even if you have lots of money -- you will have no idea as to whether or not you will be able to defend the legality of your actions. Same view here. That's why I suggested a different solution, which avoids direct static linking of a proprietary library to GPL code. Static or shared, linked directly or through other libraries: it makes no difference with the GPL. There must be *some* limit to how far this principle can extend. For example, a non-GPLed FTDI server communicating via sockets (or via some other messaging). Congratulations! You have suggested another potentially legal mechanism for distributing a FTD2XX binary driver. However -- for this to be legitimate -- you would need to implement a fully generic socket-based JTAG interface driver... which is what has been previously discussed on this list as the TCP/IP driver. With such a generic mechanism, one could build and distribute a completely and totally separate binary that contains the FTD2XX driver. It would _not_ be legal to define a FTD2XX-only socket interface, because that would be deferring the link step to the socket open call!! It must be a generic interface. This interpretation derives from past experience with other projects, though I cannot recall exactly from where this particular bit of wisdom derives. More importantly, any driver-side code for this socket-based interface would need to be licensed under the LGPL, or the present situation will remain unchanged. Clearly, this will not be possible for 0.2.0, but the build-kit idea would be a temporary workaround. Furthermore, both will improve the functional capabilities of OpenOCD for users, so it is by far the best solution in terms of delivering tangible value to the community. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 Windows - summary of options
On Sun, 2009-06-21 at 23:15 +0200, Freddie Chopin wrote: Zach Welch pisze: Fix the problems with libusb and libfdti. Period. This is starting to get ridiculous... As I already wrote somewhere - I really would like to, but... I cannot. I'm not a PC programmer, in fact I'm a newbie in embedded world too, so - sorry, I won't fix libftdi and libusb, because that is simply beyond me. Period. See it that way: I have no interest in OpenOCD being popular. I can build my own executable and that will use ftd2xx until open-sources will be equivalent (they are currently not, so...). In fact, that is all I really need. I see that most of developers here do not care about OpenOCD popularity either... CrossWorks is cheap and provides full and fast support for FT2232 chips via ftd2xx. I bet that it's cheaper than your time to fix libftdi and libusb. RIDE, Keil and IAR have free versions with support for limited code size. That will do for many users. You are effectivelly killing OpenOCD for Windows, you just don't want to see that right now. Fine. It's your decision... If you want to write code just for yourself that's also fine for me. Bullshit. What is effectively killing OpenOCD for Windows is the fact that you and others would rather bitch about the situation than do anything about it. If you cannot write code, then you need to convince (or pay) other developers to fix it. If all of OpenOCD's users chipped in, I bet each of you would pay less than any commercial alternative. I just posted two confirmations of legal alternatives, of which I have been aware since before these threads started. You are spreading FUD. Please. Stop. Now. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 Windows - summary of options
zach Please DO NOT try to cheat the GPL license. You do not understand how zach far I am willing to take these matters, and I believe any form of binary zach distribution to be a violation: a DLL wrapper, a binary patch, anything! Let me ask this another way. I believe the question is some what moot, and was moot 4 years ago one OpenOCD was originally written. Basic thesis statement, and IANAL... But I can sound like one. If I am the original author of a body of work, I hold the original copyright and can license that body of work as I please, under the GPL with any exception that I please. Those that follow do not have the ability to further restrict, nor change that license. As the original copyright holder, I can choose to explicitly write an exception for a specific use case of the package (or fail to), however - if my personal actions effectively construct and demonstrate that use case - is valid and acceptable - then it is an unwritten exception. You cannot change my original intention, nor can you change that original license and/or any exception that may have been granted before you got involved. Argument. It is well know that Dominic Rath, is the original author of OpenOCD. By reviewing his original releases that I find in the SVN repository, I can't get back to Rev1, Rev 50 fails, Rev 75 works, By Dominic's on hand purposely created OpenOCD to support the ftd2xxx library on windows. As I understand (and Laurent or Dominic can confirm) Domenic worked with Laurent to help develop the ftd2xx driver (and library) based jtag key. Perhaps - I do not now - but I assume. Dominic and other developers of the package at the time actively participated and encouraged the package to be *USED*WITH* and in fact *SOLD*WITH* this 'incompatible library' While not *explicitly* *written* I view this as an original exception that was unwritten, but granted, as demonstrated by the original author, and original copyright holder of the package as an acceptable exception. We as a group, perhaps may not like this fact, but it is what it is. I can not change that original exception, nor can anyone else. It was part of the deal when each of us started to contribute to OpenOCD. For example - see the Amontec Application note - copyright 2000 to 2006 which explicitly references the FT22xx drivers. http://www.amontec.com/pub/amt_ann006.pdf I also point out the history of openocd on the Amontec web site http://www.amontec.com/openocd.shtml (bottom of the page) The person who can clarify any misunderstanding is Domenic, and Dominic alone. **END** -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 Windows - summary of options
Zach Welch pisze: If all of OpenOCD's users chipped in, I bet each of you would pay less than any commercial alternative. You forgot something [; I don't need to pay for anything, nor does anyone else. I can build my own executable with ftd2xx. If you will drop that support, I'll just stay with the most recent one that has it. Others can do whatever they want - use free versions of commercial software, use cracked versions of commercial software, reinstall the system (via some ghost-copy mechanism it takes less than 15minutes) every month when the free CrossWorks license ends... So sorry, no money from me. Your idea behind open-source is very noble indeed. You are spreading FUD. Please. Stop. Now. Why? You - on the other hand - are all that violates GPL, period, so you're spreading GPL-or-die. Please. Stop. Now. Any realistic solution is violating the GPL according to you, that's a pure No, because that's what I say attitude. If that is so obvious that a wrapper-lib with GPL-with-exception or binary-patch violates that licence that would be no problem for you to prove that for me... Because now I think that it violates only your view of GPL. I've read this license and I just don't see any paragraph that forbids linking any GPL-ed code with exceptions to a GPL-ed software. Where it is said, that this 100%-GPL-chain has to be infinite? Why is a patch violating the license? That would be marked as clearly Non-GPL, so where is the problem? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 Windows - summary of options
On Sun, 2009-06-21 at 17:38 -0400, Duane Ellis wrote: zach Please DO NOT try to cheat the GPL license. You do not understand how zach far I am willing to take these matters, and I believe any form of binary zach distribution to be a violation: a DLL wrapper, a binary patch, anything! Let me ask this another way. I believe the question is some what moot, and was moot 4 years ago one OpenOCD was originally written. Basic thesis statement, and IANAL... But I can sound like one. If I am the original author of a body of work, I hold the original copyright and can license that body of work as I please, under the GPL with any exception that I please. Those that follow do not have the ability to further restrict, nor change that license. As the original copyright holder, I can choose to explicitly write an exception for a specific use case of the package (or fail to), however - if my personal actions effectively construct and demonstrate that use case - is valid and acceptable - then it is an unwritten exception. You cannot change my original intention, nor can you change that original license and/or any exception that may have been granted before you got involved. Argument. It is well know that Dominic Rath, is the original author of OpenOCD. By reviewing his original releases that I find in the SVN repository, I can't get back to Rev1, Rev 50 fails, Rev 75 works, By Dominic's on hand purposely created OpenOCD to support the ftd2xxx library on windows. As I understand (and Laurent or Dominic can confirm) Domenic worked with Laurent to help develop the ftd2xx driver (and library) based jtag key. Perhaps - I do not now - but I assume. Dominic and other developers of the package at the time actively participated and encouraged the package to be *USED*WITH* and in fact *SOLD*WITH* this 'incompatible library' While not *explicitly* *written* I view this as an original exception that was unwritten, but granted, as demonstrated by the original author, and original copyright holder of the package as an acceptable exception. We as a group, perhaps may not like this fact, but it is what it is. I can not change that original exception, nor can anyone else. It was part of the deal when each of us started to contribute to OpenOCD. For example - see the Amontec Application note - copyright 2000 to 2006 which explicitly references the FT22xx drivers. http://www.amontec.com/pub/amt_ann006.pdf I also point out the history of openocd on the Amontec web site http://www.amontec.com/openocd.shtml (bottom of the page) The person who can clarify any misunderstanding is Domenic, and Dominic alone. The problem with your argument is that the license in the tree is GPL; the license in all of the source code headers is GPL. There are no exceptions stated anywhere in the tree. Consequently, this demonstrates that my contributions were made under the GPL without any exceptions, and I imagine that I am not the only contributor to have come to this particular conclusion based on these same facts. I am afraid that your intent will not matter even one iota, in a court of law. If you want to make exceptions, then they do not apply to the new code. You cannot retroactively change the license; however, you are free to fork the code at a point prior to my having a claim on the copyrights, and make an exception there. Since said license will not be compatible with the GPL anymore, you may not use the changes that I contributed. However, this further presumes that I am the only one that will object to such a change. That may not be the case, and I hope that others authors that share my views will step forward to confirm this point. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 Windows - summary of options
zach I am afraid that your intent will not matter even one iota, in a court of law. This is not, and was not ever my intent, I am speaking of what I see as the original authors GPL+[undocumented]-exception intention. zach If you want to make exceptions, then they do not apply to the new code. You cannot retroactively change the license; The code was *Domenic's* to license in that way, as he was the original author. I am not changing anything, I am only stating what I see as the history of the project, things that happened +3 years before I was involved. I don't like it, you obviously do not, and I believe others equally do not like it. I would like to see this exception *documented* so that it does not expand, or continue beyond this exact situation. Then we can move on. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 Windows - summary of options
Zach Welch wrote: On Sun, 2009-06-21 at 17:38 -0400, Duane Ellis wrote: zach Please DO NOT try to cheat the GPL license. You do not understand how zach far I am willing to take these matters, and I believe any form of binary zach distribution to be a violation: a DLL wrapper, a binary patch, anything! Let me ask this another way. I believe the question is some what moot, and was moot 4 years ago one OpenOCD was originally written. Basic thesis statement, and IANAL... But I can sound like one. If I am the original author of a body of work, I hold the original copyright and can license that body of work as I please, under the GPL with any exception that I please. Those that follow do not have the ability to further restrict, nor change that license. As the original copyright holder, I can choose to explicitly write an exception for a specific use case of the package (or fail to), however - if my personal actions effectively construct and demonstrate that use case - is valid and acceptable - then it is an unwritten exception. You cannot change my original intention, nor can you change that original license and/or any exception that may have been granted before you got involved. Argument. It is well know that Dominic Rath, is the original author of OpenOCD. By reviewing his original releases that I find in the SVN repository, I can't get back to Rev1, Rev 50 fails, Rev 75 works, By Dominic's on hand purposely created OpenOCD to support the ftd2xxx library on windows. As I understand (and Laurent or Dominic can confirm) Domenic worked with Laurent to help develop the ftd2xx driver (and library) based jtag key. Perhaps - I do not now - but I assume. Dominic and other developers of the package at the time actively participated and encouraged the package to be *USED*WITH* and in fact *SOLD*WITH* this 'incompatible library' While not *explicitly* *written* I view this as an original exception that was unwritten, but granted, as demonstrated by the original author, and original copyright holder of the package as an acceptable exception. We as a group, perhaps may not like this fact, but it is what it is. I can not change that original exception, nor can anyone else. It was part of the deal when each of us started to contribute to OpenOCD. For example - see the Amontec Application note - copyright 2000 to 2006 which explicitly references the FT22xx drivers. http://www.amontec.com/pub/amt_ann006.pdf I also point out the history of openocd on the Amontec web site http://www.amontec.com/openocd.shtml (bottom of the page) The person who can clarify any misunderstanding is Domenic, and Dominic alone. The problem with your argument is that the license in the tree is GPL; the license in all of the source code headers is GPL. There are no exceptions stated anywhere in the tree. Consequently, this demonstrates that my contributions were made under the GPL without any exceptions, and I imagine that I am not the only contributor to have come to this particular conclusion based on these same facts. I am afraid that your intent will not matter even one iota, in a court of law. If you want to make exceptions, then they do not apply to the new code. You cannot retroactively change the license; however, you are free to fork the code at a point prior to my having a claim on the copyrights, and make an exception there. Since said license will not be compatible with the GPL anymore, you may not use the changes that I contributed. However, this further presumes that I am the only one that will object to such a change. That may not be the case, and I hope that others authors that share my views will step forward to confirm this point. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development Yes the licence is GPL, and there are no exceptions stated, unfortunatley. It is definitly possible to add an exception to allow linking to non GPL libraries and still remain GPL, but it is not possible to force derived GPL works to do the same: http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLIncompatibleLibs We only need the consent of the copyright holders. All long time developers of OpenOCD has been aware of the status of the libftd2xxx as proprietary code, have not been complaining and as such have been promoting this use. Or they have been living under a rock for the last couple of years. So perhaps it is time to formalize this exception to GPL that we have been accepting for years and add the exception to the licence in our code. I can tell you all that I have no objections to adding this exception to linking against a non GPL library as far as my contributions to OpnenOCD are concerned. If anybody
Re: [Openocd-development] FT2232 Windows - summary of options
On Sun, 2009-06-21 at 18:33 -0400, Duane Ellis wrote: zach I am afraid that your intent will not matter even one iota, in a court of law. This is not, and was not ever my intent, I am speaking of what I see as the original authors GPL+[undocumented]-exception intention. zach If you want to make exceptions, then they do not apply to the new code. You cannot retroactively change the license; The code was *Domenic's* to license in that way, as he was the original author. I am not changing anything, I am only stating what I see as the history of the project, things that happened +3 years before I was involved. I don't like it, you obviously do not, and I believe others equally do not like it. I would like to see this exception *documented* so that it does not expand, or continue beyond this exact situation. Then we can move on. I claim that there never was an exception to the GPL, if it was not documented as part of the public SVN tree. If the original authors allowed the distributors to produce binaries with this functionality, that appears to involve separate legal licensing agreements from the distribution of GPL binaries. Again, I have no interest in looking back at past violations, because this kind of tacit understanding with the original author -- and because I have no claim and do not really care. That said, the present situation remains the same. The license cannot be changed retroactively on the current trunk, no matter what Dominic's intent might be; such changes could only be applied to the revisions of agreeing contributors. If we had a list of all contributors that would allow such an exception, we could determine the earliest possible revision that may be exempted. Do we really want to go down that road? This issue has already balloon beyond control; today, I received what can only be described as hate mail for defending my position. I would prefer this be settled now by other contributors defend my interpretation of the situation. I will not be intimidated into backing down on this issue. Others are welcome to send me private e-mail to call me a nazi and otherwise debase my contributions to the project with profanity, but I would prefer to be convinced through a more articulate debate on this list. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Universal ft2232 .inf fileforwindows/libusb-win32
On Mon, Jun 22, 2009 at 12:19 AM, Freddie Chopinfreddie_cho...@op.pl wrote: Michael Fischer pisze: here is the driver which was build from the SVN r161 (libusb). Please test it, it should work with composite devices too. Works here. Now it is clear to me. Thanks. The SVN 161 version works. The released 0.1.12.1 version does not. I will try to ask in the libusb-win32 mailing list to ask the author to release the current SVN version as 0.1.12.2 or similar. -- 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] Universal ft2232 .inf file for windows/libusb-win32
On Sun, Jun 21, 2009 at 11:31 PM, Freddie Chopinfreddie_cho...@op.pl wrote: Xiaofan Chen pisze: It seems to me that you are using libusb-win32 with individual interfaces and I am not sure that would work. I'm not sure I understand you correctly, but if there are no entries for individual channels (...MI_00 and ...MI_01) OpenOCD doesn't work. I think that the master entry (the one without the channel info) is not required, but that has to be tested. Now it is clear to me. Thanks. The SVN 161 version works. The released 0.1.12.1 version does not. I will try to ask in the libusb-win32 mailing list to ask the author to release the current SVN version as 0.1.12.2 or similar. In this case, I think you do not need the master entry. Please try it again with the master entry deleted. -- 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] FT2232 Windows - summary of options
On Sunday 21 June 2009, Freddie Chopin wrote: You are spreading FUD. Please. Stop. Now. Why? Because it's an annoying and counterproductive waste-of-time. And because the developers aren't particularly keen on your encouragment that folk should violate the licensing on the software those developers have produced. If you're going to encourage folk break legal agreements, please have the integrity and courtesy to only do it for things *YOU* have made significant contributions towards. You - on the other hand - are all that violates GPL, period, so you're spreading GPL-or-die. No, he's just one of the people pointing out that the developers have chosen a license that precludes what you're suggesting. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 Windows - summary of options
On Sunday 21 June 2009, Magnus Lundin wrote: Yes the licence is GPL, and there are no exceptions stated, unfortunatley. It is definitly possible to add an exception to allow linking to non GPL libraries and still remain GPL, but it is not possible to force derived GPL works to do the same: http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLIncompatibleLibs We only need the consent of the copyright holders. All of them... I posted a list of about fifty holders not long ago, which I don't believe is complete (given I spent only a few minutes grepping the source tree to find it, and some of the copyright statements surely didn't turn up that way All long time developers of OpenOCD has been aware of the status of the libftd2xxx as proprietary code, have not been complaining and as such have been promoting this use. Or they have been living under a rock for the last couple of years. Right, they have been aware that personal builds could use that code. And they've also been aware that the license is GPL and thus does not support *distribution* of code using that. So perhaps it is time to formalize this exception to GPL that we have been accepting for years and add the exception to the licence in our code. I can tell you all that I have no objections to adding this exception to linking against a non GPL library as far as my contributions to OpnenOCD are concerned. If anybody decides otherwise then that is his right but as far as I can understand it is possible to add this exception and still keep OpenOCD as GPL code. Possible, yes, with about fifty more folk agreeing ... :) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 Windows - summary of options
2009/6/22 Zach Welch z...@superlucidity.net: On Sun, 2009-06-21 at 13:20 -0700, David Brownell wrote: On Sunday 21 June 2009, Audrius Urmanavičius wrote: I can also second Xiaofan, who offers distribution of .zip file with Cygwin building environment set up, probably with shell script that does `./bootstrap`, `./configure --with-ftd2xx-blahblah` and `make` there, so that Windows users with (almost) no linux experience could build openocd themselves in minutes. I can't see any particular issue with such a build kit. Of course it shouldn't include binaries of any kind. It should however be exactly equivalent to carefully written build instructions that include fetching the source (maybe both release 0.2.0 or SVN-head options) and libraries. Finally!! Someone came up with one of the legal workarounds! A build script can be distributed that automatically fetches every single component (including the compilers, if necessary) and builds all of the source code from scratch. This is simply a matter of doing the work, but I have done this for past projects for exactly these same reasons. This may seem like extra work, but the resulting distribution complies with the terms of the GPL. If we had fully modular drivers, it would even be possible to distribute a build kit that compiles _only_ the FTD2XX driver, which can be installed into OpenOCD's (forthcoming) driver module directory. Glad to heat that build-kit idea is acceptable by GPL and you two. Cygwin is not small. So it is good to distribute is as a zip file. The a shell script to fetch OpenOCD and FTD2XX driver and build OpenOCD can be put in to automatic the job. -- 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] FT2232 Windows - summary of options
On Sunday 21 June 2009, Duane Ellis wrote: I would like to see this exception *documented* so that it does not expand, or continue beyond this exact situation. The way to document this is with a change to the license, signed on to by *everyone* holding any copyright on the code. Any previous exception was for development purposes only, not for distribution. You can tell that by the way there is (cough) ... no exception in the written license. Then we can move on. We can also move on by just accepting that the license is what it is, and working with that. If someone wants to conduct a parallel effort to contact each developer and get them to publicly approve a change in the licensing terms for their contributions, then by all means do that. Preferably with the work done off-list so it doesn't clutter up mailboxes of people trying to make actual technical contributions. But lacking such an effort, all the flamage is just pure annoyance. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
On Mon, Jun 22, 2009 at 4:15 AM, David Brownelldavi...@pacbell.net wrote: On Sunday 21 June 2009, Xiaofan Chen wrote: Michael has a nice tutorial here on building OpenOCD with different configurations here. http://forum.sparkfun.com/viewtopic.php?t=11221 Michael Fischer has since updated the instruction and he tested it with OpenOCD SVN2348 and the updated build instruction works. I also tried to build SVN2348 and I can build both the FTD2xx version and libftdi version using his instruction. This is good news. Now I'm wondering whether such build instructions shouldn't be (a) included in the source tree (b) updated as necessary (c) referenced on the web page Maybe (c) suffices, referncing that forum link. This stuff is not User's Guide material, but build instructions deserve accurate documentation. c) is acceptable but I think I think a) and b) are better. -- 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] Universal ft2232 .inf file for windows/libusb-win32
On Mon, Jun 22, 2009 at 7:38 AM, Xiaofan Chenxiaof...@gmail.com wrote: On Sun, Jun 21, 2009 at 11:31 PM, Freddie Chopinfreddie_cho...@op.pl wrote: Xiaofan Chen pisze: It seems to me that you are using libusb-win32 with individual interfaces and I am not sure that would work. I'm not sure I understand you correctly, but if there are no entries for individual channels (...MI_00 and ...MI_01) OpenOCD doesn't work. I think that the master entry (the one without the channel info) is not required, but that has to be tested. Now it is clear to me. Thanks. The SVN 161 version works. The released 0.1.12.1 version does not. I will try to ask in the libusb-win32 mailing list to ask the author to release the current SVN version as 0.1.12.2 or similar. In this case, I think you do not need the master entry. Please try it again with the master entry deleted. I've asked Stephan Meyer (author of libusb-win32) to consider releasing the latest SVN version as the 0.1.12.2. http://www.nabble.com/Possibility-to-release-the-current-SVN-version-as-0.1.12.2-td24141073.html -- 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] FT2232 Windows - summary of options
On Mon, Jun 22, 2009 at 4:02 AM, David Brownelldavi...@pacbell.net wrote: * The thread about a Universal INF file seemed much more productive. Sure, more adapters need to be covered, and the library binaries that get bundled into the MSI file will need to be the right versions (libusb, libftdi). * Even the thread about getting good Win32 build instructions was more productive. So here is the summary. 1) Shorter solution: a) Release a working libusb-win32+libftdi version with some known shortcomings (not working for 64bit Windows, lack of COM ports, lower performance, etc). Get the inf files and the binary package ready for Windows users. This is GPL compliant. b) Prepare good private build instruction for FTD2XX. Release a build kit (Cygwin zip file with the necessary tools, build scripts to fetch the FTDI D2XX driver and build OpenOCD with FTD2xx). This does not pose problems with GPL. The resultant OpenOCD binary can not be distributed without violating the current GPL license. 2) Mid-term solution if it is feasible Release a non-GPLed FTDI Server for the FTDI based Jtag debuggers using FTD2xx communicating via sockets (or via some other messaging mechanism). 3) Long term solution: just several possibilities. Some of them may be more difficult than the others. a) Improve the libusb+libftdi based solution within OpenOCD. This is anyway needed. Non-blocking I/O is one key factor to boost performance. b) Try to ask the vendor FTDI to release the FTD2xx library as GPL compatible. This is not likely to happen any time soon. But no harm trying. c) Contact all the OpenOCD developers to see if relicencing is possible or not (to grant exception to FTD2XX). It seems to me that some developers are avid about GPL. So I think this is also difficult. But the efforts may still make sense. For example, if there is only one or two who do not want to grant the exceptions and his contributions can be re-written, then that may still make sense to do it. d) Improve libusb-win32, get the driver digital signed to solve the 64bit Windows issues. Some HW vendors may be able to help. They can even get their HW driver WHQLed with libusb-win32 as well. This may be outside the scope of OpenOCD community but the community can play a part. e) Improve libftdi. This may be outside the scope of OpenOCD community but the community can play a part. What do you think about this summary? -- 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] FT2232 Windows - summary of options
On Sunday 21 June 2009, Xiaofan Chen wrote: What do you think about this summary? Ooooh ... *MUCH* better! Thank you! No comments other than that, for now. Except for: d) Improve libusb-win32, get the driver digital signed to solve the 64bit Windows issues. Some HW vendors may be able to help. They can even get their HW driver WHQLed with libusb-win32 as well. This may be outside the scope of OpenOCD community but the community can play a part. Vendors who are presenting OpenOCD as part of their software solution *SHOULD* be helping out here, IMO. Not only for the (d) option either... They can't sell their hardware to Win64 users without such options, right? And even Win32 users need help... Now, as to how that should be done ... this calls for developers with enough tact to deal with vendors. As most of us know, such developers are not the most common variety (sigh). A second qualification is to be relatively fluent in Windows development. It's likely not a really-near-term thing, but folk who can put OpenOCD developers in contact with the right folk at hardware houses should do so (off line of course). The requirement isn't that OpenOCD folk do the work (nice but not essential) ... it's that it be done quickly on a not-very-big budget, and get released to the community. (Budget matters of course. These FT2232 dongles sell for US $50-$150 or so. Not gobs of profit. Payback would be in strengthened sales, and maybe some positive press.) - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Universal ft2232 .inf file forwindows/libusb-win32
Just a summary for this thread. On Sun, Jun 21, 2009 at 11:55 PM, Freddie Chopinfreddie_cho...@op.pl wrote: Now there is a clean version of libusb0.sys. I've installed two drivers - for channel A and channel B. OpenOCD is not working... So - I keep my previous statements - you NEED a hacked version of libusb0.sys. On Mon, Jun 22, 2009 at 12:19 AM, Freddie Chopinfreddie_cho...@op.pl wrote: Michael Fischer pisze: here is the driver which was build from the SVN r161 (libusb). Please test it, it should work with composite devices too. Works here. So with separate interface INF file, you need to use the SVN version of libusb-win32. This is better option than the hacked libusb0.sys. Yesterday I was installing just the master driver - without the channel a and channel b stuff, and it wasn't working too. Replacing libusb0.sys fixes the problem - OpenOCD works. I am not 100% clear clear. If you just install the master driver (the inf file for the whole device, not individual interface), does OpenOCD work with the hacked libusb0.sys or the latest SVN version of libusb-win32? Thanks. I hope that this also works. It is simpler to use INF wizard to generate the INF file for the whole 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] Universal ft2232 .inf file forwindows/libusb-win32
Xiaofan Chen pisze: Replacing libusb0.sys fixes the problem - OpenOCD works. I am not 100% clear clear. If you just install the master driver (the inf file for the whole device, not individual interface), does OpenOCD work with the hacked libusb0.sys or the latest SVN version of libusb-win32? Thanks. When I install only the master driver it doesn't work no matter what rev is installed. If I install the individual drivers the rev has to support this, so hacked or the SVN that Michael posted. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Universal ft2232 .inf file forwindows/libusb-win32
On Mon, Jun 22, 2009 at 1:21 PM, Freddie Chopinfreddie_cho...@op.pl wrote: Xiaofan Chen pisze: Replacing libusb0.sys fixes the problem - OpenOCD works. I am not 100% clear clear. If you just install the master driver (the inf file for the whole device, not individual interface), does OpenOCD work with the hacked libusb0.sys or the latest SVN version of libusb-win32? Thanks. When I install only the master driver it doesn't work no matter what rev is installed. If I install the individual drivers the rev has to support this, so hacked or the SVN that Michael posted. Thanks a lot. Now it is really clear to me. We have to use the separate interface INF files and the SVN version of libusb-win32 to make OpenOCD working with libusb-win32+libftdi. -- 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] FT2232 Windows - summary of options
2009/6/21 Zach Welch z...@superlucidity.net On Sun, 2009-06-21 at 13:20 -0700, David Brownell wrote: On Sunday 21 June 2009, Audrius Urmanavičius wrote: I can also second Xiaofan, who offers distribution of .zip file with Cygwin building environment set up, probably with shell script that does `./bootstrap`, `./configure --with-ftd2xx-blahblah` and `make` there, so that Windows users with (almost) no linux experience could build openocd themselves in minutes. I can't see any particular issue with such a build kit. Of course it shouldn't include binaries of any kind. It should however be exactly equivalent to carefully written build instructions that include fetching the source (maybe both release 0.2.0 or SVN-head options) and libraries. Finally!! Someone came up with one of the legal workarounds! A build script can be distributed that automatically fetches every single component (including the compilers, if necessary) and builds all of the source code from scratch. This is simply a matter of doing the work, but I have done this for past projects for exactly these same reasons. This may seem like extra work, but the resulting distribution complies with the terms of the GPL. If we had fully modular drivers, it would even be possible to distribute a build kit that compiles _only_ the FTD2XX driver, which can be installed into OpenOCD's (forthcoming) driver module directory. All someone need do is produce a DLL that is called FTD2XX and implements (or plans to implement) all the interfaces that OpenOCD uses and release it under LGPL. The interfaces can all return failure for now. There would be no problem whatsoever releasing a binary linked against such a 'replacement' DLL... If the user choses to delete the replacement DLL and use FTDI's version, that's their choice. Orin. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 Windows - summary of options
You may want to use reply to all. This is not as convenient but it is the way OpenOCD mailing list is running. Thanks. On Mon, Jun 22, 2009 at 1:34 PM, Anders Montonenanders.monto...@iki.fi wrote: On Jun 22, 2009, at 6:15, Xiaofan Chen wrote: On Mon, Jun 22, 2009 at 4:02 AM, David Brownelldavi...@pacbell.net wrote: * The thread about a Universal INF file seemed much more productive. Sure, more adapters need to be covered, and the library binaries that get bundled into the MSI file will need to be the right versions (libusb, libftdi). * Even the thread about getting good Win32 build instructions was more productive. So here is the summary. (snip) 3) Long term solution: just several possibilities. Some of them may be more difficult than the others. As I see it, porting libusb-1.0 to the Windows UMDF and then porting libftdi and OpenOCD to libusb-1.0 would solve the GPL, Win64 and latency-related issues. I'm not familiar enough with either UMDF or libusb to estimate how difficult that would be, but I would suggest anyone with an interest in the Windows port of OpenOCD to look into that and help out where possible. libusb-win32's development branch (libusb1) has the WinUSB backend. It is not working yet. It is also not API compatible with libusb 1.0. That is an unfortunate situation. As an aside, has anyone had the opportunity to try OpenOCD with an FT2232H-based dongle? I believe high-speed USB should almost eliminate latency effects due to going from 1 ms-based frames to 125 us-based microframes. Not sure here. The blocking I/O will render the benefits of high speed USB much less effective. David Brownell is the real USB expert in the list. He may answer better, at least on the Linux side since he is one of the leading Linux usb developers. -- 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] FT2232 Windows - summary of options
2009/6/22 Orin Eman orin.e...@gmail.com: All someone need do is produce a DLL that is called FTD2XX and implements (or plans to implement) all the interfaces that OpenOCD uses and release it under LGPL. The interfaces can all return failure for now. There would be no problem whatsoever releasing a binary linked against such a 'replacement' DLL... If the user choses to delete the replacement DLL and use FTDI's version, that's their choice. Nice idea. ;-) There was a real efforts here to create an open source alternatives to FTD2XX. http://sourceforge.net/projects/ftd2xx The CVS is very old. So I guess the project is dead. Someone may want to revitalize it. http://ftd2xx.cvs.sourceforge.net/ftd2xx/ http://ftd2xx.cvs.sourceforge.net/viewvc/ftd2xx/ftd2xx/ -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
