Linux?

[Guest Bert Vermeulen]

Is there a version of the butterfly loader for linux? The download of the 1.3 version appears to be windows-only...

[Jack Gassett]

I'm afraid I haven't been able to make a version for Linux yet. But it is very possible to do so, the Butterfly_prog application that is the heart of the butterfly loader should compile under Linux.

The source code for the Butterfly_prog application is here.

I'm putting it on my To do list to compile it for Linux.

Jack.

[Guest Bert Vermeulen]

I've had a look at the code, and it seems unlikely to be very simple. The FTDI comms code uses the static FTDI library for windows, i.e. the closed source vendor-provided userspace part of the windows-only driver. That's never going to work on Linux.

Typically you'd use libftdi (http://www.intra2net.com/en/developer/libftdi/) on linux for this. It's the userspace part of things, like ftd2xx.lib. It might be worth it to consider moving the code over to libftdi though -- apparently you pull in (an older) version of libusb, and compile it with mingw. That would at least make the loader cross-platorm.

You could also #ifdef out the gettimeofday() implementation in tools.cpp then ;-)

[Jack Gassett]

Hey Bert,

Until the newer butterfly_prog application is ported to linux there is an option with an older version of the Butterfly Loader. I guess I should have thought of this in the first place! I spent a lot of time tracking down a patch that allowed urjtag to work under Linux, its funny that I forgot about that pain so easily.

http://gadgetforge.gadgetfactory.net/gf/download/frsrelease/114/289/Butterfly_Loader1.1.zip

The 1.1 version used urjtag as the programmer, there is a linux script and the jtag_lin is a linux version of urjtag that I had to patch to get working right.

So it should work for you right now until we can figure out the newer version.

Jack.

[Guest Bert Vermeulen]

I was not aware of urjtag, and that it could be used to program the board.  I ended up just installing the version that comes with ubuntu (0.9 r1476) and writing a wrapper script around that -- works like a charm.

I also had a shot at getting the butterfly loader 1.3 working on linux. I got it to compile -- turns out the FTDI-specific code is in a file taken from another project which can use libftdi, so it wasn't as bad as all that. The compiled binary can talk to the board, so certainly the low-level comms part of that is ok.

However, actually programming a new bitstream doesn't work. Looks like my version of the papilio one has a flash chip which is not yet supported by the loader. It's a 4M part, AT45DB081D. I tried adding support for it (patch attached), but it bombs out on the first page while programming though.

Unlike the other already supported flash chips, this one appears to have a 256/264 pagesize mode. I've tried both, but no joy. I suspect some code for selecting the pagesize might have to be added.

For now, the patches I had to make to the 1.3 butterfly loader are rough -- I stomped all over the windows-specific parts -- so not quite ready for production. It might actually compile for windows with MinGW though. I've also made an autoconf setup for it. Can you tell me how you'd like to go forward with this? Keep it windows-only, cross-platform, two separate builds, etc. My preference would be to aim for a build on linux, then try and get it working with MinGW. But then I just don't care about windows though.

[Jack Gassett]

Hello Bert,

The Windows version of the butterfly_prog application supports the 8M AT45DB081D. Jochem added the AT45DB081D support and sent me an update, I guess the updated code never made it into svn. Let me try to backtrack and see if I can find the code Jochem sent me for the AT45DB081D and get it checked into svn.

My preference for tools like this is a linux version that is compiled for Windows using MinGW.

[Jack Gassett]

Ok,

I was able to find the updated code and it is checked into svn now. So if you update from svn there should be support for the AT45DB081D now.

[Guest Bert Vermeulen]

That's really the same patch (with some more targets) as I had, and it doesn't work on my board... this is what I get:

[tt]

sumner: ./butterflyloader -v -sa -b ../Fpga/bscan_spi_xc3s250e.bit -f ~/workspace/pbled/pbled.bit

Using built-in device list

JTAG chainpos: 0 Device IDCODE = 0x11c1a093 Desc: XC3S250E

Uploading "../Fpga/bscan_spi_xc3s250e.bit". Done.

Programming time 109.0 ms

Programming External Flash Memory with "/home/bert/workspace/pbled/pbled.bit".

Found Atmel Flash (Pages=4096, Page Size=264 bytes, 8650752 bits).

Erasing    :.Failed (@ Page: 1)

Error occured.

USB transactions: Write 48 read 13 retries 11

[/tt]

Do you have a board with this part? I'd really like to be sure I'm not doing something totally boneheaded here...

[Guest oliv]

Hi Bert,

I think you made a pretty good job with your linux port. I'm eager to test it.

If you wish you can post your code here, as an attachment.

I think, if Jack agrees with this idea, that a linux branch should be created alongside the current windows branch. Obviously, keeping in mind that it is desirable to have a unique and cross-platform version of the code.

Concerning the problem in your previous message, did you manage to find anything? Just a stupid a question : Is it happening on windows too?

[Guest oliv]

Hi,

I was too impatient and modified the code myself (to make it run on linux).

It seems to work.

I made some tests with the following files :

* DESIGN = ASCIITable_Quickstart.bit # provided in the 1.3 release

* BSCAN = ../Fpga/bscan_spi_xc3s250e.bit

The test protocol is minimalistic : I check if the board outputs ASCII values as expected.

_______TEST 1________

# Command line

[tt]./butter -v -f $DESIGN[/tt]

# Output

[tt]

Using built-in device list

JTAG chainpos: 0 Device IDCODE = 0x11c1a093 Desc: XC3S250E

Uploading "../../../Butterfly_Loader1.3/bitstream_archive/ASCIITable_Quickstart.bit". Done.

Programming time 327.8 ms

USB transactions: Write 86 read 2 retries 4

[/tt]

# Comment

test ok

_______TEST 2________

# Command line

[tt]./butter -v -f $DESIGN -b $BSCAN[/tt]

# Output :

[tt]

Found Atmel Flash (Pages=4096, Page Size=264 bytes, 8650752 bits).

Erasing    :................................................................Ok

Verifying  :................................................................Pass

Pogramming :..........Ok

Verifying  :..........Pass

Done.

SPI execution time 99382.5 ms

USB transactions: Write 14250 read 14214 retries 23164

[/tt]

# Comment :

Test ok but I have to replug the board.

I wonder if the the SPI execution time is normal (100s) and there is a lot of retries.

[Guest oliv]

I attached the modified version of the code here.

Caveat : it was working with me but only thanks to black magic. If you want to have an idea, just do "g++ -Wall -c *.cpp" or take a look at the implementation of the windows Sleep() function.

You can compile it as follow (there is no Makefile).

g++ -c *.cpp

g++ -lftdi *.o -o butter

You will need to get the GPL ftdi driver from http://www.intra2net.com/en/developer/libftdi/. On debian, simply install the package libftdi-dev

I'm curious to know if it still compiles on windows. You will have to set the variables __WIN32__ and USE_FTD2XX

EDIT : I removed the warnings I got with -Wall flag. It was actually nothing to worry about. I updated the file in the attachement, too.

[Guest oliv]

I made another test using the linux version of the proprietary driver provided by ftdi.

This is the output :

[tt]Using built-in device list

JTAG chainpos: 0 Device IDCODE = 0x11c1a093 Desc: XC3S250E

Uploading "../Fpga/bscan_spi_xc3s250e.bit". Done.

Programming time 143.1 ms

Programming External Flash Memory with "../../../Butterfly_Loader1.3/bitstream_archive/ASCIITable_Quickstart.bit".

Found Atmel Flash (Pages=4096, Page Size=264 bytes, 8650752 bits).

Erasing    :................................................................Ok

Verifying  :................................................................Pass

Pogramming :..........Ok

Verifying  :..........Pass

Done.

SPI execution time 65949.9 ms

USB transactions: Write 14250 read 14214 retries 0

[/tt]

As you can see, the programming is 1.5 times faster, and most importantly there is 0 retries. (it is certainly a causal relationship)

Nevertheless I think it is intesting to support the open source version.

If you want to do the test yourself, download the driver from http://www.ftdichip.com/Drivers/D2XX.htm.

Put the files ftd2xx.h libftd2xx.a.0.4.16 and WinTypes.h in the project directory. There is already a file ftd2xx.h but it is an old version.

Now recompile :

g++ -DUSE_FTD2XX -c *.cpp

g++ *.o libftd2xx.a.0.4.16 -lpthread -ldl -o butter

(pthread and dl are needed by libftd2xx.a.0.4.16)

[Guest Bert Vermeulen]

Oliv,

I've checked in my own port to linux, and added an autotools build system with cross-compile to windows. Can you update to the latest from SVN and see what diffs there are with your version? That problem with Sleep() and the -Wall warnings are still there, so it would be great if you could submit those (and whatever else).

You can either post a patch here, or create an account on gadgetforge and ask Jack for developer status on that project, so you can submit into SVN directly.

[Jack Gassett]

@Oliv

I just added you as a contributor to the Butterfly Loader project. Sorry it took so long, the request ended up in my Junk folder.

Jack.

[Guest oliv]

Hi,

I made some updates today. The change I made were essentially to remove the -Wall warnings and to get the compilation toolchain to work for me.

--> Please check my changes and see if it is still working on your side.

I removed the binary executable butterflyloader.exe.

PS : I forgot to commit a fix for a last -Wall warning.  However http://gadgetforge.gadgetfactory.net is unreachable for now!

[Guest Bert Vermeulen]

oliv,

The -DWINDOWS thing would have been because I wasn't including config.h in the right cpp files, which was kind of the whole point of the autotools thing

That should be fixed now, and -Wall is now the default as well.

Can you verify that this builds/works for you on windows?

gadgetforge is often slow or down, not sure what causes it.

[Jack Gassett]

I tested the auto-tools generated system and was able to compile both the linux and Windows executables. I had some trouble until I upgraded to Ubuntu 9.10 and then everything just worked great.

I hope to add support for the SST SST25VF040B and Numonyx M25P40-VMN6TPB SPI flash chips pretty soon here. I took a quick look and it looks like it will be easy for the Numonyx chip because it uses the same paging structure as the existing Atmel SPI Flash chips. But it will be more work for the SST chips because they use a completely different scheme.

Please keep me posted if gadgetforge continues to be slow, I use a VPS for gadgetforge and ever since they "Upgraded" their server I have been seeing strange things. It might be time to migrate to a new VPS service if people are being affected by it. Personally I've been thinking that the main website and forums have been slow and have been thinking about moving that to a different provider. But the problem is all of that web work takes away time for development of the Papilio Platform.

Jack.

[Guest oliv]

Hi,

Just a few words to say I built some DEB packages during the weekend. I attached in this message two "samples". One is for debian squeeze (testing) 32bits and the other for Ubuntu 9.10 32bits.

Obviously it is possible to build packages for other deb-centric distributions (in a chroot environment for example)

If you have time test it.

There is still some tuning to do though and not the most exciting part. Writing the Changelog, the MAN pages, and the copyright are some good examples.

I changed the name of the program. It is now "papilioloader". Tell me if you find it appropriate.

I forgot to add the vhdl files in the package. Perhaps it could be provided in the form of an extra package. Something like papilioloader-data ?

EDIT:

This is what I do to build a package (for testing purpose only)

$ cd ~

$ mkdir packaging

$ cd packaging

$ cp -r path/to/branches/papilioloader .

$ cd papilioloader

$ cp -r path/to/branches/debian .

$ ./autogen.sh

$ dpkg-buildpackage -b -us -uc

-oliv

[Guest Bert Vermeulen]

Cool as binary distributed packages are (and these deserve a spot in a download section, Jack), I've been wondering if maybe it's not a better idea to add support for the various flash chips in the papilio series into the urjtag project instead. That would be a benefit for much more than just the papilio boards.

[Guest oliv]

I just found this exciting piece of news on the urjtag mailing list :

Michael Walle - 2010-08-29 21:34

Add PLD support

This adds support for Xilinx FPGA devices. The following operations are possible:

- configure the FPGA with a bitstream

- force a reconfiguration (based on the mode pins)

- read and write configuration registers

- read and decode status (register)

Besides benefits in development (by being able to configure a FPGA) it

supports production of boards with NOR flashes connected to the FPGA. You can

load a fjmem core into the FPGA and program (fast!) the flash through it.

  /..... snip ..... /

See the complete thread at :

http://sourceforge.net/mailarchive/forum.php?thread_name=201009121552.29055.vapier%40gentoo.org&forum_name=urjtag-development

I don't know how much work it will involve to make it interact with the papilio board, but it sounds promising!

-oliv

[Jack Gassett]

@oliv

Awesome! Thank you for putting the binary deb packages together. I will verify they work for me on Ubuntu and then get them up for download. Changing the name to papilioloader is fine for now but based on Bert's suggestions I think we might want to change it back to xc3sprog and merge back with the original project.

@Bert and @oliv

We used to use urjtag but switched to our own fork of xc3sprog because it had support to program flash chips, was a lot simpler to use, and was actually faster. The reason for the fork was because Girish had to make some changes for xc3sprog to work correctly with the Spartan 3E chip if I remember correctly. Then Jochem made the Flash programming portion work correctly and somewhere along the way it was renamed to butterfly_loader instead of xc3sprog. I think the best thing to do here is to try and merge back with the xc3sprog project so any changes we make have a wider audience.

I want to head in the direction of a cross platform GUI that will have an installer and will package up all the things that can be done with the Papilio One into one application. So you just start up the application and select available projects such as "Logic Analyzer" and you can read the documentation for the Logic Analyzer, download source, choose to program over JTAG, or program to the permanent Flash; all from one convenient location.

BTW, You guys might be interested in the new project I'm working on right now, it is an Arcade Wing for the Papilio One. It will add a VGA port, Joystick port, and stereo audio into one Wing so classic Arcade games can be accurately recreated on the Papilio One. Right now I have a prototype running Pac-Man, I will be adding pictures and video to the blogs and the new forum board soon. I would greatly appreciate any input you might have!

Thanks,

Jack.

[Jack Gassett]

Girish and I are going to push hard over this upcoming weekend to work on a Papilio Loader GUI that I was talking about above. There is a new forum for discussion about the new app.