Xilinx Platform Cable USB protocol specifications and/or ope

L

Laurent Pinchart

Guest
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
 
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.
 
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.
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
 
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.
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
 
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.
 
Hi,

And you're surprized that they're not giving away their design?
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.

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.
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
 
Laurent Pinchart wrote:
I want to buy a USB JTAG programmer that I can actually use with free
softwares. Why is there none available ?

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:
http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&getPagePath=22648

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

Ed McGettigan
--
Xilinx Inc.
 
Hi Ed,

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


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:

http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&getPagePath=22648

and the iMPACT software is included in the free WebPack download.
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
 
Laurent Pinchart wrote:
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
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.
 
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 (parallel
and USB).

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

---
 
Ed McGettigan wrote:
Laurent Pinchart wrote:
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


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


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.

The security problem is more like : "I don't want foreign closed-source
code running in kernel-mode on my machine".
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.

And linux is "supported" well ... I never managed to make the usb cable
work on linux (not a redhat) ...
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
 
Hi Uwe,

I have adapted so xc3stools can talk to XC3S via the FT2232 on USB. If you
are interested, talk to me.
Can you give me more information ? A quick search for xc3stools on google
didn't return any hit.

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.
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
 
Laurent Pinchart <laurent.pinchart@skynet.be> wrote:
....
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.
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
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
 
Laurent Pinchart <laurent.pinchart@skynet.be> wrote:
Hi Uwe,

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

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

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

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
 
Hi Ed,

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.
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
 
Laurent Pinchart wrote:
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.
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.
 

Welcome to EDABoard.com

Sponsor

Back
Top