Topic: [DIY] - Reward $100 | Antminer S1/S3 Blade on Raspberry Pi - page 23. (Read 82179 times)

Has anyone thought of using a BusPirate to pull the info from the original Bitmaintech Antminer controller?
http://dangerousprototypes.com/docs/Bus_Pirate

This is the way I understand it.
1. the temp is read from the board via a pin (the temp sensor is that chip in the middle of the board). It has been mentioned in this thread what pin number this is, and as far as I can recall, the proto-board can read this too. Some chips also return their temperature individually, but I am not sure the BM1380 does this, or whether the board has been equiped to be able to read the chip temp.
2. when hashing, there is a sequence of events.

• initialise the board with the frequency you choose to run the chips at. This sets the speed at which each chip will hash and therefore you can tell (the manufacturers of the chip) how long it will take to compute the nonce, thus the timeout.
• in the initialisation, you also have a timeout number (in miliseconds / seconds ) which should be kept by the software.
• send the nonce to be searched by the chip, take note of the time sent and await a result within the timeout period. A result could be found before the alloted timespan and returned, else the chip(s) will sit idle after that.
• if a result is returned, the software then checks whether the size of the result matches (or exceeds) the difficulty requested (diff) by the pool and then sends it on to the pool, else it is trashed.

EDIT:
3. HW errors occur when the chip fails to return a value which can be caused by either a reall HW error (e.g over-heat) or when the timeout is set low and the chip does not get a chance to finish the search and return a value. Again, the software that sends work to the chips monitors this (aka count them out and count them in!)

// Bmsc doesn't send a completion message when it finishes
// the full nonce range, so to avoid being idle we must abort the
// work (by starting a new work item) shortly before it finishes
//
// Thus we need to estimate 2 things:
//      1) How many hashes were done if the work was aborted
//      2) How high can the timeout be before the Bmsc is idle,
//              to minimise the number of work items started
//      We set 2) to 'the calculated estimate' - BMSC_READ_REDUCE
//      to ensure the estimate ends before idle
//
// The simple calculation used is:
//      Tn = Total time in seconds to calculate n hashes
//      Hs = seconds per hash
//      Xn = number of hashes
//      W  = code/usb overhead per work
//
// Rough but reasonable estimate:
//      Tn = Hs * Xn + W        (of the form y = mx + b)
//
// Thus:
// Thus:
//      Line of best fit (using least squares)
//
//      Hs = (n*Sum(XiTi)-Sum(Xi)*Sum(Ti))/(n*Sum(Xi^2)-Sum(Xi)^2)
//      W = Sum(Ti)/n - (Hs*Sum(Xi))/n
//
// N.B. W is less when aborting work since we aren't waiting for the reply
//      to be transferred back (BMSC_READ_TIME)
//      Calculating the hashes aborted at n seconds is thus just n/Hs
//      (though this is still a slight overestimate due to code delays)
//

// Both below must be exceeded to complete a set of data
// Minimum how long after the first, the last data point must be
#define HISTORY_SEC 60
// Minimum how many points a single BMSC_HISTORY should have
#define MIN_DATA_COUNT 5
// The value MIN_DATA_COUNT used is doubled each history until it exceeds:
#define MAX_MIN_DATA_COUNT 100

the original version from bitmain get the temp info when they read the last calculated hash, i will need to see if there is more info hiding in the data that we recieve from the blade, or if it was something the pic handled on the control board.

in regard to timing:

this is how ive learned the chips do their magic, you send the data to the chip, and just before it is done calculating the hash, the chip needs to get a cancel order, then read the hash, so, if your too fast with the timing, you cancel unfinshed calculations, if your too slow, it sits and wait for new orders... theirfor timing needs to be correct.

I have only 4 blades and 2 cp2102 (I have bought them per $8 per piece) just now but already purchased 2 more (about $2,6 per piece).
What is much more important I think is to solve how to get proper information about how chips are running, about their status "x" or "o" and temperature. Have You any idea how to do it? In original S1 unit there is kernel module which very probably does it, send that info into some virtual device where cgi-bin script is reading it. But depends on if those informations are there where we are connected now or if there is need to attach another pin of the blabe.

its called curiousity :-p

well we have the software side running as it should, now we just need the prototype, or order 15 more cp2102 :-/

Better to order one more cp2102 I think. But good luck

it sends a known nonce to the asics, and expects to recieve the 000187a2 but the error code it recieves is a communication timeout, and does not recieve any data.

Seems like the REAL initialise routine just fiddles about with the usb, nothing to do with the board .... unless there is something hidden in the usb_ident structure.

[2014-11-08 18:08:27] Bmsc recv golden nonce timeout code 2 recieved: 0000000000 - should have recieved: 000187a2

That does not offer any insight, to me at least, but suffice to say, I have seen that zero number printed out in the error messages before, though I have tried to replicate it to no avail.

----------------start nonce------------------
 [2014-11-08 18:08:26] Bmsc send golden nonce
 [2014-11-08 18:08:27] Bmsc recv golden nonce timeout code 2 recieved: 0000000000 - should have recieved: 000187a2
 [2014-11-08 18:08:27] -----------------start freq-------------------
 [2014-11-08 18:08:27] Send frequency 82078106
 [2014-11-08 18:08:28] Send freq getstatus 8

perhaps this table of frequencies and timings will be useful )

https://bitcointalksearch.org/topic/m.9170433

OK.
Since you have managed to get all 64 chips detected, then I suppose you can try to find out why it is not going past the golden_nonce test:

After this: applog(LOG_ERR, "Bmsc recv golden nonce timeout");
Add this: applog(LOG_ERR, "Bmsc recv golden nonce timeout received: %s", ret);
My C++ is useless, but that should tell us what the return is (or does it fail on the next if ... else ... ?)

EDIT: I have actually just seen the REAL initialization routine in driver-bmsc.c aka

its the area where it tests the golden nonce, in driver-bmsc.c just trying to bypas this area to see if i can get it to start hashing

static void bmsc_initialise(struct cgpu_info *bmsc, int baud){ 
... 
}

The detection routine? Is that in reference to the CP2012 ?
I am still unsure where the bmsc code determines the number of chips since it at times initializes less than the 32 on a board, and by initializing I mean setting the frequency if you have that in the command-line, otherwise, I can not see where it does that!

Anyway back to your thingy-bob, where in code do you disable the detection routine that you refer to?

im working directly off my github version, so far i have had no luck, ive even tried to disable the detection routine, and pretended everything "was fine"

What mods have you made to the driver? I tried that with 3.8.5 and both boards were hashing the same nonce ..... thus single board speed.

well, im currently looking into connecting 2 boards to 1 cp2102, i get to set freq on all 64 chips, but currently timing out on golden nonce test...

ensure Yourself if wires are fixed properly. I use such workaround to fix them: ...

have you tried with the drivers from silab? ....