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 Roll Eyes 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.
Full Text under : https://bitcointalk.org/index.php?topic=313978.0
