Have spent quite a bit of time with mine, I've gone through the whole unit software / hardware wise and made quite a few hardware notes that ill curate and share at a later date.
Voltage control is whack on these, needs custom firmware. Over the past few days of testing i was getting the following.
600mhz, 80C, 10K+ HW errors
581mhz, 55C, 5 HW errors
575mhz, 70C, 7K+ HW errors
How reducing clock speed results in more heat + HW errors is beyond me unless there are serious voltage calculation issues with these things. Also the CPU on the control board is running near full tilt just to keep up with the UART activity on the hashing boards. So even the simple act of refreshing the web page can give you HW errors. These aren't real errors, but just the control board lagging behind.
Also these are identical to the D3 in almost every way. pic firmware, eeprom images, etc... are all identical. The only thing that sets this apart from a D3 is the ASIC's, but considering it has all the same issues that the D3 had it makes me wonder if bitmain has come up with a more universal ASIC chip that can be reconfigured. There are JTAG headers on the hash boards, so who knows?
Voltage control is whack on these, needs custom firmware. Over the past few days of testing i was getting the following.
600mhz, 80C, 10K+ HW errors
581mhz, 55C, 5 HW errors
575mhz, 70C, 7K+ HW errors
How reducing clock speed results in more heat + HW errors is beyond me unless there are serious voltage calculation issues with these things. Also the CPU on the control board is running near full tilt just to keep up with the UART activity on the hashing boards. So even the simple act of refreshing the web page can give you HW errors. These aren't real errors, but just the control board lagging behind.
Also these are identical to the D3 in almost every way. pic firmware, eeprom images, etc... are all identical. The only thing that sets this apart from a D3 is the ASIC's, but considering it has all the same issues that the D3 had it makes me wonder if bitmain has come up with a more universal ASIC chip that can be reconfigured. There are JTAG headers on the hash boards, so who knows?
No, they just use fairly universal controllers and control software, with minimal changes to suit the different algorithm.
I suspect their software for the D3 L3 and A3 all derived from some generation of their S9 software, and goes back at least as far as the S5 in the chain or direct ancestery.
Their hardware configuration seems to have been set by the S5+/S7 for all their recent miners, VERY minimal changes.
I don't see any reason why UNDERclocking would void the warranty.
Usually the eeprom's are different, L3/S9/D3 all have different eeprom content. Except the A3 and D3 share the same eeprom content. These eeproms are on the i2c bus and each hash board has one. No clue what the data is actually used for, but considering every miner has been different to this point except the D3/A3 suggest's they are more similar than bitmain would like us to believe.
Also, i traced out that header on the A3 board which all seems to connect to the PIC16F1704 chip.
1 = 14 = VSS
2 = 12 = RA1/ISCPCLK
3 = 13 = RA0/ISCPDAT
4 = 14 = VSS
5 = 1 = VDD
6 = 4 = Vpp/MCLRT/RA3
That basically makes it an ICSP header, which might be able to gather some useful information on the programming. Clearly it isn't locked as cgminer is able to flash this chip on startup if needed. Based on the code it looks like the PIC has a small boot loader program which initializes things, then waits to hear from the controller. Whether the controller actually has an ICSP connection to the PIC itself, or if the small loader program has the ability to read data over i2c for programming i don't know.
/bin/pic.txt has the pic microcode in it, but it may not contain that initial loader program.
What are your thoughts on that?
