It was viable but took a few hours. I think it's time to either get a new offline laptop or get one of those easier to use HW wallets.

What magic is it that you are using that prevents old CPUs from working? My old offline AMD C60 (64-bit) does not work either.
Building from source on an old machine like that is not really viable, it will take days.

There must be an option to ./configure to disable your magic so that we can build on a more modern machine.
Any ideas?

AX1200 works fine, I run 3 cubes from one of those. I really hope the AX1200i works as well since i have ordered a bunch of them.

I made a new modifications to cgminer.sh to make the clock configuration easier to adapt and save between reboots.

The modification will read the clock settings from the file /config/clocks.conf and apply them when cg/bfgminer is started.
The syntax of the config file should be self explanatory.

Add in the beginning (where the other similar lines are) to cgminer.sh :

CLOCKS=/config/clocks.conf


And a bit further down:

        if [ -n "$good_ports" ] ; then
                if [ -f $CLOCKS ] ; then
                    clocks=$(cat $CLOCKS)
                else
                    clocks="0x02,0x01 0x02,0x01 0x02,0x01 0x02,0x01 0x02,0x01 0x02,0x01 0x02,0x01 0x02,0x01 0x02,0x01 0x02,0x01 0x02,0x01 0x02,0x01 0x02,0x01 0x02,0x01 0x02,0x01 0x02,0x01 "
                fi

                di=0
                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
                                cl=$(echo $clocks $di | awk '{split($0,a," "); print a[a[NF]+1]}')
                                cmd=$(printf "0x86,0x%02X,%s" $c $cl)
                                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
                                di=$((di+1))
                        done

                        # re-enable all cores
                        i=0
                        while [[ $i -lt 192 ]] ; do
                                i2cset -y 2 0x2$p $i 1
                                i=$((i+1))
                        done
                        spi_ena=$(( spi_ena | (1 << $p) ))
                done
        fi



Example /config/clocks.conf:

0x02,0x71 0x02,0x71 0x02,0x71 0x02,0x71
0x02,0x71 0x02,0x51 0x02,0x71 0x02,0x51
0x02,0x51 0x02,0x51 0x02,0x51 0x02,0x51
0x02,0x51 0x02,0x51 0x02,0x51 0x02,0x51

Spaces are very important in this file. Do not add a space after "0x02,".

I hope its useful

Too bad I do not have access to a proper electronics lab
Most of your ideas could be easily tested with a scope and some other basic tools.

But I have made some other observations that might be interesting:

Iout and Vout from the two VRMs in the pairs are not even.

Typical values (as reported by the VRMs):
table]

VRM Nr	V	A
0	0.8154	24.8750
1	0.7998	27.6250
2	0.8066	30.3125
3	0.8164	26.8125
4	0.8184	30.5000
5	0.8096	30.0000
6	0.8235	27.6250
7	0.8164	31.8750

0,3 and 6 have slightly higher voltage that the other VRM in each pair. The pair 4,5 is pretty even.
Current is a bit higher on the VRMs with lower voltage. It looks the same on many different boards.
You would expect voltage and current to be the same on both VRMs in a pair. Odd.

The buzzing gets louder the more power you use. You can clearly hear when a block is found
I haven't had time yet to open a box and check what VRMs are buzzing.

Since you have ordered the parts you must know the value of then RTUNE and RTrim resistors for the VRMs?

Yes you can

Edit feb 25: Change initial adjustment to -0.0806. Higher voltage cause massive buzzing from the VRMs

I will start with a warning. It is unknown if this is safe. KnC may have turned off the VRMs due to that there is a problem with the design.
You board might burn! On the other hand they ran with all VRMs turned on for a few weeks when they were new without any major issues.
I have run a few machines with 8VRMs for almost 2 weeks without problems. Some machines will start buzzing pretty loud, I have no idea why.

Suggested procedure to enable all 8 VRMs:

1. Change all voltage adjustment to -0.0806.
When all VRMs are turned on the adjustment will be from a base of ~0.9V,
-0.0806 will give a voltage of ~0.82V which works fine for most chips at 1Ghz.
With -0.0806V and 1Ghz the machine will pull over 800W from the PSU (~190W reported per board).

2. Stop cgminer/bfgminer
Run on a shell:
/etc/init.d/cgminer.sh stop

3. Run the enable.sh script. (see below)
The script will take the voltage adjustments of the "official" 4 VRMs on each board and make sure that both VRMs for each die will have the same adjustment. It also turns on all VRMs.

4. reboot. Do not power cycle.
The VRMs have a tendency to get upset when they are turned on the first time and set error flags and in some cases not start properly. A reboot cleans things up.

5. Verify on the advanced settings page that the current on each pair of VRMs is in the same ballpark. The pairs are 0+1, 2+3, 4+5 and 6+7.

6. Overclock as usual

Each time you apply a voltage adjustment in the advanced page you have to run enable.sh again to make sure the pairs have the same adjustment.
This is VERY important!.


The script is safe to run on a machine with mixed 4 and 8 VRM boards. You may get some error message when the script tries to tank to the missing VRMs.

If you powercycle the machine I am pretty sure all changes are gone. I haven't powercyled my machines since October when there was a storm and we lost power for a few minutes.


The script (enable.sh):


#!/bin/sh

# Fetches the TRIM settings of the official 4 VRMs and sets the
# same value into each paired VRM.
for b in 3 4 5 6 7 8 ; do
    v0=`i2cget -y $b 0x10 0x22 w 2>/dev/null`
    if [ "$v0" != "" ] ; then
        i2cset -y $b 0x11 0x22 $v0 w 2>/dev/null
    fi

    v1=`i2cget -y $b 0x12 0x22 w 2>/dev/null`
    if [ "$v1" != "" ] ; then
        i2cset -y $b 0x13 0x22 $v1 w 2>/dev/null
    fi

    v2=`i2cget -y $b 0x14 0x22 w 2>/dev/null`
    if [ "$v2" != "" ] ; then
        i2cset -y $b 0x15 0x22 $v2 w 2>/dev/null
    fi

    v3=`i2cget -y $b 0x17 0x22 w 2>/dev/null`
    if [ "$v3" != "" ] ; then
        i2cset -y $b 0x16 0x22 $v3 w 2>/dev/null
    fi
done

# Turn On all VRMs using "on" in OPERATION
for b in 3 4 5 6 7 8 ; do
        for d in 0 1 2 3 4 5 6 7 ; do
                i2cset -y $b 0x1$d 1 0x80 >/dev/null 2>&1
        done
done


What the script does is that it reads the voltage adjustment register (VOUT_TRIM, address 0x22) from the official VRMs (0x10, 0x12, 0x14 and 0x17) and writes the same value to the other VRM in each pair. And then it sets the "On" bit (0x80) in the OPERATION register, address 1.

A warning:

For you brave souls that have enabled all 8 VRMS (early Octobers) I saw today that the 1.0.0 firmware does not apply the voltage adjustment to all 8 VRMs. It only applies it to the 4 that are officially enabled. The old FW applied this adjustment to all VRMs.

The VRMs work in pairs and if the voltage adjustment (VOUT_TRIM register) of the 2 VRMs in a pair is different things will go bad.

If you still want to use all 8 VRMs I suggest you read and understand the datasheet of the VRM.
The VRMs are very resilient to abuse, but they have limits.


Other than that FW 1.0.0 works very good. HW errors have dropped a lot for me. Good chips are close to 0% errors (2% before), bad chips still close to 2%.

I have inspected what the November firmware has actually changed.

What I can see it has changed a value in one of the registers in the VRMs. It has set the "ON" bit in the OPERATIONS register,changing what conditions are needed to turn the VRMs on.
This change will be permanent even if rebooted or power-cycled. It can be changed using i2c commands:


Turn all VRMs on:

#!/bin/sh
# Stop SPI poller
i2cset -y 2 0x71 2 0

for b in 3 4 5 6 7 8 ; do
        for d in 0 1 2 3 4 5 6 7 ; do
                i2cset -y $b 0x1$d 1 0x80 >/dev/null 2>&1
        done
done


Restore to factory settings:

#!/bin/sh
# Stop SPI poller
i2cset -y 2 0x71 2 0

for b in 3 4 5 6 7 8 ; do
        for d in 0 1 2 3 4 5 6 7 ; do
                i2cset -y $b 0x1$d 1 0x0 >/dev/null 2>&1
        done
done


I suggest stopping cgminer before doing this to limit the power when the operation is done.

Reading the datasheet for the VRMs I can see that when using them in pairs (as we do when all are turned on) there are some requirements on how they should be turned on. This method does not do that!

I have heard that hizzing sound as well. Some boards do that. They did that on 0.90 firmware too. No idea why.

I do not know if this is safe or not, it might be unsafe and burn your boards.

The accident that turned on the VRMs was that I loaded a November FW (0.99.2-E) onto an October Jupiter (bad idea). The machine did not hash with the November firmware, I realized my mistake and put back the proper October firmware. Once it started working again I saw that all 8 VRMs were running.

A pure accident.

My guess is that the November firmware has configured the GE VRMs as if they were the Ericsson units that are in the Novembers. Both VRMs talk the same SMBus protocol and are somewhat compatible. For some reason once they are turned on the October firmware do not turn them off again.

The whole process does not feel very safe.


I am using a 0x0271 setting.

Machine is totally stock, I haven't even opened the box.


When these machines were delivered they ran with all 8VRMs turned on at 0.9V. They ran like that for a couple of weeks when they were new with no major problems. It was not until FW 0.93 (or was it 0.95?) they disabled half of the VRMs.

A speculation to why they turned off 4 of the VRMs is that they ran out of components and had to manufacture boards with only 4 VRMs, and to make things "fair" for different customers they decided to run all boards with just 4 VRMs. They gimped the 8 VRM boards.
Another option is that it is unsafe to run with 8 VRMs. That there is something wrong with the boards.

1GHz baby!

I accidentally managed to turn on all 8 VRMs on my old 8VRM Jupiter.
Since they were all on and we can control the voltage with the tuning firmware I decided to try some more overclocking.

When running these with all VRMs on they have a base voltage of about 0.9V, so it had to be lowered in the advanced tuning page to get a reasonable voltage. -0.5V works fine.

Currents and temperatures are reasonable.

Total power consumption on the inside of the VRMs is 850W. I guess that will be 950-1000W at the wall. Since my PSU is only 1050W I do not dare to go higher.

The November units will be crazy once you get the tuning FW!

All 8 VRMs are not needed.

KnC shipped the first 4 VRM boards without knowing that they used 0.9V and over 50A.

Shipping the boards like this was an obvious mistake by KnC. Their production testing was not good enough to catch this. A bit of a noob mistake IMO. Measure the currents! Too high is bad, too low is bad!

But thanks to the overkill, expensive, components they have on the boards it could be fixed in the firmware.
This margin was a major part of the design to counter unpredictable problem like this, the problem has been solved.

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.

Been lurking for over a year. Suddenly realized I can't post!