Android Development Archive

Mecha GB Kernel (5 Nov 2011)

Posted November 11, 2011 By Ziggy471

Alright, actually had this in testing for a few days now, meant to already release it, but have been sleeping more than anything recently, got rear-ended the other day, and doc put me on Flexeril 3-times a day.  :(


Added smartassV2




Click here to download

2 Comments so far. Join the Conversation

Mecha GB Kernel (29 Oct 2011)

Posted October 29, 2011 By Ziggy471

Ziggy471’s MECHA GB Sense Kernel


I’m not responsible for you blowing up your phone or you loosing your job/wife/dog/truck/car/hair/mind/sleep.

Changelog (29 Oct 11):

2.6.38 Automatic process group scheduling
lagfree governor with a fully working sysf interface
Backported ck3
BCM Bluetooth Low Power Mode
Almost all debugging and tracing turned off
User changeable frequency table
Implement vdd sysfs interface
Over/Under clocked



Download links:

Source Code

2 Comments so far. Join the Conversation

New kernels coming today

Posted October 29, 2011 By Ziggy471

I’m getting ready to release both ThunderBolt and 3D kernels tonight.

Source is also ready to go live, only thing I’m waiting on right now is some testing during the day.

So stay tuned.

EDIT: I also have Evo-4G ready to go too.


2 Comments so far. Join the Conversation

Beta Kernels 10 Apr 11

Posted April 10, 2011 By Ziggy471

Alright, did a lot of work this morning, so I decided to get something released tonight. This will probably be my last release for the time being, I have other things I need to get done.

Lowered Wi-Fi voltages
cpufreq interactive governor: fix crash on CPU shutdown

Fixed the sysfs interface for VDD, forgot one line when I changed freq_table to dynamic
Have not found the issue with the Prox Sensor yet
Have the HAVS code in there, but get non-booters as of right now, still working on it

Updated to mainline

Added kernel support for HDMwIn

If you’re having issues with random reboots on BRAVO/EVO/INC, disable 128MHz, it appears that not every phone can handle it correctly. For those on the MECHA, I’m attaching an init script that I’m using to lower voltages, it’s saving quite a bit of power. Place it in /system/etc/init.d, and make sure it’s set executable. Also, if you notice, it’s already setup for HAVS, so as soon as I get that working, it can still be used.

Ztest-BRAVO-BFS-041011 (344)
Ztest-BRAVO-BFS-HAVS-041011 (219)
Ztest-BRAVO-CFS-041011 (215)
Ztest-BRAVO-CFS-HAVS-041011 (230)
Ztest-EVO-BFS-041011 (368)
Ztest-EVO-BFS-HAVS-041011 (362)
Ztest-EVO-CFS-041011 (308)
Ztest-EVO-CFS-HAVS-041011 (760)
Ztest-INC-BFS-041011 (291)
Ztest-INC-BFS-HAVS-041011 (825)
Ztest-INC-CFS-041011 (203)
Ztest-INC-CFS-HAVS-041011 (294)
Ztest-MECHA-BFS-041011-0922-test (402)
Ztest-MECHA-CFS-041011-0922-test (291)
MECHA vdd init script (1064)


37 Comments so far. Join the Conversation

Since I keep getting asked how to use the sysfs interfaces I have built into my kernel, I decided to do post on just those items. If you would like a more detailed explanation of sysfs, refer to

I’ve done a write-up on the VDD, smartass, and cpufreq sysfs interfaces. I also included a brief how-to for creating init scripts to make these changes on boot. All of these examples can be done via an adb shell. I’ve been using a ‘Nix of some kind since the early 90’s, so I’m very comfortable in a command line only enviroment. I still recommend trying these commands from the command line first, it’s how I test overclocking and undervolting, that way if something does not work, and the phone reboots, everything goes back to how it was.

Also, if there are any Android Java developers that would like to make an app automate these tasks for the standard users, I’d be more than willing to help with that. I’m no longer a Java developer, and have no intention of touching it again, I learned to hate it in the late 90’s on Sun Sparc’s and have no desire to go back. I’ll always be more comfortable in plain old C or maybe perl, you have to love a language that allows you to do this:
printf $a > $b ? “True” : “False”;

VDD sysfs usage:

The sysfs VDD interface for Static Voltage Scaling, SVS, uses /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels. The sysfs VDD interface for Hybrid Adaptive Voltage Scaling, HAVS, uses /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs. The first was implemented by sqn in his original patch, however the second was implement by myself so that I could have HAVS and a sysfs interface for VDD levels. Both files are similar in usage and function, below are examples of each.

To list the current values:

cat /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
cat /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs

To change ALL voltages either up (+) or down (-), must be increments of 25mV:

echo "+25" > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo "+25" > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs
echo "-25" > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo "-25" > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs

To change just one frequency, you specify the frequency and the voltage, or for HAVS, the frequency and the voltage range:

echo "998400 1100" > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels
echo "998400 1050 1100" > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels_havs

Smartass sysfs usage:

The original smartass patch that I found did not have a working sysfs interface, there were slight issues with it, so I decided to fix it, since it’s very useful to have. All smartass control files are located at /sys/devices/system/cpu/cpu0/cpufreq/smartass.

The following is a list of each file, and it’s description:

The minimum amount of time to spend at a frequency before we can ramp down, default is 45ms.

When ramping up frequency with no idle cycles jump to at least this frequency. Zero disables. Set a very high value to jump to policy max freqeuncy.

When sleep_max_freq>0 the frequency when suspended will be capped by this frequency. Also will wake up at max frequency of policy to minimize wakeup issues.

The frequency to set when waking up from sleep. When sleep_max_freq=0 this will have no effect.

Sampling rate, I highly recommend to leave it at 2.

Freqeuncy delta when ramping up. Zero disables causes to always jump straight to max frequency.

Max freqeuncy delta when ramping down. zero disables.

CPU freq will be increased if measured load > max_cpu_load.

CPU freq will be decreased if measured load < min_cpu_load.

Current smartass defaults set in my kernels:


To read the current values (max_cpu_load as an example):

cat /sys/devices/system/cpu/cpu0/cpufreq/smartass/max_cpu_load

To set the current values (max_cpu_load as an example):

echo "80" > /sys/devices/system/cpu/cpu0/cpufreq/smartass/max_cpu_load

Controlling the current cpufreq policy, i.e., How to Over/Under clock without SetCPU:

There are also control files associated with the CPU frequency, cpufreq, driver located at /sys/devices/system/cpu/cpu0/cpufreq.

The following is a list of the important files and their descriptions:

scaling_available_frequencies (Read-Only)
Lists all available frequencies that the processor is programmed to handle. This doesn’t mean that all will work, just that it’s possible to tell the processor to attempt to use them.

scaling_available_governors (Read-Only)
Lists all available governors available for usage.

scaling_cur_freq (Read-Only)
Lists the current operating frequency of the processor.

scaling_governor (Read-Write)
Gets/Sets the currently used governor.

Gets/Sets the maximum allowed frequency for the current policy, refer to scaling_available_governors for valid frequencies.

Gets/Sets the minimum allowed frequency for the current policy, refer to scaling_available_governors for valid frequencies.

To read the currently available frequencies:

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors

To set the current governor to smartass:

echo "smartass" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

To change the maximum frequency:

echo "1536000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

How to make the settings take effect after a reboot:

The problem with using the sysfs interface for the preding is that it is only current as long as you do not reboot the device. This is a good thing if your attempting to overclock your device, and it locks up, as soon as it reboots, it goes back to the defaults until something tells it differently. In order to make these changes take effect after a reboot, you need to use an init script. If your current ROM has run-parts enabled, which I believe most do anymore, then the following will work. You also need to make sure that the init scripts that you put under /system/etc/init.d are executable, i.e., chmod 755 filename. Also, in order to save these files to /system/etc/init.d, /system needs to be mounted as read-write.

The following example init script is for undervolting the lowest frequency on a ThunderBolt with SVS, others are similar. This file needs to be located in /system/etc/init.d. Example filename would be 99vddlevels.

echo "245760 850" > /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels

The following example would set the policies maximum frequency to 1.536GHz. Again, this file needs to be located in /system/etc/init.d, and for this example, is named 99overclock.

echo "1536000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

Now for some fun stuff. If you would like to setup an init script to allow you to change the policy while the screen is on or off, there are a couple other sysfs files that are going to be of interest you. Those two files are /sys/power/wait_for_fb_wake and /sys/power/wait_for_fb_sleep. These are considered blocking files, in other words, if you attempt to cat the file, display it’s contents, it will not display until a condition is reached. The condition for wait_for_fb_wake, you guessed it, the screen wakes up. When the screen wakes up, cat /sys/power/wait_for_fb_wake will return awake. Same holds true for wait_for_fb_sleep, when the screen turns off, it returns sleeping. Knowing this will now allow us to create a script to deal with different states of the screen.

The following script will change the governor, minimum and maximum frequencies. When this script launches via run-parts, it will remain running until it is either killed or the device reboots. Note, if you decide to change the values after using the script for at least one boot, make sure to reboot for the changes to take effect, either that or kill off the process and restart it.




(while [ 1 ]
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
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
done &)
14 Comments so far. Join the Conversation

Beta MECHA Kernel 6 Apr 11

Posted April 6, 2011 By Ziggy471

I guess something got messed up in the release on 4 Apr, the proximity sensor wasn’t working correctly. I had just re-done my entire source tree, I decided to rebase so that I could move an older patch forward, and wasn’t paying attention to what I was doing, so I messed things up. No big deal really, just started from scratch again, and re-applied the patches.

I wasn’t planning on releasing anything until I finished re-writing acpuclock-7×30.c, which I started on yesterday. There’s really no change you will see, everything that’s done is mostly transparent to the end user. What I’ve done so far is to get rid of the damn hard-coded freq_table, and create it dynamically from the acpu_freq_tbl, just like it’s done in acpuclock-scorpion.c. If you’re not a kernel dev, don’t worry, it works. lol

Enough rambling, on to the good stuff……

Started rewrite on acpuclock-7×30, now dynamic freq_table
Enabled 2.03GHz, remember, you guys asked for it 😉
Proximity sensor appears to be working better, still need to do more with it.


Beta Kernel MECHA CFS 6 Apr 11 (695)
Beta Kernel MECHA BFS 6 Apr 11 (2670)

To Do List:
Finish re-writing acpuclock-7×30
Implement HAVS
Re-do the voltage table, I think there’s even better battery life to be obtained.
Even more, to include requests from you guys

Changes so far:
Just in case you guys are curious, here’s how many changes I’ve done from the original HTC source:
Lines added: +30179
Lines subtracted: -12130

And here’s the command I use to do that:
git log –numstat –pretty=”%H” 08683a509c588c050fc6de93ed7bbdadc0b719a9..| awk ‘NF==3 {plus+=$1; minus+=$2} END {printf(“+%d, -%dn”, plus, minus)}’

08683a509c588c050fc6de93ed7bbdadc0b719a9 is the sha for the initial commit, I got that by running git rev-list –all –pretty.

26 Comments so far. Join the Conversation

Beta MECHA Kernel 4 Apr 11

Posted April 4, 2011 By Ziggy471

Alright, been a little busy working on the kernel for the ThunbderBolt recently. It’s getting closer to being integrated with Frankenstine, EVO/INC/BRAVO. However, since I needed to do some upgrades to the base before moving it in with the others, I decided to release some interim builds.

Updated base to
Added BFS version 363
Tweaked Smartass slightly
Opened up the top end to 1.8GHz, a couple are stable there, but I need a bigger test group
Upped the max voltage slightly, I think all the higher frequencies need is a little more cowbell

Since some of you live and breath by Quaddrant scores, here’s my results.
ROM: Das BAMF 1.3.2
Kernel: 040411 BFS
Speed: 1.8 GHz
Governor: Performance
Provided By: imneveral0ne

ROM: Das BAMF 1.2
Kernel: 040411 BFS
Speed: 1.536GHz
Governor: Smartass
Provided By: Ziggy471



Beta Kernel MECHA BFS 4 Apr 11 (577)
Beta Kernel MECHA CFS 4 Apr 11 (352)

27 Comments so far. Join the Conversation

Alpha – Almost Beta ThunderBolt Kernel 2 Apr 11

Posted April 2, 2011 By Ziggy471

Alright, decided to get a ThunderBolt on Wednesday, wanted to be grandfathered into the unlimited data plan. So I decided to put together a kernel for my newly rooted phone.

Don’t worry, I still plan to work on the Frankenstine releases, EVO/INC/BRAVO. Eventually, I will get Mecha integrated into the same tree, it’ll make my life so much easier.

Features: HTC Mecha source, sorry had issues patching up to the latest.
Smartass Governor with working sysfs interface, 245 MHz screen off
Interactive Governor
Conservative Governor tweaked
Patched the source as close to the mainline as possible
sysfs VDD interface
Undervolted, just slightly, still need more testing for better values
OverClocked to 1.72GHz, default speed 245MHz-1.22GHz
aic3254 tweaks, i.e., better battery life
Most debugging and tracing turned off



Alpha/Beta Kernel MECHA 2 Apr 11 (292)

3 Comments so far. Join the Conversation

Beta Kernel 18 Mar 11

Posted March 19, 2011 By Ziggy471

I decided to update the kernels to the latest mainline kernel version. So far it’s running good on mine and others, not really that big of a change, but I didn’t want to fall behind again. I planned on posting this earlier, but since I’m in Colorado right now, it’s still before midnight. lol

Updated to




Beta Kernel BRAVO BFS 18 Mar 11 (173)
Beta Kernel BRAVO BFS HAVS 18 Mar 11 (110)
Beta Kernel BRAVO CFS 18 Mar 11 (97)
Beta Kernel BRAVO CFS HAVS 18 Mar 11 (88)
Beta Kernel EVO BFS 18 Mar 11 (257)
Beta Kernel EVO BFS HAVS 18 Mar 11 (349)
Beta Kernel EVO CFS 18 Mar 11 (282)
Beta Kernel EVO CFS HAVS 18 Mar 11 (577)
Beta Kernel INC BFS 18 Mar 11 (258)
Beta Kernel INC BFS HAVS 18 Mar 11 (545)
Beta Kernel INC CFS 18 Mar 11 (158)
Beta Kernel INC CFS HAVS 18 Mar 11 (262)

32 Comments so far. Join the Conversation

Beta Kernel 12 Mar 11

Posted March 12, 2011 By Ziggy471

As promised, here’s a newer kernel for all to test. During the private beta, we’ve had a couple of random reboots and a couple lock ups, but nothing else major.


Updated to

Doesn’t sound like much, but that includes 408 commits of bugfixes and improvements to the mainline kernel


sysfs VDD changes take effect immediately on SVS now
Wifi driver updated slightly from newer HTC sources



Beta Kernel BRAVO BFS 12 Mar 11 (104)
Beta Kernel BRAVO BFS HAVS 12 Mar 11 (66)
Beta Kernel BRAVO CFS 12 Mar 11 (73)
Beta Kernel BRAVO CFS HAVS 12 Mar 11 (74)
Beta Kernel EVO BFS 12 Mar 11 (165)
Beta Kernel EVO BFS HAVS 12 Mar 11 (164)
Beta Kernel EVO CFS 12 Mar 11 (254)
Beta Kernel EVO CFS HAVS 12 Mar 11 (410)
Beta Kernel INC BFS 12 Mar 11 (164)
Beta Kernel INC BFS HAVS 12 Mar 11 (358)
Beta Kernel INC CFS 12 Mar 11 (108)
Beta Kernel INC CFS HAVS 12 Mar 11 (188)

21 Comments so far. Join the Conversation