Archive for April, 2011

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.

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

MECHA:
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

BRAVO/EVO/INC:
Updated to 2.6.32.36 mainline

EVO:
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.

Downloads:
Ztest-BRAVO-BFS-041011 (794 downloads)
Ztest-BRAVO-BFS-HAVS-041011 (655 downloads)
Ztest-BRAVO-CFS-041011 (668 downloads)
Ztest-BRAVO-CFS-HAVS-041011 (683 downloads)
Ztest-EVO-BFS-041011 (825 downloads)
Ztest-EVO-BFS-HAVS-041011 (677 downloads)
Ztest-EVO-CFS-041011 (643 downloads)
Ztest-EVO-CFS-HAVS-041011 (1097 downloads)
Ztest-INC-BFS-041011 (618 downloads)
Ztest-INC-BFS-HAVS-041011 (1170 downloads)
Ztest-INC-CFS-041011 (536 downloads)
Ztest-INC-CFS-HAVS-041011 (639 downloads)
Ztest-MECHA-BFS-041011-0922-test (744 downloads)
Ztest-MECHA-CFS-041011-0922-test (641 downloads)
MECHA vdd init script (1639 downloads)

md5sums:

d576e90e811438c3e8a2f461f5becbd2  ztest-MECHA-BFS-041011-0922-test.zip
459553fbc5467403bea89581711d39de  ztest-MECHA-CFS-041011-0922-test.zip
56c49f717d425502cd10492f40392314  ztest-BRAVO-BFS-041011.zip
ff007e9b8d5ab4c0e0dd33c7c9fca608  ztest-BRAVO-BFS-HAVS-041011.zip
71f6dba763e969ac70b6bcb62e519e44  ztest-BRAVO-CFS-041011.zip
75a8fccfca83e8d66bbac4ee898cebde  ztest-BRAVO-CFS-HAVS-041011.zip
36a6d03f308f550630cf33f989b478c5  ztest-EVO-BFS-041011.zip
f583c809ab84a6e01efe3fb42fe26ae2  ztest-EVO-BFS-HAVS-041011.zip
81c71441ab40e8453295083e4150b2bf  ztest-EVO-CFS-041011.zip
edd70bc3b9cedfda552db97f703409ce  ztest-EVO-CFS-HAVS-041011.zip
857c67f741f7b236efe884d8f302651b  ztest-INC-BFS-041011.zip
4a22cf01db96b41d667429ecc7f2eb9f  ztest-INC-BFS-HAVS-041011.zip
56dd4917eb1e7008b71038a36460fa71  ztest-INC-CFS-041011.zip
2e9ca67beb5aa74de3e2bba541d6aaef  ztest-INC-CFS-HAVS-041011.zip
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 http://en.wikipedia.org/wiki/Sysfs.

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:

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

up_min_freq
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.

sleep_max_freq
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.

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

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

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

max_ramp_down
Max freqeuncy delta when ramping down. zero disables.

max_cpu_load
CPU freq will be increased if measured load > max_cpu_load.

min_cpu_load
CPU freq will be decreased if measured load < min_cpu_load.

Current smartass defaults set in my kernels:

down_rate_us=20
max_cpu_load=75
max_ramp_down=38400
min_cpu_load=50
ramp_up_step=38400
sample_rate_jiffies=2
sleep_max=245760
sleep_wakeup_freq=998400
up_min_freq=9999999

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.

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

scaling_min_freq
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.

#!/system/bin/sh
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.

#!/system/bin/sh
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.

#!/system/bin/bash

AWAKE_GOVERNOR="performance"
AWAKE_GOVERNOR_FREQENCY_MAX="1536000"
AWAKE_GOVERNOR_FREQENCY_MIN="245760"

SLEEP_GOVERNOR="ondemand"
SLEEP_GOVERNOR_FREQENCY_MAX="368640"
SLEEP_GOVERNOR_FREQENCY_MIN="245760"

(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
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
SLEEPING=
fi
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……

Changelog:
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.

md5sums:
10f9ac880fe3ddb6c21a564c4380a4c3 ztest-MECHA-BFS-040611-1739-test.zip
cb47f08bf9515282d356e517ee2bdf4d ztest-MECHA-CFS-040611-1739-test.zip

Downloads:
Beta Kernel MECHA CFS 6 Apr 11 (1046 downloads)
Beta Kernel MECHA BFS 6 Apr 11 (3005 downloads)

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.

Changelog:
Updated base to 2.6.32.36
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

Performance:
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



md5sum:
35ab045e291c4a69cfdc8a53620ace3e ztest-MECHA-BFS-040411-1420-test.zip
7d001b5abfde4496f183d3bea44ef026 ztest-MECHA-CFS-040411-1420-test.zip

Downloads:

Beta Kernel MECHA BFS 4 Apr 11 (899 downloads)
Beta Kernel MECHA CFS 4 Apr 11 (693 downloads)

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:
2.6.32.21 HTC Mecha source, sorry had issues patching up to the latest.
CIFS
EXT4
TUN
Smartass Governor with working sysfs interface, 245 MHz screen off
Interactive Governor
Conservative Governor tweaked
Patched the source as close to the mainline 2.6.32.21 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

md5sum:
391b73be47c1e2b224505ad3c67f1eaa ztest-MECHA-040211-0751-test.zip

NOTE: THIS IS AN UPDATE.zip file, DO NOT JUST FLASH THE boot.img.

Download:
Alpha/Beta Kernel MECHA 2 Apr 11 (626 downloads)

3 Comments so far. Join the Conversation