Update
Here is an easier solution that doesn't require flashing.
Please use this for any new ROMs from now on.
Old solution ONLY FOR 5.10.8 and 5.10.16
This is a stock miui kernel from 5.10.8, with modified ramdisk to limit CPU frequency.
This is a test I made for myself to see how much it helps in battery time to limit the CPU. I'm sharing this, because others might be interested in it.
You need to have MIUI 5.10.8 or 5.10.16. Older versions are not fully compatible. (Vibration not working)
So, finally we have custom kernels?
No, the proper kernel source is not available yet, the kernel image is still untouched.
Will there be new versions?
Probably, as there are other possible ramdisk tweaks that can achieve better battery life.
How much this can help?
I didn't have the time for a long test yet, I hope there are some users here who are willing to compare the results with the factory kernel.
But I can make some points:
This won't help much with standby time, as the frequency there is already much more limited.
This will help the most in situations where the CPU is the biggest drainer, like games.
Is this going to slow down my phone?
Theoretically, it will be slower. However in real life usage, I can't tell the difference.
Why wouldn't you just use an app like SetCPU?
None of those apps I tried have worked.
Can this be done without flashing a new kernel?
Yes, you only have to update the frequency in KHz in /proc/cpufreq/cpufreq_limited_max_freq_by_user.
For example (with root privileges):
Code:
echo '1500000' > /proc/cpufreq/cpufreq_limited_max_freq_by_user
However, this will reset after a reboot.
The attached file can be flashed under recoveries. TWRP tested.
Or you can extract the boot.img, and flash it in fastboot.
xm_kernel.zip will limit the CPU at 1.5GHz.
xm_kernel_1200 will do 1.2GHz.
Version 2 will do the trick Ched666 suggested, thus reducing the time spent at maxfreq.
Version 3 will not disable the touch boost, instead it will replace perfservscntbl.txt with boost to 1183MHz and 2 cores.
Reserved
Looking forward results and tests.
Flashed on 5.9.24
Work perfect. Only one problem... Vibro is gone Both Incall and feedback
Bakumatsu said:
Flashed on 5.9.24
Work perfect. Only one problem... Vibro is gone Both Incall and feedback
Click to expand...
Click to collapse
Thanks for the heads-up. You probably need 5.10.8 for that to work.
I know. I just a flashagolic
ill be testing this later..nice work buddy
Test on miui 5.10.8, it works!
And later manually change value to 1200000, works without lag. But after reboot maxfreq reset to 1500000.
Can you make the same kernel, but with maxfreq 1200000?
Xmister said:
No, the proper kernel source is not available yet, the kernel image is still untouched.
Click to expand...
Click to collapse
isn't this the kernel source code: https://github.com/BalcanGSM/MediaTek-HelioX10-Kernel
avenant said:
isn't this the kernel source code: https://github.com/BalcanGSM/MediaTek-HelioX10-Kernel
Click to expand...
Click to collapse
That is just a basic MediaTek source, it's missing drivers and configuration for our device.
I think it is more easy to control the value by implement init.d on our device.
Xmister said:
What is this?
This is a stock miui kernel from 5.10.8, with modified ramdisk to limit CPU frequency at 1.5GHz.
This is a test I made for myself to see how much it helps in battery time to limit the CPU. I'm sharing this, because others might be interested in it.
You need to have MIUI 5.10.8. Older versions are not fully compatible. (Vibration not working)
So, finally we have custom kernels?
No, the proper kernel source is not available yet, the kernel image is still untouched.
Will there be new versions?
Probably, as there are other possible ramdisk tweaks that can achieve better battery life.
How much this can help?
I didn't have the time for a long test yet, I hope there are some users here who are willing to compare the results with the factory kernel.
But I can make some points:
This won't help much with standby time, as the frequency there is already much more limited.
This will help the most in situations where the CPU is the biggest drainer, like games.
Is this going to slow down my phone?
Theoretically, it will be slower. However in real life usage, I can't tell the difference.
Why wouldn't you just use an app like SetCPU?
None of those apps I tried have worked.
Can this be done without flashing a new kernel?
Yes, you only have to update the frequency in KHz in /proc/cpufreq/cpufreq_limited_max_freq_by_user.
For example (with root privileges):
Code:
echo '1500000' > /proc/cpufreq/cpufreq_limited_max_freq_by_user
However, this will reset after a reboot.
The attached file can be flashed under recoveries. TWRP tested.
Or you can extract the boot.img, and flash it in fastboot.
Click to expand...
Click to collapse
it show to be on maximum speed on cpu spy...why?
Jo-san said:
it show to be on maximum speed on cpu spy...why?
Click to expand...
Click to collapse
Maybe the flash wasn't successful,or you flashed over something.
This is mine, the 29 sec is during boot, until it activates.
Ched666 said:
Test on miui 5.10.8, it works!
And later manually change value to 1200000, works without lag. But after reboot maxfreq reset to 1500000.
Can you make the same kernel, but with maxfreq 1200000?
Click to expand...
Click to collapse
OP updated with 1.2GHz kernel
Xmister you really do a great job. I renember I used your kernel when my phone was still HTC one x and then I changed to use iPhone 5s ,6, and dropped few weeks ago. And then I am back to android envirnoment and still flashing your modded kernel. Many thanks for your contribution.
And BTW, I think the 1200 kHz really help in get away from the battery draining problems.
4pda users found interesting thing... When touch a screen, frequency increases to maximum.
But if write 0 to the /proc/cpufreq/cpufreq_limited_by_hevc and set read only permissions, this bug disappears. And no maximum freq when touch a screen.
I tried it, and phone is much less heat, and works at a reduced freqs.
ADD: make mod to xm_kernel 1,5 GHz with this tweak
Ched666 said:
4pda users found interesting thing... When touch a screen, frequency increases to maximum.
But if write 0 to the /proc/cpufreq/cpufreq_limited_by_hevc and set read only permissions, this bug disappears. And no maximum freq when touch a screen.
I tried it, and phone is much less heat, and works at a reduced freqs.
Click to expand...
Click to collapse
This seems working too.
OP updated with V2 kernels that do this automatically.
Xmister said:
This seems working too.
OP updated with V2 kernels that do this automatically.
Click to expand...
Click to collapse
Also made modification ))
No need to touch cpufreq_limited_by_hevc.
If you want to control the touch_boost, try this way.
Find the file in system/etc/perfservscntbl.txt
CMD_SET_CPU_CORE, SCN_APP_TOUCH is to control how many cores when touch boost.
CMD_SET_CPU_FREQ, SCN_APP_TOUCH is to set the value when touch boost.
Save after modify and reboot your device.
By @Ched6666 's way is totally disable touch_boost
v2 is compatible with 5.10.16 release?
Related
Hi. The following kernel is presented to you by
vorkKernel Team:
- kiljacken
- Benee
Click to expand...
Click to collapse
This kernel is for Cyanogenmod and Miui. *Could* be incompatible with latest kangs or nightlies (after a kernel update from CM team). No support for stock or mcr...
It's incompatible with MIUI and CM Builds before #177
New vorkKernel Twitter Bot: Here
First I want to make clear that all credit goes to aremcee/arcee/rmcc (man so many nicks ). He did an awesome job with the kernel.
I just tweaked it a little bit to my needs.
Features:
uv/oc support. OC up to 1,5GHz (With E-Peen version)
AVP/System/RAM/GPU OC with E-Peen version
1,2 Ghz for batt safe version.
Special tweaked (working!) Performance and Powersave Govenors which don't lock the freq to one level (they choose between 3-4 Freq steps)
It's even possible to set max/min clock via setcpu or CMSettings!
Voodoo sound. Thanks supercurio! So awesome
Default IO-Sched is Deadline with a special flash storage tweak
Slub allocator
tweaked CFS cpu sched (Low latency)
compiled with a tweaked toolchain (base linaro gcc - optimized for tegra2)
VFP optimizations (vfpv3-d16) and overall compiler optimizations
flags! (more below in the flag section)
A App for easy downloading and configuring. Credits to kiljacken!
Click to expand...
Click to collapse
The standard part:
I'm not responsible for melted phones or something like that...
The camera is unstable with E-Peen mode (due to AVP OC). After a reboot it needs to stabilize a few minutes (so you break it with every reboot again). Same for Bluetooth. Please don't report a problem regarding this. It's known and can't be fixed.
Click to expand...
Click to collapse
And the source code here.
Download (Market)
Credits to kiljacken for this awesome app! You need OI File Manager for the app (Comes with CM)!
(and if you refuse to use the app - or the app is refusing to work with you: here)
Only change something, if you want to enable OC - No need to touch anything else (like govenors, schedulers)
What are flags and how can I use them?
I recommend to use the App kiljacken made, because it's super easy for you guys. If you not want to use the app *sadpanda* then you can click this link. This is the file the app is fetching to generate the UI.
The layout is following:
Available for following device/Element style (more below)/the flag you need to add/Flag name in App/Description for general Flag/Choice name in app/actual value you need to add after flag name
If the last two points are added you first enter the flag name and than the value. For example: density230
You connect the flags with a: -
Example: -camera-ring ...
The script is configured to detect flags after vorkKernel-VERSIONNUMBER. So you can add some flags after this.
Element style
c = Checkbox
l = List you can choose things from
e = you can enter your own value
Click to expand...
Click to collapse
Error Reporting Guide
Start with rebooting, if that doesn't help, reflash CM and then the kernel, and check again. If you're using the updater app (make sure you have the latest version), use the error report function (and describe what you're problem is). If you're not using the app, then post what flags you are using, along with what your problem is.
Click to expand...
Click to collapse
Additionally I just want to point out that I'm not doing this as a fulltime job, so don't expect daily updates or something like that. I will try to fix a problem as fast as possible but in some cases it can take a while.
If you want to support me you can sign up on dropbox via my referral link or just push this nice thanks button .. If you want to donate you can donate to aremcee/arcee/rmcc something. I'm learning C and linux and vorkKernel is my learning project and it is a hobby for me. Anyway if you still want to support a poor student, I have a link in my signature
Thanks to:
arcee + the whole CM Team
morfic for all the avp oc tweaks and other stuff
thalamus (for saving me going crazy with the toolchain )
Erasmux
All guys that made pull request and contributed in any possible way
Donators to our project (app or kiljacken's donate link)
the android community
and a very big thanks to b3ndech0 for his buildbox.
Thanks, this is very much appreciated
This kernel is amazing! Nice work with the filename flags. It's brilliant! This way we don't have to have the same setup, but can enjoy both CM7 and the kernel.
sibbor said:
I'll try this kernel later. Will wait for CM7 getting more optimized for our devices first. 2000 Quadrant scores out of the box just don't cut it - I don't want to overclock to 1.4 GHz just to reach speeds of MCR FR14 ;-)
Planning on including any changes from kholk?
Click to expand...
Click to collapse
More things will be in it soon. And Quadrant doesn't matter. CM feels better in normal use (except a few problems but it is a really good starting point).
Benee said:
More things will be in it soon. And Quadrant doesn't matter. CM feels better in normal use (except a few problems but it is a really good starting point).
Click to expand...
Click to collapse
Yes I know it doesn't really matter. Although, generally speaking, higher scores means the software is more optimized to the hardware; framework, kernel and/or drivers.
CM7 should be able to smash the performance out of the LG stock ROM without problem...
Thanks for you kernel additions! Subscribed to this thread now so I can follow your progress.
is this kernel for a stock rom?
thanks
sibbor said:
Yes I know it doesn't really matter. Although, generally speaking, higher scores means the software is more optimized to the hardware; framework, kernel and/or drivers.
CM7 should be able to smash the performance out of the LG stock ROM without problem...
Thanks for you kernel additions! Subscribed to this thread now so I can follow your progress.
Click to expand...
Click to collapse
Nah. You can boost quadrant to oblivion via data2ext for example on desire/nexus but it didn't helped in real life performance. The sql sync disable doesn't help with real usage, but boost quadrant etc. So many things which doesn't improve real usage, boost quadrant. Like deleting your /system (pro move...).
But yeah in some parts you are right and optimizing drivers boost it too + help real use performance, so I will do this too.
vekkio said:
is this kernel for a stock rom?
thanks
Click to expand...
Click to collapse
Really? Just read the title: vorkKernel-OC/UV Kernel for CM. For Cyanogenmod. Not stock...
seems the IO from quadrant score still low, is it same sqlite hack with paul that one?
emprize said:
seems the IO from quadrant score still low, is it same sqlite hack with paul that one?
Click to expand...
Click to collapse
yup. patched cm, then compiled this and added it to update.zip.
vekkio said:
is this kernel for a stock rom?
thanks
Click to expand...
Click to collapse
Haaahaa yeah u flash away hahahahha
EDIT:- No only joking
DONT PEOPLE READ
ok, flash this kernal and using cm7 oc to 1.4, quadrant get 31xx
edit : fail to exec smartbench
Benee any chance you could add the OC support to the CM settings?
Sent from my LG O2X CM7 Nightly
svceon said:
Benee any chance you could add the OC support to the CM settings?
Sent from my LG O2X CM7 Nightly
Click to expand...
Click to collapse
Yep but this would break pimp my cpu support and I think pimp my cpu is the better deal. A easy user interface with undervolting support. Awesome! .. so no I won't add it to cm settings
Awesome OC in CM7 makes it even better
I know I'm going to get flamed for this but how do you o/c once you have flashed the kernel? when i open setCPU its already at the max 1g when i go to the CM settings there's no frequencies to select in the cpu management option
is it different on the tegra chips as opposed to qualacom?
sibbor said:
Planning on including any changes from kholk?
Click to expand...
Click to collapse
Ok if I understand the changelog from kholk correct, most of the changes are already included (don't know exactly because he didn't copied the commit names and sums the function up). One commit isn't in it because it introduced the graphic glitches. vfp3-d16 support and compiler optimization will be added with next update. Then most things are in it.
spences10 said:
I know I'm going to get flamed for this but how do you o/c once you have flashed the kernel? when i open setCPU its already at the max 1g when i go to the CM settings there's no frequencies to select in the cpu management option
is it different on the tegra chips as opposed to qualacom?
Click to expand...
Click to collapse
Is stated in the OP:
So I compiled it with uv/oc support via pimp my cpu.
Click to expand...
Click to collapse
Pimp My CPU can be downloaded from here: http://forum.xda-developers.com/showthread.php?t=1018411
spences10 said:
I know I'm going to get flamed for this but how do you o/c once you have flashed the kernel? when i open setCPU its already at the max 1g when i go to the CM settings there's no frequencies to select in the cpu management option
is it different on the tegra chips as opposed to qualacom?
Click to expand...
Click to collapse
Nah no flaming . You need pimp my cpu for it. Cpasjute did some kernel hacks to enable oc and add a uv function. That means you can undervolt without compiling the kernel again. Unfortunatly it isn't compatible with setcpu..
The kernel seems ok; I tried OC till 1200 with 50-100 UV (depending on OC).
What's very good with CM7 (and this kernel) is battery life, 30-40% more compared with Modaco ROM (till FR14).
Anybody have tried higher frequencies (1300-1400)?
Thanks a lot.
lukemo said:
The kernel seems ok; I tried OC till 1200 with 50-100 UV (depending on OC).
What's very good with CM7 (and this kernel) is battery life, 30-40% more compared with Modaco ROM (till FR14).
Anybody have tried higher frequencies (1300-1400)?
Thanks a lot.
Click to expand...
Click to collapse
I have been using this all day running 1300Mhz @ 1200mV - normal use with wifi on - 84% battery left after ap. 12 hours
[GT-i9195][cm11] - [ROM](Feb.2016)&[kernel](ECOACTIVE & ECOPLUG)(OC/UV)(20151210)
This is a GT-I9195 CM11 kernel highly optimized to best possible performance and energy efficiency.
It may work on Slim (confirmed), AICP (confirmed) and Carbon Rom (confirmed) as well.
It will not work on any Samsung Stock based ROM.
- built from latest avalable CM sources
- CPU OC: 1998 Mhz (light: 1782 MHz) (default and max.)
- reworked freq- tables (unique 108 MHz-steps) for fast scaling
- CPU UV: -50mv (light: -25mv) (default, adjustable)
- GPU OC: freq steps changed to 192-400-608 MHz (light: 192-400-554 MHz)
- L2 OC/UV for extra performance (stock setting is a bottleneck, especially with OC)
- improved bus scaling
- RAM UV
- adjusted msm_thermal to prevent too much thermal throttling under heavy load
- added new "ECOACTIVE" governor and set as default
- added new "ECOPLUG" hotplug driver and set as default
- added FIOPS IO Scheduler and set as default
- added some more commonly used IO schedulers
- added fast random (and enabled via init.d)
- built with official gcc 4.8 with -O3 flags
"ECOACTIVE" is the ultimate governor for lag free performance and good battery life at the same time. It's based on interactive governor. It has a special input gain including the menu, home and back buttons. Separate input gain, fullspeed and eco/screen off phases minimize the use of high frequencys whithout slowing down the device noticably. The upscaling is more agressive during the input phase (default 1s). In the following fullspeed phase (default 10s, set to 0 for unlimited) full performance is allowed. The third phase is configured for battery saving usage while reading, watching videos, music listening or when the screen is off. This ensures maximum responsiveness and best gamig experience along with best possible battery life when reading, listening to music etc.
"ECOPLUG" is an alternative hotplug driver based on AutoSMP. It works much snappier on our device than the stock msm-mpdecision. On default setting second core is down when screen is off.
Everything is fully "pretweaked".
Flash from recovery, enyoy... no need to adjust anything via init.d or app.
Dont flash this kernel if you don't know how to fix problems after flashing !
Make a backup before flashing this kernel !
The hardware parameters are adapted near to the limits of my phone. This means this kernel will not work if your devices hardware cannot handle the OC/UV.
If you are lucky you run the fastest kernel available for your phone
If your phone doesn't run with the "lombartz kernel" you may try the "lombartz light kernel" with less agressive OC/UV.
My latest pure CM11 ROM build (Feb. 2016):
https://drive.google.com/open?id=0B-1RyGtdRvCwWEVfc0ZhTTRzdXc
If you use Xposed framework you need to flash XposedFix after ROM.
regards,
lombartz
...updated.
this kernel is amazing but i have a problem when i connect the smartphone at bluetooth radio. In this case my smartphone freeze and always reboot.
sorry for my english
Hi, thanks for yor feedback Have you already checked if you have the same problem with the last official CM11 kernel from 20150105 ?
regards,
lombartz
edit: tested with my laptop as bluetooth- speaker with no problems. My actual Version is heavily tweaked at the Moment but nothing changed with audio or bluetooth.
Anyone else with bluetooth- playback issues out there ?
edit: found a possible reason for the problem. hope it's fixed in new version (see OP)
Thank you for this. Any chance to include f2fs into the kernel?
bongster said:
Thank you for this. Any chance to include f2fs into the kernel?
Click to expand...
Click to collapse
It's already included, I tested it just now with my actual Version via USB OTG a d could read and write. It should also work with the 20150212 Version.
regards,
lombartz
lombartz said:
It's already included, I tested it just now with my actual Version via USB OTG a d could read and write. It should also work with the 20150212 Version.
regards,
lombartz
Click to expand...
Click to collapse
Strange. My data and cache partition are f2fs and with the f4ktion cm11 kernel all is working well, but after installation of your kernel I'm stuck at the boot logo.
bongster said:
Strange. My data and cache partition are f2fs and with the f4ktion cm11 kernel all is working well, but after installation of your kernel I'm stuck at the boot logo.
Click to expand...
Click to collapse
Here is a Version without OC/UV or other tweaks but with all CM Updates. Its about 20% slower than the tweaked Version but more actual than the V20150212.
If this one boots your phone doesn't like my OC/UV settings...
lombartz said:
Here is a Version without OC/UV or other tweaks but with all CM Updates. Its about 20% slower than the tweaked Version but more actual than the V20150212.
If this one boots your phone doesn't like my OC/UV settings...
Click to expand...
Click to collapse
Thank you very much! I will test it and report back! If I understand it right, f2fs support is also in stock cm11 kernel?
I never tried it...
bongster said:
Thank you very much! I will test it and report back! If I understand it right, f2fs support is also in stock cm11 kernel?
I never tried it...
Click to expand...
Click to collapse
Yes.
lombartz said:
Yes.
Click to expand...
Click to collapse
No luck. I also tried flashing the latest cm11 nightly with no luck.
If I remember right I've tried the stock kernel some time ago only formatting the cache partition and this didn't work either.
20150212 working nice with latest Carbon 4.4.4
can you please add option to underclock min CPU to 162/270 MHz?
spixy said:
20150212 working nice with latest Carbon 4.4.4
can you please add option to underclock min CPU to 162/270 MHz?
Click to expand...
Click to collapse
This is a technically useless placebo feature and doesn' t save any energy.
The HFPLL has to be used to get the lower frequencys and this will eat the saved energy.
br,
lombartz
bongster said:
No luck. I also tried flashing the latest cm11 nightly with no luck.
If I remember right I've tried the stock kernel some time ago only formatting the cache partition and this didn't work either.
Click to expand...
Click to collapse
Hmm, the reason is the fstab.qcom, /cache and /data is expexted to be ext4.
Can be changed but I dont know how to allow both fs at the moment.
lombartz said:
This is a technically useless placebo feature and doesn' t save any energy.
The HFPLL has to be used to get the lower frequencys and this will eat the saved energy.
br,
lombartz
Click to expand...
Click to collapse
hi, I dont know what HFPLL is (some high frequency PLL), but I trust you
but still, is more battery efficient to hold wakelock with 162MHz than with 384, no? (see my previous post)
But on theother hand, 50mW diference between 162 and 384 MHz isnt realy so large...
spixy said:
hi, I dont know what HFPLL is (some high frequency PLL), but I trust you
but still, is more battery efficient to hold wakelock with 162MHz than with 384, no? (see my previous post)
But on theother hand, 50mW diference between 162 and 384 MHz isnt realy so large...
Click to expand...
Click to collapse
I suppose you mean 50 mV ? The lower UV limit is reached at about 384 MHz anyway.
Youre right with hfpll. Only at 384 MHz the CPU runs with pll8.
If you undervolt @ 384 manually as much as possible you will find that you cannot go noticeably lower if you clock down further.
At the Moment I am testing other tweaks that should be more effective an give some extra performance.
bongster said:
No luck. I also tried flashing the latest cm11 nightly with no luck.
If I remember right I've tried the stock kernel some time ago only formatting the cache partition and this didn't work either.
Click to expand...
Click to collapse
If you like to you can test this. But please make a full backup before because i did not test it myself. I don't want to reformat my phone for f2fs at the moment.
If it boots you are a tester for all the new changes ...
This Version will not run with ext4 /cache and /data partitions.
lombartz said:
If you like to you can test this. But please make a full backup before because i did not test it myself. I don't want to reformat my phone for f2fs at the moment.
If it boots you are a tester for all the new changes ...
This Version will not run with ext4 /cache and /data partitions.
Click to expand...
Click to collapse
Thank you very much!
After app optimisation the phone reboots and after the reboot it hangs at the Samsung logo. Only recovering the old boot image helps. Don't know if the oc is the reason.
Update:
I've tried oc with f4ction kernel and had also a reboot. I guess my CPU is not the best.
bongster said:
Thank you very much!
After app optimisation the phone reboots and after the reboot it hangs at the Samsung logo. Only recovering the old boot image helps. Don't know if the oc is the reason.
Update:
I've tried oc with f4ction kernel and had also a reboot. I guess my CPU is not the best.
Click to expand...
Click to collapse
I am sorry. Should not publish something I did not test myself...
What OC Values did you use with f4ction ?
lombartz said:
I am sorry. Should not publish something I did not test myself...
What OC Values did you use with f4ction ?
Click to expand...
Click to collapse
No problem. I'm aware of the issues that can happen.
Normally I use f4ction as it is with 50uv. For the test I oc'ed to 1998mhz.
This is the Q&A thread for Helium.
You don't know where to post something? This schema will help you.
Questions about the kernel (Does it have ****?) > here
Problems you faced, and/or their solutions > here
Weird problems I could be able to solve > the development thread
Things I should read/know > the development thread
Questions that can be answered by any user (not only by me) > here
Miscellaneous posts > here
In a nutshell, if you have to post something that I have to read, post it in the development thread, otherwise use this thread.
I will not read this thread at all. Or maybe I'll check it every now and then
Mention me if I should read something.
Testing helium in temasek, for now all working right and cpu freq. goes to 1728Mhz. Very similar to last stock cm kernel but with usb fast charging :good:
I have a question @tommons (or sombody): Why do you include KSM? In Tangerine kernel it made the device laggy, increasing the power consumption due to the continous work of cpu cores and soon many of us saw that this feature wasn't good to our Xperia Sp. I always leave it off and better overall performance is achieved.
In init.d options of Kernel adiutor we can see the entry 01tangerine. Delete this entry is the same that going to /system/etc/init.d? I suppose that is.
BTW, great work and thanks for your dev time.
Alvichone said:
Testing helium in temasek, for now all working right and cpu freq. goes to 1728Mhz. Very similar to last stock cm kernel but with usb fast charging :good:
I have a question @tommons (or sombody): Why do you include KSM? In Tangerine kernel it made the device laggy, increasing the power consumption due to the continous work of cpu cores and soon many of us saw that this feature wasn't good to our Xperia Sp. I always leave it off and better overall performance is achieved.
In init.d options of Kernel adiutor we can see the entry 01tangerine. Delete this entry is the same that going to /system/etc/init.d? I suppose that is.
BTW, great work and thanks for your dev time.
Click to expand...
Click to collapse
KSM (in v2, UKSM) is there as an option. Nobody forces you to use it It uses more power but the result is a better RAM management.
Yes you can delete 01tangerine from Kernel Adiutor too.
Trying v2 with carbon 5.1.1 seems everything OK..good work man ;D
Sent from my Xperia SP using Tapatalk
Waiting eagerly to have it fully working on CM13.. Please @Tomoms hurry up :silly:
MizoSome said:
Waiting eagerly to have it fully working on CM13.. Please @Tomoms hurry up :silly:
Click to expand...
Click to collapse
Wait more or less 70 hours and you'll have it
I have tangerine 9.1 and CM12.1 on my device. Which steps i need to follow in order to have Helium?
Overclocking?
Can you build a overclocking option from this Kernel, In Tangerine Kernel my Cellphone is stucked on 1444 MHz on all gorvenors, Can you do it? A Overclocking to 1.94 GHz or more ?
pilger said:
I have tangerine 9.1 and CM12.1 on my device. Which steps i need to follow in order to have Helium?
Click to expand...
Click to collapse
Flash the stock boot.img of your CM build (if you have CM+Addons, it would be better if you flashed the boot.img of the Addons you have installed on your device), enter TWRP, install Helium.
Or, in an easier way, next time you update your CM nightly flash Helium instead of Tangerine!
JhonesMillionBR said:
Can you build a overclocking option from this Kernel, In Tangerine Kernel my Cellphone is stucked on 1444 MHz on all gorvenors, Can you do it? A Overclocking to 1.94 GHz or more ?
Click to expand...
Click to collapse
Overclock needs some work and I'm very busy at the moment. Frequency fixes will come very very soon. In the mean time you can flash v2.1, which hasn't got any issues with frequencies.
@Tomoms I am not able to install v2.2 on cm 12.1 using twrp it says unpacking kernel and nothing happens I have to hard reboot.anyone know how to solve this?
Helium Kernel v3
On Helium Kernel v3 the frequency is stucked on 1458 MHz on both cores on all gorvenors and I/O Schedulers.. :crying: :crying:
Image Link: http://tinypic.com/r/vcv2ft/9
JhonesMillionBR said:
On Helium Kernel v3 the frequency is stucked on 1458 MHz on both cores on all gorvenors and I/O Schedulers.. :crying: :crying:
Image Link: http://tinypic.com/r/vcv2ft/9
Click to expand...
Click to collapse
Good! Well, actually that's bad, but I expected it. Will fix ASAP (that is, unfortunately for you, on Sunday/Monday).
Use v2.1, it doesn't have problems.
For the others: I remind you that this doesn't mean v3 is buggy. This bug appears only on certain devices confused and mine is one of the "lucky" ones. So the best thing to do is to try v3 and see if you're lucky or unlucky. Hopefully, the bug will be fixed with v3.1.
JhonesMillionBR said:
On Helium Kernel v3 the frequency is stucked on 1458 MHz on both cores on all gorvenors and I/O Schedulers.. :crying: :crying:
Image Link: http://tinypic.com/r/vcv2ft/9
Click to expand...
Click to collapse
Same here
Sent from my Xperia SP using Tapatalk
Tomoms said:
Good! Well, actually that's bad, but I expected it. Will fix ASAP (that is, unfortunately for you, on Sunday/Monday).
Use v2.1, it doesn't have problems.
For the others: I remind you that this doesn't mean v3 is buggy. This bug appears only on certain devices confused and mine is one of the "lucky" ones. So the best thing to do is to try v3 and see if you're lucky or unlucky. Hopefully, the bug will be fixed with v3.1.
Click to expand...
Click to collapse
It will be that the kernel comes out today ? I'm anxious
JhonesMillionBR said:
It will be that the kernel comes out today ? I'm anxious
Click to expand...
Click to collapse
It's out
Helium Kernel v3.1
Tomoms said:
It's out
Click to expand...
Click to collapse
CPU frequency table finally fixed? Needs testing.
Test: Yes, All gorvernors and I/O Schedulers is working with 1944 MHz, Tested!
Thank you, Tomoms
Is TRIM support planned? I think that it is essential for device with such slow flash memory.
As for now I'm using heavily customized Tangerine 9.2 + last Xenon HD which gives great performance, but has issues (inaccurate GPS, big lag after locking the screen, touchscreen not working couple times a week and a few more). Tested latest CM12.1 + Helium 3.1 for few hours and it looks promising, but feels slower than much more bloated Xenon HD + Tk9.2 (used since September) possibly due lack of TRIM support.
michuroztocz said:
Is TRIM support planned? I think that it is essential for device with such slow flash memory.
As for now I'm using heavily customized Tangerine 9.2 + last Xenon HD which gives great performance, but has issues (inaccurate GPS, big lag after locking the screen, touchscreen not working couple times a week and a few more). Tested latest CM12.1 + Helium 3.1 for few hours and it looks promising, but feels slower than much more bloated Xenon HD + Tk9.2 (used since September) possibly due lack of TRIM support.
Click to expand...
Click to collapse
You can use the command line utility called fstrim or mount the partitions with the "discard" option. The latter way is more difficult because it requires unpacking the kernel, the ramdisk, and then repacking everything.
Swap crashing problem is resolved in v3.2?
Tomoms said:
You can use the command line utility called fstrim or mount the partitions with the "discard" option. The latter way is more difficult because it requires unpacking the kernel, the ramdisk, and then repacking everything.
Click to expand...
Click to collapse
I think that it was my mistake - I cannot remember if I enabled root before issuing TRIM - shame on me
I am using Trimmer utility and running it resulted in instant execution without returning trimmed size in gigabytes pointing that either root was not enabled or TRIM was not supported. Judging by your reply I can assume that TRIM is supported so I think that I'll make second attempt to CM12.1 when touchscreen issue is fixed* or CM13 when camera will be working.
* I just read that @Adrian DC fixes has been merged in 3.2! I will check that kernel as soon as I can! :angel:
Here's my release of a slightly modified kernel for Zuk Z2 Pro. It's all somewhat basic, but still, maybe someone is interested.
void3.5(oc): Old AEX4.5 Android 7.1 Nougat
void5.1bat is only for AEX 5.3.
void5(oc/ocx) for AEX 5.4 <= 0411
void5ocx-mracar: Special version for Cosmicos and RR before full treble (before April 18)
For AEX 5.4-0418 and similar full-treble vendor-partition-enabled ROMs (RR working!) use void5.4.
max GPU frequency raised from 624Mhz to 653MHz (710 for ocx-Edition)
Actually I wouldn't consider this as an overclock because 653Mhz is default for Snapdragon 821, which also has Adreno 530 GPU. Yields around +2-3k in Antutu 3D score, if you're not hitting temp throttling. For that, I've included a modified thermal-engine.conf, which simply makes sense because the default limits are ridiculously low imo. There is no danger involved anyway because there are additional kernel/hardware mechanisms in place to prevent serious overheating. In fact, thermal-engine.conf can be empty (like on RR), but I'd say it's a good idea to keep it in place and prevent the phone from getting uncomfortably hot to touch. It does get warm now though!
Westwood+ TCP congestion algorithm (default)
Supposedly superior for moblie devices, but well, who knows. This had to be benchmarked and profiled in great detail, which is a difficult thing to do. I've made it default anyway, mainly because it seems to be popular and I cannot notice any negatives so far.
Zen I/O scheduler (from dorimanx OP3T kernel)
As above, hard to quantify. But I don't like CFS/BFQ for mobile devices and am in fact leaning towards Deadline, which is also included. Kernel defaults to ZEN nevertheless, but note that this is probably overwritten by the ROM's custom startup scripts. Check with kernel tools like "Kernel Adiutor" and change to Zen if you want to give it a try.
(But beware of Kernel Adiutor - it doesn't quit cleanly and hogs cpu, at least sometimes. Check with some task manager app like "System Panel" and kill it!)
F2FS enabled (untested!)
People seem to be keen on F2FS, so I thought, why not include it. Note that AEX builds from 0825 onwards also have this by default. Untested, because I don't have any F2FS partitions. Might try it in the future though - certainly makes sense.
Cleanup kernel config / Optimize build options
Remove unecessary kernel config options, optimize build, silence debug syslog output.
Ignore specific min CPU frequency request from userspace
Well, yes, totally stupid. But I couldn't find any other way to "disable" AOSP CPU-boost on touchscreen interaction (or whatever it is called). I don't like this feature - we have input boost in the kernel for that. Trying to control CPU freqs from userspace is just no good idea imo.
(Actually... I'd suggest disabling kernel's input boost also. CPUs are fast, even the small cores, and there shouldn't be any noticable lag. And if so, tune/optimize scheduler and/or governor instead.)
This change certainly helps with battery life, but how much exactly... I don't know.
Voltage Control (from optimumpr)
Added voltage control through sysfs interface (/sys/devices/system/cpu/cpuX/cpufreq/UV_mV_table). Use for example Kernel Adiutor to tweak, but beware, undervolting _together_ with overclocking does not play well on this device.
Overclock-Xtreme-Edition (ocx)
CPU is raised to 1.80/2.32 GHz and GPU to 710 MHz (!). Bus speeds are also slightly increased and performance should be a bit better than what the small increase in pure CPU-speed might suggest.
Note that the ocx-kernel is really borderline and certainly depending on the specific phone. If it doesn't boot, blue-led-of-death, and/or random apps are crashing, just use the normal oc-edition. The difference is not that big and battery life of ocx is somewhat worse. This is just for fun!
Underclocked aka battery-optimized edition (bat)
CPU underclocked to 1.4/1.92 per default, GPU 510Mhz. Underclocks can be disabled on runtime, enabling 1.67/2.23 CPU and 653 MHz GPU, which is still oc'd compared to stock, but lower than ocx. To disable underclock:
Code:
echo 0 > /sys/module/msm_performance/parameters/void_underfreq
Big thanks to all involved kernel devs and especially davidevinavil for maintaining Z2 Pro for AEX. :good:
UPDATE 20180418 - void5.4bat - void5.4ocx - AEX/RR full treble with vendor partition
UPDATE 20180402 - void5.1bat Underclocked - AEX 5.3 only!
UPDATE 20180324 - void5oc - void5ocx
UPDATE 20170916 - void3.5 - void3.5oc - For AEX 4.5
3.3 adds a more extensive "tuning"-script, located in /system/etc/void_tuning.sh. This is executed after boot and activates the default profile qpwr. Here's a list of the available profiles with a short description:
qpwr: Goal is congesting tasks on the silver cores, kicking in the bigger cluster only when more capacity is needed. All this with focus on prolonged battery life. (default)
qperf: Somewhat similar to qpwr, but with focus on performance. Freqs ramp up faster and schedulers generally act more "quickly". You can use this for benchmarks, should give the best results, but in real life usage I think the benefits are really non-existent.
qmix: No, this is _not_ intended to strike a balance between pwr/perf. Instead, the idea is to distribute the load evenly across all cores, effectively keeping freqs on a lower level on average. I'm not sure yet how this turns out with regards to battery life, but on SD820/821 it might be a valid strategy. You know, power requirements for the golden and silver cores are about equal for any given freq and both are (nearly) equally efficient. A point against this strategy might be, at least in theory, that esp. the golden cores are more frequently prevented to enter deep sleep states, even during light usage. But well, I'm not sure how big the impact on battery life really is and whether the non-linear power characteristic of these cores make up for it. I am running/testing qmix myself right now...
Currently this is not working. Still trying to figure out how to run the script automatically on boot for these 8.1 ROMs. Ideas?
My suggestion as of now is to run the script manually. There might be some apps helping with that. /system/etc/void_tuning.sh. Just execute it.
BACKUP YOUR DEVICE BEFORE FLASHING THIS PACKAGE! (use latest TWRP for Oreo ROMs!)
I CANNOT GURANTEE IT WILL WORK UNDER ALL CIRCUMSTANCES, ESPECIALLY WITH PREVIOUSLY MODIFIED BOOTPARTITIONS / RAMDISKS / WHATEVER !!!
Kernel source: https://github.com/virtvoid/android_kernel_zuk_msm8996-1
Kernel source: https://github.com/virtvoid/android_kernel_zuk_msm8996-5
---
Other things worth mentioning:
o void5.4ocx Antutu 7.0.6 score on an idle AEX5.4-1704 system is expected to be around 172k, +- 2k. If not, then there's something hogging cpu. Try a reboot, let it settle down and/or check with some task manager app if you still cannot reach these scores.
CHANGELOG
20180418 void5.4ocx - void5.4bat
o Full Treble with vendor partition
o ocx-edition + bat-edition
o switched to cosmedd's kernel base (latest caf updates)
20180324 void5oc - void5ocx
o Linaro GCC 7.2.1
o oc-edition + ocx-edition
o DD3Boh kernel base
20170916 void3.5 - void3.5oc
o Linaro GCC 6.4.1
o Normal + OC-edition
o lots of small patches, mainly battery-related (see Github)
20170905 void3.3
o Hopefully fix camera slomo issue
o more extensive void_tuning.sh script
o drop series 1/2 kernels for now
20170830 void3.2
o Enable Qualcomm HMP scheduler
o some scheduler tuning (/system/etc/void_tuning.sh)
o Enable cpu overclocking as default
20170827 void1.2 - void2.2 - void3.1
o void1.2: Based on AEX kernel 0810 (and prior?)
o void2.2: Based on CallMESuper kernel from AEX 0820, completely different source
o void3.1: Based on AEX kernel 0825, which is somewhat of a rollback/remake/enhancement of 0810, afaict.
o update each branch to latest version
o Voltage Control
20170826 void2.1
o Tone down kcal default saturation a bit
o Linaro GCC 5.4.1 toolchain
o Optimized CFLAGS
o Add (back) a few config options
20170824 void2
o initial release
Thank you ! I already flashed it and it's working perfectly on AEX last version.
I'm thinking to keep your kernel definitively.
Bryandu13 said:
Thank you ! I already flashed it and it's working perfectly on AEX last version.
I'm thinking to keep your kernel definitively.
Click to expand...
Click to collapse
Thanks, great to hear. Have you tried enabling CPU overclocking?
void23 said:
Thanks, great to hear. Have you tried enabling CPU overclocking?
Click to expand...
Click to collapse
Yeah, It's the 1st thing I did and it's working normally
Envoyé de mon Z2 Pro en utilisant Tapatalk
Downloading, I want test it on RR 5.8.3 F2FS data and cache!
Ninnix96 said:
Downloading, I want test it on RR 5.8.3 F2FS data and cache!
Click to expand...
Click to collapse
Great, that's interesting. Tell us your findings!
void23 said:
Great, that's interesting. Tell us your findings!
Click to expand...
Click to collapse
bootloop , thanks for your work, I hope to test a new version soon!
Ninnix96 said:
bootloop , thanks for your work, I hope to test a new version soon!
Click to expand...
Click to collapse
Hmm...
I don't have any experience with F2FS partitions, but I'm going to try booting RR 8.5.3 with this kernel later...
void23 said:
Hmm...
I don't have any experience with F2FS partitions, but I'm going to try booting RR 8.5.3 with this kernel later...
Click to expand...
Click to collapse
The only version work with F2FS is 5.8.3 of 26/6
I can report that it works well with lineage-14.1-20170803-UNOFFICIAL so far.
No boot loop or other issues.
Ninnix96 said:
The only version work with F2FS is 5.8.3 of 26/6
Click to expand...
Click to collapse
Ok, I've just checked with 5.8.4, no F2FS partition, boots up fine. So it either has to do with F2FS partitions, and/or this specific 26/6 version of RR.
But testing this is a good opportunity to give F2FS a try. Give me a few days...
void23 said:
Ok, I've just checked with 5.8.4, no F2FS partition, boots up fine. So it either has to do with F2FS partitions, and/or this specific 26/6 version of RR.
But testing this is a good opportunity to give F2FS a try. Give me a few days...
Click to expand...
Click to collapse
No hurry you've done too much
@void23
Thanks for the excellent work. First time antutu crossed the 160k mark with ur kernel.
@void23
One issue though, camera is force closing. Have tried stock cam on AEX, Moto camera, PMS next mod camera and camera zoom FX. All FC.
Anyway to revert to AEX or another kernel short of flashing full ROM?
sanjay0501 said:
@void23
One issue though, camera is force closing. Have tried stock cam on AEX, Moto camera, PMS next mod camera and camera zoom FX. All FC.
Anyway to revert to AEX or another kernel short of flashing full ROM?
Click to expand...
Click to collapse
Just flash ROM again.
But in my case on AEX there is no problem.
Envoyé de mon Z2 Pro en utilisant Tapatalk
Bryandu13 said:
Just flash ROM again.
But in my case on AEX there is no problem.
Envoyé de mon Z2 Pro en utilisant Tapatalk
Click to expand...
Click to collapse
Dirty flashed AEX 2407 after dalvik and cache wipe again and then flashed void kernel, still camera FC
Now flashed AEX without void kernel and camera working.
Maybe some issues with my apps so will try a clean flash and see. Have been having frequent issues with battery drain also recently with AEX 4.5 2010 so flashed back to 2407 which seems to suit my phone better.
sanjay0501 said:
Dirty flashed AEX 2407 after dalvik and cache wipe again and then flashed void kernel, still camera FC
Now flashed AEX without void kernel and camera working.
Maybe some issues with my apps so will try a clean flash and see. Have been having frequent issues with battery drain also recently with AEX 4.5 2010 so flashed back to 2407 which seems to suit my phone better.
Click to expand...
Click to collapse
Sorry to hear about your camera FC'ing. For me, standard AEX cam and cameranextmod7 both are working flawlessly, so I can only suspect it has to do something with your specific AEX installation. A clean reflash of AEX 0820 should solve the issue.
I noticed I got worse pictures with CNMv7 after flashing this; re-flashed ROM without kernel, and now CNM is giving me great shots again.
In all other aspects, the kernel delivered. Scores were 20000-30000 higher than standard AEX.
Thanks for your efforts, working without problem!!!
Antutu 2nd run after reboot...Excellent scores, no OC.
Dhollmen OMAP4_TI espresso kernel
Credits for Kernel Team and anyone else who has worked on this variant.
FEATURES:
Cpu starts boot at 1216 MHz.
Gpu starts boot at 384 MHz.
Undervolted.
Starts boot with 'interactive' as cpufreq governor.
Starts boot with 'deadline' as block scheduler.
CPU overclock selectable up to 1472 MHz. (see versions)
GPU overclock selectable up to 512 MHz. (see versions)
PowerVR SGX 540 modules built 'in',
Tweaked Init process (Slim 6 variant only)
Network CIFS support.
Reduced operating voltage by a notable percentage.
Added several optimizations to improve performance and reduce overhead.
VERSIONS:
EX version:
Uses 300, 600, 800, 1008 and 1216 MHz CPU frequencies.
Uses 307 and 384 MHz GPU frequencies.
OV version:
Uses 300, 600, 912, 1216, 1360 and 1472 MHz CPU frequencies.
Uses 307, 384 and 512 MHz GPU frequencies.
Rooted room needed to change the frecuencies.
ST_EX version: normal stock Slim 6.0 only
Uses 300, 600, 800, 1008 and 1216 MHz CPU frequencies.
Uses 307 and 384 MHz GPU frequencies.
Normal Slim 6 rom is not rooted, to appear certified in Google-Play. This version tries don't break that certification.
ST_OV version: normal stock Slim 6.0 only
Uses 300, 600, 912, 1216, 1360 and 1472 MHz CPU frequencies.
Uses 307, 384 and 512 MHz GPU frequencies.
Normal Slim 6 rom is not rooted, to appear certified in Google-Play. This version tries don't break that certification.
To change to high frequencies you need your rom rooted.
For all versions there is a specific variant for 7 inches models P31XX
Mention for nemes480 who has kindly put his time and his tablet at disposal to establish the best voltages for the 7-inch model.
Download Dhollmen 6 & Slim 6 releases
WARRANTY: You agree that this product is provided "as is" without any warranty, either expressed or implied, on its operation.
DISCLAIMER: You assumes at your SOLE RESPONSIBILITY and RISK all results produced by the "software" and/or instructions in this thread.
XDA:DevDB Information
Dhollmen kernel omap4, Kernel for the Samsung Galaxy Tab 2
Contributors
tuxafgmur
Source Code: https://github.com/Dhollmen/Kernel_omap4_ti_espresso
Kernel Special Features:
Version Information
Status: Beta
Beta Release Date: 2019-04-08
Created 2019-04-09
Last Updated 2019-04-13
.
Note:
The voltage settings that I have applied here, are different from those I used in my previous kernel.
For now, the date of the beginning of the thread, they have only been tested on my own tablet.
I have runned twice (in each and every one of the frequencies, CPU and GPU)
the Antutu stress tests and 3DMark OpenGL tests.
On the other hand, @nemes480 has carried out exhaustive tests to find the most suitable values for the 7-inch models.
Reserved
Nice work! I hope there will be nougat support too! ?
Edt: None of Ov, Ex and St versions works with Andi's Slim6 (P3110), black screen on boot! :/
nemes480 said:
Nice work! I hope there will be nougat support too! [emoji7]
Edt: None of Ov, Ex and St versions works with Andi's Slim6 (P3110), black screen on boot! :/
Click to expand...
Click to collapse
That's because some kernel changes are missing. We'll soon switch to newer DDK on our source. @Ziyan and @amaces put a lot of time, energy and afford into getting the new ddk running from 4.4 up to 7.1. Big thanks to both of them!
If there's special questions or something likes to be contributed back to us @tuxafgmur can contact me (even if my last email to him wasn't answered) or wait until needed changes are merged to Unlegacy Android.
Android-Andi said:
That's because some kernel changes are missing. We'll soon switch to newer DDK on our source. @Ziyan and @amaces put a lot of time, energy and afford into getting the new ddk running from 4.4 up to 7.1. Big thanks to both of them!
If there's special questions or something likes to be contributed back to us @tuxafgmur can contact me (even if my last email to him wasn't answered) or wait until needed changes are merged to Unlegacy Android.
Click to expand...
Click to collapse
I'm following development so I knew it there was kernel changes, but I thought tuxafgmur made this from that new source. Big thanks tuxafgmur!!! Interesting that the twrp recognize all espressowifi rom as p5110 or espressowifi10 insted of p3110 with both common and device specific twrp. (04.09.).
nemes480 said:
I'm following development so I knew it there was kernel changes, but I thought tuxafgmur made this from that new source. Does not matter, I tried with the dhollmen slim and everything was okey! Big thanks tuxafgmur!!! Interesting that the twrp recognize all espressowifi rom as p5110 or espressowifi10 insted of p3110 with both common and device specific twrp. (04.09.).
Click to expand...
Click to collapse
Yes he's using the common source (actually stable), but not those needed changes for newer DDK (will be merged soon in our stable trees, as there's no issues known yet).
About espressowifi/espresso3g:
All common ROMs use p5100 (espresso3g) or p5110 (espressowifi) fingerprint and build description to pass safetynet. You can edit your system/build.prop back to your device defaults, but it won't change anything in the end.
Edit:
Our kernel checks panel id which is passed by the bootloader and this way we know used variant. Variant is stored in sysfs which is used by audio hal for example.
To get an idea about it:
https://github.com/OMAP4-AOSP/andro...mmit/aad0f82e532dd991b4f2a74c0ee5f6d169d0ffdc
https://github.com/OMAP4-AOSP/andro...mmit/2268c59cbb81eec3bb7618f4cefc4913d32c4bef
https://github.com/OMAP4-AOSP/andro...mmit/dcb93bda2aa111c96b947d723aa63c132285f35f
https://github.com/OMAP4-AOSP/andro...mmit/b34632e91aafd20f811976f036a225b1e04fdadf
https://github.com/OMAP4-AOSP/andro...mmit/f4fc754bf9f78fe4f1e22ea1c2d75211a08f9514
https://github.com/OMAP4-AOSP/andro...mmit/30f92e10f9ade5a186dbad26a0aa09868506adc7
https://github.com/OMAP4-AOSP/andro...mmit/5e3bc1c436c5aea81462b4e47011effb3c349c4a
https://github.com/OMAP4-AOSP/andro...mmit/e5b79a5f15f717782bfe3f419b03914f3aeff09b
https://github.com/OMAP4-AOSP/andro...mmit/e41985f0dec3bb12cc99dd27ed9d757a3e6106c7
https://github.com/OMAP4-AOSP/andro...mmit/53df0adf88b7748ec19a9c727bee3675181b0dd0
https://github.com/OMAP4-AOSP/andro...mmit/17c5946b5312e5545e808e65b2e58ebd101c6d74
https://github.com/OMAP4-AOSP/andro...mmit/e3994e7d7a478bfbc7a1c99d7e6bcae83d0c0189
https://github.com/OMAP4-AOSP/andro...mmit/e9d2f3dbe2c8f66aeeabe453cbc18136b1ff72aa
https://github.com/OMAP4-AOSP/andro...mmit/294e7833340cf0da624124082cf288b8e2a02599
https://github.com/OMAP4-AOSP/andro...mmit/c10890e2659547085698866148ee37fa5757c37b
https://github.com/OMAP4-AOSP/andro...mmit/3531c0bbbf8e9d0aa04cee6ddca5528f141ac3aa
https://github.com/OMAP4-AOSP/andro...mmit/754db03e86448301e7af25b9be61c14aaab24847
More here if needed: https://github.com/OMAP4-AOSP/android_kernel_samsung_espresso/commits/history
Thanks tuxafgmur!
Finally we have options!
Will test and report here ASAP.
OBS: Think there is a mistaken info in OV build: "Uses 300, 600, 912, 1216, 1360 and 1272 MHz CPU frequencies." Should it be 1472 for the last frequency ?
galoneta said:
Thanks tuxafgmur!
Finally we have options!
Will test and report here ASAP.
OBS: Think there is a mistaken info in OV build: "Uses 300, 600, 912, 1216, 1360 and 1272 MHz CPU frequencies." Should it be 1472 for the last frequency ?
Click to expand...
Click to collapse
Yes, it is a mistake :good:
nemes480 said:
Nice work! I hope there will be nougat support too! ?
Edt: None of Ov, Ex and St versions works with Andi's Slim6 (P3110), black screen on boot! :/
Click to expand...
Click to collapse
Perhaps 7-inch models can not withstand such lower voltages.
If it is confirmed and nobody can boot from that mode, I'll have to do something about it.
For now, regarding the overclock, this kernel is a test version,
but I did not expect this kind of problems since, from my point of view, I have left margin enough to do boot at 1216 MHz.
My tablet can start at 1216 MHz with a lot less voltage.
I apologize for this issue. Thanks you for your feedback.
EDIT
Hi @nemes480
Can you install the below test kernel (with higher voltages) and tell me the result?
Thanks in advance.
Android-Andi said:
Yes he's using the common source (actually stable), but not those needed changes for newer DDK (will be merged soon in our stable trees, as there's no issues known yet).
Click to expand...
Click to collapse
Yes, i'm using the kernel forked from Slim repositories https://github.com/SlimRoms/kernel_ti_omap4 (as indicated in may github repo) to make an kernel to Slim 6 rom.
At this time, it's my only interest.
Regarding the rest of the post and all the links, suffice it to say that Ziyan took all the
work to unify the branches corresponding to the five Samsung Tab2 tablet models.
Mr tuxafgmur, reporting:
Using Twrp_Tab2-3.2.3.0.zip flashed in one step Slim-espressowifi-6.0.1-Dhollmen-20190331.zip + Dhollmen_Slim_Kernel_OV-20190408.zip = Everything runs fast and stable in my P5110.
Will test in P3110 ASAP and report here again. My friend has an P3100 and it is running your previous build too: It will be the next one to be tested!
Question: Would it be possible to release a 1520MHZ build as we had in previous Dhollmen Kernels: all my known galaxy 2 devices (P5110, P3110 and P3100) run fine at these speeds and the tablet behavior is far different from stock speeds! Maybe this would be the "ultimate" build as you can call it!
Dear tuxafgmur: If you need to test something else with these devices I have, please let me know!
Thanks again.
galoneta said:
Mr tuxafgmur, reporting:
Using Twrp_Tab2-3.2.3.0.zip flashed in one step Slim-espressowifi-6.0.1-Dhollmen-20190331.zip + Dhollmen_Slim_Kernel_OV-20190408.zip = Everything runs fast and stable in my P5110.
Will test in P3110 ASAP and report here again. My friend has an P3100 and it is running your previous build too: It will be the next one to be tested!
Question: Would it be possible to release a 1520MHZ build as we had in previous Dhollmen Kernels: all my known galaxy 2 devices (P5110, P3110 and P3100) run fine at these speeds and the tablet behavior is far different from stock speeds! Maybe this would be the "ultimate" build as you can call it!
Dear tuxafgmur: If you need to test something else with these devices I have, please let me know!
Thanks again.
Click to expand...
Click to collapse
What abour battery life? Right now I'm using Noob kernel at about 1200MHz and although OK, it seems not so snappier than stock kernel.
tuxafgmur said:
Perhaps 7-inch models can not withstand such lower voltages.
If it is confirmed and nobody can boot from that mode, I'll have to do something about it.
For now, regarding the overclock, this kernel is a test version,
but I did not expect this kind of problems since, from my point of view, I have left margin enough to do boot at 1216 MHz.
My tablet can start at 1216 MHz with a lot less voltage.
I apologize for this issue. Thanks you for your feedback.
EDIT
Hi @nemes480
Can you install the below test kernel (with higher voltages) and tell me the result?
Thanks in advance.
Click to expand...
Click to collapse
Succesfully booted up Dhollmen Slim6, with your attached kernel, and seems to be relieable! And @tuxafgmur you were right about too low voltage on 7". The device cannot finish boot (EX version I tried), drop back to reboot so process finish in bootloop.
If you need stress tests or else tell me!
Edit: EX verison booted up but, device reboot itself immediately.
barbe31 said:
What abour battery life? Right now I'm using Noob kernel at about 1200MHz and although OK, it seems not so snappier than stock kernel.
Click to expand...
Click to collapse
In the normal use of the tablet, you can't notice much difference between different kernels, only based on the speed sense.
Many processes don't run at high frequencies more than a few miliseconds (they don't even use them at all).
I have not seen Noob kernel patches (I don't know, even, if they are published) but the only "indicative" measurements can be done through synthetic tests, for example with the 3DMark or Antutu tests.
The battery's duration depends on a set of settings that go further than simply raising the frequency.
For example, Dhollmen kernel use almost less voltage at high frequencies than the "stock" kernel at normal frequencies, but the init process adds more settings (in my Rom's version)
nemes480 said:
Succesfully booted up Dhollmen Slim6, with your attached kernel, and seems to be relieable! And @tuxafgmur you were right about too low voltage on 7". The device cannot finish boot (EX version I tried), drop back to reboot so process finish in bootloop.
If you need stress tests or else tell me!
Edit: EX verison booted up but, device reboot itself immediately.
Click to expand...
Click to collapse
Thank you very much! :good:
I have spent a lot of time doing tests with different voltages for each of the possible frequencies.
As I indicated, at thread's beginning, I have passed twice the Antutu stress test and the OpenGL 3DMark test for each voltage change (going down little by little until the tablet restarted)
It's a very tedious process, but the only, to determine the best values.
If you want to do it, you can use Kernel Adiutor to make the voltage changes.
If so, then I would appreciate it if you could tell me the final values.
The problem here, is that you need a rooted ROM and, for the OV version, you need I upload another test OV kernel with high voltages to allow you to boot.
galoneta said:
Mr tuxafgmur, reporting:
Using Twrp_Tab2-3.2.3.0.zip flashed in one step Slim-espressowifi-6.0.1-Dhollmen-20190331.zip + Dhollmen_Slim_Kernel_OV-20190408.zip = Everything runs fast and stable in my P5110.
Will test in P3110 ASAP and report here again. My friend has an P3100 and it is running your previous build too: It will be the next one to be tested!
Question: Would it be possible to release a 1520MHZ build as we had in previous Dhollmen Kernels: all my known galaxy 2 devices (P5110, P3110 and P3100) run fine at these speeds and the tablet behavior is far different from stock speeds! Maybe this would be the "ultimate" build as you can call it!
Dear tuxafgmur: If you need to test something else with these devices I have, please let me know!.
Click to expand...
Click to collapse
I must admit that the CPU of these tablets has a lot of scaling margin, but you will have to recognize, too, that the difference in performance obtained at 1520 MHz is very small compared to the stress to which it is subjected.
Although any modification of the kernel to increase frequencies and voltage start from a common idea (very old and very tested) this time I have made a slightly different approach: achieve total stability with the minimum voltage and REALLY use the voltage determined for each frequency .
On the other hand, to obtain an adequate graphical yield, it is necessary to increase the frequency of the GPU up to 512 MHz, and here, an appreciable stress begins, since the GPU works at maximum or at minimum frequency, not using the intermediates at all.
I would prefer to wait for the opinions of some more people and reach a real consensus.
tuxafgmur said:
Thank you very much! :good:
I have spent a lot of time doing tests with different voltages for each of the possible frequencies.
As I indicated, at thread's beginning, I have passed twice the Antutu stress test and the OpenGL 3DMark test for each voltage change (going down little by little until the tablet restarted)
It's a very tedious process, but the only, to determine the best values.
If you want to do it, you can use Kernel Adiutor to make the voltage changes.
If so, then I would appreciate it if you could tell me the final values.
The problem is that you need a rooted ROM and, for the OV version, you need I upload another test OV kernel with high voltages to allow you to boot.
Click to expand...
Click to collapse
Not a problem, Im using root since my first phone. I have some experice. Im gladly help you out in this, so Im waiting for that OV version.
tuxafgmur said:
In the normal use of the tablet, you can't notice much difference between different kernels, only based on the speed sense.
Many processes don't run at high frequencies more than a few miliseconds (they don't even use them at all).
I have not seen Noob kernel patches (I don't know, even, if they are published) but the only "indicative" measurements can be done through synthetic tests, for example with the 3DMark or Antutu tests.
The battery's duration depends on a set of settings that go further than simply raising the frequency.
For example, Dhollmen kernel use almost less voltage at high frequencies than the "stock" kernel at normal frequencies, but the init process adds more settings (in my Rom's version)
Click to expand...
Click to collapse
Muchas gracias for your detailed explanation. Indeed everything under the hood is not so simple. I think of your work it as craftmanship.
I will try your rom+kernel and report as soon as possible.
Here are the kernel test files for Dhollmen Rom Slim 6
Only for testing best voltage levels in 7-inch models
If someone decides to try them, I hope can tell me the best values obtained.
Thanks in advance.