Xilinx Platform Cable USB protocol specifications and/or open-source firmware replacement
Laurent Pinchart
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
ghe...@lycos.com
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.
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
Antti
Laurent Pinchart
Has anyone started working on that ?
Laurent Pinchart
Laurent Pinchart
I came accross the Digilent JTAG-USB programming cable, but haven't been to
ghe...@lycos.com
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.
Laurent Pinchart
> 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
Ed McGettigan
>
> 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.
Laurent Pinchart
>> 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
Ed McGettigan
> 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.
mmihai
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.
---
Sylvain Munaut
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
ghe...@lycos.com
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.....
Uwe Bonnes
...
> 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 b...@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Laurent Pinchart
> 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
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
Uwe Bonnes
> 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
Felix Bertram
> 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
Ed McGettigan
> 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
> 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.
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.
Eric Smith
> 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.
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.
Eric Smith
> 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.
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
Felix Bertram
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
> The iMPACT software works with other devices in the chain by allowing
fpga...@yahoo.com
Ed McGettigan wrote:
> 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.
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.
> 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.
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.
Tobias Weingartner
> 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.
Sure. Give me access to a PCI bus master (say the IDE) device, and I
can splat whatever data it contains (say a binary I compiled) into whatever
portion of memory (say kernel address space) I want it to go.
Oh, you need a "cite"... Well, if you're in the "know" and understand
the implications, the following should make you cringe:
http://www.cansecwest.com/speakers.html#duflot
> 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.
If I get userland access to poke into I/O or device memory, I will take
over your machine.
--
[100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax
Laurent Pinchart
>> > 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.
>
> Sure. Give me access to a PCI bus master (say the IDE) device, and I
> can splat whatever data it contains (say a binary I compiled) into
> whatever portion of memory (say kernel address space) I want it to go.
That's exactly the point. WinDriver gives access to PCI devices from
userspace. Any PCI bus master can then be used to modify system memory.
There are many more ways to gain root privileges once you can access device
and/or system memory. Loďc Duflot published a very interesting paper
describing how to gain root access (and doing much more) using the AGP
aperture and SMM:
http://www.ssi.gouv.fr/fr/sciences/fichiers/lti/sstic2006-duflot-papier.pdf
> Oh, you need a "cite"... Well, if you're in the "know" and understand
> the implications, the following should make you cringe:
>
> http://www.cansecwest.com/speakers.html#duflot
>
>> 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.
How do you expect people to trust a closed-source driver which main purpose
is to enable userspace applications to access devices directly ? Especially
when there are safe open source multiplatform alternatives (libusb).
> If I get userland access to poke into I/O or device memory, I will take
> over your machine.
Laurent Pinchart
Ed McGettigan
> Ed McGettigan wrote:
>
> 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.
>
Xilinx has done nothing to deviate from the IEEE JTAG standards as
defined in the IEEE 1149.1 and IEEE 1532 specifications. All Xilinx
devices have corresponding JTAG BSDL files for both 1149.1 and 1532
publicly released both on our web site and in every software release.
These files fully conform to the appropriate IEEE specification.
These files and the IEEE standards are all that is needed for anyone to
create software and hardware to communicate with Xilinx devices through
the JTAG interface along with any other devices in the same chain.
If you do not like the software and hardware that we provide for this
function and if no one else does either then you should go ahead and
create what you want instead.
On the hardware comms front, Macraigor (http://www.macraigor.com)
sells various JTAG communication hardware and has (had??) GDB support
so you might want to start there first. I'm sure that there are
other providers out there as well that you can find if not then go
ahead and create your own JTAG communication hardware.
One thing is certain, if it meets the IEEE JTAG electrical specs and
wiggles the bits as defined in the IEEE standards it will work with
our devices.
fpga...@yahoo.com
Ed McGettigan wrote:
and again you completely missed the point.
Does Xilinx provide an open specification so that 3rd party software
can use your expensive JTAG interfaces?
Does Xilinx provide and open specification so that 3rd party JTAG
hardware interfaces are usable with expensive Xilinx software?
The complaint as I listen to this thread is that Xilinx does neither,
instead offering a closed development environment which allows neither
3rd party hardware or software interfaces, that also creates a trojan
root kit interface ... is that not the issue?
fpga...@yahoo.com
Ed McGettigan wrote:
> If you do not like the software and hardware that we provide for this
> function and if no one else does either then you should go ahead and
> create what you want instead.
Is that permission to replace the Xilinx bit stream tools by reverse
engineering and providing open source replacements?
The bitch ... is that Xilinx requires users to use the Xilinx usb
adapter to program, then unplug the Xilinx usb JTAG interface, from a
possibly live board, then plug another 3rd party (or home grown) JTAG
into the board to do testing or configuration of non-xilinx
device/functions on the JTAG buss, then reconnect the Xilinx usb JTAG
interface when it's necessary to reprogram a Xilinx part on the JTAG
chain.
First, this is POOR practice on a live board, and labor intensive in
any case. Second it's completely unnecessary, except for Xilinx's
refusal to provide open development tools interfaces for the JTAG
environment so that either a 3rd party usb adapter can be used, or 3rd
party software with your adapter.
Ed McGettigan
> Ed McGettigan wrote:
>
> and again you completely missed the point.
>
> Does Xilinx provide an open specification so that 3rd party software
> can use your expensive JTAG interfaces?
A IEEE 1149.1 and/or IEEE 1532 JTAG interface is available in all of our
modern FPGAs (not available in the XC2000, XC3000 and part of XC4000
families) for configuration, boundary scan and internal user extensions.
It is simple and easy to use with 4 pins TDI, TDO, TMS and TCK and
conforms to the public IEEE interface standards. We have chosen to not
implement the optional TRST pin. We have also chosen to implement allowed
optional extensions to permit internal USER scan chains. The JTAG
interface is not expensive to use.
All needed documentation on how to perform traditional JTAG boundary
scan can be found in the IEEE specification and the appropriate BSDL
file.
All needed documentation on how to configure a device from a binary
bitstream can be found in the IEEE specification and the appropriate
BSDL file and datasheet.
All needed documentation on how to create and use the internal USER
scan chains can be found in the IEEE specification and the appropriate
BSDL file and datasheet.
More information is also provided in Xilinx Application Note XAPP058
http://www.xilinx.com/bvdocs/appnotes/xapp058.pdf which documents
various consideration and even includes a C routing for JTAG
programming from a microprocessor.
It is not as hard as rocket science, but it is harder than falling
off a log.
> Does Xilinx provide and open specification so that 3rd party JTAG
> hardware interfaces are usable with expensive Xilinx software?
Xilinx software is designed to work with Xilinx communication cables
and some selected 3rd party equipment. Our software is tightly
coupled to the communication hardware and we do not provide general
access to the driver/software APIs.
Ed McGettigan
> Ed McGettigan wrote:
>> If you do not like the software and hardware that we provide for this
>> function and if no one else does either then you should go ahead and
>> create what you want instead.
>
> Is that permission to replace the Xilinx bit stream tools by reverse
> engineering and providing open source replacements?
Since the function that I was discussing was configuration through
iMPACT and a Xilinx USB JTAG cable and you have twisted this into
something completely different then of course your answer is no.
>
> The bitch ... is that Xilinx requires users to use the Xilinx usb
> adapter to program, then unplug the Xilinx usb JTAG interface, from a
> possibly live board, then plug another 3rd party (or home grown) JTAG
> into the board to do testing or configuration of non-xilinx
> device/functions on the JTAG buss, then reconnect the Xilinx usb JTAG
> interface when it's necessary to reprogram a Xilinx part on the JTAG
> chain.
There is no truth to this assertion. Our devices can be configured
by many, many, many different means. Hundreds, if not thousands, of
pages are available on www.xilinx.com describing how to take a generated
bitstream and use it configure a device.
fpga...@yahoo.com
Ed McGettigan wrote:
> fpga...@yahoo.com wrote:
> > Ed McGettigan wrote:
> >
> > and again you completely missed the point.
> >
> > Does Xilinx provide an open specification so that 3rd party software
> > can use your expensive JTAG interfaces?
Ok, interface is too general a term, as is cable, of which an active
usb device is more
than a cable, and hence refered to as an interface.
so,
Does Xilinx provide an open specification so that 3rd party software
can use your expensive "usb" JTAG interface devices/cables/converters?
Mike Harrison
AFAIK The only thing you can't do with a borrowed/made-up VID/PID is use the USB logo.
Andreas Ehliar
> 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.
At first I thought that I could take a shot at this, download the WinDriver
SDK and see if I could quickly figure out how the WinDriver API works.
However, I didn't have to do that since they have some nice sample programs
included in the WinDriver distribution:
-----------------------------------------------------------------------------
(This is all run as my normal user, not as root user.)
> cd WinDriver/util
> ls
files.txt isapnp_scan pci_diag pci_dump pci_scan usb_diag wddebug wddebug_gui wdreg
> ./pci_diag
PCI diagnostic utility.
Application accesses hardware using WinDriver
and a Kernel PlugIn driver (KP_PCI).
PCI main menu
--------------
1. Scan PCI bus
2. Find and open a PCI device
99. Exit
Enter option: 2
Enter vendor ID (to cancel press 'x'): 0x1002
Enter device ID (to cancel press 'x'): 0x5960
Found 1 matching device [ Vendor ID 0x1002, Device ID 0x5960 ]:
1. Vendor ID: 0x1002, Device ID: 0x5960
Location: Bus 0x1, Slot 0x0, Function 0x0
Memory range [BAR 0]: base 0xE8000000, size 0x8000000
I/O range [BAR 1]: base 0x2000, size 0x100
Memory range [BAR 2]: base 0xF8400000, size 0x10000
Interrupt: IRQ 10
PCI main menu
--------------
1. Scan PCI bus
2. Find and open a PCI device
3. Read/write memory and IO addresses on the device
4. Read/write the PCI configuration space
5. Enable/disable the device's interrupts
6. Register/unregister plug-and-play and power management events
99. Exit
Enter option: 3
Read/write the device's memory and IO ranges
---------------------------------------------
1. Change active address space for read/write (currently: BAR 0)
2. Change active read/write mode (currently: 32 bit)
3. Toggle active transfer type (currently: non-block transfers)
4. Read from active address space
5. Write to active address space
99. Exit menu
Enter option: 5
Enter offset to write to (to cancel press 'x'): 0x0
Enter data to write (max value: 0xFFFFFFFF) or 'x' to cancel: 0xffffffff
Wrote 0xFFFFFFFF to offset 0x0 in BAR 0
-----------------------------------------------------------------------------
At this point my upper left pixel turned white. I also managed to crash the PCI
bus (and the computer of course) by playing around with this program and reading
from the wrong address...
It seems that there are some ways around this according to comments posted at
http://freshmeat.net/projects/windriver/, but I'm not sure how you would go about
implementing that.
I wonder if the same problem will appear on the Windows version of WinDriver?
I don't really have time to test it myself at the moment though.
(And yes, I also think it would be much nicer if the Xilinx tools did not depend
on 3rd party kernel modules if it could be avoided.)
/Andreas
Peter Wallace
> 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
We have a tiny FTDI 2232 based JTAG dongle, just havent got around to
buiding them yet. Supports IO voltages from 1.6V to 5V (or 1.2V to 3.3V
using different level tranlators) Should be really cheap
~$25.00 or so, or bare PCBs for cost of shipping (Free!) I think there
are Linux drivers available for 2232.
Peter Wallace
fpga...@yahoo.com
Ed McGettigan wrote:
> > The bitch ... is that Xilinx requires users to use the Xilinx usb
> > adapter to program, then unplug the Xilinx usb JTAG interface, from a
> > possibly live board, then plug another 3rd party (or home grown) JTAG
> > into the board to do testing or configuration of non-xilinx
> > device/functions on the JTAG buss, then reconnect the Xilinx usb JTAG
> > interface when it's necessary to reprogram a Xilinx part on the JTAG
> > chain.
>
> There is no truth to this assertion. Our devices can be configured
> by many, many, many different means. Hundreds, if not thousands, of
> pages are available on www.xilinx.com describing how to take a generated
> bitstream and use it configure a device.
Then where is the documentation which describes the API for the Xilinx
USB JTAG interface/cable/adapter?
Eric Smith
> Xilinx software is designed to work with Xilinx communication cables
> and some selected 3rd party equipment. Our software is tightly
> coupled to the communication hardware and we do not provide general
> access to the driver/software APIs.
That's the part that we're questioning. If you had a publicly
documented API for the interface between Impact and the driver, you
could get two main benefits:
1) Third party hardware that came with drivers supporting your API,
so they could work with Impact.
2) Third party software (e.g., JTAG debuggers for various soft core
processors and the like) that could work with Xilinx cables (or with
the third party hardware in part 1).
Cost: A few weeks of an engineer's time to document the API. I suspect
that there's already an API document which would simply need to be
sanitized for public release.
Drawbacks:
1) Availability of third-party cables that work with Impact might
slightly reduce sales of PCIV and PCUSB. Presumably Xilinx doesn't
view PCIV and PCUSB as a major profit center, and it would overall
be of greater benefit to Xilinx's bottom line to have more third
party support even if it might slightly reduce the sales of PCIV and
PCUSB.
2) The API would be semi-frozen. Xilinx could change it with future
software releases, but then the third-party drivers and software
would have to be revised by those third parties. However, since
JTAG seems to be a reasonably mature interface, and Xilinx
presumably understands their own requirements for the JTAG API, it
seems unlikely that the API would need to be revised very often.
Eric
Luis Alberto Guanuco
> Laurent Pinchart <laurent....@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.
I am working with a JTAG-USB programmer based in FT2232D. The interface is the OOCDLink-s[0] board.
Can you give me any information about how you adapted a FPGA(Spartan 3) with FT2232 on USB? Thanks very much in advance.
Regards,
Luis
[0] http://www.xo2link.de/wp/?page_id=15
Uwe Bonnes
> El mi�rcoles, 17 de mayo de 2006 05:06:47 UTC-3, Uwe Bonnes escribi�:
> > ...
> > > 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.
> Hi Uwe Bonnes,
> I am working with a JTAG-USB programmer based in FT2232D. The interface
> is the OOCDLink-s[0] board. Can you give me any information about how
> you adapted a FPGA(Spartan 3) with FT2232 on USB? Thanks very much i
Look at the code for xc3sprog on the sourceforge SVN repository. Discuss
specific problems on the xc3sprog mailing list.