5,594,438 Members 33,879 Now Online
XDA Developers Android and Mobile Development Forum

[DEVS/KERNEL] Galaxy Nexus 1.4GHz overclock + Undervolting patches

Tip us?
 
coolbho3000
Old
(Last edited by coolbho3000; 8th December 2011 at 05:17 AM.)
#1  
Senior Recognized Developer - OP
Thanks Meter 748
Posts: 886
Join Date: Dec 2008
Angry [DEVS/KERNEL] Galaxy Nexus 1.4GHz overclock + Undervolting patches

This is a *clean* kernel based on the latest sources in AOSP (with the volume down interference fix), but also adds an undervolting interface and a 1.4GHz speed step, and brings the GPU to 384MHz instead of 307MHz. It also uses paulobrien's ramdisk for unsecure adb.

As with everything, use at your own risk! Overclocking/overvolting can be dangerous for your phone.

UV control + 1.4GHz GPU 384MHz. I encourage you to test this out before flashing.
UV control only - use this if you get stuttering issues at 1.4GHz GPU 384MHz
Or, if you prefer a tweaked kernel with more features, both Francisco and Paul have implemented the UV patch in their kernels. Feel free to post feed back about the UV in this thread, though.

To test: fastboot boot gnex_oc_uv.img
To flash: fastboot flash boot gnex_oc_uv.img

The undervolting interface works exactly as it does in the Nexus S CM kernel. Read the current voltages from /sys/devices/system/cpu/cpu0/cpufreq/UV_mV_table and write voltages to the same file space-delimited in mV (millivolts). SetCPU undervolting and probably some other undervolting apps support this interface.

Some users have experienced slowness with the new 1.4GHz speed. If you do, please post a dmesg and your exact symptoms (how slow? benchmark speeds, etc). Thanks to franciscofranco for implementing the overclock in his kernel and having users test. The undervolting patch alone should be 100% stable.

Here is a diff of the 1.4GHz patch and undervolting patch applied to the base kernel.

Available on my github too: http://github.com/coolbho3k

Quick video demo/screenshots:




I'm working on getting this phone to faster speeds than 1.4GHz, but it's not as easy as "just remove the underclock because OMAP4460 *should* be 1.5GHz."

A note about the undervolt patch: It's the only change to omap2plus_cpufreq.c in the above diff (you can see it as a single commit (with a typo :P) in the Galaxy Nexus kernel repo on my github). This patch is fairly clean in that it is implemented purely in the omap4 cpufreq driver and supports an arbitrary number of frequencies. It should also work with any recent OMAP4 kernel, not just the Galaxy Nexus. If there are any other devices that use the OMAP4 and have an unlocked bootloader, I welcome developers to try it out!
Galaxy Nexus (GSM)
Control your Android phone's CPU! SetCPU for Root Users
Follow me on Twitter!

Like my work? Buy SetCPU on the market or buy me some [insert drink here].
The Following 25 Users Say Thank You to coolbho3000 For This Useful Post: [ Click to Expand ]
 
noobdeagle
Old
#2  
noobdeagle's Avatar
Senior Member
Thanks Meter 84
Posts: 660
Join Date: Apr 2010
Location: Adelaide, SA

 
DONATE TO ME
why is it so difficult to hit that 1.5 mark ? kinda curious :P
 
bigxie
Old
#3  
bigxie's Avatar
Senior Member
Thanks Meter 5431
Posts: 1,228
Join Date: Nov 2010
Location: Shenzhen

 
DONATE TO ME
So, unfortunately, I'm one of those that experiences the stutters at 1.4GHz.

Symptom is pretty simple, it's super slow, with tiny bursts of regular speed. In fact, it took me almost 20 minutes to boot the kernel (I did wipe caches before flashing it). The boot animation would creep slowly, and have a couple short bursts of regular speed, then back to a crawl. Same thing as the apps were being optimized, the progress circle would spin slowly then quickly, etc.

All that's in dmesg are dpll_mpu_ck fails. Here's what I grabbed:

http://pastie.org/2979080

 
coolbho3000
Old
(Last edited by coolbho3000; 7th December 2011 at 07:21 AM.)
#4  
Senior Recognized Developer - OP
Thanks Meter 748
Posts: 886
Join Date: Dec 2008
Quote:
Originally Posted by noobdeagle View Post
why is it so difficult to hit that 1.5 mark ? kinda curious :P
It's the exact problem bigxie is having, except I get it at 1.5.

bigxie: thanks for the dmesg, that answers a lot.

I *have* gotten the phone to boot at faster speeds, which should also remedy the problem illustrated above. But it is not consistently stable. It's really weird. It's an issue with something called Duty Cycle Correction, which seems to be unstable on my device, but is required for higher frequencies. DCC seems to be required at lower frequencies for some than others. I wish we could get someone from TI over here

EDIT: posted the test kernel that I used to achieve the above 1.6GHz result. Flash at your own risk!
Galaxy Nexus (GSM)
Control your Android phone's CPU! SetCPU for Root Users
Follow me on Twitter!

Like my work? Buy SetCPU on the market or buy me some [insert drink here].
 
vivanshah
Old
#5  
Senior Member
Thanks Meter 21
Posts: 128
Join Date: Dec 2009
if we eventually set "apply on boot" for voltage and it ends up being unstable, we should still be able to get into fastboot and simply reflash the boot.img, correct?
 
bigxie
Old
#6  
bigxie's Avatar
Senior Member
Thanks Meter 5431
Posts: 1,228
Join Date: Nov 2010
Location: Shenzhen

 
DONATE TO ME
Quote:
Originally Posted by coolbho3000 View Post
I *have* gotten the phone to boot at faster speeds, which should also remedy the problem illustrated above. But it is not consistently stable. It's really weird. It's an issue with something called Duty Cycle Correction, which seems to be unstable on my device, but is required for higher frequencies. DCC seems to be required at lower frequencies for some than others. I wish we could get someone from TI over here

EDIT: posted the test kernel that I used to achieve the above 1.6GHz result. Flash at your own risk!
Heh, maybe for you.

I get a nice Google logo when I booted the 1.6GHz :)

I think I got the short end of the stick when it comes to chips. I noticed with francisco's kernel that I was getting some screen artifacts too, most likely from running the GPU at 384MHz?

Ahh, oh well, I'm so much more interested in UV than OC anyways. Any chance you could post a non overclocked kernel with UV?

 
coolbho3000
Old
#7  
Senior Recognized Developer - OP
Thanks Meter 748
Posts: 886
Join Date: Dec 2008
Quote:
Originally Posted by vivanshah View Post
if we eventually set "apply on boot" for voltage and it ends up being unstable, we should still be able to get into fastboot and simply reflash the boot.img, correct?
Yes. Just do an adb reboot bootloader during the boot animation. Or, to be extra safe, use fastboot boot instead of fastboot flash until you find stable voltages.

Or, if you want, press "menu" in SetCPU's main tab and extract the safe mode zip to the internal memory. If things go haywire, boot into recovery and flash the zip and the boot voltages will be ignored.
Galaxy Nexus (GSM)
Control your Android phone's CPU! SetCPU for Root Users
Follow me on Twitter!

Like my work? Buy SetCPU on the market or buy me some [insert drink here].
 
Chirality
Old
#8  
Senior Member
Thanks Meter 129
Posts: 649
Join Date: Sep 2008
Location: Cambridge, MA
Are you sure DCC is necessary for 1.5GHz? As you probably already know, the TI manual says DCC should be used for 1GHz and greater. But in the stock kernel code for the GN, DCC is bypassed even for 1.5GHz. I dug through the commit logs to find where they changed this:

Code:
commit eac0b0094edb42732c4ab095357d8ca9679e94bc
Author: Nishanth Menon <nm@ti.com>
Date:   Tue Sep 20 15:45:29 2011 -0500

    OMAP4460: DPLL: use DCC bypass until 1.5GHz

    DCC is to be bypassed untill 1.5GHz now that samples are trimmed
    for DPLL operation upto 3GHz.

    Change-Id: I55b7b52656e1630460d84876b994fce561d17b40
    Signed-off-by: Nishanth Menon <nm@ti.com>


commit 0e8f213258af4127f7299ed897aeafc20040c7ee
Author: Colin Cross <ccross@android.com>
Date:   Tue Sep 6 12:38:25 2011 -0700

    ARM: omap4: dpll44xx: Don't use DCC at 1.2GHz

    Transitioning from DCC on to DCC off seems to cause rare lockups.
    Disable DCC for 1.2 GHz, where it is not strictly necessary.
    To lock the DPLL @ 2.4 GHz DPLL trim-override needs to be used.

    Based on patch by Vishwanath BS <vishwanath.bs@ti.com>.

    Change-Id: I6979f2e5e0d8368c99a466215e6a1153510a6516
    Signed-off-by: Colin Cross <ccross@android.com>
It sounds like DCC isn't necessary even for 1.5GHz? If it's not possible to hit 1.5GHz on the GN, it's probably due to binning. Seems like the PRM module may also be binned, those certified to run 3GHz DPLL without DCC are used for 1.5GHz binned chips, while the chips binned for 1.2GHz don't have the good PRM modules. DCC for the MPU clock is probably not usable, since even TI couldn't get it to work without lockups.
The Following User Says Thank You to Chirality For This Useful Post: [ Click to Expand ]
 
coolbho3000
Old
(Last edited by coolbho3000; 7th December 2011 at 07:55 AM.)
#9  
Senior Recognized Developer - OP
Thanks Meter 748
Posts: 886
Join Date: Dec 2008
Quote:
Originally Posted by bigxie View Post
Heh, maybe for you.

I get a nice Google logo when I booted the 1.6GHz :)

I think I got the short end of the stick when it comes to chips. I noticed with francisco's kernel that I was getting some screen artifacts too, most likely from running the GPU at 384MHz?

Ahh, oh well, I'm so much more interested in UV than OC anyways. Any chance you could post a non overclocked kernel with UV?
Posted. As for 384MHz GPU, that's what the GPU is supposed to be at - Google reduced the GPU speed in the final build to save on a bit of battery, but in my experience some UV balances that out nicely.


Quote:
Originally Posted by Chirality View Post
Are you sure DCC is necessary for 1.5GHz? As you probably already know, the TI manual says DCC should be used for 1GHz and greater. But in the stock kernel code for the GN, DCC is bypassed even for 1.5GHz. I dug through the commit logs to find where they changed this:

It sounds like DCC isn't necessary even for 1.5GHz? If it's not possible to hit 1.5GHz on the GN, it's probably due to binning. Seems like the PRM module may also be binned, those certified to run 3GHz DPLL without DCC are used for 1.5GHz binned chips, while the chips binned for 1.2GHz don't have the good PRM modules. DCC for the MPU clock is probably not usable, since even TI couldn't get it to work without lockups.
I can't lock to 1.5GHz with DCC off (see bigxie's 1.4GHz dmesg - the same thing happens), but I can with DCC on (changing the value of OMAP_1_5GHz in dpll44xx.c changes the threshold at which DCC is turned on). Sometimes I can get past the Google logo with DCC on, and I can be perfectly stable within Android, sometimes (with the same binary that I made when it was stable), I can't. The above 1.6GHz kernel I posted does have DCC enabled for 1.6GHz, and at the moment, I can boot into Android. Why this happens totally beyond me right now.

Maybe some of the PRMs in GN units are binned for 1.2GHz and others for 1.5GHz. That would not, however, explain my chip, which works at 1.4GHz but not 1.5GHz (DCC off).

Where did you find that info? The 4460 documentation (for an earlier SoC revision) does say DCC needs to be turned on for over 1GHz. I can't find a technical reference manual for the revision used in the Galaxy Nexus. It would be a shame if we could not get DCC/M3 output to work ever, since we would be essentially stuck at 1.2GHz then.

Also, to pour more knowledge into this, I did look at the omap4_trim_quirks.c and tried to trim the DPLL for operation above 1.2GHz by writing to those registers directly. It seems like on my chip those registers were set up for DPLL operation up to 1.5GHz, so I increased this even more. This did not work.

Code:
Transitioning from DCC on to DCC off seems to cause rare lockups.
I did dig extensively through the commit logs, but actually did not see this particular sentence before. That's a shame - I hope we'll be able to solve that problem.

Also of note is Colin Cross's commit disabling 1.5GHz, in which he states the "tuna board is not compatible with 1.5GHz" but does not elaborate further. That's puzzling as well.
Galaxy Nexus (GSM)
Control your Android phone's CPU! SetCPU for Root Users
Follow me on Twitter!

Like my work? Buy SetCPU on the market or buy me some [insert drink here].
The Following User Says Thank You to coolbho3000 For This Useful Post: [ Click to Expand ]
 
Chirality
Old
(Last edited by Chirality; 7th December 2011 at 07:58 AM.)
#10  
Senior Member
Thanks Meter 129
Posts: 649
Join Date: Sep 2008
Location: Cambridge, MA
Quote:
Originally Posted by coolbho3000 View Post
I can't lock to 1.5GHz with DCC off (see bigxie's 1.4GHz dmesg - the same thing happens), but I can with DCC on (changing the value of OMAP_1_5GHz in dpll44xx.c changes the threshold at which DCC is turned on). Sometimes I can get past the Google logo with DCC on, and I can be perfectly stable within Android, sometimes (with the same binary that I made when it was stable), I can't.
Sounds like you are hitting the bug that caused Google/TI to turn off DCC for 1.2GHz in the first place. It seems like getting the device to be stable with DCC would be pretty difficult, and the chip in the GN is not binned for letting the DPLL_MPU to be able to lock at 3GHz, which means it'll be very difficult to impossible to get 1.5GHz to work...

According to omap4_trim_quirks.c, it seems the chip used in the GN is a so-called "PRE_RTP" device, which is not trimmed. So it's using a software trim override to enable the DPLL_MPU to lock at 2.4GHz, and presumably beyond. It sounds like the problem with hitting frequencies higher than 1.2GHz is not due to software trim locks (since this is overridden to allow the DPLL_MPU to lock at any frequency) but rather due to limitations of the silicon itself. This would explain why, with DCC off, some people can hit 1.4GHz while others can not: the PRM is not binned for 3GHz operation, so between 2.4GHz and 3GHz, we'll have some chips running ok and others not being able to lock the DPLL.

The Following 2 Users Say Thank You to Chirality For This Useful Post: [ Click to Expand ]
THREAD CLOSED
Subscribe
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes