Topic: Hacking The KNC Firmware: Overclocking - page 66. (Read 144380 times)
That phone home address seems local to me. Correct me if wrong.
Thanks really appreciated, keep up the good work!
Since KNC themselves have released no information on how to overclock our units. I have started hacking the firmware myself to achieve that goal. Here is what I have learned so far.
TL;DR
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.
initc
cgminer itself adjusts neither the voltage nor the clock. Instead, there is a program called "initc" that runs on start-up. The code for this program is not currently available. This program appears to be responsible for a whole host of tasks. It runs various self tests on the unit, loads the FPGA's bitstream, checks system configuration, etc. Based on what I have seen poking around, (this is conjecture until confirmed) it is also responsible for setting up the VRMs, and the per-die PLLs.
Per Board EEPROM
It seems that every ASIC board has an EEPROM on it. This EEPROM contains a checksum, serial number, PLL configuration data, a failure flag, and I'm not sure what else. Only about 128 bytes of data or so. They can be read like so: "cat /sys/bus/i2c/devices/X-0050/eeprom | hexdump -C" where X is 3, 4, 5, 6, 7, 8. I have a Jupiter, so I have 3,4,5,6.
The checksum is the first 32 bytes. I don't know what algorithm they're using for checksum. I would have thought SHA-256, but that didn't seem to match. Luckily it doesn't matter; we can just mod initc itself to calculate the checksum for us, when the time comes.
The PLL configuration data is 48 bytes long. It's located at 0x60 in the EEPROM. The first two bytes is the data length (48 bytes), and is not included in the length. There appears to be 3 16-bit numbers for each PLL, with the addresses 0x84, 0x85, and 0x86 associated with them. There are 4 PLLs per ASIC board, since each chip has 4 dies in it. One of the numbers is always 0xd101. The others I haven't figured out. They appear to be completely random, which is odd. It's entirely possible that they are encrypted somehow, if KNC had intended to restrict our ability to overclock. If anyone has some insight here, that would be appreciated.
I know that initc loads this data, verifies the size of the PLL configuration data, and checks the checksum, but I haven't yet reverse engineered the parts of the code that would actually use this data ... if it's used at all. I'm guessing the data is pushed to the ASICs over SPI.
Phone Home
I also discovered that initc contacts http://192.168.100.1:8080/%s?beagleserial=%s. I don't know under what circumstances it does so, nor all the combinations of strings it'll format that with. My guess: it is either part of factory set-up or their hosting facility. Each miner, on bootup, contacts a master server to retrieve pool information and such. Either this always happens, only happens once, or only happens when some flag is set. But we won't know for sure until I finish reverse engineering the program. This part of it isn't my priority though.
Reverse Engineered Source Code
I've manually de-compiled about 10% of initc so far. It sure would be nice if KNC just released this code
This will have to suffice in the meantime. I'm hoping initc manipulates the PLL configuration data, so we can gain more insight into its format. At the very least, it'll be nice to know what this program is doing as a whole.
My EEPROM Dumps
If anyone wants to dump theirs as well, I would be interested in comparing the PLL configuration data.
There's also EEPROMs at 0-0050 and 1-0054. One of those is an EEPROM on the Beagle board, I believe, and just contains the Beagle's serial number. The other one I believe is on the IO board.
TL;DR
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.
initc
cgminer itself adjusts neither the voltage nor the clock. Instead, there is a program called "initc" that runs on start-up. The code for this program is not currently available. This program appears to be responsible for a whole host of tasks. It runs various self tests on the unit, loads the FPGA's bitstream, checks system configuration, etc. Based on what I have seen poking around, (this is conjecture until confirmed) it is also responsible for setting up the VRMs, and the per-die PLLs.
Per Board EEPROM
It seems that every ASIC board has an EEPROM on it. This EEPROM contains a checksum, serial number, PLL configuration data, a failure flag, and I'm not sure what else. Only about 128 bytes of data or so. They can be read like so: "cat /sys/bus/i2c/devices/X-0050/eeprom | hexdump -C" where X is 3, 4, 5, 6, 7, 8. I have a Jupiter, so I have 3,4,5,6.
The checksum is the first 32 bytes. I don't know what algorithm they're using for checksum. I would have thought SHA-256, but that didn't seem to match. Luckily it doesn't matter; we can just mod initc itself to calculate the checksum for us, when the time comes.
The PLL configuration data is 48 bytes long. It's located at 0x60 in the EEPROM. The first two bytes is the data length (48 bytes), and is not included in the length. There appears to be 3 16-bit numbers for each PLL, with the addresses 0x84, 0x85, and 0x86 associated with them. There are 4 PLLs per ASIC board, since each chip has 4 dies in it. One of the numbers is always 0xd101. The others I haven't figured out. They appear to be completely random, which is odd. It's entirely possible that they are encrypted somehow, if KNC had intended to restrict our ability to overclock. If anyone has some insight here, that would be appreciated.
I know that initc loads this data, verifies the size of the PLL configuration data, and checks the checksum, but I haven't yet reverse engineered the parts of the code that would actually use this data ... if it's used at all. I'm guessing the data is pushed to the ASICs over SPI.
Phone Home
I also discovered that initc contacts http://192.168.100.1:8080/%s?beagleserial=%s. I don't know under what circumstances it does so, nor all the combinations of strings it'll format that with. My guess: it is either part of factory set-up or their hosting facility. Each miner, on bootup, contacts a master server to retrieve pool information and such. Either this always happens, only happens once, or only happens when some flag is set. But we won't know for sure until I finish reverse engineering the program. This part of it isn't my priority though.
Reverse Engineered Source Code
I've manually de-compiled about 10% of initc so far. It sure would be nice if KNC just released this code
This will have to suffice in the meantime. I'm hoping initc manipulates the PLL configuration data, so we can gain more insight into its format. At the very least, it'll be nice to know what this program is doing as a whole.My EEPROM Dumps
Code:
root@Jupiter-6AB:~# cat /sys/bus/i2c/devices/3-0050/eeprom | hexdump -C
00000000 75 22 4a 27 1b d8 26 f5 fc c5 0c 5c 28 23 28 63 |u"J'..&....\(#(c|
00000010 4d 6c 01 9f 00 55 a2 4c 79 d9 73 62 d3 db 51 27 |Ml...U.Ly.sb..Q'|
00000020 41 31 30 30 30 30 30 37 42 39 41 30 45 00 00 00 |A1000007B9A0E...|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000050 04 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff |................|
00000060 00 30 84 00 0d f1 84 01 c9 e7 84 02 f9 14 84 03 |.0..............|
00000070 91 65 86 00 01 d1 86 01 01 d1 86 02 01 d1 86 03 |.e..............|
00000080 01 d1 85 00 c2 cd 85 01 f5 31 85 02 eb 66 85 03 |.........1...f..|
00000090 03 01 aa 28 91 14 a0 64 12 16 f1 e5 a6 5d 1b a5 |...(...d.....]..|
000000a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
root@Jupiter-6AB:~# cat /sys/bus/i2c/devices/4-0050/eeprom | hexdump -C
00000000 5d 90 81 61 21 96 61 2f 79 aa da 0e b0 c2 97 1b |]..a!.a/y.......|
00000010 96 a4 82 86 a3 eb cb 11 68 87 a0 6c a1 c6 ab d6 |........h..l....|
00000020 41 31 30 30 30 30 30 38 30 30 31 36 33 00 00 00 |A100000800163...|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000050 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff |................|
00000060 00 30 84 00 94 50 84 01 82 5c 84 02 29 a8 84 03 |.0...P...\..)...|
00000070 ab 7b 86 00 01 d1 86 01 01 d1 86 02 01 d1 86 03 |.{..............|
00000080 01 d1 85 00 e6 d0 85 01 57 f8 85 02 60 5b 85 03 |........W...`[..|
00000090 b0 48 a7 af 63 41 fd 14 5e 7c f5 95 66 47 59 d0 |.H..cA..^|..fGY.|
000000a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
root@Jupiter-6AB:~# cat /sys/bus/i2c/devices/5-0050/eeprom | hexdump -C
00000000 5b 59 fc 0f 94 ab a3 d7 d8 7c 91 6b a5 29 d6 51 |[Y.......|.k.).Q|
00000010 4a 0f d6 6b e6 35 5e a5 a4 59 04 5f f1 26 1e 19 |J..k.5^..Y._.&..|
00000020 41 31 30 30 30 30 30 37 42 42 45 43 46 00 00 00 |A1000007BBECF...|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 |................|
00000050 08 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff |................|
00000060 00 30 84 00 56 87 84 01 74 fa 84 02 c0 34 84 03 |.0..V...t....4..|
00000070 8f 7a 86 00 01 d1 86 01 01 d1 86 02 01 d1 86 03 |.z..............|
00000080 01 d1 85 00 db 11 85 01 b7 d7 85 02 3c ce 85 03 |............<...|
00000090 3d 1c e7 e3 75 f7 fe 65 21 ea 89 91 25 3a e7 ed |=...u..e!...%:..|
000000a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
root@Jupiter-6AB:~# cat /sys/bus/i2c/devices/6-0050/eeprom | hexdump -C
00000000 7d 1c cb 21 6e a1 4a ad 65 29 bf af 12 de a3 cd |}..!n.J.e)......|
00000010 76 93 dc e7 0f 8c 28 33 5f 49 b2 86 81 b4 19 d4 |v.....(3_I......|
00000020 41 31 30 30 30 30 30 37 42 41 35 38 41 00 00 00 |A1000007BA58A...|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 04 10 00 |................|
00000050 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff |................|
00000060 00 30 84 00 f3 49 84 01 cb 1e 84 02 d9 dc 84 03 |.0...I..........|
00000070 b1 58 86 00 01 d1 86 01 01 d1 86 02 01 d1 86 03 |.X..............|
00000080 01 d1 85 00 cd 76 85 01 bd b6 85 02 fc f6 85 03 |.....v..........|
00000090 e9 05 cb d2 3f 91 df 4e ac 30 d4 32 25 65 26 e7 |....?..N.0.2%e&.|
000000a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
If anyone wants to dump theirs as well, I would be interested in comparing the PLL configuration data.
There's also EEPROMs at 0-0050 and 1-0054. One of those is an EEPROM on the Beagle board, I believe, and just contains the Beagle's serial number. The other one I believe is on the IO board.
Jump to: