Firmware for Xilinx USB cable

Hi,

Does anyone have a copy of the latest USB cable firmware version 1025 (the latest according to

formatting link
This file is necessary for use with 2.6 linux kernels and would be in /etc/hotplug/usb/xusbdfwu.fw. The version on the Xilinx website seems to be broken. Xilinx support acknowledge this but are taking some time to get back to me with the file.

I need to get this up an running urgently, so I would be grateful if someone who has the USB cable working could just send me their firmware file!

Many thanks,

Rob

Reply to
rob.dimond
Loading thread data ...

The 1025 firmware is packaged with the new driver installation stuff: ftp://ftp.xilinx.com/pub/utilities/install_drivers.tar.gz

It might be elsewhere, too.

Reply to
mark.jarvin

Sorry, that should have been ftp://ftp.xilinx.com/pub/utilities/fpga/install_drivers.tar.gz

Incidentally, that tarball also has 32- & 64-bit cable drivers.

Reply to
mark.jarvin

Many thanks!

I now have the Platform USB cable working with a 2.6.17 kernel (32-bit) using this firmware and the latest version of WinDriver (811). I will get back to Xilinx support and see if they will change the link to point to this archive!

Rob

beenftp://ftp.xilinx.com/pub/utilities/fpga/install_drivers.tar.gz

Reply to
rob.dimond

Sadly, my USB cable still doesn't work. iMPACT keeps trying to reprogram the CPLD when it notices that "CPLD version = FFFFh". If anyone has suggestions, I'm all ears. Frankly, I think the cable's hooped.

I thought the WinDriver in the Xilinx tarball was 802. Did you grab the latest from Jungo (for anyone who's reading --

formatting link
or
formatting link
I found that I had to patch the configure script included in the Xilinx tarball to get 802 to build with 2.6.17 (on Xubuntu Edgy).

--- configure.dist 2006-12-02 17:29:08.000000000 -0500

+++ configure 2006-12-04 09:52:44.000000000 -0500 @@ -886,6 +886,9 @@ if test ${VER:0:3} = "2.6" ; then else CFLAGS="$CFLAGS -DKBUILD_MODNAME=$MODULE_NAME" fi + if test $VER_SUBMINOR -ge 17 ; then + CFLAGS="$CFLAGS -include $KERNEL_DIR/include/linux/autoconf.h" + fi fi SHARED_OBJECT=libwdapi$dist_version
Reply to
mark.jarvin

It may have moved; it now seems to be at:

ftp://ftp.xilinx.com/pub/utilities/fpga/install_drivers.tar.gz

Reply to
Eric Smith

Thanks -- I had updated my erroneous post with a reply, but I guess it bears repeating.

Also, it turned out that my USB cable was broken but that the drivers were working. Now that I've tried with working cable, count me as a second successful user of the new drivers (both the Parallel IV and the Platform USB, tested and working on Xubuntu Edgy i386). I'm using the Jungo 802 distributed by Xilinx and patched as described previously, not the latest Jungo 811. I haven't yet tried the 64-bit version.

Based on what I observed, the "CPLD Version = FFFFh" message seems to indicate a broken cable whereas the "CPLD Version = 0000h" message seems to indicate a driver problem that's (presumably) fixed by the

1025 firmware.

I also observed something else a little weird. Since my environment doesn't use hotplug, I shouldn't need to run the setup_pcusb script and so I didn't. I found that programming from within EDK worked but that programming from iMPACT directly didn't -- it gave me an error and told me to run setup_pcusb. Same for XMD -- it wouldn't connect unless setup_pcusb had been run. I eventually found that iMPACT and XMD look for some side-effect of running setup_pcusb and refuse to proceed until setup_pcusb has been run (as root). If you run iMPACT as root, it'll run setup_pcusb for you (though you can obviously run it from the terminal, too). Once setup_pcusb had been run, I found that any user could program from EDK or directly from iMPACT (with appropriate permissions on the /dev nodes). XMD worked for any user, too. I speculate that it was failing because the firmware .hex file wasn't in /etc/hotplug.

The lesson: if you do a fresh install of ISE and EDK (or just ISE) and you install the drivers from the Xilinx website, don't forget to also run setup_pcusb even if it won't do anything useful in your environment. EDK must use some environment variable or flag that gets around this -- anybody know what it might be?

Reply to
mark.jarvin

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.