Related
So I've been traipsing through some of the other Qualcomm repositories searching for tidbits that might be of use for N1 kernels. As far as I can tell, none of these changes have been merged in to the aosp or cyanogen kernels, although unfortunately the underlying kernels have diverged and these won't apply cleanly but it should be possible to manually merge with some effort.
First up, this patch reduces AXI (internal bus) speed when the apps CPU is running at lower clock speeds and increases it when at higher clock speeds. Memory would otherwise be the bottleneck for many applications.
https://www.codeaurora.org/gitweb/q...it;h=6caa6d84d8c687b5f66f5b5ea281183eae8947a8
Code:
msm: acpuclock-8x50: Couple CPU freq and AXI freq.
The memory throughput is directly proportional to the AXI frequency. The
AXI freq is coupled with the CPU freq to prevent the memory from being
the bottleneck when the CPU is running at one of its higher frequencies.
This will cause an increase in power consumption when the CPU is running
at higher frequencies, but will give a better performance/power ratio.
This patch adds core support for AXI clock changes.
https://www.codeaurora.org/gitweb/q...it;h=009d997b1439edf1991e181206c74ee3e943787e
Code:
msm: clock: Add SoC/board independent APIs to set/get max AXI frequency.
Some drivers need to set the AXI frequency to the maximum frequency
supported by the board. Add a MSM_AXI_MAX_FREQ_KHZ magic value that
allows them to achieve that in a SoC/board independent manner.
The following two patches drop the AXI speed when the processor is idle but the screen is on, down to the minimum that will allow the framebuffer to keep driving the screen. Claims to save ~20 mA which would be somewhere around 10-20% at least. Unfortunately these will probably be harder to merge in, as the Chromium kernel uses quite a different mdp/framebuffer architecture. Still, worth trying!
https://www.codeaurora.org/gitweb/q...it;h=fdb01a9945f2ac3a4cc76c507ed0abf5dd5cfb57
Code:
msm_fb: Reduce AXI bus frequency to 62 Mhz from 128 Mhz
Reduced AXI bus frequency to 62 Mhx to save power during idle
screen mode/limited sleep mode.
https://www.codeaurora.org/gitweb/q...it;h=dee586811e34cb24dedc1d0587f3e31f1ba656a6
Code:
msm_fb: Reduce AXI bus frequency to 58 Mhz from 64 Mhz.
Reduce AXI bus frequency further to 58 Mhz for lcdc panels to save
~20mA power during idle screen mode/limited sleep mode.
I can't wait to see what Kmobz, Intersect, and pershoot do with this!
interesting stuff...hopefully one of the many great kernel devs can use this info and find a way to get it to be useful on the N1 and save more battery life
For those interested, if you have a look at pm.c, a lot of the logic seems to be already there:
Code:
/* axi 128 screen on, 61mhz screen off */
static void axi_early_suspend(struct early_suspend *handler) {
axi_rate = 0;
clk_set_rate(axi_clk, axi_rate);
}
The only thing that is missing is the setting of the axi rates along with the cpu frequency. However, I would think that it is going to take a special amount of trial and error to get the rates correct for the nexus one, since they are, after all, different pieces of hardware.
We could try to further reduce the frequency of the AXI bus while the screen is off. AOSP currently does 61MHz, right?
coolbho3000 said:
We could try to further reduce the frequency of the AXI bus while the screen is off. AOSP currently does 61MHz, right?
Click to expand...
Click to collapse
It should be possible to go with Code Aurora's 58 I think?
Yes we could reduce it further. I dont know what impact it will have on stability yet.
I have provided a very quick (and very dirty) patch for scaling the axi rates according to cpu frequency. THIS IS NOT INTENDED TO BE USED UNLESS YOU KNOW WHAT YOU ARE DOING.
It is just a preliminary patch which compiles into a zImage. I do not know if it works (i'll leave that to the experts). Please, always (!!), check the patches and code before running the kernel image.
I tried to follow the convention already existing in acpuclock-scorpion as much as possible. One caveat: I do not know what the return value for a successful clk_set_rate is, and I am only assuming based on the code aura sources (pm.c does not use the return value).
Edit: forgot to add that I think it is a little too much for pm.c AND acpuclock-scorpion to be setting the axi value (if it works at all), and might cause stability issues. Maybe someone might try removing the pm.c code and use acpu-clock only, I dont know....
jazzor said:
Yes we could reduce it further. I dont know what impact it will have on stability yet.
I have provided a very quick (and very dirty) patch for scaling the axi rates according to cpu frequency. THIS IS NOT INTENDED TO BE USED UNLESS YOU KNOW WHAT YOU ARE DOING.
It is just a preliminary patch which compiles into a zImage. I do not know if it works (i'll leave that to the experts). Please, always (!!), check the patches and code before running the kernel image.
I tried to follow the convention already existing in acpuclock-scorpion as much as possible. One caveat: I do not know what the return value for a successful clk_set_rate is, and I am only assuming based on the code aura sources (pm.c does not use the return value).
Edit: forgot to add that I think it is a little too much for pm.c AND acpuclock-scorpion to be setting the axi value (if it works at all), and might cause stability issues. Maybe someone might try removing the pm.c code and use acpu-clock only, I dont know....
Click to expand...
Click to collapse
I've made too many changes to acpuclock to apply this directly. I'll take a look at it later though.
jazzor said:
For those interested, if you have a look at pm.c, a lot of the logic seems to be already there:
Code:
/* axi 128 screen on, 61mhz screen off */
static void axi_early_suspend(struct early_suspend *handler) {
axi_rate = 0;
clk_set_rate(axi_clk, axi_rate);
}
Click to expand...
Click to collapse
True, but the comment doesn't agree with the code itself:
Code:
/* axi 128 screen on, 61mhz screen off */
<snip>
static void axi_late_resume(struct early_suspend *handler) {
axi_rate = 128000000;
sleep_axi_rate = 120000000; // <- 120 MHz...
clk_set_rate(axi_clk, axi_rate);
}
I wonder if we could drop the sleep_axi_rate = 120000000 to something much lower?
Also, the OP patches were for dropping the AXI rate when the screen is on but the processor is idling. (And it's not clear what screen resolution the code in the OP patches was for, but if it's for ChromeOS I presume it's higher than our 800x480, so bus bandwidth for the framebuffer shouldn't be a problem). So no, unless I'm missing something most of the logic in these patches isn't there already as you claim. (If I am missing something, please show me where... I believe it would have to be in the MDP driver somewhere).
hugonz said:
True, but the comment doesn't agree with the code itself:
Code:
/* axi 128 screen on, 61mhz screen off */
<snip>
static void axi_late_resume(struct early_suspend *handler) {
axi_rate = 128000000;
sleep_axi_rate = 120000000; // <- 120 MHz...
clk_set_rate(axi_clk, axi_rate);
}
I wonder if we could drop the sleep_axi_rate = 120000000 to something much lower?
Also, the OP patches were for dropping the AXI rate when the screen is on but the processor is idling. (And it's not clear what screen resolution the code in the OP patches was for, but if it's for ChromeOS I presume it's higher than our 800x480, so bus bandwidth for the framebuffer shouldn't be a problem). So no, unless I'm missing something most of the logic in these patches isn't there already as you claim. (If I am missing something, please show me where... I believe it would have to be in the MDP driver somewhere).
Click to expand...
Click to collapse
I might be wrong, but this is how I understand it. axi_early_suspend is called when the nexus is going under suspend mode, which is like suspend to ram. This happens when there are no active tasks running and the screen is off. As the code says, the rate is set to 0 implying it is going to set it as low as the limits allow (assuming that is 61mhz). axi_late_resume is for the case when the nexus is NOT in suspend. There are still 2 states in this mode, one where the machine is being actively used (browsing web) and one where the machine is idle (such as when we are listening to music or any background task that may or may not be using the screen), but the machine cannot suspend to ram due tasks still actively running.
In any case, experimenting with lower values of axi rates should be done to see if it indeed saves battery.
oooh great thread. I will definitely be looking into this stuff when I get back in town! thanks for the links!
https://www.codeaurora.org/gitweb/q...it;h=8a68421a300878d729991c1db609a541910d2c70
Here is another patch (more up to date -> perhaps easier to merge).
I just implemented the AXI frequency tweak for N1 - I noticed it is also present in HTC Desire kernel
I am testing it now - so far it seems stable.
Attached acpuclock_scorpion.c implementing the AXI tweaks. Basically, AXI frequency now scales with CPU frequency.
Ivan Dimkovic said:
I just implemented the AXI frequency tweak for N1 - I noticed it is also present in HTC Desire kernel
I am testing it now - so far it seems stable.
Attached acpuclock_scorpion.c implementing the AXI tweaks. Basically, AXI frequency now scales with CPU frequency.
Click to expand...
Click to collapse
Do you run this along with a custom kernel and just flash in recovery like an update.zip?
I usually use Cyanogen's kernel as base for my experiments - so this should definitely compile with Cyanogen's 2.6.34 kernels. This acpuclk-scorpion.c has lowered voltages and also support for frequencies up to 1190 MHz
Although you will also need to change few call prototypes in acpuclock.h - it is quite trivial just replace old acpuclk_set_rate() and acpuclk_power_collapse() prototypes with these:
enum setrate_reason {
SETRATE_CPUFREQ = 0,
SETRATE_SWFI,
SETRATE_PC,
SETRATE_PC_IDLE,
};
int acpuclk_set_rate(unsigned long rate, enum setrate_reason reason);
unsigned long acpuclk_power_collapse(int from_idle);
Click to expand...
Click to collapse
That should do it.
Markdental said:
Do you run this along with a custom kernel and just flash in recovery like an update.zip?
Click to expand...
Click to collapse
No, this will have to compiled into the kernel, which I'm doing right now. Thank you so much for doing this Ivan!
Nice to see someone finally got this to work! I've been too lax as of late.
Getting AXI scaling to work was pretty easy - makes me wonder why is it not in the AOSP kernel for N1.
It is definitely in the HTC Desire kernel, and I am sure HTC knows what is good for the hardware they built
Ivan Dimkovic said:
Getting AXI scaling to work was pretty easy - makes me wonder why is it not in the AOSP kernel for N1.
It is definitely in the HTC Desire kernel, and I am sure HTC knows what is good for the hardware they built
Click to expand...
Click to collapse
what change to pm.c if any?
pm.c already has everything in place needed for AXI clock switching.
I removed the link as well as the kernel images. You would be better off running a kernel found in ROM manager. That being said, I would like to leave this along with a link to the Samsung S5PC110 technical document: http://dl.dropbox.com/u/13699504/S5PC110_EVT1_UM10.pdf
For those brave enough to tweak their own, I present to you the locations of things to change.
PART 1: CPU AND OTHER ARM SUBSYSTEM FREQUENCIES
First off, there are three files you will want to look at and become familiar with: s5pc110-clock.c is the code that will control the CPU frequency. s5pc11x-dvfs.c controls the throttling thresholds for switching from one mode to another. max8998_consumer.c controls voltage levels for the Maxim 8998 voltage regulator. Although it doesn't state granulatrity, I've assumed it to be 25-unit increments measured in mV.
s5pc110-clock.c:
Code:
/*APLL_FOUT, MPLL_FOUT, ARMCLK, HCLK_DSYS*/
static const u32 s5p_sysout_clk_tab_1GHZ[][4] = {
// APLL:1000,ARMCLK:1000,HCLK_MSYS:200,MPLL:667,HCLK_DSYS:166,HCLK_PSYS:133,PCLK_MSYS:100,PCLK_DSYS:83,PCLK_PSYS:66
{1066* MHZ, 667 *MHZ, 1066 *MHZ, 166 *MHZ},
// APLL:800,ARMCLK:800,HCLK_MSYS:200,MPLL:667,HCLK_DSYS:166,HCLK_PSYS:133,PCLK_MSYS:100,PCLK_DSYS:83,PCLK_PSYS:66
{800* MHZ, 667 *MHZ, 800 *MHZ, 166 *MHZ},
// APLL:800,ARMCLK:400,HCLK_MSYS:200,MPLL:667,HCLK_DSYS:166,HCLK_PSYS:133,PCLK_MSYS:100,PCLK_DSYS:83,PCLK_PSYS:66
{400* MHZ, 667 *MHZ, 400 *MHZ, 166 *MHZ},
// APLL:800,ARMCLK:200,HCLK_MSYS:200,MPLL:667,HCLK_DSYS:166,HCLK_PSYS:133,PCLK_MSYS:100,PCLK_DSYS:83,PCLK_PSYS:66
{200* MHZ, 667 *MHZ, 200 *MHZ, 166 *MHZ},
// APLL:800,ARMCLK:100,HCLK_MSYS:100,MPLL:667,HCLK_DSYS:83,HCLK_PSYS:66,PCLK_MSYS:50,PCLK_DSYS:66,PCLK_PSYS:66
{100* MHZ, 667 *MHZ, 100 *MHZ, 133 *MHZ},
};
#define DIV_TAB_MAX_FIELD 12
//yhkim hack from TR note. We got TechnicalReport-S5PC110_Android_DRAMin_DVFSlevel4.doc.
//please check it. we change last value to 7. original val is 4 in s5p_sys_clk_div0_tab_1GHZ.
/*div0 ratio table*/
/*apll, a2m, HCLK_MSYS, PCLK_MSYS, HCLK_DSYS, PCLK_DSYS, HCLK_PSYS, PCLK_PSYS, MFC_DIV, G3D_DIV, MSYS source(2D, 3D, MFC)(0->apll,1->mpll), DMC0 div*/
static const u32 s5p_sys_clk_div0_tab_1GHZ[][DIV_TAB_MAX_FIELD] = {
{0, 4, 4, 1, 3, 1, 4, 1, 3, 3, 0, 3},
{0, 3, 3, 1, 3, 1, 4, 1, 3, 3, 0, 3},
{1, 3, 1, 1, 3, 1, 4, 1, 3, 3, 0, 3},
{3, 3, 0, 1, 3, 1, 4, 1, 3, 3, 0, 3},
{7, 7, 0, 0, 7, 0, 9, 0, 3, 3, 1, 7},
};
/*pms value table*/
/*APLL(m, p, s), MPLL(m, p, s)*/
static const u32 s5p_sys_clk_mps_tab_1GHZ[][6] = {
{266, 6, 1, 667, 12, 1},
{200, 6, 1, 667, 12, 1},
{200, 6, 1, 667, 12, 1},
{200, 6, 1, 667, 12, 1},
{200, 6, 1, 667, 12, 1},
};
PART 2: VOLTAGES
The only things I've found worthy of noting about how to enter values in here are:
1) The clock speed can be anything you want it to be.
2) The voltage in frequency_match_1GHZ (same line as frequency) might not be used to set the voltage gates. It may be used only to report to /proc/cpuinfo or other monitoring systems (SetCPU).
3) The third column is either 1100 or 1000. So far, it's always 1100 when not in the lowest power configuration. At that point, it's 1000. I think this has to do with the system-wide power configuration (not the CPU/GPU), and you may be able to increase it, but I have not tried. Please be very careful with this, as CPUs are generally more robust in terms of thermal compensation than other components.
4) dvs_volt_table_1GHZ is where you set the voltages (dvs_volt_table_800MHZ for boot mode). You set them by linking DVSARM# (1-5, 1GHZ / 1-4, 800MHz boot) and DVSINT# (1/2 for 1100/1000).
Code:
/* frequency voltage matching table */
static const unsigned int frequency_match_1GHZ[][4] = {
/* frequency, Mathced VDD ARM voltage , Matched VDD INT*/
{1066000, 1175, 1100, 0}, // Mine tested stable at 1175. Your mileage may vary.
{800000, 1075, 1100, 1}, // Stable at 1075. YMMV.
{400000, 950, 1100, 2}, // Stable at 950. YMMV.
{200000, 950, 1000, 4}, // Stable at 950. YMMV.
{100000, 950, 1000, 5}, // Stable at 950. YMMV.
};
static const unsigned int frequency_match_800MHZ[][4] = {
/* frequency, Mathced VDD ARM voltage , Matched VDD INT*/
{800000, 1100, 1100, 0},
{400000, 1050, 1100, 1},
{200000, 950, 1100, 3},
{100000, 950, 1000, 4},
};
const unsigned int (*frequency_match[2])[4] = {
frequency_match_1GHZ,
frequency_match_800MHZ,
};
/* voltage table */
static const unsigned int voltage_table[16] = {
750, 800, 850, 900, 950, 1000, 1050,
1100, 1150, 1200, 1250, 1300, 1350,
1400, 1450, 1500
};
extern unsigned int S5PC11X_FREQ_TAB;
//extern const unsigned int (*frequency_match[2])[4];
static struct regulator *Reg_Arm = NULL, *Reg_Int = NULL;
static unsigned int s_arm_voltage=0, s_int_voltage=0;
unsigned long set1_gpio;
unsigned long set2_gpio;
unsigned long set3_gpio;
/*only 4 Arm voltages and 2 internal voltages possible*/
static const unsigned int dvs_volt_table_800MHZ[][3] = {
{L0, DVSARM2, DVSINT1},
{L1, DVSARM3, DVSINT1},
//266 {L2, DVSARM3, DVSINT1},
{L2, DVSARM4, DVSINT1},
{L3, DVSARM4, DVSINT2},
// {L4, DVSARM4, DVSINT2},
// {L5, DVSARM4, DVSINT2},
};
static const unsigned int dvs_volt_table_1GHZ[][3] = {
{L0, DVSARM1, DVSINT1},//DVSINT0
{L1, DVSARM2, DVSINT1},
{L2, DVSARM3, DVSINT1},
//266 {L3, DVSARM3, DVSINT1},
{L3, DVSARM4, DVSINT2},
{L4, DVSARM4, DVSINT2},
// {L5, DVSARM4, DVSINT2},
// {L6, DVSARM4, DVSINT2},
};
const unsigned int (*dvs_volt_table[2])[3] = {
dvs_volt_table_1GHZ,
dvs_volt_table_800MHZ,
};
static const unsigned int dvs_arm_voltage_set[][2] = {
{DVSARM1, 1275},
{DVSARM2, 1100},
{DVSARM3, 1050},
{DVSARM4, 950},
{DVSINT1, 1100},
{DVSINT2, 1000},
};
That about concludes what I know about this. Thank you for the discussion, and happy hacking.
Hmmm. I seem a tad scared to try this out lol
Sent from my SCH-I500 using XDA App
I'm feeling squirrely, screw it I'll try it. Flash like anything else in recovery? All the rest is just if you want to alter your kernel correct?
Voodoo isn't included in this kernel, right?
jv
johnnyv5 said:
Voodoo isn't included in this kernel, right?
jv
Click to expand...
Click to collapse
No, I don't believe so. Voodoo kernels routinely score well over 1500 in Quadrant, so this is likely just a stock Samsung kernel tweaked with some SERIOUS overclock potential.
I'm trying it. So is this at(or around) 1.6ghz? And tweakable so we can get our own OC?
Great stuff Hex
I just did a quadrant. Is the FPS cap removed? The graphics benchmarks were unbelievable.
Nice job, AgentHex. Its been interesting reading your progress on IRC and then see it released!
Yea, Not touchin this one till it's made for release, 1600 is a pretty serious speed to tinker with.
GoogleAndroid said:
I just did a quadrant. Is the FPS cap removed? The graphics benchmarks were unbelievable.
Click to expand...
Click to collapse
What did you score?
saps said:
What did you score?
Click to expand...
Click to collapse
1172 and then 1128.
GoogleAndroid said:
1172 and then 1128.
Click to expand...
Click to collapse
Is that your 3D score?
saps said:
Is that your 3D score?
Click to expand...
Click to collapse
No, overall.
OH DEAR GOD BLAZING SPEEDS.
We need to get voodoo integrated with this bad boy and we'll be rockin!
Thanks for your work!
Btw, the FPS cap is blown off. I hit 80 FPS in Quadrant
Does anyone know though, if this is the same as the Manhattan Project that was scrapped in the Vibrant forums for inaccurately blowing up the cpu/gpu scores, or is it actually working properly?
phoenx06 said:
OH DEAR GOD BLAZING SPEEDS.
We need to get voodoo integrated with this bad boy and we'll be rockin!
Thanks for your work!
Click to expand...
Click to collapse
Agreed. Lagfix, ColorFix(with all fixes), and BLN.
GoogleAndroid said:
Agreed. Lagfix, ColorFix(with all fixes), and BLN.
Click to expand...
Click to collapse
I could go without BLN. I must be the only one that doesn't want it. The kernels with it make a terrible buzzing noise while on the phone and having the button lights on all the time has to drain battery like crazy. But agreed on the others
aroy002 said:
Does anyone know though, if this is the same as the Manhattan Project that was scrapped in the Vibrant forums for inaccurately blowing up the cpu/gpu scores, or is it actually working properly?
Click to expand...
Click to collapse
No, not at all. This is just the OP doing it on his own
Flashed Faux123's Kernel acouple days ago and have a question.
Does this Application need to be running for the voltage changes to work? What about for the profiles set?
Thanks.
i don't know the answer because i haven't flashed a kernel. the quickest and best answer is to try yourself. setcpu is in the market.
I know, but it's hard to tell and I really don't want to undervolt too much more because I don't wanna see a crash, although I have yet to experience one. I have it set at
Respectively:
-100
-100
-50
-75
-300
-300
-300
Seems stable with and without SetCPU on while spamming Quadrant standard benches and I cannot tell if the voltages are working or not. Those extra volts being taken away can greatly help my battery life, but if it's not working without the program on there is literally no way to tell. I use Advanced Task Manager a lot and it takes out SetCPU all the time.
Maybe someone with more experience of the program can help me out.
why do people undervolt it? Why wouldn't Faux undervolt when he created it? I don't touch the voltages, but not sure how you test if undervolting would hurt performance.
There is a bunch of responses to undervolting in faux's kernel thread in the dev forum. But long story short u can't have more than 100 m's between jumps when setting your undervolting, or it simply wont apply it. Example.
75
75
75
75
125
200
225
Sent from my MB860 using XDA Premium App
Phalanx7621 said:
There is a bunch of responses to undervolting in faux's kernel thread in the dev forum. But long story short u can't have more than 100 m's between jumps when setting your undervolting, or it simply wont apply it. Example.
75
75
75
75
125
200
225
Sent from my MB860 using XDA Premium App
Click to expand...
Click to collapse
Really? I'll adjust my settings. Can you show me where it says that -100 jumps won't be applicable?
Probably going to adjust it to
100
100
75
75
175
275
300
edit: It's stable after around 10 Quadrant runs. I'd still like where you found that information though.
Thanks
Phoneguy589 said:
why do people undervolt it? Why wouldn't Faux undervolt when he created it? I don't touch the voltages, but not sure how you test if undervolting would hurt performance.
Click to expand...
Click to collapse
Well, I've been overclocking computers for years and something I've learned is that the lower your voltage is, the less degraded the processor will be after awhile. Such as, if you overclock the voltage too high, overtime you would need more voltage to obtain the same speed. Same thing applies when overclocking graphics cards.
Edit: Anyways, why are people dodging the main question
no you shouldnt have to keep setCPU running. i believe the app is just changing some sysfs files, so its one and done till the next time you open and change more values.
LivingChampion said:
Really? I'll adjust my settings. Can you show me where it says that -100 jumps won't be applicable?
Probably going to adjust it to
100
100
75
75
175
275
300
edit: It's stable after around 10 Quadrant runs. I'd still like where you found that information though.
Thanks
Well, I've been overclocking computers for years and something I've learned is that the lower your voltage is, the less degraded the processor will be after awhile. Such as, if you overclock the voltage too high, overtime you would need more voltage to obtain the same speed. Same thing applies when overclocking graphics cards.
Edit: Anyways, why are people dodging the main question
Click to expand...
Click to collapse
Probably going to adjust it to
100
100
75
75
175
275
300
Bro, this setting is left 770-470 = 300 or 770 - 300 = 470mv ?
So I followed Droidstyles "how to" guide on how to put ics on my phone.( http://forum.xda-developers.com/showthread.php?t=1238070 )
I love it so far but now it leaves me wanting more from my phone. Im trying to learn how to overclock my cpu.
I currently have Teamhacksung 6.1 on my phone. And in my "about phone" section my kernel version reads
3.0.8-g0d5605e-dirty
[email protected] #1
Not too sure if those are the same thing. Can i overclock my CPU with the current kernel i have or do i have to put another one on my phone?
Thanks alot for any replies!
Djp2012 said:
So I followed Droidstyles "how to" guide on how to put ics on my phone.( http://forum.xda-developers.com/showthread.php?t=1238070 )
I love it so far but now it leaves me wanting more from my phone. Im trying to learn how to overclock my cpu.
I currently have Teamhacksung 6.1 on my phone. And in my "about phone" section my kernel version reads
3.0.8-g0d5605e-dirty
[email protected] #1
Not too sure if those are the same thing. Can i overclock my CPU with the current kernel i have or do i have to put another one on my phone?
Thanks alot for any replies!
Click to expand...
Click to collapse
Flash Glitch v14 located in the Development forum.
Please Remember to use nstools for overclocking.
Sent from my SCH-I500 using XDA App
Wow thanks for the fast reply.
Do i have to uninstall any of the other kernels I have or go back to any versions?
Or can I download glitch v14 and use odin to flash it from the version im on?
Djp2012 said:
Wow thanks for the fast reply.
Do i have to uninstall any of the other kernels I have or go back to any versions?
Or can I download glitch v14 and use odin to flash it from the version im on?
Click to expand...
Click to collapse
Flash via CWM.
Hold power button
Select 'Reboot'
then select 'Reboot Recovery'
Then flash.
No Odin needed.
That's it.
You cant uninstall a kernel, it boots the phone. You can flash different kernels though. (e.g Glitch Kernel)
Be careful when overclocking. Especially with LiveOC.
If you do not know how liveOC works, please, do not use it.
Have fun
Sent from my SCH-I500 using XDA App
Wow so i got it to work just by doing what you said. I know there is benefits for overclocking as well as some consequences if i dont do it right.
Is there anywhere i could go to read up more on how liveOC works on the fascinate? Like i said, i really want that extra edge that I can get from doing so
Also I downloaded NSTOOLS to get me started
Djp2012 said:
Wow so i got it to work just by doing what you said. I know there is benefits for overclocking as well as some consequences if i dont do it right.
Is there anywhere i could go to read up more on how liveOC works on the fascinate? Like i said, i really want that extra edge that I can get from doing so
Also I downloaded NSTOOLS to get me started
Click to expand...
Click to collapse
Here's the thread (quoted it to save you time)
Tk-Glitch said:
LiveOC and Custom Voltage guide by TkGlitch
for Glitch kernel V14
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Warning!
Overclocking is dangerous and is meant only for experienced users!
1- Introduction :
The "normal" overclocking system on SGS til now was the addition of some frequency steps past the stock 1GHz step. V13 kernel was using 7 overclocked steps
to push the maximum selectable speed to 1.7GHz.
In V14, less overclocked steps are present, but you can still overclock to 1.7GHz if you want (and if your phone is able to do it), and even up to 2.25GHz as a maximum.
You will need NSTools to use LiveOC and custom Voltage features in Glitch kernel V14.
To begin with, I'll explain you some basic things you have to know.
2- Clocks :
The CPU speed is the result of a bus speed and a multiplier.
Bus speed is linked to and equal to GPU and RAM speed.
The multiplier is per step and hardcoded by the kernel developer.
It does look like that : CPU speed = bus speed x multiplier.
Here are my values in V14 :
1500 MHz = 200 x 7.5
1400 MHz = 200 x 7
1300 MHz = 200 x 6.5
1200 MHz = 200 x 6
1000 MHz = 200 x 5
800 MHz = 200 x 4
400 MHz = 200 x 2
200 MHz = 200 x 1
100 MHz = 100 x 1
LiveOC gives you the access to direct and on-the-fly bus overclocking by 1% steps (150% being the maximum available). I'll say it again : BUS overclocking !
Though, it'll overclock the bus on all the steps at the same time, for the same percentage.
We'll talk about that later.
So if I want to overclock my 1GHz step to 1.1GHz, I'll have to select 1GHz as max frequency, and push LiveOC to 110%.
My bus speed beeing overclocked by 10% will give the following :
220 x 5 (1GHz multiplier) = 1100 MHz.
If you want to go higher than 1.5GHz, it's the same :
Set 1500 MHz as maximum frequency (for example), and push LiveOC. Let's say to 110%. You will get the following :
220 x 7.5 (1.5GHz multiplier) = 1650 MHz.
Pushing it to 114% will give 1710 MHz (228MHz bus) and so on, up to 150% giving 2250 MHz running an inachievable 300MHz bus.
3- The limits :
THE MAIN LIMIT AND PHONE KILLER IS HIGH TEMPERATURE. WARM IS OK, HOT IS TOO HOT. DON'T PLAY STUPID.
Obviously, so much control over the bus speed, frozen til now to what the kernel developer set, will also give you the ability to find the limits of your chip.
The main clocking limit is generally the RAM, corrupting itself when the bus speed is too high. And since the GPU uses the RAM as well, it'll become crashy too. That's why I have decided to add some steps with a bigger multiplier, to lower the bus for a higher CPU frequency.
The bus speed limits for you will be anywhere between 240 and 270 Mhz, depending on your device potential (higher and lower exists but rare).
Average is 240 MHz.
The CPU speed limits will be anywhere between 1300 and 1800 MHz (higher and lower exists but rare as well).
Average is 1400 MHz.
With that in mind, I wouldn't go too far past 130% (giving 260MHz bus speed).
4- The sweet spot :
What you want when overclocking is to get the best balance for each part. Since the bus is linked to RAM and GPU, you obviously want it as high as possible for gaming, video playing, web browsing etc. (even more now with GPU acceleration in Android 4.0+). Though, as you know already if you've read this guide til now, all steps in V14 are using the stock 200MHz frequency.
So what to do if I want a lower CPU speed with a higher bus/GPU speed ? Simple ! Just select a lower frequency step as starting point.
Let's say we want 250 MHz bus speed, so we'll use 125% LiveOC :
Using 800MHz step, you'll get 1GHz.
Using 1GHz step, you'll get 1.250GHz.
Using 1.2GHz step, you'll get 1.500GHz.
Using 1.3GHz step, you'll get 1.625GHz.
Using 1.4GHz step, you'll get 1.750GHz.
Using 1.5GHz step, you'll get 1.875GHz.
5- The issues :
With a new overclocking system obviously comes some new problems related to it.
With the ability to fine tune the frequencies, you'll find that some frequencies are buggy somewhat, giving low performances. For example, using 115% Live OC with the 1.3GHz step will give some poor performances, when 114 and 116% won't. It could be a NSTools issue, but I think it has more to do with the hardware. It's well known that on CPUs some frequencies or even frequency ranges can be buggy, unstable, or slow. If you encounter that, try to add or remove a percent to LiveOC.
As said earlier, LiveOC will overclock the bus for all steps at the same time by the same amount of %.
Knowing that, you'll have to adapt your voltages for all the frequencies to stay stable, and this for any sensible change on LiveOC percentage.
6- Custom Voltage :
What would be LiveOC without Custom Voltages ?!
I did add leakage values to Glitch kernel features when I saw that some phones were overclocking much better with the right balance between ARM and Int voltages, depending on the phone, with very different results. The leakage value was basically that : balance between the two.
Well, as you probably know if you did read the changelogs, you have now the capacity to overvolt/undervolt both the ARM voltage (the CPU voltage you know well already), and the Int (internal) voltage. The last one is the voltage going to the GPU/memory controller, and will need to be tweaked accordingly to your phone.
As a starting point, here are the Int voltage values I was using for each leakage, adapted for V14 new frequency table :
HIGH LEAKAGE :
1500 : 1.225
1400 : 1.200
1300 : 1.175
1200 : 1.150
1000 : 1.125
800 : 1.100
400 : 1.100
200 : 1.100
100 : 1.000
MEDIUM LEAKAGE :
1500 : 1.200
1400 : 1.175
1300 : 1.150
1200 : 1.125
1000 : 1.100
800 : 1.100
400 : 1.100
200 : 1.100
100 : 1.000
LOW LEAKAGE :
1500 : 1.175
1400 : 1.150
1300 : 1.125
1200 : 1.100
1000 : 1.100
800 : 1.100
400 : 1.100
200 : 1.100
100 : 1.000
Of course, using LiveOC will force you to change these voltages accordingly.
Here are some advices about this :
- Try to stay around 1.225 - 1.250V for your highest frequencies;
- Try not to ever go past 1.300V if you don't want to kill your phone quickly;
- Be VERY gentle when tweaking it as it is VERY sensitive;
- Try to follow a more or less linear curve for Int voltage on OC frequencies;
- Going below 1.000V on 100MHz step will generally kill stability with no battery gain.
This guide may change depending on my decisions related to the Glitch kernel development, or to polish / add things to it.
Thanks to Ezekeel from Nexus S section for these awesome tools.
LiveOC : http://forum.xda-developers.com/showthread.php?t=1288015
Custom Voltages : http://forum.xda-developers.com/showthread.php?t=1331610
23/01/2012 - UPDATED TO REFLECT V14-B1 CHANGES.
09/02/2012 - UPDATED TO REFLECT V14-B3 CHANGES.
Click to expand...
Click to collapse
Sent from my SCH-I500 using XDA App
Yeah the guide is highly confusing but ill attempt to decipher it lol. As of now though ill just run the liveoc at %110
And once again thanks for the help, trying to figure it out on my own was driving me nuts
Djp2012 said:
Yeah the guide is highly confusing but ill attempt to decipher it lol. As of now though ill just run the liveoc at %110
And once again thanks for the help, trying to figure it out on my own was driving me nuts
Click to expand...
Click to collapse
I use 110%, stock voltages, and the 1200 max step
Sent from my SCH-I500 using xda premium
whats the downside to just using voltage control and keeping it simple?
droidstyle said:
whats the downside to just using voltage control and keeping it simple?
Click to expand...
Click to collapse
No downside that I can tell
Terminators run on Android
The downside is that it's just utilizing extra frequency steps for CPU overclocking as opposed to being able to fine-tune BUS (CPU+GPU+RAM) speed.
droidstyle said:
whats the downside to just using voltage control and keeping it simple?
Click to expand...
Click to collapse
A bottleneck in the buss.. The old glitch v13 overclocked the buss for you. Check the op in the v13 thread. In this kernel by just overclocking cpu I'm sure your bound to not have an efficient setup as the gpu and buss and ram will be stock
Sent from my SCH-I500 using xda premium
Think of a Manure spreader flinging crap against a brick wall, you're manure is your data, the brick wall is your bottle neck.. Well your bottle neck had a 1 foot hole in it. That's your throughput. You speeding up your spreader without making that hole bigger gives you a wall o' ****.
Just because your overclocking to 1.5ghz dont Mean you'll process any more any quicker.. I can use a performance governer and oc to 1.8 GHz then lock my screen.. What does that give me? A battery sucker that is not throughputing the amount of info the step I'm on suggests i could be
Sent from my SCH-I500 using xda premium
currently 14hrs run time @ 42% battery, 2hrs screen on time. seems fairly efficient and fast idk. I was running nstools and using live oc with no issues previously, but i noticed no improvement over using voltage control. i guess ill switch back to nstools and give live oc another go.
droidstyle said:
currently 14hrs run time @ 42% battery, 2hrs screen on time. seems fairly efficient and fast idk. I was running nstools and using live oc with no issues previously, but i noticed no improvement over using voltage control. i guess ill switch back to nstools and give live oc another go.
Click to expand...
Click to collapse
To tell you the truth, i don't think any overclock will make a noticeable difference. These ics roms with the glitch kernel are so fast to begin with. But when it comes to heavy apps i know you won't see the performance of v13 just using vc. Because v13 overclocked the buss/gpu.
And i had 84% battery after 10 hours today. With at least an hour of screen on. But I'll keep track tomorrow with some screenies if you want to compare
Sent from my SCH-I500 using xda premium
Hello everyone! I'm using latest's sirkay's kernel which gets up to 1.6ghz oc,i wanted to know if i could increase the steps to increase the oc,so i could test if i can achieve more than 1.6ghz! Is there a way to do it? Thank you
There is, build a kernel yourself.
Sent from my ST18i using Tapatalk 2
idareyoutoclickthis said:
There is, build a kernel yourself.
Sent from my ST18i using Tapatalk 2
Click to expand...
Click to collapse
LOL....too true....
But anyway, it is craziness to overclock the RAY even to 1.6 GHz....the power dissapted by the cpu is: C x f x V x V (p = power, C = capacitance, f = frequency, and V = voltage)....the ray is rated at 1 GHz frequency and 1200 mV...so assuming you can get 1.6 GHz to be stable @ 1200 mV...you are still talking about a 60% increase in power...which means a lot more heat, which means your cpu decays faster....which means you will be need a new phone sooner.
The insidious part is that your phone probably won't fry in a few seconds , you will probably won't even notice it for a while, until one day, you start getting a lot of FCs, random reboots, and other signs of instability....the good news is that SONY is making a crapload of new phones to choose from.....
Please don't say that the chipset is the same in the arc and they can OC to 2.2 GHz.....the arc can tolerate a greater load because its design allows for greater heat dissipation....mostly because all the components aren't jammed on top of each other.....
idareyoutoclickthis said:
There is, build a kernel yourself.
Sent from my ST18i using Tapatalk 2
Click to expand...
Click to collapse
How do I build a kernel from myself?
I'm not saying i will keep it stable at 2ghz,just wanted to see if i could get it up to 1.7-1.8..i dont want to fry my phone xD
justmpm said:
LOL....too true....
But anyway, it is craziness to overclock the RAY even to 1.6 GHz....the power dissapted by the cpu is: C x f x V x V (p = power, C = capacitance, f = frequency, and V = voltage)....the ray is rated at 1 GHz frequency and 1200 mV...so assuming you can get 1.6 GHz to be stable @ 1200 mV...you are still talking about a 60% increase in power...which means a lot more heat, which means your cpu decays faster....which means you will be need a new phone sooner.
The insidious part is that your phone probably won't fry in a few seconds , you will probably won't even notice it for a while, until one day, you start getting a lot of FCs, random reboots, and other signs of instability....the good news is that SONY is making a crapload of new phones to choose from.....
Please don't say that the chipset is the same in the arc and they can OC to 2.2 GHz.....the arc can tolerate a greater load because its design allows for greater heat dissipation....mostly because all the components aren't jammed on top of each other.....
Click to expand...
Click to collapse
as expected from justmpm. good explanation. you wanna be spokesperson for xKernel? hahaha
Sent from my ST18i using xda premium