Open rapsacw opened 1 year ago
Found this out while toying with the BM1387; The asics do not search the entire nonce range. My 2 asic miner splits the 32-bit range to 0x00000000-0x80000000 for the first asic and 0x800000000xffffffff for the 2nd asic. But the first asic will only find nonces in the range of 0x00000000-78ffffff for the 1st and 0x80000000-0xf8ffffff for the 2nd asic. Likely this has something to do with using decimal or hex for mega/giga/terra like with storage media.
How do you have the address pins set? This write up on the old BM1380 says the address pins are used to control the nonce range.
The BM1397 don't have as many address pins. I think there might also be a register used to control the address?
I wonder if this has anything to do with the mysterious nonce pattern
And the asics don't do nonce rollover anymore, if the asic does not get new work before running out of nonces to try it will do 'something else'. This will slightly reduce the power consumed by the asic, and this can cause problems for other asics in the chain. This is mostly noticable when undervolting the asics for efficiency.
This is really a bummer in the Bitmain ASICs. I wish they didn't do this, but I have to assume it's an efficiency thing somewhere in the design of the chip. cgminer puts a lot of effort into using the hash frequency and a timer to figure out when the chips should be done with their nonce range and send them new work before they go do 'something else'.
btw Skot, I've lost access to bm1387.rs do you have a copy of that file? Or better a copy of that entire braiins-open release containing that emu?
oof, is this in the BraiinsOS or BOSminer source? I didn't clone it. Someone must have a fork somewhere on GitHub. I'll look around.
The address pins are only used to set the I2C address of each asic. The nonce range per chip is set in the initialization with the 0x41 0x05 command ( 0x41 0x05 asr 0x00
About the mysterious nonce pattern; yes, that might be it!
this is frustrating, internet archive got into that folder, but didn't get any of the source; https://web.archive.org/web/*/https://github.com/braiins/braiins/blob/bos-devel/open/bosminer/bosminer-am1-s9/*
The address pins are only used to set the I2C address of each asic.
The hashboards have I2C, but I don't think the ASICs do.
The nonce range per chip is set in the initialization with the 0x41 0x05 command ( 0x41 0x05 asr 0x00 where asr is (0x100 / nc) * j, with nc = number of asic chips in chain and j the asic for which the range is set.)
ok, that makes sense. But then what are the address pins on the BM1387? What do the S9 hashboards have them set to?
The hashboards have I2C, but I don't think the ASICs do.
I've checked it again, the chips have I2C, but it is not used on antminers. The I2C connections are on the secondary function of the TF & RF pins (I have no idea how to select that function, maybe with the TEST pin?)
How do you have the address pins set?
I have them all tied to ground.
btw: the response out signal (RO) is duplicated on the RF pin, my v0.1 used it to receive the response from the asic on the esp. An S9 also connects the hashboard's serial interface to that pin on asic#1 (traced the line on a defective hash board).
this is frustrating, internet archive got into that folder, but didn't get any of the source;
I am afraid this is going to be a show stopper (for me at least). Without that info it is highly unlikely the esp32 will be fast enough to check the nonces for more than 1 or 2 BM1387s, and likely not for a single BM1397.. In the files are emulators for the bitmain asics including the instruction to set the target difficulty that would limit the number of nonces the esp32c3 had to check for share target difficulty.
I've opened an issue on braiins-open asking for these files, lets hope they are willing to help us out.
I am afraid this is going to be a show stopper (for me at least). Without that info it is highly unlikely the esp32 will be fast enough to check the nonces for more than 1 or 2 BM1387s, and likely not for a single BM1397.. In the files are emulators for the bitmain asics including the instruction to set the target difficulty that would limit the number of nonces the esp32c3 had to check for share target difficulty.
I've opened an issue on braiins-open asking for these files, lets hope they are willing to help us out.
What about the bmminer from Bitmain? https://github.com/bitmaintech/bmminer-mix
What about the bmminer from Bitmain?
Again, good find!, sadly it only has the command for the bm1387 but its a start.
Did Braiins ever release an open source BM1397 based miner? I thought all we got was the BM1387 from the S9.
You might also check out the cgminer kano edition. It should be working with multiple BM1397 now.
They didn't but in the emulator they had the bm1391 and if I remember correctly also the bm1397. Found out another titbit of info; you can check the validity of the nonce returned by the bm1387 with its checksum (last byte of the nonce response), to calculate the checksum take the first 6 bytes of the response, add another byte to it containing 0x80 and call the crc5 routine with length 6*8+3.
`uint8_t CheckNonce(uint8_t *nonce) // return 1 for valid checksum { uint8_t valid = 0;
nonce[7] = 0x80; uint8_t n1 = bmcrc(nonce, 6*8+3);
n1 |= 0x80; if (n1 == nonce[6]) { valid = 1; CDCSER.print("CRC ok:"); } return valid; } `
Found this out while toying with the BM1387; The asics do not search the entire nonce range. My 2 asic miner splits the 32-bit range to 0x00000000-0x80000000 for the first asic and 0x800000000xffffffff for the 2nd asic. But the first asic will only find nonces in the range of 0x00000000-78ffffff for the 1st and 0x80000000-0xf8ffffff for the 2nd asic. Likely this has something to do with using decimal or hex for mega/giga/terra like with storage media.
And the asics don't do nonce rollover anymore, if the asic does not get new work before running out of nonces to try it will do 'something else'. This will slightly reduce the power consumed by the asic, and this can cause problems for other asics in the chain. This is mostly noticable when undervolting the asics for efficiency. btw Skot, I've lost access to bm1387.rs do you have a copy of that file? Or better a copy of that entire braiins-open release containing that emu?