"MM" <mbmsv@yahoo.com> wrote in message 
news:5cb28eF2v3r9cU1@mid.individual.net...
> OK, I am now a little bit stuck with the EDK... When I try to start it, it 
> says the following:
>
> _xps: error while loading shared libraries: libPortability.so : cannot 
> open shared object file : no such file or directory.

I found that this library is in fact in the ISE directory $XILINX/bin/lin. I 
copied it into $XILINX_EDK/bin/lin (which is set to LD_LIBRARY_PATH) and it 
complained about another library, which I also found in the ISE tree. After 
I copied a few dozens of these libraries xps finally started, but with a 
blank window :(

Arghh... What am I missing here?...

I am posting the same question on Ubuntu forum in the "Xilinx on Ubuntu" 
thread:
http://ubuntuforums.org/showthread.php?p=2763922#post2763922


Thanks,
/Mikhail

"MM" <mbmsv@yahoo.com> wrote in message 
news:5cb28eF2v3r9cU1@mid.individual.net...
> OK, I am now a little bit stuck with the EDK...

Having another problem :( I've decided to try installing the latest EDK 
service pack (SP2) and the installer refused to accept my Registration ID, 
which it happily accepted during the original EDK installation...

/Mikhail

"MM" <mbmsv@yahoo.com> wrote in message 
news:5cb28eF2v3r9cU1@mid.individual.net...
>
> Another thing I don't quite understand is why running 
> $XILINX_EDK/settings.sh script doesn's seem to have any effect on the 
> environment variables... So far I had to set some of them manually from 
> bash and some in /etc/environment...
>

For other linux newbies out there I figured this one out... Bash needs to be 
told that commands from the filename argument need to be executed in the 
_current_ shell context. Otherwise it will create another context, which 
will disappear as soon as the script ends... The way to tell this to bash is 
to precede the filename with a dot. Thus, assuming the settings.sh is made 
executable (and shebang added in the first line of the file) one has to do 
the following:

$ . settings.sh
and not
$ settings.sh

/Mikhail

OK, I am now a little bit stuck with the EDK... When I try to start it, it 
says the following:

_xps: error while loading shared libraries: libPortability.so : cannot open 
shared object file : no such file or directory.

If I set LD_ASSUME_KERNEL=2.4.7 (or 2.4.1) then it seems to break something 
severely in bash so that I can't even do printenv and xps doesn't start 
either... I suspect that the problem might have something to do with the 
fact that I have both libstdc++5 and libstdc++6 installed. According to the 
http://ubuntuforums.org:80/showthread.php?t=349336 only libstdc++5 is 
required, however I am not sure now at which point libstdc++6 was installed 
and what will I break if I try uninstalling it...

All other environment variables seem to be set correctly, at least in the 
bash session I am using to launch the app...ISE launches fine as well as 
Impact does...

Another thing I don't quite understand is why running 
$XILINX_EDK/settings.sh script doesn's seem to have any effect on the 
environment variables... So far I had to set some of them manually from bash 
and some in /etc/environment...


Thanks,
/Mikhail

On 2007-06-01, MM <mbmsv@yahoo.com> wrote:
> Another thing I don't quite understand is why running 
> $XILINX_EDK/settings.sh script doesn's seem to have any effect on the 
> environment variables... So far I had to set some of them manually from bash 
> and some in /etc/environment...

Just a quick comment regarding this..

Are you sourcing the settings.sh script as in the following?

> source $XILINX_EDK/settings.sh

Or are you running it as in
> sh $XILINX_EDK/settings.sh

If the later is true you will start a new subshell where the settings will
take effect and then happily disappear after the shell script has finished
running (which will occur in say a couple of microseconds after it has
started...)

If you are indeed sourcing the script I have no idea why it doesn't
work for you.

/Andreas

Hi Ken,

I had actually got the cable working before you posted your detailed 
instructions, but thanks a lot anyways, it's all very useful information!

I am now fighting the EDK, which doesn't want to start (the ISE seems to 
work fine), and the issues of equalizing the environment for all the 
possible ways of starting all of the Xilinx applications. I am just learning 
about how the environment variables are handled in Ubuntu and it is 
definitely not straightforward at all...At the moment my Impact works only 
when I start it from the shell... But I believe I am on the right track, 
just need a little bit of time to figure it all out...

> Three cheers to Michael Gernoth for his outstanding work in solving this 
> problem (not to mention realizing it *could* be solved)!

That is indeed a great achievement!!!

Thanks,
/Mikhail

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

MM wrote:
> Thanks a lot Ken!
> 
>> Depending what version of Kubuntu you're running, you may have other 
>> troubles.  For example, if you get errors referencing GLIBC you need
>> to set the environment variable LD_ASSUME_KERNEL=2.4.7 (this is not a
>> problem in recent releases of ISE/EDK).
> 
> I am running Kubuntu 7.04, 32-bit version and the 9.1 version of the Xilinx 
> tools. I don't recall seeing this error...

Good, that combination should be fine (one of my systems is Ubuntu 6.10, 
I had no trouble).

>> Getting a download cable to work is also a treat.  I recommend ignoring 
>> the Xilinx drivers and use the userspace driver from:
>>
>> http://www.rmdir.de/~michael/xilinx/
> 
> That's really a great advice! I was just in the middle of the process of 
> trying to install Xilinx drivers :) Hopefully I haven't broken anything yet 
> by half-working scripts :)

You'll still need the bit of the installation that handles usb firmware 
loading (fxload) and permissions settings, but a variant of it.

At the moment, the only Xilinx-related stuff in my system directories
is a file /etc/udev/rules.d/xusbdfwu.rules containing the following:

----VVV

SYSFS{idVendor}=="03fd", SYSFS{idProduct}=="0008", NAME="windrvr6"

BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd", 
SYSFS{idProduct}=="0007", RUN+="/sbin/fxload -v -t fx2 -I 
/usr/share/xusbdfwu.hex -D $TEMPNODE"

BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd", 
SYSFS{idProduct}=="0009", RUN+="/sbin/fxload -v -t fx2 -I 
/usr/share/xusbdfwu.hex -D $TEMPNODE"

BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd", 
SYSFS{idProduct}=="000b", RUN+="/sbin/fxload -v -t fx2 -I 
/usr/share/xusbdfwu.hex -D $TEMPNODE"

BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd", 
SYSFS{idProduct}=="000d", RUN+="/sbin/fxload -v -t fx2 -I 
/usr/share/xusbdfwu.hex -D $TEMPNODE"

BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd", 
SYSFS{idProduct}=="000f", RUN+="/sbin/fxload -v -t fx2 -I 
/usr/share/xusbdfwu.hex -D $TEMPNODE"

ACTION=="add", BUS=="usb", SYSFS{idVendor}=="03fd", 
SYSFS{idProduct}=="0008", MODE="0666"

----^^^

Since the above is almost certainly mangled by my mailer, I separated 
what should be single lines in the file with blank lines.  In other 
words, there is one line that starts with SYSFS{idVendor} and
ends with "windrvr6" (I think that line is actually not necessary,
but it's harmless), the next line starts with BUS=="usb" and ends
with $TEMPNODE, four more similar lines with different product IDs,
then a line that starts with ACTION and ends with "0666".

Note that the name of the file seems to be relavent - udev processes
rule files in order of filename, and getting the Xilinx stuff too early
seems to not work (i.e. I initially had this in a file "10-custom.rules"
but it didn't work there).  I don't understand udev well enough to
know why that makes it break.

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

>> I have it working for impact, chipscope analyzer, and XMD, at least
>> in all modes I actually use.  I can elaborate further all the fun I
>> had getting it to work on a 64-bit system, if that's something you'll
>> need (post here but CC my email to be sure I see it; I don't check
>> every day).
> 
> It's interesting. I was told in the past by Xilinx that EDK wasn't working 
> on 64-bit systems... Have they fixed it in 9.1 or have you found a 
> workaround?

EDK does not work with a 64-bit ISE installation.  I have both ISE and 
EDK installed as 32-bit applications.  The OS is the x86_64 version of
SuSE 9.3; the fact that all of the system binaries are 64 bit caused me 
some pain getting it installed and getting the userspace cable driver to 
work (to force the 32-bit ISE install, don't run setup at the top of the 
installation directory; cd to bin/lin and run it from there.  That is 
also needed for all the service packs and IP updates).  I have a 64-bit 
ISE installation standing by should I need it, but I haven't yet had a 
design big enough where it matters.  [Note that running 32 bit will be a 
bit faster, measurably so for long runs, due to the smaller pointer 
sizes getting fetched more efficiently by the CPU].

>> In any case, it works great on my Linux boxen which is a relief since
>> EDK does not get along with my laptop at all (multiple applications
>> built on top of Cygwin are not playing nice at all).
>>
>> Good luck, and drop me a note if you need more help.
> 
> Thanks again,
> /Mikhail 
> 
>