Topic: Linux mining distro for the Raspberry PI - MinePeon - page 137. (Read 685140 times)

Excellent!  I was indeed talking about the ZTEX firmware when I asked if you had upgraded.

It is fairly obvious in the code where the error is generated, Line 170 of libztex.c in libztex_checkDevice.  It basically means that the device has been recognised, the identifier has been read from libusb successfully but when it goes to compare the device identifier  with a list of known devices it does not match.

I am still unsure as to why you got the error though, but that is down to my lack of knowledge of ZTEX devices more than anything else and it is very hard to debug hardware that I down have sitting in front of me.

Using your 'hotplug' trick seems to work though, can I ask if it is still mining at 200.2Mh/s?

It's starting to work. I fiddled with the board connected to a windows PC. Updated the Ztex firmware (it was indeed old) and without switching it off connected it to the Raspi.

 cgminer version 2.10.4 - Started: [2013-01-31 20:56:50]
--------------------------------------------------------------------------------
 (5s):473.1M (avg):200.2Mh/s | Q:7  A:8  R:0  HW:1  E:114%  U:2.7/m
 ST: 2  SS: 0  DW: 12  NB: 2  LW: 27  GF: 0  RF: 0  WU: 3.0
 Connected to 50.31.149.57 diff 1 with stratum as user bensguild_raspberry
 Block: 04ebfa5299bc5b8d...  Diff:2.97M  Started: [20:57:26]  Best share: 7
--------------------------------------------------------------------------------
 [P]ool management [ S ]ettings [D]isplay options [Q]uit
 ZTX 0: 04A346C253-1 | 208.0MHz | 194.9M/200.2Mh/s | A:8 R:0 HW:1 U:2.66/m
--------------------------------------------------------------------------------

 [2013-01-31 20:56:47] ZTEX 04A346C253-1: capability missing: 0 7
 [2013-01-31 20:56:47] ZTEX 04A346C253-1: Found Ztex (fpga count = 1) , mark as
0
 [2013-01-31 20:56:47] Probing for an alive pool
 [2013-01-31 20:56:50] Switching pool 0 http://btcguild.com:8332 to stratum+tcp:
//50.31.149.57:3333
 [2013-01-31 20:56:54] ZTEX 04A346C253-1: Frequency set to 200.0 MHz
 [2013-01-31 20:56:58] Accepted aa113f67 Diff 1/1 ZTX 0
 [2013-01-31 20:56:58] Stratum from pool 0 requested work restart
 [2013-01-31 20:56:59] API running in IP access mode on port 4028
 [2013-01-31 20:57:06] Accepted 3c583a1c Diff 4/1 ZTX 0
 [2013-01-31 20:57:26] Stratum from pool 0 detected new block
 [2013-01-31 20:57:41] Accepted d31c8be8 Diff 1/1 ZTX 0
 [2013-01-31 20:57:57] Accepted 57d37c0c Diff 2/1 ZTX 0
 [2013-01-31 20:58:09] ZTEX 04A346C253-1: Frequency change from 200.0 to 204.0 MHz
 [2013-01-31 20:58:18] Accepted df48cf46 Diff 1/1 ZTX 0
 [2013-01-31 20:59:19] Accepted 22be4434 Diff 7/1 ZTX 0
 [2013-01-31 20:59:32] ZTEX 04A346C253-1: Frequency change from 204.0 to 208.0 MHz
 [2013-01-31 20:59:44] ZTX0: invalid nonce - HW error
 [2013-01-31 20:59:44] Accepted a49ee248 Diff 1/1 ZTX 0

Nice

I tried the new release, but no luck. Still the same error:

 cgminer version 2.10.4 - Started: [2013-01-31 19:46:14] CPU Algo: c
--------------------------------------------------------------------------------
 (5s):125.6K (avg):126.3Kh/s | Q:17  A:0  R:0  HW:0  E:0%  U:0.0/m
 ST: 2  SS: 0  DW: 32  NB: 2  LW: 52  GF: 0  RF: 0  WU: 0.0
 Connected to 50.31.149.57 diff 1 with stratum as user bensguild_raspberry
 Block: 0396df81411ed4b8...  Diff:2.97M  Started: [19:50:41]  Best share: 0
--------------------------------------------------------------------------------
 [P]ool management [ S ] ettings [D]isplay options [Q]uit
 CPU 0:                | 126.4K/126.3Kh/s | A:0 R:0 HW:0 U:0.00/m
--------------------------------------------------------------------------------

 [2013-01-31 19:46:13] Started cgminer 2.10.4
 [2013-01-31 19:46:13] Loaded configuration file /opt/minepeon/etc/cgminer.conf
 [2013-01-31 19:46:13] Found unknown ztex board
 [2013-01-31 19:46:14] Probing for an alive pool
 [2013-01-31 19:46:14] Switching pool 0 http://btcguild.com:8332 to stratum+tcp:
//50.31.149.57:3333
 [2013-01-31 19:46:19] API running in IP access mode on port 4028
 [2013-01-31 19:50:41] Stratum from pool 0 detected new block

I could connect via a browser and change the URL, username and password so I think I am running the new version. You asked before when I last updated my firmware, I then assumed you meant the firmware for the Raspi, but maybe you meant the Ztex board. I will try to run it from a windows pc with cgminer and then connect it to the Raspi without switching off the Raspi.

haha awesome! I will have to test creating a temp directory later, I broke my image and had to put back in my old version SD card. I tried to overclock my RPi and broke it so it won't boot haha oops!

Sorry, been distracted looking at Jeff's photos unpacking his new Avalon ASIC.

RE: fatal: could not create work tree dir 'google-authenticator'.: Read-only file system

It seems you are working in a read only file-system   Are you using the development partition?  If so it looks like it did not image correctly, can try making a directory like /opt/minepeon/tmp and doing it there?

About backup pools, you have a very good point, I will be adding them under "Advanced Setup" (don't look for it now, its not there yet).  In the mean time it seems that you have added them directly to /opt/minepeon/etc/cgminer.conf so all good.

Thanks again for testing, I am going to see if I can integrate google-authenticator as an option just for you  .

What about backup pools? Also where is the .conf file stored now so I can just modify it myself to include all 3 of my pools?

Edit: nevermind found it! /opt/minepeon/etc

Also, I keep getting read only errors:

[root@minepeon home]# git clone https://code.google.com/p/google-authenticator/
fatal: could not create work tree dir 'google-authenticator'.: Read-only file system


tar: pam_google_authenticator.so: Cannot open: Read-only file system
tar: Exiting with failure status due to previous errors


How do I fix that?

Glad to hear it!

The new setup should allow people with zero computer skills get it up and going quickly (it is hard to go wrong with 3 input boxes and a submit button).  There are still a few problems though;-

* How does the new user discover the DHCP IP that the Peon has picked up?
   -- At the moment they still have to log in via the console (root/peon) and type ifconfig,
       I would prefer if they never had to use the console for anything if they did not want to.
       They could get the IP from their router (or whatever it is providing the DHCP).  I am looking
       at samba or upnp so it just appears in the network list of windows computers.

* Because this is a "ready to rock" miner it has to start everything every time without fail, that means that until you fill in those three inputs fields and hit submit it will be using my test account details (you only need to do it once though and it will keep the settings forever no matter how many times you reboot).
   -- I don't really view this as a huge problem, I just want people to be aware of this
       is the behaviour and you might inadvertently mine 0.00038889 BTC for me (thanks for
       the donation).

Next update will include a few things that I am working on, the two most important things for most users being;-

* Graphs in the Web UI, everyone loves a pretty picture.

* Live Update via the Web UI.

7 days here, without any problems.
Now testing new version of MinePeon, everything looks good, setup is really noobproof.

Hi All,

Update Time! I have just finished uploading the most recent image (MinePeon – Alpha 0.0.3) to SourceForge, grab it HERE.

A lot has gone on in this build, lots of clean-up, I have moved all relevant files into /opt/minepeon for easier inspection, fixed a few bugs, and made improvements.

The main thing you will note with the new build is that there is now the start of a web interface, you now no longer need to ssh (or putty) to enter your miner details, all you need to do is open your browser to http://ip.address.of.the.miner/ and there is a very simple form to enter the URL, username and password of the miner account.  The side effect of this is that the miner will automatically start mining with my account, so change it quickly, once changed though the setting will persist through restarts so you only have to do it once.

The update system is 99% of the way there and the next update you do will be a live update without the need to download a 300MB+ image and write it to your SD Card.

I have now had reports that people have had FPGA miners run for 4 days + without the need for interaction, and I hope that I have fixed the ZTEX problems in this release (I did something dumb in the last release, fixed it now).

As always, thanks everyone who downloads and tests this for me, it is appreciated.  I am hoping that I can get it out of Alpha stage before people start to need to start running their ASIC's.

I thought it was probably a hardware issue as well, I was half expecting that the first testers would report back that the USB ports had exploded and that would be that.

While I wont call it fixed yet any stability gains are almost certainly due to me building the distro as a miner.  The default distro (Raspbian “wheezy”) is very impressive, it is a full desktop OS with X, window managers, MP3 players etc..  As an educational tool (its intended purpose) its amazing but like any desktop os you tend to freeze software components (like the kernel) in a state that you know works for 99% of the intended users so you can work on more important things.

When I first sat down to start work on MinePeon I only had 1 thing that I had to get working, the miner.  So I went about building an OS around the miner with all the latest and most advanced software components to give the miner the most perfect environment I could.  Arch Linux was the perfect choice for the upstream, and what you have in the distro is 99% from them.

My contribution was put all of the excellent work of the people before me together in such a way that it gives it the best possible chance of working.

I thought this was a hardware issue. How does your distro fix this thru software?

I can test this on my Icarus miners tonight. I have more than 2 of them, never got it to work reliably in the past due to USB problems, but I'd be willing to give a shot if you got it working. I'd prefer to try BFGMiner as well, just so we have some data on both.

Just to confirm, does this work on a Raspberry PI 256 version? I only have two 256 meg RAM Model B rev 1 PIs...

Or if anyone does...

Well I've got 2xIcarus, 1xBFL and 1xMMQ so I'll be able to test them all separately and together on it.
Again, thanks to MineForeman who is sending one to me!
But of course the biggest point of interest will be how the ASICs go on it, if I ever get any of the promised ASIC devices.

I think MineForeman is the first noob (relatively new to the forum, not anything else ) that I've ever liked. Kudos to you for coming in and being a team player.

I got shafted when I picked up a used RPi, and got the old 256MB beta board, but maybe that'll be an interesting data point. I'll test your iso soon, though I'm not currently able to hook any FPGAs up.

Looks like mineforeman is getting you one! Awesome

My 4 BFL singles have been running for a solid 2 hours with no problems. I will let you know tomorrow how they are doing.

Thanks again for this! http://blockchain.info/tx-index/46541640/65dc4b508a13d78b780f8c7211fab6a29e75e3d79e89bfc1e6e0e2246fed2c42

Edit: over 48 hours running 4 BFL singles with 0 problems.

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

Yeah, usblib, that is my main reason for starting with cgminer, but I cannot see too many problems in supporting BFGMiner, all the relevant stuff is available from Arch ARM.


Well, since your doing that I am a bit embarrassed to mention.... copy the bitstrams in place if you want to use those FPGA's  .

Everything is unmodified from the upstream providers, and yes, BFGMiner will soon be included as soon as I have a nice and easy way for the end user to chose what miner they wash to use (I just need to get around to it).  I am using cgminer now because that is what I am familiar with (from my clients GPU rigs) but both compile and work just fine on board.

My aim is to keep it that way, as unmodified as possable from the origional sources. I am one of the many "Dwarfs standing on the shoulders of giants" so I am very concious that without your guys efforts (and the many people involved in OSS in general) stuff like this would not be possible.

Is it an unmodified version of the cgminer code?
If it is then nothing else required.

If you have modified the cgminer code, please either put the modified code up available somewhere, or preferably send a git pull to https://github.com/ckolivas/cgminer with the changes
Of course it is important for the changes to not affect the other architectures.

Edit: lol at above post.

Most relevant point about that is the cgminer code all uses libusb for FPGA/ASIC except Icarus (coz I haven't converted it yet)
So there will be no need for random drivers or libraries.
(and no issues like libraries interfering with each other with different mining devices or libudev not working properly)

As for "originally" stated above ... well yeah that's the year old FPGA support code (that I also wrote some of) that I am removing and have replaced with the new USB code.

Proper USB auto detect of devices added while running isn't far away either - the new USB detection code lends itself to that directly - so if the USB in the rpi loses a device and then it reappears, cgminer will handle that also in the not too distant future.
It's all to do with using USB, not some serial-USB library on top of USB that restricts access to the devices.

P.S. I am downloading it at the moment, but it's taking an hour ... so I may already know the answer, if source is in the zip, to my question in ... a while