Cairnsmore1 - Quad XC6SLX150 Board

[ebereon]

The controller update worked, no problem here.

Dip switches are set as the PDF shows.

Now i want to programm the FPGA 0 and 3. This is only working with the temporary version:
xc3sprog –c cm1 –p 0 twin_test.bit
xc3sprog –c cm1 –p 3 twin_test.bit

But, Programming the Bitstream into the SPI Flash on the Array is not working:
xc3sprog –c cm1 –p 0 –I xc6lx150.bit twin_test.bit
xc3sprog –c cm1 –p 3 –I xc6lx150.bit twin_test.bit

If i try this, I get the error msg from my previous post.

At the moment FPGA 0 and 3 in the "Temporary Programming" mode have the orange led's on and if they got work it turn the orange led off and a second later it turns again on. the hashrate is about 40Mh/s.    Yesterday i got 380Mh/s in 1 hour average and 10 hours later they had only 40Mh/s. Dunno whats going on.

[Doff]

I get the same error as Ebereon I have 62-0013. The xc3sprog –c cm1 –p 0 twin_test.bit works, but loading to SPI Flash with xc3sprog –c cm1 –p 0 –I xc6lx150.bit twin_test.bit gives me the error below. 

JEDEC: ff ff 0xff 0xff
unknown JEDEC manufacturer: ff
ISF Bitfile probably not loaded

Also looking forward to programming these in Linux.

Thanks!

[ebereon]

At the moment FPGA 0 and 3 in the "Temporary Programming" mode have the orange led's on and if they got work it turn the orange led off and a second later it turns again on. the hashrate is about 40Mh/s.    Yesterday i got 380Mh/s in 1 hour average and 10 hours later they had only 40Mh/s. Dunno whats going on.

After uninstall the drivers and reinstall them, testing all usb ports etc., it's working now (temporary mode) and hashing @ ~370Mh/s (1 hour average checked with p2pool stats page). Phew!  

[spiccioli]

Hi,

I'm moving to my linux setup, ubuntu server

Code:

$ uname -a
Linux t5570 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

and I've found I have to issue a

Code:

sudo /sbin/modprobe ftdi-sio product=0x8350 vendor=0x0403

every time I restart my PC even if I have the udev rule in /lib/udev/rules.d/99-cairnsmore.rules

Anyway, after this the board is found and four ports become available

Code:

[ 1052.472642] usbcore: registered new interface driver usbserial
[ 1052.472703] USB Serial support registered for generic
[ 1052.475082] usbcore: registered new interface driver usbserial_generic
[ 1052.475093] usbserial: USB Serial Driver core
[ 1052.484292] USB Serial support registered for FTDI USB Serial Device
[ 1052.486249] ftdi_sio 1-6:1.0: FTDI USB Serial Device converter detected
[ 1052.487938] usb 1-6: Detected FT4232H
[ 1052.487952] usb 1-6: Number of endpoints 2
[ 1052.487964] usb 1-6: Endpoint 1 MaxPacketSize 512
[ 1052.487976] usb 1-6: Endpoint 2 MaxPacketSize 512
[ 1052.487987] usb 1-6: Setting MaxPacketSize 512
[ 1052.492091] usb 1-6: FTDI USB Serial Device converter now attached to ttyUSB0
[ 1052.492418] ftdi_sio 1-6:1.1: FTDI USB Serial Device converter detected
[ 1052.492554] usb 1-6: Detected FT4232H
[ 1052.492565] usb 1-6: Number of endpoints 2
[ 1052.492577] usb 1-6: Endpoint 1 MaxPacketSize 512
[ 1052.492588] usb 1-6: Endpoint 2 MaxPacketSize 512
[ 1052.492599] usb 1-6: Setting MaxPacketSize 512
[ 1052.493568] usb 1-6: FTDI USB Serial Device converter now attached to ttyUSB1
[ 1052.493887] ftdi_sio 1-6:1.2: FTDI USB Serial Device converter detected
[ 1052.493988] usb 1-6: Detected FT4232H
[ 1052.493999] usb 1-6: Number of endpoints 2
[ 1052.494010] usb 1-6: Endpoint 1 MaxPacketSize 512
[ 1052.494022] usb 1-6: Endpoint 2 MaxPacketSize 512
[ 1052.494033] usb 1-6: Setting MaxPacketSize 512
[ 1052.495873] usb 1-6: FTDI USB Serial Device converter now attached to ttyUSB2
[ 1052.497132] ftdi_sio 1-6:1.3: FTDI USB Serial Device converter detected
[ 1052.497249] usb 1-6: Detected FT4232H
[ 1052.497260] usb 1-6: Number of endpoints 2
[ 1052.497272] usb 1-6: Endpoint 1 MaxPacketSize 512
[ 1052.497284] usb 1-6: Endpoint 2 MaxPacketSize 512
[ 1052.497295] usb 1-6: Setting MaxPacketSize 512
[ 1052.500148] usb 1-6: FTDI USB Serial Device converter now attached to ttyUSB3
[ 1052.500217] usbcore: registered new interface driver ftdi_sio
[ 1052.500227] ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver

ttyUSB2 and ttyUSB3 are FPGA0/3 and I can mine on them with Mpbm

Now, I'll move bitstreams and xc3sprog from VirtualBox image and see what happens

spiccioli.

[spiccioli]

Now, I'll move bitstreams and xc3sprog from VirtualBox image and see what happens

spiccioli.

It happens that xc3sprog does not work, it is a 32 bit prog, I'm on a 64 bit one and without 32 bit libs.

:/

spiccioli

[yohan]

Shipping Update

Ok if you are on a June delivery indication you should either have received a request for payment or you will do so in the next 3 days. Please look out for the payment requests including the good old spam box.

We are now nearly back on our original schedule and the catch up is happening very quickly. For July it looks like we will be on schedule if not running ahead. We may have a few droops in production through July as well may have a couple of small periods of waiting for components but these won't cause anything other than a small variation in deliveries.

For the moment we are still running August as a non-production month but it is likely we will have some pulling in some September deliveries. September delivery promise is about to close and October will become the promise probably tomorrow.

Yohan

[rjk]

It's a good thing I don't have any more hair left or it would all be on the floor by now...

http://img842.imageshack.us/img842/1303/spifail.jpg

lol, you forgot to add ".bit" to the end of the filename.

> SPIProg.exe XC3S50AN_LOADER_V1.1.bit

[rjk]

Still the same result...

http://img684.imageshack.us/img684/5450/spifail02l.jpg

Huh, well that's weird.... I have no idea why it would do that. To prevent spelling mistakes, use tab-autocompletion.

[sadpandatech]

Still the same result...

http://img684.imageshack.us/img684/5450/spifail02l.jpg

Huh, well that's weird.... I have no idea why it would do that. To prevent spelling mistakes, use tab-autocompletion.

I did.  Even renamed the longfilename.bit to spi.bit with the same result.

Welcome to my bizarro world. 

This is likely not to work and may sound silly. But try typing in the complete path and filename for the .bit file.  i.e.,  SPIProg c:\windows\system32\spiprog\spi.bit

I have not started messing with this yet. Are you running it in the virtual box environment or just from windows?

[rjk]

Still the same result...

http://img684.imageshack.us/img684/5450/spifail02l.jpg

Huh, well that's weird.... I have no idea why it would do that. To prevent spelling mistakes, use tab-autocompletion.

I did.  Even renamed the longfilename.bit to spi.bit with the same result.

Welcome to my bizarro world. 

The only other thing I can think of is that it is a 32-bit app in a 64-bit environment. Normally, that isn't a problem, but certain folders are treated differently - specifically System32 and Program Files. Both of those are for 64-bit apps only, and SysWOW64 and Program Files (x86) exist for 32-bit apps.

In other words, try moving both files to either the Desktop or the C:\ root and try again.

[sadpandatech]

In other words, try moving both files to either the Desktop or the C:\ root and try again.

aye, my other thought.

[ebereon]

After the controller update, that what the pdf say's.

But the whole unit is buggy...

Sometimes it's working only with 100Mh and lower, sometimes ~280Mh/s. The orange led's show much often when the unit is working longer then 2 hours.

[Doff]

I am only able to get about 50mh with the twintest.bit file in normal cgminer. Mine seems to program without a hitch at least so thats good, but im not at the 380 yet.

Having fun playing with all this stuff though.

[Doff]

Yes, thats the only one I can seem to get to work. Any other configuration gets me a cannot mine all devices disabled in cgminer.

[rampone]

Okay. XC3 update went well, I think the red led flashes faster now.

Again I tried to temporarily load the faster test bitstream, it seems to load right (0 and 3 are yellow, 1 and 2 are yellow and red).

And still the problem that it wont hash. Reinstalled drivers and hooke up to a second computer. Same Same. It seems to get the work as the #0 and #3 flash red, also yellow switches off for a 100th second. and then it does nothing...
dip switches ae right and also tested different options.

Am I the only one left behind right now, with loaded faster bitstream and no work/hashing done? Or does my board have a defect/HFrequency/Voltage Problem, as the slower bitstream works and the faster does not? Is it the condensators beeing on the side of the fpga and not on the bottom, so flipflopping the gates hard inside the fpga ripples the voltage? Cant be that problematic if they are on the side? Is it the hair under the solder resist on my board? It crosses the connection from xc3 to sp6#2... that would be really strange if it the hair messes it up.

I dunno, and my testing knowledge is over. anyone further ideas?


I guess I will contact enterpoint directly tomorrow and ask them. I know its still early stage, but strange that it seems to run on mostly other boards. (someone had only 1 fpga hashing faster on one board (the 3 out of 8 guy).

Oh well again back to 100Mh/s (I did not load the bitstream in to flash permanently yet, want to easily fallback to "minhash")

[rampone]

kay, at least I do not feel that alone  

[yohan]

I am only able to get about 50mh with the twintest.bit file in normal cgminer. Mine seems to program without a hitch at least so thats good, but im not at the 380 yet.

Having fun playing with all this stuff though.

Hopefully it will get better as we get more time on the tools and documentation. I'm hoping to have the Linux version for the controller updater tomorrow but can't promise that given the way development sometimes goes.

After we get this sorted we would like to an idea of who isn't on the latest firmware. Whilst I anticipate this being updated again once or maybe more it's going to be our standard working level for 1or 2 weeks whilst we will then be concentrating more on improving the bitstream side. The twin build is an Icarus derivative so does have the twin clock weakness so it is possible that is causing the dropouts one or two of you are seeing. I would like to get a more formal feedback from you once we have a bitstream build that we are much happier about in terms of stability. The current "twin FPGA" running is very much a temporary bitstream as far as we are concerned.

Once we have a better bitstream (almost certainly not the final one but reasonable) we will look to bring in the up/down functionality and that will definately be a controller update again.

Yohan

[Doff]

Ramp did your try this from daemonic a few posts back? Although with that programmed im still getting crap all for hash rate, im just happy it does something at all haha

To program, I had;

SW1 all on
SW6 all on
SW2 (PGA 0) all on
SW3 (PGA 1) 12 off, 34 on
SW4 (PGA 2) 12 off, 34 on
SW5 (PGA 3) all on
(as per progamming operation from virtual box, but ignoring the SW6 3 off)

then to use standard cgminer, i switched SW1 1 off;

SW1 1 off, 234 on
SW6 all on
SW2 (PGA 0) all on
SW3 (PGA 1) 12 off, 34 on
SW4 (PGA 2) 12 off, 34 on
SW5 (PGA 3) all on
(as per normal operation)

(this is for twin_test.bit)

Ok I actually got it to program as per the instructions this time, and noticed you have to flip the switches and wait for the lights to go amber in normal operation. Still hashing at like 25-50mh though with the twin.bit.

[rampone]

doff: did everything, that was posted here in the thread, and tried other settings myself, only loading the bitstream permanently i did not do, but that should not change anything, as others worked in "temporary mode".

I am already in waiting mode again

[rjk]

Isn't the Icarus bitstream based on Ztex source? Is there any reason to use Icarus-specific stuff?