rpi B for cgminer

[kano]

I don't suppose anyone knows how to get an rpi B, paid with BTC, to Aus? (and arrive here in the near future
.. and somewhere that has it in stock ready to ship.

Current price is less than 3BTC (but I can't afford to pay with anything but BTC)
I'm interested in getting one for supporting it properly in cgminer (and using it also)
No doubt having one when I do the ASIC code would help ensure it works on the rpi also - there will be noticeable differences running ASIC vs the slower FPGA on USB ...

Of course I wouldn't at all be against anyone offering to send me one/pay for it

But if I buy it, I have to pay BTC and neither of the sites listed here support BTC.
https://bitcointalk.org/index.php?topic=128789.msg1373669#msg1373669
... and I've no idea how long they would take to send it here anyway.

Anyone want to do a deal to get me one?

Well I'll pay the full ~3BTC (which should cover shipping also at the current BTC price) if no one is interested in supporting paying for it ...

[1715181558]

1715181558

[1715181558]

1715181558

[1715181558]

1715181558

[MineForeman.com]

I have a spare, PM me your details and I will ship it to you (Your only just across the ditch from me (NZ)).

Don't worry about the payment, with what I am working on it would be good to have one of the miner developers knowing that I exist  .  If anything donate it to my project working with Raspberry Pi's ( http://mineforeman.com/minepeon/ ).

[kano]

PM sent

[MineForeman.com]

And.............

Customs seem to think it is some sort of incendiary device that shoots users full of heroin.....  (while downloading a torrent containing music, movies and wiki leaks files no doubt)

Suffice to say it is back on my desk now and I am filling out a declaration form. 

I should have done the declaration fist time, it will get back in the post today.

[kano]

Heh - maybe you've discovered what happened to the Avalon ASICs after all

[sounds]

made my day

[kano]

r π arrived! ... now to play

[MineForeman.com]

r π arrived! ... now to play

Pi seems broken in this font.  To me it looks like a RN (Short for registered nurse) has turned up any your going to play with her.

Anyway, have fun, its a great toy.

[kano]

After messing with it for a while ... then finally connecting it to my 40" HDMI TV ... I found why it wouldn't boot.
It didn't like my new cheap Class 6 4GB SD card so I gave up until I had time to find another one.
Yesterday I found an old (2006) 2GB one from my camera (in 'archive') that was full of photos ...
Transferred all that to the new 'crappy?' 4GB and put the new 4GB into 'archive' then put 2012-12-16-wheezy-raspbian on the 2GB and all works fine.

FYI anyone wanting to compile FPGA USB style from 2012-12-16-wheezy-raspbian add the following:
apt-get install vim screen
apt-get install automake
apt-get install libcurl4-openssl-dev
apt-get install libusb-1.0.0-dev
apt-get install libncurses5-dev
CFLAGS="-g -W -Wall" ./autogen.sh --enable-icarus --enable-bitforce --enable-ztex --enable-modminer
make clean
make

No code changes required at all
... and my new USB code/hotplug/Device locking all works fine with the BFL (the device locking is if you run 2 cgminers)

When I ran the above I didn't include ztex coz I don't have one.
Icarus you'll have to specifiy the /dev/ttyUSBn or also: apt-get install libudev-dev
However I detest the serial-USB and thus have no desire to even install libudev-dev for testing

So this is a first attempt at using the standard rpi ubuntu and see how the USB survives.
http://www.raspberrypi.org/downloads

Click on the images to see bigger ones:


For the power lead I was able to use an old wall plug phone charger I have - I found to my surprise

Much thanks indeed to MineForeman.com for the rpi B 512

So now it's ready to try ASIC as soon as I get one and write a driver

[MineForeman.com]

Good to hear you got it all going .

Any reason you used wheezy?  It would have been nice to have you on-board as a tester/contributor.

[kano]

Good to hear you got it all going .

Any reason you used wheezy?  It would have been nice to have you on-board as a tester/contributor.

I'm interested to see what the USB problem is with the standard rpi release or if it is gone.
I'll use that as the base for testing, since that's what rpi release with it.
In general I avoid custom kernels+releases for a number of reasons (I've mentioned on the board before) but in this case I'll test yours also when I have time.
However, at this point even playing with this is time I'm short of.

Had the compile failed I probably would have delayed it until I actually got an ASIC because:
I've got my plane tickets to BFL - Kansas City today (email digital ticket details from the travel agent) from Josh
So I'm now short on time for the next month
I never get much done quickly - so the flight to the USA on the 17th Feb (my time) and a week in total, means there's stuff I need to get done before that - non BTC stuff also
I'll test it with your kernel/config when I get to testing the ASICs but your custom interface/mining management anyone can test and I'll not use it anyway.

My original interest with your custom version was to resolve USB problems, but if the problems aren't there any more, then IMO you are better to supply a script+downloads to produce your release from the base rpi release (of course if the USB problems are still there - then that's a completely different issue altogether) So for now I'll just let it run on wheezy-raspbian (2012-12-16) and see if it fails/crashes/drops the device at all.

[MineForeman.com]

I'm interested to see what the USB problem is with the standard rpi release or if it is gone.

Good point, I am very interested in this as well, I dont have FPGA's to test with but I was never able to reproduce the problem with either wheezy-raspbian or MinePeon, and I tried really hard.

IMO you are better to supply a script+downloads to produce your release from the base rpi release

MinePeon is meant to be a plug and play, lean and mean optimised mining build.  Having to log in, download stuff, run scripts and configure stuff is something I am trying to avoid.  I am trying to make it accessible to all, no mater what your linux skills are like.

[kano]

I've had my rpi (still using 2012-12-16-wheezy-raspbian) running for a few days now with 1xMMQ and 1xBFL without any trouble
(with only one manual restart coz I rewrote a part of the MMQ driver)

I noticed that the MMQ was using about 3% CPU per daughter board (so about 12% for an MMQ)
So I changed the MMQ code to only poll every 100ms (instead of every 10ms) and check the temperature every 500ms (instead of every 300ms)
This has reduced it to roughly 0.5% CPU per daughter board (so about 2% for an MMQ)

On top of that of course there is the main cgminer code - and that's using somewhere around another 0.5% CPU Stratum mining on OzCoin
(and the BFL is using a bit under 0.2% CPU)

This does bring up some information in advance for ASIC
The BFL SC polling for results will probably be only a few times every nonce range time - so for 80GH/s it will be ~54ms per nonce range so maybe poll once every 1/3 of that (or maybe only once per nonce range will be enough?)
Anyway I haven't decided yet and of course wont until I actually have some hardware - but the reality is that it may well only be as much USB CPU usage as the MMQ code before I changed it.
The amount of data sent to do the work would be of course be one queued element per result (based on the current BFL spec) thus it may even be realistic to consider the USB CPU usage of the BFL SC Single to be less than the old MMQ code.

However, the main cgminer code will be processing 70~100 times the number of 1diff shares.
So I'd guess that the rpi should be able to handle a single 60~80GH/s ASIC, but not sure how that will go with more than one.
Of course until I get some ASIC hardware and can see the real CPU usage, this is all just guess work

P.S. my new MMQ code is in my 'hotplug' branch here:
https://github.com/kanoi/cgminer/tree/hotplug

hmm maybe the MMQ needs an --mmq-options so you can specify the poll time ...
(something like Icarus has for specifying options)

[kano]

Just in case anyone was interested ...
I have been making an rpi binary at the same time as my usual binary I release when ckolivas makes a new release.

2.11.2
https://bitcointalk.org/index.php?topic=28402.msg1603027#msg1603027

I put the binaries in my cgminer-binaries git:
https://github.com/kanoi/cgminer-binaries

[Morblias]

Just in case anyone was interested ...
I have been making an rpi binary at the same time as my usual binary I release when ckolivas makes a new release.

2.11.2
https://bitcointalk.org/index.php?topic=28402.msg1603027#msg1603027

I put the binaries in my cgminer-binaries git:
https://github.com/kanoi/cgminer-binaries

Awesome, thanks!

[kano]

Well after all this time just using BFL and MMQ FPGAs with direct USB without real problems, I tried my Icarus which still uses serial-USB
The rpi itself crashed when I first plugged them in.
Within 10 minutes of mining it crashed again - so I've decided to avoid doing that again with an Icarus.
YMMV

[MineForeman.com]

I tried my Icarus which still uses serial-USB
The rpi itself crashed when I first plugged them in.

I can verify there are problems with the serial-USB and the default raspbian pi kernel (and any other kernel that I try).

I can also verify that the problem is NOT present in x86 and i386 identical builds (apart from architectural) so the problem is most likely somewhere or something to do with the Pi itself.

This is no means a show stopper for mining on the Pi, it is just something to be aware of.

[BitMinerN8]

I tried my Icarus which still uses serial-USB
The rpi itself crashed when I first plugged them in.

I can verify there are problems with the serial-USB and the default raspbian pi kernel (and any other kernel that I try).

I can also verify that the problem is NOT present in x86 and i386 identical builds (apart from architectural) so the problem is most likely somewhere or something to do with the Pi itself.

This is no means a show stopper for mining on the Pi, it is just something to be aware of.

Yeah, looking forward to see if it can handle 2 or 3 Single SC's. 

[MineForeman.com]

Yeah, looking forward to see if it can handle 2 or 3 Single SC's. 

Me too, just to make sure that I don't spread mis-information though it is NOT lib-usb that has the issue, it seems to be only the serial-usb that has 'issues', and even then I have no serial-usb FPGA devices to test with (like Kano did, and found problems).

And added to that, no one has tested ASIC with the Pi (lib-usb or serial-usb) so it may turn out to be a non issue.

[kano]

Yeah, looking forward to see if it can handle 2 or 3 Single SC's. 

Me too, just to make sure that I don't spread mis-information though it is NOT lib-usb that has the issue, it seems to be only the serial-usb that has 'issues', and even then I have no serial-usb FPGA devices to test with (like Kano did, and found problems).

And added to that, no one has tested ASIC with the Pi (lib-usb or serial-usb) so it may turn out to be a non issue.

The problem with serial-USB is that each device has it's own kernel driver.
Thus each driver's bugs are able to take hold and cause problems (and cause incompatibilities between them)

I've not bothered to rewrite the Icarus driver coz ... I've not had the time and not really something I care too much about ...

Everything else (non-GPU) on cgminer uses libusb and mining with two different devices (BFL and MMQ) going through the same libusb has not had any major problems (i.e. no problems that were rpi specific)

All the new ASIC drivers we write are (and will be) libusb also.

... I'll have a few ASICs soon ... well ... certainly before the end of the world at least