Open-source CableServer for Impact on sourceforge.net
in [FPGA]
|
Prev: FSL read/write problems
Next: Packages for ORCAD
From: Antti on 6 Sep 2006 12:13 zcsizmadia(a)gmail.com schrieb: > I think later on it would be nice to support all Xilinx programmer > cables natively from cblsrv (Platform USB, Parallel IV, etc.): > > 1. Jungo driver could be eliminated on both Linux and Win32 > 2. A open-source "cblhost" could be easily written and bundled with > cblsrv supporting standard Xilinx cables + 3rd party cables > > Zoltan > its not that easy. specially if you want to use unmodified cable IV and usb cable. for usb cable it is possible to use replacement firmware and pld file, but it want be any more xilinx platform usb cable then. similarly the pld in Cable IV can be read out and reprogrammed. if you are interest to support Cable IV in Cable IV high speed mode I can give jedec2vhdl converter that can create VHDL code from the jedec file read back from Cable IV, it should be enough to reverse the Cable IV low level protocol I think. I tried to revers Cable IV by creating an PCI IP Core that emulated the cable and logged the transactions, but that way didnt leed to success, ok I did not have time to have proper ECP emulation that was the reason why I didnt succeed with that attempt. Antti
From: zcsizmadia@gmail.com on 6 Sep 2006 12:34 Probably I miss something here. Why not just hook LPT or Jungo driver in windows, and see what is sent to the cable? Or it is downloading the firmware at the very beginning and it's a copyright issue to include the original firmware in your open-source application? The same way using a USB sniffer the communication can be reverse engineered (unless the data is not crypted) Do you have any Par IV or Platform USB cable I could borrow to see if it could be reverse engineered? Zoltan Antti wrote: > zcsizmadia(a)gmail.com schrieb: > > > I think later on it would be nice to support all Xilinx programmer > > cables natively from cblsrv (Platform USB, Parallel IV, etc.): > > > > 1. Jungo driver could be eliminated on both Linux and Win32 > > 2. A open-source "cblhost" could be easily written and bundled with > > cblsrv supporting standard Xilinx cables + 3rd party cables > > > > Zoltan > > > its not that easy. specially if you want to use unmodified cable IV and > usb cable. for usb cable it is possible to use replacement firmware and > pld file, but it want be any more xilinx platform usb cable then. > > similarly the pld in Cable IV can be read out and reprogrammed. > > if you are interest to support Cable IV in Cable IV high speed mode I > can give jedec2vhdl converter that can create VHDL code from the jedec > file read back from Cable IV, it should be enough to reverse the Cable > IV low level protocol I think. > > I tried to revers Cable IV by creating an PCI IP Core that emulated the > cable and logged the transactions, but that way didnt leed to success, > ok I did not have time to have proper ECP emulation that was the reason > why I didnt succeed with that attempt. > > Antti
From: Andreas Ehliar on 6 Sep 2006 12:42 On 2006-09-06, Uwe Bonnes <bon(a)hertz.ikp.physik.tu-darmstadt.de> wrote: > "The standalone Xilinx Platform Cable USB is unsupported and untested. Since > its hardware is presumably very similar, it may be usable as-is or with some > minor hacking. " I have tested it and it doesn't work. One problem is that the CPLD on the platform cable does not get a supply voltage at all if the xup firmware is downloaded to the FX2 chip. /Andreas
From: Antti on 6 Sep 2006 12:53 zcsizmadia(a)gmail.com schrieb: > Probably I miss something here. > > Why not just hook LPT or Jungo driver in windows, and see what is sent > to the cable? Or it is downloading the firmware at the very beginning > and it's a copyright issue to include the original firmware in your > open-source application? > The same way using a USB sniffer the communication can be reverse > engineered (unless the data is not crypted) > > Do you have any Par IV or Platform USB cable I could borrow to see if > it could be reverse engineered? > > Zoltan > Zoltan, snooping the USB cable does not make much sense as it is always downloading the actual firmware, those any new release of ISE may have different firmware and completly new USB protocol. It could of course be possible to write an emulator for the USB chip and use the actual firmware, by emulating it in fake driver, but that is all too time consuming. now as of Cable IV, well I havent done windows kernel debugging for ages. I used todo it. But as of today I dont have debug tools that can put breakpoints on io access in running winXP system. Sure it can be done when windows is installed in qemu, etc, but its all pretty much pain. Or another way is to reverse engineer some xilinx DLL, what defenetly violates the licensing, and is boring anyway. So third option is to look at the jedec readback from Cable IV, sure after conversion to VHDL. Antti
From: zcsizmadia@gmail.com on 6 Sep 2006 13:14
cblsrv emulates a Par III cable, so Impact doesn't have any idea, cblsrv would use a Platform USB cable. One working firmware would be good enough (unless they change the cableserver protocoll when using Par III) The windows debugging part is fairly easy, no breakpoints, or anything nasty, just simply put API trace logs with dumping incoming/outgoing data. I'd be more interested to reverse engineer the Platform USB than Par IV, because most new laptops and some desktops lack par ports anyway. Reverse engineer the Digilent USB JTAG cable took roughly 2 days to reverse engineer the basic protocol, but maybe the Platform USB is much nastier. Zoltan Antti wrote: > zcsizmadia(a)gmail.com schrieb: > > > Probably I miss something here. > > > > Why not just hook LPT or Jungo driver in windows, and see what is sent > > to the cable? Or it is downloading the firmware at the very beginning > > and it's a copyright issue to include the original firmware in your > > open-source application? > > The same way using a USB sniffer the communication can be reverse > > engineered (unless the data is not crypted) > > > > Do you have any Par IV or Platform USB cable I could borrow to see if > > it could be reverse engineered? > > > > Zoltan > > > Zoltan, > > snooping the USB cable does not make much sense as it is always > downloading the actual firmware, those any new release of ISE may have > different firmware and completly new USB protocol. It could of course > be possible to write an emulator for the USB chip and use the actual > firmware, by emulating it in fake driver, but that is all too > time consuming. > > now as of Cable IV, well I havent done windows kernel debugging for > ages. I used todo it. But as of today I dont have debug tools that can > put breakpoints on io access in running winXP system. Sure it can be > done when windows is installed in qemu, etc, but its all > pretty much pain. > > Or another way is to reverse engineer some xilinx DLL, what defenetly > violates the licensing, and is boring anyway. > > So third option is to look at the jedec readback from Cable IV, sure > after conversion to VHDL. > > Antti |