[HTC EVO 3D] habitat22:
Shoot-A-Droid Custom Kernel - "Zoidberg" Version:

***

For ICS Custom Roms with HTC Sense 3.6 / 4.0 / 4.1

***

This is my first Kernel and only for the HTC Evo 3D GSM aka shooteru! Source is from HTC with mods from everywhere.

​

#include
/*
* Your warranty is now likely void.
*
* I am not responsible for bricked devices, dead SD cards,
* spontaneous combustion, or any other host of cosmic penalties
* which may befall you, your family, or your phone. *
*/

Credits & BIG Thanks to:

-Chad Goodman

-bigwillyg

-anryl

-Ryrzy

-And all other kernel devs. Sry if I forgot you.​

What is a Kernel?:

​

Features:

> Compiled with Linaro GCC 4.7.3, -O3 Optimized

> Linux Patched to 3.0.57

> Choose your Kernel Settings with Aroma Installer 2.56

> Available Governors: ondemand, lagfree, intellidemand, interactivex, smartassV2, badass, performance, powersave, interactive, conservative,

> Available Schedulers: deadline, noop, cfq, bfq, vr, sio

> CPU OC up to 1.72GHz (safe OC)

> L2 up to 1.62GHz

> 3D GPU OC up to 320MHz & 2D GPU OC up to 266MHz

> Added Sweep2Wake

> Added Swap and Zram

> Added MPDECISION

> Added THEMAL

> Added Fastcharge

> Added Vsync

> Added USB (OTG)

> Lowered Camera Flash Threshold to 5%

> Lowered WiFi voltage driver & Allow low-wifi-signals

&more​

Changelog:

:

[B][U]SAD ICS Kernel "Zoidberg" v1.3 - 27.12.12 - Linux 3.0.60[/U][/B]
-Back to old FSB
-Patched to Linux 3.0.60

Available CPU Freq.:

Green=Stable , Red=Unstable

[COLOR="Green"]1 - 192MHz
2 - 384MHz
3 - 432MHz
4 - 486MHz
5 - 540MHz
6 - 594MHz
7 - 648MHz
8 - 702MHz
9 - 756MHz
10 - 810MHz
11 - 864MHz
12 - 918MHz
13 - 972MHz
14 - 1026MHz
15 - 1080MHz
16 - 1134MHz
17 - 1188MHz
18 - 1242MHz
19 - 1296MHz
20 - 1350MHz
21 - 1404MHz
22 - 1458MHz
23 - 1512MHz
24 - 1566MHz
25 - 1620MHz
26 - 1674MHz
27 - 1728MHz[/COLOR]

Available GPU Freq.:

2D & 3D

2D - 160
2D - 200
2D - 228
2D - 266

3D - 200
3D - 228
3D - 266
3D - 300
3D - 320

Downloads:

All SAD Files are at habitat22.rullz.us

Used Toolchain: Linaro 4.7.3 Toolchain.zip @ habitat22.rullz.us

SAD ICS "Zoidberg" v1.2 Sourcecode: Sourcecode.zip @ habitat22.rullz.us

"Zoidberg" v1.3 - Linux 3.0.60 - 27.01.13 @ habitat22.rullz.us

​

***

All Settings YOU choose WILL be saved as Default Values

in an init.d script (/system/etc/ini.d/99sad) and in the Kernel.

You can change them with Kernel Tuner. It's recommend to use that app.

***​

Installation:

1. Reboot to Recovery

2. Wipe Cache & Dalvik Cache

3. Install Kernel.zip & Choose your Settings in Aroma Installer

4. Reboot​

Please read the Explanations:​

​

Explanation of Aroma Installer Settings​

1) CPU: MIN CPU CLOCK

Choose the minimal CPU Clock that the CPU can reach. Default value is 384 MHz.

This option will be saved in the Kernel and can be changed via Kernel Tuner.

​

2) CPU: MAX CPU CLOCK

Choose the maximal CPU Clock that the CPU can reach. Default value is 1566 MHz.

This option will be saved in the Kernel and can be changed via Kernel Tuner.

​

3) CPU: MAX SCREEN OFF CLOCK

Choose the maximal CPU Clock that the CPU can reach if the Screen is turned off. Default value is 486 MHz.

This option will be saved in the Kernel and can't be changed via Kernel Tuner.

​

4) GPU: 3D MAX CLOCK

Choose the maximal 3D GPU Clock that the GPU can reach.. Default value is 320 MHz.

This option will be saved in the Kernel and can be changed via Kernel Tuner.

​

5) GPU: 2D MAX CLOCK

Choose the maximal 2D GPU Clock that the GPU can reach.. Default value is 266 MHz.

This option will be saved in the Kernel and can be changed via Kernel Tuner.

​

6) CPU: GOVERNOR

Choose the Default Governor. Default value isn't set, you can choose an option.

This option will be saved in the Kernel and can be changed via Kernel Tuner.

​

7) I/O: SCHEDULER

Choose the Default I/O Scheduler. Default value is noop.

This option will be saved in the Kernel and can be changed via Kernel Tuner.

​

8) SWEEP2WAKE: CONFIG

Choose the Sweep2Wake Config. Default value is "Disabled".

This option will be saved in the Kernel and can be changed via Kernel Tuner.

You can choose between: "Disabled", "Enabled Without Captive Backlight" and "Enabled With Captive Backlight". If you enable Sweep2Wake you can set the "Start and End" Points.​

9) PANEL: VSYNC

Choose the Vsync Config. Default value is "Enabled".

This option will be saved in the 99sad init.d script and can be changed via Kernel Tuner.

You can choose between: "Disabled" and "Enabled".
​

10) CONFIG: MPDECISION

Choose the mpdecision Config. Default value is "Enabled".

This option will be saved in the 99sad init.d script and can be changed via Kernel Tuner.

You can choose between: "Enabled" and "Disabled".
​

Explanation of Kernel Features (Governors, Schedulers, etc.)​

1) Ondemand Governor:

Default governor in almost all stock kernels. One main goal of the ondemand governor is to switch to max frequency as soon as there is a CPU activity detected to ensure the responsiveness of the system. (You can change this behavior using smooth scaling parameters, refer Siyah tweaks at the end of 3rd post.) Effectively, it uses the CPU busy time as the answer to "how critical is performance right now" question. So Ondemand jumps to maximum frequency when CPU is busy and decreases the frequency gradually when CPU is less loaded/apporaching idle. Even though many of us consider this a reliable governor, it falls short on battery saving and performance on default settings. One potential reason for ondemand governor being not very power efficient is that the governor decide the next target frequency by instant requirement during sampling interval. The instant requirement can response quickly to workload change, but it does not usually reflect workload real CPU usage requirement in a small longer time and it possibly causes frequently change between highest and lowest frequency.​

2) Lagfree Governor:

Lagfree is similar to ondemand. Main difference is it's optimization to become more battery friendly. Frequency is gracefully decreased and increased, unlike ondemand which jumps to 100% too often. Lagfree does not skip any frequency step while scaling up or down. Remember that if there's a requirement for sudden burst of power, lagfree can not satisfy that since it has to raise cpu through each higher frequency step from current. Some users report that video playback using lagfree stutters a little.​

3) Intellidemand Governor:

Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. Unlike what some users believe, this governor is not the replacement for OC Daemon (Having different governors for sleep and awake). The original intellidemand behaves differently according to GPU usage. When GPU is really busy (gaming, maps, benchmarking, etc) intellidemand behaves like ondemand. When GPU is 'idling' (or moderately busy), intellidemand limits max frequency to a step depending on frequencies available in your device/kernel for saving battery. This is called browsing mode. We can see some 'traces' of interactive governor here. Frequency scale-up decision is made based on idling time of CPU. Lower idling time (<20%) causes CPU to scale-up from current frequency. Frequency scale-down happens at steps=5% of max frequency. (This parameter is tunable only in conservative, among the popular governors )

To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) behaves like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.​

4) Interactivex:

This is an Interactive governor with a wake profile. More battery friendly than interactive.​

5) SmartassV2 Governor:

Version 2 of the original smartass governor from Erasmux. Another favorite for many a people. The governor aim for an "ideal frequency", and ramp up more aggressively towards this freq and less aggressive after. It uses different ideal frequencies for screen on and screen off, namely awake_ideal_freq and sleep_ideal_freq. This governor scales down CPU very fast (to hit sleep_ideal_freq soon) while screen is off and scales up rapidly to awake_ideal_freq (500 mhz for GS2 by default) when screen is on. There's no upper limit for frequency while screen is off (unlike Smartass). So the entire frequency range is available for the governor to use during screen-on and screen-off state. The motto of this governor is a balance between performance and battery.​

6) Badass Governor:

Badass removes all of this "fast peaking" to the max frequency. On a typical system the cpu won't go above 918Mhz and therefore stay cool and will use less power. To trigger a frequency increase, the system must run a bit @ 918Mhz with high load, then the frequency is bumped to 1188Mhz. If that is still not enough the governor gives you full throttle. (this transition should not take longer than 1-2 seconds, depending on the load your system is experiencing)

Badass will also take the gpu load into consideration. If the gpu is moderately busy it will bypass the above check and clock the cpu with 1188Mhz. If the gpu is crushed under load, badass will lift the restrictions to the cpu.​

7) Performance Governor:

Sets min frequency as max frequency. Use this while benchmarking!​

8) Powersave Governor:

Locks max frequency to min frequency. Can not be used as a screen-on or even screen-off (if scaling min frequency is too low).​

9) Interactive Governor:

Can be considered a faster ondemand. So more snappier, less battery. Interactive is designed for latency-sensitive, interactive workloads. Instead of sampling at every interval like ondemand, it determines how to scale up when CPU comes out of idle. The governor has the following advantages: 1) More consistent ramping, because existing governors do their CPU load sampling in a workqueue context, but interactive governor does this in a timer context, which gives more consistent CPU load sampling. 2) Higher priority for CPU frequency increase, thus giving the remaining tasks the CPU performance benefit, unlike existing governors which schedule ramp-up work to occur after your performance starved tasks have completed. Interactive It's an intelligent Ondemand because of stability optimizations. Why??

Sampling the CPU load every X ms (like Ondemand) can lead to under-powering the CPU for X ms, leading to dropped frames, stuttering UI, etc. Instead of sampling the CPU at a specified rate, the interactive governor will check whether to scale the CPU frequency up soon after coming out of idle. When the CPU comes out of idle, a timer is configured to fire within 1-2 ticks. If the CPU is very busy between exiting idle and when the timer fires, then we assume the CPU is underpowered and ramp to max frequency.​

10) Conservative Governor:

A slower Ondemand which scales up slowly to save battery. The conservative governor is based on the ondemand governor. It functions like the Ondemand governor by dynamically adjusting frequencies based on processor utilization. However, the conservative governor increases and decreases CPU speed more gradually. Simply put, this governor increases the frequency step by step on CPU load and jumps to lowest frequency on CPU idle. Conservative governor aims to dynamically adjust the CPU frequency to current utilization, without jumping to max frequency. The sampling_down_factor value acts as a negative multiplier of sampling_rate to reduce the frequency that the scheduler samples the CPU utilization. For example, if sampling_rate equal to 20,000 and sampling_down_factor is 2, the governor samples the CPU utilization every 40,000 microseconds.​

1) Deadline I/O Scheduler:

Goal is to minimize I/O latency or starvation of a request. The same is achieved by round robin policy to be fair among multiple I/O requests. Five queues are aggressively used to reorder incoming requests.

Advantages:

Nearly a real time scheduler.

Excels in reducing latency of any given single I/O.

Best scheduler for database access and queries.

Bandwidth requirement of a process - what percentage of CPU it needs, is easily calculated.

Like noop, a good scheduler for solid state/flash drives.

Disadvantages:

When system is overloaded, set of processes that may miss deadline is largely unpredictable.

2) Noop I/O Scheduler:

Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.

Advantages:

Serves I/O requests with least number of cpu cycles. (Battery friendly?)

Best for flash drives since there is no seeking penalty.

Good throughput on db systems.

Disadvantages:

Reduction in number of cpu cycles used is proportional to drop in performance.

3) CFQ I/O Scheduler:

Completely Fair Queuing scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. Each per-process queue contains synchronous requests from processes. Time slice allocated for each queue depends on the priority of the 'parent' process. V2 of CFQ has some fixes which solves process' i/o starvation and some small backward seeks in the hope of improving responsiveness.

Advantages:

Considered to deliver a balanced i/o performance.

Easiest to tune.

Excels on multiprocessor systems.

Best database system performance after deadline.

Disadvantages:

Some users report media scanning takes longest to complete using CFQ. This could be because of the property that since the bandwidth is equally distributed to all i/o operations during boot-up, media scanning is not given any special priority.

Jitter (worst-case-delay) exhibited can sometimes be high, because of the number of tasks competing for the disk.

4) BFQ I/O Scheduler:

Instead of time slices allocation by CFQ, BFQ assigns budgets. Disk is granted to an active process until it's budget (number of sectors) expires. BFQ assigns high budgets to non-read tasks. Budget assigned to a process varies over time as a function of it's behavior.

Advantages:

Believed to be very good for usb data transfer rate.

Believed to be the best scheduler for HD video recording and video streaming. (because of less jitter as compared to CFQ and others)

Considered an accurate i/o scheduler.

Achieves about 30% more throughput than CFQ on most workloads.

Disadvantages:

Not the best scheduler for benchmarking.

Higher budget assigned to a process can affect interactivity and increased latency.

5) VR I/O Scheduler:

Unlike other schedulers, synchronous and asynchronous requests are not treated separately, instead a deadline is imposed for fairness. The next request to be served is based on it's distance from last request.

Advantages:

May be best for benchmarking because at the peak of it's 'form' VR performs best.

Disadvantages:

Performance fluctuation results in below-average performance at times.

Least reliable/most unstable.

6) SIO I/O Scheduler:

Simple I/O scheduler aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority quesues concepts, but only basic merging. Sio is a mix between noop & deadline. No reordering or sorting of requests.

Advantages:

Simple, so reliable.

Minimized starvation of requests.

Disadvantages:

Slow random-read speeds on flash drives, compared to other schedulers.

Sequential-read speeds on flash drives also not so good.

1) Vsync:

What is VSync? VSync stands for Vertical Synchronization. The basic idea is that synchronizes your FPS with your monitor's refresh rate. The purpose is to eliminate "tearing". More Info here.​

2) Sweep2Wake:

Check this Video.

Swipe your fingers over the softkeys to wake/sleep the device.​

3) mpdecision:

100% kernel based multi core decision! (should cpu1 be online or not?)

This replaces your /system/bin/mpdecision binary.

Check /sys/kernel/msm_mpdecision/conf/ for the configuration:

startdelay = time until mpdecision starts doing it's magic (70000)

delay = time between checks (500)

pause = if something else plugs in the cpu, fall asleep for 10000

scroff_single_core = if the screen is off, don't plug in cpu1 (1)

nwns_threshold_up = runqueue threshold, if this is reached cpu1 will be hotplugged (35)

nwns_threshold_down = runqueue threshold, if this is reached cpu1 will be unplugged (5)

twts_threshold_up = time threshold, this amount of time must have passed (250)

twts_threshold_down = same as above (250)

enabled = enable(1) or disable(0) mpdecision. This does not affect scroff_single_core!

idle_freq = a value against that will be checked if a core +/- is requested. (486000)

If cpu0 is below that value and a core up of cpu1 is requested, nothing will happen.

If cpu1 is above that value and a core down of cpu1 is requested, nothing will happen. (otherwise it would now put down cpu1 even though it is still working)

4) thermal:

Kernel based 3-phase thermal control!

This replaces your /system/bin/thermald binary.

It will throttle your cpu speed to keep it cool and unleash it if the cpu has cooled down enough. (3 phases: low, mid and high)

Check /sys/kernel/msm_thermal/conf/ for the thermal configuration:

allowed_max_high = highest threshold (phase 3)

allowed_max_low = remove the throttling if we cooled down to this (clr_thrshold)

allowed_max_freq = max frequency if throttled (limit)

[...]mid[...] = same as above, just for phase 2

[...]low[...] = Lowest threshold (phase 1)

check_interval_ms = how often shall we check? (sampling rate)

shutdown_temp = if we reach this shut down the device!

5) Fastcharge:

This allows one to force AC charging for any charger that is detected as USB (e.g. many car chargers) and pull the full current the charger can support. It also provides additional security when connecting to public charging stations because by forcing AC charging, USB/adb data transfers are disabled, protecting your data.​

6) Swap:

Swap is, in short, virtual RAM. With swap, a small portion of the hard drive is set aside and used like RAM. The computer will attempt to keep as much information as possible in RAM until the RAM is full. At that point, the computer will begin moving inactive blocks of memory (called pages) to the hard disk, freeing up RAM for active processes. If one of the pages on the hard disk needs to be accessed again, it will be moved back into RAM, and a different inactive page in RAM will be moved onto the hard disk ('swapped'). The trade off is disks and SD cards are considerably slower than physical RAM, so when something needs to be swapped, there is a noticeable performance hit.

Unlike traditional swap, Android's Memory Manager kills inactive processes to free up memory. Android signals to the process, then the process will usually write out a small bit of specific information about its state (for example, Google Maps may write out the map view coordinates; Browser might write the URL of the page being viewed) and then the process exits. When you next access that application, it is restarted: the application is loaded from storage, and retrieves the state information that it saved when it last closed. In some applications, this makes it seem as if the application never closed at all. This is not much different from traditional swap, except that Android apps are specially programed to write out very specific information, making Android's Memory Manager more efficient that swap.

This question is hotly debated, but you almost definitely do not need swap. The only exception to this may be if the device is a first generation device (i.e. HTC Dream or HTC Magic).

Swap can give more available memory, however, class 6 SD cards are recommended and SD write wear is increased.

Actual performance depends on user memory use; you'll only see a benefit if you're consistently using up all available memory, due to any combination of inherently low device RAM, using multiple apps simultaneously, or a singularly memory-intensive app. Otherwise, the performance hit will exceed any performance gain.​

7) zRam:

zRam is an experimental (staging) module of the Linux kernel. It was previously called "compcache". zRam increases performance by avoiding paging on disk and instead uses a compressed block device in RAM in which paging takes place until it is necessary to use the swap space on the hard disk drive. Since using RAM is faster than using disks, zRam allows Linux to make more use of RAM when swapping/paging is required, especially on older computers with less RAM installed.

Even though the cost of RAM hardware is relatively low this feature still offers advantages for netbooks and other lower-powered laptops, virtualization and in the case of embedded devices, especially those that use flash memories that have a limited lifespan, dependent on write-use and thus wear out quickly when used as a swap device. More Info here.​

8) USB OTG:

USB On-The-Go, often abbreviated USB OTG, is a specification that allows USB devices such as digital audio players or mobile phones to act as a host, allowing other USB devices like a USB flash drive, mouse, or keyboard to be attached to them. Unlike conventional USB systems, USB OTG systems can drop the hosting role and act as normal USB devices when attached to another host. This can be used to allow a mobile phone to act as host for a flash drive and read its contents, downloading music for instance, but then act as a flash drive when plugged into a host computer and allow the host to read off the new content. More Info here.​

Kernel was tested on:

> SAD ICS Sense 4.1​

Benchmarks:

​

​

***

Want to compile your own Kernel?

(I'm using Ubuntu 12.04)

***​

1. Install required packages:

​

git-core gnupg flex bison gperf libsdl-dev libesd0-dev libwxgtk2.6-dev build-essential zip curl libncurses5-dev zlib1g-dev

add-apt-repository "deb http://archive.canonical.com/ maverick partner"
sudo apt-get update
sudo apt-get install sun-java6-jre sun-java6-plugin sun-java6-jdk

upon success do:
sudo apt-get purge openjdk

if it fails, do:
sudo apt-add-repository ppa:flexiondotorg/java
sudo apt-get update
sudo apt-get install sun-java6-jre sun-java6-plugin sun-java6-jdk
or
sudo add-apt-repository ppa:ferramroberto/java
sudo apt-get update
sudo apt-get install sun-java6-jre sun-java6-plugin sun-java6-jdk

2. Setup Kernel Source and Toolchain:

< Create a folder called "toolchain" (~/toolchain) and extract the toolchain (~/toolchain/android-toolchain-eabi) in it.

< Create a folder called "kernelsource" (~/kernelsource) and extract the sourcecode (~/kernelsource/sourcecode) in it.​

3. Making changes on the sourcecode

Please search the forum!​

4. Compiling the sourcecode

< Open a terminal

< Type " cd ~/kernelsource/sourcecode "

< Type " export ARCH=arm "

< Type " export CROSS_COMPILE=~/toolchain/android-toolchain-eabi/bin/arm-eabi- "

< Type " make shooter_u_defconfig " (or any xxxx_defconfig you need)

< Type " make "
​

4. Installing the Kernel

< After compiling the kernel, it will tell you where to get all the files

< Grab all files and replace them in the SAD_Zoidberg-vx.x_x.x.xx.zip

< Flash the .zip file in recovery​