Xilinx Platform Cable USB protocol specifications and/or ope

[Ed McGettigan]

Felix Bertram wrote:

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.

Ed McGettigan
--
Xilinx Inc.

 

[Eric Smith]

ghelbig@lycos.com writes:

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]

Ed McGettigan <ed.mcgettigan@xilinx.com> writes:

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]

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

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.

 

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.

 

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

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]

fpga_toys@yahoo.com wrote:

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.

Ed McGettigan
--
Xilinx Inc.

 

[Tobias Weingartner]

In article <e4fi31$etu1@cliff.xsj.xilinx.com>, Ed McGettigan wrote:

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

 

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?

 

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]

fpga_toys@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?

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

 

[Ed McGettigan]

fpga_toys@yahoo.com wrote:

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.

Ed McGettigan
--
Xilinx Inc.

 

Ed McGettigan wrote:

fpga_toys@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]

On 17 May 2006 12:35:23 -0700, Eric Smith <eric@brouhaha.com> wrote:

ghelbig@lycos.com writes:
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.

AFAIK The only thing you can't do with a borrowed/made-up VID/PID is use the USB logo.

 

[Andreas Ehliar]

On 2006-05-17, Ed McGettigan <ed.mcgettigan@xilinx.com> wrote:

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]

On Tue, 16 May 2006 16:33:35 -0700, Laurent Pinchart wrote:

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

 

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]

Ed McGettigan <ed.mcgettigan@xilinx.com> writes:

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]

El miércoles, 17 de mayo de 2006 05:06:47 UTC-3, Uwe Bonnes escribió:

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.

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

Regards,

Luis

[0] http://www.xo2link.de/wp/?page_id=15

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

 

[Uwe Bonnes]

Luis Alberto Guanuco <guanucoluis@gmail.com> wrote:

El miércoles, 17 de mayo de 2006 05:06:47 UTC-3, Uwe Bonnes escribió:
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.

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

Look at the code for xc3sprog on the sourceforge SVN repository. Discuss
specific problems on the xc3sprog mailing list.

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

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