Papilio loader in 64-bit linux


Guest f_point

Recommended Posts

Guest f_point

Hello every one,

     

      I recently bought a Papilio One board (500K model) and have been toying  around with it. This is my second FPGA board and I must say that this  one is just great. It has lots of functionality on a rather small board  that can fit anywhere, with just exactly what I want it to have. FPGA  trainer boards are usually large compared to this one, and tend to have  lots of stuff that just gets in the way when it comes to making useful  projects. And, on top of it, it's very affordable.

     

      This board is working fine on a Windows Virtual Machine, but I'm trying  to get it to work directly in Linux. I'm currently running Kubuntu 11.04  together with Mint 10 KDE, both of them are 64-bit, but it seems I  can't get it to work in any of them.

     

      I downloaded the papilio downloader application from the papilio.cc  website, and tried to run the papilio_loader.sh script form the  Helper_App subdirectory. After getting the "dialog: command not found"  message I figured out that I was missing the dialog command line  program, so I installed the dialog package.

     

      With that out of the way I tried to run the program again, and was  immediately pleased to see the same confirmation screen as in windows Command box,  but right after that another error appeared:

     

      papilio-prog: error while loading shared libraries: libftdi.so.1: cannot open shared object file: No such file or directory

     

      I guessed again that I was missing another package. It wasn't hard to  realize that what I needed was the ftdi driver library (libftdi1), so i got it  installed. The problem didn't disappear tough, and this is where I'm  stuck. I also verified that the required file was actually installed  (It's located in /usr/lib64/libftdi.so.1).

     

      I'm guessing that the program is a 32-bit application and is unable to  use a 64-bit library, but I don't really know what to do in this  situation. I don't know if one can install a 32-bit library in a 64-bit  Linux OS (have been googling around for that and didn't get anywhere).  But even if that is possible, then there's a possibility that a lot of  libraries would be required besides the ia32-libs package for complete  runtime support.

     

      Also, an obvious solution would be to look for a 64-bit version of the  program, but so far I've not been able to find something like that on  the papilio.cc website. The only thing left is to compile the source to  manually generate a 64-bit binary, but since I'm not very good at  compiling code (lots of packages and running rather obscure scripts), I  would rather search for an alternate solution

     

      Maybe anyone here has found a solution yet for this? I would really appreciate it if someone helps me out.

 

  Thank you very much in advance.

     

Link to comment
Share on other sites

I never tried the precompiled binary versions, but the source code is actually very easy to compile under linux.

Download the source code (I guess you already have it in the tarball you downloaded), cd into the "Program" sub directory, and run "./autogen" (or whatever name that particular script have, I write this from memory), then "./configure" and "make". You'll want to run "make install" when you got it working, as usual.

"./configure" will fail with explicit messages if something is missing.

 

On my Ubuntu, I needed to install automake, g++, libftdi-dev, and perhaps one or two another packages (again, writing from memory)

BTW : there seems to be a bug in the latest version with the options parsing under Debian on a PowerBook (the getopt loop finds more arguments than given, and the extra ones raise an error => whatever you do, it shows usage and quit).

Link to comment
Share on other sites

BTW : there seems to be a bug in the latest version with the options parsing under Debian on a PowerBook (the getopt loop finds more arguments than given, and the extra ones raise an error => whatever you do, it shows usage and quit).

The result of getopt is put in a "char", then tested to "-1". It seems gcc on PowerPC uses unsigned char by default, so this doesn't work: adding "signed" in front of "char c;" at line 119 of butterfly.cpp fixed the issue.

As it cannot harm on other platforms, perhaps it would be a good idea to add it in the published code.

f_point: any progress ?

Link to comment
Share on other sites

Guest f_point

Hello ben,

At the beginning, I was a little hesitant with respect to compiling from source code, but I guess there is no other choice at the moment, as it seems that no 64-bit binaries are published.

I'm not running Debian on a PowerBook (I'm running Kubuntu on a Dell Laptop instead), so I guess the bug you mentioned should not affect me.

I did as you instructed, and installed the following packages: automake, g++ and libftdi-dev, along with their dependencies.

Running "./autogen" seemed to work fine, and 3 other files were generated: "./install-sh", "./missing" and "./depcomp"

However running "./configure" failed, and it showed quite a bunch of "checking" messages with apparent success, but the last 2 lines said this:

./configure: line 3868: syntax error near unexpected token `libftdi,'

./configure: line 3868: `      PKG_CHECK_MODULES(libftdi, libftdi >= 0.16,'

I'm pretty sure that I installed libftdi-dev (along with it's dependencies: libftdi1 and libusb-dev), so it's not a "missing library" problem. Is it maybe a version conflict problem? Or maybe I'm missing something or doing something wrong?

Thank you very much for your help, I really appreciate it.

Link to comment
Share on other sites

Guest f_point

It's a rather long script, so instead of copy/pasting it, I attached it as a file.

Had to rename it to contain a .txt extension as the forum didn't allow it to be uploaded as it was (without any extension).

Hope it helps.

configure.txt

Link to comment
Share on other sites

no idea.

I attach the code of a previous version, which compiled under my 32bit 386 ubuntu without problems -- same protocol. The configure script is different so maybe you'll be more lucky with it

I don't know what the latest additions to the source code were (beyond the renaming of butterflyprog to papilio-prog), but this is the version I use daily to upload bitfiles to  my papilio one and it works great.

butterfly-loader.zip

Link to comment
Share on other sites

Guest f_point

Hello again,

I've tried the program you uploaded without any success, unfortunately.

It seems that we've encountered some kind of strange problem here, as this program fails exactly in the same way as the first one. This probably has to do with some incompatibility issue between 32-bit and 64-bit versions of the operating systems or libraries, or maybe some old syntax feature that got removed in a newer version of some program (which now causes the syntax error).

I suppose we have stumbled upon a pretty obscure error here...

Any ideas?

Link to comment
Share on other sites

Guest f_point

Since this is presumably an operating system version/plattform issue, I'll post my current settings:

 

  Operating System: Kubuntu Linux 11.04 (64-bit edition)

 

  Computer: Dell Vostro 1320 (Notebook), with Core2 duo processor @  2.40GHz, 3GB RAM / 4GB Swap partition, nVidia GeForce 9300M GS graphics  adapter.

 

  Major Tweaks/packages added:

  KDE version upgraded to 4.6.5 via upstream repository (http://ppa.launchpad.net/kubuntu-ppa/ppa/ubuntu)

  Xserver and propietary graphics driver upgraded via upstream repository (http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu)

 

  Many other things are just minor tweaks to be listed, but it's worth  mentioning that the system is kept up to date so there aren't many  outdated programs except those that are rarely updated in the  repositories.

 

  Maybe this can help in reproducing the error.

 

Link to comment
Share on other sites

It seems that we've encountered some kind of strange problem here, as this program fails exactly in the same way as the first one. This probably has to do with some incompatibility issue between 32-bit and 64-bit versions of the operating systems or libraries, or maybe some old syntax feature that got removed in a newer version of some program (which now causes the syntax error).

looking again in the files, I'd rather say this is an automake issue. It seems the PKG_CHECK_MODULES macro is not expanded on your machine. It should be defined in the aclocal.m4 generated by aclocal: could you check it, eg with 'grep PKG_CHECK_MODULES aclocal.m4' ? if it is not there, there must be something wrong with your install. Not being an expert at all, I would try to reinstall pkg-config.

to get the Makefile to work quickly, you still have the option of commenting out the whole "PKG_CHECK_MODULES" with # in configure.ac, and replace it with its result, namely

LIBS="$LIBS -lftdi"

then run autogen, configure and make. I just tried it on my Debian, and it works fine.

Hope this helps.

Link to comment
Share on other sites

Hello f_point,

Another route to try is that there is a Linux virtual machine that you can run under VMWare to give you a frame of reference.

http://papilio.cc/index.php?n=Papilio.QuickstartLinux

I made the VM for situations where people were struggling with drivers or compilation.

Does anyone out there have a version of the Papilio Loader compiled for a 64 bit Linux system? If so I can just include it in the next version of the Papilio Loader.

Jack.

Link to comment
Share on other sites

Guest f_point

looking again in the files, I'd rather say this is an automake issue. It seems the PKG_CHECK_MODULES macro is not expanded on your machine. It should be defined in the aclocal.m4 generated by aclocal: could you check it, eg with 'grep PKG_CHECK_MODULES aclocal.m4' ? if it is not there, there must be something wrong with your install. Not being an expert at all, I would try to reinstall pkg-config.

Bingo! It's working now!

Turns out I was missing the package pkg-config, so there was no PKG_CHECK_MODULES macro in aclocal.m4 as you suspected. After I ran the command 'grep PKG_CHECK_MODULES aclocal.m4' there was no response (the string was not found), so I went to check on the package just as you said and found out it was not installed, so I installed it.

After that, it was a simple matter of running everything agan: './autogen.sh', './configure' (no error this time), and finally 'make'. And there it was - a 64-bit program called papilio-prog!

Just had to try it out immediately, so after playing around with it (It's so good when programs show their possible arguments when run alone), I found out how to use it with relative ease, and it works perfectly well. Now I can program the papilio board without a virtual machine!

Well, that pretty much solved my issue, so thank you very much ben!

There is another issue tough, but I'm guessing you already know about it, and it's about transfer performance when programming the SPI flash. It takes a while to get the flash programmed, even with small designs (tried it with a design less than 20 lines of VHDL code). So I ran the program with the 'time' command to time it, and it registered 9m39.732s

I know that flash memories are terribly slow when written to, but this program is a bit too slow IMHO. It's not that it matters waiting (after all, for debugging purposes, programming the FPGA directly is lightning-fast - less than 1s), but it would be great if it were a bit faster just for convenience.

Another (minor) issue is that root (sudo) privilegies are required to program the board. I think this is a somewhat normal OS issue, but I'm mentioning it for those that may read this thread and are having a similar problem. I remember there was a solution for that kind of issue that involved changing access permissions to USB devices, but I already forgot how to do it.

Link to comment
Share on other sites

Guest f_point

Hello f_point,

Another route to try is that there is a Linux virtual machine that you can run under VMWare to give you a frame of reference.

http://papilio.cc/index.php?n=Papilio.QuickstartLinux

I made the VM for situations where people were struggling with drivers or compilation.

Does anyone out there have a version of the Papilio Loader compiled for a 64 bit Linux system? If so I can just include it in the next version of the Papilio Loader.

Jack.

Hello Jack,

I'm afraid that my main objective was to be able to program the papilio board without a virtual machine (mostly due to performance and laptop battery life issues), but thank you very much for the help.

Since I just managed to compile the papilio loader in a 64-bit Linux OS, I'm uploading the entire archive that was used with all the modifications done to it.

The exact process done to the archive was:

- unpack the archive into hard disk

- cd to 'Program' subdirectory in a terminal

- run ./autogen.sh

- run ./configure

- run make

- repack everything again

I've compiled it under Kubuntu 11.04 (64-bit), the following packages were added for complete support:

automake

g++

libftdi-dev

pkg-config

The archive has the same name that it had when I got it from the papilio.cc website. It was downloaded from the "getting started" -> "Linux" section, from the first link under the paragraph titled "Linux Binaries", (I suppose that this is the latest version).

The other files in the archive should be unaffected, in particular the file 'Helper_App/linbin/papilio-prog" wich is the 32-bit executable and got included along unaffected.

I think It should run without problems in the latest Ubuntu 11.04  (64-bit) and all of it's derivatives (Including Mint 11), as they share  the same package base and the program is just a terminal application  which does not depend on any desktop environment.

 

Hope this is useful.

GadgetFactory-Papilio-Loader-86a6be9.zip

Link to comment
Share on other sites

f_point,

Wow, 9 minutes to program SPI Flash! That is definitely not right, it should be taking 30-40 seconds, and that is longer then it should take. The SST Flash chip support that I added could use some more work it looks like. I just added quick and dirty support and kept meaning to come back to it later. :) We should be able to program the flash in 3-4 seconds.

I guess fixing the SST Flash chip support needs to be a priority...

Jack.

Link to comment
Share on other sites

Guest f_point

I did another programming test today, this time with a custom core (an arduino/AVR core with extra PWM channels). This used about 35% of all the available slices, and took about the same amount of time to upload (9m34s). So I'm learning from this that programming time does no vary with used capacity - Just imagine it taking even longer!  :o .

Just in case you din't know, the papilio board isn't the only one that takes a long time to program. I also own a Nexys 2 board from Digilent, and uploading to flash configuration memory takes about 2 minutes under normal conditions (using windows with proper drivers installed, with a USB 2.0 host). So I don't see this as a major issue, considering that programming does actually work.

In any case, it'd be great if you managed to make it work faster. I'll be looking forward to it  :D

Link to comment
Share on other sites

  • 1 month later...

I recently noticed that the papilio-prog utility program was updated about a couple weeks ago, with a fix for the programming speed problem  :D , so I definitely had to give it a go and let you know the results for your reference.

 

So far, the programming speed has improved significantly, taking only  28.689s to finish (measured with "time" command) - Just great! now I can simply wait for it to finish instead of looking for something else to do meanwhile!

 

Thank you very much Jack for taking the time to fix it, I really appreciate it, and surely every Papilio+Linux user out there will appreciate it too.

Link to comment
Share on other sites

Thank you for the feedback. :) It's good to hear its working for everyone so far.

29 seconds is still longer then it should be... I guess I should see if I can replicate that under linux. On Windows it takes about 5 seconds to program...

29 seconds is a LOT better then the crazy times you were seeing before. I'm going to put this on my task list to look into later.

Jack.

Link to comment
Share on other sites

  • 2 years later...

This thread had all the info needed for me to recompile the papilio-prog binary for 64bit Ubuntu.  But this thread is from 2011.  So why is this still necessary?  I really do appreciate all the work that's gone into the loader, but can we get 64bit support in the std release?  Here is what I had to do to get it working for 64bit Ubuntu...  I had to recompile (as suggested in this thread) and then overwrite the symbolic link that pointed to the 32bit binary in /usr/local/bin.  It seems that there isn't a long way to go to be able to support 32bit AND 64bit.

 

Cory

 

Link to comment
Share on other sites

  • 1 month later...

Bingo! It's working now!

Turns out I was missing the package pkg-config, so there was no PKG_CHECK_MODULES macro in aclocal.m4 as you suspected. After I ran the command 'grep PKG_CHECK_MODULES aclocal.m4' there was no response (the string was not found), so I went to check on the package just as you said and found out it was not installed, so I installed it.

After that, it was a simple matter of running everything agan: './autogen.sh', './configure' (no error this time), and finally 'make'. And there it was - a 64-bit program called papilio-prog!

Just had to try it out immediately, so after playing around with it (It's so good when programs show their possible arguments when run alone), I found out how to use it with relative ease, and it works perfectly well. Now I can program the papilio board without a virtual machine!

Well, that pretty much solved my issue, so thank you very much ben!

<snip>

 

Thanks for finding this! It was the only thing stopping me from building a Windows version of the programmer on a Lubuntu VM.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.