yashsingh1/xdaforums huggingface dataset:
[Nexus 4 Original Android Development] Swords.Grizzlebee:
Photos seem to be normal, I'll keep an eye on them though. Thanks! I was impressed because usually my phone can't handle too much of an overclock.

EDIT: It can also handle a benchmark test at that frequency without rebooting. Not that I put too much stock in them, but it's nice to know it can handle it.
[Nexus 4 Original Android Development] mrg666:
I also use Quadrant and 3DMark to test stability and heat. Agree with you that user experience is what matters in the end, not the benchmark score.
[Nexus 4 Original Android Development] mrg666:
I noticed that selinux was turned off inadvertently. I have restored it and updated the builds in the OP to include selinux. Sorry :o
[Nexus 4 Original Android Development] bertans:
Hi mrg666,

it's almost one week since I installed your kernel... everything works flawless, it's really rock solid. :good:

As I previously said, I can't understand the real work behind MiRaGe (changelog is really technical) because I'm just an average user but I can tell you (take my words as a suggestion and consider that I'm in error, for sure) that battery performances looks the same as stock kernel Android, maybe a little less. Is it possibile? :eek:

It's a

stupid post

, I know, but if you can squeeze a little more battery optimization it would be very nice! :victory:

Thank you again
[Nexus 4 Original Android Development] haget83:
i would try this kernel, but everytime i flash this on Slimkat i lost root.

Updating superSu from cwm doesnt' work :(
[Nexus 4 Original Android Development] jawz101:
I don't use the overclock kernel. I'm going to flash your non-oc kernel once more and grab a last_kmsg
[Nexus 4 Original Android Development] mrg666:
Not stupid at all. Thanks for the feedback.

The problem is probably related to init scripts in slimkat doing some superuser daemon configurations which doesn't exist in my init scripts that are based on the stock ROM. The solution could be using an any-kernel-updater script. But I don't like blindly modifying the init scripts and throwing a kernel in an unknown boot image. I need to check slimkat init scripts but I don't want to deal with nonstandard AOSP/CM ROMs for now. Sorry.

______________________________

Everyone:

The SOT battery life with the overclocking kernel was worse for me too. The heat was slightly higher that can explain the higher battery drain. I have reverted the bus speed modifications and uploading the reverted builds now. Please check and let me know.
[Nexus 4 Original Android Development] mrg666:
I am seeing several kernel repos with wrong modifications in the cpu frequency table in arch/arm/mach-msm/acpuclock-8064.c. Such as the following commit

- { 1, { 384000, PLL_8, 0, 0x00 }, L2(0), 950000 },
- { 0, { 432000, HFPLL, 2, 0x20 }, L2(5), 975000 },
+ { 1, { 192000, PLL_8, 0, 0x00 }, L2(0), 950000 },
+ { 1, { 384000, HFPLL, 2, 0x20 }, L2(5), 975000 },

The first number after the second curly bracket is just a label. The cpu frequency cannot be changed by changing the label. Instead, the second divider and third (hexadecimal) multipier values following the label determine the frequency using the base frequency of 27000, as seen below.

hex(0x20) = dec(32)
frequency = 32 * 27000 / 2 = 432000

So, 432000 is just a label, and making it 384000 will not change the frequency although the kernel control apps will show as if the frequency is changed. Because they only read the label, not the *real* cpu clock frequency. For those kernel control apps to function accurately, the labels should be accurate as well. Same for 384000 -> 192000 change.

just my 2c.
[Nexus 4 Original Android Development] :
I was guilty of this exact blunder in the past. Thanks for the tutorial!
[Nexus 4 Original Android Development] mrg666:
We are all learning here. There must be errors in my repo too.

On a similar note, I have reverted the 600 MHz bus frequency. It looked like there was a little higher heat and reduced battery life. I am not exactly sure though. I am now testing the patch without using the full range of L2 frequencies. Maybe continuous scaling of the L2 freuency with cpu frequency is not the efficient way of scaling cpu frequency of 8064. There could be such a reason for the original code using only two L2 frequencies. Please let me know if you have any insights.
[Nexus 4 Original Android Development] :
I never tried any higher-than-stock bus speeds. My only finding is that I can extend the stock maximum bus speed down to 702 MHz without any issues. This has helped reduce heat and power consumption in the case of playing games, because now it is possible to play and have the highest frame rates at lower CPU frequencies.

I believe other kernels devs found that GPU would only write all the frames to the buffer if they forced the CPU frequency to 1134MHz (only because that would trigger the higher bus). They never considered bringing the highest bus speed down to lower frequencies. I think there was a misconception that it was the CPU frequency that was the dominant factor.

One thing I haven't tested yet is whether I can use a lower bus speed but retain maximum FPS
[Nexus 4 Original Android Development] mrg666:
Okay, This sounds interesting. I will test using the high bus speed at lower cpu frequencies too. If GPU demand can be satisfied at lower CPU frequency, that should also help with heat and battery life.
[Nexus 4 Original Android Development] :
It's definitely helped with the heat, so there's obvious evidence of power saving right there. Higher bus needs more power of course, but for ordinary use the two balance out I would say. It's during gaming I would say there is an enormous advantage.
[Nexus 4 Original Android Development] mrg666:
I have done and tested what you have suggested, i.e. increased the bus frequency to 1134000 at all CPU frequencies >= 702MHz.

I have run two 3DMark benchmarks back to back and monitored the CPU temperature using your modification and without the modification. The max recorded CPU temp was 60C without the mod, the next set of benchmarks with your modification is 56C. I made sure there was no thermal throttling happening during the benchmarks.

So there is an improvement in the CPU temperature. There was a tiny improvement in the benchmark score but I wasn't expecting anyway. And that should be just a statistical variation. I will test in the daily use now.

Your suggestion seems to be working to me :good:
[Nexus 4 Original Android Development] :
I hope this idea catches on. Just FYI I've been running it this way for 17 days and had no issues.
[Nexus 4 Original Android Development] zorginho:
[MENTION=4203114]mrg666[/MENTION] was trying to build your kernel with same toolchain and same command as OP says but i have that error:

[...]
CC [M] drivers/crypto/msm/qcedev.o
drivers/crypto/msm/qcedev.c:15:32: fatal error: linux/android_pmem.h: File o directory non esistente
#include <linux/android_pmem.h>
^
compilation terminated.
make[3]: *** [drivers/crypto/msm/qcedev.o] Errore 1
make[2]: *** [drivers/crypto/msm] Errore 2
make[1]: *** [drivers/crypto] Errore 2
make: *** [drivers] Errore 2
make: *** Attesa per i processi non terminati....
[...]

can u tell me how i can fix it?

it's the first time that that error appers, and i've compiled other kernels too (ex stock with faux sound and gamma, and slim kernel).
[Nexus 4 Original Android Development] mrg666:
My mistake. I have removed pmem from this kernel and one file I forgot to fix is looking for it. Just omit "modules" in the build command. I will add a fix in the repo for this one.
[Nexus 4 Original Android Development] zorginho:
ok then :D

but without ur help i've started abuild process with that command

make ARCH=arm CROSS_COMPILE=/home/stefano/Scrivania/gcc-linaro-arm-linux-gnueabihf-4.8-2013.12_linux/bin/arm-linux-gnueabihf- -j2

so without zImage too, it's the same or i have to restart the build process?

EDIT:

same result :crying:

[...]
CC [M] drivers/crypto/msm/qcedev.o
drivers/crypto/msm/qcedev.c:15:32: fatal error: linux/android_pmem.h: File o directory non esistente
#include <linux/android_pmem.h>
^
compilation terminated.
make[3]: *** [drivers/crypto/msm/qcedev.o] Errore 1
make[2]: *** [drivers/crypto/msm] Errore 2
make[1]: *** [drivers/crypto] Errore 2
make: *** [drivers] Errore 2
make: *** Attesa per i processi non terminati....
[...]
[Nexus 4 Original Android Development] mrg666:
Can you explain a little more? How do you see that root was lost? As I said there is nothing in the zip file that touches /system, /data, or anything else other than /boot. So ROM should be checking if the kernel was replaced and disabling root, I guess.
[Nexus 4 Original Android Development] QUIETLYloud:
Okay the first time I flashed on slim I was coming from hellscore kernel... Tried again after reflashing slim got multi fc's to the point that I couldn't get to home screen... it may have something to do with the fact that superuser is integrated, when I flashes the first time everything booted just fine but when I went in developer options to select "root access"the option wasn't there... Just trying to get you as much info as possible

P.s. I flashed through twrp 2.6.3.0
[Nexus 4 Original Android Development] DontPushButtons:
Well, testing on vanir didn't go so well for me lol. Needed the colorfix, so I flashed that and wiped dalvik and it kept booting to a black screen. Tried letting it sit for 10-15min with no luck.
[Nexus 4 Original Android Development] QUIETLYloud:
Last thing and I hope it helps... Looking at the .zip there seems to be a folder missing, other kernels I've flashed has a folder named "kernel" that contain 5-6 files...

Hope this helps
[Nexus 4 Original Android Development] mrg666:
There is nothing missing in the kernel zip file. I have developed MiRaGe kernel in a way that just fits squarely in the stock ROM. All of the modules are integrated in the kernel just like the stock kernel. There is no need to modify anything in the stock ROM to make it work with MiRaGe kernel. So MiRaGe should work with any ROM that is able to work with the stock kernel or stock boot image. As I understand, the ROM you use is not that similar to the stock ROM. In that case, I would recommend you to stick with the kernels that work with your ROM. I think it will be good to add this statement to the OP.
[Nexus 4 Original Android Development] mrg666:
Updated the kernel with the following changes

- optimized ARM RWSEM algorithm

- optimized ARM SHA1/AES routines

- allow CPU-supported unaligned accesses

- disable gentle fair sleepers in scheduler

- boost frequency of online cpu(s) to max on resume

- built with linaro gcc 4.8.2 and -O2 optimization

Cheers!
[Nexus 4 Original Android Development] DontPushButtons:
Hmm, seems like both links go to a JWR kernel zip. Misnamed zip? Or mistyped a hyperlink?

Edit: looks like a bad link. Md5 matches the JWR zip.
[Nexus 4 Original Android Development] Stylez Ray.:
yeah, want to try JSS version but it links to JWR...
[Nexus 4 Original Android Development] DontPushButtons:
In sure it'll be fixed shortly. Probably just sleeping or enjoying Friday night like a regular person ;)
[Nexus 4 Original Android Development] mrg666:
I have just fixed the link. Sorry ...
[Nexus 4 Original Android Development] DontPushButtons:
No worries, these things happen :P
[Nexus 4 Original Android Development] Stylez Ray.:
flashing this on crdroid with colorfix results in many FCs after boot...even wiped /system and dirty flashed rom...didn't grab kmsg though :(
[Nexus 4 Original Android Development] alen1901:
Why did you disable gentle fair sleepers? I remember in galaxy s2 days, that option was there to get better performance? Also, about boost frequency, how is that working, on touch it boosts to max? That would drain more battery, wouldnt it? Thanks.
[Nexus 4 Original Android Development] mrg666:
It probably doesn't have any impact with a quad-core cpu but disablling gentle fair sleepers generally improves the responsive of UI. See below

http://xdaforums.com/showpost.php?p=24233069&postcount=1

Regarding boost frequency commit, I am quoting from my repo.

"msm: cpufreq: boost freq of online cpu(s) to max on resume

Resume events cause several tasks to initiate such as WiFi connect,

data sync, etc. that require cpu cycles. Instead of waiting for the cpu

governor to increase the cpu frequency which occur after an unpleasant delay,

start at the max frequency and the cpu governor will scale the frequency

back as soon as possible. This shouldn't have any noticeable impact on battery

life."

I don't know what is crdroid and colorfix. As I stated in the OP, MiRaGe is developed for the stock AOSP ROM. Please use the compatible kernel with that ROM.
[Nexus 4 Original Android Development] howard bamber:
THANKS! :) IVE just come back to rooting after some time away. The note 1 was last. You are a man after my own heart. I wanted to root, keep the rom but strip bloat and look for a kernel that would be leaner.

I gave it real world testing. The phone as I'm using it 3/4 full. No special settings. Came out just better than the listed for stock sooo if I had gone to the trouble....! Nice one

Sent by mobile telephone.

---------- Post added at 07:11 PM ---------- Previous post was at 07:04 PM ----------

I'm fed up with the complaints. Come on guys this is a great fast kernel. I've no issues at all. The phone is faster. Nothing at all is wrong. BUT I'm doing as he says. Using the stock rom.....

Sent by mobile telephone.
[Nexus 4 Original Android Development] mrg666:
Thanks for the feedback and I am glad that MiRaGe is useful for you.
[Nexus 4 Original Android Development] nemanja066:
Good Kernel :good:
[Nexus 4 Original Android Development] Stylez Ray.:
crDroid is a ROM http://xdaforums.com/showthread.php?t=2395744

Why shouldn't your kernel work with it? Or am I understanding right that it really ONLY works on stock ROM?! :rolleyes:
[Nexus 4 Original Android Development] mrg666:
I really don't care. As it is clearly stated in the OP, MiRaGe is for stock AOSP ROM. :rolleyes:
[Nexus 4 Original Android Development] Stylez Ray.:
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:
[Nexus 4 Original Android Development] mrg666:
You can modify the command as follows.

make ARCH=arm CROSS_COMPILE=~/untarred-toolchain-dir/bin/arm-linux-gnueabihf- zImage -j6

or delete line 15 in drivers/crypto/msm/qcedev.c

or just sync with the repo again; I just pushed the fix.
[Nexus 4 Original Android Development] zorginho:
very well ill try it tomorrow then :D

now it's a bit late
[Nexus 4 Original Android Development] RealiZms:
Fantastic kernel. Any chance of seeing PA colors? I'm hooked on those halfbreed colors :p
[Nexus 4 Original Android Development] zorginho:
thx a lot, it worked, I've posted a mirage kernel with some mods in the oasis thread (basically it's the same idea).

and if the feedback is good I can add something more too...

obviously if it's ok for you, since is your kernel! :p

Inviato dal mio Nexus 4 utilizzando Tapatalk
[Nexus 4 Original Android Development] mrg666:
I do the boring stuff. You will find the colors at the Oasis thread

It is yours now. You can do anything you want. Have fun.
[Nexus 4 Original Android Development] mrg666:
A new build is available in the OP with the following changes

- More fat trimming

----- remove support for /dev/mem and /dev/kmem

----- disable MSM_SMD_LOGGING

----- remove nohlt debugfs node

----- remove clock-debug

- kgsl fixes

- crypto updates

- Linux 3.4.79 (will be released tomorrow)

Following the earlier discussion, no changes for the cpu bus speed are included in this build. I am still evaluating the stability/power/heat/performance aspects. It seems that the patch that improves the gaming performance is hurting the power and heat for non-gaming use. I am trying to find an optimal configuration.

Enjoy!
[Nexus 4 Original Android Development] :
This guy does solid work if you're interested in optimised toolchains: http://xdaforums.com/showthread.php?p=50107146
[Nexus 4 Original Android Development] mrg666:
I have been using Cristopher83's Scorpion optimized toolchains for the shooter kernel. It is exciting news that he has started building optimized toolchain for Krait as well. I will try them right away.
[Nexus 4 Original Android Development] Connor Baker:
Just a heads up, I did try to do a build with the a9 4.8.3 Linaro toolchain. Got this error:

arch/arm/mach-msm/lge/mako/board-mako.c:55:32: fatal error: linux/android_pmem.h: No such file or directory
#include <linux/android_pmem.h>
^
compilation terminated.
make[3]: *** [arch/arm/mach-msm/lge/mako/board-mako.o] Error 1
make[3]: *** Waiting for unfinished jobs....

Also, another question [MENTION=4203114]mrg666[/MENTION], I notice that the *first* commit on your git (https://github.com/mrg666/android_kernel_mako/commit/ec6d38f5c637437d2b22f3a4221689731f0859ae) is cloning the 4.3 branch. Is this kernel fully up to date with the kk-mr1 release kernel?

Connor Baker

P.S. Pardon my ignorance please, just wanted to know if it's updated.

EDIT: I got the error above on 4.8/6 toolchains as well
[Nexus 4 Original Android Development] mrg666:
This error can only happen if you are enabling CONFIG_ANDROID_PMEM in your .config file. Please disable PMEM since it is removed in MiRaGe and it is unnecessary for Android 4.4. Please use my config file in arch/arm/configs/mako_config to build and change your configuration starting from that file. I have downloaded the Christopher83's A15 optimized toolchain. Kernel builds and works fine for now. I will keep testing until the next release build.

Yes, MiRaGe is fully in sync with kk-mr1. But it is also far beyond kk-mr1 due to hundreds of later commits.
[Nexus 4 Original Android Development] Connor Baker:
My bad! Very sorry for wasting your time. I had used the wrong config file.

Thank you for your speedy response!

Connor Baker
[Nexus 4 Original Android Development] criminalzen:
thanks

thanks for all your work on your kernel. I am running it with the new toolchain just mentioned.I am fairly new to posting on xda, although I spent a year reading franco's nexus 4 kernel thread last year. I follow your commits and build your kernel. I really like your approach and appreciate the skill and knowledge you manifest. Thanks again for your work, and a helpful, accepting attitude.
[Nexus 4 Original Android Development] mrg666:
Your question was very useful in fact. I have double checked my repo and noticed that I was missing some of the commits that were included in kitkat-mr1. I have just added those commits now. I will test and update the build tomorrow.
[Nexus 4 Original Android Development] :
I'm trying a15 now. I think it's a similar architecture to krait, so I'm hoping it'll benefit from the optimisations just the same
[Nexus 4 Original Android Development] mrg666:
I think I can safely say that A15-optimized toolchain is reliable and safe to use. I will keep using it.
[Nexus 4 Original Android Development] :
I'd previously been using a generic toolchain with a15 optimizations in the Makefile, it's always worked well!
[Nexus 4 Original Android Development] mrg666:
gcc-4.8-based linaro toolchain was very problematic with optimizations for the shooter 3.0 kernel for scorpion cpu. Did you see this post? However 3.4 kernel for krait core is stable with gcc 4.8. I have been using only the basic optimizations to avoid stability problems since then.

BTW, everyone, I have a new build in the OP with the following changes.

- add missing kgsl commits from Google's kiktat-mr1 repo

- switch to Cristopher83's A15- optimized gcc 4.8 linaro toolchain
[Nexus 4 Original Android Development] :
As in -O2 and standard linaro flags?
[Nexus 4 Original Android Development] mrg666:
To be exact, here are the flags I use for krait in addition to standard -O2.

-mtune=cortex-a15 -march=armv7-a -mfpu=neon
[Nexus 4 Original Android Development] mrg666:
There is still no reliability problem with the A15-optimized toolchain but I am observing a little higher heat than normal. I think I have acted too early to distribute the kernel with this toolchain. I have rebuilt today's packages with the standard linaro toolchain. If you are also observing higher heat please flash with today's re-released build. I will keep testing.
[Nexus 4 Original Android Development] nycelitemaster:
does this kernel have USB OTG patch?
[Nexus 4 Original Android Development] mrg666:
I haven't worked on it yet. Are you willing to help with testing?
[Nexus 4 Original Android Development] nycelitemaster:
Ofcourse i can test. i have cable and battery.

Sent from my Nexus 4
[Nexus 4 Original Android Development] mrg666:
Thanks! I will post the test kernel here in a day or two.
[Nexus 4 Original Android Development] nycelitemaster:
Cool

Sent from my Nexus 4
[Nexus 4 Original Android Development] clockworkstop:
I'll test as well.

Sent speedily from my scurrying Nexus 4
[Nexus 4 Original Android Development] nycelitemaster:
Also just trying to confirm if voltages can be changed? I didn't see the voltage table.

Sent from my Nexus 4
[Nexus 4 Original Android Development] mrg666:
sysfs interface is not included for vdd table. As I posted in the OP, this is not a tweaker's kernel.

BTW, I worked on USB OTG but I don't like what I am adding in the kernel also changes required in the ramdisk and OS. I will post here if I can find a simpler solution. Sorry.
[Nexus 4 Original Android Development] nycelitemaster:
[MENTION=4203114]mrg666[/MENTION] thats fine. Can you please advise if you have already lowered the voltages?

Sent from my Nexus 4
[Nexus 4 Original Android Development] mrg666:
The overclocking kernel has undervolted (~100mV) and optimized vdd curves. See the following post

http://xdaforums.com/showpost.php?p=46855911&postcount=77

There is also information in the OP and if you search the keyword "vdd" in this thread you can find more posts about this discussion.
[Nexus 4 Original Android Development] nycelitemaster:
Cool thx n sry for being repetitive and not paying attention.

Sent from my Nexus 4
[Nexus 4 Original Android Development] mrg666:
New MiRaGe builds are available in the OP.

- updated SLUB memory allocator from Linux 3.8

- disabled SECURITY_SELINUX_DEVELOP and SECURITY_SELINUX_AVC_STATS

- several other updates

Cheers!
[Nexus 4 Original Android Development] :
Nice work on SLUB, I'll be cherry-picking some of that later :D
[Nexus 4 Original Android Development] :
While I was in the mood for cherry-picking, I decided to go to town and do as much as possible. I have a script that will cherry-pick through list of commits, so I produced a list from your repo:

https://github.com/bedalus/nexus4/commit/66fcef773414437fac49f636c223d621bd6d0e67

This commit message is now buried 400+ commits back, so I thought I'd bring the link to you directly.

I believe there were actually somewhere in the region of 450 commits that I cherry-picked, which represents a huge effort in backporting upstream improvements and fixes, so kudos to you for doing all of that work!
[Nexus 4 Original Android Development] mrg666:
Thanks for the appreciation. I am happy that you found the work useful since that was the whole purpose of posting the source. I think you have a genius way of dealing with so many commits. Did you improve your cherry-pick script since you had posted it several months ago?
[Nexus 4 Original Android Development] criminalzen:
wow

you both are very impressive (and way over my old head).. but I am learning watching you both and reading your threads and commits. I am gonna have to let martin (psx, plsx) and ctfrommn (velocitty and omp) know about this. I have seen ctfrommn using some of mrg666 commits before for his velocity kernel (Velocity-Project). I am enjoying building mirage with different toolchains.. no git work yet, but one must start somewhere. :)
[Nexus 4 Original Android Development] :
I needed to tweak the sed command after updating git. Apart from that it's still the same.