Topic: Hacking The KNC Firmware: Overclocking - page 65. (Read 144362 times)
ya i've just been google eyed throughout this thread, this awesome!
Interesting find, I was wondering when the OC would begin with the KNC devices esp with the diff changing every 10 days or so its good to see how much extra hash rate you can get. Keep up the good work guys!
What is maximum stable result you have?
800MHz on 2 modules and 788 on 2 more.
I have seen higher but not stable on multi modules.
Now running each module seperate to find the sweet spots.
I have seen clocks way higher 1-2 gig range.
Getting them to settle is gonna be fun.
Forward engineering clocks can be tricky and tedious, reverse engineering them can be fun and exciting, and tedious. Lots of waiting for results to settle and sustain.
I have taken much data, now working it backwards to refine guess on rest of the paramaters that are not adjustable.
This currently has most potential for sleeping die folks, 37Gh/s gain per module.
I think finding stable settings for 750 that works on every module and die is doable.
Might not be same for every module but can be narrowed to few combo's to try.
YMMV
What is maximum stable result you have?
Well I bit the bullet and tweaked the 0x86 register on one die. I tried a few different values, 0x0168, 0x0068, and 0x01ff. initc did not seem to throw any errors, and everything hashed like normal. I did not notice a difference in power consumption on any of the settings, so I can only assume the hash clock was not affected.
So ... there goes that theory.
So ... there goes that theory.
Awesome job figuring out that checksum algorithm.
Take a look in /etc/init.d/cgminer.sh and you will have your answer to why nothing changed.
It is writing to the same SPI PLL registers by hand in there just before starting cgminer, not looking in the eeprom.
for p in $good_ports ; do
# Re-enable PLL
i2cset -y 2 0x71 1 $((p+1))
for c in 0 1 2 3 ; do
cmd=$(printf "0x84,0x%02X,0,0" $c)
spi-test -s 50000 -OHC -D /dev/spidev1.0 $cmd >/dev/null
cmd=$(printf "0x86,0x%02X,0x01,0xD1" $c)
spi-test -s 50000 -OHC -D /dev/spidev1.0 $cmd >/dev/null
cmd=$(printf "0x85,0x%02X,0,0" $c)
spi-test -s 50000 -OHC -D /dev/spidev1.0 $cmd >/dev/null
done
The table for disabled cores is also stored in the eeprom at offset 0x4c and 192 bits forward.
Thx for the huge hint!
I can confirm it works.
150 Gh/s per module on Oct 4 VRM modules.
I have 2 Saturn doing a reliable 600 at the pool and 720 at the wall.
Along the way I managed to put to sleep and awaken individual die.
I think this is the way to address the dead die issue.
I offered to discuss my findings with a KnCMiner engineer, no reply.
My guess/observation is it is a low priority for KnC to fix the dead die issue.
Sad if true.
The fix seems simple, monitordcdc knows, try different clocks when dead die detected.
I have tested many low current working solutions at stock speeds.
One problem I ran into is that every ASIC is different and the .sh threats them all the same.
One Saturn was easy and one I had to do a lot of hunting (not recommended)
My next step will be unrolling the afore mentioned program loop and try each module seperately and possibly each die seperately for maximum yield.
Trying any of this will VOID YOUR WARRANTY.
You might kill your miner AND have no warranty!
You have been warned.
I have an educated guess on the field width of the variables.
I treat them as 4 bit fields with some success.
If the middle one is 5 or 6 bits wide more finesse is possible.
The lowest 2-4 bits seem to control the output and/or loop divider.
Larger numbers more division (behaves like divider)
Has a major impact, compensate with what I am calling input/reference divider.
Middle nibble seems like 4 bits of loop control.
There may be more lower bits to this field, unconfirmed.
Larger is faster.
This is the one to fiddle with once the others are close.
Highest nibble 3-4 bits of what I call input/reference divider.
Larger numbers less division (behaves like add or multiply)
Start with the middle one only and watch the current!!!
Be ready to bail if needed.
Just stop modified sh and start unmodified one.
(you did modify the COPY of the file right?)
I might have the fields backwards but I get predictable results.
This is a dangerous game to play with an expensive ASIC.
You will VOID YOUR WARRANTY and might kill your machine.
Please refrain from simplifying the process for the masses, yet.
The edits are easy, the possibility of meltdown is real.
Further testing is needed.
Don't even think about editing this stuff on a Nov unit with 8 VRM's
There is easily enough power available to cook your ASIC.
It is also not the same file to edit.
Think twice about it if you have an Oct. with 8 VRM.
There is easily enough power available to cook your ASIC.
I use 47 A and 37 W as the max per die for 150 Gh/s per module.
Under 45 A and 35 W max with stock 144 per module speed.
The main use I have for the tuning suite is feedback.
The SPI clock @ 200k is plenty. Higher is fun but not very effective.
I looked with a scope, there is room to spare @ 200k.
I leave everything default until i get the ASIC clock happy.
Once the clock is happy the rest makes little difference and I only tune V for lower power.
VCO current is IMneverHO more important than all else.
It is significant, an Idle die uses ~15 A, much of that is the clock.
If you see a die with 0 A suspect a stalled clock.
There are even ways to occasionally unstall a stalled clock.
Make a small edit to the SPI clock and hit the apply button.
For the 'hardware' tweakers, I speculate 2 loop caps per die on bottom of board.
Next diff increase or so and I may take the iron and find out.
I spent a lot to find and document the details and pass them on, downtime is money.
You can help fund this research if interested.
Just point your miner to one of my workers for a few minutes.
For BTCGuild worker = tolip_ZsearchFund (PPS, best for short donations)
For GHash.io worker = tolip.anything (replace anything with your name if you like)
You can also use my reseller ID if you purchase a Neptune.
https://www.kncminer.com/?resellerid=206
Enjoy
Thanks for the digging so far..appreciate the share.
They are easy to check/set, but like you, I wouldn't recommend it.. It can be a great way to try to keep your temps in the 'magic zone' but you need to watch the VRM amp loads and temps very carefully.
The values are an offset from a 'full' voltage value, which is 0.950 volts. The higher the value, the less subtracted from 0.950 value, with FFFF being ZERO subtracted. Older codes (like 0.91) came with much higher volts, and the current code (0.98) sets 0xff67, which works out to about 0.797 volts.. But even that value appears to be a 'suggestion' since each core on a die will be some variance off THAT number.
I have not yet succeeded in discovering how to change the hashing clocks. It appears possible.
The VRM voltages should be easy to adjust over I2C. Though I do not recommend it, yet.
The VRM voltages should be easy to adjust over I2C. Though I do not recommend it, yet.
They are easy to check/set, but like you, I wouldn't recommend it.. It can be a great way to try to keep your temps in the 'magic zone' but you need to watch the VRM amp loads and temps very carefully.
The values are an offset from a 'full' voltage value, which is 0.950 volts. The higher the value, the less subtracted from 0.950 value, with FFFF being ZERO subtracted. Older codes (like 0.91) came with much higher volts, and the current code (0.98) sets 0xff67, which works out to about 0.797 volts.. But even that value appears to be a 'suggestion' since each core on a die will be some variance off THAT number.
Any Updates?
Maybe they threw in a bunch of totally random values just to mess with people trying to tweak their hardware.
Maybe you should try probing the data that comes over the ribbon cables. I would imagine the clockrate (or some analog) would have to be transferred over at some point.
Maybe you should try probing the data that comes over the ribbon cables. I would imagine the clockrate (or some analog) would have to be transferred over at some point.
Okay, I tried tweaking the cgminer.sh script to setup my board with a PLL setting of 0x01,0x68. Power consumption did not change. I also tried 0x00,0x68; again no change. This was tested with a restart of the service. I haven't tried a reboot (would need to modify the BBB's flash or something). It's possible the PLL settings can be set only once per power-cycle, but that'd be a bit out of the ordinary.
Quote
Take a look in /etc/init.d/cgminer.sh and you will have your answer to why nothing changed.
Awesome, thanks for the heads up. I knew I should have done a more thorough grep of the firmware...I'll take a look, and maybe I'll *gulp* tweak those values.
Well I bit the bullet and tweaked the 0x86 register on one die. I tried a few different values, 0x0168, 0x0068, and 0x01ff. initc did not seem to throw any errors, and everything hashed like normal. I did not notice a difference in power consumption on any of the settings, so I can only assume the hash clock was not affected.
So ... there goes that theory.
So ... there goes that theory.
Awesome job figuring out that checksum algorithm.
Take a look in /etc/init.d/cgminer.sh and you will have your answer to why nothing changed.
It is writing to the same SPI PLL registers by hand in there just before starting cgminer, not looking in the eeprom.
for p in $good_ports ; do
# Re-enable PLL
i2cset -y 2 0x71 1 $((p+1))
for c in 0 1 2 3 ; do
cmd=$(printf "0x84,0x%02X,0,0" $c)
spi-test -s 50000 -OHC -D /dev/spidev1.0 $cmd >/dev/null
cmd=$(printf "0x86,0x%02X,0x01,0xD1" $c)
spi-test -s 50000 -OHC -D /dev/spidev1.0 $cmd >/dev/null
cmd=$(printf "0x85,0x%02X,0,0" $c)
spi-test -s 50000 -OHC -D /dev/spidev1.0 $cmd >/dev/null
done
The table for disabled cores is also stored in the eeprom at offset 0x4c and 192 bits forward.
How can I keep on running asic_test until I get the highest amount of good cores, then use that information to put into the emprom for the max amount of cores
Thanks for the effort Fpgaminer!
Are there strong indications that the clock is controllable in software (like supplied by the beagle board) and not just some IC in each board with a fixed frequency?
Well I bit the bullet and tweaked the 0x86 register on one die. I tried a few different values, 0x0168, 0x0068, and 0x01ff. initc did not seem to throw any errors, and everything hashed like normal. I did not notice a difference in power consumption on any of the settings, so I can only assume the hash clock was not affected.
So ... there goes that theory.
So ... there goes that theory.
EEPROM Checksum Algorithm
I finally reverse engineered the algorithm KNC is using to checksum the ASIC board EEPROMs. I had initially thought it was just SHA-256, but a quick try with that failed. After digging into the code my original hypothesis proved correct, it's SHA-256, but KNC has ... taken some liberties with SHA-256. It's pretty confusing code. First, the checksum function is completely broken unless the data being checksummed is a multiple of 64 bytes (the data in the EEPROMs is). Second, they use SHA-256 without any padding. Third, they use SHA-256 with their own KNC flavored initial state. Their initial state is the ASCII representation of "KnCMiner placeholder SHA256 init". I've recreated the important bits of the algorithm in Python:
whole_data in the code above is a copy of the data off one of my ASIC board EEPROMs (without the first 32 bytes, which is the stored checksum). The code prints the calculated checksum, which matched the EEPROM I tested.
So, yay, but it really makes me wonder what the KNC developers were doing. I can understand not doing the padding and only working on multiples of 64 bytes; the devs probably had higher priorities. I just don't understand the initial state thing. The real SHA-256 initial state values exist within initc. It's just that the checksum function overwrites them. Wonky.
Progress Update
We can use this to update our EEPROMs and have initc accept the checksum. I still don't know how to make sense of the PLL configuration data, but some progress is better than none. I also manually decompiled the write_eeprom function of initc. It's nothing special though, I can craft modified EEPROM data by hand easily and just use the command line to write it.
Regarding the PLL configuration data. When write_eeprom is building a new EEPROM image it first fills the buffer with random data (calling rand()). This explains why the padding on all the EEPROMs was garbage data. I'm not sure why they do it, though. It leads me to believe, though, that KNC's developers may have a habit of filling unused data with rand. Perhaps the PLL 0x84 and 0x85 registers are unused in the current ASIC revision? Maybe they were used by their FPGA prototype(s). Most importantly, perhaps only 0x86 is important, and is simply a multiplier value (or two 8-bit values, Multiplier and Divider). I don't know what the chip's input clock frequency is, so it's hard to make an educated guess about how to interpret the current setting.
That theory could be tested by adjusting the 0x86 registers of the PLL data and ... seeing what happens. Though if the theory is wrong, doing so could potentially set the chips a blaze. I don't personally want to try that (yet) ... if anyone with bigger balls than I wants to do so, feel free to try...
I'll continue decompiling initc to see if there are more hints as to the meaning of the PLL data.
I finally reverse engineered the algorithm KNC is using to checksum the ASIC board EEPROMs. I had initially thought it was just SHA-256, but a quick try with that failed. After digging into the code my original hypothesis proved correct, it's SHA-256, but KNC has ... taken some liberties with SHA-256. It's pretty confusing code. First, the checksum function is completely broken unless the data being checksummed is a multiple of 64 bytes (the data in the EEPROMs is). Second, they use SHA-256 without any padding. Third, they use SHA-256 with their own KNC flavored initial state. Their initial state is the ASCII representation of "KnCMiner placeholder SHA256 init". I've recreated the important bits of the algorithm in Python:
Code:
# SHA-256 implementation copied from pypy/lib_pypy/_sha256.py, which is licensed under the MIT license:
# https://github.com/pypy/pypy/blob/master/lib_pypy/_sha256.py
# https://github.com/pypy/pypy/blob/master/LICENSE
import struct
SHA_BLOCKSIZE = 64
SHA_DIGESTSIZE = 32
def new_shaobject():
return {
'digest': [0]*8,
'count_lo': 0,
'count_hi': 0,
'data': [0]* SHA_BLOCKSIZE,
'local': 0,
'digestsize': 0
}
ROR = lambda x, y: (((x & 0xffffffff) >> (y & 31)) | (x << (32 - (y & 31)))) & 0xffffffff
Ch = lambda x, y, z: (z ^ (x & (y ^ z)))
Maj = lambda x, y, z: (((x | y) & z) | (x & y))
S = lambda x, n: ROR(x, n)
R = lambda x, n: (x & 0xffffffff) >> n
Sigma0 = lambda x: (S(x, 2) ^ S(x, 13) ^ S(x, 22))
Sigma1 = lambda x: (S(x, 6) ^ S(x, 11) ^ S(x, 25))
Gamma0 = lambda x: (S(x, 7) ^ S(x, 18) ^ R(x, 3))
Gamma1 = lambda x: (S(x, 17) ^ S(x, 19) ^ R(x, 10))
def sha_transform(sha_info):
W = []
d = sha_info['data']
for i in xrange(0,16):
W.append( (d[4*i]<<24) + (d[4*i+1]<<16) + (d[4*i+2]<<8) + d[4*i+3])
for i in xrange(16,64):
W.append( (Gamma1(W[i - 2]) + W[i - 7] + Gamma0(W[i - 15]) + W[i - 16]) & 0xffffffff )
ss = sha_info['digest'][:]
def RND(a,b,c,d,e,f,g,h,i,ki):
t0 = h + Sigma1(e) + Ch(e, f, g) + ki + W[i];
t1 = Sigma0(a) + Maj(a, b, c);
d += t0;
h = t0 + t1;
return d & 0xffffffff, h & 0xffffffff
ss[3], ss[7] = RND(ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],0,0x428a2f98);
ss[2], ss[6] = RND(ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],1,0x71374491);
ss[1], ss[5] = RND(ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],2,0xb5c0fbcf);
ss[0], ss[4] = RND(ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],3,0xe9b5dba5);
ss[7], ss[3] = RND(ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],4,0x3956c25b);
ss[6], ss[2] = RND(ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],5,0x59f111f1);
ss[5], ss[1] = RND(ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],6,0x923f82a4);
ss[4], ss[0] = RND(ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],7,0xab1c5ed5);
ss[3], ss[7] = RND(ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],8,0xd807aa98);
ss[2], ss[6] = RND(ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],9,0x12835b01);
ss[1], ss[5] = RND(ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],10,0x243185be);
ss[0], ss[4] = RND(ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],11,0x550c7dc3);
ss[7], ss[3] = RND(ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],12,0x72be5d74);
ss[6], ss[2] = RND(ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],13,0x80deb1fe);
ss[5], ss[1] = RND(ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],14,0x9bdc06a7);
ss[4], ss[0] = RND(ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],15,0xc19bf174);
ss[3], ss[7] = RND(ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],16,0xe49b69c1);
ss[2], ss[6] = RND(ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],17,0xefbe4786);
ss[1], ss[5] = RND(ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],18,0x0fc19dc6);
ss[0], ss[4] = RND(ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],19,0x240ca1cc);
ss[7], ss[3] = RND(ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],20,0x2de92c6f);
ss[6], ss[2] = RND(ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],21,0x4a7484aa);
ss[5], ss[1] = RND(ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],22,0x5cb0a9dc);
ss[4], ss[0] = RND(ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],23,0x76f988da);
ss[3], ss[7] = RND(ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],24,0x983e5152);
ss[2], ss[6] = RND(ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],25,0xa831c66d);
ss[1], ss[5] = RND(ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],26,0xb00327c8);
ss[0], ss[4] = RND(ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],27,0xbf597fc7);
ss[7], ss[3] = RND(ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],28,0xc6e00bf3);
ss[6], ss[2] = RND(ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],29,0xd5a79147);
ss[5], ss[1] = RND(ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],30,0x06ca6351);
ss[4], ss[0] = RND(ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],31,0x14292967);
ss[3], ss[7] = RND(ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],32,0x27b70a85);
ss[2], ss[6] = RND(ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],33,0x2e1b2138);
ss[1], ss[5] = RND(ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],34,0x4d2c6dfc);
ss[0], ss[4] = RND(ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],35,0x53380d13);
ss[7], ss[3] = RND(ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],36,0x650a7354);
ss[6], ss[2] = RND(ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],37,0x766a0abb);
ss[5], ss[1] = RND(ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],38,0x81c2c92e);
ss[4], ss[0] = RND(ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],39,0x92722c85);
ss[3], ss[7] = RND(ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],40,0xa2bfe8a1);
ss[2], ss[6] = RND(ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],41,0xa81a664b);
ss[1], ss[5] = RND(ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],42,0xc24b8b70);
ss[0], ss[4] = RND(ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],43,0xc76c51a3);
ss[7], ss[3] = RND(ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],44,0xd192e819);
ss[6], ss[2] = RND(ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],45,0xd6990624);
ss[5], ss[1] = RND(ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],46,0xf40e3585);
ss[4], ss[0] = RND(ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],47,0x106aa070);
ss[3], ss[7] = RND(ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],48,0x19a4c116);
ss[2], ss[6] = RND(ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],49,0x1e376c08);
ss[1], ss[5] = RND(ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],50,0x2748774c);
ss[0], ss[4] = RND(ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],51,0x34b0bcb5);
ss[7], ss[3] = RND(ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],52,0x391c0cb3);
ss[6], ss[2] = RND(ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],53,0x4ed8aa4a);
ss[5], ss[1] = RND(ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],54,0x5b9cca4f);
ss[4], ss[0] = RND(ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],55,0x682e6ff3);
ss[3], ss[7] = RND(ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],56,0x748f82ee);
ss[2], ss[6] = RND(ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],57,0x78a5636f);
ss[1], ss[5] = RND(ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],ss[5],58,0x84c87814);
ss[0], ss[4] = RND(ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],ss[4],59,0x8cc70208);
ss[7], ss[3] = RND(ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],ss[3],60,0x90befffa);
ss[6], ss[2] = RND(ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],ss[2],61,0xa4506ceb);
ss[5], ss[1] = RND(ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],ss[1],62,0xbef9a3f7);
ss[4], ss[0] = RND(ss[1],ss[2],ss[3],ss[4],ss[5],ss[6],ss[7],ss[0],63,0xc67178f2);
dig = []
for i, x in enumerate(sha_info['digest']):
dig.append( (x + ss[i]) & 0xffffffff )
sha_info['digest'] = dig
whole_data = "4131303030303037424245434600000000000000000000000000000000000000000000000000000000000000000100000800000000000000ffffffffffffffff003084005687840174fa8402c03484038f7a860001d1860101d1860201d1860301d18500db118501b7d785023cce85033d1ce7e375f7fe6521ea8991253ae7ed".decode ('hex')
sha_info = new_shaobject ()
sha_info['digest'] = [0x4b6e434d, 0x696e6572, 0x20706c61, 0x6365686f, 0x6c646572, 0x20534841, 0x32353620, 0x696e6974]
sha_info['data'] = [ord (whole_data[i]) for i in range (0, 64)]
sha_transform (sha_info)
sha_info['data'] = [ord (whole_data[i]) for i in range (64, 128)]
sha_transform (sha_info)
for i in range (8):
print "%08X" % sha_info['digest'][i]
whole_data in the code above is a copy of the data off one of my ASIC board EEPROMs (without the first 32 bytes, which is the stored checksum). The code prints the calculated checksum, which matched the EEPROM I tested.
So, yay, but it really makes me wonder what the KNC developers were doing. I can understand not doing the padding and only working on multiples of 64 bytes; the devs probably had higher priorities. I just don't understand the initial state thing. The real SHA-256 initial state values exist within initc. It's just that the checksum function overwrites them. Wonky.
Progress Update
We can use this to update our EEPROMs and have initc accept the checksum. I still don't know how to make sense of the PLL configuration data, but some progress is better than none. I also manually decompiled the write_eeprom function of initc. It's nothing special though, I can craft modified EEPROM data by hand easily and just use the command line to write it.
Regarding the PLL configuration data. When write_eeprom is building a new EEPROM image it first fills the buffer with random data (calling rand()). This explains why the padding on all the EEPROMs was garbage data. I'm not sure why they do it, though. It leads me to believe, though, that KNC's developers may have a habit of filling unused data with rand. Perhaps the PLL 0x84 and 0x85 registers are unused in the current ASIC revision? Maybe they were used by their FPGA prototype(s). Most importantly, perhaps only 0x86 is important, and is simply a multiplier value (or two 8-bit values, Multiplier and Divider). I don't know what the chip's input clock frequency is, so it's hard to make an educated guess about how to interpret the current setting.
That theory could be tested by adjusting the 0x86 registers of the PLL data and ... seeing what happens. Though if the theory is wrong, doing so could potentially set the chips a blaze. I don't personally want to try that (yet) ... if anyone with bigger balls than I wants to do so, feel free to try...
I'll continue decompiling initc to see if there are more hints as to the meaning of the PLL data.
Someone was kind enough to share their EEPROM dumps with me. The basic structure for the PLL data is the same; 4 sets of 3 values. The values for "0x86" are still always 0xd101. The other values, though, continue to appear random.
So, at least the results are consistent. I just wish I knew why the values appear random. That's pretty strange for what should be PLL parameters. Either I'm totally off-mark and this isn't PLL configuration data, the data is encrypted, or I'm missing something...
If you want to walk me thru want you need, I have 1 jup on .95 and I will have 3 more at my facility this week. So, at least the results are consistent. I just wish I knew why the values appear random. That's pretty strange for what should be PLL parameters. Either I'm totally off-mark and this isn't PLL configuration data, the data is encrypted, or I'm missing something...
If you set up a basic guide on how to do it ill gladly share whatever you need.
Someone was kind enough to share their EEPROM dumps with me. The basic structure for the PLL data is the same; 4 sets of 3 values. The values for "0x86" are still always 0xd101. The other values, though, continue to appear random.
So, at least the results are consistent. I just wish I knew why the values appear random. That's pretty strange for what should be PLL parameters. Either I'm totally off-mark and this isn't PLL configuration data, the data is encrypted, or I'm missing something...
If you want to walk me thru want you need, I have 1 jup on .95 and I will have 3 more at my facility this week. So, at least the results are consistent. I just wish I knew why the values appear random. That's pretty strange for what should be PLL parameters. Either I'm totally off-mark and this isn't PLL configuration data, the data is encrypted, or I'm missing something...
Someone was kind enough to share their EEPROM dumps with me. The basic structure for the PLL data is the same; 4 sets of 3 values. The values for "0x86" are still always 0xd101. The other values, though, continue to appear random.
So, at least the results are consistent. I just wish I knew why the values appear random. That's pretty strange for what should be PLL parameters. Either I'm totally off-mark and this isn't PLL configuration data, the data is encrypted, or I'm missing something...
So, at least the results are consistent. I just wish I knew why the values appear random. That's pretty strange for what should be PLL parameters. Either I'm totally off-mark and this isn't PLL configuration data, the data is encrypted, or I'm missing something...
That phone home address seems local to me. Correct me if wrong.
Yes, the URL seems to indicate that the Beaglebone board serial number is the unique identifier.
So they create an internal website and (speculating here) when Zeek orders a miner,
they put his unique config on that webserver at:
http://192.168.100.1:8080/1813BBBK3065 <
and when it is built, they plug it in to Ethernet, they power it up and it programs Zeeks info from his profile and off it goes.
ALL SPECULATION, but that is how I would do it.
That phone home address seems local to me. Correct me if wrong.
u are right, but as he said it could be used in knc hosting facility ot manage fw update and admin tasks
Jump to: