[KERNEL] MiRaGe - for Nexus 4 stock ROM 10/25/15

Search This thread

mrg666

Senior Member
Aug 4, 2011
1,966
4,784
no problem, guess my phrasing wasn't right or I translated wrong (english is not my mother tongue)...i was wondering that it didn't work but as you said it is only for stock rom i understood it can't work on other roms :good:

Okay, then. But you should be careful with using that "sarcastic roll eyes" smiley. It means the same in every language ;)

Regarding the incompatibility, it is probably due to different API's of user space libraries of the ROM. Even the two versions of stock AOSP ROM requires two different kernels (JSS and JWR). There is no universal compatibility of kernel across different ROMs, unfortunately. As I said in the OP, I use the stock ROM and develop the kernel for it. I am not really interested in having the most popular kernel around here, just sharing what I build for myself.

Peace! :)
 

mrg666

Senior Member
Aug 4, 2011
1,966
4,784
I have updated the MiRaGe kernel with the following changes
- enabled Qualcomm Crypto Acceleretor and updated from CAF msm-3.4
- updated Qualcomm HW RNG driver from CAF msm-3.4
- enabled BPF JIT compiler for packet filters
- applied glibc patch to improve the performance of memcpy and memmove
- applied word-at-a-time ARM API patches

Please see the details of the changes in my repo.

My initial testing was completely stable. Please let me know your experience.

Enjoy!
 

apatal

Senior Member
Feb 27, 2012
3,576
2,066
Manila
There are many kernel options for Nexus 4. The difference of MiRaGe is, first of all, it is mine and I like to use my kernel. I wanted MiRaGe to be a very lean, optimized kernel. So my changes, additions are mainly updates and optimizations; my goal is to improve the stock Nexus 4 ROM.
Sounds promising. I'll try it out and let you know what I think. Thanks for sharing your work. :)
 
  • Like
Reactions: mrg666

mrg666

Senior Member
Aug 4, 2011
1,966
4,784
I have updated today's builds to include a patch for the interactive governor that will hopefully eliminate a seemingly harmless kernel warning. Please update if you have already downloaded today's build. Sorry for the double post today. I will keep quiet for a while.
 

fabian.m

Senior Member
Mar 25, 2013
325
130
Using your kernel since yesterday with a clean aosp build and it's flying. Thank you very much.

Sent from my Nexus 4 using xda app-developers app
 
  • Like
Reactions: mrg666

nedooo

Senior Member
Dec 26, 2010
1,785
377
Sarajevo
It's clear that this kernel is your build for your own use and it's great you are sharing it here.
Errr...one or two things may I ask?
Will you ever consider to implement gama control and 450 MHz gpu OC?
 
Last edited:

nibla101

Senior Member
May 5, 2011
247
141
29
Västerås
I understand you don't want to add unnecessary stuffs to your kernel, but please consider faux sound or some sort of sound control, the stock volume is painfully low when listening to music with headphones. :fingers-crossed:
 

mrg666

Senior Member
Aug 4, 2011
1,966
4,784
Thank you for the suggestions, guys. I will start with adding the sound patches. Let's test the recent set of changes for a couple of days first. Then, I want to clean up the warning messages in the kernel log given by WARN_ON(timekeeping_suspended); in timekeeper.c. I will add the sound patches soon after that.

I have done overclocking with all of my other kernel projects but N4's quad-core processor warms up really too quickly and it is already more than powerful enough. I am not sure if overclocking is really necessary. I might just add it for completeness.

I am not sure how Gamma control could be useful for N4. The colors on the LCD screen are very natural to me and the stock ROM has no Gamma control. If N4 had an AMOLED display with oversaturated colors (like SGS3), I would have considered it however.
 

DrummerMuppet

Senior Member
Jan 3, 2012
652
534
Caracas
Google Pixel 2
OCing on a quad-core device doesn't make much sense to me - the N4 is quite powerful already without it, IMHO.

If I may say, please keep your kernel as close to stock as possible. Simple is good too, and there are plenty of other choices for people who need more features.

Thank you for your work!
 

alen1901

Senior Member
Jan 29, 2011
5,800
7,215
Yeah, dont bloat your kernel. Ok, sound patches are good for many people listening the music but if it affects performance or stability, its not worth it. Also, gpu oc is really not needed on this phone, its powerfull enough for at least 2 more years with its specs. Also if you add oc step, it would replace stock 400mhz which is crazy, and if you add one more step in gpu freqs, its more codes and goes away from simple and clean. My opinion. :)
 
  • Like
Reactions: Maelstr0m

mrg666

Senior Member
Aug 4, 2011
1,966
4,784
Yeah, dont bloat your kernel. Ok, sound patches are good for many people listening the music but if it affects performance or stability, its not worth it. Also, gpu oc is really not needed on this phone, its powerfull enough for at least 2 more years with its specs. Also if you add oc step, it would replace stock 400mhz which is crazy, and if you add one more step in gpu freqs, its more codes and goes away from simple and clean. My opinion. :)

It seems we agree about overclocking. And, don't worry, I will not bloat the kernel.
 

mrg666

Senior Member
Aug 4, 2011
1,966
4,784
I have uploaded another build.

- fixed the warning messages in the kernel log
* Revert "msm: cpufreq: boost freq of online cpu(s) to max on resume"
- ARM: hw_breakpoint: enable HAVE_HW_BREAKPOINT feature flag

My suggestion is to wait for the kitkat update after this build.

Cheers!

Edit: On a second thought, I added QSEECOM back to test its removal a little longer before making it public.
 
Last edited:

zwodziarz

Member
Apr 6, 2011
49
9
32
Kielce
I have uploaded another build.

- fixed the warning messages in the kernel log
* Revert "msm: cpufreq: boost freq of online cpu(s) to max on resume"
- ARM: hw_breakpoint: enable HAVE_HW_BREAKPOINT feature flag

My suggestion is to wait for the kitkat update after this build.

Cheers!

Edit: On a second thought, I added QSEECOM back to test its removal a little longer before making it public.

Hey, I don't know what will KitKat bring but I want to ask: Is there any option U'll add a red LED on charging and a green LED as the battery is full feature? Cause I was on Semaphore and have it configured that way, although the kernel was making my device coming to an "X" load screen from time to time(stock rom) and I came to this thread found Your kernel works really nice, the overheating is practically gone(that's the main reason i unlocked the bootloader and flashed a kernel) battery life's decent(although not as good as on Semaphore) really appreciate Your work!
Have a question: Previously my first custom kernel was Linaro 4.8.2(NEO 15) then this Semaphore one. On the first one I got crashes all the time phone was rebooting etc. Some say it was this colorfix issue I haven't found it and flashed Semaphore then got this X screens lags - I flashed Your kernel. As You said that every module is enclosed in kernel, do I need to wipe anything now so the kernel works like it should work? Sorry for interrupting I'm a bit noobish just want my phone to perform like it should ;)
 
Last edited:

mrg666

Senior Member
Aug 4, 2011
1,966
4,784
Hey, I don't know what will KitKat bring but I want to ask: Is there any option U'll add a red LED on charging and a green LED as the battery is full feature? Cause I was on Semaphore and have it configured that way, although the kernel was making my device coming to an "X" load screen from time to time(stock rom) and I came to this thread found Your kernel works really nice, the overheating is practically gone(that's the main reason i unlocked the bootloader and flashed a kernel) battery life's decent(although not as good as on Semaphore) really appreciate Your work!
Have a question: Previously my first custom kernel was Linaro 4.8.2(NEO 15) then this Semaphore one. On the first one I got crashes all the time phone was rebooting etc. Some say it was this colorfix issue I haven't found it and flashed Semaphore then got this X screens lags - I flashed Your kernel. As You said that every module is enclosed in kernel, do I need to wipe anything now so the kernel works like it should work? Sorry for interrupting I'm a bit noobish just want my phone to perform like it should ;)

You don't need to wipe anything, the modules left by the other kernels will not be any problem. But if the system was modified in other ways, there can be problems.

It is odd to hear that your battery life was better when the phone was heating more. It is usually the other way around. Give it some more time to see the battery life.

I am not sure about the led mods. That is such an insignificant feature for hacking the kernel. As I stated in the op, I normally don't add new features without a very good reason.

Sent from my Nexus 4 using Tapatalk
 
  • Like
Reactions: zwodziarz

zwodziarz

Member
Apr 6, 2011
49
9
32
Kielce
You don't need to wipe anything, the modules left by the other kernels will not be any problem. But if the system was modified in other ways, there can be problems.

It is odd to hear that your battery life was better when the phone was heating more. It is usually the other way around. Give it some more time to see the battery life.

I am not sure about the led mods. That is such an insignificant feature for hacking the kernel. As I stated in the op, I normally don't add new features without a very good reason.

Sent from my Nexus 4 using Tapatalk

Yea but Semaphore solved the overheating a bit, although while I was using GPS it heated up a little. But for example it lasted longer while listening to music - I listened for 30minutes and battery dropped only 2%. On Your kernel (18/10 ver) today I've been using Chrome for about 3hours on HSDPA - the battery dropped to 50%. Rom stock, interactive/noop 384/1512mhz
 

mrg666

Senior Member
Aug 4, 2011
1,966
4,784
Yea but Semaphore solved the overheating a bit, although while I was using GPS it heated up a little. But for example it lasted longer while listening to music - I listened for 30minutes and battery dropped only 2%. On Your kernel (18/10 ver) today I've been using Chrome for about 3hours on HSDPA - the battery dropped to 50%. Rom stock, interactive/noop 384/1512mhz

Thanks for the report. When it comes to battery reports, I learned in the past years of developing kernels that they are always very inconsistent. I do my best to optimize and then it is what it is. So I can't help much with that.
 
  • Like
Reactions: zwodziarz

zwodziarz

Member
Apr 6, 2011
49
9
32
Kielce
Thanks for the report. When it comes to battery reports, I learned in the past years of developing kernels that they are always very inconsistent. I do my best to optimize and then it is what it is. So I can't help much with that.

Found an issue: while my phone was charging now touch screen became a laggy from time to time when I locked/unlocked the screen it came back to live then after few minutes again - lagging. Got that problem while phone was plugged in on USB debbuging but thought it was normal then - haven't reported that issue while charging
 

mrg666

Senior Member
Aug 4, 2011
1,966
4,784
Found an issue: while my phone was charging now touch screen became a laggy from time to time when I locked/unlocked the screen it came back to live then after few minutes again - lagging. Got that problem while phone was plugged in on USB debbuging but thought it was normal then - haven't reported that issue while charging

I just checked what you described but I am not able reproduce; it is as smooth as always while charging for me. Please post dmesg when that happens again.
 
  • Like
Reactions: zwodziarz

Top Liked Posts

  • There are no posts matching your filters.
  • 140
    MiRaGe is a lean and efficient kernel for the stock Nexus 4 ROM with the optimizations and updates that are not included in Google's stock kernel. MiRaGe kernel fits squarely in the stock Nexus 4 ROM; all of the modules are integrated in the kernel just like the stock kernel and it should work with all AOSP ROMs that work with the stock kernel and boot image. However, only the current stock ROM is tested. If you decide to use MiRaGe, just flash and forget it since I have avoided adding more sysfs parameters. It is not my goal to enable all possible tweaking options and add every possible feature to the kernel such as multitude of governors, io schedulers, sweep2wake, fastcharge, etc. This kernel is not intended as a tweaker's kernel. You can, of course, tweak it as much as you want since that is your phone and kernel. But please try removing your tweaks before posting any problems. I always test the latest builds with the current stock ROM before posting here.

    I am sharing exactly what I have developed for myself and posting 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 when they make sense.

    Source Code:
    Source code is based on Google's msm kernel source (currently android-msm-mako-3.4-lollipop-mr1.1) and a summary of my changes are below. You can find the full details of my changes and the complete source code in my repo.

    Changes:
    - synced with mainline Linux 3.4.110
    - cleaned up kernel configuration and removed many unnecessary options
    - removed kernel debugging options
    - built with the Linaro toolchain (gcc 4.9.4 - 15.06) using standard krait and -O2 optimization
    - removed AOUT and OABI support
    - disabled both user-space msm_mpdecision and kernel-space msm_mpdecision
    - removed msm_run_queue_stats, dcvs, and stock msm_mpdecision in the kernel
    - added autosmp, a simple and efficient (by me) multi-core cpu hotplug driver
    - disabled the user-space thermald and switched to kernel-based msm_thermal
    - replaced CFQ with the latest BFQ as the default IO scheduler
    - backported random and prandom updates from Linux 3.13 (no entropy depletion anymore)
    - backported workqueue from Linux 3.8 to include many important improvements
    - backported rwsem from Linux 3.11 to include lock stealing improvements
    - backported mutex and rcu locking from Linux 3.10 and 3.8, respectively
    - backported slub memory allocator updates from Linux 3.8
    - backported cpufreq driver, ondemand, and conservative governors from Linux 3.12
    - updated interactive CPU governor from AOSP and CAF
    - disabled userspace CPU governor,
    - enabled callback-free CPUs (RCU_NOCB_CPU)
    - backported TCP Small Queues and CODEL net scheduler from Linux mainline and set as default
    - updated kernel scheduler, msm-hotplug, msm-idle, msm-pm code from CAF and Linux mainline
    - applied patch [v4] binfmt_elf.c: use get_random_int() to help with entropy depleting
    - enabled autogroup scheduler and applied patch per-uid task group for Android
    - added optimized ARM RWSEM algorithm
    - added optimized ARM SHA1/AES routines
    - enabled CPU-supported unaligned accesses
    - disabled gentle fair sleepers in scheduler
    - updated Qualcomm HW RNG driver from CAF
    - enabled BPF JIT compiler for packet filters
    - applied glibc patch to improve the performance of memcpy and memmove
    - applied word-at-a-time ARM API patches
    - enabled CPU overclocking up to 1.728 GHz with user-space vdd control
    - optimized vdd curves, L2 and bus speeds for better performance and efficiency
    - removed unneeded a2xx and a4xx components from kgsl driver
    - modified the prima wifi driver to disable debug code
    - removed PMEM completely, MiRaGe is pure ION
    - add support for kernel mode NEON and NEON acceleration
    - add NEON optimized SHA1, SHA256, and SHA512 crypto code
    - add LoUIS API for cache maintenance ops to improve cpu hotplug latency
    - added and enabled power_efficient workqueue
    - added and enabled msm memutils
    - added screen gamma, user space cpu voltage control, and dt2w
    - backported devfreq driver from CAF and switched kgsl 3d governor to simple_ondemand
    - backported many other fixes/updates/optimizations from CAF and Linux mainline, see the repo for details
    - init.d supported if /etc/init.d and busybox are available
    - a diff file of changes to ramdisk is here

    Downloads:
    Boot image for stock ROM:
    LMY standard kernel Built: 10/25/15 MD5sum: a315cc446499d60cb4b3a61ea7bfa8f8
    LMY overclock kernel Built: 10/25/15 MD5sum: 7c72a66830f511b025968db2bb743429

    Anykernel updater for custom ROM:
    Revert back to stock kernel to restore the original ramdisk and flash anykernel package of MiRaGe after that. This is not needed in the next anykernel update.
    LMY standard kernel Built: 10/25/15 MD5sum: 85b4136ac0ada793da7b80763193095a
    LMY overclock kernel Built: 10/25/15 MD5sum: 2924fb6a963b40087c296a7b1abfc1d3

    KTU standard kernel Built: 10/31/14 MD5sum: dca7d06933eb43c8da3ba7941bb6ac88
    KTU overclock kernel Built: 10/31/14 MD5sum: dca7d06933eb43c8da3ba7941bb6ac88

    The only difference between the standard and overclock builds is the ~100mV undervolt in the overclock build. Both kernels have maximum CPU_freq = 1.728 GHz, default CPU_freq = 1.512 GHz, overclocking, and user space cpu voltage control enabled. Since the CPU gets hot quickly in Nexus 4, I only recommend overclocking with the overclock build that has built-in undervolt. If the phone doesn't boot with overclock kernel, it means that your CPU is not able to handle the undervolt settings. In that case, you can just reboot into recovery and flash the standard kernel. No-frills CPU Control is recommended to set the max overclock frequency. Each CPU has different overclock/undervolt ability. Don't get disappointed if the OC build doesn't work for you.

    Installation:
    You can do one of the followings
    - Flash the zip files in recovery, there is no need to wipe cache or dalvik-cache
    - Flash the boot image in the zip file using either Flash Image GUI or fastboot
    - Here is the original boot image for LMY48I build, in case needed for going back to stock. Either flash in the recovery or open the zip file to extract the boot image.

    Credits:
    - Special thanks to Linux, Google, CAF, Linaro developers in general.
    - @tvall, @bedalus, @xboxfanj, @ihancioglu, @xenyz for collaboration
    - @stratosk for the screen gamma interface and dt2w
    - @defconoi for collaboration (see Unleashed Kernel Series)
    - @mathkid95 for the any-kernel updater package
    - @joeykrim for FlashImageGUI
    - @Christopher83 for the optimized Linaro toolchain builds
    - Other credits are given in the repo for each commit
    43
    Recommendations:
    • I am frequently receiving requests to add sound patches in the kernel. I agree that the sound is not very good but there are solutions. I am using the Viper4AndroidFX as a replacement sound processor. I recommend giving it a try. You need to go to the sound options and select ViPER4AndroidFX to use this sound processor or freeze MusicFX (I use Link2SD for this). There is plenty of information at the above link. With this available, I am not planning to add any sound patches.
    • Another frequent question is about choosing CPU governor and IO scheduler. In the earlier builds, interactive governor had the best balance of performance and battery life among other CPU governors and it is still available. In the latest builds, ondemand governor was backported from Linux 3.12 and replaced interactive as the default. The latest patches in the mainline Linux, especially stratosk's patch that optimized the load calculations made the new ondemand governor the better option regarding both power and performance. Regarding IO scheduler, BFQ scheduler has the best overall real-use performance and it is actively maintained/improved. You can use Nofrills CPU Control to change the governor and scheduler. But I would leave the defaults as BFQ scheduler and ondemand governor.
    • Since all of the cpu power control functions are contained in the kernel with MiRaGe, the userspace PowerHAL library will be giving the following messages in the logcat.
      Code:
      E/PowerHAL( 511): touch_boost: failed to send: No such file or directory
      E/PowerHAL( 511): touch_boost: failed to send: No such file or directory
      E/PowerHAL( 511): touch_boost: failed to send: No such file or directory
      These are harmless but if you want to eliminate them, just make a backup and delete/rename /system/lib/hw/power.msm8960.so and power.mako.so. The single purpose of touch_boost is to enhance the system response to the user interaction. But using a service in the user space to send a touch boost signal to the kernel via slow sysfs file system is the wrong way of trying to achieve lower latency. In addition, every touch input doesn't need a CPU frequency boost which wastes battery power. The best way of achieving the low-latency system response to user interaction is improving the efficiency of existing CPU governor which raises the CPU frequency and hotplug driver which enables off-line cpu cores when needed. In MiRaGe, CPU freq is only controlled by the CPU governor based solely on the CPU load and the latency is low since efficiency is improved by reducing such unnecessary bloat. Additionally, highly-efficient autosmp hotplug driver works in-sync with the CPU governor to enable off-line cpu cores when the the CPU frequency reaches a high threshold and still more compute power is needed. Therefore, touch boost bloat is removed.
    • With some of the custom ROMs, root is lost after flashing MiRaGe because of using the init scripts in the ramdisk for starting the su daemon. SuperSU is the recommended solution. I might switch to any-kernel-updater to address this problem but as written in the OP, MiRaGe is primarily for the stock ROM. Also, having the full boot image in the zip file is more reliable than expanding/processing/repacking the boot image.
    • MiRaGe supports init.d if it is setup. To setup init.d do the followings either within ES File Explorer or terminal .
      - install busybox (I use busybox on rails)
      - create /system/etc/init.d and chmod to 755 (rwxr-xr-x)
      - create your init scripts in the /system/etc/init.d directory. Name them 01yourscriptname (e.g. 01mysettings) and chmod 755. Make sure they are UNIX format (not in DOS/Windows).
      example:
      Code:
      #!/system/bin/sh
      echo 1 > /sys/devices/virtual/input/lge_touch/dt_wake_enabled
      - reboot
    • Here is how to add multiROM support

    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 binary for ARM architecture.

    Linaro toolchains can be downloaded from Linaro binary page. Christopher83 has built the latest Linaro-14.08 toolchain based on gcc-4.8.4 which is stable/reliable and I recommend starting the development with this toolchain.

    The binary Linaro toolchain for Linux 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_mako.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/mako_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=~/untarred-toolchain-dir/bin/arm-linux-gnueabihf- zImage -j8

    Replace j8 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 always use the latest version of Xubuntu x64 (with custom built kernel) on my Linux workstation that has a AMD FX-8320 (overclocked to 4.2 GHz), 8 GB RAM, 500 GB HD. The compile time is about 2 minutes for me using all 8 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 any-kernel updater package in the OP as a template and replace zImage in /kernel directory with your build. If you want to create a boot image, see this post

    Now that you have source and can build the kernel, you can add all the features you want to your own kernel ;)
    23
    New MiRaGe builds are available in the OP.

    - Fixed the kernel crash while changing the cpufreq governor. I have tested cpufreq governor change many times between ondemand, interactive, and performance.
    - Built with Linaro 15.03 toolchaing (gcc 4.9.3) after testing that the kernel has no stability problem with this release. The kernels built with the earlier gcc-4.9 based toolchains had stability problem. I have been building my custom Linux-4.0 kernel for Ubuntu 15.04 with gcc 4.9 and I thought it was time to test the Android kernel as well. It seems that gcc 4.9.3 is now mature enough.

    I have also found a workaround for the shared policy problem about the governor change not applied to the offline cores. The workaround is switching initially to performance governor which brings all cores online and the next governor change applies to all cores since all of them will be online during the governor change. I will look into eliminating this workaround next.

    Cheers!

    PS: Please post if you see any problems/improvements with the new toolchain.
    23
    I have uploaded the new builds and downloads links are in the OP. The changes are the followings.

    - Disabled C1 and C2 power states by default. It is still possible to enable them via sysfs with the instructions in the thread. I have seen that there were no significant battery life savings by using these power states but disabling them improved the kernel response and potentially fixed some rare screen flickering issues for some users.
    - Fixed a rare crash of kgsl driver. Nobody has complained yet but I recommend updating the kernel with this build
    - kgsl patch to start GPU in high-priority workqueue to decrease latency
    - Removed unused USB_NET drivers
    - Removed scsi disk support.
    - Updated bpf_jit compiler with several fixes

    I think I have addressed all concerns in the recent posts and I believe MiRaGe is in a very good state right now. I need to take a break for a while. I don't expect but if there are any problems, I will be checking the thread in the weekends and will do my best to fix them.

    Cheers!


    Its okay if i flashed the new version over the old one?
    Sure, that is the way you are supposed to do.
    22
    New build is available in the OP.
    Changes:
    - Linux 3.4.95-96
    - cpufreq: governor: Be friendly towards latency-sensitive bursty workloads (from Linux 3.16)
    - cpufreq: ondemand: Eliminate the dead band effect in low load (thanks to @stratosk)
    - ext4: Speedup WB_SYNC_ALL pass called from sync(2) (from Linux 3.15)

    Cheers!