Open-source CableServer for Impact on sourceforge.net

Hi All,

Here is a open-source CableServer replacement,ent for Impact. Currently Parallel III and Alter ByteBlaster are supported, but any 3rd party can be implemented easily and can be used from Impact.

I've tested only Impact 8.2, if anybody has any problem with 7.1, please let me know!

Impact and Xilinx CableServer communication are very pooly written. There is no error recovery at all. If server stops, Impact GUI will crash. To avoid this you must disconnect server from GUI using Output/Cavble disconnect menu.

formatting link
formatting link

Regards,

Zoltan

Reply to
zcsizmadia
Loading thread data ...

Hi All,

Here is a open-source CableServer replacement for Xilinx Impact. Currently Parallel III and Altera ByteBlaster are supported, but any

3rd party programmer cable can be implemented easily and can be used from Impact. This open-source implementation can be used as a Programmer Cable SDK for Impact.

I've tested only Impact 8.2, if anybody has any problem with 7.1, please let me know!

Impact and Xilinx CableServer communication are very pooly written. There is no error recovery at all. If server stops, Impact GUI will crash. To avoid this you must disconnect server from GUI using Output/Cavble disconnect menu.

formatting link
formatting link

Regards,

Zoltan

Reply to
zcsizmadia

snipped-for-privacy@gmail.com schrieb:

Great !! it really works!

so now you can use Impact to connect to ByteBlaster, or any other custom cable or cable not supported by impact!

Antti

Reply to
Antti

I am trying to run cblsrv on Linux (Suse10.0) with a dlc5 clone (selfmade). Impact with windrvr recognizes the chain. cblsrv -d3 -cdlc5:/dev/parport0 -p 2000 doesn't find the chain. Obviosly PARPORT_DIRECT needs to get undefined with PARPORT_PPDEV

--- cblsrv-0.1/src/parport.h~ 2006-09-06 07:36:08.000000000 +0200

+++ cblsrv-0.1/src/parport.h 2006-09-06 10:35:16.000000000 +0200 @@ -50,6 +50,7 @@ // Define this if you want to support parport access by /dev/parportX #if !defined(WIN32) && !defined(__CYGWIN__) +#undef PARPORT_DIRECT #define PARPORT_PPDEV #endif Running as root with direct io works.

After the patch, running with PARPORT_PPDEV and reading the ID results in a crash of cblsrc: Program received signal SIGSEGV, Segmentation fault.

0x0804b478 in parport::shift (this=0x804f008, num_bits=-806384672, wbuff=0x804f178, rbuff=0x804f168, last=0) at parport.cpp:306 306 tdi_byte = *pw++; (gdb) p pw $1 = (u8 *) 0x8070000 (gdb) bt #0 0x0804b478 in parport::shift (this=0x804f008, num_bits=-806384672, wbuff=0x804f178, rbuff=0x804f168, last=0) at parport.cpp:306 #1 0x0804aedb in cable::write (this=0x804f008, mode=64, wbuff=@0xbf8fea68, cmp_rbuff=@0xbf8fea50) at cable.cpp:345 #2 0x080499db in do_cmd_write () at cblsrv.cpp:258 #3 0x08049f26 in do_msg_commands () at cblsrv.cpp:447 #4 0x0804a35a in client_connection () at cblsrv.cpp:584 #5 0x0804a53a in main (argc=5, argv=0xbf8feb84) at cblsrv.cpp:800

num-bit seems a little off.

Any ideas? Otherwise I'll try to debug in the next days.

B.t.w.: Do you have some smaller test client. Starting impact and clicking a zillion time to get to some point in the jtag handling is tedious...

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
 Click to see the full signature
Reply to
Uwe Bonnes

Uwe Bonnes schrieb:

there is no other test client as impact yet. I assume there will be since the cableserver protocol is now "open" :)

Antti

PS the cblsrv works perfectly on WinXP!

Reply to
Antti

On Linux the only test I did was using VmWare with direct I/O access (actually ppdev didn't work for me, it said PPEXCL failed).

Did you try to use with DIRECT_IO?

There is a cablehost directory under src. You can patch that to connect to server and send some messages. I've used it to connet tit to the Xilinx CableServer and figure out what the different write modes meant

Zoltan

PS: This weeken I'll try to more L> snipped-for-privacy@gmail.com wrote:

Reply to
zcsizmadia

ok, you tried it :)

I guess you have a little-endian envir> snipped-for-privacy@gmail.com wrote:

Reply to
zcsizmadia

I think I found the problem.

in parport::get_status:

-return ioctl(fd, PPRSTATUS);

+{
  • u8 data = 0;
  • ioctl(fd, PPRSTATUS, &data);
  • return data;
+}

Let me know if it helps!

Zoltan

Uwe B> > Hi All,

Reply to
zcsizmadia

Dear All,

This is good news. About time to get some open software to program FPGA's!.

The problem I still have is that we and many others are using the USB Parallel IV cable (DLC7). Who has ideas or works on an interface to drive the DLC7 cable? It seems to me that it now should be possible to build an USB interface to communicate with the DLC7. First someone needs to 'investigate' the functions of the Cypress firmware and then with the knowledge of the Impact protocol ....

Regards,

Rene.

Reply to
Rene van Leuken

Rene van Leuken schrieb:

formatting link

not exactly, you are messing some things. Parallel Cable IV = DLC7, does not work on USB dongle Platform USB Cable = DLC9

if you need to communicate with DLC9 then you use the original xilinx cable server and use the ip protocol to talk to it. no need to know anything internal to the DLC9.

if you want to make impact to communicate with some USB cable other than DLC9 then you have to add support for it to the opensource cable server. This could also be a special USB2LPT type of thing that is later connected to DLC7 but that doesnt make much sense.

Antti

Reply to
Antti

Rene van Leuken wrote: ...

Have a look at

formatting link

It states: "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. "

So well worth a try.

Bye

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
 Click to see the full signature
Reply to
Uwe Bonnes

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

Antti wrote:

formatting link

Reply to
zcsizmadia

snipped-for-privacy@gmail.com schrieb:

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

Reply to
Antti

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:

Reply to
zcsizmadia

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

Reply to
Andreas Ehliar

snipped-for-privacy@gmail.com schrieb:

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

Reply to
Antti

Well, you probably d "Most device drivers don't need exclusive access to the port. It's only provided in case it is really needed, for example for devices where access to the port is required for extensive periods of time (many seconds)."

And testing for failure for an ioctl is better done like ioctl(...) !=0

Running cblsrv as root (and having windrvr6 still loaded) worked. However after unloading the windrvr6 module, I couldn't get things to work.

cablehost is for win32...

Fine

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
 Click to see the full signature
Reply to
Uwe Bonnes

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:

Reply to
zcsizmadia

snipped-for-privacy@gmail.com schrieb:

ah? I am gettin old or what? you can put "API trace logs" read write to physical IO? to reverse the Cable IV that is required.

as of platform USB cable, it makes sens to use the natice cableserver as gateway, so you are not troubled with the USB protocol or firmware revision, etc

Antti

Reply to
Antti

Uwe,

Did you have a chance to try my patch?

I've already fixed them. Next week probably I'll finish the Digilent USB JTAG cable support in cblsrv, and will make a new release with the patches.

Zoltan

Uwe B> > On Linux the only test I did was using VmWare with direct I/O access

Reply to
zcsizmadia

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.