[kernel][Overclocked] Overclocked kernel

[Guest Stephen Hyde]

this is my ALPHA build of my first overclock kernel fr the blade,

changelog from stock:

overclock to 864mhz capable - setcpu is recommended to monitor this

new 'interactive' frequency governor ported from htc legend

swap support enabled in kernel (compcache will work if you build it )

minor other tweaks added

at moment the wifi DOES NOT work due to me not building its module yet

also this requires a modified keylayout file as android will not recognize the power button otherwise

this kernel runs your device above its normal clock speed and i am not responsible for any problems or issues it causes - FLASH AT YOUR OWN RISK

have only tested this on pauls r4 rom and the initrd is based off his boot.img for r4

boot.img:

http://downloads.streakdroid.com/boot-cm.img

7k_handset.kl

http://downloads.streakdroid.com/7k_handset.kl

ok quick howto

am assuming you have fastboot and adb setup already

boot your phone into fastboot mode (turn off then turn on while holding vol up key)

flash the boot img to phone

fastboot flash boot boot-cm.img

next reboot your device

fastboot reboot

let it boot up and settle down. then push the handset file over using adb :

adb remount

adb push 7k_handset.kl /system/usr/keylayout

adb reboot[/code]


allow device to restart and then you should see power button works :)

[Guest goatee]

Thanks Stephen! Just to be clear, before I put this on mine, is it possible to use the overclock widget to control the level of overclocking?

this is my ALPHA build of my first overclock kernel fr the blade,

changelog from stock:

overclock to 864mhz capable - setcpu is recommended to monitor this

new 'interactive' frequency governor ported from htc legend

swap support enabled in kernel (compcache will work if you build it )

minor other tweaks added

at moment the wifi DOES NOT work due to me not building its module yet

also this requires a modified keylayout file as android will not recognize the power button otherwise

this kernel runs your device above its normal clock speed and i am not responsible for any problems or issues it causes - FLASH AT YOUR OWN RISK

have only tested this on pauls r4 rom and the initrd is based off his boot.img for r4

boot.img:

http://downloads.streakdroid.com/boot-cm.img

7k_handset.kl

http://downloads.streakdroid.com/7k_handset.kl

ok quick howto

am assuming you have fastboot and adb setup already

boot your phone into fastboot mode (turn off then turn on while holding vol up key)

flash the boot img to phone

fastboot flash boot boot-cm.img

next reboot your device

fastboot reboot

let it boot up and settle down. then push the handset file over using adb :

adb remount

adb push 7k_handset.kl /system/usr/keylayout

adb reboot

allow device to restart and then you should see power button works :)

[Guest Stephen Hyde]

yes it is, im not sure is i set the default scaling to top out at 806 or 864 (not near my build pc to check at min) but either way setcpu or any of the other number of overclock apps can change cpu clock

[Guest goatee]

Great - thanks :). I'll give it a go tonight, as my computer at work doesn't have the Blade compatible adb drivers installed (has the old hero one).

yes it is, im not sure is i set the default scaling to top out at 806 or 864 (not near my build pc to check at min) but either way setcpu or any of the other number of overclock apps can change cpu clock

[Guest Stephen Hyde]

lol kool, testings always welcome

[Guest cobhc]

lol kool, testings always welcome

Well I have to say I'm not too impressed, games seem to run slower than on Froyo, and so does Launcher Pro, and all menus. Not quite as exciting as I thought it would be, maybe overclocking scales better with Froyo, we'll see.

Edit:- Rebooted again and seems a little quicker now, word to the wise for everyone, a few reboots may be needed.

Edited November 2, 2010 by cobhc

[Guest goatee]

But you're not comparing like with like - Froyo *is* faster because it uses a JIT compiler - compare it with one of the 2.1 ROMs.

Well I have to say I'm not too impressed, games seem to run slower than on Froyo, and so does Launcher Pro, and all menus. Not quite as exciting as I thought it would be, maybe overclocking scales better with Froyo, we'll see.

[Guest popoyaya]

Well I have to say I'm not too impressed, games seem to run slower than on Froyo, and so does Launcher Pro, and all menus. Not quite as exciting as I thought it would be, maybe overclocking scales better with Froyo, we'll see.

This is to be expected. The overclock gives only a 30% performance gain, whilst Froyo can give (theoretically) up to 500% performance gain.

As a proof of concept this overclock is great. Can't wait for overclocked Froyo!

[Guest cobhc]

But you're not comparing like with like - Froyo *is* faster because it uses a JIT compiler - compare it with one of the 2.1 ROMs.

See edit, seems to be a lot better now. I'm guessing this with Froyo will be pretty nice.

[Guest goatee]

Fair enough - and sorry if I got a bit narky, as popoyaya said, having a JIT compiler will have a far greater impact than the 33% increase in CPU speed will bring.

See edit, seems to be a lot better now. I'm guessing this with Froyo will be pretty nice.

Edited November 2, 2010 by goatee

[Guest cobhc]

Fair enough - and sorry if I got a bit narky, as popoyaya said, having a JIT compiler will have a far greater impact than the 33% increase in CPU speed will bring.

No problem. Was just a little underwhelmed at first. I knew not to expect miracles, but it just didn't seem any faster than my brothers SF which is completely stock, and felt slower in some cases. Gaming seems to be around the same speed as Froyo if not better, while loading is a lot quicker. Really looking forward to this on Froyo!

Edited November 2, 2010 by cobhc

[Guest Rem1x]

Whoa. Looks like my battery is going down quicker then USB can charge it :)

Seems faster then froyo, imo. At least in the UI, etc.

[Guest oh!dougal]

Seems faster then froyo, imo. At least in the UI, etc.

From which I gather that it is providing a faster (yet totally stable) 2.1 experience. (Well apart from the quirks that we are already all too well aware of, and the wifi, the keyboard, powerbutton ... )

FroYo + overclocking is clearly (at some point in the future) going to be a "paradigm shift" ... OK, it'll make it twice as fast as it started out ... and twice as hated by the iPhone crowd!

Edited November 2, 2010 by oh!dougal

[Guest blauwal26]

Well done mate!

[Guest cobhc]

Been trying to fool JIT into working on 2.1, but it's not having it. Wanted to get a taste of the speed we can expect from Froyo+Oc'ing.

[Guest Mark D]

Whoa. Looks like my battery is going down quicker then USB can charge it :)

That's my main concern. Increased battery drain and cpu temp.

Is it noticably different or is it really as bad as you said above? :)

I'm quite looking forward to a froyo overclockable beta or better if our Chinese friends come up with the goods. Quite a steep learning curve for this noobie.....

more reading to do.......

[Guest cobhc]

Reminder for anyone trying this out.

In order to get your original rom working again (R4 or Froyo Alpha) you will need to re-run the commands detailed here BEFORE doing a system restore or a reflash of your previous rom.

Otherwise you will end up with a non working battery status, and Wi-Fi which will error while trying to activate.

It's very important that you reflash the boot image BEFORE restoring/flashing your previous rom, otherwise you will end up with a phone that doesn't boot.

Trust me on this one, just spend the last half hour getting my phone working again!

Stephen, if you could add this to your original post and modify if need be, that would be great.

Edited November 2, 2010 by cobhc

[Guest Bazza76]

Hi

Can some one tell me how to do this with ubuntu 10.10 please!

Just ditched windows and loving ubuntu but a lot to learn yet.

Thanks

[Guest acolwill]

There's a graphics bug when selecting items from the settings menu

Check the left hand side just as you press, it goes yellow.

[Guest kallt_kaffe]

Is this the acpuclock.c you are using? https://github.com/jvaughan/san-francisco-k...msm/acpuclock.c

If so then isn't this just the good old cosmetic overclocking that the pulse guys where doing until I pointed them in the right direction?

I posted an acpuclock.c here that should work if this CPU follows the same rules as the MSM7225/7227 (which I believe it does). Not tested as I haven't got a blade myself.

Edited November 3, 2010 by kallt_kaffe

[Guest zed2012]

Any ETA for a Froyo kernal ? cant wait it to try it out and see if it burns my hand whilst on a call .. like my old G1 ... :)

[Guest Stephen Hyde]

Not sure the diffdrence between yours and mine except using a different pll value. I pulled my values ffom an overclock htc legend kernel jence I know they work

[Guest kallt_kaffe]

Not sure the diffdrence between yours and mine except using a different pll value. I pulled my values ffom an overclock htc legend kernel jence I know they work

Assuming you are using the acpuclock.c in the git repo I pointed to, changing the first value in the frequency array does not overclock the device. It just changes the speed it tell you it runs but it does run at that speed. It does affect the BogoMIPS which are just BogoMIPS as in Bogus MIPS but it does not affect benchmarks.

The pulse guys did the same mistake but they were not first, it's an old mistake that keeps popping up. I realized it when trying to add the pulse guys 760MHz overclock to my U8100 (similar to pulse mini) and realized it weren't overclocking at all.

Here's how it works. You set the "cosmetic" value in the frequency array, copying the highest stock frequency. Then in another part of acpuclock.c you detect if the "cosmetic" value us above 600000 and overrides some stuff (don't ask how that part works in detail, I just stole the idea from the Hero guys and adapted it for the pulse and pulse mini code).

This is the part that does the real overclocking:

/* Set proper dividers for the given clock speed. */

static void acpuclk_set_div(const struct clkctl_acpu_speed *hunt_s) {

		uint32_t reg_clkctl, reg_clksel, clk_div, src_sel, a11_div;



		reg_clksel = readl(A11S_CLK_SEL_ADDR);


		/* AHB_CLK_DIV */

		clk_div = (reg_clksel >> 1) & 0x03;

		/* CLK_SEL_SRC1NO */

		src_sel = reg_clksel & 1;



		a11_div=hunt_s->a11clk_src_div;


		// Perform overclocking if requested

		if(hunt_s->a11clk_khz>600000) {

				a11_div=0;

				writel(hunt_s->a11clk_khz/19200, MSM_CLK_CTL_BASE+0x33C);

				udelay(50);

		}


		/*

		 * If the new clock divider is higher than the previous, then

		 * program the divider before switching the clock

		 */

		if (hunt_s->ahbclk_div > clk_div) {

				reg_clksel &= ~(0x3 << 1);

				reg_clksel |= (hunt_s->ahbclk_div << 1);

				writel(reg_clksel, A11S_CLK_SEL_ADDR);

		}


		/* Program clock source and divider */

		reg_clkctl = readl(A11S_CLK_CNTL_ADDR);

		reg_clkctl &= ~(0xFF << (8 * src_sel));

		reg_clkctl |= hunt_s->a11clk_src_sel << (4 + 8 * src_sel);

		reg_clkctl |= a11_div << (0 + 8 * src_sel);

		writel(reg_clkctl, A11S_CLK_CNTL_ADDR);


		/* Program clock source selection */

		reg_clksel ^= 1;

		writel(reg_clksel, A11S_CLK_SEL_ADDR);


		/*

		 * If the new clock divider is lower than the previous, then

		 * program the divider after switching the clock

		 */

		if (hunt_s->ahbclk_div < clk_div) {

				reg_clksel &= ~(0x3 << 1);

				reg_clksel |= (hunt_s->ahbclk_div << 1);

				writel(reg_clksel, A11S_CLK_SEL_ADDR);

		}

}[/code]


Just run winmerge or diff and compare my acpuclock.c and the one I pointed to in the repo and you'll find the differences.


As you can see the overclock is done by setting a value and that value * 19200kHz is the frequency you get, that's why all the overclocking steps are dividable by 19200. The Legend acpuclock.c should have something similar like this buy you may have missed copying that part.


With a working overclock you should see a performance increase in linpack and setcpu benchmark scores that are in proportion to the overclock but do several as the benchmark result can vary a bit between runs.

Edited November 3, 2010 by kallt_kaffe

[Guest mELIANTE]

Assuming you are using the acpuclock.c in the git repo I pointed to, changing the first value in the frequency array does not overclock the device. It just changes the speed it tell you it runs but it does run at that speed. It does affect the BogoMIPS which are just BogoMIPS as in Bogus MIPS but it does not affect benchmarks.

The pulse guys did the same mistake but they were not first, it's an old mistake that keeps popping up. I realized it when trying to add the pulse guys 760MHz overclock to my U8100 (similar to pulse mini) and realized it weren't overclocking at all.

Here's how it works. You set the "cosmetic" value in the frequency array, copying the highest stock frequency. Then in another part of acpuclock.c you detect if the "cosmetic" value us above 600000 and overrides some stuff (don't ask how that part works in detail, I just stole the idea from the Hero guys and adapted it for the pulse and pulse mini code).

Just run winmerge or diff and compare my acpuclock.c and the one I pointed to in the repo and you'll find the differences.

But there's another user whose phone started to show artifacts after applying steve's OCed kernel. I suppose that's because real speed was actually changed?

[Guest kallt_kaffe]

But there's another user whose phone started to show artifacts after applying steve's OCed kernel. I suppose that's because real speed was actually changed?

If he's using the acpuclock.c I pointed to, which I am not yet 100% sure of, then the artifacts are likely caused by something else or that the acpuclock.c (that I pointed to in the github) does not follow the rule copy-the-last-frequency-line-and-change-only-the-first-value. On the other hand that should only affect CDMA phones but it's hard to tell which of the four arrays it uses. If I had a blade I would identify it as it is very easily done but sadly I don't have one, don't live in the UK, and can't spare the 150-160GBP they cost on eBay at the moment.

I'm just trying to make sure you don't fall into the pit of cosmetic overclock and placebo effects that so many other overclocking attempts seems to go through as a first phase.

Edited November 3, 2010 by kallt_kaffe