Topic: Raspberry Pi / cgminer for your BFL BitForce (Read 20694 times)

After a recent firmware update and cgminer 3.1.1 my pi has been rock solid! Lovin it.

I'd like to get an rpi
https://bitcointalksearch.org/topic/rpi-b-for-cgminer-138921

Ahhh, it seems they did not update the site.....

http://www.aliexpress.com/store/product/cubieboard-1GB-2012-9-9-revision/511685_721644583.html

But then I took a look at the schematics......

They are using a shitty little realtek chip RTL8201(I really hate Realtek shit... just F*** off)
1. NO hardware offload
2. NO internal ram.. the CPU has to deal with each & every byte from the network
3. ONLY ONE ethernet connection port allowed!!! (stratum only & NO external SSL whilst mining!!)

The only way I would guess it to disable the ethernet then use an Arduino  W5100 network board, at least it has upto 4 connections at a time.
The only other option is to go back to the korean PCB
http://www.hardkernel.com/renewal_2011/products/prdt_info.php?g_code=G135341359084

Because at least it is using an SMC chip with 13kb ram & 64 ethernet ports, but the shipping is like $30usd!! Almost 50% of the board cost.

Hmm, well, I'm running the same firmware version as you now (latest as of today) and I still get the comm errors. So now I think the next item down the troubleshooting list is to try a new USB hub. I'll drop by my local BestBuy and see if I can get one of those Belkin hubs from the Raspberry Pi official hardware supported list.

Thanks for the info Scott!

Linux RPiCoin 3.6.11+ #348 PREEMPT Tue Jan 1 16:33:22 GMT 2013 armv6l GNU/Linux

Jan  2 2013 23:40:34
Copyright (c) 2012 Broadcom
version 360331 (release)


Currently running RPiCoin which I have renamed this software in my mind, with 4x BFL singles. I built BFGMiner to only be able to run Bitforce and disabled everything else. I do almost daily sudo apt-get update / upgrade / dist-upgrade and clean. Was able to fix rpi-update after deleting the config file mentioned. I am using a good quality power supply being an official iphone white charger. My main difference may be I did alot of research and bought a good / expensive powered usb hub, the 12 port satechi which is $30ish on amazon, which is know not to have any power feed back problems. My plan is to upgrade to 6x Single SC on 1 RPi with the same hub. Also, how many singles are people trying to run off a RPi? I never had problems with 1-2 singles, when I got my 3rd and 4th units in the mail was when I started to see Comm errors for the first time. I would say rpi-update is the best way to solve comm errors. Hope this helps.

Can you post what firmware version you're running.

I managed to find out what USB Hub I'm using (it's not branded with anything so it's one of those generic types).

lsusb shows the following:

Bus 001 Device 004: ID 1a40:0201 Terminus Technology Inc. FE 2.1 7-port Hub
Bus 001 Device 005: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB

Has anyone else had success using the Pi reliably with this usb hub?

The reason I'm asking is that perhaps this usb hub is problematic or backfeeding power to the Pi therefore causing instability and possible long term damage to the Pi.

I checked out the Raspberry Pi Verified Peripherals page but the hub is not mentioned there.

http://elinux.org/RPi_VerifiedPeripherals#Working_USB_Hubs

Well, after about an hour or so I started getting "comms error" from one of my BFL Singles. So fail once again.
I ran rpi-update once again (after removing the .rpi-firmware folder). Let's see if that helps.

I should mention that rpi-update DID work and that I noticed a newer firmware revision # and uname -a shows a newer date  (Tue Jan 1). Cross my fingers and hope it will help in some way.

Ok, so I've made both of those changes 2 min ago and rebooted. Let's see how long it will remain stable for. I will report my results here.

Edit: I should also mention that I now have the Pi sitting in front of a fan that blows across my fpga miners as well. I don't know if this will help in any way but I hear that the Pi can run pretty hot (50 C and up?) so keeping it cooler should be at least good for it. Hell who knows it might even make it more stable. If that is the case I think getting one of those heatsink kits for it would be a good idea.

Hmm, yeah quite disappointing .

I think in the end the best solution would be a mini-ITX case with an Intel ATOM CPU and some el'cheapo case. Time to hunt my local classifieds for one. Oh, btw if any of you have this for sale and are willing to ship it to me (Ontario Canada) please let me know.

Well, I got it run once and it now using the latest firmware, but that did not help at all with the stability issues. So maybe this weekend I will play around with it and try your suggestion.

1. It is not available.....
2. It is not tested.......
3. There is no software or kernel available for it yet....
4. Its been on going for over 6 months they have had $96k in funding.... and still no product?
Seriously I Know Chinese companies that could bring such a product to market in under 2 months.

I have no idea if it will help, I have nothing to test it with as of yet, I have a couple of basics ordered but until they get here I'm just toying around with it.



I found this on their forums


then running rpi-update should get the latest without the hang

I wanted to chime in on this as I appreciate the project. I am running a modified version of the 12/8 distro, having switched everything from cgminer to bfgminer 2.10.2. I had a 256mb pi that I switched to a 512mb thinking all usb problems would be fixed. On both versions same day comm error problems solved with doing a rpi-update. I am stock on the november firmware is I also have the bug that rpi-update will not upgrade more then once. Been running 2 days without a reboot, but I except a reboot once every 3-4 days is going to have the be the accepted norm on a RPi. I have not had watchdog reboot the system yet automatically, but will watch for it.

I'm going to give that a try. Have you had to do this too? (ie are you having stability issues?)

The main question here is can I get the Pi to mine reliably without ANY reboots or hangs?

Neat! If it is more stable than the Pi then I'm all for it.

Thanks for letting me know about it.

I guess it's not available for purchase yet, but at $46 it could be worth the wait.

I was poking around today and found this on http://elinux.org/R-Pi_Troubleshooting maybe this could help?

Crashes occur with high network load

The USB driver allocates memory from the kernel, and when traffic is very high (e.g. when using torrents/newsgroup downloads) this memory can be exhausted causing crashes/hangs. You should have a line like:

in /etc/sysctl.conf. Try increasing that number to 16384 (or higher). If that doesn't work, try adding to /boot/cmdline.txt


which will reduce network throughput, but has improved stability issues for some.

That thing is interesting, i think more interesting than rpi!

The problem of the rasberry Pi restarting randomly on its own is well known.
I experience it myself from time to time

This little board will provide some alternative to the rasberry
http://cubieboard.org/
Might be worth to have a look for you too.

Well time to stop using it at least temporarily until I figure out the cause. It could be the power adapter or the usb hub. Never had any problems with the usb hub though. I still suspect the actual Pi itself. I'm going to see if I can RMA it.

My system is very stable and never reboots by itself.
I'm using those power adapters: http://www.amazon.fr/gp/product/B002SQE2FS/ref=oh_details_o05_s00_i00
On the 2 USB ports, I've:
- USB Wifi http://www.amazon.fr/gp/product/B003MTTJOY/ref=oh_details_o00_s01_i00
- USB Hub http://www.amazon.fr/gp/product/B004SOTVB8/ref=oh_details_o00_s02_i00 where my 2 BFL singles are plugged

However I do have the comm problems from time to time (yesterday > 10 hours without any, don't had any for the moment). I've added a cronjob to reboot the system every 12 hours (might decrease the interval in the future), so even if it crashes it's not that bad.

I noticed that rpi-update can only be run once, which is very strange (when I try to run it now it never finishes, hanging on "Updating firmware (this will take a few minutes)").

Is it possible your Pi isn't getting enough power itself? An ordinary USB charger won't have enough, it has to be able to provide 1A (on the one port, not across all N ports).

Well, bummer, system rebooted even with bfgminer 2.10.2 after 9 hours of uptime

My own experience with USB hubs has been that 99% of them are crap, and the remaining 1% cannot be uniquely identified before plugging them in.

If you build bfgminer with libudev support (install libudev-dev and re-run configure), you can drop all the -S options and let it autodetect.

If 2.10.2 proves stable (give it a few days, just to be sure?), you could easily debug the problem further using git bisect in reverse: you tell it the known-working version is "bad", the known-problematic version is "good", and it will give you a series of commits between the bad and good ones (it's smart about minimizing how many of these) to test and report back on (remember to invert the bad/good, since bisect was designed for looking for regressions, not fixes); you'd also need to be careful to run autogen for each commit and note whether it builds bfgminer or cgminer. Eventually, bisect will tell you which commit fixed your problem.

Numerous fixes have been added to 2.9.x between 2.9.4 and 2.9.7, so I would focus on the latter (if not 2.10.x). In my experience, usually watchdog resets triggered by software are caused by excessive swapping - which would suggest a memory leak. I do test for memory leaks most releases, but it's possible 2.9.4 was one of the times I forgot to check before releasing.

lol

https://bitcointalk.org/index.php?topic=123146.new;boardseen#new

*facepalm* should've waited/did some more research before buying one of these things expressly for miner management purposes.

4 Icarus boards and 3 BFL singles. All connected to a 10 port USB (powered) hub. USB Hub is one of those generic ones you find everywhere - got it off of ebay:
Raspberry Pi is not doing anything else other than managing the fpga miners. No keyboard or mouse is attached to the Pi. USB hub is connected to the lower usb port (bottom one).

I'm running bfgminer with the following argument (all pretty standard from what I'm aware):

bfgminer -c /home/btc/cgminer.conf -S /dev/ttyUSB0 -S /dev/ttyUSB1 -S /dev/ttyUSB2 -S /dev/ttyUSB3 -S /dev/ttyUSB4 -S /dev/ttyUSB5 -S /dev/ttyUSB6



cgminer's Bitforce driver is based on bfgminer's, except they've added a bunch of bugs. I could try it next, but as long as bfgminer works, I don't see a point...
[/quote]

Surprisingly bfgminer 2.10.2 has been running for 8 hours now without any issues. Lol maybe I should just leave it alone. Still I'm really curious to at least know with a reasonable amount of certainty what was causing these instability issues for me.

Hmm, if you say there are bugs in cgminer's bitforce driver that could explain the comm errors me and the OP have been getting. However 2.9.4 causing a system reboot (or causing a system even like large cpu load or something that is causing this mining distro's watchdog daemon to reboot the system) is bizzare. I would be nice if someone else can verify my experience. Perhaps the OP will give 2.9.4 a try and see if the same thing happens for him.

It shouldn't be, but I can try it I guess... Only have 1 Icarus though - what's your environment like?

cgminer's Bitforce driver is based on bfgminer's, except they've added a bunch of bugs. I could try it next, but as long as bfgminer works, I don't see a point...

Hmm, odd. I wonder why this happens only for me (as far as I know). 5 hours with 2.10.2 running without any problems...I will monitor this further.

Luke do you think that the fact that I have both Icarus and Bitforce miners is somehow relevant?

Could you also try cgminer 2.10.4 to see if you get any Comm errors from one of your Bitforce singles? That definitely happens for me with the latest cgminer build - the whole reason that caused me to look for an alternative to see if the same thing happens (ie to bfgminer).

Hmm, well it's been 5 hours on 2.9.7 and no problems of any sort... trying BFG 2.10.2 now.

I suppose I could. I'd have to take it out of its case and stop using it for mining for a bit, so it's a tiny bit of an inconvenience, but do you suppose you could learn something from that? Do you need _my_ pi pic or what exactly do you think you'll ascertain from a closeup pic? Damage to components?

2.9.7 takes about 2 hours to cause a system reboot. Digging though /var/log/messages shows this:

Dec 30 06:46:22 raspberrypi kernel: [18946.081057] smsc95xx 1-1.1:1.0: eth0: Error reading MII_DATA
Dec 30 06:46:22 raspberrypi kernel: [20868.008194] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000$
Dec 30 07:36:23 raspberrypi kernel: [20868.008221] smsc95xx 1-1.1:1.0: eth0: Error reading MII_DATA
Dec 30 07:36:23 raspberrypi kernel: [23869.190094] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000$
Dec 30 07:36:23 raspberrypi kernel: [23869.190144] smsc95xx 1-1.1:1.0: eth0: Error reading MII_ACCESS
Dec 30 09:53:58 raspberrypi kernel: [23869.190163] smsc95xx 1-1.1:1.0: eth0: Timed out reading MII reg 01
Dec 30 09:53:58 raspberrypi kernel: [32124.183193] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000$
Dec 30 11:30:46 raspberrypi kernel: [32124.183223] smsc95xx 1-1.1:1.0: eth0: Error reading MII_DATA
Dec 30 11:30:46 raspberrypi kernel: [37932.079567] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000$
Dec 30 12:21:33 raspberrypi kernel: [37932.079597] smsc95xx 1-1.1:1.0: eth0: Error reading MII_DATA
Dec 30 12:21:33 raspberrypi kernel: [40979.609688] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x0000$
Dec 30 14:23:10 raspberrypi shutdown[10330]: shutting down for system reboot
Dec 30 14:23:20 raspberrypi kernel: [40979.609716] smsc95xx 1-1.1:1.0: eth0: Error writing MII_ADDR

2.10.2 is now what I'm running (I kept on switching between the two to see which one would result in the most stable results...so far cgminer bfgminer (both version) has caused issues.

The thread starter also reported having COM errors with his BFL units with cgminer (latest build).

Linux raspberrypi 3.6.11+ #346 PREEMPT Fri Dec 28 00:50:33 GMT 2012 armv6l GNU/Linux

this is what I have...exactly like yours...

root@raspberrypi:/opt/vc/bin# ./vcgencmd version
Dec 28 2012 11:22:54
Copyright (c) 2012 Broadcom
version 359904 (release)

So I guess we are both running the latest everything (firmware and OS)

There was some mention somewhere on the net of putting "dwc_otg.fiq_fix_enable=1" in /boot/cmdline.txt

I did not try this yet as supposedly now this is turned on by default? As to if this is only in certain kernel version or whatnot I'm not sure.

My cmdline.txt file has this though "dwc_otg.lpm_enable=0" which was there by default...but no mention of dwc_otg.fiq_fix"

reference for this: http://raspberrypi.stackexchange.com/questions/1886/what-kernel-parameters-are-available-for-fixing-usb-problems

I've been running 2.10.0 on my pi since it was released (with MMQ), and it seems to work fine with BFL (though I only just now moved it from my development system to the pi).
I built 2.9.7, and will let that run for a bit to test. How long does it usually take to reboot your pi?
After that, I can test the latest 2.10.x, but I don't expect any change from 2.10.0...

luke-jr@raspberrypi /opt/vc/bin $ ./vcgencmd version
Nov 22 2012 18:09:58
Copyright (c) 2012 Broadcom
version 352766 (release)
luke-jr@raspberrypi /opt/vc/bin $ uname -a
Linux raspberrypi 3.2.27+ #285 PREEMPT Tue Nov 20 17:49:40 GMT 2012 armv6l GNU/Linux

This is what I get



what does
>uname -a
put out?
I tried the latest download and the kernel would not update (just waits forever) still the old version I think
I started from scratch with the script and updated the firmware first and it seemed to work

Should be like
pi@raspberrypi:~$ Linux raspberrypi 3.6.11+ #346 PREEMPT Fri Dec 28 00:50:33 GMT 2012 armv6l GNU/Linux

Can you post a closeup picture of your PI, so I can see the components...

Here is what I found. With cgminer 2.10.4 the comm error shows up. With bfgminer 2.9.4 it works but I believe the system is restarting so it's causing a system crash. bfgminer 2.10.1 is misreporting the hash rate for the bfl singles (at random)

It might be time to give up and go back to windows with cgminer + mpbm (modular python bitcoin miner). Quite disappointing really
Or maybe find a low power x86 solution (atom board or something similar)

Ok, so on to try bfgminer I go. If this fails too then it's "screw you raspberry pi" for me. I have a feeling that bfgminer won't help either as this seems like a raspberry pi issue (yes I did update the firmware).

Shit it's still doing it..

This sucks..

root@raspberrypi:/opt/vc/bin# ./vcgencmd version
Dec 28 2012 11:22:54
Copyright (c) 2012 Broadcom
version 359904 (release)

latest firmware running..let's hope this fixes it..

Some tips for you folks that are thinking of doing the same thing. First the rpi-update script passes a bunch of command argument (git, etc) with the --quiet flag. If you want to know what it's doing edit the script (rpi-update is a bash script) and remove the "--quiet" flags.

sudo apt-get update
sudo apt-get upgrade -y
sudo sync && sudo shutdown -r now
sudo wget http://goo.gl/1BOfJ -O /usr/bin/rpi-update && sudo chmod +x /usr/bin/rpi-update

If you get an error message regarding certificates

sudo apt-get install ca-certificates

and then rerun rpi-update

root@raspberrypi:/opt/vc/bin# ./vcgencmd version
Nov 22 2012 18:12:01
Copyright (c) 2012 Broadcom
version 352766 (release)

I'm not sure if this is relevant but could someone else run that command and tell me what firmware version you've got?

I'm running rpi-update right now..taking a long ass time..read somewhere that it could take up to 20 min..

Maybe that will fix this issue..

Hmm check this out:

https://github.com/luke-jr/bfgminer/issues/105

This bug was reported with bfgminer a while back....I think this may be an issue with the raspberry pi itself and not the mining software or the OS.

[2012-12-30 02:18:05] BFL2: Comms error
 [2012-12-30 02:18:06] Accepted 5a03aed4 Diff 2/2 ICA 0
 [2012-12-30 02:18:10] BFL2: Comms error
 [2012-12-30 02:18:12] Accepted 74c98fce Diff 2/2 ICA 0
 [2012-12-30 02:18:15] BFL2: Comms error
 [2012-12-30 02:18:20] BFL2: Comms error
 [2012-12-30 02:18:25] Accepted 6222264c Diff 2/2 ICA 2
 [2012-12-30 02:18:26] BFL2: Comms error
 [2012-12-30 02:18:27] Accepted 61a22b72 Diff 2/2 ICA 2
 [2012-12-30 02:18:27] Accepted 6d4d902e Diff 2/2 BFL 0
 [2012-12-30 02:18:31] BFL2: Comms error
 [2012-12-30 02:18:36] BFL2: Comms error
 [2012-12-30 02:18:38] Accepted 58f98beb Diff 2/2 ICA 1
 [2012-12-30 02:18:41] BFL2: Comms error
 [2012-12-30 02:18:43] Accepted 6a42c394 Diff 2/2 BFL 0

problem still persists

This time it occurred with a different single..

Ok, well, operation was successful and I'm now running cgminer 2.10.4 (previous 2.10.3). Time to detach the screen and see if the problem manifests itself again. Hopefully not

Hmmm, ok I'll give it a try but I thought the current image is running the latest build.

Also I don't think this issue manifests itself right away or with regularity. I've been running it for 4+ hours and no comm errors and I did not update cgminer yet.

Either way I'm running the update script. Let's see how it goes..

I updated cgminer (simply run Update.sh script) and it seems I doesn't have this issue anymore (no comm error so far, running for more that 3 hours).
Give it a try and share.

I think this is happening only when you log into the btc account and then detach from the screen session. I was logged into the session (ie I saw the cgminer terminal output) and it did not happen the whole time. I just screen'ed out of the session and I will wait and see if one of the fpga miners craps out again. I have a very strong feeling it will as this seems to me the only common pattern.

I'm getting this too, very strange...
I'll try to investigate on this.

Well this sucks. The comm error from one of the singles happened again. I guess it takes a hour or two before this manifests itself.

[2012-12-29 12:54:58] Accepted 12a670c7 Diff 13/2 BFL 2
 [2012-12-29 12:55:00] BFL0: Comms error
 [2012-12-29 12:55:05] BFL0: Comms error

Anyone else have any clue as to what is going on?

The fpgas are connected to a powered USB hub.

Well I got it going just today. The only issue is that it seems to me that something is flaky. I'm getting communications errors from one of the BFL singles. Closing cgminer forcibly and waiting for the watchdog script to restart it seems to work...as to how long it will work until it poops out again I'm not sure - I guess I'll have to keep an eye on it and see. I don't think it's caused by the Single throttling as normally if that was the case eventually the single would come back online once it's done rebooting - that and the temp is not even high at all (44 C)

Just added an alternate link: http://dl.free.fr/hmpSyVjcg

Download ist not working ->File owner's public traffic exhausted.

See first post, I posted a detail of everything I did.

allinvain > thanks, link updated in first post, sorry about that

Just thought I'd mention that the link on the first post still points to the old image. Use this link until the author updates it or you can just copy the URL and copy and paste it in a new broker window/tab (ie don't just click on it)

http://rapidshare.com/files/3214579155/2012.12.22%20-%20debian%20wheezy%20configured%20-%20public.zip

If someone wanted to make an image like this for another piece of hardware that wasn't the rPi, say an MK802 II, would you mind posting a few more details about what you did, specifically the watchdogs and such? Thanks!

Image updated (see first post)

Awesome. Thanks crazydownloaded! My Pi just shipped today. I can't wait to put that little thing to work.

I think I will go with a 8 gb or 16 gb sd card too. 16 GB ones are like $15 CDN here.

fpf > I just integrated rpi-update, I'll post a new image soon

allinvain > I just added icarus+modminer+ztex support to cgminer (compilation options), will be in the new image. However, I can't guarantee every other things will work (I don't have those and don't really know what they need), however I think everything should be OK.

moreporknz > I'm using Transcend class 10 SD cards (8GB) and never had a crash so far

heavyb, allinvain > Correct, there is no wallet embedded. If you wan't a wallet, go to https://blockchain.info/ and sign up. You'll also need some mining pools (In case some fails), I personally use http://ozco.in (which is great but fails a lot), https://mining.bitcoin.cz, https://www.btcguild.com and https://deepbit.net

heavyb, allinvain > I've no idea how to shrink the image too. The problem comes from the fact I used a 8GB SD Card (best value at the moment, 4GB are 6.50 € and 8 GB only 8 €, taxes included) and the way the disk imager is working (doesn't care about size used on the card neither the size of the partitions, it simply copies everything as on the card).
I released a full step by step on how to get the same result I did (http://pastebin.com/2J8BDHRB) if you wan't to do it all by yourself.
I unsuccessfully tried to find a 2GB SDCARD at a normal price (those I found were more expensive than 16GB class 10 cards!). However I've a 4GB card, I will do the image again on it and post it here.

Stay tuned!

That's easy enough to do Any chance you can upload the core image files (meaning the 650 mb modified debian iso) so we can make our own smaller IMG file? Or perhaps release a smaller img file for 8 gb or 4 gb SD cards? (or smaller).

Default it's DHCP

CGminer is only enabled for bitforce in the image (at least in the old one, not sure about the new one, but I guess it's the same)
If you want to enable other devices you need to modify the compilation option in the /root/Update.sh script and run it

fpf

Ok, nevermind my idea with using a windows ISo reader program. Apparently I was seeing just the boot partition. Now that I think about it makes sense. Should've realized that sooner. As someone said:
"The boot partition IS readable by Windows, the others are not"

So the only way to resize it would be to mount the image and then copy all the stuff of it and into a new image.

I'll see what I can do in that regard, but I may take the lazy way out and just get a 16 gb SD card. They're not that expensive anyways.

Jeez, I dunno why I kept on saying CF. I meant SD card. Here is a list of SD cards known to work with the pi:

http://elinux.org/RPi_VerifiedPeripherals#SD_cards

Ok, so I think I have found a way to resize this using UltraISO. I went to "Actions" and chose Change image format (or F9). Sized it up as 2GB. Now as to whether it will work or not I'll have to see once I get the board and a CF card.

Perhaps you can try it out and let me know if it works?

Thank you, this is what I figured the problem was, but I had read people had been sucessful putting them on 8 gig cards. I acctually found a 1gb card in my storage closet at working hunting for cards haha.

Does anyone have the skills the resize this?

Hmm, I downloaded the image and it's slightly bigger than 8 GB. This will definitely need to be resized.

Hmm this may help:


But having said that I have a feeling we're going to need to use a bigger CF card than 8 gb unless the author releases a smaller image or we resize the image. I am most likely going to look into resizing the image as I don't see the point of buying a 8 GB CF card or bigger for a 622 mb image. A el cheapo 2 GB card should do once the image is resized (I can't for the life of me find 1 GB cards these days)

I have a 8 gb SD card and I am getting a write error that there is not enough space on the card. It comes up as 7.45 in windows explorer. Any suggestions?

Alright cool, I will be loading this today and post how it goes.

That would be really neat. However, if I understand things correctly you don't have to modify anything relating to wallet info in this mining distro. You just have to change the cgminer.conf to reflect your chosen mining pool info (or solo if that's your thing).

If nobody else beats me to it I think what I shall do is when I get my raspberry pi (shipped today) I will write a guide on how to get this distro working and post it here or on pastebin.

Would anyone be willing to create a youtube video on how to install the OS, modify it to your wallet info for us to watch? I have never done anything like this before but would really like to learn.  Thanks.

Very neat project.I just bought a raspberry pi a few minutes ago for this very purpose. My scenario is a bit different though. I have a few Icarus boards as well so I'm wondering if you've compiled cgminer with support for all FPGA mining boards not just specifically BFL Singles.

Also what is the default LAN IP address you've built into the image? 192.168.1.x or ?

What brand sd are you using? I also had this issue, updated firmware and seemed to fix it..

I think my issues turned out to be SD Card related (picked up a cheap pos, that seems to have been bugging a bit) in addition to any firmware problems. Worked out the contact a little better, and updated firmware, and so far so good, though I'm afraid to push my pi too hard again.

For now though 24h+ uptimes with no glitches

I have a model B with 512MB...
There is no other difference to the old one except the RAM and where it's assembled - the issues I had where all software related.

FPF

I heard that the new Rpi model has the USB issue fixed. Can anyone confirm this?

Was able to fix it with some updates...

https://github.com/Hexxeh/rpi-update/
sudo wget http://goo.gl/1BOfJ -O /usr/bin/rpi-update && sudo chmod +x /usr/bin/rpi-update
sudo rpi-update

It's stable now for more than 24 hours 

FPF

Uhm... hmm... mine lately seems to be dead sadly. I can't even boot anymore (no video), so might be a different issue. I got a rainbow frozen output with the OPs image though, so maybe there is something to this link you've posted. Most disappointing though regardless.

Seems it's not completely dead - but the whole USB system will fail (including the USB based Ethernet controller..)

Same issue / topic: (there are a couple more)
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=16280

It seems that some older Raspberry Debian Wheezy images did not have such issues, however I have no older images to try.

FPF

Bcpokey,

Actually... I am having the exactly same issues, it did restart before - lately it just freezes - it's just plain dead.

FPF

@serp
I use putty sometimes for SSH access, however - I am not talking about loosing the ssh connection, I have a physical screen connected and without any SSH connection to it it just randomly reboots or hangs...

I had an issue similar to that, without running cgminer, so I'd be interested if you figured something out about it. I would come back and Pi would have rebooted for no reason that I could. Lately it has begun freezing completely. I'm hoping it is a software issue and not a hardware issue.

fpf, are you using putty and if so is it possible that putty was closed/exited through some other method than normal or that there was a temporary disconnect in your network?  Maybe on a laptop where you closed the lid or something?

The reason I ask is that I have a user having a similar issue with screen while using putty.  He gets exits/freezes when putty is not closed manually.  This seems to only happen while using putty on windows.  No other user has this problem. 

Def. no temperature issues.

Right now - I don't display the cgminer screen anymore over ssh / the main display and it has been stable for 8 hours. Will do some more tests and let you and the other guys know.

About the watchdog, cgminer does auto restart in case you quit it - so that one works.
About the other ones - I have yet to try them somehow.

In the beginning the raspberry just randomly rebooted from time to time. However yesterday I also had it freezing twice... (without the watchdog kicking in) As mentioned earlier I assume that's because I had the cgminer screen running on the host display / ssh all of the time.

fpf

I just made the changes
The image is very stable for me, do you have temperature issues?
Does the watchdogs does their jobs? (ie you don't have to do anything, it reboot by itself when blocked?)

Thanks.

Thanks fpf for your feedback, I'll try to make the changes asap.

Feedback for this image:

- The User BTC didn't/doesn't have the needed privileges required to open /dev/ttyUSBx
(had to manually add him to the dialout group)

- Something is/was wrong with the cgminer.conf file, had to create a new one.

If I log on with the User BTC (within the first 5 minutes after bootup) I will not end up at the cgminer screen.
Reason: There will be 2 active screen threads - the first start of cgminer fails but the "sleep 300" in the bash file will keep the screen another 5 minutes...

I still have some random restarts or hangs - reason unknown.

FPF

wow thank you so much. i will be referring back to this page when my pi finally comes. which better be soon or i'll be sad

I need to go out and buy another SD card before I can give this a try Thanks for sharing, saves us rpi users some time. I should have this tested by the end of the week

Did anyone had the occasion to test the image?
Is everything working fine for you?

Thanks

Thank you for this!

Thank you for this! Been meaning to set my RPi up and get everything configured before ASICs ship.

Thanks crazydownloaded.  Even though I consider myself a linux expert, I always learn new things when I look at other people's stuff.

Before I reply I want to say Thank You for writing this long guide and making an Image as well for users. I'm sure it will come in handy for many users now and in the future as they struggle to configure their low power, control devices. Good man.

The flip (complaining) side is how this always seems to happen to me. I recently picked up a Pi for fun and profits (yesterday really), and quickly realized I had forgotten everything about linux. So I set about the arduous task of re-learning linux commands, and how to update and expand the install to get all the programs and whatnot I want on it, and I started nice and early in the morning. And you go and release this in the afternoon, centralizing all the things I would have needed to pick up

End rant, thanks again

With an appropriate usb hub (or maybe a few of them), as many as you like.
I guess you think to Jalapeno which is USB powered, right? Price per GH/s is very bad for those units...

I'll prefer Singles SC (which have a standalone power unit), that have more or less the same price per GH/s as the new Mining Rig SC but is way better in case something goes wrong (it's unlikely that all the SC units goes wrong, way less likely than an entire Mining Rig fails) + price is much more reasonable and you can grow your rig as you earn the BTC...

BitForce Jalapeno   4,50 GH/s   5 W     26,02 €/GH/s
BitForce Little Single SC   30,00 GH/s   30 W    17,00 €/GH/s
BitForce Single SC   60,00 GH/s   60 W    17,01 €/GH/s
BitForce Mini Rig SC   1 500,00 GH/s   1 500 W   15,66 €/GH/s

could this be used to power asic's and if so how many max would u say?

cypherdoc > very easy, simply write the image to a sd card, plug your bfl/ethernet/power to your raspberry then ssh your device (maybe the most complicated part... download putty http://the.earth.li/~sgtatham/putty/latest/x86/putty.exe, type in the IP of the raspberry, login: root, password: berry), then type "nano cgminer.conf", change the parameters to match your mining pools (it's like a regular text editor without mouse), then ctrl+w), then type "reboot" and that's it

when you want to check how is cgminer doing, use putty, ip of the raspberry, login "btc" and password "berry" and cgminer magically appears.

the pastebin is here only for reference, if you don't trust my image or want to set up your own system, so you're not stuck with me.

If you don't have a raspberry:
http://www.farnell.com/pi/ or http://www.rs-components.com/raspberrypi
You'll also need few compatible full size SD cards (so you can test systems easily and have spare -- prefer class 10 cards, their speed is worth it!), a SD card reader, a power adapter and (optionnaly) a case.

Compatibles things can be found here: http://elinux.org/RPi_VerifiedPeripherals (scroll down to see hardware).

i would love a setup like this but my linux skills are almost non-existent.  i looked at your pastebin and almost barfed.

Nice, this would definitely save me having to use my laptop to run one of these miners, plus i've been meaning to get a raspberry pi and bfl single.

Hi Everybody,

I feature a mining rig away from home, based on BFL products. To control them, I bought some Raspberry Pi (only one is needed to control them all, but buying 2 allow me to have spare parts available).
I created an image that I'm releasing today for this purpose.
I started with the official Raspberry Debian Wheezy image that I configured to fit my mining needs.
You can also create your own, I've logged everything I did on http://pastebin.com/2J8BDHRB

You can download the image here: http://rapidshare.com/files/3214579155/2012.12.22%20-%20debian%20wheezy%20configured%20-%20public.zip or here: http://dl.free.fr/hmpSyVjcg
Just write it to a SD Card the normal way (with win32diskimager-binary or so, as described on http://www.raspberrypi.org/downloads)
New in v2012.12.08: Added btc to "dialout" group to let him access ttyUSB devices, corrected default cgminer.conf, corrected "double launch at startup" because of the software watchdog
New in v2012.12.22: rpi-update runned to update to latest firmware, added support for icarus/modminer/ztex

! Password for root, pi and btc users is "berry" (and not "raspberry" !)
! The image is for a 4 GB card (or +), even if it would fit on a 2GB card, sorry about that -- I cannot find any 2GB card and I don't know how to shrink the image back... hopefully, you can configure your own system using the pastebin steps
! I've included my mining configuration (in /home/btc/cgminer.conf) for testing purposes (plug your devices to test the system, and change things if you like it), so don't forget to replace them with your own!
! I don't have my BFL devices to test the system (!!!), so feel free to tell me any bug so I can correct the image and the pastbin
! I'm using "testing" sources (in /etc/apt/sources.list), stable is always too conservative for me on Debian
! CGminer only enabled for bitforce, if you want to enable other devices you need to modify compilation option in the /root/Update.sh script then run it to upgrade cgminer

+ cgminer launched at startup
+ Logging with "btc" user will automatically show you the cgminer screen, press CTRL+A then D to go back to shell
+ root and pi features config files in their own directory as links to btc's config files, so it's easy to change them
+ Security upgrades are automatically installed (apticron)
+ cgminer miner is started on a "screen" so you can always see what's happening on cgminer my typing "screen -r btc/cgminer"
+ if cgminer exits, the screen is kept for 5 minutes so you can see what's wrong
+ Features an "Update.sh" script (in /root) that upgrades your cgminer to the latest version, run it regularly to keep your cgminer up to date; the script also runs "aptitude update" to update your packages list, so you can run "aptitude dist-upgrade" right after if needed
+ Features 3 watchdogs :
+++ Hardware watchdog, if system is totally freezed (I'm away from my mining rig, so I'm not here to "reboot" the system if it fails!)
+++ Software watchdog, that feeds the hardware watchdog and reboot the system if cpu usage too high (max-load-15 = 18)
+++ Software watchdog, that looks if cgminer is running and restart it if not (logs restarts to /tmp/) (check is every minute)


Remember:
- Launch raspi-config to change timezone (Europe/Paris by default), locale (en_US/UTF8 by default) or expanding the filesystem to fit your card
- Change password for root, pi and btc ("passwd", "passwd pi", "passwd btc")
- Put your mining pools informations into cgminer.conf (in /home/btc/, /home/pi/ or /root/, they are all the same file)
- Regularly run "Update.sh" and "aptitude dist-upgrade"


PS: Sorry for possible english mistakes - i'm not a native