Database Info

[HOW TO] Create your own Frequency Table. Works on 2.2

Ok so I Overclocked/undervolted via Milestone Overclock - no problems, however it got me thinking, all we are doing with this app is changing the maximum frequency and the maximum vsel.
I was looking for some extra oomph but also wanted to maximise battery life. My current set up is a 900mhz/46vsel maximum, but what about the other available frequencies - 600/300mhz - we ain't touching the vsel on these - are we getting the most out of this??
I did a bit of delving around so firstly I found the following when performing a cat /proc/overclock/mpu_opps with my overclock in place:
mpu_opps[3] rate=900000000 opp_id=3 vsel=46
mpu_opps[2] rate=600000000 opp_id=2 vsel=48
mpu_opps[1] rate=300000000 opp_id=1 vsel=33
So this is showing that the vsel for 600mhz is actually higher than 900mhz - not very economical! so how can we change this, well delving around various forums i got the jist of how to change this so here's a tutorial
IMPORTANT READ THIS!!! Disclaimer: I will not be held responsible for any damage to your phone, your PC or indeed your life from following this guide. The steps in this guide worked for me. Doing this kind of thing could affect your warranty and all that so have a long hard think about it before you go ahead. If anything goes wrong and your phone freezes or reboots spontaneously, remove the sdcard and boot the phone which will disable the overclock module and enable you to reverse whatever you did! As always I would always recommend a backup using Clockworkmod recovery. This is hacking and bad things can happen so be prepared. This is only tested on a stock/rooted 2.21 UK Generic/2.34 Deblur ROM with no apps removed - I have no idea if this works on other ROMs like JBoogie's (stock roms should be ok), because I don't know what changes/tweaks the Dev has done - If you try it and find it does/doesn't work then report back, but I can't offer any support for that
1) Create a setscaling.sh (I have attached mine as a base) script, this is what mine looks like. You can change frequencies/vsels, but it MUST stay in the format below.
echo 46 > /proc/overclock/max_vsel
echo 900000 > /proc/overclock/max_rate
echo 1 300000000 28 > /proc/overclock/mpu_opps
echo 2 600000000 38 > /proc/overclock/mpu_opps
echo 3 900000000 46 > /proc/overclock/mpu_opps
echo 0 900000 > /proc/overclock/freq_table
echo 1 600000 > /proc/overclock/freq_table
echo 2 300000 > /proc/overclock/freq_table
Lines 1/2 are your custom vsel/freq as loaded into Milestone Overclock
Lines 3/4/5 are your freq's and the custom vsels you want to use at those freq's (you can see they are much less than what they were originally!)
Lines 6/7/8 are your frequency table
I can't stress enough you must keep the format the same, and make sure you use the corect number of. It is possible to for example add an extra step/Frequency in - I haven't tested this so just be careful. Also bear in mind if you lower the vsels too much then you will cause the phone to fall over. However if you do get this just pull the SD card an it will boot the phone with the overclock module disabled
when you have set your setscaling.sh up you then need to do the following.
copy it to your sdcard, then via adb (you can also use root explorer)
su
mount -o rw,remount -t ext3 /dev/block/mmcblk1p21 /system
cp /sdcard/setscaling.sh /system/xbin/setscaling.sh
chmod 755 /system/xbin/setscaling.sh
mount -o ro,remount -t ext3 /dev/block/mmcblk1p21 /system
Then to after this to execute via adb you can just type:
setscaling.sh
Seriously though guys get root explorer as that will enable you to edit you setscaling.sh on the fly as you do your testing (finding optimum vsel), once edited you can then execute it by simply clicking on the file.
Once you have got your setscaling.sh just the way you want it, you can then get it to initialise automatically after boot - this had me stumpted for a while as the script was executing before the overclock module had loaded hence the settings weren't taking effect and I was having to start it manually. I'm more windows orientated and this actually turned out to be a really easy fix.
the key is another script called install-recovery.sh (again I have attached this to the post) and it contains the following info
#!/system/bin/sh
sleep 80
setscaling.sh
So what this does is it waits 80 secs before executing setscaling.sh - which gives the system more than enough time to boot up and load the overclock module. Intall this as per below after plaing on sdcard:
su
mount -o rw,remount -t ext3 /dev/block/mmcblk1p21 /system
cp /sdcard/install-recovery.sh /system/etc/install-recovery.sh
chmod 755 /system/etc/install-recovery.sh
reboot
Once rebooted do a cat /proc/overclock/mpu_opps and check your setscaling.sh has applied ok (i.e it is displaying your custom vsels)
Jobs a good un - enjoy!
##If you are reporting problems with it not working please post the exact steps of what you have done, otherwise I won't be able to assist##

Reserved...............

I've searched for an hour how to use Motorola Overclock. I've put the kernelmodule.tar.gz on the sdcard...
But i don't understand how to load it. Or where to place it...
The wiki on the googlecode page leaves me without a clue.

vanloque said:
I've searched for an hour how to use Motorola Overclock. I've put the kernelmodule.tar.gz on the sdcard...
But i don't understand how to load it. Or where to place it...
The wiki on the googlecode page leaves me without a clue.
Click to expand...
Click to collapse
mate just download milestone overclock from the market!

Higgsy said:
mate just download milestone overclock from the market!
Click to expand...
Click to collapse
That's what i did... And then i can't do anything in the app...
Oh Hey, i did forget to Re-Root after FrozenEclairing!

vanloque said:
That's what i did... And then i can't do anything in the app...
Click to expand...
Click to collapse
Do you have root?

after you apply this how do you tell if its worked?
edit: wow im retarded ignore this post -.-

A one right here

thanks, needed this for my overclock

I use gscript lite, and this info is perfet A 1

thanks for the idea and this should work with just adb; no need to download the scripts...
Code:
su
mount -o rw,remount -t ext3 /dev/block/mmcblk1p21 /system
echo "#!/system/bin/sh
echo 46 > /proc/overclock/max_vsel
echo 900000 > /proc/overclock/max_rate
echo 1 300000000 28 > /proc/overclock/mpu_opps
echo 2 600000000 38 > /proc/overclock/mpu_opps
echo 3 900000000 46 > /proc/overclock/mpu_opps
echo 0 900000 > /proc/overclock/freq_table
echo 1 600000 > /proc/overclock/freq_table
echo 2 300000 > /proc/overclock/freq_table" > /system/xbin/setscaling.sh
chmod 755 /system/xbin/setscaling.sh
setscaling.sh
echo "#!/system/bin/sh
sleep 80
/system/xbin/setscaling.sh" > /system/etc/install-recovery.sh
chmod 755 /system/etc/install-recovery.sh
mount -o ro,remount -t ext3 /dev/block/mmcblk1p21 /system

really glad others are using this and liking it, everyone who is using milestone overclock should be using it!

Hey Higgsy,
i installed your scripts through Root Explorer (incl. executing + rebooting), but checking the mpu_opps file still gives me standard frequencies. You got an idea for this?
Greets, Jack

basshamster said:
Hey Higgsy,
i installed your scripts through Root Explorer (incl. executing + rebooting), but checking the mpu_opps file still gives me standard frequencies. You got an idea for this?
Greets, Jack
Click to expand...
Click to collapse
is the milestone overlock installed and module loaded?
Custom setting in milestone overclock set to 900mhz/46vsel?
Did you set the permissions? (ie the chmod bit).

- Milestone Overclock installed and loaded (incl. startup-load)
- i use different settings 1000/50 (300/30, 600/40 -> in setscaling-script), but 1000/50 is also set in custom settings so it seems equal to me
- permissions of both scripts are "rwxr-xr-x"
hmmm....
little edit: mpu_opps gives me 300/33, 600/48, 1000/50 so it#s not completely standard

basshamster said:
- Milestone Overclock installed and loaded (incl. startup-load)
- i use different settings 1000/50 (300/30, 600/40 -> in setscaling-script), but 1000/50 is also set in custom settings so it seems equal to me
- permissions of both scripts are "rwxr-xr-x"
hmmm....
little edit: mpu_opps gives me 300/33, 600/48, 1000/50 so it#s not completely standard
Click to expand...
Click to collapse
yeah it is standard apart from the max overclock you set in Milestone Overclock.
Please attach your exact setscaling.sh so I can take a look at it.

Thx for helping!

basshamster said:
Thx for helping!
Click to expand...
Click to collapse
hmm looked ok on the face of it, however when I recreated the file it was 355bytes as opposed to yours that was 353bytes
anyway, i think I might know the problem, in root explorer, open setscaling.sh in text editor - look at the end of each line - is there a little box? If there is the delete them - save and then execute.
Your permissions were ok
This is working ok on my phone now

Unfortunately still not working ... don't know what's the problem. Maybe someone else joins us with another solution. Thx for your help anyway!

I posted on the google forum bugreport.
When i click LOAD that reboots the phone and when i relaunch the app the clocks are still empty, so i click load again and it reboots again... Etc.

For those of you having issues with the new ASOP Kernels

I found that I was having an issue with most of the new kernels and after much research I found that it was due to the HAVS being very aggressive from stock to make the kernel better at battery preservation.
To fix this you need to build a script and dump it on your phone so it loads every boot. This was hard to find all the info in one place so I figured I would put it all together here.
Ok here we go, first grab the file you need from your phone doing a cut and paste of the following commands
adb shell
cat /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
Copy and paste this out into a text editor
Then adjust the script voltages such as I did in the following example
#!/system/bin/sh
echo "19200 975 1000" > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
echo "128000 1000 1025" > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
echo "245000 1000 1025" > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
echo "384000 1000 1025" > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
echo "422400 1000 1050" > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
echo "460800 1000 1050" > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
echo "499200 1000 1050" > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
echo "537600 1025 1075" > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
echo "576000 1050 1100" > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
echo "614400 1050 1125" > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
echo "652800 1100 1150" > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
echo "691200 1100 1175" > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
Just change the numbers in the right to match what voltage you need to use to keep your phone from rebooting.
Now we need to get the file on the phone but we need permissions so run
adb remount
once you do that you need to push the script back to the phone using the adb push command
adb push c:\filename /etc/init.d/filename
This will put the file there but you need to chanage the permissions so that it can run on each boot.
adb shell
chmod 755 /etc/init.d/filename
once this is done you can reboot again to dump the values or you can do the following command.
./etc/init.d/filename
That should do it
YOu can do to check
cat /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
The above values were just ones I was playing around with my phone seems to have issues at the bottom of the range so I bumped those up a bit and it seemed to work fine!
Let me know if you need any help with this as it was a pain finding all the info and putting it all together.
Props to ziggy at http://www.ziggy471.com/2011/01/21/beta-kernel-21-jan-11/
as he was the one where I got most of the info.

like which kernels and what versions would this apply too?

I have had to do it to the SZ and Tiamat kernels, but this is only if you phone is boot looping with the stock and you believe its due to voltage. I was having a problem with ever rom and kernel that was using HAVS with my phone and this was the only way I could get it to boot and stabilize.
Again its not for everybody and I would assume that you can make you phone not boot, but you could also use this to drop the voltage to save more battery but you might make it so you phone boot loops and you would be stuck going to back to a nandroid or stock kernel again.

Seagrizzly said:
I have had to do it to the SZ and Tiamat kernels, but this is only if you phone is boot looping with the stock and you believe its due to voltage. I was having a problem with ever rom and kernel that was using HAVS with my phone and this was the only way I could get it to boot and stabilize.
Again its not for everybody and I would assume that you can make you phone not boot, but you could also use this to drop the voltage to save more battery but you might make it so you phone boot loops and you would be stuck going to back to a nandroid or stock kernel again.
Click to expand...
Click to collapse
im running the nosbc savage-zen with no issues.

fixxxer2008 said:
im running the nosbc savage-zen with no issues.
Click to expand...
Click to collapse
I also have the same issues with OP. Any kernel that has HAVS will put my phone on a constant bootloop (savage zen with or without sbc) or either get it to load fine (Tiamat), but will then lock after a few seconds and reboot.

fixxxer2008 said:
im running the nosbc savage-zen with no issues.
Click to expand...
Click to collapse
Same.. no issues here with that kernel.

thanks! great post.
i wrote a script figured i'd upload it here.
this is savaged-zen 1.0.1 stock voltage -50
it can be edited with whatever voltages you want, but make sure you save it as plain text.
just push this following the instructions in the OP but remove the .txt file extension.

Hey cool and thanks for the script, to repeat for those saying things work fine for them. That is awesome but some of us were having an issue running any of the HAVS kernels at all and thus why I had to do this fix to get my phone stable and using the new kernels, by the way I have had awesome battery life with my changes after about 12 hours only down to 79% using the tiamat 3.3.3 kernel as a base with my changes, I would only have to assume that if you could run the kernel with HAVS stock it would only be better so props goes out to the dev for that.

This is the only SBC Rom that doesn't reboot for me SBC-htc-15. I forget what Rom I was using with it but I'm using CM7 RC4 now. I'm not really sure how to do what is suggested so is there another option that might be easier?
thanks

It's so strange how we all have the same phone, yet some are very picky with HAVS and lower voltages and some are completely fine with it.

Gonna try it because my battery on CM7 has been...6 hours?
Android 17 said:
It's so strange how we all have the same phone, yet some are very picky with HAVS and lower voltages and some are completely fine with it.
Click to expand...
Click to collapse
Not really, no two cores are the exact same. The way they design them calls for them to be within an acceptable range only.

Definitely already seeing a massive improvement in battery efficiency, thanks.

How do I get Voodoo Color settings to stick after reboot?

So I applied the voodoo color settings from this thread here: http://forum.xda-developers.com/showthread.php?t=1401759
But they don't stick after reboot. Can anyone tell me how I can get them to stay when I reboot my Nexus?

You can always make an init.d script if your ROM supports it
Here's an example of how it should look, you can change the values to whatever you like
#! /sys/bin/sh
echo 2863311680 >/sys/class/misc/voodoo_color/red_multiplier
echo 3336681600 >/sys/class/misc/voodoo_color/green_multiplier
echo 3925507840 >/sys/class/misc/voodoo_color/blue_multiplier
echo -33 >/sys/class/misc/voodoo_color/blue_v1_offset
echo -26 >/sys/class/misc/voodoo_color/red_v1_offset
echo -30 >/sys/class/misc/voodoo_color/green_v1_offset
Or you can use an app called ROM Toolbox and use the "Scripter" to run this at boot
Sent from my Nexus S 4G using Tapatalk 2

Thanks! It's working great! However, I do notice that it sometimes makes my phone reboot on bootup about two times before it applies. But better than trying to remember my screen's values in Voodoo.

ARHD 7.x random reboots - solved?

Hello, I'm a long time user but a bit of a lurker but have been flashing custom ROMs for some time. Hence my post count is <10 and cannot post in the dev forums to contribute...
I noticed other users in the ARHD 7.x thread are having random reboot issues - http://forum.xda-developers.com/showthread.php?p=39586309#post39586309 - which I was suffering from too. I've been using ARHD since the 6.x days and it's a great ROM!
The new ARHD 7.x was a bit of a let down due to the random reboots. After trying all manner of things, it seems it might be one of two things. I've reflashed and not selected a couple of tweaks in the Aroma installer. So far i've been running for a few days with no reboots.
I've not chose to apply the memory/multitasking tweak and the build.prop tweaks. Not sure which of the two was the cause....
The build.prop tweaks apply these:
I doubt the nocheckin value has anything to do with the random reboots, I'm either suspecting the deeper sleep or bypassing of the kernel error checking? Perhaps a kernel panic is causing the sudden lockup and then reboot. Perhaps the "lock up" we perceive, is the phone doing a core dump?
Code:
#!/sbin/sh
# Extra tweaks for build.prop
echo "# EXTRA TWEAKS" >> /system/build.prop
echo "# Disable Sending Usage Data" >> /system/build.prop
echo "ro.config.nocheckin=1" >> /system/build.prop
echo "# Deeper Sleep" >> /system/build.prop
echo "pm.sleep_mode=1" >> /system/build.prop
echo "# Disable Kernel Error Checking" >> /system/build.prop
echo "ro.kernel.android.checkjni=0" >> /system/build.prop
The multi-tasking tweak applies these values....
I'm not sure if it could be these values being aggressive.
Code:
#!/system/bin/sh
# ========================================
# init.d script for Android Revolution HD
# ========================================
# Tweak minfree values for better multi-tasking
echo 1536,2048,3584,5120,8704,10240 > /sys/module/lowmemorykiller/parameters/minfree
I'll have to test these in the adb shell and see how the phone performs. Will keep you posted.

[SCRIPT] Lagg Nullifier - Get rid Of That Lagg!

Hello Guys & Gals of XDA, I Bring to You My Custom Script That I dident Place in this Thread as things Get DeBumped Pretty Quick So i Placed it in Xperia Play Android Development,
This Script is Aimed to Get ridd of Laggs not Increase your FPS! - Also might not show Performance on Good Roms and Or Roms with Good Scripts,
Also a little Note:
Use the Universal Version if You Dont have 512 Mb Of Ram (Universal Removes LMK Settings)
Thread is Located Here:
http://forum.xda-developers.com/showthread.php?t=2319774

Can I run this on linaro slim beanz is the starter script fixed
ss beanz T989

hatememarkz said:
Can I run this on linaro slim beanz is the starter script fixed
ss beanz T989
Click to expand...
Click to collapse
Yea, Everything works, But use the Universal Version , Also make a backup as i dont have a remover and if the starter dosent work copy this into your build.prop:
# Pro-Tuned ADJ 1.2 by LENAROX
ro.FOREGROUND_APP_ADJ=0
ro.VISIBLE_APP_ADJ=4
ro.PERCEPTIBLE_APP_ADJ=3
ro.HEAVY_WEIGHT_APP_ADJ=2
ro.SECONDARY_SERVER_ADJ=15
ro.BACKUP_APP_ADJ=5
ro.HOME_APP_ADJ=6
ro.HIDDEN_APP_MIN_ADJ=3
ro.EMPTY_APP_ADJ=15
# Kernel Stabalizer;
dalvik.vm.checkjni=false
debug.kill_allocating_task=0
# Nitro Lagg Nullifier;
ENFORCE_PROCESS_LIMIT=false
MAX_SERVICE_INACTIVITY=false
MIN_HIDDEN_APPS=false
MAX_HIDDEN_APPS=false
CONTENT_APP_IDLE_OFFSET=false
EMPTY_APP_IDLE_OFFSET=false
MAX_ACTIVITIES=false
ACTIVITY_INACTIVE_RESET_TIME=false
MAX_RECENT_TASKS=false
MIN_RECENT_TASKS=false
APP_SWITCH_DELAY_TIME=false
MAX_PROCESSES=false
PROC_START_TIMEOUT=false
CPU_MIN_CHECK_DURATION=false
GC_TIMEOUT=false
SERVICE_TIMEOUT=false
MIN_CRASH_INTERVAL=false

Hi there, you might have seen my name, you might not, but it doesn't matter...but I come here in peace, wanting to get things clarified...
Regarding your Starter Kit, all it does is setprop, so why is
Code:
sleep 60
needed? Users will see a "jammed" screen for a minute...and another thing, to add lines to build.prop, setprop is not sufficient as most of the values will be reset after a reboot...you should have done this:
Code:
echo "ro.FOREGROUND_APP_ADJ=0" >> /system/build.prop
or something similar...
Now for your main Lagg_Nullifier_Gen_2.sh.pdf, I still see a lot of sleep commands being used....whereas the script can be completed within seconds...not every command requires you to wait that long...this is essential especially when you request users to convert this into an init.d script...it extends boot time and possible initial lags right after a reboot...and certain parts of the script contains unused lines which does nothing, like this:
Code:
while true; do
FREEMEM=`free | awk '{ print $4 }' | sed -n 2p`
FREEMEMMB=$(($FREEMEM/1024))
MFK=`cat /proc/sys/vm/min_free_kbytes`
MFKMB=$(($MFK/1024))
MFKMB1=$(($MFKMB+16))
MFKMB2=$(($MFKMB+32))
if [ "$FREEMEMMB" -lt $MFKMB1 ]
then
echo "done!"
It is just to calculate your free RAM...and if FREEMEMMB is lesser than MFKMB1, it just prints out "done!"...and nothing else...or I should say you have not integrated the script fully...another example is the drop cache lines...that is only needed after the system cache has accumulated after a certain period of usage, then it will be cleared...that was the initial purpose...so if you want users to use this script at boot, the drop cache part is not needed...
My suggestion is that your script generates another script in init.d, like V6 Supercharger to avoid conflicts...

Ryuinferno said:
Hi there, you might have seen my name, you might not, but it doesn't matter...but I come here in peace, wanting to get things clarified...
Regarding your Starter Kit, all it does is setprop, so why is
Code:
sleep 60
needed? Users will see a "jammed" screen for a minute...and another thing, to add lines to build.prop, setprop is not sufficient as most of the values will be reset after a reboot...you should have done this:
Code:
echo "ro.FOREGROUND_APP_ADJ=0" >> /system/build.prop
or something similar...
Now for your main Lagg_Nullifier_Gen_2.sh.pdf, I still see a lot of sleep commands being used....whereas the script can be completed within seconds...not every command requires you to wait that long...this is essential especially when you request users to convert this into an init.d script...it extends boot time and possible initial lags right after a reboot...and certain parts of the script contains unused lines which does nothing, like this:
Code:
while true; do
FREEMEM=`free | awk '{ print $4 }' | sed -n 2p`
FREEMEMMB=$(($FREEMEM/1024))
MFK=`cat /proc/sys/vm/min_free_kbytes`
MFKMB=$(($MFK/1024))
MFKMB1=$(($MFKMB+16))
MFKMB2=$(($MFKMB+32))
if [ "$FREEMEMMB" -lt $MFKMB1 ]
then
echo "done!"
It is just to calculate your free RAM...and if FREEMEMMB is lesser than MFKMB1, it just prints out "done!"...and nothing else...or I should say you have not integrated the script fully...another example is the drop cache lines...that is only needed after the system cache has accumulated after a certain period of usage, then it will be cleared...that was the initial purpose...so if you want users to use this script at boot, the drop cache part is not needed...
My suggestion is that your script generates another script in init.d, like V6 Supercharger to avoid conflicts...
Click to expand...
Click to collapse
Code:
FREEMEM=`free | awk '{ print $4 }' | sed -n 2p`
FREEMEMMB=$(($FREEMEM/1024))
MFK=`cat /proc/sys/vm/min_free_kbytes`
MFKMB=$(($MFK/1024))
MFKMB1=$(($MFKMB+16))
MFKMB2=$(($MFKMB+32))
this part happens to be(and it was mine) in my first version of mpengine script..just saying
Oh.. and 'ro.' means do not change value when its property was set ONCE.