OK, I figure it's time to start providing my kernels to the general public.
This should be compatible with most stock-derived Gingerbread firmwares. It is NOT compatible with CM7/MIUI or any other AOSP-derived firmware. It is NOT compatible with ICS and WILL NOT BE until ICS kernel source for the I9100 is released. At that point a new thread will be created for those kernels. I am testing it currently with self-deodexed/debloated/Hellraised XWKL1.
This kernel series is intended to be similar in spirit to my Daily Driver series for the Infuse at http://forum.xda-developers.com/showthread.php?t=1212795
It is built from sources at https://github.com/Entropy512/linux_kernel_sgh-i777/commits/master, and initramfs at https://github.com/Entropy512/initramfs_sgh-i777/commits/master
My general goals are to focus on stability and battery life. If it comes to a tradeoff between performance and the above two, I will choose stability/battery life. In general I will choose stability first, with the exception of undervolting.
Current features:
codeworkx's cpuidle patch - should improve battery life a bit. In most cases it will likely not improve things much, but in rare cases it will result in significant improvements. (I only have one partially-reproducible test case on the Infuse so far)
JHash 3
BFQ I/O scheduler
CIFS module in initramfs
CWM 5.0.2.8 pulled from latest CM7 source tree as of 2/28/2012
"insecure" kernel (meaning root in ADB)
CPU governor set to Conservative by default to conserve some battery - this will make your device slightly less responsive, use SetCPU or a similar app to return to ondemand if you want it, or reduce the conservative polling interval
Filesystem readahead tweaks in initramfs
netarchy's Sleep of Death fix
netarchy's conservative governor tuning patch - should improve responsiveness of devices when using the conservative governor if you reduce the polling interval (misnamed as sample_rate) - the I9100 community calls this "lionheart" even though it's really only a 2-line patch
Battery charge current monitoring (CurrentWidget) support - only reports charge current and not discharge, and reports a value 2.85 times the actual current. Use CurrentWidget's "operation on value" to divide by 2.85.
Miscellaneous bugfixes pulled from Ninphetamine and CM7 sources - see github for details
/system/etc/init.d support in initramfs - Note that this only runs stuff in /system/etc/init.d - ROM developers or you need to create it. Attached is an example script that will change the CPU frequency governor to ondemand if placed in /system/etc/init.d and set to executable
Four "use at your own risk" features that trade performance for stability - See Post #4 for details
Standard bootanimation support
/proc/last_kmsg crash debugging support
NFS modules in initramfs - note that they must be insmodded in a specific order: sunrpc.ko, lockd.ko, then nfs.ko
Fix for fuel_alerted perma-wakelocks
Fix for wifi tethering on I9100 ROMs that have been Hellraised
Bump up TCP buffer sizes in initramfs to match that of the Infuse - may help network performance in some cases
cpuidle driver from Tab 7 Plus kernel - allows entry into AFTR more often
Support Bluetooth HID on newer firmware bases
3-step GPU clock/voltage control
Extended hotplug tuning
Support for Xan's ExTweaks universal tuning app - https://market.android.com/details?id=com.darekxan.extweaks.app
Planned features, short term:
Pull in some improvements from myfluxi and arighi's trees
Planned features, mid-term:
????
Planned features, long-term:
Improved battery charge algorithm for faster charging - Initial research indicates we have an alternate battery charger chip (MAX8922) that differs from the MAX8997 used in the I9100. We DO have an 8997 also - but on our device for some reason Samsung decided to use an alternate chip instead of using the 8997's built-in charging. This means we have far fewer options (90,400,660 mA) in terms of charge rates compared to the I9100 (from 200 to 950 in 50 mA steps). So we might not be able to implement any fancy charging algorithms.
Features not planned:
BFS process scheduler - I have only once ever seen a test case where this clearly outperformed the mainline Linux scheduler (multithread x264 encoding) - The mainline schedule was fixed in the next release and BFS now has no performance benefits
Any feature that trades off stability or data integrity for performance unless it can be disabled entirely and defaulted to "off"
Any feature that cannot have functionality tested without a paid app. Interface-only checks don't cut it - I don't want users complaining that the app they paid for didn't work because an interface check worked but function didn't
Touch recovery - too prone to accidental user errors - Maybe I will revisit when ICS hits.
Known issues:
Power management regression somewhere between 12/8/11 and 1/2/12 - Intermittent high drain without high AOS or reduced deep sleep percentage when on some wifi networks - seems more likely if GPS is used when connected to wifi. Wifi with high AOS/reduced deep sleep is not a kernel problem. This appears to only happen on some firmwares - it happens on XXKI3 but not XWKL1. It is likely connected to a wifi power management bug in some firmwares. A debugging feature in 2/7 and later will allow identification of such firmwares - see http://forum.xda-developers.com/showpost.php?p=22581928&postcount=1777 for details
Some people have reported touchkey lights becoming disabled until the screen is turned off and back on again. Under investigation - seems to mainly happen on firmwares with BLN-modded liblights even if the BLN app isn't used
Internal and External SD card are swapped in CWM currently
Basic flashing instructions for .tar releases (NOTE - There are currently no releases in this category. These instructions only remain for heimdall+ZIP users:
(Tested on Linux, not tested MacOS/Windows but should work) Heimdall - Extract the contents of the tar file, enter download mode, and flash with the following command line:
Code:
heimdall flash --kernel zImage
Flashing instructions for .zip releases:
Flash in CWM, or extract the zImage and use the Heimdall instructions above.
Please do not ask how to enter download mode or install Heimdall/Odin in this thread - these are basic generic skills anyone flashing custom firmwares on Samsung devices should know and plenty of documentation exists elsewhere. If you really need to ask, use the General forum, or if created, the Q&A forum. I want to try to keep this thread clean and only with bug reports and issues specific to this release, not general HOWTO or troubleshooting posts. Some of the information you need is in jivy26's FAQs thread at http://forum.xda-developers.com/showthread.php?t=1288112 - Reading at least the first post of this thread in its entirety is STRONGLY recommended.
Bug reports:
If you have a crash (reboot all the way to Galaxy S I9100 screen), use ADB dump the contents of /proc/last_kmsg and post
If you have oddball behavior, include a clearly reproducible test case with your report, or use ADB to obtain a dmesg and logcat capturing the odd behavior at the time of error.
Similar to flashing - using ADB and obtaining last_kmsg, dmesg, and logcat dumps are basic skills that anyone working with custom firmwares on Android devices should have. If you need help with these, do some searching, or post in the General forum or, if created, Q&A forum.
Firmware ("ROM") Developers:
While I cannot restrict anyone from putting this kernel into a ROM as long as links are given to the github sources for GPL compliance, I request that anyone who includes this kernel in a firmware release does the following out of courtesy:
Link to this thread
Clearly indicate in your firmware changelog which Daily Driver kernel release is included in your firmware release whenever you change DD releases - this lets users identify whether a fix is present in the kernel they're using or not
Kernel Developers:
Similar to my request for ROM developers, while I can't restrict you from doing anything, I ask as a courtesy that if you cherry-pick my commits, you do the following:
Please don't rebase my commits into a large multi-feature without consulting me - rebasing related bugfixes together is OK.
Please try not to implement lots of unrelated features or bugfixes in a single git commit - it makes it hard to reimplement that when Samsung drops new sources or releases a new device
ALL OF MY RELEASES ARE NAMED BY RELEASE DATE - MMDDYYYY. See the changelog for differences between Experimental (exp) and non-exp versions for days where dual releases are made.
Change Log
3/7/2012 Release:
Default GPU voltages were slightly too high (but not dangerously so) due to misreading some #ifdefs. Adjusted them downwards.
03/05/2012 Release:
3-step GPU voltage control (thanks to gokhanmoral of SiyahKernel)
Extended CPU hotplug tunables (also thanks to gokhanmoral of SiyahKernel) - I didn't bother with Tegrak Second Core support as it offers nothing these tunables don't offer that makes sense
Preliminary support for Xan's ExTweaks tuning app - https://market.android.com/details?id=com.darekxan.extweaks.app (Yes, it currently says SiyahKernel only, but I added support) - use this to tweak the new features
03/04/2012 Release B:
Add GPU voltage control in addition to existing clock control - see http://forum.xda-developers.com/showpost.php?p=23260574&postcount=64 for more
Reduce default sampling_rate of conservative governor from 100ms to 50ms - conservative uses deferred ticks that shouldn't impact cpuidle
03/04/2012 Release:
Readd https://github.com/Entropy512/linux_kernel_sgh-i777/commit/0746aeb285341896877a3adddd79bdaa0cf4a6f6 (disable second core when screen is off)
03/03/2012 Release B:
Readd a couple of cpuidle register restore/saves that were removed by Samsung between the I9100 and Tab 7 Plus sources - Small chance this might be where the SoDs come from.
03/03/2012 Release:
Readd https://github.com/Entropy512/linux_kernel_sgh-i777/commit/373425c3130fbbb67cdae74793bd3df363a5dc04
Remove powersave governor - it's a guaranteed SoD if used and the same results (without SoD) can be achieved by setting conservative with min=max=200 MHz
03/02/2012 Release:
Revert https://github.com/Entropy512/linux_kernel_sgh-i777/commit/3954900055afe0d22a7ce71b50e4a5cb439c24bf - It turns out it's not actually in the mainline tree, and it has had questionable results from users. It may have caused power regressions for shoman94
Readd https://github.com/Entropy512/linux_kernel_sgh-i777/commit/ec9e34085c2e1284b3e30926862161fa63d498ea - Should improve performance a little on devices with "small" memory (compared to PCs, 1GB is "small")
02/28/2012 Release:
Revert https://github.com/Entropy512/linux_kernel_sgh-i777/commit/634b73c2d0b7e156b5c1626fd268662fcaa5fabe again - It was causing severe performance regressions for red5, and was clearly narrowed down to a single patch (red5 swapped between 18B and 26 multiple times, these are adjacent releases that differ by only one patch.)
Readd https://github.com/Entropy512/linux_kernel_sgh-i777/commit/9c10cd423cdcb0039c5f7730076d1f8db9c09442
Reduce minimum polling interval of conservative from 25 msec to 20 msec
Make defaults of conservative governor consistent with battery-optimized tuning - won't affect anyone using SetCPU to tune governors
Initramfs: Clean up cruft that was doing nothing but taking space
Initramfs: Compiled latest CWM 5.0.2.8 from sources - should fix advanced restore
Initramfs: Swap internal/external SD in CWM to be consistent with newer Android standards
02/26/2012 Release:
Readd https://github.com/Entropy512/linux_kernel_sgh-i777/commit/634b73c2d0b7e156b5c1626fd268662fcaa5fabe
02/16/2012 Release B:
PULLED - actual release was identical to 15C due to a mistake in creating the ZIP. - Replaced by 02/18/2012 Release B.
Readd https://github.com/Entropy512/linux_kernel_sgh-i777/commit/3954900055afe0d22a7ce71b50e4a5cb439c24bf (cpuidle: governor: menu: don't use loadavg)
02/16/2012 Release A:
PULLED - actual release was identical to 15C due to a mistake in creating the ZIP. - Replaced by 02/18/2012 Release A. (CWM will report this as 2/17A - ignore this, CPUSpy should report afternoon in 2/18)
Readd https://github.com/Entropy512/linux_kernel_sgh-i777/commit/4d8a7e7834e29cee232d6634454c0c38e9903d49 (Add MSHCI Power Control)
02/15/2012 Release C:
Fixes to multiple drivers that were attempting to lock frequency to certain levels. On an overclock kernel, these were all two frequency steps higher than originally intended:
Application-controlled lock in kernel/power/main.c - Likely this combined with arighi's frequency scaling patch was the cause of most 2/7 stability issues
Camera locking to 1.2 GHz is fixed
Thermal limits (reducing clock frequency while overheating) was broken, should now work properly
02/15/2012 Release B:
Readds the following patches, should be safe:
https://github.com/Entropy512/linux_kernel_sgh-i777/commit/35187426d15d05d465d07b6d743e1eb37c629a24 - small network performance improvement
https://github.com/Entropy512/linux_kernel_sgh-i777/commit/733758d888e4a23d7ae6487de0dbb525e9d7433c - another small network performance improvement
https://github.com/Entropy512/linux_kernel_sgh-i777/commit/325cdbf1b89e7d2138482e76879fabf9a6dac5b7 - Provide a warning when a broken firmware is preventing proper wifi power management
02/15/2012 Release A:
Revert most patches from 1/30 and 2/07 due to stability issues EXCEPT:
BTHID interoperability fix
MFC/new cpuidle interoperability fix
A BCM4330 patch revert (it was a revert to begin with)
There will be a second "B" release containing patches that I think should be safe stability-wise but want to have separated anyway. After that, I will be making releases 1-2 times a day, each with only one new patch. This will allow the offending patches for recently reported stability problems to be identified. As a result, releases will have A/B/C/etc letter codes after the date until I no longer expect multiple releases per day. Until the stability issues are resolved, Experimental releases are suspended.
02/07/2012 Release:
Lock out AFTR during hardware accelerated video playback - should fix issues with hwaccel video that some people had with 1/29 and later
Disables second core when the screen is off (this patch comes from arighi)
A patch from arighi ("smooth scaling") that prevents the performance governor from getting "stuck" at the wrong frequency, and should make ondemand a bit more responsive
Small cpuidle governor fix from mainline
Revert a wifi patch that did nothing at all if you read the code
Print an error in dmesg when suspend handling in the wifi driver is blocked by the system firmware for whatever reason (XXKI3 does this) - System firmwares that do this will make you vulnerable to battery drain on "dirty" networks (ARP spam, broadcast traffic)
Small performance patch by Russell King of ARM (see github for details)
Standard only for now - will release experimental in a day or two
Warning - This doesn't have as much testing as I normally put into a kernel, but I needed to get a cpuidle fix out ASAP in my opinion
1/30/2012 Releases:
Backport Bluetooth HID fixes from Epic 4G Touch EL29 sources - Seems to fix Bluetooth HID on UCKK6, should also fix it on newer I9100 bases
Backport a power management change (MSHCI power control) from E4GT EL29 - Actually, I think this is something that was in the AT&T drop and I9100 Update3 removed
ashmem deadlock fix - might fix nizda1's issue (unknown, I thought I had this in already but I guess I didn't) - found by arighi
Tweak from arighi - set SLUB_MAX_ORDER to 0 since our device doesn't have ginormous amounts of RAM
Increase TCP initial receive and congestion windows - should improve throughput on new TCP connections (such as web page loads)
Remove a small dmesg spam introduced by the cpuidle backport
Add ARM Errata 753970 (bugfix)
1/29/2012 Releases:
Backported cpuidle driver from the Tab 7 Plus - Allows AFTR idle to be entered more often, enables it my default, and permits it to be tracked separately from LPA idle mode.
Reverted some small I9100 changes to GPIO configurations - These changes may do nothing, the functions of these GPIOs are undocumented but appear to be somehow sleep related. See github commit for details
1/24/2012 Releases:
Include tun.ko
The above change is so small I'm removing the 1/23 download
1/23/2012 Releases (Note: Experimental might not actually be posted until 1/24):
Enable building for I9100 targets (source code change only, see github)
Revert some unnecessary patches from arighi's tree, prep for implementing more useful ones
A pile of upstream Linux kernel bugfixes, huge thanks go to myfluxi for finding these and testing them on himself: https://github.com/myfluxi/xxKernel
Bring in two small missing updates from I9100 update3 sources
Enable separate debugging of wake_lock_destroy() to enable diagnosing high deleted_wake_locks time
1/2/2012 Releases:
Road to I9100 Update3: COMPLETE - Video changes, media changes, battery/PMIC changes, Samsung-specific arch/arm changes
Road to I9100 Update3: Revert touchscreen drivers to I777 source codebase. SiyahKernel also did this, it seems to solve the wake lag issues. However those that didn't encounter lag may see reduced responsiveness. There's a possible workaround though.
12/21/2011 Releases:
Road to I9100: USB Host (untested), Touchkey, Broadcom DHD (Bluetooth, WiFi)
Initramfs: Bring in a few updates from UCKK6. Might fix wifi for KK6 people (UCKK6 compatibility UNTESTED.)
12/12/2011 Releases:
Road to I9100: Touchscreen Drivers
Irrelevant Road to I9100: DPRAM, WiMax, staging drivers
12/8/2011 Releases:
Resume dual-release standard (2.6.35.7) and experimental (2.6.35.14) builds - note exp does NOT fix the AOS bug, just hides it - see http://git.kernel.org/?p=linux/kern...it;h=a3fe22ee824895aafdc1b788e19c081a2e6dd9da
Remove some debugging printk()s from the AFTR cpuidle driver for those who enable AFTR deep idle mode (see init.d scripts thread linked below)
More components of I9100 update3 sources - MMC, filesystem, and generic arch/arm changes
Removed filesystem I/O scheduler tweak script from initramfs - this belongs as a separate init.d script. See http://forum.xda-developers.com/showthread.php?t=1378080 for this script's new home along with other scripts
Enable compilation of FUSE module. Combined with an ntfs-3g binary this should allow people who want to mount NTFS drives with OTG cables to do so. I cannot provide any additional support for this though - no OTG cable
12/1/2011 Release:
Disable interactive governor - it was causing kernel panics in LPM (e.g. reboot to normal poweron when power-off charging), too much risk of it causing a panic during normal operation so it's gone
Two small fixes, one to MMC power management and one to cpuidle - see github for details
Per-file fsync disable - see HERE BE DRAGONS post #4 and USE AT YOUR OWN RISK
First step of patching up to Samsung I9100 update3 sources - New sound drivers. Please focus on sound until the next release.
11/23/2011 Release:
BLN from Ninphetamine - WARNING: An active BLN notification WILL drain your battery by holding a wakelock. Also, you need to install a compatible liblights if your ROM doesn't already have it. VillainROM 3.0 has it, I'll try to post a library and installation instructions after the Thanksgiving weekend ends
Permissions changes for /data/misc/wifi that allow tethering settings to persist on Hellraised ROMs (EDIT: Not working for fresh flashes... Maybe not working at all. what the **** is overriding the perms?)
Enabled Interactive governor in defconfig. drowningchild says it's stable - I tend to be paranoid when it comes to governors
11/13/2011 Release:
Upgrade to CWM 5.0.2.7 pulled from Cyanogenmod 7 nightly 12 - adds nandroid backup/restore to external SD - advanced restore from extSD not working yet, also CWM labels external SD as "internal"
11/10/2011 Release:
Removed automatic root injection from the initramfs - It causes too many problems. Flash ChainsDD's Superuser package from CWM instead.
11/03/2011 Release:
Fix for wifi tethering on I9100 ROMs
Bump up TCP buffer sizes in initramfs to match that of the Infuse - may help network performance in some cases
Experimental (2.6.35.14) releases discontinued until further notice - They provided no discernible benefit, and hid the infamous "AOS Bug" making it harder to diagnose. (It did not fix the drain)
10/20/2011 Releases:
Fix for fuel_alerted perma-wakelocks
GPU clock control, same method as Ninphetamine - see Ninphetamine kernel for documentation. Completely untested other than that the default values don't change or break anything. Same rules as for my overclock code... Credit goes to Netarchy for this, it's his git commit 100%
10/16/2011 Releases:
Make root injection script less aggressive
NFS modules in initramfs - note that they must be insmodded in a specific order: sunrpc.ko, lockd.ko, then nfs.ko
Miscellaneous bugfixes, see git
10/13/2011 Releases:
Make root injection script in initramfs less aggressive
10/09/2011 Releases:
Update root injection script to install su-3.0 - Still need work on this to make it more robust when su updates again.
Misc. fixes from codeworkx's CM7 tree and Ninphetamine
Start of Experimental dual-release series - Experimental updates base to 2.6.35.14 using arighi's patches
10/07/2011 Releases: (There were multiple, but as their files are no longer posted I'm merging it into one changelog entry)
Conservative tuning patch no longer considered experimental
/system/etc/init.d support in initramfs
Overclocking/Undervolting implementation by codeworkx - USE AT YOUR OWN RISK. DO NOT REPORT BUGS OR PROBLEMS IF YOU ARE OVERCLOCKING OR UNDERVOLTING. IF YOU EXPERIENCE ANY STABILITY PROBLEMS, DISABLE ALL OC/UV
Standard bootanimation support
10/06/2011 Experimental Release:
netarchy's conservative governor tuning patch - should improve responsiveness of devices when using the conservative governor
10/06/2011 Release:
Automatic root injection in initramfs
Filesystem readahead tweaks in initramfs
netarchy's Sleep of Death fix
Battery charge current monitoring (CurrentWidget) support - only reports charge current and not discharge, and reports a value 2.85 times the actual current. Use CurrentWidget's "operation on value" to divide by 2.85.
Miscellaneous bugfixes pulled from Ninphetamine sources - see github for details
Initial Release: 10/04/2011
codeworkx's cpuidle patch - should improve battery life a bit. In most cases it will likely not improve things much, but in rare cases it will result in significant improvements. (I only have one partially-reproducible test case on the Infuse so far)
JHash 3
BFQ I/O scheduler
CIFS module in initramfs
CWM 5.0.2.3 from Codeworkx's CWM kernel
CPU governor set to Conservative by default to conserve some battery - this will make your device slightly less responsive, use SetCPU or a similar app to return to ondemand if you want it
"Insecure" kernel - ADB sessions ALWAYS have root
Here be dragons
This post is for features present in the kernel that are "use at your own risk" - They have either potential or guaranteed negative side effects if used.
Overclocking (CPU):
Enable using SetCPU or a similar app
USE AT YOUR OWN RISK. DO NOT REPORT BUGS OR PROBLEMS IF YOU ARE OVERCLOCKING OR UNDERVOLTING. IF YOU EXPERIENCE ANY STABILITY PROBLEMS, DISABLE ALL OC/UV
Overclocking (GPU):
See Ninphetamine kernel for documentation - Same control method
USE AT YOUR OWN RISK. DO NOT REPORT BUGS OR PROBLEMS IF YOU ARE OVERCLOCKING. IF YOU EXPERIENCE ANY STABILITY PROBLEMS, DISABLE ALL OC
Per-File fsync() disable:
This allows you to disable per-file write forced syncs. (e.g. if an app tries to force a write straight to disk, it'll just go to cache). This achieves the same goal as the modded sqlite hacks seen in tweaks such as USAS, however it can be disabled at runtime.
WARNING: THIS CAN CAUSE DATA LOSS OR CORRUPTION IN A CRASH
To enable, do the following in a terminal, or add it to an init.d script (look at my ondemand script as an example):
Code:
echo "1" > /sys/module/sync/parameters/fsync_disabled
And to disable (return to the default):
Code:
echo "0" > /sys/module/sync/parameters/fsync_disabled
Good for around 200 points of epeen in the database benchmarks in Antutu or 500-600 points of epeen in Quadrant. Real-world benefit: Probably not worth the data integrity risk, but you've got a choice now.
Backlight Notifications (BLN):
This allows the touchkey backlights to be used for notifications. Some stock apps (such as stock MMS) don't support it. Supposedly services.jar mods can change this.
This WILL drain your battery when a notification is active due to a wakelock that holds deep sleep. Sorry, it's either this or instability for the time being.
In addition to the BLN control app, the ROM needs a modified liblights file for this to work
Attached here - Liblights - both BLN-modified (extracted from VillainROM 3.0) and stock I777
To install, take the file and push it to /system:
Code:
adb remount
adb push <file> /system/lib/hw/lights.SGH-I777.so
adb chmod 644 /system/lib/hw/lights.SGH-I777.so
Then reboot
Note that on a Hellraised ROM, you need to replace SGH-I777 with GT-I9100. This includes manually ported ROMs like Cognition 777
Like my prerooted system image, this file is compressed using 7-Zip to prevent people from trying to flash it with CWM
OK, right now this post only has documentation of one "special but safe" feature:
To enable debugging of high deleted_wake_locks time, I've set this up to allow wake_lock_destroy() to be debugged without enabling DEBUG_WAKE_LOCK (which spams dmesg with a ton of stuff not needed for wake_lock_destroy() debugging). To enable, add 32 to the value of /sys/module/wakelock/parameters/debug_mask - This defaults to 3, so the proper value is 35.
Code:
echo "35" > /sys/module/wakelock/parameters/debug_mask
Return this to 3 to set it back to the default.
With this, you'll see wake_lock_destroy debugging information in your dmesg output. This is only needed if you have very high deleted_wake_locks times.
If we're not rooted(stock) this will give us root? Or just cwm where we can either use superoneclick or your pre rooted kernel?
eep2378 said:
If we're not rooted(stock) this will give us root? Or just cwm where we can either use superoneclick or your pre rooted kernel?
Click to expand...
Click to collapse
If it's in "planned features" - it's not in yet.
However it can be SOCed just like codeworkx's kernel
Works fine, as in I don't notice a huge difference in speed or anything but huge differences after changing kernels shouldn't really happen so I guess that's good.
I flashed your kernel with Odin and I think it went well. Will kernel version in About phone be the same as stock (2.6.35.7)?
Thanks for using the recommended toolchain to compile
all the newer ones seem to cause the SGS2 to get very warm.
shishir95 said:
Works fine, as in I don't notice a huge difference in speed or anything but huge differences after changing kernels shouldn't really happen so I guess that's good.
Click to expand...
Click to collapse
Shouldn't be any difference in speed - might even be slightly slower since I make conservative governor default for battery saving purposes. You can change this with SetCPU.
wonner said:
I flashed your kernel with Odin and I think it went well. Will kernel version in About phone be the same as stock (2.6.35.7)?
Click to expand...
Click to collapse
In About Phone, yes. If you use a more advanced info tool that shows the localversion, the git tag should be appended and the [email protected] build info should be [email protected] I'm going to be adding a CONFIG_LOCALVERSION tag in the future.
I just had my first Sleep of Death and realized I'm missing last_kmsg support. That's on the list for Planned Features, short-term now.
designgears said:
Thanks for using the recommended toolchain to compile
all the newer ones seem to cause the SGS2 to get very warm.
Click to expand...
Click to collapse
Newer ones make the Infuse die a horrible and painful death, if the kernel even compiles, and I want to retain that compatibility for now.
Sorry for my ignorance regarding Samsung Hardware, this is my first device from them.
Is this kernel aimed at CM or any Rom such as Cognition?
Drew
drewdatrip said:
Sorry for my ignorance regarding Samsung Hardware, this is my first device from them.
Is this kernel aimed at CM or any Rom such as Cognition?
Drew
Click to expand...
Click to collapse
Right now, stock-derived ROMs. NOT CM7/MIUI.
Regarding BLN - I am very unhappy to hear it may not be easy/possible to implement this on our phones. It appears that they've got it working on the international galaxy s 2s, do our phones have more in common with the Infuse than with those?
By the way, I almost forgot -- thank you for this! Flashed it with ODIN, no problems at all, and super-one-click-rooted as well. So far so good!
Any chance of adding a date to the thread title do I can know when you've updated and flash it again lol
jivy26 said:
Any chance of adding a date to the thread title do I can know when you've updated and flash it again lol
Click to expand...
Click to collapse
Will do. If you look at my Infuse series, I usually edit the first post with the update, and post to a post within the thread with a list of changes. The post in the thread will cause a bump - but since bumps don't always mean updates this is a good idea.
Initial observation.
With setting i/o to deadline i did not see my phone go into deep sleep much last night.
Today using noop the phone seems to sleem more often
Drew
drewdatrip said:
Initial observation.
With setting i/o to deadline i did not see my phone go into deep sleep much last night.
Today using noop the phone seems to sleem more often
Drew
Click to expand...
Click to collapse
Hmm... Interesting. That might be part of why battery life in CM7 on my Infuse seemed to be less the last time I used it, I never got tweak_scheduler.sh running on that.
Default in this kernel is CFQ, I've added BFQ but I've had bad things happen when it's the default at boot.
Is this a common issue that we're supposed to be having? Sleep of deaths? I haven't gotten any since I started using your kernel.
Related
This is my own personally compiled kernel based on the latest kernel from Cyanogen's Github repository with Kmobs' undervolt modifications, CodeAurora's AVS code, pershoot and rotohammer's audio gain mod and several compiler optimizations based on initial idea from psyq.
Only major releases will be advertised here.
All changes since 05/05 can be found at my Euroskank host:
http://intersectraven.euroskank.com/kernels/
*Thanks to RyanMacG for the free hosting!
Old uploads with minor changes can be found at my MediaFire folder or my Bitpad folder:
http://www.bitpad.co.uk/intersectraven
http://www.mediafire.com/intersectRaven
Major features:
- based on latest Cyanogen Mod kernel source from his GitHub repository
- numerous compiler optimizations with a custom compiler by redstar3894
- all CPU power governors for user dependent tweaking of power saving method
- Hybrid AVS (Adaptive Voltage Scaling combined with Static Voltage Scaling) support for maximum possible power savings dependent on CPU requirements and a customizable version (CAVS) for people who like to tweak how far their N1s can go
- universal update.zip template made by Koush
Instructions:
1.) Reboot to recovery and flash the update.zip directly.
OR
Instructions for zImage and bcm4329.ko driver extracted from the update.zip(from command line):
1.) adb remount
2.) adb push bcm4329.ko /system/lib/modules
3.) adb reboot bootloader
4.) fastboot flash zimage zImage
5.) fastboot reboot
OR
Use ADB GUI by minooch found here:
http://forum.xda-developers.com/showthread.php?t=666964
*please note the instructions...push the wifi driver BEFORE rebooting for flashing zImage...if your wifi is turned on when you reboot before you pushed the wifi driver for the kernel, there is a chance that you will go into a bootloop due to the incompatible wifi driver!
Changelog:
20120108_2143:
- just merged pershoot's commits
20111203_11XX:
- enabled MSM EHCI
20111114_23XX:
- integrated CM's commits (mainly bluetooth and WiFi fixes)
20111111_19XX:
- compiled using updated Mjolnir/Linaro compiler hybrid (having problems with our Mjolnir GCC)
- enabled SYN_COOKIES as requested
- some tweaks to the VFS settings
- switched network scheduler to SFB
- switched TCP congestion to Veno from YeaH (seems it's better for devices with a greater chance of random drops of packets)
20111010_11XX:
- disable CleanCache for YAFFS (too complex to change)
- more proper reapplication of changes from 3.0
20111009_22XX:
- enabled CleanCache for YAFFS, EXT3 and EXT4 (experimental)
20111008_23XX:
- ported BogoMIPS calibration from 3.0
- added CleanCache from 3.0
- switched to SIO from BFQ
- block IO batching from 3.0
- activate_pages batching from 3.0
20110904_07XX:
- added SmartAssV2 CPU governor
20110828_13XX:
- fix AVS to actually work (see previous latest post for apology... )
*this should restore the instability on some devices that can't handle AVS
20110828_00XX:
- prevent excessive suspend attempts
- optimized sha1 implementation
20110813_15XX:
- increased NAND buffer to 8k similar to codeaurora's version
- enabled 8-bit transfers for when the MMC card supports it
20110724_20XX:
- SmartAss improvement from the test kernels
- AVS code improvement also from the test kernels (hopefully improved the stability)
- RCU optimizations
- updated Mjolnir compiler
20110713_10XX:
- re-hauled SmartAss governor:
* interactive threads instead of workqueues to improve responsiveness when ramping-up frequencies
* reduced stepping frequency to use lower frequencies more
20110707_08XX:
- fixed the Voice Search problem
20110706_09XX:
- code cleanup
- additional tweaks
20110628_09XX:
- ARM improvements to memcpy and memmove operations from Wildfire (arco's kernel source)
- cherry-picked serial number commit from CM kernel
20110608_21XX:
- rebased everything together with removal of worthless commits
- added 2 new governors from SavagedZen kernel (SavagedZen & InteractiveX)
- updated code of Smartass governor to the one in SavagedZen since it seems more updated than the one I found
20110527_21XX:
- new method for addressing slow writes on USB from CodeAurora (although it's still slow using native USB mount and I didn't test using another mounter)
- some SIRC potential bug fixes
- input event handling modification from Google
20110523_08XX:
- compiled using updated Mjolnir
20110522_11XX:
- upgraded to v2.6.38.7
20110521_15XX:
- interrupt masking
- smd_tty buffer limit implementation
20110519_22XX:
- fix for potential bug and power leak improvement in DSP driver
- GPIO tweaks
20110516_19XX:
- increased DMA zone to 14MB (may speed some things or may not)
- timer workarounds have been removed as they're unneccessary on Scorpion
- prevent reading from write-only registers (just silly)
- used relaxed access functions for some functions
- remove extra interrupts sent from the SMD channel
20110515_21XX:
- added another commit from android unmerged which implements a watchdog to catch lockups during device resume
- fix for wakelocks which addresses the problem where while being connected to a computer, any attempt to power up will result in display immediately shutting off with touchscreen buttons still on
- uses an updated Mjolnir compiler
20110514_17XX:
- rebased everything
- removed some commits which were useless on the N1
- more zen branches merged
- WiFi-Fast patch has been integrated in all kernels since it seems to have no effect on battery (no more separate WiFi-Fast release)
20110511_22XX:
- reverted a change made to PMEM driver since the commit it was reliant to was reverted (sorry! didn't notice this...I wasn't too critical of my earlier cherry-picks... )
Link to a file which contains all kernels:
http://hotfile.com/dl/117478444/390f688/intersectR_-_20110511_22XX.zip.html
20110510_18XX:
- updated to 2.6.38.6
- committed some more video driver commits from CodeAurora
Link to a file which contains all kernels:
http://hotfile.com/dl/117350839/0a9a504/intersectR_-_20110510_18XX.zip.html
20110509_14XX:
- merged some commits from Android repositories that were still unmerged yet may prove useful for Ashmem and RPC
Link to a file which contains all kernels:
http://hotfile.com/dl/117209820/5b7fe7b/intersectR_-_20110509_14XX.zip.html
20110507_21XX:
- even more improvements from CodeAurora
Link to a file which contains all kernels:
http://hotfile.com/dl/117048553/0831385/intersectR_-_20110507_21XX.zip.html
20110506_15XX-16XX:
- enabled cache error reporting as this is indicative of how tolerant your N1 is to AVS undervolting
- smartass governor (from Temasek)
*this was mistakenly included in the previous release
- a minor kernel scheduling statistic commit
Link to a file which contains all kernels:
http://hotfile.com/dl/116922979/5fb2ec0/intersectR_-_20110506_15XX-16XX.zip.html
20110505_16XX-17XX:
- updated Mjolnir compiler
Link to a file which contains all kernels:
http://hotfile.com/dl/116827854/5839b43/intersectR_-_20110505_16XX-17XX.zip.html
20110505_08XX-09XX:
- AVS and CAVS now both allow changing of voltages on-the-fly. The only difference now is that AVS is undervolted by default while CAVS is undervolted to the same voltages that CM uses in his SVS kernel
- uses eviollet's on-the-fly voltage modification system instead of the previous one I had which is a lot more flexible
Link to a file which contains all kernels:
http://hotfile.com/dl/116798881/0d5b5bf/intersectR_-_20110505_08XX-09XX.zip.html
20110503_09XX:
- updated to version 2.6.38.5
Link to a file which contains all kernels:
http://hotfile.com/dl/116600585/b76a4b6/intersectR_-_20110503_09XX.zip.html
20110502_10XX:
- synced with pershoot's latest modifications which mirror CM's latest addition with regards to USB accessory function (not too important I think since it seems to be for future ADB use)
- uses an updated Mjolnir compiler (20110429)
Link to a file which contains all kernels:
http://hotfile.com/dl/116528049/1865aa6/intersectR_-_20110502_10XX.zip.html
20110424_11XX:
- reverted WiFi driver to same version CM uses for mainline kernel to fix channel 11 issues with the newest one
20110422_12XX:
- updated to 2.6.38.4
- compiler updated
20110421_15XX-16XX:
- first files to be hosted by Bitpad (http://www.bitpad.co.uk/intersectraven/)
*Thanks to MajorProbes
- just a minor release since I only updated the compiler
20110416_20XX:
- several compiler optimizations enabled (loop unrolling, peeling, etc.)
- zen-kernel cherry-picks for memory and fs optimization
20110415_23XX:
- updated to 2.6.38.3
- compiled using latest Mjolnir with an experimental merge by redstar
20110409_23XX:
- integrated a bluetooth fix and MMC quirks improvement from official Google repositories
20110407_13XX-14XX:
- integrate CM commits on futex optimization and removal of dodgy optimizations
20110403_12XX:
- fix for USB transfer speed (should now hold at 1MB/s without dropping)
20110401_22XX-23XX:
- first 2.6.38.2 release based on pershoot's 2.6.38
- added the usual mix (AVS, SLQB, CodeAurora patches, etc.)
- compiled using Mjolnir GCC 4.6.1
- changed FPU optimization to NEON
20110328_08XX-09XX:
- updated to 2.6.37.6
20110328_07XX:
- compiled using Mjolnir GCC4.6.0
- enabled Link Time Optimization and Graphite Optimization (use Google for definitions)
20110326_08XX:
- updated BFQ to v2-r1
20110324_18XX:
- updated to 2.6.37.5
20110320_17XX:
- merged Nick Piggin's RCU patches which were originally for 2.6.38 (one of the things Linux was excited about according to Phoronix)
20110319_09XX:
- merged latest CM kernel commits which enables the ff:
- enabled RCU boost
- enabled touchscreen filter (reduce CPU load made by touchscreen)
20110315_22XX:
- updated to 2.6.37.4
20110312_23XX:
- round 2 of CM's wonk fix attempt integrated
- toolchain update
*for links, go to my MediaFire folder as specified above
20110311_1623:
- integrated cyan's wonk fix attempt
- VPN "fix" (I don't like this one since it's just a backport of the old PPP interfaces)
*for links, go to my MediaFire folder as specified above
20110308_2246:
- updated to .37.3
- based on CM's latest kernel source
- with SLQB and BFQ v2
- regular and customizable AVS
- some CodeAurora patches
*for links, go to my MediaFire folder as specified above
20110213_1506:
- corrected minimum voltage value to 800mV
CFS-HAVS-CM7-NOBOOST -> http://www.mediafire.com/?m32mi1744ksb55m
20110213_1035:
- test release for new AVS-CUSTOMIZEABLE build which allows for runtime customization of AVS minimum and maximum limiters for more flexible AVS voltages depending on your CPU tolerance (/sys/module/avs/parameters/avs_adjust)
- AVS debugging outputs can also be toggled in runtime (/sys/module/avs/parameters/avs_debug -> set to 0 to not display, 1 to display)
CFS-HAVS-CM7-NOBOOST -> http://www.mediafire.com/?bt7mmtlmg407ne1
*format for avs_adjust is:
frequency,minimum voltage,maximum voltage
e.g.
echo 245000,925,975 > avs_adjust
**AVS debugging output will be enabled by default when you modify the limits
Finally created a github to store all of my kernel modifications:
http://github.com/intersectRaven/
To follow me for updates on Twitter:
http://www.twitter.com/intersectRaven
[Kernel] [.35.10, .37] intersectRaven's Kernel (HAVS-AXI-FM-720p-Zen)1/9/2011 10:13
Reserved for intersectRaven - Added 2post to allow OP to have more place for futur update
Finally a thread!
been using your kernels for some time now, good work!
---------------------------------------------------------------
Updates: I thought I'll use this space to provide some info since its right next to the OP
BFS:
BFS is the Brain **** Scheduler. It was designed to be forward looking only,
make the most of lower spec machines, and not scale to massive hardware. ie
it is a desktop orientated scheduler, with extremely low latencies for
excellent interactivity by design rather than "calculated", with rigid
fairness, nice priority distribution and extreme scalability within normal
load levels.
http://ck.kolivas.org/patches/bfs/bfs-faq.txt
CFS
Completely Fair Scheduler is the name of a task scheduler which was merged into the 2.6.23 release of the Linux kernel. It handles CPU resource allocation for executing processes, and aims to maximize overall CPU utilization while maximizing interactive performance.
http://en.wikipedia.org/wiki/Completely_Fair_Scheduler
Comparison of BFS vs CFS: http://www.cs.unm.edu/~eschulte/data/bfs-v-cfs_groves-knockel-schulte.pdf
Conclusion
The results indicate that CFS outperformed BFS with minimizing turnaround time but that BFS
outperformed CFS for minimizing latency. This indicates that BFS is better for interactive tasks
that block on I/O or user input and that CFS is better for batch processing that is CPU bound.
Click to expand...
Click to collapse
can i use this kernel along with the desire camera app?
britoso said:
Finally a thread!
been using your kernels for some time now, good work!
Click to expand...
Click to collapse
Had my dog press the enter key to prevent me from chickening out.
jblazea50 said:
can i use this kernel along with the desire camera app?
Click to expand...
Click to collapse
I haven't tested it so I don't know if it needs something from the kernel to work.
@intersectRaven - in the http://forum.xda-developers.com/showthread.php?p=6003800#post6003800Audio Mod thread rotohammer incorporated settings that increased both the bluetooth and in-call/earpiece volume. is your audio fix for a headset/bluetooth headset and/or does it incorporate higher values for in-call volume as well? thanks!
cortez.i said:
@intersectRaven - in the http://forum.xda-developers.com/showthread.php?p=6003800#post6003800Audio Mod thread rotohammer incorporated settings that increased both the bluetooth and in-call/earpiece volume. is your audio fix for a headset/bluetooth headset and/or does it incorporate higher values for in-call volume as well? thanks!
Click to expand...
Click to collapse
Hmmm...thanks for pointing that out. I'll probably release a new version later which will have this. (loading my Nexus Compilation Environment VM now...)
*Edit: I recompiled with the .min and .max settings he specified but reading further back it seems he changed some other things so I can't be sure if just this will provide the volume increase desired.
cortez.i said:
@intersectRaven - in the http://forum.xda-developers.com/showthread.php?p=6003800#post6003800Audio Mod thread rotohammer incorporated settings that increased both the bluetooth and in-call/earpiece volume. is your audio fix for a headset/bluetooth headset and/or does it incorporate higher values for in-call volume as well? thanks!
Click to expand...
Click to collapse
Hmmm...thanks for pointing that out. I'll probably release a new version later which will have this. (loading my Nexus Compilation Environment VM now...)
*Edit: I recompiled with the .min and .max settings he specified but reading further back it seems he changed some other things so I can't be sure if just this will provide the volume increase desired.
intersectRaven said:
I haven't tested it so I don't know if it needs something from the kernel to work.
Click to expand...
Click to collapse
It works. I thought you incorporated the audio fix yesterday too!
britoso said:
It works. I thought you incorporated the audio fix yesterday too!
Click to expand...
Click to collapse
I just compiled one with higher settings based on rotohammer's research. I think I'll stick with the default ones in my previous version though so its okay to skip this latest one.
For those who wanted to try out the modified values:
http://www.mediafire.com/?dqynw1inh3y <= 2.6.32
http://www.mediafire.com/?mmjwxzjlmmw <= 2.6.33
I'm working on a mod that will allow us to change the min_vol and max_vol from a file. Kernel SOP dictates this not advised, but I don't have time to learn how to implement a procfs hook.
I also used the voltages specified by kmobs so there should be no difference with the voltages. .32 is from the android kernel source while .33 is from cyanogen's. .32 is the stable kernel while .33 is still in its experimental stage.
Thanks a lot I've been looking for something like this!
intersectRaven, any chance to release Overclock kernel ?
1267Mhz on the nexus one will be great. hahahaha
rheza02 said:
intersectRaven, any chance to release Overclock kernel ?
1267Mhz on the nexus one will be great. hahahaha
Click to expand...
Click to collapse
haha...I'll think about it...I don't have the courage to try an OCed version though so you'll have to test it yourself if ever!
intersectRaven said:
I just compiled one with higher settings based on rotohammer's research. I think I'll stick with the default ones in my previous version though so its okay to skip this latest one.
For those who wanted to try out the modified values:
http://www.mediafire.com/?dqynw1inh3y <= 2.6.32
http://www.mediafire.com/?mmjwxzjlmmw <= 2.6.33
Click to expand...
Click to collapse
i'm currently using MoDaCo Alpha 19, which reports using a 2.6.33.1 kernel. so i would use the 2.6.33 version, correct? just to confirm, are your volume values the same as used by rotohammer? also, where is the zImage stored on my device, that is if it's actually saved at all (yes, i am a newbie, lol). thanks!
cortez.i said:
i'm currently using MoDaCo Alpha 19, which reports using a 2.6.33.1 kernel. so i would use the 2.6.33 version, correct? just to confirm, are your volume values the same as used by rotohammer? also, where is the zImage stored on my device, that is if it's actually saved at all (yes, i am a newbie, lol). thanks!
Click to expand...
Click to collapse
yes u would use the .33 if ever...the links u quoted does use rotohammer's values...and lastly, the zimage is flashed onto the image/kernel area in your device's boot partition...oh and no shame being a noob...we were all noobs once...
This kernel crash on my nexus one with desire camera when I try to see a video.
Anyone can confirm this?
www1 said:
This kernel crash on my nexus one with desire camera when I try to see a video.
Anyone can confirm this?
Click to expand...
Click to collapse
I just recorded a video with the desire camera app and played it back fine.
Pushbullet: https://www.pushbullet.com/channel?tag=zen
{
"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"
}
But you say I'm just a friend
Project Background
First of all. I like the nexus 6. Actually, I really really like the nexus 6. I think the device from factory performs quite marvelously, especially since the 5.1 update. Because of this, I am actually pretty content with running the stock kernel. "But BB...What about INTelligentSuperBOOSTXX5MillionPOINT5MegaBlast?!?!?!? Can you add this!?". While I appreciate all the great and free work that several great individuals do for the community. I personally don't see the need to alter any of these MSM/Board drivers a whole lot - not on these latest generation of devices. Things run pretty well I think.
"Why don't you just run the stock kernel then you sick low-life waste of space?"
Because, I still think improvements can be made.
I think there's a lot of good intentions out there to make improvements in the kernel-space, BUT:
I've observed a variety of things that were prevalent a couple of years ago and that are still prevalent today. (1) A lot of small things are changed - and advertised as a huge improvement, (2) some tunables are adjusted and advertised as a huge change/improvement but end up being a regression because they were never tested, or (3) some code is merged that causes regressions and it turns out that self-inflicted bugs are being chased around.
Zen is an attempt at improving the stock kernel. That's it.
Project Summary
The Zen kernel has always been oriented at improving the experience for desktop mobile users as much as possible. This iteration of the series is no different. The goal is simple: Improve the experience.
BFS CPU Scheduler
BFS is an alternative CPU scheduler to the stock kernel's CFS. BFS features a simple single-runqueue O earliest virtual deadline first design. There is no need for excessive balancing to achieve fariness on multiple runqueues - fairness is ensured by deadlines.
The goal of the Brain **** Scheduler, referred to as BFS from here on, is to completely do away with the complex designs of the past for the cpu process scheduler and instead implement one that is very simple in basic design. The main focus of BFS is to achieve excellent desktop interactivity and responsiveness without heuristics and tuning knobs that are difficult to understand, impossible to model and predict the effect of, and when tuned to one workload cause massive detriment to another.
Click to expand...
Click to collapse
BFS is tweaked towards human perception. It is not a real-time scheduler (like the SCHED_DEADLINE policy/scheduling in 3.14+) nor does it use runtimes+red/black trees to figure out fairness. It uses deadlines with the 6ms rr_interval based on the fact that humans cannot detect jitters until >= 7ms.
Anyway, not going to get into it much but you may find more information in post 2, or throughout this thread (I explained a bit more details about it around page 4).
Also, check these out:
BFS FAQ
BFS Wikia
Android/MSM 3.10 BFS Port
What is different about this and the 3.10-ck1 bfs v440 patch available on ck.kolivas.org
Backport fixes and features (not SMT NICE) from up to bfs v460ish
Some of Alfred Chen's upstream synchronization and refactoring of BFS methods (linux-3.18/19-gc branch)
My own syncing with mainline as well as backporting
What does this mean
Suspend/Wake issues that were killer on bfs v440 for 3.10 are not present in this port - these issues have been resolved.
You should NEVER report any issue related to this kernel upstream. Not android, linux, or BFS related. Do not report any issues anywhere but here.
"How about the performance?"
This kernel is all about interactivity by default.
The default rr_interval is set to 6. The logic is the human eye cannot detect jitter until about 7ms. Try lowering it if you want to increase interactivity. Try increasing it to achieve higher thoroughput.
-------------------------
Zen/Shamu Features
BFS CPU Scheduler
@flar2 Wake Gestures
@savoca KCAL Screen Color Control
@imoseyon Vibration SysFS interface
USB Fastcharge Support
Fsync SysFS Interface
Overclocking support
Flar2 userspace CPU voltage control
f2fs support and latest f2fs: f2fs/dev (even with ZenyKernel zip)
FIOPS + BFQ + SIO in addition to the stock ROW, CFQ, Deadline, No-op I/O schedulers
Several misc. CAF/msm + upstream updates/fixes.
Forced encryption disabled. (Even With ZenyKernel zip)
Added init.d support (ZenyKernel is up to your existing ROM/kernel)
selinux adjustments for viper4android and other things (ZenyKernel is up to your existing ROM/kernel)
Compatible with most ROMs, use ZenyKernel zip if there's compatibility issues.
Added zRam support
MPDecision disabled by default, replaced by touchboost listener + ZenDecision 2.0
ZenyKernel based on @osm0sis AnyKernel2 to use for roms who break compatibility with stock ramdisk
I work based on real results from user experience, not numbers. I don't claim anything as a big deal if it isn't one. Zen is a no-nonsense, well-tested kernel making real improvements to interactivity in the kernel space.
---------
Releases
All of these builds are for android 5.1 and above, unless otherwise noted
Wipe /cache before flashing for best results
Versions
- Recovery Zip: Kernel+Ramdisk: Use this on a stock/stock-like rom, or on a rom without support for things like viper4android or init.d support. Flash in recovery.
- Boot.IMG: Kernel+Ramdisk: Same as recovery zip, except in the raw boot.img form. Can be flashed in fastboot, flashify, etc.
- ZenyKernel Zip: Kernel Only (+ no force encryption +f2fs support +zen settings): Will use the exact same ramdisk you already have. If you have issues with the other full versions, then dirty flash your rom and this on top of it.
3.10-zen21 "Cheap and Easy"
Changes:
Compile with GCC 5.1
Several bcmdhd/wifi driver updates
Misc. CAF updates
Fix come cores sticking to performance governor
3.10-zen21 Recovery Zip Download
3.10-zen21 boot.img (install via fastboot/twrp IMG) Download
3.10-zen21 ZenyKernel Zip (Use on top of ROM dirty flash if issues with the above two)
Legacy Releases
3.10-zen20_rev2 "Grad Party"
Changes:
Disable MPDecision by default
ZenDecision 2 - Driver to ensure all cores are online when they are supposed to be online (tunables in /sys/kernel/zen_decision)
TouchBoost generic interface from franco, but modified for globalization
CPU-BOOST: Strip all existing input_boost functionality, use the existing parameters for the new touchboost interface
Slub: Update to newer upstream version of the mem. allocator ported by @XileForce
OC: Add 3.09GHz support (requires v2 of zen_max_freq zip)
msm_hsic wakelock slider...
f2fs: numerous upstream updates
conservative: add franco's twostep counter functionality
conservative: adjust default settings
interactive: adjust default settings
ondemand: Update frequency decision making from upstream
ondemand: Adjust defaults to be less aggressive
BFQ default I/O scheduler - based on significant interactivity improvement benchmarks on solid state and emmc memory.
rev1 fixes issue setting bat_threshold_ignore in ZenDecision
rev2 fixes issues with f2fs
3.10-zen20 Recovery Zip Download
3.10-zen20 boot.img (install via fastboot/twrp IMG) Download
3.10-zen20 ZenyKernel Zip (Use on top of ROM dirty flash if issues with the above two)
3.10-zen19 "Show Stopper"
Changes:
Revert to MPDecision by default. I don't have the time to fully implement a replacement ATM
BFS: Sync try_to_wakeup_* and ttwu_*
BFS: Replace resched_task with resched_curr
BFS: add soft_affined flag
BFS: sync context_switch and finish_task_switch
F2FS: Numerous upstream updates
MSM/KGSL: CAF Fixes/Updates
MSM/MDSS: CAF Fixes/Updates
MSM/mmc: CAF Fixes/Updates
MSM/vidc: CAF Fixes/Updates
MSM/QoS: CAF Fixes/Updates
Misc general upstream updates
Wake Gestures: Disable haptic by default
3.10-zen19 Recovery Zip Download
3.10-zen19 boot.img (install via fastboot/twrp IMG) Download
3.10-zen19 ZenyKernel Zip (Use on top of ROM dirty flash if issues with the above two)
3.10-zen18 "Think Twice"
Changes:
Disable MPDecision by default
Delegate MPDecision's input boosting (raising min_freq) to cpu-boost
Default cpu-boost touch boost set to 2s @ 1.497GHz, configurable in user space
ARM Updates
Some BFS updates
Fair Queue packet scheduler (Queue discipline)
Heavy-Hitter Filter Qdisc
PIE AQM Qdisc
I/O Scheduler: Change default deadline scheduler settings
I/O Scheduler: Add simple I/O scheduler v0.3 (user request - default remains CFQ)
ARM/Crypto: optimized SHA-256/224 (faster encryption performance)
Kcal updates
F2FS updates from upstream
Standard ramdisk support for CM12.1 and friends
The net schedulers are probably useless to the average user, but harmless. A couple people who like to play with network stuff may want to play around with them by using the "tc" command. If you aren't sure you don't need to do anything :silly:
3.10-zen18 Recovery Zip Download
3.10-zen18 boot.img (install via fastboot/twrp IMG) Download
3.10-zen18 ZenyKernel Zip (Use on top of ROM dirty flash if issues with the above two)
3.10-zen17 "Epidemic"
Changes:
Fix GPU frequency displaying low power modes
MDSS/Panel: misc. updates
MM: Misc upstream updates
CPUFreq: General CPUFreq driver updates/fixes
CPUFreq/Interactive: Numerous updates
BCMDHD: Reduce packet timeout, supposed to reduce wlan_rx wakelock
MSM/Power: quickwakeup driver from motorola + implementation
MSM/PM: Replace BUG_ON usage with correct solutions
AnyKernel: Remove device check, some devices that identified as something besides "shamu" had issues flashing.
3.10-zen17 Recovery Zip Download
3.10-zen17 boot.img (install via fastboot/twrp IMG) Download
3.10-zen17 AnyKernel Zip (Use for CM 12.1 or other roms that change ramdisk/sepolicy things)
3.10-zen16 "Yippee Ki-Yay"
Changes:
Revert ext4/3.18 backport which caused periodic lockups.
Merge up ext4 from v3.10.74 in lieu of the above
Add faux sound support
Adaptive LMK default
msm: vid coder possible null pointer fix from CAF
msm: mdss/panel fixes from CAF
kmemleak reporting improvements from upstream
3.10-zen16 Recovery Zip Download
3.10-zen16 boot.img (install via fastboot/twrp IMG) Download
3.10-zen16 AnyKernel Zip (Use for CM 12.1 or other roms that change ramdisk/sepolicy things)
3.10-zen15 "Unbroken"
Changes:
All the great changes of zen14 except without the BFS LLC cpumask selection - was an issue causer
Updated kcal (I forgot to merge into 14)
3.10-zen15 Recovery Zip Download
3.10-zen15 boot.img (install via fastboot/twrp IMG) Download
3.10-zen14 "Flight School"
Changes:
BFS: Full cpumask LLC cpu selection from -gc
BFS: Some trivial cleanups and fixes
Sched/BFS: Brought in the scheduler attr stuff from v3.14
rtmutex: deadlock detect fixes from upstream, prio. boost support for __setscheduler
Everything: Dozens and dozens of relevant i2c/usb/pinctrl/others race condition fixes, memory leak, deadlock fixes, etc. from upstream v3.10.y (without pulling it all I cherry picked relevant stuff)
VMA cache from upstream
ARM fixes from v3.10.y
Asynchronous I/O updates and unnecessary plug I/O removed for SSDs
Just dumped all my KGSL changes and sync'd with newest stuff from leankernel because i was too lazy to bisect and determine what was causing random page faults (they may still be there, they are on stock kernel too)
MSM: Updated sound soc
CM12.1 and friends AnyKernel zip added
3.10-zen14 Recovery Zip Download
3.10-zen14 boot.img (install via fastboot/twrp IMG) Download
3.10-zen14 AnyKernel Zip (Use for CM 12.1 or other roms that change ramdisk/sepolicy things)
3.10-zen12 "On top of the World"
Changes:
BFS: Sync up some tick accounting from upstream
LEDS: Merge in 13 or so patches. Fixes bugs such as concurrency issues as well as adds some features
MDSS: Merge in over a dozen patches, refactorizations, and bug fixes
Crypto: Update NEON/AES module
3.10-zen12 Recovery Zip Download
3.10-zen12 boot.img (install via fastboot/twrp IMG) Download
3.10-zen11 "Too Fast, Too Furious"
Changes:
Fix a bug in modem that I created
BFS: Add grq lock for priodl (alfred chen -gc)
BFS: Fix a potential bug but probably not in __schedule
Proc/MMU: Merged a bug fix and cleanup patchset.
3.10-zen11 Recovery Zip Download
3.10-zen11 boot.img (install via fastboot/twrp IMG) Download
3.10-zen10 "Interstellar"
Changes:
Reverted the red/black tree change to LowMemKiller. I observed some issues with it, perhaps I was missing fixes for it. Certainly the RBTree selection is much faster than the previous iterative method. But how much do we really care about the performance of LMK with 3GB ram?
Upstream CFQ bug fixes
(1) SMP: Added wake_up_all_idle_cpus function
(2) BFS: Added wake_up_if_idle function
(3) CPUIdle: Use wake_up_all_idle_cpus instead of old kick_all method. Should result in reduced cpuidle latency/better performance
Adreno: revert to stock wake-up latency of 490, from 101.
3.10-zen10 Recovery Zip Download
3.10-zen10 boot.img (install via fastboot/twrp IMG) Download
3.10-zen9 "Sunshine and Whiskey"
Changes:
Completely rebased my entire tree. Based on stock/msm tree again.
Pulled in all VM/MM updates from linux-3.10.y
Updated f2fs to latest f2fs/dev.git (Up to "f2fs: do not recover wrong data index")
Fix a KGSL bug that would result in page faults
Updated MSM V4L2 video driver (msm: vidc)
Misc. updates throughout the kernel and MSM to resolve potential memory leaks
Built a new compiler from latest linaro, building with that now instead of my antique one.
3.10-zen9 Recovery Zip Download
3.10-zen9 boot.img (install via fastboot/twrp IMG) Download
3.10-zen8 "Notorious Z"
Changes:
Repair self-inflicted wounds
KGSL+Adreno fixes
Buy food for phil the cat
Buy coffee
Pick up jacket from dry cleaner
3.10-zen8 Recovery Zip Download
3.10-zen8 boot.img (install via fastboot) Download
3.10-zen7 "Space Bound"
Changes:
BFS: fix hotplug bug related to affinity set/get
block: Add FIOPS I/O scheduler
ARM: numerous upstream updates/fixes
MSM: usb/bam numerous fixes
MSM: mdss numerous fixes
MSM: kgsl numerous fixes
MSM: camera numerous fixes
3.10-zen7 Recovery Zip Download
3.10-zen7 boot.img (install via fastboot) Download
3.10-zen6 "Morning After"
Changes:
qcom-cpufreq allow a boot parameter to specify max_freq, which determines how to populate the frequency table. By default it is the stock 2.6GHz. If you use the aroma zip at the end of this post you can choose up to 3.03GHz. This kernel code/method is from @flar2 I only made minor/trivial changes to it and hacked up the aroma so people can change the boot parameter easily..
Changed f2fs mount options again, for more stability
3.10-zen6 Recovery Zip Download
3.10-zen6 boot.img (install via fastboot) Download
3.10-zen5_rev1 "Day Drinking Sunday = Rough Monday"
Changes:
Added kexec-hardboot support for multirom
Adjusted f2fs default mount options (nobarrier on /data) (inline_dentry, extent_cache on /data and /cache). Zen4 f2fs was acting really slow, this fixes it
Build f2fs with security labels for selinux
Added BFQ v7r7
Added 2.95GHz and 3.03GHz overclock steps
BFS: refactor sched_init_smp
BFS: cleanup/remove unused above_background_load function
3.10-zen5 Recovery Zip Download
3.10-zen5 boot.img (install via fastboot) Download
3.10-zen4 "Bottoms Up"
Changes:
Merged v3.10.73 from linux-stable/linux-3.10.y
Overclock to 2.9GHz
Userspace voltage control from flar2
f2fs support and latest f2fs/linux-3.10 merged
ext4 3.18 backport, from ext4/backport-for-3.10
BFS rr_interval set back to default of 6
Several CAF KGSL/MDSS Fixes/Improvements
I/O Deadline some tweaks
3.10-zen4 Recovery Zip Download
3.10-zen4 boot.img (install via fastboot) Download
3.10-zen4 boot.img (use for f2fs, has security labels for selinux - Zen4 forgot to include it)
3.10-zen3 "Walking Tall"
Changes:
Fixed issue with KCAL app caused by zen2 ramdisk changes
Reverted culprits of random OOPs' and PANIC issues
Added vibration sysfs interface (same one as leanKernel)
Support for frequency mitigation (from imoseyon). If you just want to change the battery throttling I suggest you see post #2 instead though
1 misc. change
Internal changes that make me feel good inside
3.10-zen3 Recovery Zip Download
3.10-zen3 boot.img (install via fastboot) Download
3.10-zen2 "Where is the love?"
Changes:
Synced up some ramdisk stuff from imoseyon for other rom/CM compatibility
Added a fix from v3.10.51 to fix random oops' caused by my compiler
3.10-zen2 Recovery Zip Download
3.10-zen2 boot.img (install via fastboot) Download
3.10-zen1 "Dollar Drink Night"
3.10-zen1 Recovery Zip Download
3.10-zen1 boot.img (install via fastboot) Download
ZenDecision (zen20+)
You can still turn on MPDecision without any ill effects if desired
As of 5.1+ MPDecision is somehow responsible for at least the following:
Raise MIN_FREQ to 1497MHz for 3 seconds on touch events
Ensure CPUs come online after certain events, like thermal events (due to low battery for example)
User configurability is sacrificed when it is enabled. For example: changing minimum CPU frequency is not possible, nor is changing the touchboost frequency or duration possible. Simply disabling MPDecision results in the permanent disabling of CPUs in certain situations (until the user either reboots, or manually turns them on again).
ZenDecision is a simple "handler" for to keep CPUs online by the following logic:
When screen comes on, make sure all CPUs are online if current battery level is above bat_threshold_ignore
Simple, not a complete replacement for MPDecision. Just a handler for the event of cores never coming back online. Touchboosting is now configurable through the standard cpu-boost module parameters.
ZenDecision tunables (/sys/kernel/zen_decision/):
enabled (0=disabled, 1=enabled): Enable/Disable the driver from doing any work
wake_wait_time (0-60000 ms, 1000 by default): How long to wait to execute CPU_UP work after screen comes online.
bat_threshold_ignore(1-100, 0=disabled, 15 by default): The battery percentage to ignore CPU_UP operations. If current battery level is below this level, then the driver is essentially disabled.
How to enable overclocking (zen6+)
If your device is unstable at the overclocked frequencies, it is a hardware limitation with your device. Do not report it as a bug
To enable overclocking on zen6 or newer, you will need to use the recovery zip/aroma below.
You choose the max frequency you want, it pulls the boot.img from the device, adds a boot parameter specifying the OC frequency.
If you are not on zen6 or newer it will have no affect.
This does not install a kernel, you still have to install the kernel from one of the links above
Zen Overclock Enable v2
3.09GHz step only supported on zen20+
Thanks guys, and enjoy. Feedback is always appreciated.
XDA:DevDB Information
Zen Kernel, Kernel for the Nexus 6
Contributors
bbedward, purian23
Source Code: https://github.com/bbedward/ZenKernel_Shamu/
Kernel Special Features: Android/MSM BFS Port, kcal, gestures, cool stuff
Version Information
Status: Stable
Current Stable Version: 21
Stable Release Date: 2015-05-20
Created 2015-03-24
Last Updated 2015-05-20
FAQs:
Based on 5.1 Stock Kernel - It should work on all AOSP & CM ROMS
Disabled forced encryption - Meaning if your encrypted you'll stay that way, if you aren't, you'll stay that way
CPU Interactive Governor - Conservative/OnDemand/Userspace/Powersave/Performance Available
CFQ I/O - Deadline/Noop/Bfq/Row/FIOPS Available
Overclocking now available up to 3GHz - Must use Aroma OC Zip above.
F2FS Support - Find out how to enable this here!
KCal Colors by Savoca
Full Wake Gestures by flar2
Double Tap to Wake / Sweep to Sleep / Sweep to Wake
New stock setting - 5.1 throttles at 40% and again at 20% battery life - See the dev's details below on how to change this
@bbedward Regarding 40-20% Battery Throttle
Typically in the old days (which is the last time I was around) this type of thing would be in a cpufreq kernel driver using methods from the battery driver, and possibly allowing configurability through a basic sysfs interface. However, this is not the old days.
I inquired to my good friend imoseyon (I say good friend, he'd probably say "friend? you mean that crazy guy who i talked to once and now he keeps asking if I want to hang out?")
It appears that this battery change goes through the msm_thermal driver through a userspace process. The sad news is that there isn't a way to differentiate between thermal-related calls and these battery-related calls at the kernel level.
BUT,
this specific behavior can be disabled in the userspace (just not in the kernel space) - You will need root access (or you could make this change through twrp)
I will point you to this file (Which you should make a backup of before making any changes to it):
Code:
/system/etc/thermal-engine-shamu.conf
You can either edit it in something like root explorer, or pull it down through adb like this:
Code:
# adb pull /system/etc/thermal-engine-shamu.conf
Open it in your editor of choice (on windows I suggest you use something that supports unix line endings, like notepad++)
Point yourself to BAT-SOC-CPUFREQ near the top of the file
Code:
[BAT-SOC-CPUFREQ]
algo_type monitor
sensor soc
sampling 5000
thresholds 60 80
thresholds_clr 59 79
actions cpu cpu
action_info 2265600 1728000
Interpreting this is pretty straight forward:
- sampling 5000 : I guess how often (probably in ms) that it compares battery % to thresholds and thresholds_clr
- thresholds 60 80: defines two thresholds in which to take actions
- thresholds_clr 59 79: defines two thresholds in which to clear actions
- actions cpu cpu: the action to take (like a method) when thresholds are met
- action_info 2265600 1728000: action parameters that are apparently used to change scaling_max_freq
Read from thresholds down like a column
The bit that tells it to reduce frequency to 2.26Ghz at 40% and back to 2.6 at 41% is this:
Code:
thresholds 60
thresholds_clr 59
actions cpu
action_info 2265600
Where thresholds 60 refers to 40% battery by apparently % discharged (100-60 = 40%). Similarly thresholds_clr 59 (100 - 59 = 41%)
Anyway lets you say you want to throttle to 2.26GHz at 20% and at 21%+ you want to be back to normal scaling_max_freq (2.6Ghz stock) You should change it to look like this:
Code:
[BAT-SOC-CPUFREQ]
algo_type monitor
sensor soc
sampling 5000
thresholds 80
thresholds_clr 79
actions cpu
action_info 2265600
Save the file thermal-engine-shamu.conf and push back to device (or in root explorer you are already there)
Code:
# adb remount rw /system
# adb push thermal-engine-shamu.conf /system/etc/
# adb remount ro /system
Changes will probably take effect after you restart the thermal-engine service (if not, then do a reboot).
Code:
# adb shell stop thermal-engine
# adb shell start thermal-engine
Also notice the exact same applies for GPU frequency throttling and HOTPLUGGING due to battery
On stock 5.1 - Here is everything that happens and can be understood from the default thermal-engine-shamu.conf (related to battery):
CPU is throttled to scaling_max_freq 2.26GHz @ 40% battery
CPU is throttled to scaling_max_freq 1.7GHz @ 20% battery
GPU is throttled to 500MHz @ 45% battery
GPU is throttled to 389MHz @ 10% battery
GPU is throttled to 300MHz @ 5% battery
CPU3 (core #4) is removed (hot-unplugged) @ 15% Battery
CPU2 (Core #3) is removed (hot-unplugged) @ 8% Battery
Hotplug and GPU throttle behavior can be changed in the same thermal-engine-shamu.conf on the subsequent lines. (Exact same logic as described above, but actions/methods are different OFC)
Code:
[BAT-SOC-HOTPLUG]
algo_type monitor
sensor soc
sampling 5000
thresholds 85 92
thresholds_clr 84 91
actions hotplug_3 hotplug_2
action_info 1 1
[BAT-SOC-GPU]
algo_type monitor
sensor soc
sampling 5000
thresholds 55 90 95
thresholds_clr 54 89 94
actions gpu gpu gpu
action_info 500000000 389000000 300000000
So this is actually quite an easy thing to adjust. I know that franco/imoseyon have taken further actions to (and are currently working on):
Prevent this sort of userspace changes from going through msm_thermal driver, by rewriting the driver to only deal with thermal stuff (basically - and probably as it should do to begin with). Apparently this is a little problematic because QC/Moto/Goog have used this driver and its ioctl to funnel other important stuff through (that isn't thermal-related but is still important)
To lock specific msm_thermal userspace processes from making changes to cpufreq
But there are other factors in play there that complicate things.
Disabling the specific behavior of throttling CPU+GPU and disabling hotplugging at certain battery percentages is extremely easy through that configuration file.
Edit: More Knowledge Added - 4/7/15
Each row represents an array essentially, but if you specify something like 3 values for thresholds you need to specify 3 threshold_clr and 3 actions and 3 action parameters.
It's hard for me to say how the thermal engine behaves if you specify something wrong. Ideally you would assume that the parser is smart enough to handle things done incorrectly - and that the service itself is smart enough to have fallback for critical things if they are missing (I don't trust QC enough to assume that's the case), but it's impossible to say without guessing unless we saw the thermal-engine source (this is the service that's in the userspace - not in the kernel). Remember this is a qualcomm piece of software, and because /system is always mounted read-only in android (unless you access it with root access or through a custom recovery) they possibly didn't spend a lot of time working out error handling with respect to user error - because it's not something a user would ordinarily change.
Other Stuff:
Moto is cheap: (and so is everyone else). When it comes to a power supply there's more to it than just a battery - there's regulators, surge-protecting capacitors, protecting diodes, current sensors, etc. Each component in the device doesn't care about these things - they just draw a certain current. The cheapness comes in to play in that Motorola or any manufacturer is not going to bother building a power supply that's more than needed. In the case of the nexus 6 it appears that what they have is "just enough"
Battery efficiency degrades as it discharges. This certainly varies from battery to battery, but the faster the battery is discharging - the less ability it has to provide the required charge to power the device
Recall that there was a huge slurry of random reboot issues reported after the Nexus 6 launch. Something that occured apparently entirely at random, that didn't result from any sort of kernel panic - apparently simply the battery couldn't supply current demanded, so some current-limiting protection or a diode went into reverse bias and just cut the power (I can't say exactly because I didn't design the device).
The issue of unexplained random-rebooting seems to be almost entirely resolved in 5.1. The likely reason: the addition to the thermal-config-shamu file that restricts the maximum frequency, at 40% battery, to ~2.2GHz.
In short, it doesn't matter where you change this behavior. Changing the configuration file that directly communicates to the kernel ioctl is just as good as any kernel solution. The problem with a kernel solution is it goes through the same userspace process as thermal-related throttling. There are ways to block it in the kernel, but it is not configurable and not adjustable. It's more of an on/off type of thing.
Every device is different (different manufacturing tolerances). The majority of users probably had no issues with reboots or supply issues when they didn't have any throttling (until ~20%) on 5.0. But for the ones that did the only thing they could be told was to RMA their device.
I personally think google did the throttle at 40% to make up for a crummy power supply, rather than to gain an extra few minutes of battery life.
Also, there is no active hotplugging on 5.1 (Except for at something like 15% battery and while the device is sleeping - but not ACTIVE hotplugging). This could also be part of the reason why they added the 40% throttle, because when the cores are online all the time there's going to be more active draw from the power supply.
Interested in building ZenKernel?
Using GIT Differently
You don't need permission to fork, build, modify zen. Nor do you need permission to bundle it in your rom.
BUT, there has been some confusion in the way I handle my git tree I thought I would help explain here.
I handle all of my kernel-related GIT affairs very differently from anybody else you've seen, probably:
Everything is based off of stock msm/android-msm-shamu-3.10-lollipop-mr1 (Or newer revs as they come available)
When there is a major revision update to the base (android-msm-shamu-3.10-lollipop-mr2 or something), I will avoid rebasing the branch and create a new branch each (so there will be a BFS and a BFS_mr2 or something)
Every change from the stock kernel lives on it's own,independent branch. There's BFS, kcal, fsync, f2fs/ext4_upstream, kexec-hardboot, usb_fastcharge, etc, etc.)
I merge all these independent branches into the master branch, which is how I come up with the "Zen-Kernel" that includes all of them (git merge BFS; git merge kcal; git merge wake_gestures_ex, etc, etc.)
This means forking zen is not traditional, but it's a good thing!
What do I do if I want to pull something from Zen kernel into my tree?:
Add the ZenKernel_Shamu remote to your local tree (git remote add zen https://github.com/bbedward/ZenKernel_Shamu.git)
Fetch the newest zen changes (git fetch zen)
Pull the change you want, for example to pull BFS into your local tree: git pull zen BFS
Whenever you want to pull an update, git fetch zen; git pull zen BFS
These branches are all based on the STOCK msm/android-msm-shamu tree. So if you pull in BFS or kcal you will not get anything new except BFS or kcal. No other unwanted things will be pulled. Some branches depend on each other (ext4_upstream depends on mm_upstream for example), so if you pull in ext4_upstream you will also get the contents of mm_upstream, and so forth.
What do I do if I want to fork the entire zen kernel exactly as it is?
Well you can do it the old way as you always have. But I change some other stuff for internal purposes you may want to change (in the zen branch), such as the ZEN_INFO_SYSFS_INTERFACE is probably irrelevant to you and ZEN_INFO_VERSION_CODE only represents an integer value with the extra version "-zen" statically defined in the Makefile. You may want to change these things or revert them and just append something in the CONFIG_LOCALVERSION such as "-MyKernel_5.1" or something.
Oh my goodness gracious..... Zen Kernel. Oh boy, oh boy......
And we're back!!!
I have an untested bfs port for the msm/3.4 tree as well. It is in process of getting tested on the nexus 5. Anybody interested I will send it to you.
This looks tasty, cant wait to see how it performs!
Sounds like a plan send it much alohas
if @purian23 is contributing, then i have to try out this kernel
simms22 said:
if @purian23 is contributing, then i have to try out this kernel
Click to expand...
Click to collapse
Haha thanks dude, all the credit goes to @bbedward! We've been buddy's since our GNex adventures! I'm doing a little bit of testing here and kept bugging him until he caved to build again lol
Zen Kernel was my favorite kernel on the GNEX. Ah.. The good old days
Ahhh.. BFS.. Reminds me of early kernel flashin days
whojabacod said:
Ahhh.. BFS.. Reminds me of early kernel flashin days
Click to expand...
Click to collapse
Give it a try, interactivity feels very good especially doing things like browsing content heavy desktop websites.
In the old days, and present day with 3.10-ck there seemed to be suspend/wake issues that kept everybody away - probably rightfully so. I'm quite happy with the way this version is working though.
Running g good so far.
bbedward said:
Give it a try, interactivity feels very good especially doing things like browsing content heavy desktop websites.
In the old days, and present day with 3.10-ck there seemed to be suspend/wake issues that kept everybody away - probably rightfully so. I'm quite happy with the way this version is working though.
Click to expand...
Click to collapse
Thanks for bringing this kernel to the Nexus 6, do I need to wipe anything before flashing your kernel? I am on a custom kernel. Thanks
Damon13 said:
Thanks for bringing this kernel to the Nexus 6, do I need to wipe anything before flashing your kernel? I am on a custom kernel. Thanks
Click to expand...
Click to collapse
I flashed without wiping anything. But the dev recommends wiping cache.
pantmunu said:
I flashed without wiping anything. But the dev recommends wiping cache.
Click to expand...
Click to collapse
Thanks i completely missed that, by the way is the kernel running 4 cores like stock. Thanks in advanced
Damon13 said:
Thanks i completely missed that, by the way is the kernel running 4 cores like stock. Thanks in advanced
Click to expand...
Click to collapse
Yes it is.
Gland to see you here I flashed your kernel over benzo rom and got system fc keep popping up any ideas tied to get a log but could not
jaythenut said:
Gland to see you here I flashed your kernel over benzo rom and got system fc keep popping up any ideas tied to get a log but could not
Click to expand...
Click to collapse
Flashed this on terminus. No problem here. Try dirty flashing benzo ..let it reboot and flash the kernel. Might help.
jaythenut said:
Gland to see you here I flashed your kernel over benzo rom and got system fc keep popping up any ideas tied to get a log but could not
Click to expand...
Click to collapse
Stock kernel might not work on cyanogen mod? Maybe it relies on some ramdisk changes I'll have to look into it.
Endurance Kernel • Galaxy Note 9
Endurance Kernel was designed by me with the goal of providing a much more responsive user experience whilst simultaneously conserving the devices battery as much as possible. This kernel is a port of Endurance Kernel, recreated for the Galaxy Note 9. The kernel is largely adjustable in the paid app EX Kernel Manager (EXKM) by flar2 or in the free app MTweaks by Morogoku. Please note, I don't actually own a Note 9!
DISCLAIMER - I am not responsible for any harm that may come to your device as a result of flashing this kernel. I am however happy to provide support if required.
Downloads
1.x.x indicates the kernel should be used with an Oreo based firmware. 2.x.x indicates the kernel should be used with a Pie based firmware.
Latest GitHub Release
MEGA Repository
Key Features
Latest ELS (almost) always merged in
Implemented AndreiLux’s custom scheduling, EAS backports, 16ms PELT half-life, and migration hysteresis filter
Hotplugging enabled
Boeffla wakelock blocker supported (default list tweaked for improved deep sleep)
Support GPU overclocking up to 598MHz on all builds
Adapted notification LED fade support from NX Kernel from the Galaxy S8
Enabled fsync on / off support (on is default and recommended)
DoubleTap2Wake, Sweep2Wake, Sweep2Sleep & RGB colour control
CFQ (stock and kernel default), deadline, noop, FIOPS, SIO, Zen, Maple and BFQ support
Westwood (kernel default), bic (stock), cubic, reno, htcp, lia, veno and olia TCP congestion algorithms enabled
9.0 AOSP support
Several kernel optimizations from Notorious Kernel
WireGuard Support
DriveDroid Support
SELinux set to enforcing
F2FS support
Unofficially supported adjustable SELinux status through the 'Magisk SELinux Manager' module or # setenforce 1 or 0
Disabled irrelevant or unused Samsung security and features
Disabled almost all logging, debugging and tracing
Various patches to improve performance and battery
No bull****!
Detailed Overview
The PELT half-life has been reduced from 32ms (stock) to 16ms which greatly improves device responsiveness, alongside the use of updated custom scheduling, both thanks to Andrei Frumusanu’s amazing work on the kernel. For a more up to date reference on the performance of the Exynos 9810, look at Andrei's investigation comparing the Exynos Note 9 to the Snapdragon Note 9.
This kernel supports overclocking. In order to use overclocking, simply flash the OC zip from the Android File Host folder.
The overclock build will now use big cluster (M3) quad / triple frequencies up to 2106MHz, dual frequencies up to 2416MHz and single frequencies up to 2964MHz. The small cluster has now also been overclocked to 2002MHz. The overclock build also modifies Andrei's conservative frequencies in order to utilise the higher frequencies more. There is no guarantee that your battery will perform well with overclocking, nor your device will be safe running above stock frequencies. Use at your own risk.
Notification LED fade support has also been added and enabled by default. The fade can be turned on and off and have fade in and out speed adjusted in EXKM or MTweaks. Additionally, in both EXKM and MTweaks such as fsync on / off support, DoubleTap2Wake, Sweep2Wake, Sweep2Sleep & RGB colour control.
This kernel unofficially supports (but I typically strongly advise against the use of) a permissive SELinux status through the 'Magisk SELinux Manager' module.
GSI / AOSP Kernel
The kernel supports 9.0 AOSP GSIs. These builds are entire ports of Endurance Kernel that have been adapted for AOSP, hence any changes that are made to the base kernel will almost always also be included in the AOSP kernels.
If SafetyNet is failing, this can be worked around to allow SafetyNet to pass. You will need the 'MagiskHideProps' module installed. After rebooting, using a Terminal Emulator app enter the following commands in the order listed without quotation marks.
Type 'su'
Type 'props'
Type '1' to edit the device fingerprint
Type 'f'
Type '13' to select Samsung
Type '24'
Reboot
Due to the sheer diversity of AOSP GSIs, it is important to ensure you are concise when reporting an issue. Before you report an issue ensure you explicitly state the variant of the kernel you are using, as well as the ROM, firmware and vendor once you have ensured the ROM is compatible with the kernel. If these requirements are not met, you may receive support for the wrong platform or no response at all. It is preferred that you ask in the relevant telegram group prior to publishing on the XDA thread if possible.
Telegram Groups
If you're joining the Telegram group for support, please read the FAQ first!
Endurance Kernel Discussion / Support Group - https://t.me/endurancekernel
Endurance Kernel News Channel - https://t.me/endurancekernelnews
Credits
A huge thank you to everyone involved in the production of this kernel. Particularly a few names I would like to mention.
ianmacd - For creating A Pretty Good Kernel and doing all the hard work for me, as well as being a fantastic mentor who has assisted me through every stage of this kernel. My words understate my appreciation for your efforts.
AndreiLux - For pushing the device to its limits in many regards and paving the pathway from which many other devs, myself included rely on, and for assisting me in the production of the kernel.
farovitus - For his vast efforts included in the development of Notorious Kernel and for providing inspiration of changes and commits to include in the kernel as well as making another great kernel before the production of Endurance Kernel. Also thanks for maintaining ELS and keeping it simple for me!
flar2- For his fantastic EXKM app, and all his work from ElementalX included in APGK such as wake / sleep gestures and RGB colour control.
djb77 - For inspiring a few additions to the ramdisk and for being another fellow Aussie.
Freeza - For allowing the use of his installation script and for aiding in the issues faced in the early stages of kernel development.
Chrisaw - For being an exceptionally thorough and generous beta tester and for basically doing the hard troubleshooting for me. I can't say thanks enough for the time and effort you put into the kernel.
Huge thanks to everyone else who was involved in development of the kernel, and helped me during the stages of instability in the early phases of this kernel. You know who you are!
And of course, everyone involved in mainline Linux development!
Additonally
Lord Boeffla for Boeffla Wakelock Blocker
franciscofranco for fsync on / off support
Ktoonsez for initially introducing Notification LED fade support.
Noxxxious for making it easier to adapt Notification LED fade to the S9!
osm0sis for Android Image Kitchen
If I included your work and forgot you, let me know and I’ll add you to the credits list!
Source - https://github.com/eamo5/crownlte-endurance
Click here to donate! I used to not accept donations but while I'm undertaking my degree, a small donation could go a long way.
OneUI Current Build Changelog
V2.0.27
Linux 4.9.190
CSG5 kernel source and ramdisk
Converted GPU workqueues to kthreads (thanks farovitus)
Previous Changelogs
V2.0.26
Linux 4.9.186
CSFC source and ramdisk
Removed various unneeded drivers
Disabled swap on AOSP
AOSP 2.0 build works again
V2.0.25
Linux 4.9.185
V2.0.24
Linux 4.9.184
AOSP 2.0 based kernel appears to be broken for now, I will try to address this ASAP
V2.0.23
Linux 4.9.183
Addressed some regressions from the previous build
I forgot to update the kernel version lol
V2.0.22
Linux 4.9.182
CSF9 kernel source and ramdisk
Several improvements to ashmem, binder, SELinux dynamic memory allocation, IRQs & qos from Sultanxda
V2.0.21
Linux 4.9.180
V2.0.20
Linux 4.9.179
Cross compiled with GCC 9.1
Fixed instability in 4.9.178
V2.0.19
Linux 4.9.177
CSDJ ramdisk (kernel source is identical to CSDE)
V2.0.18
Linux 4.9.176
Cleaned up defconfig
V2.0.17-1
CSDE kernel source and ramdisk
Unset CONFIG_DEBUG_KERNEL (and it's dependencies)
Optimised F2FS configuration
V2.0.17
Linux 4.9.175
Fixed F2FS
V2.0.16
Linux 4.9.174
F2FS support
V2.0.15
Linux 4.9.173
V2.0.14
Linux 4.9.172
Updated Gator driver to v6.9
V2.0.13
Linux 4.9.171
Unset CONFIG_AUDIT (reduce SELinux overhead)
Updated Gator driver to 6.8
V2.0.12
Linux 4.9.170
V2.0.11
Linux 4.9.169
V2.0.10
Linux 4.9.168
V2.0.9
Linux 4.9.166
Fixed 4.9.165 performance regression
V2.0.8
Linux 4.9.165
Reduced kernel size
Unset CONFIG_ION_EXYNOS_STAT_LOG
V2.0.7
CSC1 kernel sources
Linux 4.9.164
V2.0.6-1
Fixed lockscreen issue on CSC1 ROMs
V2.0.6
Linux 4.9.163
CSB3 kernel sources
V2.0.5
Linux 4.9.162
Unset approximately 15 CONFIG_TRACE & CONFIG_EXYNOS_SNAPSHOT related options
Linux 4.9.161
Set CONFIG_STRIP_ASM_SYMS
Unset CONFIG_BT_DEBUGFS
Unset CONFIG_USB_DEBUG_DETAILED_LOG
Unset CONFIG_DEBUG_ATOMIC_SLEEP
Unset CONFIG_SEC_BOOTSTAT
Unset CONFIG_SEC_UPLOAD
Unset CONFIG_SEC_DEBUG_PPMPU
Fixed an issue with the r8152 ethernet driver & updated the driver.
V2.0.3
Linux 4.9.160
Unset CONFIG_EXYNOS_CORESIGHT (and everything it unsets)
Unset CONFIG_DEBUG_LIST
Unset CONFIG_DEBUG_EXCEPTION_STACK
Unset CONFIG_TIMER_STATS
Unset CONFIG_DEBUG_NOTIFIERS_PRINT_ELAPSED_TIME
Suppressed additional minor logging
V2.0.2
Linux 4.9.159
Unset CONFIG_KSM
Unset CONFIG_SDFAT_DEBUG
Unset CONFIG_SCHED_DEBUG
V2.0.1-1
CSB3 ramdisk (fixes lockscreen loop on CSB3)
Kernel now requires CSB3 ROM
V2.0.1
Linux 4.9.158
V2.0
Linux 4.9.156
Minor tweaks to scheduling
V2.0 RC 4
Linux 4.9.155
V2.0 RC 3
Rebased on ELS 4.9.154
Tweaked conservative scheduling a bit more for a slightly better user experience.
V2.0 RC 2
Tweaked conservative scheduling for an improved user experience
V2.0 RC 1
Support Android 9.0 OneUI
Linux 4.9.59
CSA2 kernel sources
Can boot with and without Magisk
Full OC implementation
DriveDroid support
Conservative scheduling
Oreo and GSI Current Build Changelog
V1.2.33
Linux 4.9.190
Previous Changelogs
V1.2.32
Linux 4.9.186
Removed various unneeded drivers
V1.2.31
Linux 4.9.185
Reverted Simple LMK on AOSP builds as it doesn't appear to be making reclaims correctly atm.
V1.2.30
Linux 4.9.184
Introduced the latest stable Simple LMK from Sultanxda in AOSP kernels
V1.2.29
Linux 4.9.183
Addressed some regressions from the previous build
I forgot to update the kernel version lol
V1.2.28
Linux 4.9.182
Several improvements to ashmem, binder, SELinux dynamic memory allocation, IRQs & qos from Sultanxda
V1.2.27
Linux 4.9.180
V1.2.26
Linux 4.9.179
Cross compiled with GCC 9.1
Fixed instability in 4.9.178
V1.2.25
Linux 4.9.177
V1.2.24
Linux 4.9.176
Cleaned up defconfig
V1.2.23
Linux 4.9.175
Fixed F2FS
V1.2.22
Linux 4.9.174
F2FS support
V1.2.21
Linux 4.9.173
V1.2.20
Linux 4.9.172
Updated Gator driver to v6.9
V1.2.19
Linux 4.9.171
Unset CONFIG_AUDIT (reduce SELinux overhead)
Updated Gator driver to 6.8
V1.2.18
Linux 4.9.170
V1.2.17
Linux 4.9.169
V1.2.16
Linux 4.9.168
V1.2.15
Linux 4.9.166
Fixed 4.9.165 performance regression
V1.2.14
Linux 4.9.165
Unset CONFIG_ION_EXYNOS_STAT_LOG
V1.2.13
Linux 4.9.164
V1.2.12
Linux 4.9.163
V1.2.11
Linux 4.9.162
Unset approximately 15 CONFIG_TRACE & CONFIG_EXYNOS_SNAPSHOT related options
V1.2.10
Linux 4.9.161
Set CONFIG_STRIP_ASM_SYMS
Unset CONFIG_BT_DEBUGFS
Unset CONFIG_USB_DEBUG_DETAILED_LOG
Unset CONFIG_DEBUG_ATOMIC_SLEEP
Unset CONFIG_SEC_BOOTSTAT
Unset CONFIG_SEC_UPLOAD
Unset CONFIG_SEC_DEBUG_PPMPU
V1.2.9
Linux 4.9.160
Optimised scheduling
Unset CONFIG_MODULES
Unset CONFIG_EXYNOS_CORESIGHT (and everything it unsets)
Unset CONFIG_DEBUG_LIST
Unset CONFIG_DEBUG_EXCEPTION_STACK
Unset CONFIG_TIMER_STATS
Unset CONFIG_DEBUG_NOTIFIERS_PRINT_ELAPSED_TIME
Suppressed additional minor logging
V1.2.8
Linux 4.9.159
Unset CONFIG_SDFAT_DEBUG
Unset CONFIG_SCHED_DEBUG
V1.2.7
Linux 4.9.158
ARL4 Kernel Source
V1.2.6
Linux 4.9.156
V1.2.5
Linux 4.9.155
V1.2.4
Linux 4.9.154
DriveDroid support
Fixed Android System warning on boot on GSI and AOSP kernels
V1.2.3
Linux 4.9.153
Fixed several weird bugs related to booting including requiring Magisk to boot!
V1.2.2
Linux 4.9.152
V1.2.1
Linux 4.9.151
V1.2.0
Linux 4.9.150
Realigned defconfig closer with ELS to hopefully fix some issues
V1.1.9
Linux 4.9.149
Updated WireGuard importer
FAQ
A FAQ section will be established as kernel development progresses. If you have any explicit unanswered questions, feel free to ask away. If you must contact me due to an issue, please report your device variant, ROM, firmware, vendor and previous kernel.
1. I can’t unlock / boot my phone! What do I do?
If you're stuck in a lockscreen loop, make sure you're on a firmware with a matching ramdisk to the kernel. Do not mix a CSC1 kernel ramdisk with a CSA2 ROM for example. Anytime the ramdisk is changed, it will be listed in the changelog. Are you on the correct firmware and vendor? If not, you can always flash this zip or revert back to previous versions through the Android File Host folder. Can anyone else successfully flash the kernel? If yes, verify the MD5 sum by referencing and ensuring a matching MD5 sum between the local file and the Android File Host file. Did I just push an update? If yes, contact me on Telegram in the Endurance Kernel group for a faster response, and XDA for an eventual response. Does your ROM require a permissive SELinux status to boot? If yes, use the 'Magisk SELinux Manager' module to adjust your SELinux status. If none of this can solve your problem, contact me through the Endurance Kernel group.
2. Why doesn't my camera work after flashing the kernel?
Verify that you are on the correct firmware, vendor and a ROM that supports the current kernels sources. If you are still encountering issues after verifying this is correct, then let me know! If you do not wish to update, you can maintain a version of the kernel that does support your ROM by reading the changelog and downloading the previous versions from the Android File Host folder
3. Why doesn't my Bluetooth work after flashing the kernel?
Are you on a ROM that does not patch libsecure_storage, such as DevBase? If your Bluetooth is broken, the answer is probably. Instead you can use ianmacd's Magisk module 'libsecure_storage companion for rooted Samsung devices' or you can manually flash a zip to patch it yourself, without the need for Magisk.
4. Why doesn't my WiFi work after flashing the kernel?
Make sure you have forgotten and rejoined all WiFi networks after installing the kernel if the device won't connect to the network. If the devices WiFi won't turn on at all, make sure you do not have ianmacd's 'libsecure_storage companion for rooted Samsung (Oreo) devices' installed. If you're still encountering issues, please contact me in the Telegram group or on XDA.
5. Should I use the permissive or enforcing SELinux status?
The decision is yours. There is plenty of documentation available online outlining their differences. I strongly recommend enforcing, hence why permissive is not officially supported. Permissive is far less secure, and hence I do not condone the use of permissive. If you are using permissive, you should either have to due to a dependency or have another specific reason for doing so. eg. ROM requires disabled signature check. For most users, unless directed otherwise, use the default enforcing build.
6. When will you update the kernel?
Once ELS is updated and the kernel is ready! This is just a side hobby and I do have a life outside of kernel development. Be patient, the update will arrive within a few days if not ASAP.
7. Will you add CPU / GPU undervolting?
No, EAS (Energy Aware Scheduling) has mostly made CPU undervolting mostly irrelevant. Google EAS if you would like it find out more information as to why it is the case. I've included a detailed YouTube video outlining the scheduling mechanisms of EAS here. Currently, any GPU voltage control for Exynos 9810 devices does not work, hence I will not be including it in my kernel.
8. Do I need to install Magisk?
Magisk is entirely optional with this kernel.
9. Why does this kernel offer no additional governors?
Because most of them are unstable and cause the device to crash, as well as EAS' integration with schedutil and EHMP.
10. Why does this kernel makes my device crash / battery poor / performance poor?
Because this kernel is still in beta. Since I can't personally verify anything with the kernel, it's possible there may be issues. If this is the case, report it on the XDA thread or Telegram group.
11. Why is my WiFi performance worse when using this kernel?
This may be the case for some people. This kernel uses the Westwood+ TCP algorithm for enhanced WiFi speeds on certain networks. However there may be scenarios on poor signal networks, this TCP algorithm may cause packet loss at a greater rate than is default. This should hopefully not be an issue for anyone, however if it is, try using bic as default and contact me.
12. Why is my battery still terrible?
Are you in an area with poor signal reception? Unfortunately that is one thing a custom kernel cannot compensate for due to the device modem having restricted access and also legal issues. That leaves us with optimizations that can only be done to the SOC of the device. How you use your device can also greatly lead to variation in battery stats. If you are in need of further battery, 'underclocking' is available and is explained in OP. If you want the best battery life, I advise you try out that build.
13. Why does SafetyNet fail on the AOSP kernels?
This is a minor issue I don't believe I can address on my end. This can be worked around however to allow SafetyNet to pass. You will need the 'MagiskHideProps' module installed. After rebooting, using a Terminal Emulator app enter the following commands in the order listed without quotation marks.
Type 'su'
Type 'props'
Type '1' to edit the device fingerprint
Type 'f'
Type '13' to select Samsung
Type '23' or '24'
Reboot
14. How can I use F2FS?
To use F2FS, you must erase your data and format your data partition (and optionally cache partition) to F2FS using the N9 TWRP available here, even if you are on S9. From there you should be able to reboot your device and restore your data through a backup.
15. Where can I donate?
I used to not accept donations but while I'm undertaking my degree, a small donation could go a long way. You can donate through my PayPal link here.
Bluetooth connections does not stick. Latest oreo.
Edit: Install libsecure from magisk and the issue fixed.
burakgon said:
Can't connect to wifi. Bluetooth connections does not stick. Latest oreo.
Click to expand...
Click to collapse
Hmmmm the kernel is using the latest ramdisk. This wasn't an issue in any of my beta tests. What device model are you on? Anyone else?
Eamo5 said:
Hmmmm the kernel is using the latest ramdisk. This wasn't an issue in any of my beta tests. What device model are you on? Anyone else?
Click to expand...
Click to collapse
After connecting a different network, I could reconnect my old wifi. But after reboot bluetooth connections does not stick. Check with s pen.
burakgon said:
After connecting a different network, I could reconnect my old wifi. But after reboot bluetooth connections does not stick. Check with s pen.
Click to expand...
Click to collapse
You might need to use the libsecure_storage companion Magisk module to fix Bluetooth pairing on some ROMs.
Amazing!!! Bring Exynos back to the glory again... Golden Age is coming again for Exynos I knew there's alot of sh*t happening on kernel level with Exynos.... I'm glad you got it all sorted (nearly)
But... I will wait till you add or support GPU & CPU undervolt , CPU Overclocking as undervolting CPU will further increase battery life it is obvious
Thank you! For providing this kernel!! I will keep watching it till at least have an undervolting CPU & GPU support (I'm not asking for any ETA'S) Thank you again!
#Exynos is back
Nice to see this here! Kudos
Good job man, this kernel working very good and Good battery life.. on my N9 TW keep going bro
Da-BOSS said:
Amazing!!! Bring Exynos back to the glory again... Golden Age is coming again for Exynos I knew there's alot of sh*t happening on kernel level with Exynos.... I'm glad you got it all sorted (nearly)
But... I will wait till you add or support GPU & CPU undervolt , CPU Overclocking as undervolting CPU will further increase battery life it is obvious
Thank you! For providing this kernel!! I will keep watching it till at least have an undervolting CPU & GPU support (I'm not asking for any ETA'S) Thank you again!
#Exynos is back
Click to expand...
Click to collapse
The conservative scaling of frequencies should already return some battery life, but slightly worsen the scores of some synthetic benchmarks. This is counterbalanced by the introduction of 16ms PELT which will in return improve real world performance.
The OC build will be much more performance centred.
The UC build should reduce peak power drain, but most battery savings will occur in the standard build. As stated in the FAQ, undervolting is mostly irrelevant with EAS.
Trying to work out the script ATM with a talented Note 9 tester. Hopefully should be introduced soon
Eamo5 said:
The conservative scaling of frequencies should already return some battery life, but slightly worsen the scores of some synthetic benchmarks. This is counterbalanced by the introduction of 16ms PELT which will in return improve real world performance.
The OC build will be much more performance centred.
The UC build should reduce peak power drain, but most battery savings will occur in the standard build. As stated in the FAQ, undervolting is mostly irrelevant with EAS.
Trying to work out the script ATM with a talented Note 9 tester. Hopefully should be introduced soon
Click to expand...
Click to collapse
I'm really happy to hear that :victory: this is like a new year gift to my ears !:victory:
But I'm really sorry for not being specific... I know what you mean for the CPU undervolting is irrelevant I have readed the FAQ ....
But what about the GPU? Is undervolting is irrelevant for the GPU too? it is an achievement when maximizing GPU OC with undervolting since the GPU is the weakest part on the Exynos... a significant OC pump frequency with tweaking voltage will bring some performance pump on heavy graphics performance :fingers-crossed: see what I mean?
Waiting for your reply.... as your opinion matters to me alot
Again Thank you.. Thank you!
Da-BOSS said:
I'm really happy to hear that :victory: this is like a new year gift to my ears !:victory:
But I'm really sorry for not being specific... I know what you mean for the CPU undervolting is irrelevant I have readed the FAQ ....
But what about the GPU? Is undervolting is irrelevant for the GPU too? it is an achievement when maximizing GPU OC with undervolting since the GPU is the weakest part on the Exynos... a significant OC pump frequency with tweaking voltage will bring some performance pump on heavy graphics performance :fingers-crossed: see what I mean?
Waiting for your reply.... as your opinion matters to me alot
Again Thank you.. Thank you!
Click to expand...
Click to collapse
GPU Voltage control was originally ported over to the Exynos 9810 but the voltage control was seemingly broken. When GPU voltage control is working, I'll introduce it again. Underclocking the GPU and allowing to run at a lower minimum frequency is something I may eventually investigate and measure if there are any benefits.
Eamo5 said:
GPU Voltage control was originally ported over to the Exynos 9810 but the voltage control was seemingly broken. When GPU voltage control is working, I'll introduce it again. Underclocking the GPU and allowing to run at a lower minimum frequency is something I may eventually investigate and measure if there are any benefits.
Click to expand...
Click to collapse
Thank you :fingers-crossed::good:
Running this kernel for 24 hours. Battery life & smoothness improved. No problem yet. Stock latest oreo S2ARL3 Thank you.
Endurance Kernel V1.1.8
Happy New Years!
Linux 4.9.148
Fixed GPU minimum frequency on TW build
Download links updated in OP!
Eamo5 said:
Endurance Kernel V1.1.8
Happy New Years!
Linux 4.9.148
Fixed GPU minimum frequency on TW build
Download links updated in OP!
Click to expand...
Click to collapse
thank you sir.
to you and yours aswell
Eamo5 said:
Endurance Kernel V1.1.8
Happy New Years!
Linux 4.9.148
Fixed GPU minimum frequency on TW build
Download links updated in OP!
Click to expand...
Click to collapse
Nice! Happy New year to all XDA! Cheers :highfive:
Will see version for pie soon?
Hello!
I want to introduce my first custom kernel for the SM8250 family of Snapdragons. This is based of latest Samsung OneUI 2.5 Sources and I cherry-picked commits to make improvements to the stock base. I'm not a developer, but i really like to port stuff over .
I will try to have this Kernel updated as soon as new source tarballs are drop by Samsung. If you want to request for specific features, let me know and i'll do my best to bring them over.
Special Features:
Changelog is in post #2
How to Install:
First, make sure you are in any OneUI 2.5 (BTH* or BTI*) ROM and have TWRP on the device. Make sure you take a backup of your current boot partition in twrp, now install either the boot.img (extract from the tar file) or use ODIN to flash in Dowload mode. Please make sure to read Post #3 regarding issues with the current OS Patch Level. Images from 1.5.0 onwards are pre-rooted but you will probably need to update magisk either manually or by flashing latest magisk.zip file.
Keep in mind the following table to determine your phone model:
x1q = S20 - G981X
y2q = S20+ - G986X
z3q = S20U - G988X
r8q = S20 FE - G781B
c1q = Note 20 - N981X
c2q = Note 20U - N986X
IMPORTANT NOTE: It seems some users need to flash a vbmeta image file provided by Google in order to boot and user the Custom Kernel. If you find yourself in a situation were you are not able to boot, please flash the attached vbmeta img along with the Kernel and if still bootlooping share the last_kmsg to determine what's driving the issue.
Download:
Disclaimer: I am not responsible if you use this and brick your device or if your device blows up, implodes, flames start shooting from it or it kills your neighbor's dog. Flash at your own risk. I am not responsible.... It was the other guy... I swear....
You can use THIS link to get the latest builds. These and other downloads can also be found in the Telegram Group.
Sources for Q? https://github.com/Jimbo77/JimboK_common_sm8250
Sources for R? https://github.com/Jimbo77/Jimbok_common_sm8250-R
Join the Telegram Group for additional discussions and downloads - HERE
Special thanks to:
Afaneh
Ianmcd
0smosis
flar2
Lord Boeffla
jesec
elliwigy
pappasmurf
For their work and dedication to development!
Changelog or features or whatever
04.10.21 - JimboK-R-2.6.0
Upstreamed to .185
04.05.21 - JimboK-R-2.5.0[/B]
Sync code to add missing changes in upstreamed branch
Reworked the DEVFREQ_BOOST driver
Tweaked SchedHorizon default freqs
Tweaked DEVFREQ_BOOST defaults in defconfig
03.31.21 - JimboK-R-2.4.0[/B]
Upstreamed to Stable Linux 4.19.184
Built with cortex-a55 specific optimizations
removed facebook process from 'kill-in-the-background' mod. This was affecting the user experience (for those that use Facebook a lot, like my wife lol)
02.24.21 - JimboK-R-2.3.0[/B]
Upstreamed to Stable Linux 4.19.176
Switched from G988U source as base to N986N source drop for OneUI 3.1
Removed a lot of unused configs from defconfig. This resulted in a reduction of Kernel size and will have an impact on the overall performance and resource utilization.
Reworked the DEVFREQ and CPU_INPUT_BOOST drivers
Added and Enabled schedhorizon governor
Imported the option to edit the CPU Frequency table
Performance Governor is default for LITTLE Cluster now
02.03.21 - JimboK-R-2.1.0[/B]
Upstreamed to Stable Linux 4.19.172
Moved to KOR dts to improve on stability for custom DTBO's
Added Flicker-Free or DC Dimming. There are two versions of the Kernel and this will be the only version with Flicker Free. After this, there will not be added since i don't like how it messes the Screen Colors/Performance.
Disabled Bootstats
Enabled MPTCP
01.25.21 - JimboK-R-2.0.0[/B]
Upstreamed to Stable Linux 4.19.169
Disabled several not needed debug Samsung Configs
CPU ASSIST Feature
Disabled ZRAM and SWAP
DTS (dtb and dtbo) updates for all variants to their latest source drops
General CLANG and LLVM optimizations
01.01.21 - JimboK-R-1.8.0
Reworked both DEVFREQ and CPU_INPUT Boost functionalities
finetuned for SM8250 (Samsung) specific frequencies/values
added and enabled Simple Low Memory Killer (SLMK)
added: CIFS, NTFS and ISO9660 FS in-kernel Support
added Wireguard Support
Several 'under the hood' improvements to task/memory management.
12.28.20 - JimboK-R-1.7.0
Added BBR2 TCP Config and made Default
Several updates to NET protocols and BBR2
Added PROC_MAGISK_HIDE_MOUNT
Added a script to fix Shealth, Smart View and set ZRAM parameters.
12.25.20 - JimboK-R-1.6.0
Added Dynamic Fsync
Tweaks for Memory Management
Updated LZ4 compressor
Enabled ZSTD Compressor for ZRAM - Default now
12.21.20 - JimboK-R-1.5.1
Fixed Wifi Calling
12.20.20 - JimboK-R-1.5.0
Fsync On/Off Support
Readahead 0
Slimbus OC
Toggle to enable/disable CRC
Turned off several debug options within the tree
added EAS related commits
12.16.20 - JimboK-R-1.4.0
Added Kcal Color Control Driver
Added KLAPSE Driver
Disabled Gentle Fair Sleepers
Added Boeffla Wakelock Blocker
Disabled AVB Flag for better protector in terms of SafetyNet
Misc fixes and addons to dtb
12.15.20 - JimboK-R-1.3.0
Skipped, no public Release xD
12.13.20 - JimboK-R-1.2.0
Added IO-SCHED drivers like: ZEN, FIOPS, MAPLE etc...
Added DevFreq Boost Driver and tuned based off OP8
Added Adreno Boost Driver
12.12.20 - JimboK-R-1.0.0
Initial Android R (OneUI 3.0) bring up
Source is based off the G988U source drop. This includes all other variant files, i have added support to all previous phones from day one now
Disabled Samsung Security useless stuff (DM Verity for example)
11.01.20 - JimboK-1.6.3
Added a fix to hide Magisk Mount for Isolated Processes. This is a critical leak in MagiskHide that can be exploited by apps trying to determine if the device is rooted. I had an issue with two payment apps that after applying this fix, they work. Not sure if they were finding magisk with this method lol. Read more here https://darvincitech.wordpress.com/2019/11/04/detecting-magisk-hide/
Finally removed the warning upon boot. EdXposed compatibility was not affected by the removal of it.
10.27.20 - JimboK-1.5.0
Rebased to S20 FE source as baseline for all models. This is to ensure support for the S20 FE is added and to keep the most up date source from Samsung
Streamlined even further the 'common' defconfig and updated all other variant defconfigs to make it easier to build individual Kernels.
Removed GPU OC - This is to test drive if performance takes a small hit but battery is gained. I have this as *temp change* consider it a 'test' phase so i will need your feedback on it to see whether if we keep it or not. Also, the OC was causing issues to boot in N20 units and some weird hiccups in the System-UI for my S20U.
Added BBR2 TCP CONG protocol. By far, the best TCP CONG to speed up the network connections overall. Read out more here: http://dl.ifip.org/db/conf/networking/networking2018/2B1-1570416152.pdf
BBR2 is now default TCP CONG for the Kernel. I recommend ya'll to make the switch
Several Upstreams to NET/TCP in order to improve Network Connectivity and Speed.
Kernel comes pre-rooted now (via ramdisk). In the event of a magisk update you will only need to update through Magisk Manager. This is for the sake of simplicity
10.16.20 - JimboK-1.4.0
Removed several DEBUG options from defconfig that should not be present in a Production Kernel
Disabled ZSWAP and VBSWAP (this will create conflict with ZRAM) and ZRAM has proven to be more effective and create less wear than ZSWAP
Disabled LZO, updated LZ4 compression algorithms
Enabled ZSTD Compression, it is recommended to enable this for ZRAM moving forward
Disabled KPERFORM in defconfig
Enabled .gz compression for Kernel. Kernel is now almost 1/3 in size of what it used to be
Added and Enabled HID: NINTENDO SWITCH controllers support
10.13.20 - JimboK-1.3.0
Unified Sources a bit more. Removed the individual defconfigs to have one single plus each variant
for X1Q and Y2Q moved dts sources from CHN OPEN to KOR to keep it in line with main (Z3Q) sources and also for CXQ sources. BTI3 (latest software release) is now used for those models.
Enabled a few drivers inside of Kernel: CDC, NTFS, CIFS and some native gaming devices as well
Disabled DM_VERITY checks. This will help with the booting times
JimboK-1.2.0 and before:
Build with latest LLVM Clang 11
Disabled Samsung Security useless stuff (DM Verity for example)
GPU OC up to 895mhz
Adreno Boost
Boeffla Wakelock Blocker Driver
Disabled ZRAM and moved to ZSWAP and VBSWAP
KCAL Color Control Driver (Up to date)
KLAPSE Driver (check out https://forum.xda-developers.com/an...apse-kernel-level-livedisplay-module-t3907025)
Added IO-SCHED drivers like: ZEN, FIOPS, MAPLE etc...
Latest Wireguard Driver
BBR TCP Congestion algorithm by Default
built-in Kernel Westwood and other modules
SLIMBUS OC to improve the Audio Mods
Several Debug Options removed from driver and all over the Kernel itself
QCACLD-3.0 Support
Dynamic Sync Control
Fsync On/Off Toggle
Several EAS commits for balancing power+efficiency
OS PATCH LEVEL set as 2099-12 (Read post #3 - Mandatory)
OS PATCH LEVEL PROBLEM
This is a modified version of @evdenis post HERE
My Kernel uses an OS Patch Level of 2099-12 to maximize its compatibility among all releases by Samsung across all the supported phones. That's it. No other reason as to why choose that date, now, when you continue using my Kernel update after update there will be no issue, but if you change the kernel to any other (specially stock) chances are that Kernel is using the current month OS PATCH LEVEL which will cause two things:
You will not be able to pass beyond your lockscreen. No matter what you try, it won't let you unlock upon reboot
Your Samsung Account will warn you to log off and log back in but you will not be able to do so
The problem is not in sources. It's due to os_patch_level mismatch with you current kernel. As mentioned JimboK Kernel does not uses common security patch date to be in sync with the official samsung firmwares. You can check the default os_patch_level in build.mkbootimg.* files. However, this date can be higher than other kernels use. When you flash a kernel with an earlier patch date on top of the previous one with a higher date, android activates rollback protection mechanism and you face the problems stated earlier. It's impossible to use a "universal" os_patch_level because different users use different custom kernels and different firmwares. JimboK Kernel uses a highest date by default in order to suite most of users.
How can you solve the problem? 6 ways:
You can restore my kernel and the problems will be gone
You can flash the attached zip file. backtothefuture-2099-12.zip, it will make your new Kernel Patch OS Level 2099-12 thus avoiding the issues above. - read more about the zip HERE. You will have to flash this with any new kernel if you ever use mine (unless you do a full wipe as mentioned at the end of this list).
You can check the os_patch_level date of your new kernel here https://cruelkernel.org/tools/bootimg/ and patch the kernel image image to the same date. If your previous kernel is mine (JIMBOK), patch your new Kernel to 2099-12 date.
You can reboot to TWRP, navigate to data/system and delete 3 files those names starts with 'lock'. Reboot. Login, set a new pin. To fix samsung account login, reinstall the app
You can rebuild JimboK Kernel with os_patch_level that suites you. To do it, you need to change the OS PATCH LEVEL to the desire date when using mkbootimg.
You can do the full wipe during the new Kernel flashing
Update 10.20.20
Updated the zip file to add support for W models.
Update 10.19.20
Updated the zip file to remove Exy devices and focus solely in N20 and S20 Snap line.
Finally kernel for s20 thanks a lot.
Works great!
I've got bootloop with my S20U G9880 after flashing this kernel even with a full wipe
Working
It works on my G9810 Thanks!!!
stszf9124 said:
I've got bootloop with my S20U G9880 after flashing this kernel even with a full wipe
Click to expand...
Click to collapse
Strange I have G988N which is just about the same and I don't have that issue. Did you come from a rooted device? Were you in a custom ROM before?
Can you tell me a bit more of your setup?
Are there any other G9880 users with the same issue?
I have s20+ 5g g986u
Unlocked bl
Flashing twrp
Flashed the kernel
Flashed vmbeta disabler
Flashed magisk
Boot
All ok
Thank you
thank you
my device is running custom Rom and stock kernel, the firmware is BTH6 , last night I installed the latest version of TWRP and format data and flashed the multiple disabler, the device booted , but it got this issue after the kernel was installed even with a full wipe again
has battery life been improved?
can i flash this and then magisk to get root?
Smartphones13 said:
can i flash this and then magisk to get root?
Click to expand...
Click to collapse
Yes, you can do that.
Viet.molet said:
has battery life been improved?
Click to expand...
Click to collapse
I flashed this and did a minor debloat and gained roughly 30 minutes of screen on time.
I also noticed the animation from recents to home screen is slightly snappier.
Could be placebo but I like it.
@jimbo77 what kind of benefits do I get by flashing your Kernel?
chieco said:
@jimbo77 what kind of benefits do I get by flashing your Kernel?
Click to expand...
Click to collapse
Disabled some Samsung Security, you will be able to run edxposed if you are into that. Also a few changes and add-ons, read the op for some of the features added to the Kernel
Works on sm-g9810?
jucin said:
Works on sm-g9810?
Click to expand...
Click to collapse
It should. Although I haven't personally tried since I own a G988N
jimbo77 said:
Yes, you can do that.
Click to expand...
Click to collapse
Hey man, how's it going? Did you do anything special to get kcal working on the kernel? Mental made a kernel for the Note 20 Ultra but said he could not get Kcal working.
Also, even better, would you consider making a common kernel for the Note 20 Ultra Snapdragon? I'd definitely send a donation your way.
Kirisakura-Kernel for the Sony Xperia 1 III
Hello everyone,
To keep it short: Here is Kirisakura - Kernel for the Sony Xperia 1 III aka Sagami. Sagami is the internal codename for this years development platform of Sony Mark III devices. Please note this kernel is made to run only on Xperia 1 III.
I would appreciate if everybody that flashes the kernel, reads at least once through this opening post and the following ones.
Kirisakura - Kernel is designed to bring a handful of beneficial features to the device, while ensuring excellent performance and smoothness to get you safely through the day!
If you expect a custom kernel to magically improve your devices battery life manifold and this is your only priority then this might not be the right place for you.
However the kernel is built to keep battery life close to the same as you would experience the on stock kernel while being tuned to perform better in various UI related benchmarks. The same benches are used by google to verify and ensure UI smoothness on the Pixel devices.
There´s also a cpu-battery saver mode that cuts back the CPU max- freqs, but without the disadvantages like delayed notifications from built into the system user-space power-saving modes.
If that got your curious, I welcome you to continue reading if you´re still interested!
The kernel includes a lot of improvements and contributions from other developers as well. Without this kernel would not exist.
A big part of improvements originate from @arter97´s, @kdrag0n´s and @Sultanxda´s work. Many others contributed in some way or another to this kernel.
A big thanks to all of them at this place!
Now lets continue with a list of features in the next paragraph!
Main Features:
- Based on latest kernel sources from Sony for Android 12 and intended to be used on the latest Stock-Firmware
- compiled with Clang 14.0.7 and built with -O3 speed optimizations
- Linux-Stable-Upstream included to 5.4.202
- upstreamed CAF base for the Snapdragon 888 (qcoms internal codename "lahaina")
- CPU-Battery saver to be able to restrict max cpufreqs on the fly, without enabling powersaving modes that might cause missed notifications (more info here)
- include important fixes/improvements from kernel/common
- reduce power consumption during deep sleep
- remove logging while device is suspended
- add SSG-IO scheduler from samsung (less overhead, better tuned towards android)
- disable various debugging mechanisms for drivers which are not needed on a perf build (e.g. binder)
- disable selinux auditing (we don´t have to adress selinux denials running a stock rom)
- disable unnecessary CPU errata for our specific SoC
- implement LRNG (thanks @arter97, see arter kernel OP for more info )
- Flashing the kernel will keep root!
- Flashable via EXKM, FKM or TWRP (if available) on a rooted system!
EAS related features:
- Implement dynamic WALT-Window size depending on current FPS, collecting information about CPU-Load to provide more precise information for the scheduler
- EAS implementation patched up to latest CAF state
- updates from kernel/common
- scheduler updates from sd888/ 5.4 kernel
CPU related features:
- Power saving workingqueues enabled by default (toggleable in EXKM)
- Change various drivers (WLAN, MM, audio, charger, power, thermal, glink etc) to use power efficient workingqueues. This compliments EAS in general
- improvements to cpufreq/times/stats
- vdso32 patches as found on Google Pixel devices (brief documentation here) (CAF 5.4 default, keep for documentation)
- remove event debug logging
- disable broken irq detection, disable debugmon
- improve suspend/resume from audio driver (caf-upstream for audio-kernel)
- cpuidle: wake only cpus for which qos has changed (this allows cores to keep idle states better)
- disable debugging during sleep states as per qcom recommendation
- remove RTB logging to reduce overhead
- disable trace_printk as it shouldn´t be used on production/perf kernel builds
- enable suspend_skip_sync to save power during suspend/resume
- disable edac and coresight (following google on the pixel kernels)
- disable jtagv8 debugging as recommended by qcom for perf builds to avoid potential power, performance and memory penalty
- disable s2idle in favor of deep idle state -> improves deep sleep drain (google initially used 2idle for improved suspend/resume latency on pixel 3 and pixel 4, but disabled it on pixel 5. qcom followed suit for sd 888, but apparently didn´t see google reverting it on pixel 5. Other OEMs such as Xiaomi or OnePlus already disabled s2idle on their SD888 devices in favor of deep- read more about s2idle vs deep here)
GPU related features:
- GPU driver updated to latest CAF-State
- gpu/kgsl improvements from pixel 4/pixel 5 kernel
- add low_prio_worker thread for gpu driver (Improves performance when tearing down processes (eg, via LMK) and not blocking currently running UI from submitting work to the GPU
File System related features:
- upstream BFQ-MQ to latest state in linux-mainline and default to 128KB readahead
- improve memory allocations in kernfs
- ufs improvements from pixel 4/ pixel 5 kernel
- improve GC as to not interfere while user interaction is happening and prevent possible jitter or latency spikes
Network related features:
- Wireguard Support (Details)
- advanced TCP algorithms enabled
- use bbr as default TCP congestion algorithm (fasted algo according to this excellent research from @kdrag0n found here )
- improved networking drivers from caf-upstream (especially wifi)
- remove unnecessary wakelock from WLAN driver to reduce thousands of very short wakeups during a 7 hour deep sleep period
- improved bluetooth performance (¹, ²)
- Enable support for TTL spoofing
Memory related features:
- Speculative Page Faults left enabled (1. 2) (CAF 5.4 default, keep for documentation)
- Fix various memory leaks in different subsystems
- improved mm with patches from mainline
- patches from kernel/common
- improve memory allocations in various subsystems, video encode/decode, kernfs, cgroup
- Backport to enable CONFIG_HAVE_MOVE_PMD (see here) , thanks @arter97
- Backport to enable CONFIG_HAVE_MOVE_PUD (commit here) , thanks @arter97
- free more RAM by removing unused reserved memory regions
- mm: Micro-optimize PID map reads for arm64 (improves game performance, especially unity based games such as genshin impact)
- MGLRU added (info here and here
Security related features:
- Control-Flow-Integration (CFI) and Link-Time-Optimization (LTO) (CAF 5.4 default, keep for documentation)
- Use ThinLTO which was first used in the Pixel 4 XL Android R-Kernel instead of full LTO (CAF 5.4 default, keep for documentation)
- Shadow Call Stack (SCS) Security-Feature ( 5.4 default, keep for documentation)
- enable init_on_alloc for even more security, more information can be found in the commit message (CAF 5.4 default, keep for documentation)
Misc Features:
Wakelock Blocker:
- advanced wakelock blocker with the ability to block any wakelocks (dangerous, use with caution)
- please read [URL="https://arstechnica.com/gadgets/2018/08/p-is-for-power-how-google-tests-tracks-and-improves-android-battery-life/"]this for further info
- blocking a kernel wakelock should only be done in case of firmware incompatabilities (WiFi network at work (can´t be changed) causes deep sleep to not work on the phone.) That´s the only use case I see for this feature. The kernel does not features this to improve battery life!
Other features:
- clean up asus drivers and fix a few warnings in kernel log
- disable logging and debugging to make the kernel more lightweight in various places (includes binder, mm, vma, gpu, ipa etc)
- fix several coding issues detected by newer Clang-Toolchains
- enlarge dmesg size to ease debugging
Flashing Guide, Download and Changelog
Requirements:
- unlocked Bootloader
- USB-Debugging in developer options enabled
- latest adb and fastboot binaries
- working adb and fastboot environment
- magisk root
- a backup of stock boot.img or your magisk patched boot.img in case you want to go back to stock.
How to flash the Kernel:
1. Download the latest kernel.zip and make sure you have properly updated to the latest matching Firmware (check the feature list for the current firmware the source is based on). When there´s an OTA update for the Sony Xperia 1 III it takes Sony a while to release the source code for the new OS and me a while to build a new kernel. If you don´t want to face any issues, wait until I either release an updated kernel or give green light because there were no kernel changes.
If you want to be sure there are no issues, always make sure to run the firmware the kernel is built for!
If you feel adventurous and try in advance, make sure you have a backup ready!
2. Flash the kernel.zip via latest TWRP (if available), EXKM or FKM app and do a full reboot.
3. Reboot and profit.
DOWNLOAD:
Download is located always in this folder:
https://www.androidfilehost.com/?w=files&flid=331114
Or attached to the release post starting with Android 13 as AFH is currently not working correctly
Important: Read after Download
Please take a look at the second post after flashing the kernel!
Changelog:
Android 11
1.0.0 Initial Release
1.0.1 https://forum.xda-developers.com/t/...xperia-1-iii-aka-sagami.4377449/post-86140929
Android 12
2.0.0
[Kernel][02.07.2022][Android 12] Kirisakura 2.0.0 for Sony Xperia 1 III aka "Sagami"
Kirisakura-Kernel for the Sony Xperia 1 III Hello everyone, To keep it short: Here is Kirisakura - Kernel for the Sony Xperia 1 III aka Sagami. Sagami is the internal codename for this years development platform of Sony Mark III devices. Please...
forum.xda-developers.com
Android 13
3.0.0 https://forum.xda-developers.com/t/...xperia-1-iii-aka-sagami.4377449/post-88048199
3.0.1 https://forum.xda-developers.com/t/...xperia-1-iii-aka-sagami.4377449/post-88404445
Donations:
Donations are not mandatory but very welcome if you want to support development or just buy me a coffee/tea
If you like my work: http://paypal.me/freak07
Credits:
Sony for the development device, giving me the opportunity to create this project!
@osm0sis for all his work, including the ak3 installer!
@tbalden for being the best HTC, Pixel, OnePlus and now Asus wingman!
@LeeDroid and @mwilky for their awesome roms and work I used on multiple devices!
@Captain_Throwback for all the mentoring and guidance!
@Eliminater74 for bringing me into the game and the Inspiration
@nathanchance for his upstream guidance and assistance
@RenderBroken for helping me out
@flar2 for all his work
@joshuous for all the help he provided to me in the past!
@arter97 for giving me advice
@kdrag0n for his help and advices!
@topjohnwu for magisk!
Source Code: https://github.com/freak07/Kirisakura_Sagami
F.A.Q:
Question: Is root preserved when flashing this kernel?
Answer: Yes, the AnyKernel.zip will detect root and keep it.
Question: Safetynet does not pass on my phone since I unlocked the phone, why is this so?
Answer: Google introduced hardware backed attestation recently. Unfortunately the old kernel tricks to still get safetynet passing won´t work. Instead you will have to rely on some magisk modules. Short guide in post #4 below.
Question: How do I return back to stock or another kernel.
Answer: Extract boot.img from the matching firmware you are on (you can do so by using this tool or similar ones found on XDA and when googling around) and flash them via fastboot. If you want to keep root flash back the magisk_patched_boot.img. Or dirty flash your rom and re-root.
Question: Why is having Magisk installed mandatory for this kernel?
Answer: The kernel uses a ramdisk overlay to apply some settings after boot. If you are not rooted these settings will not get applied and you miss some of the optimizations.
Question: How to report bugs properly?
Answer: Have a look at post #3 in the linked thread. The linked guide is a pretty good starting point.
Before reporting any bug make sure you´re running on a stock configuration. That´s means you´re not using any mods, tweaks in kernel managers or other root tweaks , magisk modules, scripts or other modifications that alter various functions like sound mods, data traffic, sleeping behaviour, scheduler, magical battery tweaks etc.
Try to describe the issue as detailed as possible! Give your exact setup, like rom, magisk version, kernel version.
Is the issue reproducible? Does it happen frequently?
Please make sure to meet the points described above, provide logs as detailed in the link above, otherwise debugging is a lot more time consuming and harder. (kernel flashing apps usually support exporting logs of flashes too) If these requirements aren´t met and I don´t find time to either reproduce the issue myself or I´m not able to reproduce the issue myself, reports might just be ignored. If you can already reproduce the issue and provide logs it greatly limits the amount of time I have to spent until I figure out how to reproduce it.
If the device force reboots/randomly reboots (that means you see the bootloader unlocked screen!) provide a .zip of /asdf.
Easiest way is immediately after booting up, with a root explorer navigate to /asdf. Copy the contents to your internal storage, zip it up and send it to me.
If the issue happens while the device is running provide a dmesg plus a logcat that you take while/shortly after the issue happens. This will log what´s running in the current session. Try to be as detailed as possible what´s happening when the issue appears. It will also help me in reading the log!
Feature Documentation:
Here´s a brief documentation about some of the features included in the kernel that can be changed as the user desires.
They can be accessed via either terminal, scripts or for example EXKM manager ( tools -> user settings).
CPU-Frequency Limiting:
Another option is CPU-Freq Limiting. You can now limit the CPU frequency to a few different levels with a sysfs interface. Original implementation is from @tbalden, I only changed it to be accessible via traditional root methods.
Main Switch:
sys/module/cpufreq/parameters/batterysaver
Set this option to "1" to enable the feature
Max-Frequency Selection (Input boosts, such as scrolling boost or app launching boosts will still apply, if touch boost restriction is not set to 1)
sys/module/cpufreq/parameters/batterysaver_level
Set this to "1" to restrict the max CPU-Freqs to 1,7GHZ/2,1GHZ/2,49GHZ (Little Cluster/Big Cluster/Prime Core)
Set this to "2" to restrict the max CPU-Freqs to 1,6GHZ/1,7GHZ/2,0GHZ (Little Cluster/Big Cluster/Prime Core)
Set this to "3" to restrict the max CPU-Freqs to 1,49GHZ/1,4GHZ/1,6GHZ (Little Cluster/Big Cluster/Prime Core)
Touch-Boost Restriction
sys/module/cpufreq/parameters/batterysaver_touch limiting
Set this to "1" to restrict the powerhal from boosting over the limit defined in batterysaver_level
Set this to "0" to allow the powerhal to boost above the values defined in batterysaver_level, but only during interaction with the Phone!
Screenshots:
View attachment 5309899View attachment 5309901View attachment 5309903
This is for example very useful during gaming to prevent additional heat, if not the highest performance from the CPU is required. Check if the game is running fine on level 1 or 2, and you´ll notice much less heat. Powerdraw will be reduced as well.
Another very useful trick while doing video calls or long extended navigation sessions with google maps to preserve battery or keep the phone from heating. Especially during summer if the ambient temperatures are high.
This is a very easy way to preserve battery or reduce heat without toggling the battery save mode in settings as that restricts background data usage, which can lead to delayed notifications.
How to pass Safetynet after unlocking the bootloader
With the introduction of hardware backed safetynet attestation, passing safetynet has become a lot more complicated.
Some probably remember a while ago, flashing a kernel that forced some flags was enough to pass it. However these days are gone.
Below is a short guide how to pass safetynet on phones that are flagged to use HW attestation (such as the ROG 5).
1. Make sure you´re running latest magisk canary.
2. In Magisk Manager enable both zygisk and deny list.
4. Download the latest Universal Safety Net Fix from @kdrag0n ´s github for zygisk cand flash it in Magisk Manager. Reboot.
5. Profit
this one is the last one
Freak07,
Please not this kernel is made to run only on Xperia 1 II
Click to expand...
Click to collapse
I guess it should be "Please note this kernel is made to run only on Xperia 1 III"
By the way, is there any plans to make same kernel for 5 III ?
Source Code: https://github.com/freak07/Kirisakura_Sagami
Click to expand...
Click to collapse
Leads me to nowhere (404).
dron39 said:
Freak07,
I guess it should be "Please note this kernel is made to run only on Xperia 1 III"
By the way, is there any plans to make same kernel for 5 III ?
Leads me to nowhere (404).
Click to expand...
Click to collapse
Fixed the typos and the link.
No, I only have the Xperia 1 III to work on.
Amazing work mate, very meticulous tuning. Would love to have this kernel on the 5 III. I understand the device architectures are quite similar?
treff89 said:
Amazing work mate, very meticulous tuning. Would love to have this kernel on the 5 III. I understand the device architectures are quite similar?
Click to expand...
Click to collapse
I asked the same question above
And unfortunatelly Freak07 do not support 5 III because he doesn't have it. Hope someone else could transfer his patches and things to 5 III.
Thanks for the kernel. However after installing the kernel my SD card gave an error. It says issue with the SD Card tap to fix and then asks me to format it?
BlazingKahn35 said:
Thanks for the kernel. However after installing the kernel my SD card gave an error. It says issue with the SD Card tap to fix and then asks me to format it?
Click to expand...
Click to collapse
I see. Thanks for the report!
I think i know whats up. They use a proprietary driver for exfat formatted sdcards ( I assume yours is formatted as exfat?) so it's not included in the source i build the kernel from.
I don't use a sdcard, that's why I missed it.
treff89 said:
Amazing work mate, very meticulous tuning. Would love to have this kernel on the 5 III. I understand the device architectures are quite similar?
Click to expand...
Click to collapse
dron39 said:
I asked the same question above
And unfortunatelly Freak07 do not support 5 III because he doesn't have it. Hope someone else could transfer his patches and things to 5 III.
Click to expand...
Click to collapse
They are similar, but I can't support a device i don't own. I also lack the time to do any remote debugging.
The phones however are similar as you mentioned, so if somebody is interested in starting to work on it all my work is up on GitHub. That might make it a lot easier than it would be otherwise.
Freak07 said:
I see. Thanks for the report!
I think i know whats up. They use a proprietary driver for exfat formatted sdcards ( I assume yours is formatted as exfat?) so it's not included in the source i build the kernel from.
I don't use a sdcard, that's why I missed it.
Click to expand...
Click to collapse
Yes mine is exfat since it's 256gb but not a big issue. I just transferred all my files to PC formatted the SD and transferred back now it works.
Also I'm using forced 4K all the time. But the only downside is the slowing down of the FP sensor. I think it's a kernel panic can you look in to that also maybe? (It was also slow on stock kernel)
Dear developer, if there is an opportunity, I would like to receive a kernel for PRO-I products!
I promise to donate
Update to 1.0.1
Good morning everybody,
thanks to @BlazingKahn35 ´s report exfat formatted sdcards are now working fine again.
Included an open source driver, that spoofs texfat support (the proprietary exfat driver) once an exfat sdcard is detected.
Download link can be found in the OP.
BlazingKahn35 said:
Also I'm using forced 4K all the time. But the only downside is the slowing down of the FP sensor. I think it's a kernel panic can you look in to that also maybe? (It was also slow on stock kernel)
Click to expand...
Click to collapse
Not sure what you mean. A kernel panic crashes the device so that it reboots.
The fingerprint scanner works fine for me. I place my finger on it, it scans and proceeds to unlock. It's not the fastest around, but it's quick enough for me.
Also used the adb commands to enable 4k and the speed of the fingerprint sensor stayed the same on my end.
I noticed just as I woke up that my phone was charged to 100%. Did you removed battery care from the kernel?
Freak07 said:
Not sure what you mean. A kernel panic crashes the device so that it reboots.
The fingerprint scanner works fine for me. I place my finger on it, it scans and proceeds to unlock. It's not the fastest around, but it's quick enough for me.
Also used the adb commands to enable 4k and the speed of the fingerprint sensor stayed the same on my end.
Click to expand...
Click to collapse
For me there is a big delay sometimes. Do you have AOD enabled?
BlazingKahn35 said:
I noticed just as I woke up that my phone was charged to 100%. Did you removed battery care from the kernel?
Click to expand...
Click to collapse
Not intentionally no. It might be not enabled the way I built the source or i need to see if the drivers is available somewhere else to be able to build it in.
I'll play around with it the next few days, see if I can reproduce the issue and find what's missing or broken. Thanks for the report again.
BlazingKahn35 said:
For me there is a big delay sometimes. Do you have AOD enabled?
Click to expand...
Click to collapse
Not constant AOD. Only waking to AOD screen when lifting the phone is enabled.