Bitfury asic, 3 processor boards, communication board and Raspberry Pi. generates around 79-83GH/s total (not overclocked)
Is anyone interested?
Let me know!

Is there anyone who can confirm/deny that C05I and C04I on the M-card are supposed to be soldered together on one side?
My M-Card apparently doesn't work (powersupply auto-shuts within less than 1 sec after powering on), although I don't see any of the "known possible defects" (http://imgur.com/a/t3AKx) on the card, except the C05I and C04I soldered together on one side.

Some pictures here:
http://www.void.be/tristan/bitfury/bitfury_m_1.jpg
http://www.void.be/tristan/bitfury/bitfury_m_2.jpg
(C05I and C04I are the 2 lower condensators in the group of 4 in the middle of the picture)

Does anyone know if I can just send my board back, or what the normal course of action is? (I used the bitfurystrikesback contactform yesterday but haven't received a reply yet)

Thanks

interested too

Some quick instructions on how to use the Raspberry Pi for mining using FPGA's.
I wrote this one since I got a few private messages asking for tips, so it might be useful for some people.
I'm mining using a single Cairnsmore-1 using cgminer, but the instructions should also work for any other FPGA miner.

First of all: make sure you have the maximum amount of memory available for the Raspberry Pi system.
By default the PI has 128MB available for itself, and 128MB for the GPU. If you're only mining with it, you don't want to waste that memory reserved for an unused GPU.
The following command will make 224MB of memory available for the Raspberry PI (execute under root or using sudo):
cp /boot/arm224_start.elf /boot/start.elf

Install some pre-req's for cgminer:
apt-get update
apt-get install autoconf
apt-get install libcurl4-openssl-dev

Download cgminer (you can also use other miner software) and install. In the cgminer directory:
autoconf
./configure --disable-opencl --disable-cpumining --enable-icarus
make
make install

Install screen so you can disconnect and reconnect to the mining session later on:
apt-get install screen

Install some USB libs (might not all be needed, but I installed them just in case):
apt-get install libftdi1
apt-get install libusb-dev

Now, putting the udev rules in the /lib/udev/rules.d/ directory won't work (well, you can put them there, but apparently they aren't used when booting), so you'll have to type the following command every time after booting the Raspberry PI (or put it in some start-up script):
modprobe ftdi_sio product=0x8350 vendor=0x0403

So after all previous actions are done, reboot your Raspberry PI and do NOT connect any miner to it yet.
You'll need to execute the following steps every time you're rebooting your PI:

- login
- su to root (or use sudo) to execute: modprobe ftdi_sio product=0x8350 vendor=0x0403
- connect your FPGA device (you should see it's connected in the dmesg output)
- start a screen session: screen
- start your miner: cgminer --quiet --disable-gpu --icarus-timing long -S /dev/ttyUSB0 -S /dev/ttyUSB1 -S /dev/ttyUSB2 -S /dev/ttyUSB3 -o http://<poolurl>:<poolport> -O <pooluser>:<poolpassword>

You should now be mining.

press CTRL-a-d to exit the screen session, and after that exit to log off from your PI.
Next time you want to check the cgminer status, just login, and type screen -r to reconnect to the screen session (and after that CTRL-a-d to disconnect again).

Hope this is useful for somebody.

I'm mining with a Raspberry Pi too, only 1 board though, but I guess it can handle a few more at least.

Just use a Raspberry Pi to control your FPGA's. Run it with the stock Raspbian, and it'll only use maybe 2,5W...

dcmwd4e_210 is running great on my #0005 board (with 1.3 controller).

Status after running for about 11 hours:

(5s):1014.5 (avg):839.2 Mh/s | Q:900  A:7256  R:36  HW:0  E:806%  U:11.6/m
ICA0                | (5s):419.3 (avg):419.5 Mh/s | A:3663 R:18 HW:0 U:5.9/m
ICA1                | (5s):419.0 (avg):419.8 Mh/s | A:3590 R:18 HW:0 U:5.8/m

I'm currently using 2 different bitstreams on my #0005 board: shortfin_eb_test_210_overclock.bit on p0 and p1, and shortfin_icarus_cm1_test_190_overclock.bit on p2 and p3. 210 Did great for a while on all 4, but after a few hours 2 FPGA's would stop performing work, so I switched those back to the 190 bitstream.

Stats with this setup:
(5s):770.2 (avg):774.7 Mh/s | Q:11545  A:26708  R:190  HW:0  E:231%  U:10.6/m
ICA0                | (5s):400.8 (avg):395.2 Mh/s | A:13732 R:102 HW:0 U:5.5/m
ICA1                | (5s):378.5 (avg):379.5 Mh/s | A:12978 R:88 HW:0 U:5.2/m

pool reports 771 Mhash/s

Are these DCM bitstreams also suitable for pre #0050 boards? (I tested the shortfin_dcmwd2_test_200_overclock.bit some days ago and it didn't seem to be hashing very stable on my #0005 board)

Currently the best bitstream for my board seems to be the shortfin_icarus_cm1_test_190_overclock.bit, closely followed by shortfin_eb_test_210_overclock.bit, but that last one isn't stable (1 Icarus device stops performing work after some time)

I have the high frequency sound also (but not always, or at least I don't always notice it)

hm, if it helps here's a rundown how I program and run mine (#0005) - I assume the controller version is already v1.3, and the drivers are already installed on your programming/mining pc:

- start the enterpoint virtualbox on my pc (I use Windows 7, 64bit)
- set the correct switches on the cairnsmore for programming (at this point the cm is completely off: not powered, and not connected through USB)
  (switches depending on your bitstream, but for the Makomk bitstreams: SW1: 3 off, others on; SW6: 1 off, others on; SW2/SW5: all on; SW3/SW4: 2 off, others on)
- login to the enterpoint virtualbox (root/password)
- power on the cm1 (power only), and wait for about 3 minutes
- connect the cm1 with usb cable to pc
- verify xc3sprog can connect to the cm: xc3sprog -c cm1 -j
- if ok, continue, otherwise start over again from beginning (better to disconnect the cm and reboot the pc at that point to be absolutly sure)
- program the bitstream:
xc3sprog -c cm1 -p0 -Ixc6lx150.bit shortfin_icarus_cm1_test_190_overclock.bit
xc3sprog -c cm1 -p1 -Ixc6lx150.bit shortfin_icarus_cm1_test_190_overclock.bit
xc3sprog -c cm1 -p2 -Ixc6lx150.bit shortfin_icarus_cm1_test_190_overclock.bit
xc3sprog -c cm1 -p3 -Ixc6lx150.bit shortfin_icarus_cm1_test_190_overclock.bit

each command will take some time, haven't checked but I guess around 10 minutes
- if all commands went ok ("Verify: Success!"), power off the cm1, and disconnect USB cable
- set the switches for mining: SW1: 3 on (others stay as they are)
- boot your mining pc/pi/whatever (if you use the programming pc also for mining, reboot it first!)
- power on the cm1 (power only), and wait for about 3 minutes (leds will be blue at the start, and will all turn to orange after some time)
- connect the cm1 with usb cable to pc
- start cgminer (any new version)
Linux: cgminer --quiet --disable-gpu -S /dev/ttyUSB0 -S /dev/ttyUSB1 -S /dev/ttyUSB2 -S /dev/ttyUSB3 -o http://<url>:<port> -O <username>:<pw>
Windows: cgminer --disable-gpu -S \\.\COM21 -S \\.\COM23 -o http://<url>:<port> -O <username>:<pw>
(Starting it like that on Linux will give a warning message that 2 of the devices couldn't be opened, but it will start on the other 2,
on Windows you can also specify \\.\COM20 and \\.\COM22 if the 21 and 23 don't work)
- cm1 should now be mining (leds shouldn't be constantly orange anymore) - let it mine for 48 hours to have stable statistics (MH and U values)

some additional info: I don't use any USB hubs, I just connect straight to my pc; except for mining on my Raspberry Pi, for which I use an unpowered USB hub. To make it work I need to boot the Pi first, enable the ftdi driver (execute with root: modprobe ftdi_sio product=0x8350 vendor=0x0403), connect the unpowered hub first, then connect the c1m to the hub, and then mine.

dunno if this helps...

I'm currently running the dcmwd2_200 bitstream on my #0005 board (controller v1.3), and it has been running smooth for a good 42 hours now.
Only thing I noticed is that it seems to be a bit slower than the previous shortfin_190 bitstream (dcmwd2_200 runs at around 722 MH/s, shortfin_190 at about 752 MH/s - as reported by a mining pool. Cgminer reports 775 MH/s for the dcmwd2_200 bitstream and 739 MH/s for the shortfin_190)

funny, I got it hashing on my Raspberry Pi by connecting it through a cheap unpowered usb-hub instead of connecting it directly to the Raspberry...

tried already since I noticed the udev rules don't seem to apply on Raspberry Pi (Raspbian)
I'll try the powered USB-hub as Doff mentions

I suppose I do, I installed libftdi1 and installed the D2XX FTDI ARM drivers (not sure if these last ones are needed, but I installed them anyway)
dmesg show "ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver"
yet, I don't get any /dev/ttyUSBx devices either (only /dev/usbdev1.1, /dev/usbdev1.2 and /dev/usbdev1.3)

I'll fiddle a little further...

I'm trying to get my Cairnsmore1 run on a Raspberry Pi (cgminer), but I'm getting these type of errors:

 [2012-08-05 09:38:57] Icarus Detect: Test failed at /dev/usbdev1.2: get 12010002, should: 000187a2

I then tried on a Linux machine, and I get the same type:

 [2012-08-05 10:17:12] Icarus Detect: Test failed at /dev/ttyUSB0: get 00000000, should: 000187a2

on Windows it mines without problems. Anyone an idea on how to fix this?

Board 0005 with controller v1.3

ran the Makomk shortfin 160 stable for 70 hours, cgminer output:

 cgminer version 2.3.4 - Started: [2012-07-30 22:37:47]
--------------------------------------------------------------------------------
 (5s):573.3 (avg):733.2 Mh/s | Q:13024  A:37148  R:184  HW:0  E:285%  U:8.96/m
 TQ: 2  ST: 3  SS: 5  DW: 952  NB: 413  LW: 83348  GF: 0  RF: 0
--------------------------------------------------------------------------------
 CM 0:                | 457.6/368.2Mh/s | A:18511 R:95 HW:0 U:4.47/m
 CM 1:                | 240.4/365.0Mh/s | A:18637 R:89 HW:0 U:4.50/m
--------------------------------------------------------------------------------

pool reported a hashrate of 640 Mhash/s

Since it ran stable, I decided yesterday to upgrade the board to the makomk shortfin 190oc version.
That one has been running stable now for the last 20 hours:
 cgminer version 2.3.4 - Started: [2012-08-02 20:52:14]
--------------------------------------------------------------------------------
 (5s):858.4 (avg):735.3 Mh/s | Q:3881  A:12827  R:77  HW:0  E:331%  U:10.53/m
 TQ: 2  ST: 3  SS: 2  DW: 325  NB: 150  LW: 25767  GF: 0  RF: 0
--------------------------------------------------------------------------------
 CM 0:                | 244.3/367.4Mh/s | A:6475 R:30 HW:0 U:5.32/m
 CM 1:                | 436.8/367.9Mh/s | A:6352 R:47 HW:0 U:5.22/m
--------------------------------------------------------------------------------

pool currently reports a hashrate of 756 Mhash/s

my experience is that after programming etc, it's best to power down the board completely (unplug power and usb), and restart the pc you want to mine on (if it's the same one you did the programming on).
Power on the board, wait about 3 minutes, plug in the USB in the pc, and start mining.

board #0005 still running stable with shortfin_icarus_cm1_test_160.bit (using controller 1.3) after running for about 19h45

 cgminer version 2.3.4 - Started: [2012-07-30 22:37:47]
--------------------------------------------------------------------------------
 (5s):598.2 (avg):733.2 Mh/s | Q:3695  A:10554  R:49  HW:0  E:286%  U:8.95/m
 TQ: 2  ST: 3  SS: 1  DW: 255  NB: 108  LW: 23701  GF: 0  RF: 0
--------------------------------------------------------------------------------
 CM 0:                | 460.7/367.6Mh/s | A:5266 R:24 HW:0 U:4.47/m
 CM 1:                | 383.8/365.5Mh/s | A:5288 R:25 HW:0 U:4.48/m
--------------------------------------------------------------------------------

pool account reports 550 Mhash/s

I flashed the shortfin_icarus_cm1_test_160 on my 0005 board, and it seems to be working without problem for at least the last 7,5 hours:

 cgminer version 2.3.4 - Started: [2012-07-30 22:37:47]
--------------------------------------------------------------------------------
 (5s):623.4 (avg):729.3 Mh/s | Q:1463  A:4132  R:27  HW:0  E:282%  U:8.91/m
 TQ: 2  ST: 3  SS: 0  DW: 113  NB: 48  LW: 9320  GF: 0  RF: 0
--------------------------------------------------------------------------------
 [P]ool management Settings [D]isplay options [Q]uit
 CM 0:                | 436.9/365.9Mh/s | A:2103 R:13 HW:0 U:4.54/m
 CM 1:                | 375.3/363.6Mh/s | A:2030 R:14 HW:0 U:4.38/m
--------------------------------------------------------------------------------

yep

I upgraded my board (0005) to the 1.3 controller and programmed the twin bitstream, and it seems to be hashing away stable for the last 11 hours (using the cgminer version found on the Cairnsmore1 support page).

One of the 2 FPGA's does seem to be slower:
CM 0: | 439.6/427.5Mh/s | A:1715 R:9 HW:0 U:2.56/m
CM 1: | 494.6/438.4Mh/s | A:1310 R:8 HW:0 U:1.96/m