• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root [KERNEL] MiRaGe - for HTC stock ICS ROM - 3.0.101 - 10222013

mrg666

Android Enthusiast
Nov 26, 2011
363
313
There are many kernel options for EVO 3D/V and most of them are excellent. The difference of MiRaGe is, first of all, it is mine and I like to use my kernel :) MiRaGe is a very lean, updated, optimized, overclocking kernel.

I am posting the kernel here so that I can return at least a small part of what I have received from the open source community. I thought the amount of time I have spent for MiRaGe could be useful for others as well. In short, take it if you want it, leave it if you don't. ;) But comments, suggestions are always welcome.

There are several custom ROMs in this forum and they can be incompatible with a different kernel. If you are running a custom ROM please use the kernel that the ROM developer recommends. If you know what you are doing and don't need hand holding, you will do what you want anyway.

Changes
  • separate builds for stock HTC/Sense ICS ROM and AOSP JB ROMs
  • based on the latest HTC official source
  • updated to current Linux 3.0 patch level - some of the most irrelevant commits for shooter board were omitted
  • added cifs, tun modules
  • enabled usb otg and added otg-wakelock
  • enabled autogroup scheduler option in CFS to improve interactive responsiveness
  • compiled with gcc 4.7.4 Linaro toolchain with -O2 optimization
  • CPU clocked at default 1.512 GHz, enabled higher overclock up to 1.7 GHz
  • 3D GPU overclock to 320 MHz, added 160 MHz low frequency to save battery
  • 2D GPU overclock to 266 MHz, added 160 MHz low frequency to save battery
  • smoothed voltage curve to increase stability and added CPU voltage table for user control
  • added 467 MHz bus speed to support 1.6 and 1.7 CPU frequencies
  • decreased the number of frequency steps using 108 MHz steps to increase efficiency of interactive governor
  • enabled cpu stats
  • backported staging/android drivers and updates from Google android-3.0 and 3.4 kernels
  • backported many msm/kgsl (a220) driver updates from CAF msm-3.4 and removed the unnecessary a3xx part of the driver
  • upgraded msm/qdsp6 sound driver to v3 from v2 from CM htc_msm8660 kernel
  • backported many ARM optimizations/updates/fixes from Linux 3.8 and CAF msm kernels
  • backported latest interactive cpu governor from Google android-3.4 kernel, set as default
  • backported ondemand governor from CAF msm-3.4 kernel
  • removed unnecessary cpu governors - governors available: <interactive>, ondemand, performance, powersave
  • backported latest ROW I/O scheduler from CAF msm-3.4 kernel
  • removed unnecessary i/o schedulers - schedulers available: <row>, noop, ondemand
  • backported bcm4329 wifi drivers from CAF msm-3.0 kernel, enabled AP_ONLY for WiFi tethering
  • backported bcmdhd wifi driver from CAF jb_chocolate for JB kernel
  • backported workqueue from Linux 3.6 to enhance the hotplug performance of kernel-based mpdecision
  • backported rwsem from Linux 3.11
  • completely revised kernel-based msm_mpdecision for performance
  • removed kernel debug bits, debugfs for security, and bugverbose for lower memory use
  • switched to simple FIFO net scheduler
  • added patch [v4] binfmt_elf.c: use get_random_int() to fix entropy depleting
  • backported latest Qualcomm Crypto Engine (QCE) from CAF msm-3.4
  • QDSP6V3 Hexagon driver enabled
The details of all changes and source code are available at my Github repo for Sense/ICS and AOSP/JB

Downloads
The GSM version of MiRaGe kernel and related thread is here

Instructions and Recommendations
  • Flash Image GUI must be used when flashing the MiRaGe kernel first time over the stock kernel since any-kernel-updater script will not be able to expand the stock encrypted boot image. If the EVO3D is still S-ON, Flash Image GUI is also recommended for flashing the MiRaGe kernel since Flash Image GUI bypasses S-ON safely and easily.
  • When the kernel package is flashed in the recovery, /system/bin/mpdecision and /system/bin/thermald are deleted since the kernel comes with corresponding kernel-based services. However those two binary files are not deleted by flashing the kernel using Flash Image GUI. So after flashing the MiRaGe kernel for the first time over the stock kernel, either flash the special package above or reflash the kernel in recovery to delete these files separately. This is required only once after the initial MiRaGe kernel upgrade.
  • I have tested the kernel with S-ON stock HBOOT 1.57/1.58 and also S-OFF JBear HBOOT 1.57.5757/1.58.5858/1.50.5050. Because the kernel upgrade package is an any-kernel-updater package (i.e. existing boot image is upgraded with new kernel binary), it should work with all HBOOT versions.
  • Against the widely claimed misconception, there is no need to wipe dalvik-cache with kernel flash. If you still want to wipe it for your superstition, there is no harm either other than wasting your time and wearing off the flash memory :)
  • If you try to flash the kernel in 4ext recovery while you are S-ON and get caught in a boot loop, you can boot into the fastboot (volume-down and power buttons) and recover the boot partition using the following command.
    Code:
    fastboot flash boot boot.img
    You will need your original boot.img saved on your hard drive first. You can find the original boot.img in your original nandroid backup or in the stock-kernel package above if you are using the stock ICS ROM. In any case, please do a nandroid backup before flashing anything. For the boot image in the nandroid backup to work, you should have the same (or compatible) hboot when it was backed up. For example, the boot image that was working with v1.58 hboot will not boot with 1.50 but will boot with 1.57. I will not accept any responsibility with the loss of your phone or its warranty.
  • I use the excellent No-frills CPU Control app for controlling/changing the minimum/maximum frequencies, cpu governor, I/O scheduler and also monitoring the CPU stats. Normally, you don't need this app unless you want to control these settings, overclock, or monitor the CPU stats.
  • Using Kernel Tuner or similar apps is not recommended. I have optimized the kernel and MiRaGe kernel doesn't need any tuning/tweaking. Please don't post about kernel problems without mentioning that you are using kernel tuner.
  • Don't use the JB kernel with stock ICS ROM. Don't report problems to ROM developers without specifying that you use a different kernel with their ROM.

Credits
Thanks to Johnnyslt, Sultanxda (Android1234567), and Bigwillyg for their collaboration and help
Thanks to faux123, showp1984, MikeC84, Agraben, and Coolexe for their earlier development and patches
Special thanks to Koush for any kernel updater and joeykrim for Flash Image GUI
Thanks to LeslieAnn for testing USB OTG
Thanks to howpathetic for testing and help with the GSM build
Thanks to sellers86 for additional testing
Thanks to Christopher83 for the Linaro toolchain packages
And, also thanks to Linux, Google, CAF, CM, HTC developers, and all developers on XDA.

Battery Use and Performance for Reference
Battery life corresponds to light daily use with the original OEM battery and CPU @1.7 GHz overclock
The benchmarks are the best values with CPU @1.7 GHz overclock
0qv4.png
 
How to build

If you are going to distribute your builds, please don't build your binaries with the same name (i.e. MiRaGe) and distribute in this thread. I would recommend you to start an alternative thread. Otherwise the problem reports will be too confusing for everyone.

First requirement is an ARM toolchain for cross compiling, i.e. using an X86 computer to generate ARM binary. I use Linaro tool chain for cross compiling like many others since Linaro specifically develops tool chains that produce optimized code for ARM architecture.

Linaro toolchains can be downloaded from Linaro binary page. The Linaro-12.03-gcc-4.6 toolchain is very stable/reliable and I recommend starting the development with this toolchain. After the kernel build is successfully done and tested, you can switch to later versions. The toolchain can also be built from the source code available at Linaro website. Cristpoher83 distributes binary packages built from source and I use his 4.7.4 package. It is very reliable. I don't use the experimental gcc-4.8 based toolchains (as of July 2013) since they don't build reliable kernels for me yet.

The binary Linaro toolchain package needs to be expanded in a certain directory, probably inside the home directory. The source code for kernel is available in my Github repo, You can either download the kernel source as a compressed package or you can git-clone it with the following command (you will need git installed in your Linux computer)
Code:
git clone https://github.com/mrg666/android_kernel_shooter.git

The kernel source can again be in a specific home directory.

After the source and toolchain are prepared, copy the configuration file for shooter, arch/arm/configs/shooter_config, as .config to the root of the kernel source and use the following command to build the kernel
Code:
make ARCH=arm CROSS_COMPILE=~/android/android-toolchain-eabi_46/bin/arm-linux-gnueabi- zImage modules -j6

Replace j6 in the above command according to the number of cpus you have on your computer.
Also set CROSS_COMPILE based on the directory you have expanded the binary toolchain package in your home directory.

I use Xubuntu 13.04 x64 (currently) on my Linux workstation that has a Phenom II X6 CPU (960T unlocked to 6 cores and overclocked to 3.4 GHz), 8 GB RAM, 500 GB HD. The compile time is about 1m32.824s for me using all 6 cores. I have been using Ubuntu since version 10.04 to build Gingerbread, Jellybean, and Linux kernel and updated the OS to each and every new version, all of them worked just fine. There is no magic version of Ubuntu. The build problems arise from the package requirements not the OS version.

The flash package is easy. Just use what I distribute as a template and replace zImage and modules inside the package with your build.

Now that you have source and can build the kernel, you can add all the features you want to the kernel ;)
 
Upvote 0
Reporting back results. Rom, Harmonia 3.17. Hboot, jbear 1.57.5757. Recovery TWRP 1.1.1. Kernel, butter toasted. Kernel flashed with app FLASH Image GUI as directed. dalvik-cache wiped for superstition. reboot recovery option chosen after flashing. In recovery flashed Mpdecision deleted. no frills CPU control downloaded
and clock set 1.512. Everything is working so far. will report back later on battery life :)
 
Upvote 0
04/19 version had some static in the headphones when touching the screen. 04/23 this noise is gone. Could have been fixed or unrelated to the kernel. It has only been running for about 2 hours so let's see.

That parasitic sound could also be an imperfect ground connection somewhere. My hearing is not that good but I will keep an "ear" on it. Please post if it happens again.
 
Upvote 0
Upvote 0
You can configure Interactive governor to respond like conservative governor. I don't think there is a need for another governor in the kernel. Please check the following reference about the configuration parameters.
http://forum.xda-developers.com/showthread.php?t=1369817

Great idea, but I'm not clear on what values to use...

What I have is:

hispeed_freq = 1188000
go_hispeed_load = 85
above_hispeed_delay - 20000
min_sample_time = 80000
timer_rate = 20000
input_boost = 0
boost = 0

How do I map these knobs to the settings on the page you pointed me at?

"i) For battery:- [Set freq_step to lower value to make conservative governor conserve more battery]


echo "95" > /sys/devices/system/cpu/cpufreq/conservative/up_threshold
echo "120000" > /sys/devices/system/cpu/cpufreq/conservative/sampling_rate
echo "1" > /sys/devices/system/cpu/cpufreq/conservative/sampling_down_factor
echo "40" > /sys/devices/system/cpu/cpufreq/conservative/down_threshold
echo "10" > /sys/devices/system/cpu/cpufreq/conservative/freq_step"

Am I missing something??
 
Upvote 0
Great idea, but I'm not clear on what values to use...

What I have is:

hispeed_freq = 1188000
go_hispeed_load = 85
above_hispeed_delay - 20000
min_sample_time = 80000
timer_rate = 20000
input_boost = 0
boost = 0

How do I map these knobs to the settings on the page you pointed me at?

"i) For battery:- [Set freq_step to lower value to make conservative governor conserve more battery]


echo "95" > /sys/devices/system/cpu/cpufreq/conservative/up_threshold
echo "120000" > /sys/devices/system/cpu/cpufreq/conservative/sampling_rate
echo "1" > /sys/devices/system/cpu/cpufreq/conservative/sampling_down_factor
echo "40" > /sys/devices/system/cpu/cpufreq/conservative/down_threshold
echo "10" > /sys/devices/system/cpu/cpufreq/conservative/freq_step"

Am I missing something??

If I were you, I would leave the interactive governor alone. Tying the processor at lower frequencies like conservative governor do will make the cpu busy for longer periods of time. If you let interactive governor supply the cpu power by quickly raising the frequency, the process will complete sooner and the cpu will go back to lowest frequency as quick as possible. This scenario saves battery too and also improves the responsiveness of the device.

If you still want to tweak interactive to act more conservatively.
- Try increasing the timer_rate which compares with the sampling_rate of the conservative governor.
- Try decreasing the min_sample_time. Interactive governor does not have down_threshold but this is a similar parameter for interactive governor that controls the trigger timer for decreasing the frequency. So decreasing the min_sample_time will decrease the frequency quickly. But remember changing the frequency too frequently can use more battery power.
- Finally, try increasing the go_hispeed_load to 95. That will make the interactive governor spend more time in the lower frequencies like conservative.

I don't understand the coding, but I find the Github logs to be fascinating as it gives me an insight into the development process.

If you keep doing this, you will find yourself developing your own kernel. You've been warned! :)
 
Upvote 0
I have synced with Linux 3.0.75 and the new MiRaGe kernel is available in the OP.

Remember that this build includes several other changes if you have not updated since 3.0.74.
- Default cpu clock reduced to 1.188 GHz, you can overclock up to 1.728 GHz
- Severel video/msm driver updates from CAF kernel
- Slightly lowered cpu voltage profile
- autogroup scheduler and cpufreq fixes

Enjoy!
 
Upvote 0
Flashed the 75 kernel this morning. Nothing has melted down yet.

I noticed a long list of commits on today's github. The ones from Torvalds must be related to the Linux base, but are the others also in that category?

Some of them are unrelated but I still include them for completeness since one of the future commits might rely on them. There are usually 1/5 of the commits that directly compile in our kernel. I even omitted several commits that were completely related to different architectures.

You can see the original commits below.
kernel/git/stable/linux-stable.git - Unnamed repository; edit this file 'description' to name the repository.
 
Upvote 0
Hey mrg666,

Loved MiRaGe when I had the OV. I was a ROM flashing junkie between Jerry Script, Leslie Ann and you at the time.

Quick questions: Is Sweep2Wake implemented in your kernel?
Any plans to bring a MiRaGe ROM to the EVO V?

Thanks for your hard work and contributing to the EVO V!

Thanks for the comments. S2W is not included in the kernel. I am working on an AOSP build but it is not there yet. I will post it later hopefully.
 
Upvote 0

BEST TECH IN 2023

We've been tracking upcoming products and ranking the best tech since 2007. Thanks for trusting our opinion: we get rewarded through affiliate links that earn us a commission and we invite you to learn more about us.

Smartphones