Xilinx Platform Cable USB protocol specifications and/or open-source firmware replacement

Hi everybody,

I recently bought a Xilinx Spartan-3E evaluation board, which comes with an integrated Platform Cable USB. Looking for a Linux compatible solution to program the FPGA, I found out that Impact requires the binary kernel driver Jungo and is thus not an option.

As Xilinx decided to classify the cable USB protocol specifications as "highly confidential", I started to reverse engineer the programmer to see if I could write an open-source host software.

The programmer is made of a USB microcontroller (Cypress EZ-USB) and a CPLD. After trying to understand the protocol from USB traces only without success, I decided to disassemble the microcontroller firmware. The code gave me more information regarding the protocol, but some USB commands are forwarded to the CPLD through register read/write operations and/or general purpose I/Os.

Not being able to understand the protocol, I thought I would write a replacement firmware which would not require a kernel driver. I'm looking for people interested in the project (or for people who have managed to understand the Xilinx USB protocol :-)). I can take care of the Cypress EZ-USB microcontroller, but needs someone with CPLD programming experience to write a replacement for the Xilinx CPLD firmware.

Laurent Pinchart

Reply to
Laurent Pinchart
Loading thread data ...

I too had the same thought. For a while.

A platform USB cable from the Xilinx store costs $150. Given the time to reverse engineer the protocol and design a board, and ...

And let's not forget that Xilinx owns the USB Vendor ID for the device, so one can't re-use it without their permission.

You can't make one that's iMPACT compatable; might as well buy one of the Digilent $38 versions.

Reply to
ghelbig

I came accross the Digilent JTAG-USB programming cable, but haven't been to find its protocol specifications. I asked Digilent for more information, but my e-mail seems to have been discarded. Do you know if the cable protocol is available somewhere ? Or will I have to reverse engineer it as well ?

Laurent Pinchart

Reply to
Laurent Pinchart

I came accross the Digilent JTAG-USB programming cable, but haven't been to find its protocol specifications. I asked Digilent for more information, but my e-mail seems to have been discarded. Do you know if the cable protocol is available somewhere ? Or will I have to reverse engineer it as well ?

Laurent Pinchart

Reply to
Laurent Pinchart

not directly available. RE needed

Reply to
Antti

Has anyone started working on that ?

Laurent Pinchart

Reply to
Laurent Pinchart

And you're surprized that they're not giving away their design?

Not to rain on your parade, but the typical FPGA engineer has spent a hundred bucks or so on the part, a grand or two on the PCB, and 1/2 a man-year on the code. $38 for a JTAG dongle is down in the noise.

If it's hobby use you're after, you can stretch the JTAG signals off of your card to another target.

There is an open-JTAG effort on SourceForge. You might want to check it out.

Reply to
ghelbig

Hi,

Who's talking about their design ? I'm not trying to create a cheap clone, but to drive the programmer using free software. I don't mind paying $38 (or even $150) for a good USB JTAG dongle, as long as I can use it.

I've checked that out, but it only support parallel port bit-banging adapters.

I want to buy a USB JTAG programmer that I can actually use with free softwares. Why is there none available ?

Laurent Pinchart

Reply to
Laurent Pinchart

I reread the thread and didn't see this asked. Why aren't you just using our iMPACT software. Linux is one of the supported OSes after all.

You do have to compile the drivers into your Kernel as explained here:

formatting link

and the iMPACT software is included in the free WebPack download.

Ed McGettigan

-- Xilinx Inc.

Reply to
Ed McGettigan

Hi Ed,

formatting link

Because iMPACT requires the Jungo binary driver, which has serious security issues.

Linux offers a user-space USB library called libusb (available for win32 as well) which would let iMPACT access the Platform Cable USB without using a binary kernel driver.

As I can't modify iMPACT to get rid of the Jungo dependency, I went the other way and tried to write a simple command line software to drive the cable. Unfortunately, the USB protocol seems to be classified top secret, and reverse engineering the EZUSB firmware didn't give me enough information. That's why I asked for more information on here.

Laurent Pinchart

Reply to
Laurent Pinchart

I've never heard of any Linux security issue with the Jungo drivers and a quick Google search produced nothing indicating any problems. There was a single discussion on freshmeat.net in the windriver project, but there was no conclusive or specific issue mentioned and no other net sources.

Based on the first comment on the freshmeat.net site by "omerz" it appears that you could put superuser/root permissions on the driver that theoretically could be misused, but if don't leave it as root then you get just normal user permissions.

It seems like you want to go to whole lot of effort to redo work that already exists and ships for free. If so, then I guess everyone needs a hobby to work on.

If you could cite a single instance of Linux box being "owned" through a Jungo USB/Parallel driver exploit I would be interested in seeing the reference.

Ed McGettigan

-- Xilinx Inc.

Reply to
Ed McGettigan

laurent has a point.

i would like too having usb programs for fpga/jtag interface using libusb with sources available.

linux version of ISE works without problems under FreeBSD but i can not do programming using iMPACT due problems with the cable[s] (parallel and USB).

linux was supposed to be about open source not about free software.

Reply to
mmihai

The security problem is more like : "I don't want foreign closed-source code running in kernel-mode on my machine".

And linux is "supported" well ... I never managed to make the usb cable work on linux (not a redhat) ...

Sylvain

Reply to
Sylvain Munaut

This wasn't apparant from your earlier postings.

Wanting to program an FPGA with a USB device under Linux seems like it should already exist, and I understrand your frustration that it doesn't.

Seems to me it would be possible to write an adaptation layer for an existing device. So all you need is a device you understand.

That can be fixed.....

Reply to
ghelbig

Laurent Pinchart wrote: ...

I have adapted so xc3stools can talk to XC3S via the FT2232 on USB. If you are interested, talk to me.

Otherwise, I understand your concerns about WinDriver. It's the first thing that gives you trouble when you come back to ISE after some time. As one probaly upgraded the kernel in the meantime, you first have to hunt for a fitting Windriver. And that for a task that could be done with on board means (parallel port access with /dev/parport and usb access vin /proc/bus/usb). As a hint for the Xilinx developpers: Libusb exists for Win32 too.

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

That's not the only issue. The main problem is that the Jungo driver is a security hole by design: it gives applications access to PCI cards from user space without any security check, making it possible for any user to read from and write to any memory location. The people who designed such a piece of crap should be banned from using computers for the rest of their life. Mind you, Jungo is not the only company who makes money from creating security holes. Macrovision, with its copy protection systems (SafeDisc for instance) introduced similar problems: the copy protection system loads a Windows kernel drivers which can be used by any application to read from or write to kernel memory. I could also mentionned the recent problems with the Sony copy protection on audio CDs...

But Sylvain is right: even if the security hole in the Jungo products wasn't so wide, I don't want closed-source code running in kernel mode. Running untrusted user-space applications is one thing, running untrusted kernel-mode code is another.

I've managed to scan the JTAG chain once with iMPACT, but it never worked again. The CPLD version is misread nearly each time, making iMPACT insist on updating the CPLD (and that takes a *lot* of time, as each JTAG bit toggling operation is implemented as a separate USB command).

Laurent Pinchart

Reply to
Laurent Pinchart

Hi Uwe,

Can you give me more information ? A quick search for xc3stools on google didn't return any hit.

That was one of my points: why use a closed-source kernel-mode driver so badly designed that it insults all kernel developers when an open-source, free software multiplatform solution is available ?

Laurent Pinchart

Reply to
Laurent Pinchart

s/xc3stool/xc3sprog

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

Hi Ed,

it's good to see that Xilinx monitors this group- and the JTAG topic.

When talking about JTAG and using it to configure FPGAs or CPLDs and programming PROMs, you are probably right: Impact is your friend. It will do what you want and there is no need to use any open source solution or program something on your own.

BUT: Often my world does not look like this. I have setups that are mixed with chips from other manufacturers. I want to access all of them. I want to do some tests, toggle a few pins, see what happens. And now the pain begins, as I cannot. I cannot just write my own JTAG software, because I cannot access the Xilinx cable.

Of course Xilinx is right from a revenue perspective. All these "odd" setups do not generate any revenue for Xilinx. So why should Xilinx support these applications? Because engineers do not want to use two different cables: One for the Xilinx flow, one for the more advanced problems. It is obvious from a technical perspective, that everything that is required is already there. So why should I buy another cable, just to be able to talk to the JTAG chain? This just does not make any sense.

OK, still I understand that Xilinx is not really motivated to do so. Probably, the documentation of the cable API will lead to a support night-mare. But again, there are solutions to it. Why not do it the other way around (and keep your driver dongled with Impact)? This is what I would really like to see:

- Create a properly documented API to talk to the driver.

- Make Impact use this API.

- Publish this API.

- Allow vendors to integrate their JTAG cables/ solutions with Impact.

This solution would probably make a lot of developers and vendors of development boards very happy. Including me.

Best regards, Felix

--
Dipl.-Ing. Felix Bertram
http://www.bertram-family.com/felix
Reply to
Felix Bertram

Can you please cite a reference that documents this issue in detail? And as I originally requested is there any known exploit that takes advantage of this, again I need a cite. I looked and I can't find anything other than comments that are 4+ years old at this time.

If there is truly an issue here I will look into it further as my group is one of licensees of Jungo drivers, but so far all I've seen is FUD for "closed source" code.

Ed McGettigan

-- Xilinx Inc.

Reply to
Ed McGettigan

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.