[GUIDE how-to]Make Your Own /init.d Script to do OC/UC, UV, and more.... - HTC Rezound

Make Your Own /init.d Script to do OC/UC, UV, and more....
I've seen a whole bunch of posts out there where users are hounding kernel devs about how to do this or that to their kernel using this or that app. The following is my take on these apps, why I do things the way I do, and how you can do them that way too.
disclaimer:
I am in NO way a developer or programmer. I've read some stuff and followed some directions. That's about it. I take no responsibility for your device releasing the magic smoke that makes it work or becoming otherwise non-functional.
Also....
Not all components in the examples provided will work with every kernel due to the fact every kernel dev incorporates different features. If you want to alter a parameter the dev hasn't specified in his sysfs, KINDLY ask him to provide it, but do NOT EXPECT him to. Things may be a certain way in his kernel for a reason. For these reasons, I make NO promise to the efficacy of any script upon any kernel.
Why apps are useful
Apps like Incredicontrol, setCPU, and CPU Master serve a purpose without a doubt. They're easy to use and, in some cases, are the only good way to manipulate your custom kernel. (Earlier incarnations of SebastianFM's kernel made CPU Master the best choice long-term.) They also make tweaking kernel settings quick and easy when you're experimenting.
Why apps suck
Apps aren't my first choice as a long-term solution. Though these apps aren't big, they are apps and that means they take up memory, clock cycles, and battery power to run. That's why I prefer to make a script to do what most of these apps do.
An /init.d script is basically a list of commands that the system executes at boot or when commanded to, and it does these things with the least amount of burden on the system as possible. This makes /init.d scripts ideal, if not the only option, for performing certain functions. For the purpose of this thread, I'm going to stick to the basics of what most of the CPU tweaking apps do.
The Meat and Potatos
First, lets look at a script.
Code:
#!/system/bin/sh
echo 30 > /proc/sys/vm/swappiness
echo deadline > /sys/block/mmcblk0/queue/scheduler
echo 30 > /proc/sys/vm/vfs_cache_pressure
echo 3074 > /sys/block/mmcblk0/queue/read_ahead_kb
AWAKE_GOVERNOR="smartassV2"
AWAKE_GOVERNOR_FREQENCY_MAX="1782000"
AWAKE_GOVERNOR_FREQENCY_MIN="384000"
AWAKE_GOVERNOR_UP_RATE_US="40000"
AWAKE_GOVERNOR_AWAKE_IDEAL_FREQ="540000"
AWAKE_GOVERNOR_MAX_CPU_LOAD="80"
SLEEP_GOVERNOR="ondemand"
SLEEP_GOVERNOR_FREQENCY_MAX="486000"
SLEEP_GOVERNOR_FREQENCY_MIN="192000"
SLEEP_GOVERNOR_POWERSAVE_BIAS="20"
(while [ 1 ]
do
AWAKE=`cat /sys/power/wait_for_fb_wake`
if [ $AWAKE = "awake" ]; then
echo $AWAKE_GOVERNOR > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo $AWAKE_GOVERNOR_FREQENCY_MAX > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo $AWAKE_GOVERNOR_FREQENCY_MIN > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo $AWAKE_GOVERNOR_UP_RATE_US > /sys/devices/system/cpu/cpufreq/smartass/up_rate_us
echo $AWAKE_GOVERNOR_AWAKE_IDEAL_FREQ > /sys/devices/system/cpu/cpufreq/smartass/awake_ideal_freq
echo $AWAKE_GOVERNOR_MAX_CPU_LOAD > /sys/devices/system/cpu/cpufreq/smartass/max_cpu_load
AWAKE=
fi
SLEEPING=`cat /sys/power/wait_for_fb_sleep`
if [ $SLEEPING = "sleeping" ]; then
echo $SLEEP_GOVERNOR > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo $SLEEP_GOVERNOR_FREQENCY_MAX > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo $SLEEP_GOVERNOR_FREQENCY_MIN > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo $SLEEP_GOVERNOR_POWERSAVE_BIAS > /sys/devices/system/cpu/cpufreq/ondemand/powersave_bias
SLEEPING=
fi
done &)
sysfile="/sys/devices/system/cpu/cpu0/cpufreq/vdd_levels"
sysfile="/sys/devices/system/cpu/cpu1/cpufreq/vdd_levels"
echo "192000 775000" > $sysfile
echo "384000 800000" > $sysfile
echo "432000 825000" > $sysfile
echo "486000 825000" > $sysfile
echo "540000 850000" > $sysfile
echo "594000 850000" > $sysfile
echo "648000 875000" > $sysfile
echo "702000 875000" > $sysfile
echo "756000 900000" > $sysfile
echo "810000 950000" > $sysfile
echo "864000 950000" > $sysfile
echo "918000 975000" > $sysfile
echo "972000 1000000" > $sysfile
echo "1026000 1000000" > $sysfile
echo "1080000 1025000" > $sysfile
echo "1134000 1050000" > $sysfile
echo "1188000 1075000" > $sysfile
echo "1242000 1100000" > $sysfile
echo "1296000 1125000" > $sysfile
echo "1350000 1125000" > $sysfile
echo "1404000 1150000" > $sysfile
echo "1458000 1175000" > $sysfile
echo "1512000 1200000" > $sysfile
echo "1566000 1200000" > $sysfile
echo "1620000 1225000" > $sysfile
echo "1674000 1250000" > $sysfile
echo "1728000 1275000" > $sysfile
echo "1782000 1275000" > $sysfile
echo "1836000 1350000" > $sysfile
What you're looking at...
The first 4 lines have nothing at all to do with your CPU. "/swappiness" and "/vfs_cache_pressure" have to do with the system's tendency to create a swap file or cache your file system. "/scheduler" sets the I/O scheduler. And "/read_ahead_kb" tells the system how far to read ahead on mass storage. Mass storage should be understood as the primary storage location of system data and apps on the device, NOT your SD Card. Those settings are elsewhere and your ROM dev may have an /init.d script called "01tweaks" that covers those. I couldn't begin to explain all of the settings within a Linux/Android kernel that can be tweaked/modified to good or bad effect.
To explain what going on next...
The next 2 groups of lines,
"AWAKE_GOVERNOR="smartassV2" specifies the smartassV2 gov for the "awake" state
AWAKE_GOVERNOR_FREQENCY_MAX="1782000" specifies the max frequency
AWAKE_GOVERNOR_FREQENCY_MIN="384000" specifies the min frequency
AWAKE_GOVERNOR_UP_RATE_US="40000" This value is the minimum step up the governor will make in ramping up frequency
AWAKE_GOVERNOR_AWAKE_IDEAL_FREQ="540000" This is the target freqency the governor will attempt to attain
AWAKE_GOVERNOR_MAX_CPU_LOAD="80" This is the % load at which point the governor will begin ramping up frequency
SLEEP_GOVERNOR="ondemand" specifies the ondemand governor for "sleep" state
SLEEP_GOVERNOR_FREQENCY_MAX="486000" set the max frequency
SLEEP_GOVERNOR_FREQENCY_MIN="192000" sets the min frequency
SLEEP_GOVERNOR_POWERSAVE_BIAS="20" specifies the powersave bias, which is specific to the ondemand governor
These values are applied here:
"(while [ 1 ]
do
AWAKE=`cat /sys/power/wait_for_fb_wake`
if [ $AWAKE = "awake" ]; then
echo $AWAKE_GOVERNOR > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo $AWAKE_GOVERNOR_FREQENCY_MAX > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo $AWAKE_GOVERNOR_FREQENCY_MIN > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo $AWAKE_GOVERNOR_UP_RATE_US > /sys/devices/system/cpu/cpufreq/smartass/up_rate_us
echo $AWAKE_GOVERNOR_AWAKE_IDEAL_FREQ > /sys/devices/system/cpu/cpufreq/smartass/awake_ideal_freq
echo $AWAKE_GOVERNOR_MAX_CPU_LOAD > /sys/devices/system/cpu/cpufreq/smartass/max_cpu_load
AWAKE=
fi
SLEEPING=`cat /sys/power/wait_for_fb_sleep`
if [ $SLEEPING = "sleeping" ]; then
echo $SLEEP_GOVERNOR > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo $SLEEP_GOVERNOR_FREQENCY_MAX > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo $SLEEP_GOVERNOR_FREQENCY_MIN > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo $SLEEP_GOVERNOR_POWERSAVE_BIAS > /sys/devices/system/cpu/cpufreq/ondemand/powersave_bias
SLEEPING=
fi
done &)
If you're kernel doesn't support different awake and sleep profiles, or you don't want to do them, then that's a lot of pointless typing. It's easier to just do this:
Code:
echo 384000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 1782000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo smartassV2 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 40000 > /sys/devices/system/cpu/cpufreq/smartassV2/up_rate_us
echo 540000 > /sys/devices/system/cpu/cpufreq/smartassV2/awake_ideal_freq
echo 80 > /sys/devices/system/cpu/cpufreq/smartassV2/max_cpu_load
(This may be the method of choice for all HTC source kernels in order to avoid issues.)
For most of you this will accomplish your goals. SmartassV2, as well as several other governors, recognize "awake" and "sleep" and adjust themselves accordingly so setting up profiles isn't all that necessary.
This here is where your voltages are set for each frequency stepping your kernel provides. This is the equivalent of typing out "echo "192000 775000" > sys/devices/system/cpu/cpu0/cpufreq/vdd_levels" for every stepping.
sysfile="/sys/devices/system/cpu/cpu0/cpufreq/vdd_levels"
echo "192000 775000" > $sysfile
echo "384000 800000" > $sysfile
echo "432000 825000" > $sysfile
echo "486000 825000" > $sysfile
echo "540000 850000" > $sysfile
echo "594000 850000" > $sysfile
echo "648000 875000" > $sysfile
echo "702000 875000" > $sysfile
echo "756000 900000" > $sysfile
echo "810000 950000" > $sysfile
echo "864000 950000" > $sysfile
echo "918000 975000" > $sysfile
echo "972000 1000000" > $sysfile
echo "1026000 1000000" > $sysfile
echo "1080000 1025000" > $sysfile
echo "1134000 1050000" > $sysfile
echo "1188000 1075000" > $sysfile
echo "1242000 1100000" > $sysfile
echo "1296000 1125000" > $sysfile
echo "1350000 1125000" > $sysfile
echo "1404000 1150000" > $sysfile
echo "1458000 1175000" > $sysfile
echo "1512000 1200000" > $sysfile
echo "1566000 1200000" > $sysfile
echo "1620000 1225000" > $sysfile
echo "1674000 1250000" > $sysfile
echo "1728000 1275000" > $sysfile
echo "1782000 1275000" > $sysfile
echo "1836000 1350000" > $sysfile
Let the mayhem begins....
Now that you've got yourself a script that will do what you want, lets talk about what to do with it.
First, I highly suggest you do NOT whip up a script like this and push it off to your device willy nilly. Once it's out there it's going to execute at boot, every time, without fail. If you've specified voltages or frequency settings that aren't stable, your device will become unstable before you can do anything about it. You're only easy fix at that point is restore from a backup, or reflash your ROM and kernel. Instead, what I recommend is that you experiment with your settings, either through an app (whether it retains the settings after reboot or not), or bust out ADB or a terminal emulator and run the settings you intend to apply. In the event your device goes wonky and restarts, whatever you've entered is lost and default parameters take effect.
Second, you're going to want to use a Linux native text editor to create this thing. I use Vim on my computer or any number of text editors on my device. Pretty much all text editors on Android will work. Windows/Microsoft editors don't format the text correctly and Linux doesn't like the file extensions. In short, it won't work even if it LOOKS right.
Assuming your script settings are stable, you're ready push it to your device and apply it.
Crack open your ADB shell and enter the following:
Code:
adb push [I]filenamehere[/I] /system/etc/init.d
Then open your shell:
Code:
adb shell
Now to set the file's permissions:
Code:
su
chmod 755 /system/etc/init.d/[I]filenamehere[/I]
And now you can execute it just as it would be if you rebooted your device:
Code:
sh /system/etc/init.d/[I]filenamehere[/I]
Alternative Execution
Install ScriptManager, place your script somewhere you can find it, set it to have SU privileges and to "run at boot", and profit.
Problems???
If you execute the script and you see a bunch of jazz come up LIKE "blahblah/blah/blahblah/blah: no path or directory exists" there's a good chance you fat-fingered something. It's also possible you're using a kernel that doesn't support whatever you're trying to do. Just because a kernel has a given governor does not mean that the sysfs (the mechanism that allows your script to set parameters) allows for the governor itself to be tweaked. The same applies for any parameter. That will also generate error messages as described above.
If you attempt to push your script to your device via ADB and it fails to allow you to do this, make sure your /system is mounter R/W as in Read/Write, as opposed to R/O as in Read/Only.
I'm happy to answer questions, but I warn you now, I don't know a whole lot. The primary purpose of this guide is to provide a better way to do what CPU tweaking apps do, not teach the finer points of script creation... which I couldn't teach anyone if I wanted to because I don't know them myself.
Further Reading:
I'll add to this if/when I come across something relevant.
http://www.linuxinsight.com/proc_filesystem.html A well written guide to exploring and understanding the /proc directory in Linux.
Asides:
This is the script I'm currently using on SebastianFM's OC Kernel v. 1.4.0. Unless you want profiles and GPU overclocking, you don't need no stinking app. (Updated. Every line of this works and it's SMOOTH.)
Code:
#!/system/bin/sh
echo 30 > /proc/sys/vm/swappiness
echo deadline > /sys/block/mmcblk0/queue/scheduler
echo 60 > /proc/sys/vm/vfs_cache_pressure
echo 3074 > /sys/block/mmcblk0/queue/read_ahead_kb
echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 1728000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo 192000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 30000 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate
echo 10 > /sys/devices/system/cpu/cpufreq/ondemand/powersave_bias
echo 1 > /sys/devices/system/cpu/cpufreq/ondemand/ignore_nice_load
echo 10 > /sys/devices/system/cpu/cpufreq/ondemand/down_differential
echo 1512000 > /sys/devices/system/cpu/cpufreq/ondemand/two_phase_freq
echo 10 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
sysfile="/sys/devices/system/cpu/cpufreq/vdd_table/vdd_levels"
echo "192000 775000" > $sysfile
echo "384000 800000" > $sysfile
echo "432000 825000" > $sysfile
echo "486000 825000" > $sysfile
echo "540000 850000" > $sysfile
echo "594000 850000" > $sysfile
echo "648000 875000" > $sysfile
echo "702000 875000" > $sysfile
echo "756000 900000" > $sysfile
echo "810000 950000" > $sysfile
echo "864000 950000" > $sysfile
echo "918000 975000" > $sysfile
echo "972000 1000000" > $sysfile
echo "1026000 1000000" > $sysfile
echo "1080000 1025000" > $sysfile
echo "1134000 1050000" > $sysfile
echo "1188000 1075000" > $sysfile
echo "1242000 1100000" > $sysfile
echo "1296000 1125000" > $sysfile
echo "1350000 1125000" > $sysfile
echo "1404000 1150000" > $sysfile
echo "1458000 1175000" > $sysfile
echo "1512000 1200000" > $sysfile
echo "1566000 1200000" > $sysfile
echo "1620000 1225000" > $sysfile
echo "1674000 1250000" > $sysfile
echo "1728000 1275000" > $sysfile
echo "1782000 1275000" > $sysfile
echo "1836000 1350000" > $sysfile

---

This guide looks sweet. I saw your post in dsbs kernel thread and I was gonna try it when I got some free time and now I have a guide to help me out

---

Good stuff man
Sent from the Rez

---

Thank you for the script, had just pushed it to my Rez.

---

richii0207 said:
Thank you for the script, had just pushed it to my Rez.
Click to expand...
Click to collapse
Lemme know how it works out.

---

It doesn't look like your script is setting voltages for cpu1 (only cpu0), what am I missing?

---

gr8nole said:
It doesn't look like your script is setting voltages for cpu1 (only cpu0), what am I missing?
Click to expand...
Click to collapse
From what I understand, CPU1 gets reset when it goes offline, so setting any values is almost pointless. :/
Sent from my ADR6425LVW using Tapatalk 2

---

An explanation of I/O Schedulers
An I/O scheduler can use the following techniques to improve performance:
Request merging - The scheduler merges adjacent requests together to reduce disk seeking
Elevator - The scheduler orders requests based on their physical location on the block device, and it basically tries to seek in one direction as much as possible.
Prioritisation - The scheduler has complete control over how it prioritises requests, and can do so in a number of ways
No-op Scheduler:
This scheduler only implements request merging.
Anticipatory:
The anticipatory scheduler is the default scheduler in older 2.6 kernels – if you've not specified one, this is the one that will be loaded. It implements request merging, a one-way elevator, read and write request batching, and attempts some anticipatory reads by holding off a bit after a read batch if it thinks a user is going to ask for more data.
Deadline:
The deadline scheduler implements request merging, a one-way elevator, and imposes a deadline on all operations to prevent resource starvation.
Complete Fair Queueing Scheduler (CFQ):
The complete fair queueing scheduler implements both request merging and the elevator, and attempts to give all users of a particular device the same number of IO requests over a particular time interval. The CFQ scheduler aims to distribute disk time fairly amongst processes competing for access to the disk. In addition, it uses anticipation and deadlines to improve performance, and attempt to bound latency.
Budget Fair Queuing (BFQ):
The Budget Fair Queueing (BFQ) scheduler turns the CFQ Round-Robin scheduling policy of time slices into a fair queueing scheduling of sector budgets.
SIO:
SIO Scheduler is based on the deadline scheduler but it's more like a mix between no-op and deadline.
In other words, SIO is like a lighter version of deadline but it doesn't do any kind of sorting, so it's aimed mainly for random-access devices (like SSD hard disks) where request sorting is no needed (as any sector can be accesed in a constant time, regardless of its physical location).
V(R):
V(R) is similar to, and based on, Linux's deadline I/O scheduler. It implements request deadlines which try to limit starvation, but provide no hard guarantee of request latency. It also merges and batches requests in a similar manner, but unlike deadline, read and write requests are issued together. This means there is no preference to reads over writes. Thus, higher throughput can be achieved at the cost of interactive performance.
credit: EducateandInnovate link: here

---

Great guide thanks