Hello everyone,
after countless hours of work here it finally is. The first working EAS kernel for our beloved HTC U 11.
Important question: What is EAS?
Energy Aware Scheduling (EAS) is an enhancement to Linux power management, unifying CPU power control under the Linux kernel. EAS extends the Linux kernel scheduler to make it fully aware of the power/performance capabilities of the CPUs in the system, to optimize energy consumption for advanced multi-core SoCs including big.LITTLE. With EAS, the Linux kernel will use the task load and a CPU ‘Energy Model’ to control task placement to select the optimal CPU to run on.
Google thinks, EAS is the way to go for the future. With this kernel you can get pixel (2) experience even before the pixel (2) is released.
Interesting links for further research:
http://www.linaro.org/blog/core-dump/energy-aware-scheduling-eas-progress-update/
https://developer.arm.com/-/media/d...overview_and_integration_guide_r1p3.pdf?la=en
DISCLAIMER:
I had to rewrite and cut out a lot of code to get EAS working. Due to this the prebuilt WLAN and texfat modules are no longer working for this kernel. There are conflicts because I moved to far away from HTC´s codebase.
Because of this I had to compile the WLAN driver from source and integrate it as a module in the kernel zip. To get texfat working I had to built the exfat-nofuse driver from @dorimanx into the kernel.
To allow the kernel to fully operate we need to disable HTC´s PNPMGR.
That means in case you want to go back to a HMP kernel you will have to either backup the wlan module and the pnpmgr files manually or do a nandroid/dirty flash your rom (which is way easier).
This also caused WLAN calling not to work!
Features:
- EAS for 4.4 with patches from 4.9 eas-dev
- Upstreamed to latest 4.4.170
- Rootless interface supported
- Enabled NOOP, DEADLINE, CFQ, MAPLE, TRIPNDROID and BFQ IO scheduler
- Enabled advanced TCP Congestion Control
- Included GPU Boost
- S2S across navbar area
- KCAL color calibration
- Backlight Dimmer
- Button Mapper Support
- Fsync On/Off support
- Green Pulsating Notification LED @tbalden)
- Fingerprint Double Tap to sleep support @tbalden)
- Button Light Notification from @tbalden
- Gradient Charging LED from @tbalden
- Squeeze Control (squeeze to wake/peek/sleep; squeeze to swype) from @tbalden
- Flashlight notification from @tbalden
- Vibrating Notification reminder from @tbalden
- Notification Boost from @tbalden
- Generic wakelock blocker
- Completely rewritten CPU-Boost for EAS (thanks to @RenderBroken) along with Dynamic Stune Boost from @joshuous
- included BFQ IO Scheduler for 4.4 kernels
- USB Fastcharge
- Various CAF improvements
- upstream patches from kernel/common
- Locking Backports from 4.9 Kernel
- OOM_Reaper, OOM_Kill Backport from 4.9 kernel
- Lowmemorykiller Backport from 4.9 Kernel
- RCU backport from 4.9 kernel
Instructions:
1. Please dirty flash your rom to have a clean ramdisk
2. Backup your current setup in twrp
3. flash the zip file/s according to your favorite install method in twrp
4. reboot
5. If you dont want to use @tbalden ´s rootless kernel apps, but traditional root via supersu or magisk delete the uci....cfg file from the root of your sdcard
6. Enjoy your phone
Download:
OREO: https://www.androidfilehost.com/?w=files&flid=251050
Nougat: https://www.androidfilehost.com/?w=files&flid=229307
Changelog:
1.003:
https://forum.xda-developers.com/showpost.php?p=73283377&postcount=174
https://forum.xda-developers.com/showpost.php?p=73283388&postcount=175
ZERO_BETA_2
https://forum.xda-developers.com/showpost.php?p=73500972&postcount=233
ZERO_GAMMA_4
https://forum.xda-developers.com/showpost.php?p=73533313&postcount=296
ZERO_GAMMA_6
2.0
https://forum.xda-developers.com/showpost.php?p=73806358&postcount=386
3.0
https://forum.xda-developers.com/showpost.php?p=73874622&postcount=424
CAF_1.0
https://forum.xda-developers.com/showpost.php?p=73983865&postcount=493
CAF 1.10
https://forum.xda-developers.com/showpost.php?p=74055104&postcount=626
CAF 1.20
https://forum.xda-developers.com/showpost.php?p=74103333&postcount=676
CAF 1.30
https://forum.xda-developers.com/showpost.php?p=74135102&postcount=687
CAF 1.31
https://forum.xda-developers.com/showpost.php?p=74163796&postcount=703
CAF 2.00
https://forum.xda-developers.com/showpost.php?p=74202067&postcount=719
CAF 2.10
https://forum.xda-developers.com/showpost.php?p=74270321&postcount=755
CAF 3.0
https://forum.xda-developers.com/showpost.php?p=74476266&postcount=792
CAF 3.1
https://forum.xda-developers.com/showpost.php?p=74677436&postcount=845
OREO 1.0
https://forum.xda-developers.com/showpost.php?p=75636045&postcount=918
OREO 1.3
https://forum.xda-developers.com/showpost.php?p=75675979&postcount=938
OREO 2.0
https://forum.xda-developers.com/showpost.php?p=75843285&postcount=955
OREO 4.0
https://forum.xda-developers.com/showpost.php?p=76020308&postcount=987
OREO 5.0
https://forum.xda-developers.com/showpost.php?p=76287809&postcount=1029
OREO 7.0
https://forum.xda-developers.com/showpost.php?p=76625681&postcount=1053
OREO 10.0
https://forum.xda-developers.com/showpost.php?p=77187817&postcount=1082
OREO 11.0
https://forum.xda-developers.com/showpost.php?p=77588328&postcount=1107
OREO 12.0
https://forum.xda-developers.com/showpost.php?p=77757572&postcount=1113
OREO 13.1
https://forum.xda-developers.com/showpost.php?p=78144426&postcount=1146
OREO 15.0
https://forum.xda-developers.com/showpost.php?p=78815371&postcount=1170
Credits and Thanks:
I want to say thank you to all those who helped me along my way, who answered all my questions and took their time to support me. Huge thanks to @tbalden @Eliminater74 @Captain_Throwback @RenderBroken
Additionally a huge thanks to @RenderBroken for doing the main work on getting EAS on the android 4.4 kernel. Without him this wouldn´t exist. Drop him a thanks on his threads or show your appreciation with a little donation.
This credit also goes out to @joshuous who works together with @RenderBroken.
Credits:
@flar2 for his complete work
@tbalden for his led tricks, adreno boost etc
@Flinny for helping me with compiling the kernel!
@savoca for Kcal
@Eliminater74 for bringing me into the kernel game
@Sultanxda
@eng.stk
@osmosis
@frap129
@velimirchek for all the testing and support
@tomascus for the nougat base!!
@jsaxon2 for helping me with the OREO magisk module!
and all others that helped me on my way
also for the OREO Kernel Testers!
@zhuchella
@aadeshiscool
@Snah001
@ffh2303
@cjrivera04
@Derepinar
@p50kombi
@CharliesTheMan
@jsaxon2
Donations:
Donations are not mandatory but very welcome..
If you like my work: http://paypal.me/freak07
Source: https://github.com/freak07/OCEAN_OREO_EAS
So this post will be dedicated to information about EAS in general.
Here is a good breakdown on EAS vs traditional HMP (which the other kernels here are using)
Right here we go.
EAS is a completely different breed compared to the conventional HMP system, where it serves an entirely different purpose of achieving the optimal balance between performance and efficiency, with the latter taking the top spot. EAS achieves that via cleverer tasks placement, by which the system determines which is the more efficient cluster for the task to be processed by, as well as categorising the different tasks into cgroups (top-app, foreground and background, in order from highest priority to lowest priority respectively) by which each cgroup receives its sliver of the available firepower (cpuset). EAS also offers the capability of inflating the perceived load, that's determined by the load trackers, of the task in any of the cgroups via its schedtune.boost setting, and whether the task should be processed by all the cpu cores available or only by the cluster the task has been placed on via its schedtune.prefer_idle setting. One of the key features of EAS is lifting almost all the processing from the governor to the CPU scheduler (no it is not the I/O scheduler, something different) and letting it take much much more control, leaving the CPU governor to only do the frequency determination part, which unsurprisingly relies heavily on data supplied by the scheduler. With all that said, it is easily deduced that EAS is not all about governors and governor settings and the like, rather a much cleverer solution that serves the purpose of seeking the best balance between performance and efficiency, and to ensure the CPU is not overdoing a task or the CPU governor is overshooting a simple task, which would attribute to needlessly draining a lot of power as a natural consequence. EAS is about ensuring you get the smoothest UI possible while retaining as much power as possible. However, that does not mean that EAS is lame poor when it comes to performance. Sometimes, if not in most cases, this cleverer tasks placement makes tasks get processed faster, a point that is already proved quite well by the EAS-supporting non-OOS based custom ROMs like VertexOS, ZeNiTy-RR and PAEX. Conserving battery does not necessarily mean crushing performance. This explains that app launches are on-par with HMP if not ahead of it sometimes.
Now on to your question. After going through that brief explanation of EAS, i think your question is actually invalid, since it is not an apple-to-apple comparison anymore. EAS seeks for the optimal balance between performance and efficiency. Should there be a commit to improve performance while not being at the expense of efficiency, EAS should have that stuffed in, whereas HMP is prioritising performance higher than efficiency by design. What Burnout does is taking HMP and making it even more performance oriented, hence it is very unlikely to face micro lags with it. However, HMP still misses the cleverer tasks placement, which can show its canines if you have so much processes going in the background, where in that area EAS takes the lead quite noticeably.
Conclusion: You should try and see what suits you more. But something i can safely say is, EAS is more than satisfactory when it comes to performance from the perspective of a man that always seeks the best performance available, and with the battery gains you yield with EAS, it can go better.
Hope i helped and clear the confusion.
-TDK
A short Explanation on WALT vs PELT. This kernel uses WALT.
RenderBroken said:
An amazing write up by a talented dev @joshuous:
PELT and WALT
Time for me to flex the analogy muscles.
Just to set things straight, PELT and WALT are different load tracking metrics that try to determine the load of the system. The load will eventually be used by the frequency governor to set the frequency. Think of them (the load tracking metrics) as an employee who is dedicated to announcing how quickly customers are coming into your burger restaurant. The frequency governor is the burger chef, who isn't able to see the number of customers entering, so he has to rely on the announcer in order to know the rate at which he is making burgers. The announcer can say that there are "many" customers, and the chef has to decide how fast to make the burgers based on how he interprets "many".
One announcer can say that 10 customers is "many", while another may say that 20 is "many". An announcer may also attempt to predict the number of customers that will enter based on how many he sees at the current point in time. In this way, burger output is more 'bursty'. For example, there are 10 customers ("many"), then no customers ("none"), then 15 customers ("very many"). The chef works hard, then thinks he can take a break for a moment, then suddenly has to work like crazy to dish out burgers for 15 customers. An oversimplified analogy to WALT.
On the other hand, another announcer may observe a trend of customers and apply some prediction to guess how many customers might come through the door. Using the same customer sequence as before, he may instead tell the chef "many", "some", then "many". So the chef may make burgers even when there are no customers, in anticipation of future customers, but he won't be worked so darn hard all of a sudden. This is less bursty and more consistent. An oversimplified analogy to PELT.
In the same way there are different chefs (e.g. Sched and Schedutil). They have different interpretations of what "many" means to them. That's why their burger outputs may be different even when having the same announcer.
So which is better? It all boils down to your workload, and even so it is difficult to make a conclusion. All I can say is that you must test each mechanism for over a week and check your active drain rate (Ex Kernel Manager is good for this). Active drain rate is a much better measure than SOT. And make sure to keep jumping back and forth between the two to account for anomalies.
Edit: On another note, to complete the analogy... Interactive and HMP is more similar to the chef being the announcer as well. Except for he is able to see less than a dedicated announcer can. I.e the chef (interactive governor) can't look at the queue outside his restaurant but only the ones in his restaurant (so he is partly blind). A dedicated announcer can look at customers inside and outside the restaurant though.
Do note that this has little to do with EAS per se. EAS is a different beast that focuses on optimizing which customers is assigned to which chefs. I'll probably write the analogy for this another time if there is a demand for it
Click to expand...
Click to collapse
FAQ
Q: I got the SD is corrupted message after booting and my sdcard is formatted as exfat. What should I do?
A: Reboot to Recovery mount USB storage, unmount it and reboot.
Q: I switched kernels and now my wlan isn´t working?
A: that is because I have to use my own wlan module. restore system of your nandroid. or extract stock wlan module from custom rom.
Q: My device does not sleep and the reason is media scanner is holding the device awake. What to do?
A: There can be a strange case where the exfat nofuse driver I have to use in order for external sdcard to work creates an infinite folder loop.
It can be solved if you check your sdcard with a file manager for a folder like android/data/com.xyz.app/files/files/files/files...... and so on.
Go to twrp recovery move the infinite file folder to the root of external sdcard. Then it can be easily deleted. Before moving the file deleting it is not possible.
Q: How to set up the cleanslate LED/Notification Light/BLN options?
A: Take a look at this post: https://forum.xda-developers.com/showpost.php?p=72710244&postcount=2
Not needed as per Version 3.0
Q: Netflix isn´t playing videos?
A: go to settings -> dev options -> untick disable hw overlays, watch netflix and don´t forgot to tick the option again after using netflix ( say thank you to HTC for not releasing the new source)
So allright guys. This will be the section where you will fine information on how to fine tune the EAS kernel if you aren´t satisfied with my default settings.
So as you can see in a kernel manager like EXKM for example we have an input boost on this kernel.
The 4 little cores ( aka the little cluster) gets boosted to 1171.200mhz for 1500ms when you interact/touch your screen by default.
This ensures scrolling/fling/app loading smoothness.
Now you say, only core 0 gets boosted. But if you look at the source you will see the cpu boost driver works only for both clusters and single cores. This is done by design.
If you want to additionally boost the big cluster (because you aren´t satisfied with above mentioned scrolling/fling/app loading etc) you have to define the boost frequency for core 4 also.
Writeup for dynamic stune boost v1 (OLD)
Now a writeup on dynamic stune boost by @joshuous
For those who are not sure what Stune (schedtune) boosting is, it is an EAS feature that allows you to bias frequencies higher or lower for certain task groups.
Android defines the following task groups that you can boost:
1. Top-app: The task that you're directly working on, or the task that you see. This mostly refers to the app that you're currently interacting with.
2. Foreground: Tasks that are not the top-app, but are still part of the user experience (e.g. the surfaceflinger display thread and audio threads)
3. Background: Tasks that are not part of the user experience (e.g. some random task running in the background that you don't care about)
4. System-background: Similar to background, but specifically for system tasks
5. Root: anything that else that does not belong to the other categories
Why do we need Schedtune boosting when we already have the cpu-boost feature?
cpu-boost works by allowing the user to set the specific boost frequencies and duration for clusters. But how do you know whether the frequency you specified is too little or too much? If you specify 1000 MHz boost for Little cluster, is that overkill for typing, or is it too miniscule for scrolling in a content-heavy app like Google Calendar? You end up facing a dilemma of choosing between increased battery drain or increased smoothness. Personally, I find that cpu-boost is rather inflexible and doesn't scale according to the user's needs.
So how does Schedtune boosting work?
Let's first talk about Schedutil governor. It works by using utilisation data provided by the [Linux] Completely Fair Scheduler. The 'CFS Scheduler' (not I/O scheduler erherm), in simple words, decides which tasks should be assigned to which CPU cores. Based on the Scheduler's knowledge of the tasks it allocates to cores, it can directly sends signals about the cores' utilisation to the Schedutil governor. Think of utilisation as the number of customers that a chef needs to serve at this point in time. The Schedutil governor uses the utilisation value and tells the chef how fast he must cook (what frequency the core should run at).
Now sometimes you may have certain customers (who are part of the Top-App Company) who are in a hurry to get their food and rush back to work. You need to serve the Top-App customers urgently, so you ask the chef to cook even faster than usual. You can think of Schedtune boosting as artificially inflating the number of customers (boosting the utilisation value) to get your chef to cook faster.
The beauty of Schedtune boosting over cpu-boost is that you don't need to fix a frequency to boost to. Instead, the Schedutil governor will give certain tasks a little bit more oomph. If the original unboosted frequency for scrolling is 600 MHz, Schedutil may boost it a little bit more to 750 MHz, for example. If the unboosted frequency for scrolling in calendar is 1000 MHz, perhaps Schedutil may boost it to 1300 MHz. It all depends on the boost value you want to set.
Give Schedtune boosting a go
Analogies aside, you can adjust the boost value in /dev/stune/{top-app, foreground, background, system-background}/schedtune.boost. Usually we mostly care about boosting top-app. Schedtune boost basically boosts the utilisation value by a certain factor. For example, if you set a boost value of 10, the utilisation (not the frequency) is boosted by 10%. A larger utilisation value will cause Schedutil to select a higher frequency.
Try setting the value in /dev/stune/top-app/schedtune.boost to a value between 10-20. Turn off cpu-boost. Enable GPU profile rendering and watch the magic. If your results are like mine, you'll see very low bars which means that it's really smooth. Launch CPU Float app and observe the frequencies. You might notice that they run at a very low frequency compared to the default cpu-boost value, yet it is even smoother. Why is Schedtune boosting producing smoother experience at a lower frequency? I have no freaking clue :S.
Now what is Dynamic Schedtune Boosting?
The issue with setting schedtune boosting (in /dev/stune/*) is that it boosts 24/7 and could drain a bit more battery. There are some situations when you may not want to boost, such as watching YouTube (Top-app task). Boosting is beneficial for mostly touch activity, such as scrolling or typing. The solution I implemented was extending the cpu-boost feature to apply schedtune boost only during touch activities. Other than touch events, schedtune boost won't run 24/7 and drain excess battery.
Getting started with Dynamic Stune Boost
To get started do the following:
1. Enable cpu-boost
2. Set all cpu-boost frequencies to zero
3. Set the boost duration to 1500ms (you can vary it depending on your needs)
4. Edit the boost value in /sys/module/cpu_boost/parameters/dynamic_stune_boost to between 10-20. Feel free to adjust this value. Make sure to set /dev/stune/top-app/schedtune.boost to 0, otherwise it may overwrite dynamic schedtune boost.
5. Turn on GPU Profile Rendering to analyse smoothness of frames.
6. Enjoy and report back your findings in terms of your tunable values, smoothness and battery drain.
tldr; If your brain hurts, just follow the instructions in "Getting started with Dynamic Stune Boost"
Now you may see that I don´t use the dynamic schedtune boost by default. That is because most tasks got assigned to the little cores when activating it and it actually performs worse. This will get solved in some time and I may update the guide then again.
But for now it is not recommended to turn on the dynamic stune boost.
Current setting are
dev/stune/schedtune.boost is at 5
dev/stune/top/app/schedtune.boost is at 15.
input boost is enabled for the little cluster (core 0) at 1171.200mhz for 1500 ms
If you want to experiment with different schedtune.boosts for global, background, foreground and top-app and found good values please share them with us here in the thread
A workaround for you experiment guys that want to enable the dynamic schedtune boost is:
1. Set /dev/stune/top-app/schedtune.boost to 5-10
2. Set dynamic stune boost to 10-20 (I like 20)
The issue with dynamic stune boost is that it only (at the moment) boosts the frequencies of the cluster that a top-app task resides in. So why were there still performance issues? That's because top-app tasks preferred to stay on Little cores, which is likely overcrowded already. That means that the top-app task have to compete with the other tasks on the same overcrowded core for computing power. Imagine it like having a huge pizza (high frequency), but so many people have to share it such that you only get a tiny piece. This is why a task can run on the less-crowded Big cluster at a much lower frequency but still perform better than running on a crowded Little cluster with high frequency.
Now, setting the /dev/stune/top-app/schedtune.boost to 5 does two things. Firstly, it increases the perceived load of the individual top-app task, consequently biasing Schedutil to select a higher frequency (not by much). Secondly and most importantly, since the perceived load is higher (imagine a very hungry person), EAS decides that it needs to be shifted to the Big cluster (larger pizza). 5 was chosen because it's around the tipping point to cause the shift. Use 10 if it's not smooth enough.
Dynamic stune boost doesn't influence tasks to be shifted to the Big cluster, which is why top-app tasks tended to stay on Little cluster.
Combining both steps, we can influence top-app tasks to run on Big cluster (step 1), and a larger Dynamic Stune Boost value will cause the frequency to ramp up during touch interactions on the Big cluster where top-app tasks run (step 2). No unnecessary boosting when watching YouTube woohoo!
Tldr; You're in a pizzeria. Regular schedtune boost shifts you to a less crowded table. Dynamic schedtune boost increases the size of your pizza. Your stomach rejoices
Writeups about dynamic schedtune boost v2 from @Mostafa Wael and @joshuous
Dynamic SchedTune Boosting v2
Couple of weeks ago, Joshuous wrote a new feature, namely Dynamic SchedTune Boosting, that’s been incorporated in recent RenderZenith kernel builds, which essentially alters the value of schedtune.boost for the top-app cgroup dynamically on touch events, to conserve battery. But still, the solution was not that flawless, since it didn’t migrate the task to the big cores when essential as Joshuous previously explained. A quick workaround was to increase the value of /dev/stune/top-app/schedtune.boost to 1 (at least) to allow the utilization of the big cores when required. Many of you may be wondering why that was necessary. Well, hopefully I can break it down a bit for you.
Given the task that needs processing, the find_best_target() function – that is responsible for placing the tasks on the suitable cluster – iterates firstly on the big cluster when the SchedTune boost value is greater than 0, whereas the little cluster will be iterated firstly, should the value of SchedTune boost be equal to or less than 0, to save power. What SchedTune boost does is inflating the task and CPU utilisation fed to the scheduler, and therefore impacting the OPP selection and allowing the task to be placed on the big core(s) if needed. What the older version of Dynamic SchedTune Boosting did was rather inflating the value of utilisation going into Schedutil governor, that is then used to determine the frequency step to be selected for the task via a linear formula, which consequently increases the calculated frequency. But since the value of utilisation going into the scheduler is not inflated, the placement of the task on the corresponding core(s) won’t be impacted and therefore, the task won’t be moved to a big core instead. In essence, the older version would only increase the frequency and not impact the tasks placement on the cores. This caused a drastic performance difference compared to what you get when setting the SchedTune Boost value statically.
With the new v2 version, Dynamic SchedTune Boosting will directly change the value of /dev/stune/top-app/schedtune.boost directly, addressing the issue of only inflating the utilisation data going to the schedutil governor, and therefore the tasks should be able to move to the big cluster when demanded as well as increasing the CPU frequency. This will allow us to safely leave the value of /dev/stune/top-app/schedtune.boost at 0 and save some power for low-medium workload scenarios, since the tasks will be moved to the big cluster on touch with no issues.
-TDK
with a little addition from @joshuous
Very well explained Mostafa
And thanks for saving me the time
To add on, don't be alarmed to see /dev/stune/top-app/schedtune.boost having the same value as dynamic_stune_boost when you want to edit it because your touches trigger the boosting. Just write the value you want into the file and save. It will automatically update the default stune boost value when the boosting stops. To confirm it, you can connect your phone to computer and do
adb shell cat /dev/stune/top-app/schedtune.boost
to confirm that it has changed. You gotta wait a second or so before you issue that command.
I would recommend keeping the /dev/stune/top-app/schedtune.boost at 1 or higher if you want lower latency when Dynamic Stune Boost kicks in. Reason being that default stune boost of 1 somewhat ensures that most of the top-app tasks are already on Big cluster so that we don't have to suddenly migrate too many tasks from Little to Big when Dynamic Stune Boost kicks in.
If you don't type much, and watch videos or listen to music mostly, then setting default stune boost to zero may save you more battery
following this link you will also find a goog explanation on how things work with EAS. It is quite simplified but good to get the general idea of it.
https://forum.xda-developers.com/showpost.php?p=74054394&postcount=526
Proper Way to Report a Bug
ramopps: is an oops/panic logger that writes its logs to RAM before the system
crashes. It works by logging oopses and panics in a circular buffer. Ramoops
needs a system with persistent RAM so that the content of that area can
survive after a restart.
logcat: the logoutput of the Android system
kernel log: (kmsg / dmesg): the kernel messages
Additionally there's the last_kmsg which is a dump of the kernel log until the last shutdown.
radio log: the log outpur ot your System / BB / RIL communication
4
ramopps: Some Documentation on Ramopps
Normal Logcat:
Code:
adb logcat -v time -d > logcat.log
Radio Logcat:
Code:
adb logcat -b radio -v time -d > logcat_radio.log
Ramoops:
Code:
adb shell su -c cat /sys/fs/pstore/console-ramoops > kmsg.txt
Kernel Log:
Code:
adb shell su -c dmesg > dmesg.log
Last_Kmsg: NOTE:
New location of last_kmsg on Android 6.0 and above: /sys/fs/pstore/console-ramoops
Code:
adb shell su -c "cat /proc/last_kmsg" > last_kmsg.log
NOTES:
-v time will include timestamps in the logcats
-d will export the complete log.
If you want to save a continuous log you can remove the -d parameter - then you need to cancel the logging process via CTRL+C.
To export a continuous kernel log use adb shell su -c "cat /proc/kmsg" > dmesg.log (and cancel it via CTRL+C again).
PS: This Document was taked from another XDA Thread Called: [Reference] How to get useful logs
URL: http://forum.xda-developers.com/showthread.php?t=2185929
Also check this one out: [Tutorial] How To Logcat
I only Revived it a bit for ramopps.
I will update this more at a later time..
[DMESG Help Commands]
Code:
Usage:
dmesg [options]
Display or control the kernel ring buffer.
Options:
-C, --clear clear the kernel ring buffer
-c, --read-clear read and clear all messages
-D, --console-off disable printing messages to console
-E, --console-on enable printing messages to console
-F, --file <file> use the file instead of the kernel log buffer
-f, --facility <list> restrict output to defined facilities
-H, --human human readable output
-k, --kernel display kernel messages
-L, --color[=<when>] colorize messages (auto, always or never)
colors are enabled by default
-l, --level <list> restrict output to defined levels
-n, --console-level <level> set level of messages printed to console
-P, --nopager do not pipe output into a pager
-r, --raw print the raw message buffer
-S, --syslog force to use syslog(2) rather than /dev/kmsg
-s, --buffer-size <size> buffer size to query the kernel ring buffer
-u, --userspace display userspace messages
-w, --follow wait for new messages
-x, --decode decode facility and level to readable string
-d, --show-delta show time delta between printed messages
-e, --reltime show local time and time delta in readable format
-T, --ctime show human readable timestamp (may be inaccurate!)
-t, --notime don't print messages timestamp
--time-format <format> show time stamp using format:
[delta|reltime|ctime|notime|iso]
Suspending/resume will make ctime and iso timestamps inaccurate.
-h, --help display this help and exit
-V, --version output version information and exit
Supported log facilities:
kern - kernel messages
user - random user-level messages
mail - mail system
daemon - system daemons
auth - security/authorization messages
syslog - messages generated internally by syslogd
lpr - line printer subsystem
news - network news subsystem
Supported log levels (priorities):
emerg - system is unusable
alert - action must be taken immediately
crit - critical conditions
err - error conditions
warn - warning conditions
notice - normal but significant condition
info - informational
debug - debug-level messages
[LOGCAT Help Commands]
Code:
Usage: logcat [options] [filterspecs]
options include:
-s Set default filter to silent.
Like specifying filterspec '*:S'
-f <filename> Log to file. Default is stdout
-r <kbytes> Rotate log every kbytes. Requires -f
-n <count> Sets max number of rotated logs to <count>, default 4
-v <format> Sets the log print format, where <format> is:
brief color long printable process raw tag thread
threadtime time usec
-D print dividers between each log buffer
-c clear (flush) the entire log and exit
-d dump the log and then exit (don't block)
-t <count> print only the most recent <count> lines (implies -d)
-t '<time>' print most recent lines since specified time (implies -d)
-T <count> print only the most recent <count> lines (does not imply -d)
-T '<time>' print most recent lines since specified time (not imply -d)
count is pure numerical, time is 'MM-DD hh:mm:ss.mmm'
-g get the size of the log's ring buffer and exit
-L dump logs from prior to last reboot
-b <buffer> Request alternate ring buffer, 'main', 'system', 'radio',
'events', 'crash' or 'all'. Multiple -b parameters are
allowed and results are interleaved. The default is
-b main -b system -b crash.
-B output the log in binary.
-S output statistics.
-G <size> set size of log ring buffer, may suffix with K or M.
-p print prune white and ~black list. Service is specified as
UID, UID/PID or /PID. Weighed for quicker pruning if prefix
with ~, otherwise weighed for longevity if unadorned. All
other pruning activity is oldest first. Special case ~!
represents an automatic quicker pruning for the noisiest
UID as determined by the current statistics.
-P '<list> ...' set prune white and ~black list, using same format as
printed above. Must be quoted.
filterspecs are a series of
<tag>[:priority]
where <tag> is a log component tag (or * for all) and priority is:
V Verbose (default for <tag>)
D Debug (default for '*')
I Info
W Warn
E Error
F Fatal
S Silent (suppress all output)
'*' by itself means '*:D' and <tag> by itself means <tag>:V.
If no '*' filterspec or -s on command line, all filter defaults to '*:V'.
eg: '*:S <tag>' prints only <tag>, '<tag>:S' suppresses all <tag> log messages.
If not specified on the command line, filterspec is set from ANDROID_LOG_TAGS.
If not specified with -v on command line, format is set from ANDROID_PRINTF_LOG
or defaults to "threadtime"
[/QUOTE]
That's great achievement, congrats and thanks for bringing eas to the u11!
congrats!
Also @damanrico this might interest you. For me every lag the u11 with the stock hmp implementation had is eliminated with EAS.
To everyone.
Just set input boost to 1,401ghz for the small cluster in ex kernel manager.
duration to 1500ms
And
dev/stune/top-app/schedtune.boost to 20
Edit:
dev/stune/schedtune.boost to 5
Please experiment with this settings. I want this completely smooth.
Make sure to use schedutil governor!
Freak07 said:
Also @damanrico this might interest you. For me every lag the u11 with the stock hmp implementation had is eliminated with EAS.
To everyone.
Just set input boost to 1,401ghz for the small cluster in ex kernel manager.
duration to 1500ms
And
dev/stune/top-app/schedtune.boost to 20
dev/stune/schedtune.boost to 5
Please experiment with this settings. I want this completely smooth.
Make sure to use schedutil governor!
Click to expand...
Click to collapse
For me it is smooth as baby a$$ in this short time I am using it ..
I'd like to try this...any chance for a Magisk-compatible version? I don't ever write directly to system anymore...
Flashed it and my wifi won`t turn on at all.
grega_slo said:
Flashed it and my wifi won`t turn in at all.
Click to expand...
Click to collapse
Are you on magisk?
Nope.
Latest Viper coming from elemetalx kernel.
grega_slo said:
Flashed it and my wifi won`t turn on at all.
Click to expand...
Click to collapse
Freak07 said:
Are you on magisk?
Click to expand...
Click to collapse
Same here, wifi not turning on. I'm on US Unlocked 1.16 firmware running magisk version of Viper rom 1.5
I'll see if I can grab log files later today, but I'm at work now.
grega_slo said:
Nope.
Latest Viper coming from elemetalx kernel.
Click to expand...
Click to collapse
Can you extract the file qca_cld3_wlan.ko out of the directory /system/lib/modules/qca_cld3 from my Zip
And push it to /system/lib/modules/qca_cld3
overwrite the existing module, set permissions to 644 rw-r--r-- and reboot?
And see if that fixes it?
What version of the phone do you have?
jsaxon2 said:
Same here, wifi not turning on. I'm on US Unlocked 1.16 firmware running magisk version of Viper rom 1.5
I'll see if I can grab log files later today, but I'm at work now.
Click to expand...
Click to collapse
Would you also try this?
Can you extract the file qca_cld3_wlan.ko out of the directory /system/lib/modules/qca_cld3 from my Zip
And push it to /system/lib/modules/qca_cld3
overwrite the existing module, set permissions to 644 rw-r--r-- and reboot?
And see if that fixes it?
What version of the phone do you have?
Freak07 said:
Would you also try this?
Can you extract the file qca_cld3_wlan.ko out of the directory /system/lib/modules/qca_cld3 from my Zip
And push it to /system/lib/modules/qca_cld3
overwrite the existing module, set permissions to 644 rw-r--r-- and reboot?
And see if that fixes it?
What version of the phone do you have?
Click to expand...
Click to collapse
just did that and it worked
Edit: European dual sim
velimirchek said:
just did that and it worked
Click to expand...
Click to collapse
Yup +1
Thank you both. Did a silly mistake. Will upload new zip soon. The wlan module didn’t get flashed.
Freak07 said:
Thank you both. Did a silly mistake. Will upload new zip soon. The wlan module didn’t get flashed.
Click to expand...
Click to collapse
FYI I made a Magisk version of the zip that doesn't flash anything to system and a separate Magisk support module, and it seems to be working okay (I have working Wi-Fi, if that's any indication). Is there any way for me to know for sure that everything is working as it should?
Related
Welcome to the Perseus kernel! I thought it would be a nice catchname considering the Galaxy/Universe/Pegasus themes.
I'm trying to be more cutting-edge in terms of development in this kernel. In contrast to other kernels and philosophies of other developers, I don't believe giving the users more choice is a very smart thing to do. As such you won't find a dozen different governors or twenty different settings for this kernel. There is a optimal, or at least, most optimal setting on which the devices operate both in terms of performance and power management. For the average user this kernel will brings lots of benefits to battery life, screen improvement, fluidity and sound enhancements without having to set up any of the configurations.
The kernel comes with a configuration application called STweaks, and is installed automatically with the kernel. You will find all advanced options in there.
Don't be scared by the alpha denomination of the kernel, I'm just taking the traditional naming scheme where alpha designates feature development, beta is feature-completeness, and final will actually be when I'll actively stop developing the kernel. The kernel is very stable, and any bugs are fixed in hotfix versions (alpha x.y)
The kernel is also being maintained and released cross-device for the I9305 (S3 LTE), N7100 (Note 2) and N7105 (Note 2 LTE) and shares the same base-source.
Features / changelist:
Perseus alpha36.3 (26/04):
Fixed slice lookup issue on ABB: It's recommended you put your slices back to default before flashing if you changed them to borderline stability values. Please upgrade.
Perseus alpha36 (22/04):
Adaptive Body Bias control (ABB). (Experimental feature)
Body biasing is taking advantage of transistor body effect for binning the chip depending on its quality. In fact, this is used on the latest Samsung SoCs both for reducing power consumption and validating bad chips by adjusting their electrical characteristics.
The body bias is dictated by the voltage applied to the transistor gate (The usual voltages you're all used to) minus the voltage applied to the transistor body. The resulting bias can change the transistor's electrical characteristics in two possible ways:
Before reading on: A transistor's voltage and operating frequency is defined/limited mostly on its threshold voltage. Wikipedia has a neat visual representation of this; voltage must raise to a certain point for the transistor to be able to switch and operate. This threshold voltage can be highly dependant on temperature, influenced by the body effect, and defined by the manufacturing process. What we're doing nowdays with undervolting is to get as near as possible to the upper bound of this threshold voltage.
With that in mind:
Forward Body Bias
A FBB is defined when the bias of the gate voltage minus body voltage is positive, meaning the gate voltage is higher than the body voltage. This has the effect of reducing the threshold voltage. By reducing it, you can achieve lower voltages, or be able to clock the transistor higher. However the side-effect of lowering the threshold voltage is that you are sacrificing power leakage, meaning that the lower the threshold voltage becomes, the higher leakage current in the transistor becomes. This leakage power rises exponentially with a linear lowering of the threshold voltage. This is what is called static transistor leakage.
Reverse Body Bias
A RBB is defined when the bias of gate voltage minus body voltage is negative, meaning the gate voltage is lower than the body voltage. it has the direct opposite effect of FBB, it raises the threshold voltage thus you would need a higher gate voltage for switching, but however you also dramatically decrease static leakage.
What happens is that you want to use RBB when idling, and a reduced RBB, or even FBB at very high clocks.
Samsung currently uses this on top of voltage scaling to bin their chips. Here's an excerpt of the stock body biasing on the 4412 Prime chip (I'm using that one as an example as it has better adjusted ABB values over the Rev 1.1 chips).
{
"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"
}
To find out your ASV group: You can read out your ASV group in /sys/devices/system/abb/abb_info now.
I have rewritten the ABB scaling logic/driver for CPU, GPU, MIF and INT voltages.
In the current implementation, since it would be insane to have paired-up gate-body voltages divides the frequency range in several slices; even Samsung uses only three voltage ranges on the DVFS scale. I divided the frequency ranges as follows:
CPU: Divided into four slices, with frequency ranges of 200], 800], 1600] and ]1600 Mhz.
GPU: Three slices: 160], 533] and ]533 Mhz.
MIF and INT: Both only two slices with the bottom frequencies for each as middle-threshold.
As mentioned above, controls can be found in /sys/devices/system/abb/ and the entries are self-explanatory. You can also change the frequency slice limits per sysfs, however in STweaks I only included the voltages for each slice only for now.
Disclaimer
{ And that's about it in that regard. I have tried testing things over last couple of weeks, but I haven't come to a solid conclusion yet beyond what's presented by the stock characteristics: It's up to you people to do some advanced testing on the matter. My limited empirical testing in terms of voltages tells me it works as intended, but if a user with advanced measuring equipment would do similar testing to what I did back on the 4210 it would be perfect. }
zRAM: Switched over from LZO to Snappy compression algorithm, this provides much faster compression and decompression than the LZO implementation which was in the current kernel. I updated the Snappy libraries to the latest original CSNAPPY implementation, so this is extremely new.
Some kernel internal updates to speed up hotplugging and improve I/O latencies.
A correctly (Unlike basically every other kernel out there till now) applied load averaging patch regarding fixing a Moiré pattern in the scheduler load calculations which was floating around.
Fixed mono and equalizer switches in the sound engine. (Thanks to sorgelig for beating me to it)
Fixed led controls to behave correctly with user-space apps.
mDNIe digital brightness reduction:
You can now lower the brightness to basically nothing via this: it uses the mDNIe engine to digitally remove luminance from the RGB channel values, as opposed to reducing brightness via a proper backlight/display driver. The side effect of this is that you lose colour resolution somewhat, but is a practical and working method to reduce the too bright minimum values of our displays.
You have three configurables:
A reduction rate which you want to apply, this is the intensity of the darkening you want to achieve.
The take-over point; the backlight driver gets fed brightness values from 0-255 (In reality values below 20 have no effect). The take-over point is the point where the digital brightness reduction starts, on a reverse scale. The reduction is applied linearly from 0, (Full reduction taking place), to the take-over point (Zero reduction). The stock slider doesn't go below 20 in the interface, so practically the full reduction rate is never applied unless you use a third-party brightness controller app, just to keep that in mind, but in practice it doesn't matter.
Auto-brightness input-delta: This is needed because the stock framework is retarded in the values it forwards to the kernel, you can adjust this to avoid having brightness reduction when you don't want it on auto-brightness.
Somebody needs to edit config_autoBrightnessLevels, config_autoBrightnessLcdBacklightValues in framework-res.apk\res\values\arrays.xml to fix this.
Optionally, if you use a third-party app like Custom Auto Brightness which allows backlight values of down to 0, you can avoid this problem.
The register hook needs to be enabled to be able to use this function.
Increased the maximum brightness by 50 candela: the manual controls were limited to 250cd as maximum as opposed to 300cd which was only usable during auto-brightness, and unusable for any third-party apps.
Unaligned memory access throughout the kernel when applicable.
Switched over to GCC 4.7.3 Linaro toolchain for compiling.
Perseus alpha35 (06/04):
Further rewrote the in-kernel audio controls:
Threw out the old detection methods for something more robust.
This particularly enables non-cellular applications such as Skype, Viber, and so on to be detected correctly. A "calling" state now includes any and all use-cases where the audio is outputted via the phone's earpiece. This fixes microphone levels for such apps to correctly use the calling sensitivity value.
Added microphone level for camera use, this state is enabled whenever a camera stream is active. It should give more options into adjusting things to your likings.
By now the sound engine has only little similarities to Boeffla, any bugs and feedback now go directly to me.
Developers only: MHS: Added a new small tool for tracking media use and reporting it to other in-kernel drivers. Capable of detecting video recording, decoding and camera streams for now. See commit for more info.
mDNIe control changes:
Removed several controls in STweaks simply because people misunderstood them or misused them, or they simply had no rational use.
Video detection, now with the help of MHS, is no longer limited to the stock video player. Any video players using hardware decoding will now be able to make use of edge enhancement, HDR and DNR, this includes any web-based players and the YouTube app.
Custom LED controls implemented; Exposed most variable controls for the notification LED via sysfs and STweaks (LED tab). :
Control LED brightness. Currently the OS dictates, depending on brightness detected by the light-sensor, wether to run the LED in a low-power mode or in a high-power mode, you can now set brightness for both.
Blinking control, this is basically the shape of the wave-pattern that the LED blinks in, you have several controls, best described the data-sheet description:
The fade-in time period is TT1 in the graph, while the fade-out period is TT2.
Slope (1/2/3/4) detention time represents DT1,2,3,4 in the graph, it controls how "steep" the four different curves are.
The LED fading checkbox simply switches between having the detention times controlled by the sliders to having them to 0 (Stock blinking behaviour).
Increased default zRAM size to 400mB. This won't override your STweaks setting, so only new users will see the new value. Others should please adjust the value manually to your liking.
Sources:
https://github.com/AndreiLux/Perseus-S3
Credit and thanks:
gokhanmoral, netarchy, and anybody credited in the commits.
TL;DR: before flashing aside from known issues in the second post.
This isn't an AOSP kernel. I won't work with CM and AOSP derivatives.
DOESN'T WORK ON SAMSUNG JELLYBEAN 4.2.1 ROMS.
Known issues [Updated 02/12]
None
Older changelogs
Perseus alpha34 (22/03):
Updated sound engine. Based on Boeffla (Andip71)sound but custom fork with rewritten system interface and some other code re-factorings.
Should fix all FM Radio issues.
Brings us saturation prevention for the equalizer.
Privacy mode.
Microphone level control
You now have control over the speaker equalizer via sysfs, please visit /sys/class/misc/wolfson-control/ the controls are self-explanatory.
I removed the equalizer pre-sets from STweaks, if you want, set them manually:
Bass-extreme: 12 8 3 -1 1
Bass and Treble: 10 7 0 2 5
Treble: -5 1 0 4 3
Classic: 0 0 0 -3 -5
Pleasant for ears: 4 3 2 3 1
Eargasm: 12 8 4 2 3
I recommend HeadphoneAmpControl (thread - Play Store) for controlling the volume directly on a hardware level; it will overwrite the digital volume of the OS and use the hardware amplifiers only.
Enabled ZRam by default with disk size of 200mB and swappiness of 90%.
The ZRam control is found in the I/O Tab in STweaks. Set it to 0 to turn it off completely, any other value to turn swap on. Changing value takes about ~10-20 seconds depending how loaded the disk is with swap pages so don't piss your pants if it doesn't react immediately.
Applied a requested patch which allows PCs to be booted off from the phone storage.
Perseus alpha33.2 (27/02):
Master profile is correctly calibrated.
Detailed calibration report: Download
Advanced colour management report: Download
All thanks goes to Slimer777 for his excellent work.
Perseus alpha33 (26/02):
Revamped and hopefully final version of mDNIe controls:
The controls work now on two levels: First we have a master sequence that overrides any and all of Samsung's settings; currently this version is released without calibration, however in the next minor version it will be updated with proper professional screen calibration. See the Note 2 thread to see what to expect here too. The master sequence is calibrated to sRGB norms on a precision level equalling and even surpassing the iPad3/4.
The master sequence works as as the calibrated base; for people not wanting to bother further with any more controls, you simply enable this and you're done.
Second part is the register hook, it catches effect values and modifies them by applying delta values available as controls in STweaks and in /sys/class/misc/mdnie/hook_control/.
Leaving both these options will give you Samsung's default values, plus the black crush fix.
The register hook, while used on Samsung's profiles, is not capable to alter effects which are not integrated in that screen profile's value sequence, the "Movie" profile for example lacks some effects present in the "Dynamic" profile. The same is valid when having different scenarios, the "Camera" scenario will use different effects in its base than the "UI" scenario. To fully explore all possible effects, use the Master profile as it integrates all effect values known.
Each control has a master kill-switch which enables or disables the effect. This varies by profile and scenario, so you have control to only "toggle" the switch, whatever its state may be in.
Digital noise reduction - Reduces and flattens out grain. Advanced controls are found in the hook_control folder with the dnr_ prefix.
High dynamic range - A HDR effect which brings out details in dark and extremely bright scenes.
Digital edge enhancement - An edge enhancement effect. What we previously called "sharpening". Divided in controls for radius, amount and threshold. Read the Wikipedia page for more information. More advanced controls found in the sysfs under the de_ prefix.
For the above three effects, scenario consideration is taken into account. You can enable/disable them depending when you want it to be applied. Please be aware only the stock applications trigger the scenarios. I will try to enable at least the video scenario depending on when the hardware decoder is active in the future so that they are enabled also in third-party video players.
Chroma saturation control - Same as in previous version but with fixed labels.
Colour temperature control - By default this is disabled on all profiles, however, if your screen has a tint to it, this is the first control you should try to fix as it alters temperature on all channels.
The SCR controls are colour channel filters working on the Red, Green, Blue, Yellow, Cyan, Magenta, White, and Black channels.
Imagine the controls as manipulating the corners of the RGB cube:
(Credit to Wikipedia for the graphic)
By controlling the RGB coordinates of each corner/channel we can mould the cube into a different shape. At the same time the cube is projected onto a hexagon; the perimeter of the hexagon represents the colour hue, the radius of the hexagon from the middle represents chroma. We can use the chroma saturation controls to "push in" each corner of the cube, while moulding the corner's directions with the RGB controls. The RGB coordinates can be transformed into the HSL space space if needed, however I didn't include this function yet as I don't feel the need for it.
STweaks has controls for the RGBYCMW channels, the K (Black) channel I left out because it makes no sense in altering it, but can be found in the sysfs folder.
Several controls have a "factory setting" switch, this are the burned in-hardware values for some controls, they overwrite the controls themselves.
Additionally to the controls exposed to STweaks, there are several other effects and modifiers exposed in the sysfs interfaces. This also includes the gamma curve controls for levels 0-255 in steps of 16.
There are also some additional unidentified configurables which I wasn't able to properly give a name to or had no effects: Dithering, ABC (Seems to give a gamma brightness boost), SCC, UC, and MCM (Colour temperature) configurables whose exact effect isn't documented.
Perseus alpha32 (29/01):
Charging control implemented. This is my own version.
Charging currents:
Charging currents are dictated by input and charging current limits. The input current is the current flowing into the device through the USB port at 5V. The charging current is the current delivered to the battery at usually 4.35V. The device can have a higher charging current than input current because of the voltage differential, usually a 15% discrepancy. You can also have much higher input currents than charging currents, this can be useful when you are using the device in situations like gaming and charging your battery at the same time, provided your charger actually can provide the power.
There are 3 USB charger type categories: DCP / Dedicated Charging Ports which also includes AC chargers, but also special USB plugs; SDP / Standard Downstream Ports which usually includes almost all data enabled USB ports, and CDP / Charging Downstream Ports which includes also data enabled USB ports but which are designed to provide more power, usually on newer laptops where the USB port has a lightning logo next to it. More info here. - Technical explanation here.
Charging logic:
Stable margin removal option. The charger chip is capable of detecting unstable charging sources; it dynamically reduces the input current in 100mA steps until it detects a stable voltage input [We don't have the charger chip datasheet, so the technical explanation is a bit blurry here on how it decides that it's unstable]. It further reduces it by 100mA as a safety margin, you can disable this now.
Complete disabling of unstable power detection. This simply ignores unstable power sources and leaves the input current limit at its set up value. This will fix charging problems people have been reporting. However, please use it at your own risk, the S3 chargers which have had these symptoms clearly have some issue in their hardware so you might actually kill them with this option enabled as there is no protection from the phone's side anymore.
The actual input current limit can be read out in /sys/devices/platform/samsung-battery/power_supply/battery/current_max, so you can see the real limit there, it's the closest thing we have to the actual charging current on stock values since there is no hardware to read out the live currents.
Voltage control:
Hard voltage control: 4.20, 4.35V, and 4.40V charging voltages are available. This is included for anybody running on third-party batteries, whom most of them have a 3.7V battery chemistry as opposed to the 3.8V on the stock battery. These batteries should be charged at 4.2V instead of 4.35V.
Soft voltage control: As opposed to the hard voltage control which is the voltage which the charger chip provides to the battery while charging, the soft-voltage is the battery voltage itself. 3.7V batteries have a top-off voltage of 4.2V and 3.8V again 4.35V. The default limit on the stock battery is 4.30V before the charger logic stops and considers the battery as full. This is also merely provided for 3rd party batteries which should be charged at lower voltages. If you overcharge your battery beyond these what are safe considered voltages, such as raising the default 4.30 top-off voltage to the design 4.35V or even higher, you are running into the risk of damaging the battery or even causing it to melt-down. Use at your own discretion.
mDNIe sharpness and RGB/YCM chroma saturation control in STweaks:
I started implementing sharpness control in STweaks and went a bit over-board instead of a simple checkbox; You now have controls over the mDNIe registers as a delta offset value compared to the stock register values. I'm applying the offset to all mDNIe profiles and scenarios which have the specific post-processing effect active in that specific scenario. Meaning, that you start with the default profile; Dynamic / Standard / Natural / Movie and have the delta offset applied on top of that.
Sharpness delta. This is what brought most of the quality difference in hardcore's original tweaks. You can now fine-tune it to your own taste, and also take into regard that it produces a different effect for each screen profile while having the same delta - the base values between the profiles are different.
DE control - I don't know what this actually does and I couldn't discern much difference between the values, but it used to be disabled in hardcore's tweaks.
Chroma saturation control: This is composed of 2 values for each RGB/YCM channel. See the Munsell color system for a visual representation of the values controlled here. The chroma curve control describes the curve weight based on chroma intensity, the chroma gain is the chromatic gain that is being applied on the respective channel. Chromatic saturation weight is again another multiplier for all channels combined. I have not managed to properly identify the chroma grey threshold and its effects.
Basically this is like an RGB control on steroids, and enables you to tune your screen to your own liking and calibrate it as you wish. Please note that not all scenarios in the profiles have chroma saturation effects, the Movie profile for example has no effect applied to the UI so chromatic control has no effect on it.
I also want to state that the above are my deductions and theories on the descriptions of these controls, I'm not familiar enough on colour theory to be able to confidently say that these descriptions are correct, and the controls are a work-in-progress for now. Experts are welcome to contribute here.
Front buffer early suspend delay option for those who have issues with the CRT animation.
Did some refactoring on the Mali drivers and fixed a bug which may have caused less capable undervolting than the stock implementation.
Perseus alpha31 (09/01):
Removed my own security fixes and replaced them with the official Samsung one. I guess it can now be disclosed: exynos-mem was only one of multiple entry-points for the memory exploit. We discovered the s5p-smem exploit ourselves back in December but kept it quiet, I fixed that one back in version 29.2 without mentioning. Nobody was secure from a smart exploiter up until then, SuperCurios or Chainfire's software fixes are also just patching a single hole in what is a Swiss cheese. Kernels >v31 and beyond stock LLA are now the only truly protected ones.
Samsung's fix for the sudden death syndrome (SDS) included. It is caused by eMMC failure on phones with VTU00M internal memory chips with revision 0xF1. You can check your phone with the "eMMC Brickbug Check" in the Play Store (Ignore the message if it says you're not affected, the type and revision is what matters). The patch is a firmware soft-patch that is applied on every boot and MMC resume, it is not a permanent fix. You will need to stay forever on kernels which include the patch, this also includes updated recoveries and their embedded kernels.
Some other minor MMC changes extracted from Update 7 sources.
Harmonized some mif/int max voltages with the Note 2 limits.
Perseus alpha30 (06/01):
Internal and memory voltage control. This is the first and only working implementation out there. Memory interface voltage is exactly what it the name implies, the voltage on the chip-to-chip interface from the SoC to the memory chip. Internal voltage is the whole SoC voltage excluding CPU, GPU, and the MIF. This includes all auxiliary function blocks such as the ISP/Image signal processor, camera interfaces, I/O interfaces, display controller and the MFC/Multi function codec hardware video de-/en-coder.
Internal voltage respectively memory voltage table is found in /sys/devices/cpu/busfreq/ as int_volt_table or mif_volt_table
The frequencies are defined as OPP's (Operating performance points), internal frequency and memory frequency (And voltages) together as a pair form an OPP. If you want to change the voltages through the sysfs files, keep in mind how you change them. MIF voltages are stored independently with each OPP step. INT voltages are stored in respect of their frequency key.
Default OPP steps are: 400200, 267200, 267160, 160160, 133133, 100100. The first three numbers represent the memory frequency, the other three the internal base frequency. For example 267200 means the memory interface is at 267MHz (533MHz DDR) and the internal frequency is 200MHz.
The voltages in STweaks are sorted out through some magic and are frequency unique, I recommend using that for controlling them.
Busfreq logic control added into STweaks, this includes all the already available configurables in the stock kernel with added explanations and I supplemented it with a sampling rate parameter.
Some minor source updates from Samsung regarding some new sensor drivers.
Replaced pegasusq's runqueue detection logic with a new more superiror and precise in-scheduler collection logic, I found that the real runqueues are much less than what was previously reported. This should help a lot with hotplugging.
Enabled AFTR by default since we are now running very often in single-core mode. Keep in mind this mode is WFI Idle + LPA + AFTR.
Fixed a kernel bug which was eating up randomness entropy. This is related to that whole seeder business - please don't use any of those fixes. I also disabled virtual addresss randomization and at the same time disabled entropy generation from the block layer, which should avoid I/O overheads.
Perseus alpha29.2 (24/12):
Another minor (major) release due to security. Please update.
I screwed up something touchscreen related in v29 that disabled Flexrate requests, fixed now.
Changed Flexrate requests so that they don't scale down in their sub-samples anymore. This should improve fluidity.
Perseus alpha29 (18/12):
I'm doing a quick release because of the security fix, not very feature rich.
Fixes the exynos-mem security hole. This is my own fix and will not break camera. Read about it here. You don't need to use Chainfire's or Supercurio's fixes, in fact, you shouldn't use them because of the camera.
Updated Wifi drivers.
Added GPU utilization control to sysfs and STweaks.
Changed default GPU thresholds to more relaxed values (75/17)
Added block device read-ahead control to STweaks. Additionally set the default read-ahead for internal memory to 256kB and 1mB for SD cards.
29.1: - Reverted the Wifi drivers back and did some CMA adjustments to see if that fixes some random reboots of people.
Perseus alpha28 (13/12):
28.1: I reverted the striked out changes due to exFat. I changed my mind due to demand. I apologize for the chaos.
On your SD card showing up as damaged: it is not.
I made a decision in terms of exFat compatibility; either I advance the kernel with newer upstream Linux versions or stay back and keep compatibility with the exFat modules. While I have nothing against proprietary modules or such, not being able to adapt them to the kernel is not optimal. You can format your cards to FAT32 or ext4 without much issue. Please back up your data and format your card accordingly before flashing v28.
[*]Updated the block system to Linux kernel 3.3.
Introduced FIOPSv2, ROWv4, ZEN, BFQv5 as new I/O schedulers;
FIOPS is the new default scheduler, it's a CFQ like fairness scheduler optimized for solid state storage. ROW should be the actual better performer here as it has superior logic, but I didn't set it as default because of some lags when installing applications. ZEN is just a mix of SIO and Deadline and nothing special. BFQ seems to underperform. I recommend the first two over everything else, and added the latter two just for comparison's sake.
Added dynamic Fsync control (Faux123). It disables Fsync only when the screen is on. Enabled by default (Fsync off).
Changed some logic on when the adaptive scaling voltages are applied in the kernel init sequence. This fixes GPU voltages not being applied at boot and also fixes the wrong default voltages being displayed in STweaks.
STweaks tab for I/O with scheduler selection for each device block and also dynamic Fsync.
New script side feature in the uci.sh framework: When inserting an override.profile file into the profile folder (/data/.perseus), the entries in the override profile will supersede the ones in your default profile. You can use to make CWM zips to turn off set at boot flags or to share targeted settings with others. The override is applied once at boot after which the profile deletes itself.
Perseus alpha27 (02/12):
Sources updated with various updates from N8000u1 base. Included are following important changes;
CMA memory allocation has been altered and page handling in the kernel in regard to CMA affected pages has been dramatically improved, this should fix the high load of the "migration" process users have had since initial Jellybean kernels.
Updated wireless drivers.
Adds a delay to SD Card host controller power-down, which I assume is to prevent some corruption. There is a specific change to Toshiba 19nm manufactured SD Cards, these are mostly the latest SanDisk 64GB cards. Together this may fix issues users have had.
Updates the camera interface, Video4Linux and Jpeg2x drivers and this fixes compatibility with 4.1.2 ROMs. Backwards compatibility is retained.
Other updates which are more transparent to the end-user.
New PegasusQ logic:
- We now have additional conditionals on the hotplug logic which checks the total load across all cores and is able to bias towards a specified core count if the load is low. This is useful because previously we could have had frequency spikes and lots of low-load threads triggering a hotplug-up while in reality it wasn't needed. The core count is more biased on keeping 2 cores online in most cases now unless really needed.
- The way freq_step is handled has changed. We now take the remainder of load space above the up threshold and dissect it into three slices each having different frequency increase step sizes. The first two slices are each of up threshold differential size, lop-sided towards the lower end of the load scale. We specify the slice size and freq_step delta in regard to the original freq_step.
- A new fast-down scaling logic; if frequency is beyond a certain threshold, we take a heightened up_threshold value solely on the down scaling logic to scale down more aggressively from the higher frequencies.
STweaks. This is my custom implementation of the kernel side, based on Gokhan Moral's initial implementation.
- CPU overclocking and voltages interface.
- Configurables for all CPU governor settings.
- GPU overclocking and voltage interface.
- Interface for audio enhancements.
Perseus alpha26 (14/11):
Updated MTP drivers back to the newest version. Fixes some inconsistencies which some people had.
Further increased MMC command timeout from Linux default 300ms to 3s in trying to finally squash errors and "unexpectedly removed SD card" after resume.
Ported Gokhan Moral's mDNIe interface and also added colour tone modes on top of the scenarios. System interfaces are found in /sys/class/misc/mdnie . Input syntax is the same as the output syntax, or, single register-value pairs as a single line in the output format, except 0xFF which is a terminator value.
Increased default sampling rate down to 30ms from 50ms for a bit more fluidity.
LTE devices only: Updated some power management functions on the MDM modem from latest sources; this will drastically decrease the amount of wakelocks on mobile data and improve battery life.
26.1
Disabled net_os_rxfilter_add_remove userspace/ROM filter management in the Wifi driver to prevent the operating system of enabling unwanted pass-through multicast and broadcast filters while in standby.
Perseus alpha25 (23/10):
Raised and fixed USB, MISC charging rate to 900mA.
Enabled OTG car dock, smart dock and music dock charging. Alternatively this can be triggered if you short pins 4 and 5 of the USB connector with a 40.2kΩ, 64.9kΩ or 619kΩ resistor.
MTP fixed on OSX devices.
Fixed ROM power savings feature, this was originally broken because of the addition of overclocking, and the same interface that Samsung uses for limiting CPU speed in power savings mode also limits the max frequency to factory defaults. This is now fixed and powersavings mode will throttle to 1000MHz.
Fixed mis-configuration of the default audio settings to improve sound quality, sorry about that.
Ripped out the old GPU scaling mechanisms and scaling logic and replaced it by something new.
The old mechanism was getting overly complicated and was a remnant of the Galaxy S2 where we merely had 2 frequency steps originally; this was fine then, but isn't anymore today. The threshold fuçkery was confusing to a lot of people and people generally misconfigured their settings with inane values.
The new scaling logic follows a more CPU governor-like approach: Scaling up logic is basically the same as before: the GPU will scale up to the next frequency step when the load reaches a certain threshold. Up-scaling takes place step by step. The up-scaling threshold is now global and a single value applies for all frequency steps.
Scaling down in the new logic resembles more like the ondemand method; The scaling down takes place when the load goes under a certain threshold. This threshold is dictated by the up-threshold minus a down-differential. By default they are 90 and 10. Triggering this condition we scale down into a dynamic frequency target capable of accommodating and dictated by the load level. In plain words, we can scale from max frequency immediately down to the lowest one. This will improve power consumption.
Ripped out the old GPU control interfaces and rewrote it with something new to accommodate the new logic. Your old scripts won't work anymore.
We now have 10 frequency steps to the user's disposition; defaults are: 54 108 160 266 350 440 533 640 733 800.
The new system interface targets can be found in /sys/devices/system/gpu/ .
- freq_table outputs a list of the current frequency table. You can use this interface for configuring the frequencies themselves in two ways:
Pair-wise target setting: echo 533 500 > /sys/devices/system/gpu/freq_table will change the 533 step frequency to 500.
Whole-table echo: echo 54 108 160 266 350 440 500 640 733 800 > /sys/devices/system/gpu/freq_table
In the above example you end up with the same end-result over the stock settings.
Valid clock frequencies are as follows: 54, 108, 160, 200, 266, 275, 300, 350, 400, 440, 500, 533, 600, 640, 666, 700, 733, 750, 800.
- volt_table outputs the voltages to the corresponding frequencies.
Pair-wise target setting: echo 533 1025 > /sys/devices/system/gpu/volt_table will change's 533MHz's voltage to 1025mV.
Whole-table echo in the same format as freq_table. Valid voltages are 600mV => x <= 1200mV.
- thresholds sets the two global threshold settings. echo 90 10 > /sys/devices/system/gpu/thresholds . Remember that the first is the up-threshold and the second is the down-differential. The down differential may not be higher than (99 - up value).
- min_freq and max_freq set the limits of the current DVFS policy. By default we're scaling from 160MHz to 440MHz (Same as stock).
echo 533 > /sys/devices/system/gpu/max_freq will enable the top limit to 533MHz and basically overclock the device.
echo 108 > /sys/devices/system/gpu/min_freq in the same way sets the lower limit.
25.3:
- current_freq shows the current frequency. This is if somebody likes to make a monitoring app or something.
- time_in_state shows the time spent in µS on each frequency step. Echo 0 to it (by default disabled) to disable it, 1 to enable monitoring, and any other numerical value to reset the timekeeping back to 0.
Perseus alpha24 (09/10):
Galaxy Note 2 source and kernel merge. Various platform fixes included from patching up from update5.
Fixed Mali GPU interface bugs relating to staycount, and lowered undervolt-soft limit down to 600mV.
5 step GPU scaling, for now. Change your scripts.
Fixed black crush on the display. Vastly better black levels are now of order.
Perseus alpha23 (27/09):
Changed some auxiliary CPU clock dividers for frequencies 1600,1704,1800 MHz. These frequencies should use less power now and also should be more easily reached with more stability or lower voltage depending on your device.
Fixed CPUPower driver (Back from alpha20); this will now skew the reported processing capacity of CPU0 in the lower frequencies up until 500MHz to be 8 times greater than CPU1-3, what it does now is that the scheduler will even more migrate tasks onto CPU0 to avoid idle wakeups on the remaining CPUs, resulting in increased power efficiency. For high load > 500MHz, the driver reverts back to the default power configuraitons.
Reset the regulator configurations to their physical minima; you can now undervolt to 600mV on the GPU. Sorry I missed this before.
New feature: Dynamic Screen Frequency Scaling.
This decreases the display controller frequency in tandem with the CPU speed. Usually when you have low activity on the screen; i.e. low re-draw rates, then you mostly also have logically low CPU load. I wrote a scaling mechanic to switch between high display frequency (60Hz), and low display frequency (40Hz) in accordance to CPU scaling. This is tied in in the CPUFreq governor, in this case PegasusQ. We have three new governor configurables found in /sys/devices/system/cpu/cpufreq/pegasusq/ (Or alternatively just use SetCPU):
lcdfreq_enable: Enables or disables the mechanic, disabled by default.
lcdfreq_kick_in_down_delay: The amount of samples to wait on below the threshold frequency before entering low display frequency mode. Default value is 5 for now, a.k.a. in most cases 250ms unless accelerated flexrate is active on low load (fingers touching the screen), then depending on situation it might get as low as 62.5ms.
lcdfreq_kick_in_freq: The frequency threshold below which the low display frequency kick-in will be active. Default is 500MHz, and should probably stay as such, setting it higher will cause lags as we'd be using 40Hz in an interactive situation.
For the curious: I made a rudimentary time_in_state state accounting sysfs in /sys/devices/platform/samsung-pd.2/s3cfb.0/graphics/fb0/lcdfreq/time_in_state for testing purposes. Currently it shows wrong time values for 60Hz as the driver gets initialized before the high resolution timer, and I'll fix that later, but the 40Hz time statistics are correct.
Notice: There will be now conflicts between this and user-space controlled TwDVFS service/app. The service would limit screen frequency to 40Hz while using the camera app, this will be now overridden. I also thought the service would do more but I could not find it scaling for anything else than the camera, so it's pretty much useless in my mind, and you could theoretically remove it.
Feedback 23.3: This feature causes flickering on bright colours and low brightness. Enable it at your own will.
Changed the functionality to boost to 60Hz on any touch interaction, regardless of CPU speed.
Please provide feedback on fluidity and battery life.
Perseus alpha22 (22/09):
Update to update5 source code. Only compatible with Samsung Jellybean ROMs.
Stacks with my previous memory changes: total memory: 857mB for now.
Implemented timer slack controller.
Backported the scheduler NoHz load computation fixes, this should dramatically improve PegasusQ's hot-plugging decision making.
Further reduced Mali sampling rate down to 50ms and changes the default thresholds to more aggressive power savings and clear-cut scaling. Removed 10ms regulator switching latency. I measured a 10% battery improvement in GLBenchmark 2.1 Egypt Battery - 50% Brightness 60 FPS.
config.gz support.
Alpha21 is the same as above but without update5 and for ICS. This is the last kernel for ICS, I'll not longer support it.
Perseus alpha20 (9/09):
Gökhan Moral's port of Voodoo Sound implemented. Currently no configuration interface is available, so if you wish to play with the settings, refer to the sysfs interfaces in /sys/class/misc/scoobydoo_sound/ . If you wish to change the device name, you must do echo 0 > /sys/class/misc/scoobydoo_sound_control/enable , followed by an echo output to the same file with the target device driver name. You can use this to change the device path to /sys/class/misc/voodoo_sound/ and sub-sequentially make a certain configuration application work. Please do not ask me for support on the latter. You can disable the sound modifications completely by the same method, by of course not re-enabling it afterwards.
Changed the Wifi packet filter to block out all but mDNS multi-cast packets.
Increased mmc timeout for bad quality SD cards.
Perseus alpha19 (1/09):
Updated Samsung source base up to update4, includes changes to the Wifi driver and various other small fixes
Added ARM topology support for the scheduler to be able to use sched_mc levels. This should increase cpu idle power consumption by decreasing idle wake-ups. For the moment disabled by default, and cpu_power doesn't seem to correctly work.
Swap support.
mDNIe sharpening improvement, courtesy of hardcore.
Decreased Mali utilization timeout to 100ms down from 1s which improves reaction time on instant GPU loads (Lock screen is best example).
New valid GPU frequencies : 54, 108, 160, 200, 266, 275, 300, 333, 350, 400, 440, 500, 533, 600, 640, 666, 700 Mhz
Increased user-space memory by 48mB to have a total of 825mB useable RAM; this comes from reduced DMA memory spaces on the part of:
- The Mulfi Function Codec a.k.a. the hardware decoding and encoding unit memory space from 50176kB to 28672kB
- The camera interface imaging subsystem from 12080kB to 10240kB
- The front-camera firmware block-space from 15360kB to 14336kB
- The ION heap size for the Video4Linux driver from 71680kB to 48128kB
In the case of the ION/V4L and MFC heap sizes I determined it by setting a benchmark for all the HD sample videos listed here to not have any detrimental effect before and after the changes. Below 41mB is the size for which the Planet Earth birds scene at 1080p high profile 4.1 40mbps video starts to lag. Keep in mind that there is no way this would be considered normal quality as this is basically un-recoded Blu-Ray quality and most videos are vastly under this bit-rate.
I note that I also haven't found any detriment in use of the cameras including the modded 30mbps camera quality.
Disabled the Kies daemon, I see no point in it and it uses up memory uselessly. Obviously Kies won't work any-more, if you want you can start the service yourselves manually.
Perseus alpha18 (11/07):
Updated Samsung source base up to update3, includes various fixes to fuelgauge battery reporting on full charge, MHL code, video media drivers, Wifi driver updates, gyroscope, MAX77686 battery charger changes, increased max display brightness, a buttload of LCD panel changes, and changes to the pixel refresh rate driver (This thing is controlled by the TwDVFSapp by the way and decreases screen power consumption at runtime).
ro.secure=1 again now but with an insecure adbd as root included.
LFB ramdisk.
Compiled with Linaro 4.6.2 and some higher level optimizations.
Keep in mind that running the new kernel on older ROMs can cause some funny behaviour, so update your ROM if so.
Perseus alpha17 (9/07):
Rewrote flexrate request code for pegasusq: I apologize for releasing the previous version in the state that it was, shame on me.
Now upon receiving a flexrate request and active ones, the governor delays hot-plugging sampling logic so that accelerated sampling is being taken into account and hot-plug sampling is normalized for the standard sampling rate. All sub-samples are being averaged into a normal sized sample at the end of the normalized period. This no longer interferes with the runqueue read-outs as they were being reset too fast and generally accelerated hot-plugging in a bad manner.
Changed touchscreen flexrate requests to 12500µS sampling rates over 4 periods to synchronize with the default pegasusq sampling rate.
I consider this chapter to be done and a success as far implementing flexrates as a viable and working alternative to touch-boost to increase responsiveness without having the bad battery-life side-effects of the touch booster.
Performance governor is now core-aware, previously as no other hot-plugging logic was available, the governor would start with whatever number of online cores were available at that time and stay like that. This made Performance useless for it's designed purpose, that being bringing maximum performance. It now brings up all available cores online upon start and turns all additional cores back offline on governor stop. It is now by far the best and consistent governor for benchmarking.
Removed unused cpu_freq_up, cpu_freq_down, and several other flexrate related governor parameters in Pegasusq as they were either not used, or senseless.
Default Pegasusq parameters changed:
- Sampling-down factor reduced to 1 from 2, this caused reduced sampling speed upon reaching maximum frequency. It now scales (possibly down) faster.
- Frequency steps reduced from 40% to 21% of maximum frequency, this causes it to scale in 300MHz steps for the default maximum policy of 1400MHz. As we now have flexrates to scale faster I did not notice any negative effects on performance and this should help battery-wise on load-"spiky" applications, and in general.
- Increased runqueue-length thresholds for the hot-plugging logic by a flat 75 for all conditions. In my opinion and experience they were too low and caused to keep the cores needlessly online. This now reduces for "average low" use the online-time of the third core considerably.
- Increased the hot-plug frequency conditions for the 4th core.
Updated the kernel from upstream to 3.0.36.
Memcopy and string function improvements, won't bring any noticeable differences.
Compilier optimizations (Roughly the same as Ninphetamine's) are now in. VFP uses the NEON libraries now. I couldn't measure any increase in any synthetic benchmarks with this though.
LFB exFat modules.
Perseus alpha16 (3/07):
Disabled touchscreen touch booster; this previously locked the CPU frequency at 800MHz, memory interface to 400MHz and bus frequency to 200MHz at any time the finger touched the screen.
Implemented flexrate capability into pegasusq; additionally added a frequency threshold above which flexrate requests are ignored. Currently this is set at 800MHz but is configurable in the governor tunables.
Enabled quality of service requests in the touchscreen driver, this currently triggers a flexrate request at a sampling period of 15ms over the governor default of 50ms, and over 5 periods, giving 75ms of heightened reactivity. It also sends a direct memory access throughput quality of service request to the the linux power management quality of service interface to guarantee a 266MHz bus frequency for 142ms. Still need to check if that the last part works correctly.
Perseus alpha14 (21/06):
Only Mali platform changes.
Remove Samsung integrated checks on in the Pegasus platform that prevented the GPU control interfaces to work. Overclocking, undervolting, and the rest now properly work.
Removal of the CPU frequency lock to 1200MHz if the GPU is at 440MHz, this is excessive as 3D load heavy applications usually do not tax the CPU that far, and is an unnecessary power consumption burden.
The thermal control unit temperature throttling causes to fix the voltage to a fixed value when throttling is in place; this is useless considering frequency is not limited, making the whole thing senseless. Thus removed.
Perseus alpha13 (20/06):
Rebased sources on a Linux branch for commit completedness. All commits reapplied and cleaned. New repo.
CIFS included as module
Busybox removed. This should be part of the ROM.
Perseus alpha12 (14/06):
Added enhanced init.d support as per dk_zero-cool's implementation.
SHA-1 improvements
Added exception to the module loading logic for the exFat driver module thus making it work. (Credit to gokhanmoral)
Perseus alpha11 (10/06):
ro.secure=0
Recovery renamed as busybox in /sbin. I'll compile a proper busybox later on, or remove it alltogether when a recovery with autoinstall is released by CF or somebody else.
Perseus alpha10 (8/06):
Overclocking up to 1800MHz. Voltages in ASV table are somewhat scaled up until 1600MHz, after that you're on your own and have to optimize yourself.
Intel claims maximum sustainable safe voltage for 32nm HKMG to be 1.4V, above that may cause electron migration to the silicon and permanently deteriorate your chip. 1700 and above only for avid overclockers and benchmark freaks. Credit to tvanhak for playing lab rat with his phone.
Samsung frequency limitation removed to scale above 1400MHz, full credit goes to Gokhanmoral for finding this hack in the kernel as it is in a very sneaky location.
Perseus alpha7 (5/06):
Reduced regulator voltage initialization minimum to 600mV, you can now undervolt that far. Be aware of crashes.
Added SIO scheduler
Some network and CRC related patches
Perseus alpha6 (4/06):
UV_mV_table support, apps like SetCPU work now.
If you have a voltage set at for example 1187500µV the output will be rounded up to be displayed at 1188mV. If you set a voltage non multiple of 12.5mV then for example, 1190mV, it will round it to the nearest valid step, being 1187.5mV. UV_uV_table is there for finer grained control but no app suports that yet.
Perseus alpha3 (4/06):
Mali: disable state tracking
Mali: GPU frequency, scaling and voltage control
Governor pegasusq: make up_threshold_at_min_freq and freq_for_responsiveness configurable values. This is the reason the Galaxy S3 is so smooth, it has super aggressive scaling values for the governor until default 500MHz.
Enabled 1500MHz per defconfig and added voltage values to ASV table for it
Added UV_uV_table for voltage control on the CPU; this is not compatible for any programm which supports undervolting right now, we need UV_mV_table for that and since we have 12.5mV steps being fed to Vdd it's not compatible for now.
Boot partitions are made visible.
Knowledge base
I'm going over time to update this post with some informations. It may be unsorted, unfinished or un-editorialized for the time being.
2) Hardware
The Galaxy Note 2 will be coming out with a new 4412 versioned Rev 2.0, where as the one currently in the S3 is versioned Rev 1.1. The new chip will be launched at 1.6GHz default clock. What is interesting is that they have increased the base clock from 800MHz to 880MHz, most of the SoC internals feed off this clock, meaning that we're going to have 10% clock boost in the internal bus and memory speeds.
Now as a side note: One thing that I haven't understood from the press releases back in May, is that there were this "internal 128bit bus" mentioned, with some idiotic websites taking that tidbit and claiming the chip was a 128bit architecture. Whatever. Anyway, the reason for this is that the way the Samsung SoCs internally function: they are separated in a "left bus" and a "right bus". The left bus is connected to the memory controllers and is also just called the MIF/Memory Interface. The right bus is called the "internal bus" and is connected to the ARM cores and everything else. The biggest difference here between the 4412 and the previous Samsung iterations was that both these were running at the same clock. In the 4412 the internal bus is running at half the memory interface bus, this corresponds to the increase to 128bit in the internal bus.
Now I got curious due to all this talk about the A6 and this tidbit:
"K3PE7E700F-XGC2" the last two characters refer to the clock speed. The iPhone 4S was [under]clocked at 800 Mhz. "K3PE4E400B-XGC1" was the A5's part number. E4 refers to 2 Gb LPDDR2 die and because A5 features a dual-channel LPDDR2 memory with two 32-bit die. 2 GB x 2 = 512 mb of RAM. C1 was the clock speed which was 2.5ns which indicates a 400MHz clock frequency. Two channels result in the A5 clock speed of 800MHz. So the A6 has C2 which is 1.9ns which indicates a 533 MHz clock frequency. 533 x 2 is ~1066 GHz.
Click to expand...
Click to collapse
Both the A6 and 4412 use the same memory, only difference being what seems to be a revision serial character. I was talking a few months ago how the 4412 showed a good 30% bandwidth improvement over the 4210, and credited this to it running 1066mbps memory instead of 800mbps; but in reality that is not the case.
I went over the source code of the busfrequency driver in the S3, and found that actually there is an entry for the internal frequency to run at 266MHz (128bit), but that entry is disabled in the driver; because the memory interfaces don't exceed 400MHz. The bus speed is defined in (MIF/INT) pairs and top speed available is 400200 (400MHz memory, 200 internal). Well this is interesting we can overclock our device's memory then if there's headroom! Well that idea quickly faded as I found that the C2C (Chip-to-chip) interface to the memory isn't capable of being clocked to 533MHz because simply the C2C clock divider register simply doesn't allow a divider value needed for that frequency, only being able to run 400MHz(and lower) and 800MHz. Basically we can't use the fast memory because it seems the clock dividers don't allow it. Anyway, coincidentally the i9305 sources were released two days ago and it included all the Note 2 sources and so on, so what Samsung did was simply increase the MPLL base clock from 800 to 880MHz, actually increasing the frequency of a load of things like the camera interface and who knows what at the same time.
What this also means is that Samsung increased effective bandwidth by 30% without increasing the memory speed. This indicates much improved memory controllers, and also why it easily beats the Tegra 3 and others in memory benchmarks.
Another new addition to the REV 2.0 chip is that we'll be running 533MHz for the Mali clock by default. We were already experimenting with this on the S3 and pretty much made the GPU run up to 700MHz, of course, it gets quite warm and battery hungry, but it's neat nonetheless.
3) Reserved memory spaces
There is the current reserved memory space breakdown, with red as Perseus changes over stock:
#Secure spaces on fixed memory addresses
Front-camera firmware & heap: fimc0: fmic1 =
0x65800000 - 0x66700000 => 15360K (0xF00000) => 14336K
Multi function codec B memory space: mfc-normal =
0x64000000 - 0x64400000 => 4096K
ION device memory allocator reserved space: ion =
0x5F200000 - 0x63800000 => 71680K (0x4600000) => 48128K
Multi function codec device reserved space: device_mfc =
0x5C800000 - 0x5CA80000 => 2560K (0x280000)
Multi function codec A memory space (Virtually contiguous to MFC, practically has a physical memory hole): mfc-secure =
0x5C100000 - 0x5C800000 => 7168K (0x700000)
0x5F000000 - 0x5F200000 => 2048K (0x200000)
Bootloader: sectbl =
0x5C000000 - 0x5C100000 => 1024K (0x100000)
# non secure
Camera imaging subsystem: fimc_is => 12080K (0xBCC000) => 10240K
Display interface and frame buffer: fimd => 8192K (0x800000)
Main-camera firmware & heap: fimc0 => 62464K (0x3D00000)
Audio buffer: srp => 1024K (0x100000)
Good start dude, i will release my kernel in 2 days max too, just need to finish a few things and it's done
Sent from my Desire HD using Tapatalk 2
simone201 said:
Good start dude, i will release my kernel in 2 days max too, just need to finish a few things and it's done
Sent from my Desire HD using Tapatalk 2
Click to expand...
Click to collapse
Desire HD? Did you already get rid of your S2? Thanks. Do you have your device or also waiting for the blue one?
AndreiLux said:
Desire HD? Did you already get rid of your S2? Thanks. Do you have your device or also waiting for the blue one?
Click to expand...
Click to collapse
Haha yeah i sold it to buy a GS3, i ordered the white one from amazon.it but it is taking ages -.-"
BTW, look at my repo, i have done some great new mods if someone wants to use other govs than pegasusq (that is way better but you know, it's always good to have a choice)
Sent from my Desire HD using Tapatalk 2
Nice AndreiFlux let's test
Gesendet von meinem GT-I9300
simone201 said:
BTW, look at my repo, i have done some great new mods if someone wants to use other govs than pegasusq (that is way better but you know, it's always good to have a choice)
Click to expand...
Click to collapse
Great work. Personally I'm not going to allow anything other than Pegasusq though, I just don't see the point. The users can use your kernel if they want choice
AndreiLux said:
Great work. Personally I'm not going to allow anything other than Pegasusq though, I just don't see the point. The users can use your kernel if they want choice
Click to expand...
Click to collapse
Yeah you're right, that's why i will stay with pegasusq by default
My mods are good to use the cores as you want, like it was with Tegrak's 2nd Core
Sent from my Desire HD using Tapatalk 2
Hi
is a bootanimation possible with this kernel or is it in a future version planed?
Bootanimations on the S3 are supposedly in a proprietary format now, so we'll have to see about it. As said, for now it's baby steps as long as I'm not able to molest the flash counter on the device myself.
Wifi is not working on this Kernel
Kevinkuensken said:
Wifi is not working on this Kernel
Click to expand...
Click to collapse
Yes, me too...
+1
Same issue with wifi...
Kevinkuensken said:
Wifi is not working on this Kernel
Click to expand...
Click to collapse
I guess it boots well then! Reuploaded a new version for Wifi, please test if you want to.
AndreiLux said:
I guess it boots well then! Reuploaded a new version for Wifi, please test if you want to.
Click to expand...
Click to collapse
Strange, modules not loaded?
For me it worked perfectly from first build, using fully stock ramdisk
Sent from my Desire HD using Tapatalk 2
AndreiLux said:
I guess it boots well then! Reuploaded a new version for Wifi, please test if you want to.
Click to expand...
Click to collapse
Still no wifi with Alpha3.1
Mopral said:
Still no wifi with Alpha3.1
Click to expand...
Click to collapse
Same here
simone201 said:
Strange, modules not loaded?
For me it worked perfectly from first build, using fully stock ramdisk
Sent from my Desire HD using Tapatalk 2
Click to expand...
Click to collapse
Hmmm. I'm reverting to fully untouched ramdisk now, alpha3.2 uploaded.
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
{
"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"
}
2015-10-14
New:
Hi guys. First I want to thank you all, both current and former users, for being here in this thread with me. It's been a pleasure for me, you are all awesome.
This release is the final update of Spring. It'd took a bit longer as I wanted this one to be the most throughout tested release to date. It's rock stable for me, probably the best rom version I've released.
Now I'm moving to another project, which is different to this project, and it feels super exciting. So I'll hope to see you around.
Thanks again,
Per
Rom no longer forces encryption, meaning there's no need to flash a different kernel to stay decrypted.
The main goal with this project is to provide an optimized ROM with a handful of useful features added, on top of a heavily improved base (kernel) to improve speed, network and battery life.
This is my personal preference of how a ROM should be. I will never add features just for the sake of it, I pick those which makes sense for me. This is a one man ROM, which is good as I got control over every little bit of the process. The base of Spring is CyanogenMod 12.1 and I will always try to keep this as close to CM as possible, but at the same time improve the experience for me and you.
Except for the great features CM provides, the following additions are made (changelog in second post):
Rom additions:
Disabled forced encryption
- Added a quick setting tile to toggle expanded desktop.
- Built with latest 4.9 linaro
- Patches and optimizations from linaro.
- Added a setting to force expanded notifications (Settings -> Notification drawer -> Force expanded notification). This feature is nice when you have a big device as ours. Credits to jmztaylor.
- Settings: addded development animation transition mode 0.9. I find 0.75 too fast, and some stutter may occur. 0.9 makes no sacrifice of the lollipop fluidity and speeds the animations up 10%.
- Added LCD Density changer. Credits to Tom Marshall (Source 1) (Source 2). I very much recommend to set the DPI to 480. This will give you more screen real estate and improve your android experience. Try it, play around, and evaluate after a couple of days.
- Fixed some graphics to go with a wider range of densities.
Click to expand...
Click to collapse
Kernel additions:
- M-Preview kernel.
- Kernel compressed with LZ4 (see https://lwn.net/Articles/534168/ for info).
- Optimized VMA caching (see this for info)
- Byte-sized index for the freelist of a slab (see this for reference).
- Updated idle driver and suspend (deep sleep) code.
- MSG_FASTOPEN is now enabled by default. You can try it in your chrome browser. Enable the "TCP Fast Open" flag.
TCP Fast Open is an optimization to the process of stablishing a TCP connection that allows the elimination of one round time trip from certain kinds of TCP conversation, which can improve the load speed of web pages. In Linux 3.6 and Linux 3.7, support was added for this feature, which requires userspace support. This release enables TCP Fast Open by default.
Click to expand...
Click to collapse
- TCP auto corking.
When applications do consecutive small write()/sendmsg() system calls, the Linux kernel will try to coalesce these small writes as much as possible, to lower total amount of sent packets - this feature is called "automatic corking". Automatic corking is done if at least one prior packet for the flow is waiting in Qdisc queues or device transmit queue. Applications can still use TCP_CORK for optimal behavior when they know how/when to uncork their sockets. A new sysctl (/proc/sys/net/ipv4/tcp_autocorking) has been added to control this feature, which defaults to enabled. For benchmarks and more details see the commit link. For benchmarks see this commit.
Click to expand...
Click to collapse
- Multiboot compatible.
- Completely ditched the interactive governor from 3.10 kernel and replaced it with the one from the 3.18 kernel.
- Added a quickwake patch from Motorola.
The purpose of this feature is to drastically reduce the suspend/resume time for device driver which needs to do periodic job. In our use case (android smartphone), the system is most of the time in suspend to RAM, and needs to send a low level command every 30s. With current framework it takes about 500ms on omap3430 to resume the full system, and then suspend again. With quickwakup feature, in the resume process after resuming sysdev and re-enabling irq, the driver handler is executed, and then it suspends again. This new path takes 20ms for us, which leads to good power-saving.
Click to expand...
Click to collapse
- Added SCHED_DEADLINE, a new scheduling class for resource-reservation real-time CPU scheduler in the kernel.
Quoted from: https://lwn.net/Articles/575497/: "Deadline scheduling does away with the concept of process priorities that has been at the core of most CPU scheduler algorithms. Instead, each process provides three parameters to the scheduler: a "worst-case execution time" describing a maximum amount of CPU time needed to accomplish its task, a period describing how often the task must be performed, and a deadline specifying when the task must first be completed. The actual scheduling algorithm is then relatively simple: the task whose deadline is closest runs first. If the scheduler takes care to not allow the creation of deadline tasks when the sum of the worst-case execution times would exceed the amount of available CPU time, it can guarantee that every task will be able to finish by its deadline. Deadline scheduling is thus useful for realtime tasks, where completion by a deadline is a key requirement. It is also applicable to periodic tasks like streaming media processing."
Click to expand...
Click to collapse
- Added Heavy-Hitter Filter (HHF) qdisc.
This is a first size-based qdisc that attempts to differentiate between small flows and heavy-hitters. The goal is to catch the heavy-hitters and move them to a separate queue with less priority so that bulk traffic does not affect the latency of critical traffic. Currently "less priority" means less weight (2:1 in particular) in a Weighted Deficit Round Robin (WDRR) scheduler. In essence, this patch addresses the "delay-bloat" problem due to bloated buffers. In some systems, large queues may be necessary for obtaining CPU efficiency, or due to the presence of unresponsive traffic like UDP, or just a large number of connections with each having a small amount of outstanding traffic. In these circumstances, HHF aims to reduce the HoL blocking for latency sensitive traffic, while not impacting the queues built up by bulk traffic.
Click to expand...
Click to collapse
- Added PIE AQM scheme
This is a Proportional Integral controller Enhanced (PIE) scheduler to address the bufferbloat problem. Bufferbloat is a phenomenon where excess buffers in the network cause high latency and jitter. As more and more interactive applications (e.g. voice over IP, real time video streaming and financial transactions) run in the Internet, high latency and jitter degrade application performance. There is a pressing need to design intelligent queue management schemes that can control latency and jitter; and hence provide desirable quality of service to users. We present here a lightweight design, PIE(Proportional Integral controller Enhanced) that can effectively control the average queueing latency to a target value. Simulation results, theoretical analysis and Linux testbed results have shown that PIE can ensure low latency and achieve high link utilization under various congestion situations.
Click to expand...
Click to collapse
- Many updates to the interactive cpu governor.
What is an interactive CPU governor? Quoted from https://android.googlesource.com/ke...aebe08b/Documentation/cpu-freq/governors.txt: "The CPUfreq governor "interactive" is designed for latency-sensitive,interactive workloads. This governor sets the CPU speed depending onusage, similar to "ondemand" and "conservative" governors. However,the governor is more aggressive about scaling the CPU speed up inresponse to CPU-intensive activity."
Click to expand...
Click to collapse
- Many updates to cpuidle.
What is cpuidle? Quoted from www.fsl.cs.stonybrook.edu/docs/cpuidle/cpuidle-from-userspace.pdf: Cpuidle is a module in the Linux kernel which is respon- sible for running some power saving routines on a core when the core does not have any task in its run queue . The power saving routines try to put the core into a low power state or an idle state."
Click to expand...
Click to collapse
- Added frandom module. The following is quoted from Eli Billauer at (source):
Frandom is a Linux kernel random number generator, which is 10-50 times faster than what you get from Linux' built-in /dev/urandom. And it uses very little (/dev/frandom) or none (/dev/erandom) of the kernel's entropy pool, so it is very useful for applications that require a handy source for lots of random data.
Click to expand...
Click to collapse
- mm: Increase MIN and MAX default readahead sizes for performance reasons, and we've got enough RAM to handle it.
- Built with latest a15 optimized 4.9 linaro toolchain. See this thread (source) for info.
- Updated kernel from 3.10.40 to latest 3.10.79.
Click to expand...
Click to collapse
Download ROM: https://www.androidfilehost.com/?w=files&flid=28963
Download Gapps (Updated!): https://github.com/cgapps/vendor_google/raw/builds/arm/gapps-5.1-2015-07-03-13-41.zip
Want root? Flash SuperSU in recovery. Download it here: https://download.chainfire.eu/696/SuperSU/UPDATE-SuperSU-v2.46.zip
Credits:
- CyanogenMod
- jakew02
- bbedward
- Imoseyon
- Altaf-Mahdi
- Chainfire
Kernel source (branch "new"): https://github.com/PerLycke/android_kernel_moto_shamu
XDA:DevDB Information
Spring, ROM for the Nexus 6
Contributors
pemell
Source Code: https://github.com/PerLycke
ROM OS Version: 5.1.x Lollipop
ROM Kernel: Linux 3.10.x
Based On: CyanogenMod
Version Information
Status: Beta
Created 2015-04-06
Last Updated 2015-10-14
Changelog
2015-10-14
Hi guys. First I want to thank you all, both current and former users, for being here in this thread with me. It's been a pleasure for me, you are all awesome.
This release is the final update of Spring. It'd took a bit longer as I wanted this one to be the most throughout tested release to date. It's rock stable for me, probably the best rom version I've released.
Now I'm moving to another project, which is different to this project, and it feels super exciting. So I'll hope to see you around.
Thanks again,
Per
2015-09-29
- Kernel update. Added BFQ-v7r8 I/O scheduler which cyanogen himself states as SUPERBUTTER. Let's see if we all agrees with him.
- All the ordinary upstream changes.
2015-09-22
- Kernel update to 3.10.89.
- Updates to wireless driver.
- Upstream updates.
2015-09-16
This update is all about power saving behavior. I don't like the stock behavior, it throttles the CPU as soon as you hit 40% and unplug a CPU as soon as you hit 15%. As long as we have the battery saver feature and the fast charging, let us stay in control, and don't force a worst performance on us. I've changed it so the CPU will throttle at 20% and unplug a CPU at 10% (and never unplug a second one).
I've also enabled a low memory kill optimization option, to have LMK select task to kill from rbtree.
Older changelogs:
2015-09-10
- Kernel update and wireless driver update.
- ROM upstream updates.
2015-09-01
Big kernel update:
- Up to par with M-kernel
- Updated to Linux 3.10.87
- Updated wireless driver
- Rom: Upstream changes
2015-08-29
- Fixed mms issue
- Updated wireless drivers
- Upstream changes
2015-08-15
- I was not pleased with the slow USB charging rate. With USB the charging current is around 160-170 mA. So the charging output is slightly increased over USB (up to about 300-400mA, courtsey of imoseyon).
- Upstream changes, a lot of them
2015-08-11
- Big kernel update (Now on Linux 3.10.86)
- Upstream changes, a lot of them.
2015-07-27
- Updated wireless driver. Should improve wireless stability and improve battery performance.
- Fixes and improvements here and there. Trying to squash the few bugs still there (which I don't experience). It's very hard to fix an issue I don't have but I'm trying so please bear with me.
- A lot of CM upstream changes.
2015-07-20
This is quite a big update. There's a bunch of kernel commits from the latest m-preview which I implemented in Spring kernel. There's also many upstream CM-changes implemented.
2015-07-13
- Updated Gapps. Download here: https://www.androidfilehost.com/?fid=24052804347773064
- The updated Gapps fixes Google Play Services battery drain and the Google Search FC issue.
- Kernel update to 3.10.84.
- CM upstream changes.
2015-07-06
- Kernel update to version 3.10.83.
- Wireless driver update.
- Fixed livedisplay tile, will now show outdoor mode if available.
- CM upstream changes.
- Updated Gapps. Download link: https://github.com/cgapps/vendor_google/raw/builds/arm/gapps-5.1-2015-07-03-13-41.zip
2015-07-01
- Kernel update to version 3.10.82.
- CM upstream changes.
2015-06-27
- Updated kernel to 3.10.81.
- A lot of google upstream updates of the wireless driver.
- Updated boot animation.
- New default wallpaper.
- Some more small updates here and there.
- Added a power menu qs-tile.
- Fixed some games not opening and Kindle not being able to download books.
- Fixed kexec implementation.
2015-06-21
- Freshly synced upstream.
- New bootanimation.
2015-06-10
- Bug fixes
- Kernel update to 3.10.80
- CM upstream
2015-06-04
- Misc fixes, updates and improvements. If you want to know in detail please see my github for reference.
- Updated Gapps at https://github.com/cgapps/vendor_google/tree/builds/arm. Make sure to flash this version.
2015-06-03
ROM
- Squashed some memory leaks with fixes from Android M-release.
- A few optimizations from the Android M-release.
CM upstream with the following changes to WiFi-calling and Enhanced 4G LTE Mode:
- IMSEnabler: Application to toggle the Enhanced 4G LTE Mode setting
Somewhere in the changes made by caf to IMS the AOSP ims.apk is not
reading that Enhanced 4G LTE Mode is enabled at boot, or possibly its
a race condition. IMS works fine if it is toggled off and back on
after network data is established. So we set up a reciever for network
change events and do the toggle when mobile data is activated.
Click to expand...
Click to collapse
KERNEL
- Memory enhancements.
- Updated CPU interactive governor to follow aosp-common/android-3.18 repo.
- CM upstream with a big update to the f2fs file system.
2015-05-31
- Android M kernel base. Kernel is now up to par with the kernel coming with Android M. I've redone my whole kernel (again lol) so every single commit from Android M preview is implemented cleanly without a single conflict. I've implemented all my improvements, and CM improvements, from the past on top of the Android M kernel, thus you don't miss out on the features from past releases. Also, the kernel base is updated to 3.10.79 so it's on par with Linux mainstream. This means it's up to date with both AOSP and Linux and in whole provides a cutting edge kernel.
- ROM-wise there's a lot of updates to AOSP repositories.
- CM upstream
- VoLTE now kind of works. It will soon fully work but in the meantime see this post: http://forum.xda-developers.com/showpost.php?p=61028937&postcount=76
2015-05-28
- Merged in Android 5.1.1 release 4: https://github.com/PerLycke/android...mmit/943467249627a91eee4bf2fbed7750226c8c5d72
- Kernel update from AOSP: https://github.com/PerLycke/android...mmit/6647622c39e00d981b8bdeeaeda55eeb6251c55d
- Shamu vendor blobs updated to LYZ28E: https://github.com/TheMuppets/propr...mmit/cf5ddd2b15b53d2dfaa01e3a42772926283cd688
2015-05-27
- Fixed Google Play Services FC. Thanks to arter97 for pinning down the issue and to squid267 for pointing me to it.
- Updated cpu interactive governor. The governor in it's updated state seems to work just wonderful, makes things smoother. IMO It's worth upgrading to this release just for this.
- Upstream CM changes. There's been some important changes, e.g. some bug fixes related to custom densities.
2015-05-24
- Added a screenshot tile to quick settings.
- Updated wireless drivers from android repo. This should improve your wireless connection and could save you some power.
- Added FauxSound support. Use FauxSound app or any other app with FauxSound compatibility to control it.
- Merged in Android 5.1.1_r3.
- CM upstream changes.
2015-05-21
- Improved scrolling fluidity
- Upstream CM changes
2015-05-17
- Updates to memory management to avoid random reboots and improve multitasking.
2015-05-16
- Bugfixes
- CM upstream
2015-05-14
- Implemented some linaro optimizations (reference) and (reference).
- Removed some CM stuff (e.g. the updater).
- Kernel is now compressed with LZ4 (info).
2015-05-13
- Fixed some compatibility issues and vastly improved battery-life. Please upgrade to this build if you are on the 20150507 or 20150510 (or older) build.
2015-05-10
- Cleaned up the kernel repository and moved to branch master.
- Updated the kernel to 3.10.77.
- Implemented a couple of new memory management features.
- CM upstream changes.
2015-05-07
- Added a quick setting tile to toggle expanded desktop. It's nice when reading articles or pdf's.
- Several updates to kernel memory management.
- CM upstream changes.
2015-05-04
- Updated idle driver and suspend (deep sleep) code.
- MSG_FASTOPEN is now enabled by default. You can try it in your chrome browser. Enable the "TCP Fast Open" flag. TCP Fast Open is an optimization to the process of stablishing a TCP connection that allows the elimination of one round time trip from certain kinds of TCP conversation, which can improve the load speed of web pages. In Linux 3.6 and Linux 3.7, support was added for this feature, which requires userspace support. This release enables TCP Fast Open by default.
- TCP auto corking. When applications do consecutive small write()/sendmsg() system calls, the Linux kernel will try to coalesce these small writes as much as possible, to lower total amount of sent packets - this feature is called "automatic corking". Automatic corking is done if at least one prior packet for the flow is waiting in Qdisc queues or device transmit queue. Applications can still use TCP_CORK for optimal behavior when they know how/when to uncork their sockets. A new sysctl (/proc/sys/net/ipv4/tcp_autocorking) has been added to control this feature, which defaults to enabled. For benchmarks and more details see the commit link. For benchmarks see this commit.
- CM upstream changes.
- Reverted adaptive-tick mode for scheduling-clock ticks handling.
2015-04-30
- Multiboot compatibility
- Disabled housekeeping ticker when a CPU handles a single task and improved timerless multitasking: allow timekeeping CPU go idle.
- CM upstream changes
2015-04-29
- Kernel updated from mainline to 3.10.76
- Upstream CM changes
2015-04-28
New: It's time for an update, and this time I'm bringing you something special. I've never been satisfied about how the CPU behaves on the interactive governor, the scaling behavior and jumping between cores and frequencies sometimes doesn't seem logical. After monitoring the CPU in different situations, especially when idling, made me want to improve the governor.
So, in today's release the interactive governor from 3.10 kernel is ditched completely. Rm'd.
Instead you'll find a completely updated interactive governor, implemented straight from the 3.18 kernel. This version of the interactive governor is implemented in a much cleaner way. It's more simple, more clean, and the the result is satisfying to say the least.
I've been running this one for 24 hours now. The way it deep sleeps, the way it idles and the way it scales up under heavy load seems great. So it should be more gentle to your battery and suite you well when you need to do some heavy work.
On a last note. This wasn't complicated. Sometimes you miss the most obvious things and opportunities, which are right there in front of you to grab.
Enjoy folks,
Per
2015-04-25
- CM upstream (including bump to Android 5.1.1).
- Disabled forced encryption by default.
2015-04-21
- More updates to the kernel. Implemented a quickwake patch from Motorola. Some minor layout updates to framework. CM upstream changes.
And I've updated the link to official CM 12.1 gapps (use this from now on).
The no encryption kernel is also updated.
2015-04-20
- You'll find a flashable kernel zip here with forced encryption disabled. If you are decrypted, flash it after you flash my ROM (before booting) and you'll stay decrypted. The ROM itself still forces encryption so flash this zip if you want to stay decrypted.
- Introducing SCHED_DEADLINE, a new scheduling class for resource-reservation real-time CPU scheduler in the kernel.
Quoted from: https://lwn.net/Articles/575497/: "Deadline scheduling does away with the concept of process priorities that has been at the core of most CPU scheduler algorithms. Instead, each process provides three parameters to the scheduler: a "worst-case execution time" describing a maximum amount of CPU time needed to accomplish its task, a period describing how often the task must be performed, and a deadline specifying when the task must first be completed. The actual scheduling algorithm is then relatively simple: the task whose deadline is closest runs first. If the scheduler takes care to not allow the creation of deadline tasks when the sum of the worst-case execution times would exceed the amount of available CPU time, it can guarantee that every task will be able to finish by its deadline. Deadline scheduling is thus useful for realtime tasks, where completion by a deadline is a key requirement. It is also applicable to periodic tasks like streaming media processing."
Click to expand...
Click to collapse
- Introducing Heavy-Hitter Filter (HHF) qdisc.
This is a first size-based qdisc that attempts to differentiate between small flows and heavy-hitters. The goal is to catch the heavy-hitters and move them to a separate queue with less priority so that bulk traffic does not affect the latency of critical traffic. Currently "less priority" means less weight (2:1 in particular) in a Weighted Deficit Round Robin (WDRR) scheduler. In essence, this patch addresses the "delay-bloat" problem due to bloated buffers. In some systems, large queues may be necessary for obtaining CPU efficiency, or due to the presence of unresponsive traffic like UDP, or just a large number of connections with each having a small amount of outstanding traffic. In these circumstances, HHF aims to reduce the HoL blocking for latency sensitive traffic, while not impacting the queues built up by bulk traffic.
Click to expand...
Click to collapse
- Introducing PIE AQM scheme
This is a Proportional Integral controller Enhanced (PIE) scheduler to address the bufferbloat problem. Bufferbloat is a phenomenon where excess buffers in the network cause high latency and jitter. As more and more interactive applications (e.g. voice over IP, real time video streaming and financial transactions) run in the Internet, high latency and jitter degrade application performance. There is a pressing need to design intelligent queue management schemes that can control latency and jitter; and hence provide desirable quality of service to users. We present here a lightweight design, PIE(Proportional Integral controller Enhanced) that can effectively control the average queueing latency to a target value. Simulation results, theoretical analysis and Linux testbed results have shown that PIE can ensure low latency and achieve high link utilization under various congestion situations.
Click to expand...
Click to collapse
- Many updates to the interactive cpu governor.
What is an interactive CPU governor? Quoted from https://android.googlesource.com/ke...aebe08b/Documentation/cpu-freq/governors.txt: "The CPUfreq governor "interactive" is designed for latency-sensitive,interactive workloads. This governor sets the CPU speed depending onusage, similar to "ondemand" and "conservative" governors. However,the governor is more aggressive about scaling the CPU speed up inresponse to CPU-intensive activity."
Click to expand...
Click to collapse
- mm: Increase MIN and MAX default readahead sizes for performance reasons, and we've got enough RAM to handle it.
- Many updates to cpuidle.
What is cpuidle? Quoted from www.fsl.cs.stonybrook.edu/docs/cpuidle/cpuidle-from-userspace.pdf: Cpuidle is a module in the Linux kernel which is respon- sible for running some power saving routines on a core when the core does not have any task in its run queue . The power saving routines try to put the core into a low power state or an idle state."
Click to expand...
Click to collapse
- Updated kernel to 3.14.75.
- Rom-wise some fixes are done to the DPI changer and upstream CM changes.
2015-04-17
- Several fixes and improvements. (It fixes a lot of things so please upgrade to this one if you are on 2015-04-16.)
2015-04-16
- Added a setting to force expanded notifications (Settings -> Notification drawer -> Force expanded notification). This feature is nice when you have a big device as ours. Credits to jmztaylor.
- Upstream kernel changes, bumped to 3.10.74.
- A lot of upstrem CM changes.
2015-04-10
- Added density changer. Changes in density have no impact on play store compatibility (Settings -> Display and lights -> LCD Density)
- Updated kernel from 3.10.40 to 3.10.73.
- Removed CM updater to stop confusing users.
- Changed navbar layout overlay to make it look better on more densities.
- Reverted BFS to CFS.
2015-04-09
- Fixed dialer layout when using 480 dpi
- Upstream CM changes
2015-04-05
- Initial release
Sweet May give this a try
Wooorrdddd
Super excited to try this! Flashing now. OP sounds very thorough. Love the idea of simple and stable.
Cool to see another BFS adopter
Double-tap to wake working nicely. Returned DPI to default (560), but Appstore still doesn't recognize it as a Nexus 6. I can download "Amazon for Tablets", but not the regular Amazon app.
Good job. This ROM flies.. Optimizations make a huge difference.
How do I change DPI back to the 560 I can't download anything from play store.
kingskidd268 said:
How do I change DPI back to the 560 I can't download anything from play store.
Click to expand...
Click to collapse
You can't even get TexDroider from the store? If not.. Google search it and you'll find the apk.
Or you can edit the build prop back to 560 or whatever you like with Root Browser / Editor.
Sounds cool. Wish it was earlier. Be back to try this tomorrow. Thanks
hijax2001 said:
Double-tap to wake working nicely. Returned DPI to default (560), but Appstore still doesn't recognize it as a Nexus 6. I can download "Amazon for Tablets", but not the regular Amazon app.
Click to expand...
Click to collapse
Edit: I see now that you are trying to use amazon app store. I've got no knowledge about that store and how it handles different densities. I will take a look at it. Cheers / Per
Edit 2: I'm tired, now I get it you are trying to download amazon app store from Google play. All my 100+ apps are treated as phone apps so I don't know why this one isn't. Will try to find out. Cheers again / Per
kingskidd268 said:
How do I change DPI back to the 560 I can't download anything from play store.
Click to expand...
Click to collapse
About DPI and Play Store: The density of your rom, like 480, will be registered within Google apps. If you change the density it needs to get re-registered. You could let it sit for a while or try to clear Googla Play Services, Google Services Framework and Play Store cache followed by a reboot. You would probably have to wait some time after this for the new density to get registered.
The reason I changed the density within the source is that if you do a clean install (format system and data before flashing) the only density which will be registered to Google apps upon first boot is 480 and you will have no problem installing apps in Play Store. I've installed 100+ apps without no issues whatsoever when following those instructions.
480 is the "native" density for Shamu and it was actually used by google some time before releasing. It gives you more screen real estate and I highly recommend using it and take advantage of the big beautiful screen we have.
Some odd apps, like Amazon app store, chooses the tablet layout resources when on 480 DPI. Not many apps behaves like this and it's not that big of a drawback IMHO. If you feel it is you can always sideload the Amazon app store phone layout app using http://apps.evozi.com/apk-downloader/. Don't use that link to try and download paid apps (It won't even work).
Thanks...I was indeed referring to downloading the Amazon Store app from Google Play.
Nice and smooth so far ! Thanks for sharing !
Rom updated to 20150409, changelog in second post.
Cheers,
Per
Solid ROM, very fluid. Just wish you had, or plan to add, LCD Density. :good:
Andromjb said:
Solid ROM, very fluid. Just wish you had, or plan to add, LCD Density. :good:
Click to expand...
Click to collapse
Just use romtoolbox.
Well, i have now an encrypted phone!!!
You should update the thread...
niyazidk said:
Well, i have now an encrypted phone!!!
You should update the thread...
Click to expand...
Click to collapse
Sorry for that mate but I haven't said I've disabled encryption by default. This is based on CM kernel and CM kernel is encrypted by default. You can't assume a non default feature is there if not stated by me.
I guess you can back up your data, flash a kernel with default encryption disabled, wipe userdata with fastboot and restore your data.
Can I ask why you want it decrypted? I can't find a good reason
Hey guys and girls,
So straight to Topic.
The Kirisakura-Harmony is based on the latest google sources. On top of it are the latest EAS patches directly from Linaro. It also includes a few Audio Patches from CAF. Power Gating is disabled so you can use this kernel with @chdloc ´s excellent, I am wholeheartedly recommending it, biquads mod. If you grasp what you can do with it, you will never need an equalizer in your life again. So this is also an audio oriented kernel.
As I said I am still learning. The Feature list Comes here:
- Based on the latest Sources from Google for Android Q/10
- Upstreamed to 3.18.140
- Schedutil included again
- GPU Adrenoboost
- Wake gestures from flar2
- KCAL from savoca and ported by tbalden
- HBM enabled and accessible for the user
- Backlight dimmer is added
- FIOPS, SIO and MAPLE I/O Scheduler included
- Updated BFQ I/O Scheduler
- I managed to merge some Audio Patches from CAF, which should enhance Audio
- Power Gating disabled so you can use @chdloc ´s biquad mod
- Vibration Control
- Sound Control
- sdcardfs
- Sched and latest Schedutil (with latest upstream patches is also default)
- Updated EAS Machinery
- USB fast charge
Instructions for Android P
How to flash the Kernel:
1. Download the kernel.zip to your device
1a. Optional: While it may not be necessary all times, you may want to restore stock boot.img, re-root with magisk and optionally install twrp.zip if coming from another kernel. Before reporting issues make sure you do that! Thank you!
You only need to do either 2a OR 2b
2a. Boot to TWRP and flash my kernel.zip. Root will be preserved!
or
2b. Flash kernel zip in EX Kernel Manager or FKM app. Root will be preserved!
3. After booting up make sure to set schedutil as default CPU governor (check apply on reboot option) to fully profit from the kernel´s changes!
4. Enjoy your device now!
Android 10 Download:
Download:
https://www.androidfilehost.com/?w=files&flid=300707
Download for PIE
Download:
https://www.androidfilehost.com/?w=files&flid=198589
Oreo Kernel Stuff
Download:
https://www.androidfilehost.com/?w=files&flid=152851
Changelog-Mainline:
0.1
- Initial release
0.2
-added safetynet patch
0.3
- Add GPU OC
- Update wake gestures
- Many new Performance Patches
- Updated dm verity
0.4_1
- More performance tweaks
- Made my kernel a flashable zip <-- I hope you guys are satisfied now
0.5
- add Slimbus OC <-- Increases Audio Quality
- Various crypto Patches
- More Patches that may help with Performance
- added wakelock Patches
- added a few alsa patches
0.6
- added soundcontrol
- disabled some logging stuff
- some more tweaks
0.7
-enabled few other tcp congestion algorithms <-- westwood is now default
- set default iosched to deadline as it works best with eas kernels if we trust the documentation
0.8
- added sdcardfs <-- take a look at the FAQ on how to enable it
- added in two new governors, alucardsched and darknesssched
- merged in some other commits. take a look at my github
0.9
- when deactivating kernel side dt2w and s2w, one is still able to use the stock google dt2w implementation
- code updates for both alucardsched and darknesssched <--- if anyone has time please test and report back how they work with 0.9
- added option for GPU boost <--- disabled by default, take a look at the faq please
- update to cpuidle <--- deep sleep is improved for me
- the simple_ondemand GPU governor is now usable and does not crash upon choosing
- fix an issue were tasks were not given properly to cpusets
- a few other changes, please take a look at my github
0.9_5
- fixed a typo which would the user not choose msm-adreno-tz GPU governor after choosing simple_ondemand <--- also have no worries I implemented a patch that will let you choose only GPU governors that will not crash
- a few more commits for schedutil and sdcardfs
0.10
- all security patches
- some patches that may help with efficiency
- many patches to schedutil,sched, and walt (many)
- few patches to sdcardfs
- tuned WALT values a bit
- other things I forgot, check my github
0.11
- I added a few additional commits to adrenoboost, it is now more conservative and suited for daily use. I run it on moderate boost and don´t notice any battery drain
- performance of the fingerprint reader may be improved <-- I need feedback from you, don´t use it myself
- update to slimbus OC
- a few patches that may help with stability and performance in general
- many patches to schedutil , it is the recommended governor now in conjunction with nohint.zip
- introduced a new governor, called helix_schedutil based on schedutil; thanks to @ZeroInfinity
I had a little play with it, if anyone finds better values I can include them.
- for more details check my github
- please check this post prior to flashing: https://forum.xda-developers.com/showpost.php?p=71415045&postcount=210
Changelog for 0.12:
- added blu active governor
- updates to helix_schedutil, alucardsched and darknesssched
- updates to sdcardfs
- maybe some performance improvements <-- please give feedback
- other things look at my github
- made a non oc version
- please check this post prior to flashing: https://forum.xda-developers.com/showpost.php?p=71502126&postcount=241
Changelog for 0.13
- Implemented CPU_Input_Boost by sultanxda <--- disabled by default, if you experience scrolling lag activate it in EXKM, CPU Tab
- Implemented a new sched governor called energy-dcfc (Dynamic Capacity and Frequency Capping), more information in second and third post
- Some adjustements for schedutil
- Updated helix_schedutil
- some improvements to alucardsched and darknesssched
- adjusted WALT to final parameters
- bumped up and improved BFQ, thanks @DespairFactor <-- new default
- introduced Maple I/O scheduler
- updated sdcardfs
- please check this post prior to flashing: https://forum.xda-developers.com/showpost.php?p=71502126&postcount=241
Changelog for 0.14
- Added April Security Patches
- Updates to Schedutil, Sched, energy-dcfc
- Introduced a new EAS governor called pwrutil <-- more information on the second post
- Some upstream patches
- some more crypto patches
- updated wakelock blockers
- for other things look at my github
- please check this post prior to flashing: https://forum.xda-developers.com/showpost.php?p=71502126&postcount=241
Changelog for 0.16
- Linux Kernel Version is now 3.18.51
- Applied May security Patches
- many other little improvements and changes
Changelog-Rebase:
- Features EAS 1.2 Machinery
- May security update
- Linux version 3.18.53
- Includes all features from mainline except the EAS Governors (sched and schedutil are included) and CPU Boost.
- IO switcher
- some patches to schedutil
1.24
Updated sdcardfs
little performance tweak
updates to low power mode
1.28
- IO switcher
- some patches to schedutil
1.29
- performance tweak
1.32
- 3.18.55
- June Security Update
1.36
- updated sdcardfs
- EAS patch
- Linux Bump to 3.18.56
- ipv6, net and ext4 patches
1.40
- Linux Version now at 3.18.59
- July Security Patches
- updated sdcardfs
- little patch for sched
- boost now also ufs storage controller upon turning on the screen additionally to boost ddr bandwidth(even faster wakeup)
- extended recharge rate when battery is near full (aids longevity of our battery)
Changelog-Harmony:
4.00
https://forum.xda-developers.com/showpost.php?p=75835635&postcount=1105
5.01
https://forum.xda-developers.com/showpost.php?p=76106520&postcount=1129
6.00
https://forum.xda-developers.com/showpost.php?p=77515614&postcount=1166
6.01
https://forum.xda-developers.com/showpost.php?p=77533981&postcount=1178
6.02
https://forum.xda-developers.com/showpost.php?p=77588617&postcount=1180
6.04
https://forum.xda-developers.com/showpost.php?p=77758260&postcount=1188
6.05
https://forum.xda-developers.com/showpost.php?p=77776533&postcount=1189
6.06
https://forum.xda-developers.com/showpost.php?p=78125103&postcount=1198
6.07
https://forum.xda-developers.com/showpost.php?p=78342154&postcount=1209
7.00
https://forum.xda-developers.com/showpost.php?p=78916917&postcount=1243
7.01
https://forum.xda-developers.com/showpost.php?p=78968314&postcount=1251
8.10
https://forum.xda-developers.com/showpost.php?p=79506878&postcount=1287
10.0
https://forum.xda-developers.com/showpost.php?p=80581575&postcount=1301
10.1.0
https://forum.xda-developers.com/showpost.php?p=81119421&postcount=1311
FAQ:
Q: Which app do you recommend to apply changes to the kernel?
A: EX Kernel Manager from @flar2 is a great choice. He is constantly updating it.
Q: Which CPU governor I can choose freely and not hinder the EAS?
A: schedutil
Q: what is GPU boost and how should I choose the boost level?
A: I also implemented GPU Boost.
if you use the default GPU governor which is msm-adreno-tz you will have the option of GPU boost in EXKM. if you choose simple_ondemand not.
I think GPU Boost is not really needed on this phone as it raises GPU freqs aggressively enough for most tasks. So I leave it disabled at default.
It was originally introduced on the HTC 10, to counter an issue whereby the GPU failed to scale up aggressively enough, to run some not demanding games properly in 60fps locked. But there are some performance junkies (like me) who want to try such things.
So you can enable this setting and it has 3 profiles. Low, medium and high. It defines how aggressively the GPU gets scaled up.
I found GPU boost on low to be quite a good all day setting. Maybe a little bit more performance and not a too big hit on battery.
Medium and High are definitely more battery hungry and you should do this only for gaming or benchmarks.
Q: What is the difference of WALT and PELT and how does it affect me?
A: https://forum.xda-developers.com/showpost.php?p=71336204&postcount=179
Credits:
@Eliminater74 for bringing me into the game and the Inspiration
@flar2 for all his work
@tbalden
@savoca
@franciscofranco
@DespairFactor for the zip and the help
@Alucard24
@ZeroInfinity
@RenderBroken for helping me out
@dorimanx
@Sultanxda
if i forgot anyone just pm me and I will gladly add you
Source: https://github.com/freak07
Info Post
So this post will be dedicated to information about EAS in general.
Another amazing write up about alucardsched by a talented new dev @joshuous:
This is what I understand from tracing the Alucardsched code. I apologise if my understanding is incorrect.
Firstly, next frequency selection with Schedutil (very simple):
Code:
next_freq = 1.25 * Max_freq * current_util / max_util;
Now, here's a quick overview of one cycle of frequency selection in Alucardsched:
1. You have two key extra tunables: PUMP_INC_STEP and PUMP_DEC_STEP
2. Current utilisation here refers to the system's current demand. It is calculated using:
Code:
curr_util = (util * (100 + tunables->boost_perc)) / max_utilisation
The "util" is a value determined by the EAS scheduler.
3. Target load here refers to what processor is currently supplying. It is calculated using:
Code:
target_load = (current_freq * 100) / max_freq;
4. The key idea is to ensure that supply satisfies demand. That is, target load ≈ current load.
5. If target_load <= current_load (too little supply), then we want to increase frequencies to match the system’s load. For Alucardsched, frequency is increased by jumping up PUMP_INC_STEP number of steps in the OPP table. (By OPP table, I refer to the available frequencies that you can switch to)
6. If target_load > current_load (too much supply), then we want to decrease frequencies to match the system’s load. For Alucardsched, frequency is decreased by jumping down PUMP_DEC_STEP number of steps in the OPP table.
7. Do note that Alucardsched jumps several frequency steps, compared to Schedutil and Interactive which try to jump immediately to a calculated next frequency. In this way, Alucardsched doesn't care about the specific value of the next speed. It's like driving a car, and deciding to increase gears by several steps instead of deciding to jump immediately to a specific gear.
Extra Tunables
FREQ_RESPONSIVENESS
PUMP_INC_STEP_AT_MIN_FREQ
PUMP_DEC_STEP_AT_MIN_FREQ
Sometimes you want the "pumping" behaviour to behave differently at lower and higher frequencies. FREQ_RESPONSIVENESS can be seen as the mark that divides the low and high frequencies. If the current frequency is less than FREQ_RESPONSIVENESS, the number of frequency skips will be PUMP_INC_STEP_AT_MIN_FREQ and PUMP_DEC_STEP_AT_MIN_FREQ instead of the usual PUMP_INC_STEP and PUMP_DEC_STEP.
How is it used? If your frequency is low (lower than FREQ_RESPONSIVENESS) and your system demand is high, you ideally want to boost frequency speeds quickly. This is when PUMP_INC_STEP_AT_MIN_FREQ kicks in. PUMP_INC_STEP_AT_MIN_FREQ is usually (and should be) a larger value than PUMP_INC_STEP. When your frequency is high (higher than FREQ_RESPONSIVENESS) and your system demand is high, you don't want to be jumping so many steps up otherwise you will hit max frequencies too quickly (overkill). I'm pretty sure you can figure out how PUMP_DEC_STEP and PUMP_DEC_STEP_AT_MIN_FREQ works after having read this paragraph
Tldr;
Schedutil: simpler
Alucardsched: more tunable
Code:
IF CURRENT_FREQ < FREQ_RESPONSIVENESS:
PUMP_INC_STEP_AT_MIN_FREQ and PUMP_DEC_STEP_AT_MIN_FREQ are used
ELSE:
PUMP_INC_STEP and PUMP_DEC_STEP are used
PUMP_INC_STEP_AT_MIN_FREQ should be larger than PUMP_INC_STEP.
Note: There is however a potential problem (if you may call it one) with Alucardsched: just like Interactive you rely almost entirely on heuristics (trial and error) to control your frequency jumps instead of letting the system choose it for you, like in Schedutil. In that way, Alucardsched detracts from the goal of Schedutil to provide a simple frequency choosing mechanism. Without the proper tuning to meet your specific usage, it is likely that your frequencies will overshoot or undershoot past the needed load on Alucardsched (just like in Interactive). I would recommend that you play with the tunables to see what works best for you.
Here is information about energy-dcfc (Dynamic Capacity and Frequency Capping):
This new governor is based on schedutil. It uses target_load variables as thresholds to let the governor decide when to cap the frequencies for both clusters. These variables are called "load1_cap" and "load2_cap". Load1_cap corresponds to target_load1 meaning anything that is below target_load1, it caps using load1_cap. Anything above target_load1 and below target_load2, use load2_cap. Anything above target_load 2 and the maximum frequency will be used.
As a result of this behaviour, bit shift value must be set to 1. Anything higher than 1 and frequency scaling will be extremely slow. This is because the lower the maximum frequency, the lower the next frequency target is because the frequency range is being limited.
AS OF V009: The governor has now incorporated @Kyuubi10 's schedutil dynamic formula change. When load is below target_load1 it will use add bitshift in the formula. If load is above target_load1 but below target_load2, it won't use any bit shifting at all. If load is more than target_load2, it will subtract bitshift in the formula. This has proven to be very efficient with a touchboost-like behaviour when scrolling (Up to the capped frequency of this governor), then steady performance in between, and on heavy workloads it will not just stay on maximum frequency, in fact it will hover around 1.3-1.9GHz to ensure thermals are good as well as battery endurance.
This governor is aimed with maximum efficiency in mind. Do not expect outstanding performance with this governor.
helix_schedutil explained by @Kyuubi10
To understand Helix_schedutil you must first understand the original schedutil algorithm.
Here it is:
next_freq = maxfreq + (maxfreq >> bitshift) * util/maxcapacity
Explanation:
The most obvious difference of this algorithm is that it moves away from the idea of scaling frequencies up or down which were used in previous generations of governors.
Instead the aim of the above algorithm is to calculate the most appropriate frequency for the TOTAL CPU load.
NOTE: This is TOTAL load on CPU, not just load for the current frequency step as Interactive used to calculate with.
Now, for you numberphiles like myself that like understanding algorithms... Let's break it down:
"util/maxcapacity = Load."
The above creates a percentage value in decimal format (80% = 0.8) which represents the TOTAL load on CPU.
the algorithm now reads the following way:
next_freq = maxfreq + (maxfreq >> bitshift) * load
"maxfreq + (maxfreq >> bitshift)"
Essentially the aim of the above is to ensure that next_freq is always a little higher than the exact value needed to cover the load.
Bitshift: (paraphrasing @ZeroInfinity) in programming the ">>" mathematical function allows for shifting the binary values towards the direction of the arrows by "N" times.
In this case it is towards the right.
The relationship between "N" and the calculation in the "()" is as follows:
Bitshift = 1 = maxfreq/2
Bitshift = 2 = maxfreq/4
Bitshift = 3 = maxfreq/8
If the "+()" didn't exist in the algorithm, the chosen frequency would be exactly enough to cover the load.
If load is 0.6, aka 60%, all you need is a frequency = 60% of max frequency.
This would be bad since it doesn't leave any capacity/bandwidth leftover for inevitable bumps in load, nor space for EAS itself to run. Thus inevitably creating lags.
To keep a bit of free bandwidth you add "(maxfreq >> bitshift)".
Finally the problem I encountered, if bitshift = 2, then the result of the algorithm is that any load above 0.8 will result in a next_freq HIGHER than maxfreq. - This is your tipping point. As any load higher than 80% will wake up a new CPU.
Which means you have still about 20% of the CPU's max capacity being unused. Such a CPU is only 80% efficient.
Therefore by increasing bitshift to 3, the algorithm reads:
"maxfreq+(maxfreq/8)*load = next_freq"
This way you can use 89% of capacity before reaching max frequency of the CPU.
With bitshift=4 it reads:
"maxfreq+(maxfreq/16)*load = next_freq"
This allows you to use up to 94% total CPU load before reaching max frequency.
While this is great for improving efficiency at the higher frequencies, it doesn't leave enough bandwidth when calculating lower frequencies, and creates lag when load spikes at lower frequencies.
Update to the explanation:
After being inspired by the concept of @ZeroInfinity's new governor - Energy-DCFC, I decided to carry out a couple of tests on HTC 10 using variations of Helix_Schedutil.
The focus was stress-testing by increasing the current frequency load above 100%. (AKA Use up all of the bandwidth of the current frequency step.)
After the testing me and Zero worked on this new version of Helix_Schedutil.
The current behaviour of the governor is the following:
- Boost frequencies when load is below Target_Load1. (Boost can be increased by DECREASING bit_shift1 value.)
- Between Target_Loads there is no bit_shift at all. The governor just uses the following algorithm instead - (max_freq*util/max = next_freq)
- Loads higher than Target_Load2 will be THROTTLED. Bit_Shift2 here is subtracted rather than added. (Throttle effect can be increased by DECREASING bit_shift2 value.)
The result is that low freqs have spare bandwidth to avoid lags, middle frequencies leave no extra bandwidth at all, while higher frequencies are throttled to save battery.
Another focus of the governor update is to reduce overhead as much as possible. This results in a very responsive governor which isn't overly demanding on battery life.
Schedtune.boost values recommended for use with this governor:
Top_App: 5
Foreground: -50
Background: -50
Global: -50
Energy-DCFC is still recommended for those who prefer battery life over performance, but if you prefer greater performance then this governor can be used without making you feel guilty about wasting battery.
correction a misconception:
Some people describe tipping point as the load threshold which the governor uses to decide whether to ramp up or down.
While if you look into the behaviour of the governor it may appear that it behaves in such a way, it is technically incorrect.
As I mentioned previously this new algorithm moves away from the behaviour of legacy governor algorithms which focus on the current frequency load.
This governor does no ramping up or down.
It isn't even aware of the current frequency load, as it only knows the load relative to max capacity.
The misconception appears based on a property of the algorithm that results in a consistent load at any chosen frequency. This is a coincidental result of the algorithm, even though the algorithm is completely unaware of it.
Tipping point is in fact the load percentage at which the CPU reaches max frequency and any increase in load forces it to wake up a new core
here is some Information about pwrutil governor:
This new governor is based on schedutil.
A much simpler yet very effective governor based on schedutil. All this changes is the calculation to get the next frequency. Rather than using bit shift to calculate tipping point and what not, we don't use it at all. This is much much more efficient if you use my program called "schedutilCalculator" to calculate what the next frequency is. For example, a load of 25% with a max freq of 2150400 will get 500MHz as next frequency. A load of 50% will get 1GHz as next frequency. A load of 75% will get 1.5-1.6GHz as next frequency. A load of 100% will get 2.15GHz as next frequency. You can see the lower the load, the much lower the frequency selection will be, but the higher the load and the higher the frequency selection is. So it can go from a very low powered state with 50% load and under, to a high performance state from 75% load and above.
Includes a tunable called "utilboost" which is basically a load multiplier - it makes load higher than it is perceived by the governor, thus making next frequency selection higher. Remember utilisation does not equal load. The equation of calculating load is util / max capacity of a CPU (which should be 1024). So 512 / 1024 = 0.5 (50% load).
UTIL BOOST IS NOT MEANT TO BE USED WITH SCHEDTUNE.BOOST AT THE SAME TIME! EITHER USE ONE OR THE OTHER OR ELSE PERFORMANCE WILL BE OVERKILL AND BATTERY LIFE WILL DRAIN MUCH FASTER!!!
Util boost is supposed to be a replacement of schedtune.boost. schedtune.boost applies boosting to both clusters, whereas util boost allows boosting per-cluster so users can have much more control.
how to gather logs:
There are several apps that can do this process for you, Here is one: PlayStore: SysLog
And here is another: PlayStore: Andy Log (ROOT)
ramopps: is an oops/panic logger that writes its logs to RAM before the system
crashes. It works by logging oopses and panics in a circular buffer. Ramoops
needs a system with persistent RAM so that the content of that area can
survive after a restart.
logcat: the logoutput of the Android system
kernel log: (kmsg / dmesg): the kernel messages
Additionally there's the last_kmsg which is a dump of the kernel log until the last shutdown.
radio log: the log outpur ot your System / BB / RIL communication
4
ramopps:Some Documentation on Ramopps
Normal Logcat:
Radio Logcat:
Ramoops:
Via adb:
adb shell su -c cat /sys/fs/pstore/console-ramoops > kmsg.txt
Via terminal on phone:
su
cat /sys/fs/pstore/console-ramoops > /sdcard/kmsg.txt
Kernel Log:
Kernel Log:
adb shell su -c dmesg > dmesg.log
Last_Kmsg:NOTE:
New location of last_kmsg on Android 6.0 and above: /sys/fs/pstore/console-ramoops
adb shell su -c "cat /proc/last_kmsg" > last_kmsg.log
NOTES:
-v time will include timestamps in the logcats
-d will export the complete log.
If you want to save a continuous log you can remove the -d parameter - then you need to cancel the logging process via CTRL+C.
To export a continuous kernel log use adb shell su -c "cat /proc/kmsg" > dmesg.log (and cancel it via CTRL+C again).
PS: This Document was taked from another XDA Thread Called: [Reference] How to get useful logs
URL: http://forum.xda-developers.com/showthread.php?t=2185929
Also check this one out: [Tutorial] How To Logcat
I only Revived it a bit for ramopps.
I will update this more at a later time..
Excellent work my friend thanks for supporting the Pixel XL I hope you get lots of joy from your new hobby!
Will flash in the morning and see how it goes...
Most of those audio patches you backported seem to be interesting, specially the ones that are meant to reduce power comsumption. Will pick. Suggestion, you don't need to specify the slot in the fastboot command, just fastboot flash kernel kernel_binary
can you disable storage force-encryption？thanks！
Sent from my Pixel XL using XDA Labs
Are the safetynet patches implemented by any chance?
franciscofranco said:
Most of those audio patches you backported seem to be interesting, specially the ones that are meant to reduce power comsumption. Will pick. Suggestion, you don't need to specify the slot in the fastboot command, just fastboot flash kernel kernel_binary
Click to expand...
Click to collapse
When I did only fastboot flash, I ended up twice with a system that somehow didn’t know which boot slot to boot to.
Each reboot it would boot into the different boot slot. The only thing that resolved this was to flash the factory image from google.
Even specifying the boot slot via fastboot did not alter this behaviour.
Somewhere in the q & a section someone is describing the problem too. It occured the first time after using fastboot flash kernel command.
almightysiman said:
can you disable storage force-encryption？thanks！
Click to expand...
Click to collapse
I will look into it.
ghostENVY said:
Are the safetynet patches implemented by any chance?
Click to expand...
Click to collapse
No I didn’t implement them yet. I will look into it.
Let us know when you'll have a flashable zip for this! Sounds good!
Thanks for another kernel option!
Sent from my Pixel XL using XDA Labs
Freak07 said:
When I did only fastboot flash, I ended up twice with a system that somehow didn’t know which boot slot to boot to.
Each reboot it would boot into the different boot slot. The only thing that resolved this was to flash the factory image from google.
Even specifying the boot slot via fastboot did not alter this behaviour.
Somewhere in the q & a section someone is describing the problem too. It occured the first time after using fastboot flash kernel command.
Click to expand...
Click to collapse
Well, I've been using that command since day 1. I've flashed countless times, it never failed to boot once...
franciscofranco said:
Well, I've been using that command since day 1. I've flashed countless times, it never failed to boot once...
Click to expand...
Click to collapse
are you running stock rom? I believe you, if you say, you never had issues.
I ran into the issue I described earlier. It would Change Slots upon each reboot and nothing except flashing back stock Google Image fixes it.
new kernel 0.2 is available
I added safetynet patch and another commit that may help with Performance
Download is here or in the OP
https://www.androidfilehost.com/?fid=529152257862702410
It's great to see development for our beloved Pixel XL! I'll be checking this out. I thank you friend!
Freak07 said:
It also includes a few Audio Patches from CAF.
Click to expand...
Click to collapse
Anything related to aptX Bluetooth?
CZ Eddie said:
Anything related to aptX Bluetooth?
Click to expand...
Click to collapse
Don’t know. What are you searching for exactly?
Hey
I updated the kernel to 0.3
Main changes are:
- Add GPU OC to 652mhz like the performance edition of our soc
- Update wake gestures
- Many new Performance Patches
- Updated dm verity
Download is here:
https://www.androidfilehost.com/?fid=745425885120707916
Lots of sweet features and commits. Definitely keeping my eye on this kernel. :good:
Can you make it TWRP flashable please?
Sent from my Pixel XL using XDA Labs
This thread is all about kernel things. I will be trying to provide a brief explanation regarding most of the features & options available in custom kernels. There are two custom kernel which are maintained for our device.
Disclaimer: I in no way claiming that information available in this thread is 100% correct.
Brief History about these custom kernels.
1. Chimera Kernel by rupanshji
This is a custom kernel based on Nichcream & Team Reloaded’s kernel source code with features added by the developer. This kernel has spectrum support. Talking about updates, Chimera is not updated frequently.
Source Code | Thread
Download link: Google Drive | Older Builds
2. Jasper Kernel by Pawan.S 5277!
This is a custom kernel based on msm-3.18 kernel source code with features and patches added by the developer. Jasper is updated whenever a new CAF tag is available (as mentioned in OP & what I have noticed).
Source Code | Thread
Download link: AndroidFileHost | MediaFire
3. Spicy Kernel by DyWN
Temporarily discontinued.
Kernel Managers
EX Kernel Manager
Kernel Auditor
Features and Options available in at-least one of the custom kernels mentioned above are mentioned below along with a brief description about them.
GOVERNORS
1. Alucard: This govenor is based on ondemand but has been heavily tweaked to bring better battery life and performance. It has been known to be battery friendly without sacrificing much performance.
2. Blu_active: A governor developed by eng.stk (featured in his Code_Blue kernels) based on interactive with upstream caf patches and ondemand governor bits too. This governor is mainly focused on performance like the other things the developer creates but it is also well balanced for gaming and general usage.
3. Clarity: Basically this from interactive CAF with additional tunables and tweaks. such as: Remove boost functional - Limit max frequency when screen off. Using relation CPU frequency Current (C) (Low power as possible). - additional down load tunable.
4. Conservative: This governor biases the phone to prefer the lowest possible clock-speed as often as possible. In other words, a larger and more persistent load must be placed on the CPU before the conservative governor will be prompted to raise the CPU clockspeed. Depending on how the developer has implemented this governor, and the minimum clockspeed chosen by the user, the conservative governor can introduce choppy performance. On the other hand, it can be good for battery life.
The Conservative Governor is also frequently described as a "slow OnDemand". The original and unmodified conservative is slow and inefficient. Newer and modified versions of conservative (from some kernels) are much more responsive and are better all around for almost any use.
5. Darkness: It's based on nightmare but more simple and fast, basic configs but very complex structure. It is an updated nightmare gov and improved stability, so far it is quite stable in tests.
6. Electron: This is a governor based on interactive from the latest MSM8994 CAF branch with more upstream improvements, powersave bias, screen off max frequency, and some other tweaks to improve battery life without hindering performance.
7. Interactive: This governor scales the clockspeed over the course of a timer set by the kernel developer (or user). In other words, if an application demands a ramp to maximum clockspeed (by placing 100% load on the CPU), a user can execute another task before the governor starts reducing CPU frequency. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. It is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency.
Interactive also makes the assumption that a user turning the screen on will shortly be followed by the user interacting with some application on their device. Because of this, screen on triggers a ramp to maximum clockspeed, followed by the timer behavior described above.
8. Lisi: This governor is less aggressive and works similar to Alessa. This driver adds a dynamic cpufreq policy governor & designed for latency-sensitive workloads. The governor does a periodic polling and changes frequency based on the CPU utilization.
9. Nightmare: A PegasusQ modified, less aggressive and more stable. A good compromise between performance and battery. In addition to the SoD is a prevention because it usually does not hotplug.
10. Ondemand: This is one of the original and oldest governors available on the linux kernel. When the load placed on your CPU reaches the set threshold, the governor will quickly ramp up to the maximum CPU frequency. It has excellent fluidity because of this high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand was commonly chosen by smartphone manufacturers in the past because it is well-tested and reliable, but it is outdated now and is being replaced by Google's Interactive governor.
11. Performance: The performance governor locks the phone's CPU at maximum frequency.
12. Powersave: The opposite of the Performance governor, the Powersave governor locks the CPU frequency at the lowest frequency set by the user.
13. Schedutil: This is a new EAS governor found in recent versions of the Linux Kernel (4.7+) that aims to integrate better with the Linux Kernel scheduler. It uses the kernel's scheduler to receive CPU utilisation information and make decisions from this input. As a direct result, schedutil can respond to CPU load faster and more accurate than normal governors such as Interactive that rely on timers.
14. Userspace: This governor, exceptionally rare for the world of mobile devices, allows any program executed by the user to set the CPU's operating frequency. This governor is more common amongst servers or desktop PCs where an application (like a power profile app) needs privileges to set the CPU clockspeed.
CPU Scheduler options... Search yourself.
THERMAL
1. Msm thermal is a kernel platform driver which regulates thermal conditions on the device during kernel boot. The goal of MSM_THERMAL is to prevent the temperature of the system from exceeding a thermal limit at which it cannot operate. Examples are CPU junction thermal limit, or POP memory thermal limit. The MSM_THERMAL driver polls the TSENS sensor hardware during boot, and reduces the maximum CPU frequency allowed in steps, to limit power/thermal output when a threshold temperature is crossed. It restores the maximum CPU frequency allowed in the same stepwise fashion when the threshold temperature (with hysteresis gap) is cleared.
2. Core Control Enable / disable throttling, this enables the thermal engine and enable VDD restriction and core throttle.
3. VDD Restriction Limits CPU voltage, limiting it will decrease temperature.
HOTPLUG OPTIONS
1. AiO_hotplug: An all in one HotPlug for Traditional Quad-Core and Hexa/Octa-Core big.LITTLE SoCs.
2. Autosmp: A highly-efficient hotplug driver, works in-sync with the CPU governor to enable off-line cpu cores when the the CPU frequency reaches a high threshold and still more compute power is needed. Therefore, touch boost bloat is removed.
GPU OPTIONS
Min GPU Freq: 216Mhz Max GPU Freq: 500 Mhz
GPU Governor:
1. msm-adreno-tz: The default GPU governor used by Qualcomm for their adreno GPUs. It is based on the ondemand governor but is biased towards performance, therefore it should give better performance in games but less battery life.
2. Performance: As the name suggests, this keeps your GPU running at the max frequency. This is a governor if you want the best possible experience in games but you don't care about your battery life.
3. Powersave: Like the CPU governor, this keeps your GPU running at the lowest possible frequency. Best battery life, extreme lag in games.
4. Simple_ondemand: As the name implies, it is a simpler version of the CPU governor ondemand. simple_ondemand will ramp up the frequency when a load is detected. It has a good balance between performance and battery savings.
Note: There are many other broken GPU Governors. Do not select them. If you are using Chimera, then your device will reboot if you try to select them.
GPU Boost: If you are using msm-adreno-tz governor, then you can configure GPU boost option also. Use ExKM to configure this additional option.
Adreno Idler: It is an idling algorithm, an efficient workaround for msm-adreno-tz's overheads. Main goal is to lower the power consumptions while maintaining high-performance. Since msm-adreno-tz tends to *not* use the lowest frequency even on idle, Adreno idler replaces msm-adreno-tz's algorithm when it comes to calculating idle frequency(mostly by ondemand's method). The higher frequencies are not touched with this algorithm, so high-demanding games will (most likely) not suffer from worsened performance.
COLOR CONTROL
Self-explanatory
SCREEN OPTIONS
Backlight Dimmer: Enable only at night times.
GESTURE OPTIONS
1. DoubleTap2Wake
2. Sweep2Wake
3. Sweep2Sleep
All of them are self-explanatory
Pro tip: Use KA if using chimera or ExKM if using Jasper to configure gesture options.
GESTURE VIBRATION
You can the intensity of vibration for the gestures.
VOLTAGE
You can decrease or increase the voltage globally or per core by adjusting the values.
Pro tip: Just don’t play with this unless you’re pro. AFAIK, both custom kernels have under-voltage values according to CPU cluster so doing further can for sure cause in-stability issues.
SOUND
You can decrease or increase the headphone digital gain, mic gain or speaker gain by configuring settings under sound tab.
MEMORY
Low Memory Killer: is a process killer, which is designed to work in cooperation with the Android Framework. Each process is assigned a special value by the Framework when started, the oom_adj value(oom_score_adj on newer kernels). This value defines how important the process is for the system(its priority), and thus how easily it can be killed. Values vary between -17 and +15(0 to 1000 for oom_score_adj). Higher values are given to less important processes which are killed first. Moreover, LMK defines 5 different categories for processes, each one containing processes with oom_adj/oom_score_adj in a specific range of values:
1. Foreground Applications: The application currently shown on the screen and running.
2. Visible Applications Applications that might not be shown on the screen currently, but are still running. They might be hidden behind an overlay or have a transparent window.
3. Secondary Server Services running in the background and needed for Apps to function properly. This category includes Google Play Services for example.
4. Hidden Applications Applications that are hidden from the user, but are running in the background.
5. Content Providers These are the services providing content to the system like contacts provider, location provider etc.
6. Empty Applications This category contains Applications that the user exited, but Android still keeps in RAM. They do not steal any CPU time or cause any power drain.
ZRAM OPTIONS
zRAM is just compressed RAM space. So you can store more in RAM by compressing the data you can fit more data inside your RAM.
Now obviously it is slower than actual normal RAM (since you have to encrypt and decrypt the data), but apparently it still is faster than using swap (which is in your internal memory rather than RAM). The principle works based on that Android prefers to keep data stored as much as possible in RAM to keep recently used apps running quickly. The more you use an app the more priority it has, therefore will stay in normal RAM, things you use sometimes but not very often are kept in zRAM (regardless of how full your actual RAM is), but since you don't use this very often you don't notice the performance hiccup of decrypting that data.
Then last case scenario things you barely use are kept in swap.
For you IT enthusiasts you should have realised already that "z" is the technology prefix for Compression. So it shouldn't come as a surprise that zRAM is compressed RAM.
zRAM Size: 1 GiB is a fairly balanced amount. According to Google, it is useful even on devices with 4 GB of ram because it helps reduce page cache
thrashing, or constant unloading and reloading of cached pages from disk.
zRAM Compression: lzo or lz4
VIRTUAL MEMORY OPTIONS
Dirty Ratio & Dirty Background Ratio: Most people say that these need to be high, so that more stuff is stored in Cache. This will make your phone quick. Because cache is quick. But in reality this is only good advice if all you need to load on your phone is the system UI. Because as soon as you start loading different apps this cache fills quickly, and whenever you want to open an app/file/webpage that is not in cache, your CPU is tasked with both emptying whatever is filling up cache memory and load your new app into cache. Thus making multitasking a nightmare within the first day. A simple reboot of the phone is not enough, nor is clearing RAM (Note: Cache is not RAM).
Overcommit Ratio: While increasing allows more multitasking, I recommend leaving this at 0. It keeps RAM from completely filling up, thus avoiding "app xxx not responding" issues.
I/O OPTIONS
I/O Scheduler:
1. BFQ: Instead of time slices allocation by CFQ, BFQ assigns budgets. Disk is granted to an active process until it's budget (number of sectors) expires. BFQ assigns high budgets to non-read tasks. Budget assigned to a process varies over time as a function of it's behavior.
2. CFQ: This scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. Each per-process queue contains synchronous requests from processes. Time slice allocated for each queue depends on the priority of the 'parent' process. V2 of CFQ has some fixes which solves process' i/o starvation and some small backward seeks in the hope of improving responsiveness.
3. Deadline: The goal of the Deadline scheduler is to attempt to guarantee a start service time for a request. It does that by imposing a deadline on all I/O operations to prevent starvation of requests. It also maintains two deadline queues, in addition to the sorted queues (both read and write). Deadline queues are basically sorted by their deadline (the expiration time), while the sorted queues are sorted by the sector number.
4. Fiops: This new I/O scheduler is designed around the following assumptions about Flash-based storage devices: no I/O seek time, read and write I/O cost is usually different from rotating media, time to make a request depends upon the request size, and high through-put and higher IOPS with low-latency. FIOPS (Fair IOPS) I/O scheduler tries to fix the gaps in CFQ. It's IOPS based, so it only targets for drive without I/O seek. It's quite similar like CFQ, but the dispatch decision is made according to IOPS instead of slice.
5. Noop: Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.
6. Maple: Maple is based on the Zen and Simple I/O schedulers. It uses ZEN's first-come-first-serve style algorithm with separate read/write requests and improved former/latter request handling from SIO. Maple is biased towards handling asynchronous requests before synchronous, and read requests before write. While this can have negative aspects on write intensive tasks like file copying, it slightly improves UI responsiveness. When the device is asleep, maple increases the expiry time of requests so that it can handle them more slowly, causing less overhead.
7. Sio: Simple I/O aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority queue concepts, but only basic merging. SIO is a mix between Noop & deadline. No reordering or sorting of requests.
8. Zen: It is based on the Noop, Deadline and SIO I/O schedulers. It's an FCFS (First come, first serve) based algorithm, but it's not strictly FIFO. ZEN does not do any sorting. It uses deadlines for fairness, and treats synchronous requests with priority over asynchronous ones. Other than that, it's pretty much the same as Noop blended with VR features.
More info can be found here.
MISCELLANEOUS
TCP Congestion algorithm: Available choices are bic, cubic, lp, reno & westwood.
More info can be found here.
My recommendation: Try both custom kernel for atleast two days and then decide which suits your need. And use ExKM to configure Jasper as some of the options available in that kernel are not available in KA.
References: Source 1 | Source 2 | Source 3
Reserved
Thnx its very usefull to know about the governers
Nois tutorial!
Just a correction. You can use exKernel manager with chimera. I recommend KA to prevent piracy. Most of the peeps pirate exkernel manager usually.
rupanshji said:
Nois tutorial!
Just a correction. You can use exKernel manager with chimera. I recommend KA to prevent piracy. Most of the peeps pirate exkernel manager usually.
Click to expand...
Click to collapse
I mentioned KA for Chimera because when i tried this kernel, Wake gestures were working better with KA and not EX Kernel Manager.
If you want, I can amend OP according to your preference.
Nice good topic, thanks