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

not directly available. RE needed

Has anyone started working on that ?

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

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,

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

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

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

Ed McGettigan
--
Xilinx Inc.

Hi Ed,

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

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[s] (parallel
and USB).

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

---

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

...

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                b...@elektron.ikp.physik.tu-darmstadt.de

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

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

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

s/xc3stool/xc3sprog

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

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

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

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.

The iMPACT software works with other devices in the chain by allowing you to
specify a BSDL file for the device when it doesn't recognize it.  The iMPACT
software also allows you to generate arbitrary JTAG sequences in order to do
anything that you want to do.  If you want to generate a program to improve
your ability to do this then run iMPACT in batch/command line mode and have
your program control iMPACT.

I would also suggest using a product like Universal Scan (http://www.universalscan.com/)
I've not used it personally, but I did have a conversation with the principal developer
a few years ago and it seems like a nice light weight tool to do exactly what you
want to do.  I think that it might be Windows only though.

Or, if the pins that you want to toggle are from a Xilinx device, then I would
suggest using ChipScope Pro with a VIO (Virtual I/O) core attached to the pins for
an even simpler product and it includes FPGA configuration capabilities. ChipScope Pro
does work on Linux.

Ed McGettigan
--
Xilinx Inc.

Why?  Xilinx doesn't have a copyright, trademark, patent, or trade
secret on their USB vendor ID.  I don't recall that I've ever signed a
contract with Xilinx (or anyone else) stating that I would not use the
Xilinx USB vendor ID for something else (e.g., a Xilinx-compatible
cable).

Anyhow, you could always ship a product with some other USB vendor ID,
and supply a tool that allowed the user to change the vendor ID to
any numeric value of his or her choice.

Doesn't work on 64-bit Linux.  Jungo supports 64-bit, but Xilinx only
supplies 32-bit versions of the proprietary binaries that get linked to
the Jungo code.

Please, please, please support 64-bit Linux in 8.2i, or at least in
8.2i SP1.

Thanks!
Eric

Hi Ed,

thank you for your reply and setup suggestions. Unfortunately this only
partly addresses my wishes. Just two (and a half) examples:

1) Think about a development board, that connects to a host PC via USB
or Ethernet. It would be nice, if a vendor could supply a driver, and
integrate the board with Impact. To do so, Impact would need to be able
to talk to third party JTAG drivers. As board vendors cannot do this,
every vendor is forced to provide his own configuration tool- which is
really not the way things should look like.

2) When talking about pin toggling: I am not talking about a few toggle
events, which I could do with a GUI. I am looking for an environment,
where I can program complex toggle sequences. While I am happy to do the
development of the required JTAG library myself, I would need to be able
to access the JTAG cable easily. It would be nice to use the existing
Xilinx cable- unfortunately the API is not disclosed.

3) Now think about a reason to combine both of the above setups without
switching cable hardware, setting jumpers and changing flying leads...

Ed, I do understand that this kind of applications is not your primary
interest. Still, it does not always help here to try and teach the
engineer to do it a different way, as there are probably good reasons,
why the engineer wanted to do so. While a technology leader will
definitely need to do some evangelism, it is sometimes a nice marketing
approach to listen to the customer (even if it is a smaller one).

Best regards, Felix

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

Ed ... you missed the point. JTAG is "supposed" to be an open standard
interface,
usable for a large number of in system interfaces, and Xilinx is
turnning it into another
proprietay closed interface with VERY limited static sequences exported
to the user.

Consider that JTAG is the ideal port to introduce a source level
debbugger interface
into HLL reconfigurable computing netlists, which would require an open
interface to
plug a gdb/ddd backend onto. Having to create one JTAG chain for Xilinx
tools, and
one each for other vendors tools, and a separate one for your own
debbuging tools
is a total crock, and violation of what is "supposed" to be an open
interface standard
test port.

Open source is not about "free", is about the ability to preserve the
right and ability
to take and modify the tools to do what you need/want, and not be stuck
with the
bugs and lack of features (because the vendor lacks the resources to do
it right)
that you need. Or because the vendor obsoleted the product,
discontinued support,
and orphaned your VERY EXPENSIVE hardware that is only a year or two
old
(read XC4085XL and XC40150XV reconfigurable computing boards).

Xilinx may move rapidly in the market, but products built with Xilinx
parts must be
supportable for a reasonable life of 7-10 years or more.  Current
Xilinx polices which
violate this sensibility are ....

Open source is Xilinx's friend in this respect, and provides a user
community
supported path to pick up the pieces when Xilinx commits these gross
errors
in product life support from and OEM and End User perspective.

Yet another proprietary expensive tool. Probably only supported on a
proprietary
platform (Redhat Enterprise).  Linux support is not about proprietary
RE, it's
about supporting Fedora, SuSE, Debian, ubuntu, etc in an "open source"
not "free
proprietary" way.  That can include proprietary binary applications,
but properly
maintaining open source interfaces and NOT locking other open
interfaces like
JTAG to also be proprietary in the process.

I'm all for proprietary software and products which create pay checks
for programmers,
but when that is integrated with open source and open interface
standards, it should
be done in a sensible way that doesn't violate the openness of those
standards.
Proprietay JTAG interfaces, violates the openness of that standard.