Related
Diet Android Kernel 2.6.33.2 by PsyQ
I am releasing the kernel which I use by myself I removed most of the debugging options useful for kernel/driver debugging and maxed-out possible compiler optimizations. It has Hybrid AVS support using IntersectRaven's improved method as well as optional overclocking (see note)
These kernels feature:
* Hybrid Adaptive Voltage Scaling for extra battery life
* Optional 1.1 GHz Overclocking Support
* Extra 8 MB of RAM reclaimed from Camera
* Based on Cyanogen's 5.0.6 kernel
* Maximum possible compiler optimizations (loop unrolling, tree vectorization, NEON, Cortex A8 compiler tuning, armv7a target, and many more)
* Removed all unnecessary features from the kernel configuration, including debugging options (these kernels are not useful for kernel debugging / driver development)
* All cpufreq governors (ondemand, powersave, conservative, ...) for people that want to tweak the CPU frequency scaling
Following kernels are available:
diet_2.6.33.3.hybrid_avs_800mv.zip --> Hybrid AVS support, goes down to 0.8 volts and has stock frequency (998 MHz) as max.
diet_2.6.33.3.hybrid_avs_800mv_OC.zip--> EXPERIMENTAL Hybrid AVS with overclocking to 1.1 GHz (0.8v min voltage)
diet_2.6.33.3.hybrid_avs_925mv.zip --> Hybrid AVS support, goes down to 0.925 volts and has stock frequency (998 MHz) as max.
diet_2.6.33.3.hybrid_avs_925mv_OC.zip--> EXPERIMENTAL Hybrid AVS with overclocking to 1.1 GHz. (0.925v min voltage)
To use it, flash the zimage with fastboot and push the bcm4329.ko to the /system/lib/modules:
Code:
[power off your phone and boot into fastboot]
fastboot flash zimage zImage
[reboot]
adb remount
adb push bcm4329.ko /system/lib/modules/bcm4329.ko
Pushing of the bcm4329.ko is necessary as WiFi support would be broken otherwise. If you don't do it, WiFi will not work.
Changelog:
Code:
V1.11 - Update - May/02nd/2010
- Moved to 2.6.33.3 Kernel
V1.10 - Update - Apr/26th/2010
- Changed floating point model to VFP
- There are two AVS versions with different lowest voltage limits (800/925mv)
V1.09 - Update
- Implemented IntersectRaven's Hybrid AVS method
- Synced with the latest code snapshot of CM kernel
V1.08 - Update
- Non AVS kernel is now undervolted down to 0.925v
- Kernel RCU is now of uniprocessor type, saving memory
- DMA speedup patch from latest CM source
- Removed "loopback" file device (this is not related to network)
- Further compiler optimizations
V1.07 - Update
- 8 MB RAM reclaimed from Camera
- Further kernel trimming
- AVS is now available with 0.925v and 0.850v flavors
- Some attempts to make AVS more stable (still work in progress)
V1.06 - Update
- Moved to kernel 2.6.33.2 from Cyanogen's 5.0.5.6 source
- AVS kernels are capable of undervolting down to 0.925v instead of 1.000v
- Minor cleanups
V1.05 - Update
- Further fixes in AVS Support (thx intersectRaven!)
V1.04 - Update
- Fixed bugs in AVS Support
- More kernel tweaks
- Removed "normal" version of the kernel, as _xtra seems to be stable enough
- Added non-overclocked AVS kernel for maximum battery life
V1.03 - Update
- Added Experimental Adaptive Voltage Support (AVS)
- Currently AVS is "for test only", and this kernel has debug support and no loop unrolling
V1.02 - Update
- Switched to CFQ I/O Scheduler
- Removed some more stuff (e.g. 10 Gbit Ethernet Support)
V1.01 - Update
- Added Conservative Governor
- Fixed table lookup bug (thanks pershoot!)
V1.0 - Initial Release
- Based on CyanogenMod 5.0.5.3 source
- Overclocking Support (1.1 GHz)
- Undervolted
- Optional extra undervolt (see attachments - _xtra is additional UV)
- Added Powersave CPU governor
- Removed most of the debugging stuff from Kernel (which makes this kernel useless for kernel debugging!)
- Even more C compiler optimizations (almost -O3 level + extra stuff, like loop unrolling, etc...)
- Audioboost patch
For other kernel developers - you can find the source code here (note that for AVS support you need AVS sources from ChromeOS):
http://github.com/psyq321/nexus_one_kernel_additions
Do you use the xtra version, if so have you noticed any problems
Nice release, will definitely try sometime.
Grrr!!! checked for updated version right before leaving for work, and just missed it!
I am using the one you posted in the other forum without any issues. Does it possess the same undervolting as the Xtra version?
Yes, _xtra is using same undervolt as the version from yesterday.
Additionally, this version contains more optimizations (loop unrolling) that I managed to cram-in by removing more debug options of the kernel (otherwise it would not fit)
What is loop unrolling?
Awesome, I'll pull the config to see what you have done...
just installed on my device. so far so good, using the extra undervolt. booted fine and everything so will report back later if I notice anything weird.
Hi man, in first thanks for this work...
Now can u tell me how can i use your kernel?
Thanks in advanced
just
[power off your phone and boot into fastboot]
fastboot flash zimage zImage
[reboot]
adb remount
adb push bcm4329.ko system/lib/modules/bcm4329.ko
interesting...I've been experimenting with the compiler optimizations in my own build...it made the kernel bigger although I feel a bit more responsiveness now...almost not noticeable but I think its there...
xPatriicK said:
What is loop unrolling?
Click to expand...
Click to collapse
Loop unrolling is the optimization technique used by modern compilers to potentially speed-up execution by decreasing overhead of the loop passes.
For example, imagine that you have a loop, that does something 4 times:
Code:
for(x=0; x<4; x++) {
do_something;
}
In this case, some % of the execution will be checking if the x is less than 4, and if no - "doing_something" again. This check has to be performed for every step (so, it is done 4 times)
Now, if you unroll this loop, it would look like this:
Code:
do_something; x++;
do_something; x++;
do_something; x++;
do_something; x++;
^ So, in this case, we completely eliminated checks.
Or, if the loop is much bigger (say, x goes up to 800):
Code:
for(x=0; x<800; x+=4) {
do_something;
do_something[x+1];
do_something[x+2];
do_something[x+3];
}
See? In this case, you reduce the number of condition checks for bigger loops.
This can sometimes make code faster - but the downside is that it makes the code bigger (which is obvious even in those examples above).
In Android Kernel 2.6.33.1 case - loop unrolling increases zImage size by ~350K. If I didn't strip debugging stuff out, zImage would be too big to fit on Nexus One.
Fortunately, there was approx. 400K to be saved by just kicking out features that enable kernel debugging. I don't think most of the people need that. These features are useful for kernel and driver developers, but most of others can perfectly live without them
Alright, thank you!
will try _xtra when Paul released the new Desire cam. Thanks for your work
Ivan Dimkovic said:
Loop unrolling is the optimization technique used by modern compilers to potentially speed-up execution by decreasing overhead of the loop passes.
For example, imagine that you have a loop, that does something 4 times:
Code:
for(x=0; x<4; x++) {
do_something;
}
In this case, some % of the execution will be checking if the x is less than 4, and if no - "doing_something" again. This check has to be performed for every step (so, it is done 4 times)
Now, if you unroll this loop, it would look like this:
Code:
do_something; x++;
do_something; x++;
do_something; x++;
do_something; x++;
^ So, in this case, we completely eliminated checks.
Or, if the loop is much bigger (say, x goes up to 800):
Code:
for(x=0; x<800; x+=4) {
do_something;
do_something[x+1];
do_something[x+2];
do_something[x+3];
}
See? In this case, you reduce the number of condition checks for bigger loops.
This can sometimes make code faster - but the downside is that it makes the code bigger (which is obvious even in those examples above).
In Android Kernel 2.6.33.1 case - loop unrolling increases zImage size by ~350K. If I didn't strip debugging stuff out, zImage would be too big to fit on Nexus One.
Fortunately, there was approx. 400K to be saved by just kicking out features that enable kernel debugging. I don't think most of the people need that. These features are useful for kernel and driver developers, but most of others can perfectly live without them
Click to expand...
Click to collapse
on point. i like what i see. i will try this out.
If I use the powersave governor option, SetCPU always show it running at minimum 245MHz. Is it working as expected?
bethedealer said:
If I use the powersave governor option, SetCPU always show it running at minimum 245MHz. Is it working as expected?
Click to expand...
Click to collapse
That's fine since the powersave governor clocks it to the lowest for maximum power savings.
standby 245/245 governor is better than on demand?
xPatriicK said:
standby 245/245 governor is better than on demand?
Click to expand...
Click to collapse
Curious about this too!
xPatriicK said:
standby 245/245 governor is better than on demand?
Click to expand...
Click to collapse
It's not necessarily better. It depends on what you're optimizing for. For example, powersave governor optimizes for power savings in return for slowest clock speed which may be apparent when using CPU intensive apps. Ondemand tries to balance it somewhat while giving more importance to CPU speed since it clocks the CPU back to full speed whenever an app runs and downclocking when appropriate. The conservative governor I use in my kernel also tries to balance this but gives more importance to power savings since when an app runs it slowly ramps up the clock speed until the app finishes. Hope this clears it up!
Note that powersave might actually consume more power at the end if you do some intensive work.
Why? Because it will force CPU to stay at the lower clock, even if the task could be completet much quicker with the higher clock.
At the end - it could very well be that running the task quicker @higher clock speed could consume less power total!
Unfortunately, there is no easy way to test what is better, unless someone writes a script that performs some tasks repeatedly until battery dies, and compares the baterry life between different CPU scaling strategies.
I'd definitely not use powersave governor. Rather, I'd play with the "up threshold" and "profiles" in SetCPU to make the CPU frequency scaling more conservative.
motley kernel for the Nexus 7 and Jellybean
Disclaimer: You know the gig...I am not responsible for damaging your device or voiding your warranty. Play at your own risk!
ROM devs/cooks: If you want to use this kernel in your ROM, I am fine with that, but please include a "thanks" and a link back to this thread. Thanks!
Requirements (please read carefully and visit the other dev threads as necessary)
You must be unlocked and rooted.
You must have custom recovery installed (CWM or TWRP) to install the kernel.
Busybox is required for init.d support.
Do a backup using custom recovery (CWM or TWR) so you can restore your boot.img and ROM if necessary!
Have your ROM zip in /sdcard so you can restore your ROM if necessary.
System Tuner is recommended for tuning the CPU, especially for voltage control.
Main Features
GPL compliant - source is kept up to date at github.com and released at the time the kernel is released to the public for all builds. Ask other devs to do the same!
Asus\Nvidia\Google Linux 3.1.10 base. All stock features are supported (camera, OTG, NFC etc.)
OC to 1.6GHz (optional)
Voltage control - be careful to not save the setting on boot until you are 100% sure!
GPU OC from 416 to 520MHz (default is 446, adjust as you wish up to 520MHz)
Dynamic EDP - allows EDP to remain enabled (safer), but with an added simple temperature throttle switch (based on Asus Prime)
Compiler optimizations (-O2) - using Linaro 4.7 ARM toolchain
I/O schedulers - row (default), SIO, V(R), CFQ, NOOP, and deadline
TCP Congestion Control - default cubic + several different algos to choose from.
ZRAM - must be enabled by a script
Governors - Interactive (default), Performance, OnDemand, PowerSave, Conservative
initramfs - insecure (your ROM must have busybox)
CIFS/UTF8, NFS, NTFS r/w, TUN - built-in, no need for any kernel modules
fsync sysfs enable/disable switch (defaults to fsync enabled)
kexec with hardboot (for supporting Linux/MultiROM)
Many other misc patches and tweaks (see github link below)
Install:
Check the requirements above!
Flash the zip using custom recovery (no need to wipe anything)
See post 2 for performance tweaks and more info
build #249 for Jellybean 4.2.2 - WiFi and 3G 2013-02-24
Added ability to change GPU clock speed at runtime (referenced franco, morific, and metallice git repos)
Added row io scheduler and set as default (Tatyana Brokhman)
Added TCP Congestion Control, several different algos to choose from. Default is cubic (stock).
Added optimized ARM RWSEM (Ezekeel)
Input patch (Henrik Rydberg)
View attachment motley_anykernel_N7_build_249.zip
build #247 for Jellybean 4.2.2 - WiFi and 3G 2013-02-17
Merged 4.2.2 patches
Updated Linaro toolchain to 2012.12
View attachment motley_422_nexus7_anykernel_build_247_446GPU.zip
build #246 for Jellybean 4.2.1 - WiFi and 3G
kexec\MultiROM support
Download from here since I posted in the MultiROM thread
build #244 for Jellybean 4.2 - WiFi and 3G - Recommended for WiFi and 3G on 4.2.x
446 GPU build (stock + 30MHz). Let's see if this fixes touchscreen issues for those having them. My theory is that after the GPU heats up, this starts to affect touchscreen behavior on some devices. This is likely what happened to me on build 234 when I was testing. The GPU definitely gets hot on this device even with normal usage at 484+. At 446 this doesn't happen. IMHO, we are reducing the life of the device by overheating the GPU repeatedly. My Antutu scores actually tested higher after I flashed the 446 build.
Supports Android Jellybean 4.2.x
Reverted some commits from 233
Removed KSM from config, no ROM is using this AFAIK
Panel clock reduced to match Nvida cardhu sources (74180000). Having the panel clock cranked up fakes out scores on some benchmark tests, but adds no real value.
View attachment motley_nexus7_anykernel_build_244_446GPU.zip
Previous builds and release notes
build #234 for Jellybean 4.2 - First properly working 3G build
Supports Android Jellybean 4.2.x
Only change - added CONFIG_USB_NET_RAW_IP=y to hopefully address any issues with 3G (reported working by DiamondBack)
View attachment motley_nexus7_anykernel_build_234_484GPU.zip
build #233 for Jellybean 4.2 - if you don't have issues with GPU OC @484, this build may work well for you.
Supports Android Jellybean 4.2.x
Updated to latest Linaro toolchain 2012.10.22 and tweaked some compiler options.
Should support 3G as I have merged the Google patches, but I have not tested this.
Removed WiFi PM_FAST toggle as I see no need for this (PM_MAX for better battery is already the default in stock)
Stopped logging temp warnings until lit gets to 65C near the EDP throttle limit.
Quad-core tweaks - referenced showp1984's bricked grouper kernel source
See github for other minor details.
View attachment motley_nexus7_anykernel_build_233_484GPU.zip
build #232 - Recommended for WiFi on 4.1.2
Added support for Android Jellybean 4.1.2
Updated to latest Linaro toolchain 2012.10.22.
View attachment motley_nexus7_anykernel_build_232_484GPU.zip (GPU OC 484MHz)
stable v1.1.1 - builds #218-220 - Recommended for WiFi on 4.1.0 or 4.1.1
Supports Android Jellybean 4.1.1 or 4.1.0
DVFS tweaks and drop top cpu frequency to 1600, not much is lost and it should now be stable for everyone I hope. We pushed the envelope to 1.7 and 1.624 and now we are back to real world sensible decisions. My Nenamark2 520 GPU scores actually went up.
Dynamic EDP temp adjusted from 67 to 68C to catch temp notifier quicker when cooling back down.
Other miscellaneous patches
Just in case, please note and then unset your saved voltage control settings before using the new version. You may need to clear your System Tuner App data to see the correct frequencies. Remember that the DVFS table and the scaling frequencies are different in some cases (see the second post for details)
View attachment motley_anykernel_nexus7_1.1.1_NoGPUOC_build_220.zip (GPU stock 416GHz)
View attachment motley_anykernel_nexus7_1.1.1_GPU484_build_219.zip (GPU OC 484MHz)
View attachment motley_anykernel_nexus7_1.1.1_GPU520_build_218.zip (GPU OC 520MHz)
alpha v1.1.0 - builds #213-215
Added fsync sysfs enable/disable switch (thanks Ezekeel). fsync is still enabled by default. For more info and how to disable, see post 2.
Experimental: now forging speedo id 4 and process id 2 so that EDP limits are slightly raised and it narrows everyone down to a common DVFS record for everyone. Raised Dynanic EDP governor to 67C (from 60C) to give a little more room before edp is allowed to enable.
Minor cpu voltage table tweaks aiming for slightly better battery for those that don't undervolt.
Lowered the cold offsets from 50 to 25 for the top 4 cpu voltage slots. This will give folks a little more breathing room when undervolting and may help cold performance a bit if your voltages are lowered close to their lower limit.
Deadline i/o scheduler (morfic's secret 1:1 sauce that I remember back from my Iconia A500 days!). SIO is still the default, but we can try it out and see what we think.
OnDemand really wasn't usable in it's stock state since it was so laggy, so I have made some tweaks to the tuneables and it seems to be better now for those that want to give it a spin. Interactive is still the default governor.
cpu transtition latency lowered - fairly certain that it only affects OnDemand governor and not Interactive (reference morfic and http://permalink.gmane.org/gmane.linux.ports.tegra/1649)
Reverted most of the adjustments to the tegra 3 algorirthim for bringing cpus online and offline. I think it livened it up, but at the expense of battery.
Added kernel config option BCMDHD_WIFI_PM (thanks Ezekeel). See post 2 on how to enable it (not recommended unless you have music steaming issues when the screen is off). Not yet tested.
Other miscellaneous tweaks
Just in case, please note and then unset your saved voltage control settings before using the new version. You may need to clear your System Tuner App data to see the correct frequencies. Remember that the DVFS table and the scaling frequencies are different in some cases (see the second post for details)
View attachment motley_anykernel_nexus7_1.1.0_NoGPUOC_build_214.zip (GPU stock 416GHz)
View attachment motley_anykernel_nexus7_1.1.0_GPU484_build_213.zip (GPU OC 484MHz)
View attachment motley_anykernel_nexus7_1.1.0_GPU520_build_215.zip (GPU OC 520MHz)
stable v1.0.12 - builds #175-177
Changed highest frequency back to 1.624GHz and core voltage back to 1200mV. After experimenting with higher core voltages and 1.7GHz probing our limitations, it just doesn't seem right on this tablet. Why fry the butter?
CPU voltage is capped at 1237, so don't set it higher than that if tuning.
Refresh rate now adjusted with GPU OC clock at compile time. Higher FPS should be realized at 484 and 520 for most (thanks to clemsyn for sharing his research and findings)
Adjustments to the tegra 3 algorirthim for bring cpus online and offline, especially for the OC frequencies.
Fixed GPU clock compile time switch. Removed 500MHz choice.
Set cpu frequency policy to 1.3GHz on startup. This should help with heat build-up on startup and users where the highest OC clock rate is not desired.
Lowest brightness setting set back to stock since several users were requesting it (18 back to 13).
Minor adjustment to the interactive governor to make it slightly more responsive when demands increase.
PowerHAL change so it doesn't mess with a couple other interactive governor tunables on init.
All frequencies throughout the power range should be used in a more balanced manner.
Just in case, please note and then unset your saved voltage control settings before using the new version. You may need to clear your System Tuner App data to see the correct frequencies. Remember that the DVFS table and the scaling frequencies are different in some cases (see the second post for details)
View attachment motley_anykernel_nexus7_1.0.12_NoGPUOC_build_177.zip (GPU stock 416GHz)
View attachment motley_anykernel_nexus7_1.0.12_GPU484_build_176.zip (GPU OC 484MHz)
View attachment motley_anykernel_nexus7_1.0.12_GPU520_build_175.zip (GPU OC 520MHz)
alpha v1.0.11 - builds #126-128
Changed highest frequency from 1.624 to 1.7GHz
Increased core voltage for the highest frequency to 1250mV. This should bring some increased stability at the highest two overclock frequencies (thanks to clemsyn and Pinoyto for their help)
Tweaked DVFS table for the GPU. It should now scale a bit better and still bring the same performance and the top end.
Lowest brightness setting increased from 13 to 18 (thanks to clemsyn). Lets give this a try and we can increase it further if need be. The brightness levels can be tweaked on the ROM side as well in the N7 device tree, at least when you build from scratch, so we don't want to be too limiting here.
PowerHAL fix now included /vendor/lib/how/power.grouper.so (thanks to imoseyon). See this post to see the code I changed.
(Removed download links since many were reporting random reboots. I think v1.0.12 is better anyhow)
stable v1.0.10 - build #110/111
CPU frequecies back to 1400, 1500, 1600, and 1624 (leaving the new highest setting)
DVFS table tweaks
Frequency table fix fix for 1624 (thanks to Clemsyn for bringing to my attention!)
Only stock and 484MHz GPU OC version - code switch is still there for those that want to compile and experiment. Moving beyond 484 doesn't show any benefit. My best Nenamark2 score 62.7 was achieved on 484MHz.
Just in case, please note and then unset your saved voltage control settings before using the new version. You may need to clear your System Tuner App data to see the correct frequencies. Remember that the DVFS table and the scaling frequencies are different in some cases (see the second post for details)
experimental v1.0.9 - builds #102-105
CPU OC to 1.624GHz - higher end CPU frequencies are now at 1408, 1504, 1600, and 1624 (old 1400, 1500, 1600, N/A)
DVFS table tweaks - Just in case, please note and then unset your saved voltage control settings before using the new version.
GPU versions stock, 484, 500 and 520MHz builds for testing
Added a GPU OC kernel config choice switch to allow compile time selection of GPU speed (446, 484, 500, or 520MHz).
NTFS r/w enabled
PegasusQ governor no longer built in, but code remains if we want to look further into when time allows.
Reduce some temp reporting kernel log spam until the temp gets a little higher
stable v1.0.8 - build #77/78
Added PegasusQ governor - experimental only, not enabled by default (thanks Samsung SGSIII source and gokhanmoral for tweaks)
Revert "HACK: block fbearlysuspend to not break androids crt-off animation"
Added LulzActive governor, but not built-in due to issues.
stable v1.0.7 - build #70/71
Voltage Control tweak - let's ignore the highest freq slot for show and
save since it shows 1.6GHz twice in the voltage table in System Tuner.
We are are only allowing 1200mV for 1.6, so the top slot is not
currently used. See my notes in post 2 about voltage control.
cpu-tegra: let's skip the temporary downclock and kernel log spam if the
custom Dynamic EDP throttle is not currently enabled.
ARM/VFP compiler optimization
compilation: fix annoying and serious warnings (thanks faux123!)
video: tegra: host: Fix error case memory leaks
When a submit fails, the related nvhost_job is not freed. Add an
explicit free. Also, 3D is mapping the save buffer, but it is not
unmapped (Nvidia)
mm: Ensure pte and pmd stores ordering (Nvidia)
Get rid of some more kernel log spam.
HACK: block fbearlysuspend to not break androids crt-off animation
(thanks codeworx, drewis (repo) and aaronpoweruser for pointing it out). This is untested (by me), but this may help with ROMs that
have this functionality (AOKP etc.)
cpu-tegra3: modified the hot-plug governor down_delay to be 1s
instead of 2s
stable v1.0.6 - build #47/48
GPU clock increased to 484MHz - Nenamark2 scores of 61+
More compiler optimizations (-fmodulo-sched, -fmodulo-sched-allow-regmoves, -funswitch-loops, -fpredictive-commoning, -fgcse-after-reload, -ftree-vectorize, -floop-interchange, -floop-strip-mine, -floop-block, -mfpu=neon )
Now using Koush's AnyKernel delivery method. Uses your existing ramdisk so you can easily use with any ROM.
stable v1.0.5 - build #39
Honor your max frequency fix - no more spikes
alpha v1.0.4 - build #38
Fixes units that can't OC (process_id = 3)
Linaro 4.7.1 toolchain -O2 (2012-06-25)
Increased panel clock rate - increases fps without further GPU clock Nenamark2 scores 59.6 best score so far for Nexus 7
ramdisk added back in boot 1.3GHz, but device still spikes to max allowed CPU freq sometimes (see update below, will be fixed in 1.0.5)
Minor clock and voltage adjustments - should run a bit cooler and use less battery.
Added GPU OC compile switch in case we want a non-OC GPU build.
Added some VPN/networking capabilities for those that need it (L2TP, IP_GRE_DEMUX,INET_AH, INET_XFRM_MODE_BEET)
Some unnecessary debugging options turned off. Should save kernel RAM usage.
Some say it made wifi signal stronger again for them, but I never had any issues. Might be the toolchain and its effect on the broadcom driver. Reports that it is better are fine with me!
alpha v1.0.3 - build #17
UV support, minor voltage adjustments
V(R) i/o scheduler added
ramdisk removed custom init.rc line...hope this will fix the stock units that weren't booting!
alpha v1.0.2 - build #6
Mild GPU OC from 416 to 446MHz - baby steps...its been rock solid so far. NenaMark 2 scores are up from 55 to 57.2fps. A future release may have two versions, one with GPU OC and one without.
Upgraded toolchain to GCC v4.6.3 optimized google version by ezterry, see http://forum.xda-developers.com/showthread.php?t=1686310)
alpha v1.0.1 - build #4
Limit frequency to 1.3GHz on boot. It can then be OC'ed from there. This should make it safer for those that can't OC or don't want to.
Changes to allow OC for Process ID's 0 and 1. Theoretically, these should be earlier release versions like IO and earlier.
alpha v1.0.0 - build #1
This initial alpha release is working well on a Nexus 7 16GB (Speedo ID 7/Process ID 2) on JB 4.1.1. There are no open issues that I know about. Looking for some advanced users and testers to give some feedback, and then we can hopefully make it even better!
Thanks to:
fordwolden - for his generous donation of a Nexus 7
Google and Asus for releasing a nice, open, and inexpensive tablet for the masses.
drewis (Andrew Sutherland) - for the base kernel on github
paulobrien - thanks for the CWM touch recovery
birdman and FadedLite for their Unlock\Rooting instructions
clemsyn for his ideas and insight
Git repo:
https://github.com/motley-git/Kernel-Nexus7
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
(http://www.gnu.org/copyleft/gpl.html)
More info
last_kmsg
Please provide the dmesg output or last_kmsg if you experience any issues (random reboot or crashes) that you think are attributed to the kernel. I ask that you please test with the default/stock kernel first for your rom before you blame the issues on this kernel. Wait for the tab to reboot, or if it doesn't wait long enough so you can capture a good log. If you place this on your /sdcard, it will be easy to capture. Boot into recovery, flash this zip, and then flash a known kernel that works. Then reboot, and go grab the last_kmsg in /sdcard.
View attachment LastKMESG.zip (thanks go to CekMTL, I always keep this handy since you gave it to me!)
Voltage Control
What is voltage control?
It is simply allowing for the cpu voltage to be changed on the fly for each frequency step. CPU voltage is typically lowered (undervolting) for certain frequency steps to conserve power. For an overclocked device, some devices need more juice to be stable than others. Voltage control allows others not to pay this penalty and they can lower the voltage as they see fit for their device and usage needs.
Is undervolting safe?
If the lowered voltage values you enter are stable for the tablet, then absolutely it is safe.
What are the benefits?
Better battery life and less heat
Additional Info on voltage control
Only System Tuner is displaying the DVFS table frequency labels correctly and I recommend that you use this if you want to play with voltage control. SetCPU is showing the scaling frequencies when it displays them in the UI, some of which are for the LP core. This is not correct and is misleading, so it is best not to use it for this kernel.
Since the tools available only allow for tweaking one DVFS table (the high powered G cores), voltage control is not currently possible for the LP core. It is not needed anyhow IMO and setting it too low could result in SOD. There is more battery saving to be had with the G cores anyhow if you are into this sort of tweaking.
The frequencies shown may have two values for one frequency. This is how it came with the factory kernel as well and I have only tweaked the top end of the DVFS table. It may seem weird, but this gives us direct access to the DVFS table. I would recommend keeping it as a staircase, just like Nvidia has it even though some frequencies are listed twice.
The freqs shown in the System Tuner display will match the DVFS table for the cpu_process_id for your tablet (seen in the kernel log at startup). All tablets won't display the same frequencies. There are at least two maybe three or four variants we have found so far for the Nexus 7 with Tegra 3 SoC #7.
Also, some may not know, but the tegra3 kernel also has automatic UV using a "cold" zone in where 50mV undervolting is done automatically when the cpu is cool. Take this into consideration when playing around.
GPU OC
Valid max GPU frequency is 416 - 520 MHz. If you try higher or lower clock speeds, it will fail and remain unchanged.
Examples:
Code:
echo 484 > /sys/devices/system/cpu/cpu0/cpufreq/gpu_oc
Code:
echo 520 > /sys/devices/system/cpu/cpu0/cpufreq/gpu_oc
Performance Tweaks
These are a couple of tweaks that many are using for faster benchmarks and better battery performance. Google it and decide for yourself if you like the risk or not. I recommend that you do a full backup in recovery and regularly backup your /data partion or cloud sync if you enable these options. Will many run them daily as I now do, there is some additional risk. These can be added to scripts and automated via init.d or other apps/tools that support them.
To disable fsync for better battery and better disk i/o performance:
Code:
echo 0 > /sys/class/misc/fsynccontrol/fsync_enabled
To enable fsync for better data integrity (default)
Code:
echo 1 > /sys/class/misc/fsynccontrol/fsync_enabled
Faster disk i/o - remount /data partition with noauto_da_alloc option (google it, better battery, less data integrity)
Code:
mount -o remount,noauto_da_alloc /data /data
TCP Congestion Control Algorithms
Only one can be set at a time, so only add one of the lines to your script. Here are some examples:
Code:
echo "reno" > /proc/sys/net/ipv4/tcp_congestion_control
echo "veno" > /proc/sys/net/ipv4/tcp_congestion_control
echo "vegas" > /proc/sys/net/ipv4/tcp_congestion_control
echo "westwood" > /proc/sys/net/ipv4/tcp_congestion_control
zRAM
What is zRAM?
This is a mainline kernel feature for Compressed RAM block device support (CONFIG_ZRAM)
http://en.wikipedia.org/wiki/ZRam
Like many of the other tweaks done in the Android world, ZRAM is another one of them that is controversial, probably because people only think in terms of immediate performance they can measure easily with benchmarks etc. *Here is my take...think I will add this to the Q&A section as well.
But, will it make my device faster? Will I score higher on benchmarks?
It depends, but for normal usage, the answer is no. zRAM is most useful for those that are configuring Android to be a true multitasking workhorse. For example, if I enable zRAM, open an bunch of apps at one time, and actually start to work towards depleting the memory of the system. *For example, say I open system tuner, a browser with several tabs, a word processing app, a game, and perhaps a picture viewing app or a movie. If I don't formally close out of each one by hitting back and just begin switching between apps and the home screen, you will see zRAM start showing benefits.*
If you tweak the Android memory and swappiness settings, this can also be useful in this type of environment.
How do I know it is initialized and working?
You can type "free" from an command line and see the swap space.
Also, you can look at the disksize to see if it is initialized
cat /sys/block/zram0/disksize
To see how much it is being used in your environment, you can look at the output from:
cat /sys/block/zram0/num_writes
cat /sys/block/zram0/num_reads
So, unless you have a heavy workload as stated above, then it won't be of a lot of use for normal Android users.
How do I enable zram?
It must be enabled by a script. Some ROMs may support activating it. If you need to do it yourself you have two choices.
1) Save this to a file and run the script from terminal, Script Manager or System Tuner.
2) Or better yet, save this to a file called 90zram (or whatever you prefer) in /system/etc/init.d and automate it (The ROM's ramdisk needs to supports init.d)
Code:
#!/system/bin/sh
# auto zram activation init script with busybox search
# by show-p1984
echo "[90ZRAM]: Firing up /system/etc/init.d/90zram";
if [ ! -e /sys/block/zram0/disksize ] ; then
echo "[90ZRAM]: ERROR unable to find /sys/block/zram0/disksize";
echo "[90ZRAM]: Is this a ZRAM kernel?";
echo "[90ZRAM]: ZRAM NOT ACTIVATED. (404)";
else
#find busybox in /system
bblocation=$(find /system/ -name 'busybox')
if [ -n "$bblocation" ] && [ -e "$bblocation" ] ; then
echo "[90ZRAM]: busybox found in:" $bblocation;
echo "[90ZRAM]: Setting ZRAM disksize.";
echo $((100*1024*1024)) > /sys/block/zram0/disksize
echo "[90ZRAM]: Starting ZRAM...";
bblocation=${bblocation%/*}
cd $bblocation
./busybox mkswap /dev/block/zram0
./busybox swapon /dev/block/zram0
echo "[90ZRAM]: ZRAM activated.";
else
echo "[90ZRAM]: ERROR! busybox not found!";
echo "[90ZRAM]: Is busybox installed? Symlinks set?";
echo "[90ZRAM]: ZRAM NOT ACTIVATED. (404)";
fi
fi
Flashed with CWR and it doesn't boot past the Google screen Is there something special I need to do?
*Edit*
I am on the new 4.1.1 "D" or whatever but right now I'm using the Atlantis "1.5" kernel and it works so I donno.
Thanks for another addition to the nexus 7 kernel community, love having different kernels to try.
Clienterror said:
Flashed with CWR and it doesn't boot past the Google screen Is there something special I need to do?
*Edit*
I am on the new 4.1.1 "D" or whatever but right now I'm using the Atlantis "1.5" kernel and it works so I donno.
Click to expand...
Click to collapse
Thx, please grab the dmesg output while booting or last_kmsg if you can. Working fine here, but this why I put it out as an alpha. Even if you boot off another kernel, if you can send a dmesg captured right after boot, that would help so I can see your SoC/Process ID numbers. There are two lines written just after boot with the info. On the Prime, we had different CPUs in some models, but it may just be a voltage issue. I have run Antutu and Quadrant several times without issues though. Not sure about the D update...I I have 4.1.1.
Edit: Version 1.0.1 released, please test again and leave feedback when you can. Please let me know when you received your tab. Is it an early IO version? If this doesn't do it, I most likely will need to increase voltages a bit. Hopefully I won't have to do this so we can keep battery life at it's best.
oh s^&*, you developing here also. oh yeah! glad to see you here buddy. so you have your nexus 7 already? now that i see you here also, i will be unlocking my nexus 7, once it arrives, sooner than i thought. welcome aboard...glad to see familiar faces around here
I had the same issue. Couldn't pass the boot screen after flashing. On 4.1.1 latest update as of July 15th
Sobai said:
I had the same issue. Couldn't pass the boot screen after flashing. On 4.1.1 latest update as of July 15th
Click to expand...
Click to collapse
Thanks, I am dying to take a look at a log to see how I am so lucky to have it working! I've added LastKMSG.zip to the OP. If someone with a booting problem can do the following, I would really appreciate it:
1) Put LastKMSG.zip on your /sdcard along with the newest kernel zip
2) Flash the kernel zip
3) Wait for it to boot, give it a few seconds and then hold power down to reboot if it doesn't do it on its own.
4) Go back into recovery and flash LastKMSG.zip
5) Flash another booting kernel or your current rom to recover.
6) Boot and retrieve the file /sdcard/last_kmsg
7) Attach the log here or PM me with a dropbox link or whatever.
Thanks!
Just got some good news from a gentleman that didn't have enough posts to share with us here yet, so he PM'ed me and said that I can share the details of his experience.
First report was more of the same, sounded familiar, more bad news...
Flashed your kernel and couldn't boot pasted Google screen. Restarted in to boot and couldn't get into recovery. Was stock rooted on the latest 4.11. Went back to stock. Looking forward to trying again, now I'm on Modaco's latest. I'll let you know how it goes.
Next report was good using the latest version in the OP. Not sure, but this may help others.
Thanks! This kernel is fantastic! Makes this thing a real beast! Sorry I didn't give you the info you asked for! I got it Thursday from GameStop. The problems may have stemmed from the fact that I updated to 4.11 , rooted then side updated the newest little update and then ran a su zip to regain root (Paul o' Brian ROM) . I was also on his first cwm and then updated to his new one after I started from scratch. Loaded up his new ROM, rebooted then applied your 2nd kernel and this thing is hitting 15626 in CF benches!
Not sure what is going on, but I can't explain it. It may be my 2nd version of the kernel that fixes it, but I am not sure since I haven't seen a log yet. I suppose something may be jacked up with the early versions of recovery or roms, but the I was using the the same early versions when I tested just fine....maybe folks are losing recovery and don't realize it? I did the second step to keep recovery that is now automated in r2. If anyone has any ideas, let me know.
New version released
New version released...see OP. GPU OC to 446MHz (up from stock 416)
Looking for more feedback
_motley said:
New version released...see OP. GPU OC to 446MHz (up from stock 416)
Looking for more feedback
View attachment 1204164
Click to expand...
Click to collapse
Just out of curiously, would you ever try 520mhz for the gpu, to try to get it to t30 speeds? Or maybe would you consider some kind of app interface like extweeks for the galaxy s2 & s3 to control the GPU clock speed and maybe voltages instead of different kernels. As I would personally love to get the GPU to about 460-500mhz Anyway when I get my n7 (hopefully in a day or two) I can't wait to try this out (I am spoilt by the much more powerful 440mhz mali-400mp in the s3, so I would love to try to narrow the power difference between the devices GPU wise)
Nice man! The new versions fixed everything boots great! Now if we can just figure out how to make the Overclock stick after you turn the screen on/off. I'm not sure how to tell if the GPU OC is sticking.
Sent from my Nexus 7 using xda app-developers app
danielsf said:
Just out of curiously, would you ever try 520mhz for the gpu, to try to get it to t30 speeds? Or maybe would you consider some kind of app interface like extweeks for the galaxy s2 & s3 to control the GPU clock speed and maybe voltages instead of different kernels. As I would personally love to get the GPU to about 460-500mhz Anyway when I get my n7 (hopefully in a day or two) I can't wait to try this out (I am spoilt by the much more powerful 440mhz mali-400mp in the s3, so I would love to try to narrow the power difference between the devices GPU wise)
Click to expand...
Click to collapse
Sure, we may push the GPU OC version a bit, but I always like to walk before we run to see how things go. I would like to monitor heat output, battery usage etc. and then move forward in steps. I am very happy with it right now, but dynamic configuration would also be cool. Let me know what you think once you have it hand.
Clienterror said:
Nice man! The new versions fixed everything boots great! Now if we can just figure out how to make the Overclock stick after you turn the screen on/off. I'm not sure how to tell if the GPU OC is sticking.
Click to expand...
Click to collapse
Awesome, glad to hear it! I don't think I see this issue with the OC sticking after you turn the screen off/on, but I will do more checking after work today.
_motley said:
Awesome, glad to hear it! I don't think I see this issue with the OC sticking after you turn the screen off/on, but I will do more checking after work today.
Click to expand...
Click to collapse
Thanks a ton! Yea if you go into setcpu and make it 1.6 then turn the screen off then on (unlock) set CPU slider still shows 1.6 but if you read under that the smaller text says its actually set at.1.3 again. It seems to be a problem with the Atlantis kernel also something to do with hardcoded CPU freqs I think. Oh I wanted 5k soooo bad rofl got this twice rofl.
Sent from my Nexus 7 using xda app-developers app
Clienterror said:
Thanks a ton! Yea if you go into setcpu and make it 1.6 then turn the screen off then on (unlock) set CPU slider still shows 1.6 but if you read under that the smaller text says its actually set at.1.3 again. It seems to be a problem with the Atlantis kernel also something to do with hardcoded CPU freqs I think. Oh I wanted 5k soooo bad rofl got this twice rofl.
Sent from my Nexus 7 using xda app-developers app
Click to expand...
Click to collapse
I've just made profiles that automatically set the clock to 1.5 when the screen turns on again and back to 1.5 when the screen turns off.
Edit*
Just tried the newest version and it failed to boot. Got stuck at the Google Logo. Here is the last_kmsg. Hopefully it helps
(had to put a .txt extension on it btw. Uploader wont let me upload w/o extension)
The Nexus 7 GPU is better than the Transformer Prime due to the faster RAM, so more bandwidth? If I'm correct? Thats why we see a higher Nenamark score at a lower clock?
This kernel looks very promising, excellent work! How much "play" have you had with upping the voltages, before the battery quits? On my TF, I can only go so far before the battery cannot provide enough juice, and it freezes on me. It would be interesting to know for people who want to OC really high. Does anything above 1.6 GHZ actually boot (heat and battery drainage aside)? It would be nice to OC up to 2.0 GHZ, if only for a proof-of concept. Finally, what are the temps you are getting on the higher clocks? It sounds like overheating may start becoming a real issue, and I was just curious.
The ram disk version rendered my tablet unbootable had to flash the Atlantis kernel from fast boot to get it back up and running.
Sent from my Nexus 7 using Tapatalk 2
Good work there, I would suggest adding Smartassv2 as well since it has been a good choice for many dev
I for the life of me can't get this kernel to OC. Tried System Tuner, Setcpu etc. Max only reads 1300mhz nothing shows higher beyond 1300. I have no clue what the deal is. I've tried wiping also. Even tried Atlantis' kernel. on his, it won't allow me to set anything. Max shows 0 and Min shows zero. I am running Pauls Modaco Jr3 and even tried it on EOS' new release. I'm beginning to wonder if its something diff internally. Anyone have any guesses?Also showing root as setcpu requests superuser permissions.
This is what my device shows
Board: grouper
Product: nakasi
Model: Nexus 7
Device: grouper
Build: JRO03D (Modaco Custom ROM Jr3)
google/nakasi/grouper:4.1.1/JRO03D?402395:user/release-keys
Manufacturer:asus
Brand:google
CPU ABI: armeabi-v7a
Kernel
Linux version 3.1.10-motley+([email protected]) (gcc version 4.6.3 (GCC)) #6 SMP
PREEMPT Tue Jul 17 00:52:59 EDT 2012
Page 1: Information
Page 2: Changelog and Downloads
Page 3: Additional info and FAQ
Instructions:
Make sure you are on the latest bootloader version before flashing this or any other custom kernel. Search for a flashable zip or use fastboot and the google factory images.
Download Kernel to internal SD card. Flash in recovery. Reboot. Congratulate yourself for wisely installing the best nexus 7 kernel.
A complete list of changes is available at my Github.
Source: https://github.com/Metallice/android_kernel_grouper
Recommended Settings:
The only app supported for changing any kernel parameters and settings is TricksterMod - https://play.google.com/store/apps/details?id=com.bigeyes0x0.trickstermod
CPU governor - TouchDemand with default parameters (default)
I/O Scheduler -
- ROW for pure read speed. Fast reads which are often the most important on mobile. Similar concerns like deadline.
- BFQ for more consistent performance. Slower than Deadline and ROW, but prevents stutters while downloading in background
Max Frequency - 1.2Ghz (Stock max for 2+ cores) (for lollipop it might be a good idea to use 1.3Ghz)
- Note: Tegra sets the max frequency to 1.5Ghz at boot, make sure to change it manually or have an app set it at boot to avoid battery loss. If you have a program such as
TricksterMod set it at boot make sure to include at least a 60 second "delay" in applying boot settings.
- Note 2: DO NOT USE THE APP "SYSTEM TUNER" TO SET FREQUENCIES. CONFLICTS WITH AUDIO PERFLOCK IN KERNEL. Do NOT use system tuner to set frequencies as it conflicts with audio performance lock in this kernel. Will prevent you from lowering your maximum frequency. Use Trickstermod.
GPU Max Freq - 446Mhz (maintains good battery life while smoothing out some games. Anything greater than 446Mhz is so heavily bottlenecked by RAM that it's essentially worthless. 600Mhz might give you 1 or 2 extra FPS for significantly worse heat, battery life, and stability)
- Possible frequencies - To be completed later
Fsync - On
Dynamic Fsync - On (be aware of data loss concerns, even if they actually are minimal.)
SmartDimmer/PRISM - On (off for a63 and lower)
zRAM - off/none (default) (For lollipop it may help with multitasking at the price of speed, although you really shouldn't be trying to heavily multitasking with a 2012 N7 anyway) (Not very useful on android 4.x with >=1GB RAM, for lollipop it's not really helpful >=3Gb)
Data remounting scripts - already included in ramdisk. Additional scripts not needed.
I DO NOT RECOMMEND, nor will I support, any kind of optimization/superdupercharge/placebo script. All settings are already optimized in kernel and ramdisk. Using these scripts or tweaks will only lead to problems and performance degradation.
__________________________________________
If you'd like to buy me some caffeine so I can continue to fit studying and kernel-ing in my busy schedule, feel free to donate below. Thanks so much for all of your support! Clicking the thanks button is always appreciated too
Alpha Changelog (stable feature list above):
a77 - remove CM12.1 specific stuff from ramdisk
a76 - Fix for 5.1
a75 - 5.1 Lollipop update and patches
Click to show complete changelog
a74 -
Fix for TricksterMod. Sync with cm12 ramdisk. Fake update dmcrypt to allow TRIM on encrypted devices (untested). Set ROW as default scheduler.a73 -
Lollipop! Updated toolchain. Removed touch2wake due to the wakeup issues it created for some. Other stuff.a69 -
Quick fix to allow overclocking on stock roms.
a68 -
Update to latest 4.4.3 kernel source
Sync with latest CM 4.4.3 ramdisk
Update to 4.8 toolchain
F2FS support
Zip installation supports all permutations of ext4/f2fs layouts
Based on work by frantisek.nesveda, but modified to support all layouts and be more flexible
Make sure to go to his thread -HERE- and click the thanks button!
Upgrade to BFQ v7r4
Adjust touchboost values
Enable Kernel Samepage Merging - I've gone back and forth on this. For now, enabled.
Probably some other changes I'm forgetting.
a67 - Update + sync ramdisk from cm11 to enable native USB OTG. Add thermal charging shut off. Some kconfig tweaks.
a66 - Only hold wakelock is touch/slide to wake is enabled. Tweak default BFQ values a bit.
a65 - Update BFQ from 5.1 to 6r2. Set BFQ as default for testing. Tweak Deadline and CFQ (Franco's CFQ values). If CFQ is still causing reboots for some, I will revert it to stock in next build. Cgroups timer slack controller. Enable RCU priority boosting for testing.
a64 - merge 4.4 kernel changes. Update ramdisk for 4.4
a63.1 - CM hotfix
a63 - Add Tegra 4 SmartDimmer (ported from TripNRaVeR's port for the One X). It either works much better or is completely broken. Either way, it's an improvement from the old SmartDimmer. Add necessary ramdisk change for PAC rom. Add dm9620 usb ethernet support. Switch back to linaro 4.7 toolchain from google 4.6 (used in mr2 for stability reasons).
a62 - Add double tap to wake thanks to flar2 and sgt. meow. Add configurable timer to keep double tap to wake active after screen shut off. Remove Fsync toggle. Pointless and confusing with Dynamic Fsync available now. Update Dynamic Fsync from faux123. Set backlight levels back to defaults and disable otf_scaling. Some random stuffs.
New sysfs:
/sys/android_touch/wake_timeout
Value is in seconds. Defaults to 60. Set to 0 to keep double tap to wake permanently active at the price of battery.
a61 - Enable compass driver. Add Dynamic Fsync by Faux123. Disable Fsync off at boot. Enable Dynamic Fsync at boot. Remove wifi pm fast/max toggle as it is now pointless and won't work since 4.3 kernel update. Add an older, but simpler, version of usb host mode by mehrvarz. Fixed and enabled many 4.3 config options relating to things like selinux.
a60 - More ramdisk fixes
a59 - Update cm10.2 ramdisk to fix storage issues. Fix 00su init.d.
a58 - Incorporate cm10.2 ramdisk.
a57 - Update to 4.3 kernel base. 4.3 stock only. Ramdisk base courtesy of Francisco Franco. Fsync off at boot since the internal storage is just so appallingly slow.
a56 - Add back some missing config options removed in a55 to support various features. No CIFS support. Couldn't get it to boot for some reason.
a55 - Add v2 of Tegra AHB patch set. Remove and revert USBHOST patches. Revert to almost stock kernel config for testing (will probably revert back later). Revert to stock PA ramdisk for testing. Tweak default TouchDemand parameters for bettter performance. Hard-code deadline and cfq tuneables thanks to the work by those in Franco's thread - details in commitlog on github. Set deadline as default I/O scheduler. Add core hotplugging lock during touch boost/input to interactive governor based on implementation in stock interactive governor (not fully tested). Other minor, inconsequential changes.
a54 - Remove AHB bus drivers and patches.
a53 - USBHOST support and patches. WiFi adhoc IBSS support.
a52 - revert voltage table changes
a51 - fix flickering at brightness level 13 when smartdimmer was enabled by setting SD min to 10. Re-enable a 3g modem reset assignment fix. It was disabled in a49/a50; let's see if re-enabling it causes 3g drops to return (Otherwise TCP proportional rate reduction was the cause). Re-enable wifi p2p patch that was disabled in a49 under the impression it wasn't included in the stock kernel when it actually is (whoops). Increase the some DVFS voltages so that that they are at least as high pre-a50 (according to DVFS debug showing actual running voltage) and not more than 25mV greater than pre-a50. Hard-code default pm_qos_max_cpus as 4 instead of ULONG_MAX. Fixes aesthetic bug where the default tegra hotplug max_cores was 2147483647 (For the curious - it is 2^31 − 1, the maximum value for a 32-bit signed integer in computing).
Oh, and change thread title to accord with new XDA requirements.
a50 - re-enable dynamic edp. Rework some edp limits. Rework DVFS voltage tables to better match frequencies, YMMV. Removed 1.7GHz max frequency option as it was pretty split whether your device could run it or not. If people were more responsible and wouldn't complain about issues when running 1.7 or higher I would leave it in, but unfortunately that's just not the case. So it saves me headaches in the future. Sorry. It's a minor increase from 1.6GHz and most can do 1.6 just fine.
a49 - add some rwsem patches. Revert TCP proportional patch. Revert a wifi p2p patch. Fully stock /net and drivers/net in source now. Add custom min/max backlight interface. I'll add more info when I'm not so busy. Removed zRam support.
Change your max backlight (min - 255) - /sys/module/board_grouper_panel/parameters/max_backlight
Change your min backlight (1 - max) - /sys/module/board_grouper_panel/parameters/min_backlight
Enable/Disable on-the-fly backlight level redistribution through available brightness slots based on new min/max using math below (0/1) - /sys/module/board_grouper_panel/parameters/otf_scaling
- brightness = min_backlight + DIV_ROUND_CLOSEST(((max_backlight - min_backlight) * max((brightness - 10),0)),245);
a48 - actually upload a kernel that is mr1 + row patches + flash fix
a47 - mr1 + row patches + flash fix accidentally uploaded old kernel version...
a46 - disable have_efficient_unaligned_access. Add USB Host mode charging patches.
a45 - Fix adobe flash corruption. Add ARM unaligned access and enable have efficient unaligned access. Make sure slider min brightness and auto-brightness min have the same backlight value.
a44 - Start over at mr1. Add ROW patches. Add LZ4 compression.
a43 - revert all network and wireless patches since mr1.
a42 - revert some config options. Fix fixed_mode on boot for multiboot. Sched_mc_power_savings set to 0 instead of 2 to see how it affects wakeup.
a41 - ARM cpu topology and relevant patches. Enable multi-core scheduling. Enable maximum multi-core scheduling power savings for testing. Switch back to LZ4 ramdisk compression as Multiboot supports it now. Increase touchdemand sampling down factor since sampling rate was decreased previously.
a40 - Revert SLQB. Add latest usb host mode charging from mehrvarz's repo. Force detect/report usb as ac, no apparent benefit. Enabled a config SVIPC or something... I forget. Enabled rndis support from CM.
a39 - SLQB allocator. Switch back to Gzip ramdisk compression for multirom.
a38 - Fix adobe flash playback. Super fast Lz4 compressed for ramdisk and kernel. Arm unaligned efficient memory access. Some misc. wifi and network patches. Many other changes. No guarantees.
__________________________________________________
Downloads:
Alphas 5.1 -
a77 - https://www.androidfilehost.com/?fid=23991606952601904
a76 (CM12.1) - https://www.androidfilehost.com/?fid=23991606952601166
Click to show downloads for older versions of Android
Alphas 5.1 -
a75 - https://www.androidfilehost.com/?fid=95916177934553111
Alphas 5.0 -
a74 - https://www.androidfilehost.com/?fid=95916177934528566
a73 - https://www.androidfilehost.com/?fid=95784891001616369
Alphas 4.4 -
a69 - http://d-h.st/kI7
a68 - http://d-h.st/gPV
a67 - http://goo.im/devs/Metallice/Nexus7/4.4.x/M-Kernel_a67.zip
a66 - http://goo.im/devs/Metallice/Nexus7/4.4.x/M-Kernel_a66.zip
a65 - http://goo.im/devs/Metallice/Nexus7/4.4.x/M-Kernel_a65.zip
a64 - http://goo.im/devs/Metallice/Nexus7/4.4.x/M-Kernel_a64.zip
Milestone 4.3.x Releases -
mr2 (4.3.x)
http://goo.im/devs/Metallice/Nexus7/Milestones/M-Kernel_mr2.zip
Alphas 4.3 (post mr2) -
a63.1 - http://goo.im/devs/Metallice/Nexus7/4.3.x/M-Kernel_a63.1.zip
a63 - http://goo.im/devs/Metallice/Nexus7/4.3.x/M-Kernel_a63.zip
a62 - http://goo.im/devs/Metallice/Nexus7/4.3.x/M-Kernel_a62.zip
Alphas 4.3 (pre mr2) -
a61 - http://goo.im/devs/Metallice/Nexus7/4.3.x/M-Kernel_a61.zip
a60 - http://goo.im/devs/Metallice/Nexus7/4.3.x/M-Kernel_a60.zip
a59 - http://goo.im/devs/Metallice/Nexus7/4.3.x/M-Kernel_a59.zip
a58 - http://goo.im/devs/Metallice/Nexus7/4.3.x/M-Kernel_a58.zip
a57 - http://goo.im/devs/Metallice/Nexus7/4.3.x/M-Kernel_a57.zip
Milestone 4.2.x Releases -
mr1 (4.2.x)
http://goo.im/devs/Metallice/Nexus7/Milestones/M-Kernel_mr1.zip
Alphas 4.2.x -
a56 - http://goo.im/devs/Metallice/Nexus7/4.2.x/M-Kernel_a56.zip
a55 - http://goo.im/devs/Metallice/Nexus7/4.2.x/M-Kernel_a55.zip
a54 - http://goo.im/devs/Metallice/Nexus7/4.2.x/M-Kernel_a54.zip
a53 - http://goo.im/devs/Metallice/Nexus7/4.2.x/M-Kernel_a53.zip
a52 - http://goo.im/devs/Metallice/Nexus7/4.2.x/M-Kernel_a52.zip
__________________________________________________
Legacy downloads available at http://goo.im/devs/Metallice/Nexus7
THIS POST/GLOSSARY NO LONGER UPDATED DUE TO TIME CONSTRAINTS
Glossary of terms:
(that one may not be as familiar with as things like CPU and GPU)
Hotplugging - the process of turning CPU cores on and off.
G core(s) - One of four ARM A9 CPU cores found in the Tegra 3 SoC
LP (core) - The ARM A9 "Low-Power" CPU core found in the Tegra 3 SoC in addition to the 4 G cores. The LP core, contrary to what many seem to believe, does not run in tandem with the 4 G cores.
Runnable Threads (hot plugging) - Limits turning on more cpu cores based on the average number of running threads
Touchdemand - A modified ondemand-based governor that I designed and configured to better suit the Tegra 3 and android based on my observations
Variant -
Scheduler -
Other things
FAQ:
What's the difference between the mr(#) version/download and the a(#) version/download? Which should i download? What do these acronyms mean/stand for?
The mr# (ex. mr1) stands for milestone release number #. The milestone builds are the stable, bug-free, and thoroughly, extensively, and expansively tested builds of m-kernel.
The a# (ex. a38) stands for alpha build number #. The alpha builds listed under downloads are all of the alpha builds after the latest milestone build listed in reverse chronological and "morphological" (? FIX) order. It is the continuation of the "alpha branch" of m-kernel, and is basically the latest milestone with a ton of patches, fixes, and changes that are completely UNTESTED by anyone but me. The number and substantiality of changes since the latest milestone obviously vary and also depends on the number of alpha builds since the latest milestone release. An alpha build isn't guaranteed to be stable, working, and bug-free. They are testing builds leading up to the next milestone
Do you recommend setting the maximum number of cores to 2?
I don't necessarily recommend everyone do this, for it really comes down to personal preference. However, limiting the maximum cores to two is a very simple change to make that will slightly improve battery, with little to no impact on performance. Android 4.x is highly optimized for dual-core processing. There is no part of the Android 4.x OS that needs more than 2 cores for a smooth experience, and likewise there are few to no android applications that need 2 cores.
For the most part, the 3rd and 4th g cores are only activated during time sensitive actions such as opening an app for the first time (i.e. not previously opened and cached in RAM) and during screen rotation. These are short lived operations meaning those 3rd and 4th g cores are quickly turned off afterwards. In essence a small hit to battery life for even smaller benefits.
Why won't my minimum frequency go below 340MHz?!?
As long as you don't use system tuner, the minimum frequency does go below 340MHz. The minimum frequency is temporarily raised to 340MHz during an audio event to prevent audio playback problems when using ondemand and similar governors. The minimum frequency returns to the previous value afterwards. Some apps may show the minimum frequency as 340MHz because clicking the app to open it created a sound causing the minimum to temporarily rise. The app does not change when the minimum frequency goes back to its previous value.
Why can't over clock the GPU as high as I can on other kernels!?!
You can. You have to raise the voltage for the top GPU slot. Other kernels do this automatically and to fixed values. The amount necessary depends on the GPU frequency you are trying to run and your device. No devices are alike and the voltage necessary at whatever frequency will vary considerably from device to devices. Be aware that having to overvolt to run a certain frequency may mean suggest that you shouldn't run that frequency anyway. Raising the GPU frequency and voltage has risks to consider
What is this tegra 3 "variant" or whatever? How do I find it? What does it meeeeaaaannnn??!!?
You can find this info in /sys/kernel/debug/t3_variant
In the stock kernel/source, each device sku is recognized and assigned four ID values. For the CPU there is a primary "cpu speedo id" and a secondary "cpu process id". For the SOC, or core (think LP core, RAM, GPU, etc), there is a primary "soc speedo id" and a secondary "soc process id."
Each "pair" of ids is used to choose the respective voltage tables for the components they represent. I'm going to ignore the soc/core ids as they aren't relevant to my point and are the same for all our devices.
The CPU voltage tables are represented by ( cpu_speedo_id # , cpu_process_id #). The voltage tables that share the same first number, the cpu_speedo_id, all end with the same MHz value. To make things simple, Tegra uses the maximum frequency in the voltage table to determine the maximum frequency. All of our Nexus 7 Tegra 3s share the same cpu_speed_id, corresponding to a maximum frequency of 1.3GHz.
The second number, the cpu_process_id, differs between all of our N7 T3's. Faux123 and everyone refers to value as our "variant." This value, cpu_process_id determines the voltages for each frequency in the table. For each increase in cpu_process_id, the RANGE of voltages for the voltage table is compressed by 25mV (i.e. the voltage for the top frequency is decreased by 25mV while the bottom stays at 800mV and the middle frequency voltages are adjusted accordingly).
Therefore, in a direct sense, the cpu_process_id, or "variant", HAS NOTHING TO DO WITH CPU FREQUENCY. I'll repeat this. YOUR CPU_PROCESS_ID OR VARIANT HAS NO DIRECT CONNECTION TO THE MAXIMUM FREQUENCY CAPABILITIES OF YOUR CHIP. Variant/cpu_process_id refers to the voltage tolerance of your cpu. While there may be correlation or secondary connection to the maximum frequency capabilities of your chip, there is not direct connection. Additionally, cpu_process_id HAS NOTHING TO DO WITH YOUR SOC/CORE AT ALL, WHICH INCLUDES YOUR GPU/LP/RAM. A high cpu_process_id tells you nothing about your core and how high you can clock your GPU.
TL;DR - Variant, or more accurately cpu_process_id, refers to voltage tolerance, and has no direct connection to the max frequency abilities of your chip, and definitely has absolutely no relationship to your core/GPU.
To do:
Core voltages quirks.
Max freq delay necessity.
Why doesn't the kernel come with recommended settings?
One more
Re: [Kernel[3G+Wifi] M-Kernel - mr1
Sweet will flash this and give you some results later
Sent from my VS920 4G using Tapatalk 2
Re: [Kernel[3G+Wifi] M-Kernel - mr1
azoller1 said:
Sweet will flash this and give you some results later
Sent from my VS920 4G using Tapatalk 2
Click to expand...
Click to collapse
+1 I got a good feeling about this one
Sent from my SGH-T999 using xda app-developers app
tdizzle404 said:
+1 I got a good feeling about this one
Sent from my SGH-T999 using xda app-developers app
Click to expand...
Click to collapse
I really hope you're making a joke... I've had a thread in android development for a while now... 37 versions...
Re: [Kernel[3G+Wifi][4.2.2] M-Kernel - mr1
So really there is no need for gpu over clock unless for a benchmark?
Sent from my VS920 4G using Tapatalk 2
azoller1 said:
So really there is no need for gpu over clock unless for a benchmark?
Sent from my VS920 4G using Tapatalk 2
Click to expand...
Click to collapse
Says who? Me? Where?
No of course that's not true. GPU overclock can have benefits. Minimal due to RAM bottlenecking, but it will still marginally imrprove FPS in some cases.
I love your work metallica, we really appreciate it
I remember you made 5(+) different versions just because for 2 people having wifi issues...
You really spend a lot of time at this and this is a great kernel.
Thanks!
Re: [Kernel[3G+Wifi][4.2.2] M-Kernel - mr1
Metallice said:
I really hope you're making a joke... I've had a thread in android development for a while now... 37 versions...
Click to expand...
Click to collapse
No joke here ive had decent results with your kernel I'm just commenting on the update
Sent from my SGH-T999 using xda app-developers app
Re: [Kernel[3G+Wifi][4.2.2] M-Kernel - mr1
Oc GPU to 520 and when I left trickster It blacked out and rebooted
Sent from my Nexus 7 using Tapatalk 2
Nothing to say at the moment but gotta post in it so I get subscribed. Keep up the good work!
I had just posted in the original M-kernel thread and couldnt edit my last post (probably cuz its being moved) . I was unable to set cpu max core to 4 w/o system freezing up. I just upgraded to mr1 and it shows 4 cores active and no freeze ups so far. I will leave everything to stock for now.
Cool you finally moved to "original" forum, makes it alot easier for me to navigate since I am usually in this forum anyways..
thxs
d
azoller1 said:
Oc GPU to 520 and when I left trickster It blacked out and rebooted
Sent from my Nexus 7 using Tapatalk 2
Click to expand...
Click to collapse
Hi, you just need to increase the GPU voltage a little bit before you overclock it to 520mhz, hope that helps
Re: [Kernel[3G+Wifi][4.2.2] M-Kernel - mr1
azoller1 said:
Oc GPU to 520 and when I left trickster It blacked out and rebooted
Sent from my Nexus 7 using Tapatalk 2
Click to expand...
Click to collapse
Maybe you should try reading the FAQ :/
Sent from my Nexus 7 using Tapatalk HD
Re: [Kernel[3G+Wifi][4.2.2] M-Kernel - mr1
Congrats my friend. What a journey!
How,s it feel to be in the big leagues
Edit: mr1 flashed. Keeping it default for now. Seems very smooth. Another excellent kernel. Thank you for everything.
Cheers, FReaKRaNT
Re: [Kernel[3G+Wifi][4.2.2] M-Kernel - mr1
thanks for the hard work the kernel works great and the FAQ was very helpful.
Sent from my Nexus 7 using Tapatalk 2
Απ: [Kernel[3G+Wifi][4.2.2] M-Kernel - mr1
Guys does flash working for u without any problems?
Edit:I'm on Francos kernel now. I just flash this kernel without wipe cache and dalvkin?
Sent from my Nexus 7 using Tapatalk HD
Cool you're in Original Dev now. Congrats Metallice.
Downloading mr1 now. :good:
This is my version of crpalmer's kernel with some additional features:
-Android 5.0 support
-Sweep2Wake/Sweep2Sleep, DoubleTap2Wake (from Beastmode)
-force fast charge (credits to chad0989)
-kexec-hardboot support (for use with MultiROM, credits to Tasssadar for the multirom and the m7 patch I used)
-FauxSound (faux123)
-Moar overclockingz (up to 1890 mhz)
Note: Every chip is different, your device may not support these higher frequencies.
-GPU overclocking (up to 533 mhz) (credits to faux123, )
Note: Again, every chip is different, your device may not support higher frequencies.
-Additional CPU governors and I/O schedulers. Read about CPU governors here.
-Dynamic Fsync (faux123)
-Simple GPU Governor (faux123)
-L2 Cache overclock
-600 MHz bus overclock
-F2FS support (still no luck with getting this fully working, testers are welcome)
-LZ4 compressed kernel (faster boot)
-More TCP Congestion algorithms
-Lots of slimbus improvements thanks to poondog
For maximum performance, I recommend some optimized dalvik libraries (KitKat only):
-For 4.4.4 ROMs, use the "CM11 Dalvik_Final" zip in this post
-For older (4.4.2) ROMs:
-For 4.4.2 CM11-based ROMs released before March 1st, use my Sense dalvik libraries here.
-If you are using a 4.4.2 CM11-based ROM released after March 1st, or any ROM with this commit you will need to use the 4.4_qc-optimized_dalvik-cm11.zip here. Credits to kszaq for this one.
-For LiquidSmooth, use these Sense dalvik libraries here.
-Also, credits to kszaq because these were based on his flashable zip.
If you find any ROMs where none of these zips work, let me know and I will try to make one for that ROM.
I am not responsible for anything that happens to your phone. It is your device and your responsibility.
The following scripts are not required to change settings, they only exist as an alternative for people who don't want to use a third-party app. You can still use your favorite tuner app to tweak most of these kernel settings.
init.d tweaks
I created some scripts that run on boot (init.d) because I install my kernel so many times that I would go insane if I had to use an installer to configure it each time. By using these scripts and configuration files on the sdcard, I can just configure it once and keep installing away to my heart's content.
After installing this kernel, there will be:
/system/etc/init.d/99crpalmer
run at boot, even if you switch to another kernel. It is safe to leave this file there and to let it run as it only makes changes if the kernel contains "crpalmer" in the version. If run with a kernel that contains crpalmer in the version, it will rename mpdecision so it can't run. If you install another kernel it will then rename mpdecision back so that it will run in the new kernel. In addition to stopping the built-in mpdecision it will allow the following tweaks:
CPU Frequencies
* Frequencies loaded from /sdcard/crpalmer-cpufreq-min and /sdcard/crpalmer-cpufreq-max
* Governor loaded from /sdcard/crpalmer-cpufreq-governor
* If you specify either or both of these frequencies, it will lock down all of the CPU frequency controls. I had to do this because HTC overrides them in a script that is run very late in the boot process (thanks HTC!).
* E.g. adb shell su -c "echo 192000 > /sdcard/crpalmer-cpufreq-min"
* E.g. adb shell su -c "echo 1728000 > /sdcard/crpalmer-cpufreq-max"
* E.g. adb shell su -c "echo interactive > /sdcard/crpalmer-cpufreq-governor"
Undervolting
* + or - value loaded from /sdcard/crplamer-uv
* The undervolting in 2.0.23 for FAST binned CPUs would be specified as:
* E.g. adb shell su -c "echo -100 > /sdcard/crpalmer-uv"
Lightsensor
* My light sensor changes didn't sound like they worked well for everyone. If you don't like them you can disable them by:
* E.g. adb shell touch /sdcard/crpalmer-stock-lightsensor
HTC Colour "Enhancement"
* If this file is present then the HTC's colour "enhancement" will be used, otherwise it will be disabled.
* If this file contains the string "m7" then it will use one of the colour enhancement that was used in the M7 kernel for a panel most like ours.
* E.g. adb shell touch /sdcard/crpalmer-color-enhancement
Click to expand...
Click to collapse
DoubleTap2Wake:
* This allows you to wake the device by double tapping in the bottom half of the screen, just above the hardware keys.
* To enable or disable, create the file /sdcard/jamiethemorris-dt2w
* If this file contains a 1, dt2w is enabled. If it contains a 0 it is disabled. Enabled by default.
Sweep2Wake/Sweep2Sleep:
* This allows you to wake the device by sweeping from left to right over the hardware keys, and sleep the device by sweeping from right to left.
* To enable or disable this, create the file /sdcard/jamiethemorris-s2w.
* If the file contains a 1, s2w and s2s are enabled. If it contains a 0, they are disabled. Enabled by default.
GPU Overclock:
* The GPU's max frequency is loaded from /sdcard/jamiethemorris-gpu-oc. If this file does not exist, the stock frequency of 400 MHz is used.
* To set this GPU overclock, you need that file containing the GPU frequency in MHz. Frequencies from 400 to 550 MHz are available.
* E.g. adb shell su -c "echo 450 > /sdcard/jamiethemorris-gpu-oc"
GPU Governor:
* You can choose from either ondemand, simple, or performance GPU governors. Default is ondemand.
* The governor is loaded from /sdcard/jamiethemorris-gpu-gov
* E.g. adb shell su -c "echo simple > /sdcard/jamiethemorris-gpu-gov"
Dynamic Fsync:
* From Faux123: The dynamic sync control interface uses Android kernel's unique early suspend / lat resume interface. While screen is on, file sync is disabled. When screen is off, a file sync is called to flush all outstanding writes and restore file sync operation as normal.
* Disabled by default. To enable or disable, create the file /sdcard/jamiethemorris-dyn-fsync. Use 0 to disable and 1 to enable.
Force Fast Charge:
* To enable or disable fast charge, create the file /sdcard/jamiethemorris-fastcharge
* Use 0 to disable, and 1 to enable. Disabled by default.
Intelliplug and Eco Mode:
* Intelliplug is a replacement hotplug driver for HTC's mpdecision, Eco Mode limits your device to dual-core operations.
* To enable or disable, use create the file /sdcard/jamiethemorris-intelliplug
* If the file contains 0, intelliplug and eco mode are both disabled and your phone will use crpalmer's hotplug driver. If the file contains a 1, intelliplug is enabled but eco mode is disabled. If the file contains the string 'eco', intelliplug and eco mode are both enabled. Both are disabled by default.
I/O Scheduler:
* To change the I/O scheduler, create the file /sdcard/jamiethemorris-iosched, and your device will use whatever I/O scheduler you specify.
* E.g. adb shell su -c "echo row > /sdcard/jamiethemorris-iosched"
Undervolt Override:
* This allows you to globally undervolt your device, but leave the 1836 MHz, 1890 MHz, and 1917 MHz frequencies at their default voltages.
* To enable or disable:
- First you need to find your PVS bin number. You can find this by checking the file /sys/module/acpuclock_krait/parameters/pvs_number.
- Create the file /sdcard/jamiethemorris-pvs and put your PVS number in that file.
- After a reboot, your device will automatically set the highest frequencies to the default voltages for your chip.
* If you are either lazy or confused, you can put '?' in the file and your phone will set itself to the voltages for a 'nominal' binned chip.
For the rest of the features and changelog, see crpalmer's original cm11 kernel thread.
Thanks: crpalmer for all of his help (before I started on this I didn't even know how to use git), coachcrey for originally inspiring me to do this, and all the other devs/builders here that may or may not know I'm learning from them constantly.
Downloads
Latest version:
Version 6.0.1
Older versions:
Older versions on Android File Host
Source:
Kernel Source
Build Tools
Recommended Settings
You can either use an app such as TricksterMod or Kernel Tweaker to set these parameters or use my scripts.
-Minimum CPU frequency: 162000
-Maximum CPU frequency: 1890000 for performance, 1512 for battery life, 1728 for balanced
-Undervolt: -100 for battery life, -50 for balanced/stability
-Color enhancement (script only): m7
-DoubleTap2Wake: Enabled for convenience or pretending you have a G2, disabled for battery life
-Sweep2Wake: Enabled for convenience, disabled for battery life
-Fastcharge: Disabled for safety, enabled for convenience
-GPU overclock: 500 MHz or 533 MHz for performance, 400 MHz or 320 MHz for battery life, 450 MHz for balanced
-GPU governor: ondemand for battery, simple for performance
-CPU governor: preservative for battery or balanced (decrease up threshold for faster response at the expense of battery), intelliactive for general performance, performance for benchmarking
-Intelliplug/Eco mode: Disabled for performance, enabled for balanced, Eco Mode for battery life
-I/O Scheduler: BFQ for balanced/stability, vr for performance
-Dynamic Fsync: Disabled for safety (less likely to have data loss in the event of sudden power off), enabled for performance, enabled for balanced
-Undervolt Override (script only): set jamiethemorris-pvs to your chip's PVS bin. Recommended for those with high overclock that are undervolted.
To make things easier for those who do not wish to use a third-party app, I have posted some zips with the necessary files. Just unzip them and put the files on your sdcard.
Default settings
Recommended settings (these are the settings I use, good performance vs. battery compromise
For best battery life
For best performance
XDA:DevDB Information
jamiethemorris's kernel, Kernel for the HTC Droid DNA
Contributors
jamiethemorris, crpalmer
Source Code: https://github.com/jamiethemorris/dna-kernel/tree/6.x
Kernel Special Features: dt2w, kexec-hardboot, overclock, fastcharge, fauxsound
Version Information
Status: Stable
Created 2014-01-28
Last Updated 2014-12-04
Changelog:
6.0.1
- All updates from CM:
- F2FS updates. Maybe F2FS works now (probably not).
- UID-based routing
- Enable selinux development
- Initial support for Lollipop (KitKat 4.4.4 ROMs are still supported)
5.8.2
- Updates from crpalmer:
* Update some video bandwidth parameters
* Interactive governor updates
- Pretty sure that's it.
5.8.1
- Updates from crpalmer:
* Patched up to linux 3.4.99 (latest version of as now)
* Patched up to latest CM (fixes a couple of CVEs, not a whole lot else was missing)
5.7.7.1:
-Force Fast Charge should now be fixed
-Make sure all cores are enabled when using performance CPU governor
5.7.7:
-Moved from Linaro 4.8.3 to 4.9.1
-Update modem restart commit from stock CM kernel
-No more intelliplug due to random reboots and the fact that simple plug works just fine. I may bring it back future versions.
-Reduce memory usage of input driver + oom tweaks that theoretically help a little bit with the touchscreen wake issue. I am still working on finding a real fix.
-SLIMBUS: m8 port, caf updates, new OC from poondog (better audio quality)
-Update BFQ to v7r3
-Update to latest F2FS driver
Older versions:
5.7.6:
-NOTE: There are 2 different zips for this version to avoid conflicts between crpalmer's simple plug and faux123's intelliplug.
-IMPORTANT: On the intelliplug version, intelliplug is enabled by default. If you disable intelliplug, there will be no hotplug driver running which will kill your battery quickly. So if you decide you don't want to use intellidemand, please use the simple plug version instead.
-Memory optimizations from Motorola
-Enable Linaro's power-efficient workqueues
-Intelliplug updates
-Merge latest CM commits
-Merge crpalmer's latest commits
-Update to Linux 3.4.86
-Update F2FS to the latest version
5.6.4:
-Hopefully fix voltage for "faster" binned chips
-Fixed random reboots when using intellidemand governor
-Fix scripts
-Disable intellidemand's active max frequency to prevent it from interfering with overclock
-Enable additional TCP congestion algorithms (thanks iHateWebOS)
-Sync s2w/dt2w/pocket detection with Beastmode
-Add Preservative governor (credits to bedalus)
-Update BFQ I/O Scheduler to v7r2
-Merge latest CM commits
-Merge crpalmer's latest commits
-Update to Linux 3.4.79
-Add LZ4 kernel compression/decompression for faster boot
-I think I forgot to mention this before, but I am now using a Cortex a-15 optimized Linaro toolchain.
5.5.5:
-Dynamic Fsync (Enable this only if you are sure your device is stable! If you have too many reboots, your data may get corrupted and you will have to reflash your ROM.)
-Simple GPU Governor
-Intelliplug hotplug driver with Eco mode (dual core operations). When this is disabled, it will use crpalmer's hot-plug driver.
-Intellidemand tweaks - I'm still working on this one, it tends to have random reboots at the moment.
-Decrease GPU OC to 533 MHz and increase bandwidth
-1917 MHz overclock is back, should be more stable now
-Sweep2wake + Sweep2Sleep
-Doubletap2sleep is not implemented in this version, sorry. Use your ROM's dt2s feature for now. I do plan on adding this back.
-Doubletap2wake can be used anywhere on the screen
-There should be scripts for all features, let me know if I missed something.
-Undervolt override for high overclocks. You can globally undervolt while leaving 1836 MHz, 1890 MHz, and 1917 MHz clocks unaffected.
-L2 cache overclock
-600 MHz bus overclock for 1674 MHz - 1917 MHz frequencies
-Support for F2FS filesystem (F2FS TWRP and MultiROM are coming as well, as soon as I have time to test)
-FIOPS I/O Scheduler
5.5.4.1:
-Now only one kernel zip
-GPU overclock is set with /sdcard/jamiethemorris-gpu-oc between 400 and 550 MHz. Default is 400.
-New wheatley governor
-Some more optimizations
5.5.4:
-Fixed video undderrun (blue flickering) issue with GPU overclock
-Updated FauxSound to 2.1
-Now only 2 kernel zips. One is stock GPU clock and the other is for 450 and 500 mhz overclocks. Default is 500 on the OC version.
-New governors: intellidemand, intelliactive, smartassV2, lagfree, badass, Lionheart
-New I/O Schedulers: zen, vr
-Improved touchscreen sensitivity - If this causes problems for people I will revert it.
-SLIMbus overclock which should in theory improve audio quality
-Various performance optimizations, see github for full details
5.5.3.4:
-Switch linaro optimization level from -03 to -0fast
-A few other optimizations, see github for full details
5.5.3.3: Up to 500 mhz GPU overclock. For now, there are 3 different downloads depending on what GPU frequency you want - stock (400 mhz), 450 mhz, and 500 mhz. There are no other changes, so if you don't want a GPU overclock there is no need to update to this version.
5.5.3.2: Up to 1890 mhz CPU overclock
5.5.3.1: Added FauxSound
Nice work man!
Sent from my HTC6500LVW using Tapatalk
Multirom link is in the op. I plan on getting s2w working soon also. The code is there, but it's made for an HTC one so it doesn't work yet. Technically logo2menu is in there as well lol
Sent from my Droid DNA using Tapatalk
Dt2w works perfect! Will this kernel be updates as CP pushes changes in the future?
HTC DNA
LG Optimus G
d08speed3 said:
Dt2w works perfect! Will this kernel be updates as CP pushes changes in the future?
HTC DNA
LG Optimus G
Click to expand...
Click to collapse
Yes, that is the plan
Sent from my Droid DNA using Tapatalk
CM double tap to sleep. Doesn't work well with dt2s. It turns off then back on.
HTC DNA
LG Optimus G
---------- Post added at 07:57 AM ---------- Previous post was at 07:56 AM ----------
d08speed3 said:
CM double tap to sleep. Doesn't work well with dt2s. It turns off then back on.
HTC DNA
LG Optimus G
Click to expand...
Click to collapse
Edit: turning the CM dt2s works. I'm guessing you have this enabled for status bar double tap to sleep?
HTC DNA
LG Optimus G
d08speed3 said:
CM double tap to sleep. Doesn't work well with dt2s. It turns off then back on.
HTC DNA
LG Optimus G
---------- Post added at 07:57 AM ---------- Previous post was at 07:56 AM ----------
Edit: turning the CM dt2s works. I'm guessing you have this enabled for status bar double tap to sleep?
HTC DNA
LG Optimus G
Click to expand...
Click to collapse
Just to clarify, in that last edit you're just saying that turning dt2s off in the settings makes the kernel's version of dt2s work right? Cause that's what I'm seeing on my phone. Thanks for the heads up, I enabled the dt2s setting a while ago but I always forget that I did so I hadn't tested it yet.
Sent from my Droid DNA using Tapatalk
jamiethemorris said:
Just to clarify, in that last edit you're just saying that turning dt2s off in the settings makes the kernel's version of dt2s work right? Cause that's what I'm seeing on my phone. Thanks for the heads up, I enabled the dt2s setting a while ago but I always forget that I did so I hadn't tested it yet.
Sent from my Droid DNA using Tapatalk
Click to expand...
Click to collapse
Yea. Turning off CM's dt2s settings off makes your dt2s work. I see it enabled in sys>android_touch.
HTC DNA
LG Optimus G
d08speed3 said:
Yea. Turning off CM's dt2s settings off makes your dt2s work. I see it enabled in sys>android_touch.
HTC DNA
LG Optimus G
Click to expand...
Click to collapse
Got it. Looks like this was bad timing to release a kernel, apparently we're moving from m7 to msm8960 soon...
Sent from my Droid DNA using Tapatalk
i love the convenience of s2w and dt2w and now we have it for aosp and sense! what a awesome time this is to own a dna
Swipe or double tap to sleep isn't working. Normal?
-DroidIsDNA- said:
Swipe or double tap to sleep isn't working. Normal?
Click to expand...
Click to collapse
Dt2s is working for me. S2w isn't functional yet. Is dt2w working for you?
If you have dt2s enabled in your ROM settings, make sure you disable it as out counteracts the kernel's dt2s.
Sent from my Droid DNA using Tapatalk
jamiethemorris said:
Dt2s is working for me. S2w isn't functional yet. Is dt2w working for you?
If you have dt2s enabled in your ROM settings, make sure you disable it as out counteracts the kernel's dt2s.
Sent from my Droid DNA using Tapatalk
Click to expand...
Click to collapse
I don't think I have it enabled in probam. Dt2w doesn't work
-DroidIsDNA- said:
I don't think I have it enabled in probam. Dt2w doesn't work
Click to expand...
Click to collapse
Did you follow the instructions in the op to enable it? It should be enabled by default I think but if not I put instructions there
Sent from my Droid DNA using Tapatalk
jamiethemorris said:
Did you follow the instructions in the op to enable it? It should be enabled by default I think but if not I put instructions there
Sent from my Droid DNA using Tapatalk
Click to expand...
Click to collapse
Oops I meant double tap to sleep I'm sorry
-DroidIsDNA- said:
Oops I meant double tap to sleep I'm sorry
Click to expand...
Click to collapse
That's weird then. You have to double tap the status bar in case you didn't already know that. If that's still not working, then enabling the ROMs version of it in settings should do the trick.
Sent from my Droid DNA using Tapatalk
jamiethemorris said:
That's weird then. You have to double tap the status bar in case you didn't already know that. If that's still not working, then enabling the ROMs version of it in settings should do the trick.
Sent from my Droid DNA using Tapatalk
Click to expand...
Click to collapse
Ohhhhhh, yeah I was double tapping above the menu keys. Status bar works flawlessly. Thanks! Idk if its in the op or if I just blanked out
-DroidIsDNA- said:
Ohhhhhh, yeah I was double tapping above the menu keys. Status bar works flawlessly. Thanks! Idk if its in the op or if I just blanked out
Click to expand...
Click to collapse
It actually wasn't in the OP, I just added it for clarification.
Is force fast charge on by default?
HTC DNA
LG Optimus G
Code:
Your warranty is now void.
I'm not responsible for bricked devices, dead SD cards,
thermonuclear war, or you getting fired, because the alarm app failed. Please
do some research if you have any concerns about features included
before flashing it! YOU are choosing to make these modifications, and if
you point the finger at me for messing up your device, I will laugh at you.
So here it is. After testing for a few days I've decided to give out builds of CM 12.1 kernel with a little bit better CPU management.You may see improvement especially when you're not using 3G/LTE as it seems to drain battery almost as fast as before (depending on the use ofc). You'll get much better battery life on wifi though. You may tweak the settings using some kernel control apps but the recommended setup is already applied.
Features:
+ Bricked hotplug driver - turns off CPU cores if the CPU load is not big enough to need them.
+ Powersuspend - a driver that should turn off unused hardware components when screen is off
+ Quickwakeup driver - it allows some tasks to wake up the system to perform certain actions without fully resuming it
+ Min. CPU freq 200MHz (CM12.1 has it set to 800MHz but it seems we don't need it that high after disabling CRC checks)
+ Revised interactive governor target_loads to clock CPU more efficiently
Download:
Kernel:
CM12.1:
J500FN
J500F
J500G
J500H
J500M
J500Y
J5008
CM13:
J500FN
J500F
LOS14.1:
J500FN
J500F
J500H
J5008
GPU Max Frequency Limiting Scripts:
400 Mhz
475 Mhz
550 Mhz
650 Mhz
Installation:
Just flash the zip for your device in TWRP.
Changelog:
Code:
07.10.2017:
- First release rebased on @vince2678 kernel source and device trees (Will work only with his Los14.1 builds from now on, don't even try any older ROMs available)
- Added some tweaks by @Bulgaricus
24.07.2017:
- Rebased on newest LOS kernel
- Reimplemented some of tweaks previously reverted due to conflict (The most important being Display driver update, refresh rate should be better now)
30.05.2017:
- Merged upstream changes (new power hal compability etc.)
19.05.2017:
- Merged base kernel updates
- Enabled thermal core control
- Change throttling cpu temperature from 60°C to 80°C to avoid performance loss
- Enabled CPU_BOOST config
- Kernel now should boot on both LL and MM bootloaders (needs testing)
18.05.2017:
- First release for Lineage OS 14.1
- Rebased on @SoUnd001 kernel source (LOS 14.1 only)
- Drop CM1300/LOS13.0 support
02.03.2017:
- Fixed slow charging
- Cpusets tweaks for hotplug (multitasking related)
25.01.2017:
- Squashed update to 3.10.104
- Additional CPU & Battery tweaks
- Faster boot
16.01.2017:
- Major cleanup
- Tweaked recommended values
- Final release for CM12.1
- First release for CM13.0
08.01.2017:
- Added GPU OC up to 720MHz (you may change max frequency if you don't like OC or want it to be a little less thanks to the scripts included in downloads. Previous default freq was 400 MHz)
- Changed default gpu governor to simple_ondemand to avoid frequency bug described in #16
06.01.2017
- Initial release
- Added bricked hotplug driver
- Added powersuspend driver
- Added quickwakeup driver
- Changed CPU min freq. to 200MHz instead of 800MHz
- Optimized interactive's target_load
XDA:DevDB Information
Hotplug enabled kernel for Cyanogenmod 12.1/13.0, LOS 14.1, Kernel for the Samsung Galaxy J5
Contributors
Koloses, Nick Verse, ganesh varma, #Henkate, SoUnd001, vince2678, Bulgaricus
Source Code: https://github.com/hotplugj5
Kernel Special Features:
Version Information
Status: Stable
Created 2017-01-06
Last Updated 2017-10-07
GJ
great work on FN works pretty good
Awesome, can I request you to build one with 1.4 OC!? :silly:
Can you make for Ressurection Remix too?
Sent from my SM-J500FN using XDA Labs
Since most if not all of custom ROMs are similiar, this should work on RR, just try it. I'll look into overclocking later on since it's not the most needed feature and I wanted to release stable kernel first. I also plan adding adreno idler.
Koloses said:
Since most if not all of custom ROMs are similiar, this should work on RR, just try it. I'll look into overclocking later on since it's not the most needed feature and I wanted to release stable kernel first. I also plan adding adreno idler.
Click to expand...
Click to collapse
Yep, it's confirmed working on RR..
Well, GPU overclock seems to work (3D score) . We'll see about CPU later on as it doesn't seem to have any impact other than showing time in state. I'll add GPU OC to the next build.
First screenshot is without GPU overclock, second is overclocked GPU.
Sent from SM-J500 CM12.1
So to install this on RR we just have to flash in TWRP?
Sent from my SM-J500FN using XDA Labs
Cm 13 on lolypop bootloader will work?
Does this hurt the hardware in anyway? (Not using overclocking of course)
Sent from my SM-J500FN using XDA Labs
Koloses said:
Well, GPU overclock seems to work (3D score) . We'll see about CPU later on as it doesn't seem to have any impact other than showing time in state. I'll add GPU OC to the next build.
View attachment 3994178View attachment 3994179
Sent from SM-J500 CM12.1
Click to expand...
Click to collapse
I got higher GPU score without overclock (879).
Benchmarks may or may not reflect the real phone performance. Personally im against OC.
Any CM kernel should work on RR as well, since RR is using cm kernel.
Oh I didn't mention: First ss shows the score without OC (860) The second is OC'd (979) I'll test it further though because antutu is rather heavy benchmark. OC possibility will be included anyway but I'm thinking about making it enabled out of the box or not.
I did repeat it several times and just took 2 random screenshots from before and after. I'll edit the post to include that.
Sent from SM-J500 CM12.1
Koloses said:
Oh I didn't mention: First ss shows the score without OC (860) The second is OC'd (979)
I did repeat it several times and just took 2 random screenshots from before and after. I'll edit the post to include that.
Sent from SM-J500 CM12.1
Click to expand...
Click to collapse
Oh well, thats clearly an improvement
But im still against OC. I didnt experience any game lag when ive been playing.
OC will lead to higher temperature & battery drain. Personally, i prefer to use phone without OC, since it performs well.
Perhaps you can do a test with temperature when using CPU/GPU OC?
Alright tested this kernel and it works outstanding! My battery life has been improved and I really like that I can see how the cores turn themselves off when they are not needed, in Kernel Adiutor.
Works perfectly on RR
Sent from my SM-J500FN using XDA Labs
#Henkate said:
OC will lead to higher temperature & battery drain. Personally, i prefer to use phone without OC, since it performs well.
Click to expand...
Click to collapse
We'll see. Adreno Idler may compensate GPU OC battery drain, I need to test the temperatures too. It's only a matter of setting up default settings though because I also want to let people configure things to fit them while providing recommended configuration out of the box.
I could always apply OC out of the box and add flashable zip with init.d script to set stock frequency on boot so I won't have to build boot image twice for all the devices. Sounds fair to me.
Sent from SM-J500 CM12.1
Koloses said:
We'll see. Adreno Idler may compensate GPU OC battery drain, I need to test the temperatures too. It's only a matter of setting up default settings though because I also want to let people configure things to fit them while providing recommended configuration out of the box.
I could always apply OC out of the box and add flashable zip with init.d script to set stock frequency on boot so I won't have to build boot image twice for all the devices. Sounds fair to me.
Sent from SM-J500 CM12.1
Click to expand...
Click to collapse
I have tested Adreno Idler and according to latest Kernel Adiutor, it goes to 200mhz when phone is in idle so it is working fine and also i think there are less switches between GPU frequencies than before. Just like the other people, i have noticed battery improvement too using Adreno Idler. But read msm-adreno-tz governor bug below.
The GPU governor called simple_ondemand is working nice too. I searched for 1080p youtube video and GPU frequency stays at 200 always when watching a video (assuming the screen is not touched), which is great and can improve the battery alot for that task and also for reading.
Unlike simple_ondemand, msm-adreno-tz used to stay at 300-400mhz when watching same video. I havent tested yet with Adreno Idler though, but simple_ondemand seems a great choice for tasks like watching a video or reading something long.
When i tested msm-adreno-tz frequencies for first time (with the command from adreno idler thread, but the path is different for J5), i have found that msm-adreno-tz:
- use 300mhz freq when phone is in idle with screen on and on homescreen
- when you touch/keep sweeping with the finger on the screen (e.g. on homescreen), the GPU frequency goes to 200. It gets lowered instead higher LOL.
GPU MSM-ADRENO-TZ BUG, default on all kernels, both on stock and cm based roms.
If screen goes off (or you turn the screen off), then you turn it on, and then it goes off again (or you power it off) WITHOUT UNLOCKING THE PHONE AND TOUCHING THE SCREEN AFTER UNLOCK the GPU will stay at 400mhz until you turn the screen on, unlock and touch it.. This doesnt happen with simple_ondemand, where GPU stays at 200mhz always when screen is off or phone is in idle with screen on. Even if you dont have a lockscreen, the bug still persist.
GPU staying at 400mhz when screen is off, means that it will use power useless, for no reason. And also, it can lead to slower charging. I dont know how much power it use, but i know that it counts.
Unfortunately, even with Adreno Idler i see that the bug is still present. Or perhaps i havent implemented Adreno Idler properly? But i think i did.
This is the governor bug i wanted to talk about. I wanted to make a thread under general section.
I recommend simple_ondemand governor, although i see that it has more switches between GPU frequencies, it can lead to higher battery backup for tasks like watching a video or reading something long.
Im sorry for going a bit off-topic
EDIT:
@Koloses:
Run following commands in terminal to see the current GPU frequency, updated constantly:
PHP:
adb shell
cd /sys/devices/soc.0/1c00000.qcom,kgsl-3d0/devfreq/1c00000.qcom,kgsl-3d0
while true; do cat trans_stat; busybox sleep 0.1; done
The "*" shows the current frequency.
Total transitions = the number of total switches between frequencies.
Development talk is never ever an offtopic to me
Anyway, where did you get Adreno Idler from? https://forum.xda-developers.com/an...dreno-idler-idling-algorithm-devfreq-t3134872 This seems to be an official thread regarding it and explanation of how it works seems fine. It needs powersuspend, but we have that in kernel already. I'll look into implementing it after getting home.
Sent from SM-J500 CM12.1
Koloses said:
Development talk is never ever an offtopic to me
Anyway, where did you get Adreno Idler from? https://forum.xda-developers.com/an...dreno-idler-idling-algorithm-devfreq-t3134872 This seems to be an official thread regarding it and explanation of how it works seems fine. It needs powersuspend, but we have that in kernel already. I'll look into implementing it after getting home.
Sent from SM-J500 CM12.1
Click to expand...
Click to collapse
I got Adreno Idler 1.1 from other msm8916 kernel, as i had some troubles with the commits from the official thread ( i dont remember what troubles lol). I got PowerSuspend 1.5 from same kernel.
Im not sure if PowerSuspend is working. I enabled the debug mode, but i cant find any PowerSuspend line in dmesg, kmesg, neither logcat. But i have power_suspend folder & lib, and also i see that it is on hybrid mode, both in Kernel Adiutor and system file.
Also, in logcat (taken since boot), i see following error:
PHP:
W/libsuspend( 942): Error writing 'on' to /sys/power/state: Invalid argument
I/libsuspend( 942): Selected wakeup count
It is trying to write "on" to state file.
/sys/power/state file has two words: frezee mem.
#Henkate said:
I got Adreno Idler 1.1 from other msm8916 kernel, as i had some troubles with the commits from the official thread ( i dont remember what troubles lol). I got PowerSuspend 1.5 from same kernel.
Im not sure if PowerSuspend is working. I enabled the debug mode, but i cant find any PowerSuspend line in dmesg, kmesg, neither logcat. But i have power_suspend folder & lib, and also i see that it is on hybrid mode, both in Kernel Adiutor and system file.
Also, in logcat (taken since boot), i see following error:
PHP:
W/libsuspend( 942): Error writing 'on' to /sys/power/state: Invalid argument
I/libsuspend( 942): Selected wakeup count
It is trying to write "on" to state file.
/sys/power/state file has two words: frezee mem.
Click to expand...
Click to collapse
@Koloses
I have found this in ramdisk:
init.zygote32.rc:
Code:
service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server
class main
socket zygote stream 660 root system
onrestart write /sys/android_power/request_state wake
[B][COLOR="Red"]onrestart write /sys/power/state on[/COLOR][/B]
onrestart restart media
onrestart restart netd
Thats why i got that error while booting, but i dont know why libsuspend is mentioned at the error. Also, there is no android_power folder.
This is on stock kernel 5.1.1.
Good work @Koloses !!! Keep up buddy Just to notify I had 31.800+ benchmark score with the well known kernel 5.1.1. of dj steve, without overheating... Personally I prefer more performance instead of battery life, so if you keep on tweak and overclock your kernel would be nice maybe a separate zip. To enable it. Have a nice day man!