[krn.modules] overclocking for Arc (ICS) without custom kernels [now released!]

Update:

Use at your own risk, nothing is guaranteed!! Overclocking is dangerous and could brick your phone so be aware of what you are about to do!

If you want to take the risk, the files are below:

overclock_arc_ics_v1.zip

Install procedure:

1. The zip contains two files, overclock_12.ko and overclock_14.ko.
2. Unpack the two files onto your /sdcard folder
3. Insert one or the other using:


where X is 2 or 4 depending on what frequency you want, 2 for 1200MHz or 4 for 1400MHz.

You can create a small script with the same contents and have Script Manager run it at boot time.

IMPORTANT: About frequency managers:

The CPU Managers are not perfect (I've tried SetCPU and No Frills).
They do not read the frequency tables from kernel - but as far as I can tell, they rely on the time_in_state file to see what frequencies are available. But if a frequency is changed, they remain disorientated.

THUS.

a) When booting the phone with any of the overclocking module there should be no problems, as long as SetCPU / NoFrills did not start and did not read the time_in_state file. Then no changes needed.
b) But if you start them and THEN you insert / remove the modules, etc - please go back to them and select again minimum frequency and maximum frequency EVEN IF they appear as already selected.
Just drag the first slider to the max and the second one to the min.

Also IMPORTANT:

Do not set the module at boottime unless you are absolutely sure the phone is stable with the frequencies. Otherwise you might end up in a boot loop.

PS: To other members trying to help: PLEASE DO NOT REPACK the archive and to offer it as update.zip or init.d scripts, etc.
I will do it in the next few days. The reason is that people get confused what to choose and then they ask questions about those .zips and so on. Better keep things simpler with minimal changes to the system (even these modules, they are very small, ~30kb ).

Enjoy guys - and thank you very much for your support!

Do not forget: for anyone interested, I posted a lengthly tutorial on my blog on how overclocking is achieved (disassembly and so on): http://hex.ro/wp/blog/overclocking-an-android-phone-running-with-an-msm-core/

--

I've managed to overclock my Arc (running Arc S latest ICS ROM) to run at 1200Mhz - all this WITHOUT a custom kernel and without the bootloader unlocked and so on.

I've read oppinions like this one: http://talk.sonymobile.com/message/184828#184828:

To Overclock you need to use a custom Kernel[ DoomKernel]. with Stock kernel overclocking not possible. To use a custom kernel you need to unlock the bootloader. [which is little bit sensitive]

Click to expand...

Click to collapse

This is plain wrong.

I will offer the module, but now is still in development, since the time_in_state table is still wrong (but that doesn't mean CPU doesn't go to 1200Mhz with any governor installed). Also, I don't know if I will ever fix the time_in_state since it is boring to disassemble - but it can be done.

Here are some screenshots:

1) Running at 1200MHz, but SetCPU insists the maximum frequency is 1024MHz - it probably uses some other values instead of the one on the /sys/devices/system/cpu ..



2) SetCPU Native Benchmark (at 1200Mhz it is around 600, and at 1024MHz it is arround 800 - lower is better)



Although things could have been easier if the kernel would export some symbols - nonetheless it can be done by using the /proc/kmem dump in a similar process described here http://code.google.com/p/milestone-overclock/wiki/Disassembly (but adapted to msm instead of omap2).

I will post a full article too - but I have to write it first - on how to do this...

If you guys are interested or having any questions, just post below ..

thanks for the support guys

I did not try to go to 1.4 Ghz since I believe I need to up a bit the voltage and I did not yet identified kernel memory spaces where this has to happen.

I'm still looking to see if time_in_state can be adjusted - the table seems dynamically allocated and it makes its detection a bit more tedious since it doesn't have a fixed address in memory upon each reboot.

I'm wondering if it is needed to know what time in state is, seems more useful for battery saving but since the goal is to overclock ..

Good news - time in state table is fixed.

Noticed a few glitches with the time_in_state programs (mostly SetCPU).
Since the phone starts with 1024MHz but then is changed by the module to 1200MHz, some programs have small bugs because they remember the initial frequency. For example, after module is inserted, SetCPU somehow considers the minimum frequency to be 245MHz but a touch of the slider makes it go back to 122MHz.

This is now the only small inconvenience ..

Also, the smartassV2 module I've built has the max frequency set to 1024MHz, but I will recompile and offer them as a bundle to have 1200MHz hard coded. It is actually faster to have the speeds hardcoded instead of detected on the fly, since it makes the transitions quicker ..

Below few screenshots:

a) SetCPU showing correct Max frequency.



b) CPU Spy showing time in state ... it uses also deep sleep.



c) SetCPU bogomips:



One last thing...

I cannot add all Arc's S frequencies. It is easier to 'patch' the kmem and have the phone go to 1200MHz instead of 1024MHz instead of adding new values - because time_in_state table is allocated dynamically when phone boots to have 6 states. There's no space allocated for additional frequencies. If I add another value at the end (and patch the indexes) - some other variable put there by the kernel could be overwritten.

I could allocate the table in the module and update the global pointer to the new space - but it means more code which now doesn't seem necessary.

I will do some tests with 1400 instead of 1200 ..

VICTORY!!!

First, for happy side, here are the benchmarks:

a) AnTuTu 3373 vs 3069 (about 10% increase according to it).



b) Linpack 38.05 vs 33.5



Second, for drama side:

SetCPU native results from the initial posts above ended up to be fake. Don't know what SetCPU was doing but were incorrect. I'll explain.

Wanting to put some screenshots of OC improvements, I tried out Antutu and linkpack. To my surprise / shock, they were both offering the same values for the two speeds, 1200MHz and 1024MHz. I could not believe, how come the speed was now 1200 but results the same ???? Also, SetCPU did report an massive improvement, right ? From 800 down to 600 ...
Unconvinced, I found a PI Calculator, and tried it out with 10000 digits, it also reported same results 10.3 seconds .....

So ... going back to the source code I found out that frequency was actually controlled by the PLL rates and I was not modifying those, the CPU was actually phisically running at 1024Mhz. I lost trust in SetCPU with it's native tests (which now return about 500 when I finally fixed the code).
I thus dug more and found the correct PLL rates - and changed them to the real 1200MHz. Indeed the phone switched to the correct frequency and all performance tests above show the increase.

Tests were done with Performance governor on (max speed).

PS: PI Calculator now reports 9.3 seconds for 10.000 digits, and improvement of 10%.



I will release the module very soon now.

It will be very simple - just:


To run it at boot time, it can be done from GUI using apps as Module Loader or Script Manager (SManager).

The overclock.ko will come in two flavours

One for 1200000Hz another one for 1401600Hz.

I have posted an article on my blog on the procedure followed to create the module: http://hex.ro/wp/blog/overclocking-an-android-phone-running-with-an-msm-core/

I've tested the 1.4Ghz frequency with 1200mV voltage and it resets in Antutu towards the end of the 3D test. However, I've upped the voltage to 1250mV and I've ran 3 Antutus with no problems! But boy it gets hot.

Here are some benchmark results from 1024000Hz up to 1401600Hz
a) 37% in CPU Integer operations
b) 41% in CPU Floating Point operations.

This generates almost 20% increase in total performance!

Thanks for the link.

I've checked it but is incomplete - it doesn't handle the time_in_state file ( cpufreq_stats_table kernel variable).

Mine goes on a similar route but :
a) handles the time_in_state
b) is unloadable (which the vision_hc doesn't do - it doesn't go back to stock if you want rmmod it). Mine switches back to stock.



But a good effort on that one also!

Will put them up tonight.

@Dark Fable - About the Arc S - I could but I need remote access to a phone to be able to dump specific addresses into memory and adjust the constants from the code.