Re: ISE/EDK Kubuntu linux installation issues
- From: Ken Ryan <newsryan@xxxxxxxxxxxxxxxxxx>
- Date: Fri, 01 Jun 2007 02:39:17 GMT
Ken Ryan wrote:
Anyway, since you're just starting to install the cable drivers I'll
follow up my own post with a description of how I got the userspace
shim to work transparently..
OK here goes...
Note this applies to the USB driver. Theoretically it also works with the parallel cable, but I haven't tested it.
First, add the file /etc/udev/rules.d/xusbdfwu.rules as I described in my previous post. That gets the firmware loaded and device permissions set when you connect the usb cable. I *think* it's tailored narrowly enough to not open unwise permissions, but if it matters to you have someone with a clue about security look it over.
Next download the userspace shim sources from http://www.rmdir.de/~michael/xilinx/ and compile them. For those on a 64-bit OS, edit the Makefile and add -m32 to the CFLAGS variable to force a 32-bit compile.
Now, there seem to actually be only three binaries that try to communicate with the cable hardware:
$XILINX/bin/lin/_impact iMPACT bitstream downloader (core)
$CHIPSCOPE/bin/lin/cse Chipscope cable server
$XILINX_EDK/bin/lin/xmd Software debugger server
To use the driver shim, they each need the libusb_driver.so prelinked
to intercept the windrvr calls. On a pure 32-bit platform you could simply set the environment variable LD_PRELOAD to the full pathname of
the libusb_driver.so, but then the system attempts to prelink *all* of your binaries to that library. On a 64-bit platform this fails miserably.
So I did the following:
1. Copy libusb_driver.so to $XILINX/bin/lin/ to ensure it's available for all users of the system (in my case: me, myself and I but whatever).
2. Rename $XILINX/bin/lin/_impact to $XILINX/bin/lin/_impact.bin (note
'm renaming _impact not impact).
3. Create a shell script called $XILINX/bin/lin/_impact containing the following:
---VVV
#!/bin/sh
#
# Preload driver binary
LD_PRELOAD=$XILINX/bin/lin/libusb-driver.so $0.bin $*
---^^^
4. Ensure the script permissions are set with chmod +x.
5. Repeat steps 2-4 for the Chipscope and XMD binaries, as applicable. I use the identical script file in all three places; the $0.bin and different name ensures the right thing gets run.
6. Enjoy!
Note that installing a service pack may overwrite this hack (the EDK9.1.02 service pack did that to the xmd script). Just repeat steps 2-4 to fix it.
What's happening:
I initially just used a csh alias to include the LD_PRELOAD, but that only worked for direct command-line invocations. Running any of these from a GUI bypasses the shell. Similarly, putting a script in the search path doesn't work, as the GUIs seem to call their helper programs via a direct path. By putting an executable shell script directly in the places where callers look for it, you can add the prelink and the Linux system libaries will sort out whether it's executing a binary or a shell script.
The impact program was a bit weird, and threw me for a little while on my 64-bit box. The binary $XILINX/bin/lin/impact is what gets started, but after doing some initial stuff it then calls _impact to do the heavy lifting. I have no idea why that is so - perhaps _impact does the downloading and something else does the prom file preparation, and impact is just the front-end wrapper. It did have the bizarre behavior of working properly if I just ran impact alone, but if I added any command-line parameters it failed (the resulting message was highly misleading as well - failed to find libusb-driver.so even though the error message itself included the complete correct path...the clue was the error message was from tcsh not impact, indicating impact actually invoked my shell to execute _impact).
I have used impact, chipscope analyser.sh and xmd with this setup, both direct from the command line and impact/xmd from within the xps GUI.
If I were Xilinx I would jump on this userspace driver and can the kernel driver. Aside from debatable kernel module license issues, the userspace driver means users are mucking with their system a whole lot less, which *surely* has to reduce support calls! Three cheers to Michael Gernoth for his outstanding work in solving this problem (not to mention realizing it *could* be solved)!
ken
.
- Follow-Ups:
- References:
- Re: ISE/EDK Kubuntu linux installation issues
- From: Ken Ryan
- Re: ISE/EDK Kubuntu linux installation issues
- Prev by Date: Re: Xilinx Seminars in Wiesbaden, Berlin, Hannover
- Next by Date: Re: weird PACE Error, not one google result
- Previous by thread: Re: ISE/EDK Kubuntu linux installation issues
- Next by thread: Re: ISE/EDK Kubuntu linux installation issues
- Index(es):
Relevant Pages
|