So, I’ve got a lot of feedback on nueOverClockTest, which is actually more mixed than I expected. Here’s a brief summary of the results:
1) Both GSM and CDMA users are capable, to some degree, of running their device at 768MHz.
2) Some users cannot run at the higher speed at all, while others can run on AC and Battery just fine.
3) Stability varies heavily from user to user. Some people report that their device crashes after 1 minute, others claim they can run at 768MHz all day (and run intensive apps such as CorePlayer).
So what does this all mean? Let’s break down exactly what we’re doing here. The MSM7xxx series, as much as we love or hate it is a pretty complicated in terms of clocks, as it needs to maintain accurate, low jitter clocks for cell radio, USB, TV out, I2C, the two processors, memory, etc – all on one chip. The MSM comes with several clock sources:
Sleep Crystal: 32.576 kHz, used for sleep circuit when TCXO is disabled
TCXO (Temperature Controlled Crystal Oscillator): A very accurate 19.2MHz signal that is required for radio communications (Apparently, dividing this by about 16 gives you ~ the 1.25 MHz baseband channel frequency for CDMA).
USB Crystal: a 48MHz crystal used to meet USB standards for jitter.
Now, thats not actually very many frequencies to work with, so how do we generate the 528MHz required for the A11 at regular (stock) operating speed? The MSM7500 comes with four PLLs to generate these:
PLL0: a FPLL (Frequency and Phase Locked Loop), this generates the frequency used for the Modem (ARM9), which if I’m correct, is 294 MHz.
PLL1: a DPLL (Digital Phase Locked Loop), this is the “global PLL”. A lot of frequencies are generated from this PLL by division, and it runs at 768MHz.
PLL2: a DPLL, “Backup PLL 0”, which is used for the MSM7xxA processors when they are at 528MHz. It appears to run at 1.056 GHz.
PLL3: a DPLL, “Backup PLL 1”, which appears to be unused.
All these PLLs source their signals from the 19.2MHz TCXO, probably because its nicely accurate and temperature compensated.
So what does nueOverClockTest do? It simply sets the primary clock for the applications arm (ARM11) to PLL1 / 1, instead of the default PLL2 / 2. (And no, there are no non-integer dividers, probably because it would result in really bad jitter) Now why would this work on some devices but not others? Let’s explore several theories:
Die Quality: It might just be that the dies of some processors are higher quality than other processors, making them capable of running at higher frequencies than others, much as in your traditional CPU. After all, we are running the ARM11 at 45% higher than it’s rated speed, so quality control only rejected dies that could not run at 528 MHz.
AHB/AHI/AXI bus stability: Some people may have noted that running applications such as Manila may cause crashes. This is because the graphics core runs at a different frequency than the ARM11 core, so a sudden drastic change in frequency might not make the intercommunications bus very happy and cause the device to crash.
Radio Version: As much as it seems to not be related, contrary to common belief, the Radio actually controls a lot of the setup and initial configuration of the device, including controlling voltage levels and PLL settings. This might explain why some radios seem to work better than others (different AMSS versions).
Insufficient Voltage: Perhaps the voltage regulators are a little inaccurate, and the devices that are working are pushing a higher voltage than the devices that aren’t working.
So what have I done to approach the problem?
1) I’ve tried to see if I can adjust the output value of PLL2. It appears that a clock control register under the control of the ARM9, DCPLL1_L_VAL_REG, controls what the output frequency of PLL2 is. It appears to be a multiple the TCXO 19.2MHz clock – the default value is 0x7, and when I set it to 0x1, the device operates as if it is running at 19.2MHz. 0x2 – 0x6 causes crashes. Another option here is to try using PLL3, which is unused, to generate a custom frequency.
2) I’ve tried to adjust voltage regulators. The device has eight (0-7) power levels, which are set by the ARM9. There is a configuration register, VDD_APC_PLEVEL*, which controls the actual output of each level, which in turn is set by the PMIC. The ARM11 can request one of the levels, and the ARM9 in turn requests a level from the PMIC. I’ve tried increasing the voltage defined in this register, but it seems to not help at all with stability.
3) There is a clock divider for the AHB that is separate from the ARM11 frequency. I’ve tried increasing the divider from the default of 0x4 to 0x5, with no real increase in stability.
So that’s what I’ve done so far – and hopefully that gives you a better picture of the task at hand =). I’m working hard on trying to lower the frequency a bit so its stable for more people, and to make it work for everyone, be patient!