valexKernel
For SM-P600, AOSP/CM13-based 6.x ROMs ONLY!
Disclaimer: This kernel is for use with AOSP/CM13-based ROMs only and will not work on stock ROMs. If your device bricks, breaks or explodes as a result from flashing this kernel I am not to be held accountable for it. Flash this at your own risk.
About: This kernel focuses mainly on backports and improvements from more recent versions of Linux. As of now, major updates have been made to the scheduler, SMP, hotplug, memory management, random, the user namespace, and the ARM architecture in general. Compiled with Cortex-A15 optimized GCC 4.9.4. For full changelog, see my git repository here: https://bitbucket.org/sigma-1/valex_kernel_mm/commits/branch/valex_master
Features: My kernel contains no "gimmicky" features other than the ones that are already present in the CM13 kernel base for our device which includes voltage control, haptic intensity control and AndreiLux's sound control feature to mention a few. Again, my kernel focuses mainly on updates and backports from mainline so it can be said that those are its main features.
Known bugs: None so far. If you are encountering freezes and reboots with the S-Pen, audio crackling or lags then try this fix: http://forum.xda-developers.com/galaxy-note-10-2014/development/lt03wifi-temaseks-unofficial-build-t2980604/post65631142. If you encounter any bugs that you think may be kernel-related, please report them here along with logcat or dmesg.
Other issues: While it can't be said that this kernel should be considered "stable" that does not mean that it is necessarily "unstable" either. Some of the backports are experimental at best so if you run into any new issues please report them here along with a dmesg log or a logcat.
Support: Currently this kernel only supports the SM-P600. Support for the P601 will be added soon.
Licence: The Linux kernel is licenced under the GNU General Public Licence v2. What this means is that if you want to develop a custom kernel using mine (or anyone else's for that matter) as your base then you are free to do so without asking for my permission. That is the nature of the Linux kernel so go nuts.
Installation: Just flash the zip in recovery and reboot. The installation procedure does not replace your current boot.img but rather just decompresses it to swap out the kernel binary (zimage) itself. This should make it compatible across different CM13-based ROMs for the SM-P600.
Download the latest build here:
valexKernel MM v1.00 https://drive.google.com/open?id=0B7Ui4IHpV48JMXNsMV96T1ZuLWc
XDA:DevDB Information
valexKernel, Kernel for the Samsung Galaxy Note 10.1 (2014 Edition)
Contributors
Andmoreagain, RaymanFX
Source Code: https://bitbucket.org/sigma-1/valex_kernel_mm
Kernel Special Features:
Version Information
Status: Beta
Current Beta Version: 1.0
Created 2015-07-10
Last Updated 2015-07-11
Manual cherry-picking: If you are cherry-picking from my tree and a patch needs to be manually applied for whatever reason, I find it preferable to amend the original author to the commit in order to avoid confusion in regard to authorship. This is done using the following command before pushing the commit:
Code:
git commit --amend --author="Author Name <[email protected]>"
The commit editing screen should now pop up, where at the bottom you may then add:
Code:
Signed-off-by: Your Name <[email protected]>
This helps keeping track of the patch's original authorship along with any modifications made to the patch. While this is not strictly a mandatory rule, I would prefer that anyone who wishes to utilize my backports in the future would follow this procedure.
Mind if I include some of this in my feature rich kernel[emoji6]
Sent from my SM-P600 using Tapatalk
Orion116 said:
Mind if I include some of this in my feature rich kernel[emoji6]
Sent from my SM-P600 using Tapatalk
Click to expand...
Click to collapse
Do it! :good:
Andmoreagain said:
Do it! :good:
Click to expand...
Click to collapse
Cannot wait to see the result
The latest build has a bug that causes reboots when the screen is off. I'll fix it and upload a new build tonight.
v1.0 is good though, a bit battery-hungry but the performance is well above average.
Edit: fell asleep last night before I could finish this. I decided to start over with the gic backports and update the big.LITTLE switcher accordingly. The difficulties that I'm running into is that the stock bL_switcher code itself is a backport that skips the upstream MCPM dependencies and thus it looks a bit different than the upstream version.
I'm going to try to just add the MCPM patches with the upstream bL_switcher and see how it runs. I already know that it compiles but I don't know if it actually works because the kernel lacks the arm-cci driver. Then again, maybe the cci driver is only required for hmp support. Only one way to find out...
Edit 2:
:fingers-crossed: Just look at this: https://bitbucket.org/sigma-1/linux-android-3.4.y-exynos-lt03wifi/commits/branch/v2-test2
Multi-Cluster PM compiles now, but the big.LITTLE switcher is causing a different build error due to some missing dependencies. I can't wait to test this out as soon as these missing dependencies have been resolved. If MCPM works then it means that there's not much left to add for true octa core support.
Edit 3:
Bahh... gonna put this on hold for now. I'm getting some nonsensical "undefined reference" errors at the very end of the build. If anyone wishes to try and figure this one out, be my guest, because these are all defined as far as I can tell.
Code:
LD vmlinux.o
MODPOST vmlinux.o
GEN .version
CHK include/generated/compile.h
UPD include/generated/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
arch/arm/common/built-in.o: In function `bL_switch_to':
/home/valex/linux-android-3.4.y-exynos-lt03wifi/arch/arm/common/bL_switcher.c:196: undefined reference to `gic_get_sgir_physaddr'
/home/valex/linux-android-3.4.y-exynos-lt03wifi/arch/arm/common/bL_switcher.c:212: undefined reference to `gic_send_sgi'
/home/valex/linux-android-3.4.y-exynos-lt03wifi/arch/arm/common/bL_switcher.c:230: undefined reference to `gic_migrate_target'
arch/arm/common/built-in.o: In function `bL_switcher_halve_cpus':
/home/valex/linux-android-3.4.y-exynos-lt03wifi/arch/arm/common/bL_switcher.c:513: undefined reference to `gic_get_cpu_id'
arch/arm/mach-exynos/built-in.o: In function `exynos4_init_irq':
/home/valex/linux-android-3.4.y-exynos-lt03wifi/arch/arm/mach-exynos/common.c:875: undefined reference to `gic_init_bases'
/home/valex/linux-android-3.4.y-exynos-lt03wifi/arch/arm/mach-exynos/common.c:882: undefined reference to `gic_arch_extn'
/home/valex/linux-android-3.4.y-exynos-lt03wifi/arch/arm/mach-exynos/common.c:882: undefined reference to `gic_arch_extn'
arch/arm/mach-exynos/built-in.o: In function `gic_init':
/home/valex/linux-android-3.4.y-exynos-lt03wifi/include/linux/irqchip/arm-gic.h:76: undefined reference to `gic_init_bases'
arch/arm/mach-exynos/built-in.o: In function `exynos5_init_irq':
/home/valex/linux-android-3.4.y-exynos-lt03wifi/arch/arm/mach-exynos/common.c:915: undefined reference to `gic_arch_extn'
/home/valex/linux-android-3.4.y-exynos-lt03wifi/arch/arm/mach-exynos/common.c:915: undefined reference to `gic_arch_extn'
Makefile:882: recipe for target '.tmp_vmlinux1' failed
make: *** [.tmp_vmlinux1] Error 1
I'm just gonna get back on track, fix the screen-off-reboot bug and deal with this big.LITTLE stuff when I have the time and patience for it. Something good has come out of this though since now I have a bunch of commits that help preparing the kernel base for MCPM support. That's not to say that it will ever work with this kernel. Maybe it will, maybe it won't. The best chance for this to ever work would be a board file-to-device tree migration with linux 3.10 or higher. That requires some work on the device drivers though since a few of them are not in mainline or anywhere else for that matter, except our stock kernel (why Samsung haven't sent these to be supported upstream is beyond me).
Bump!
v2.0 release candidates have been added. Both tested and running good so far. RC2 is a bit more bleeding-edge since it contains some more preparatory backports for MCPM integration. I uploaded RC1 too in case anyone runs into a bug and wishes to fall back to a more stable version. See changelog for more info on both RCs. Enjoy!
Hi. Do you plan to add other govenors ?
Thank you!
So what is the different between this kernel and stock? better battery life? performance? both? I'm looking for the main shine feature of this kernel.. )
buhohitr said:
So what is the different between this kernel and stock? better battery life? performance? both? I'm looking for the main shine feature of this kernel.. )
Click to expand...
Click to collapse
Performance is significantly better compared to stock as both the scheduler and SMP/hotplug functionality have been updated and improved. At first this came at the cost of power consumption but as of the latest updates this seems to be fixed. A lot of the updates included are also preparatory patches for HMP support.
DirkStorck said:
Hi. Do you plan to add other govenors ?
Click to expand...
Click to collapse
It is not my main focus at the moment but I haven't really made a final decision in that regard.
Andmoreagain said:
Performance is significantly better compared to stock as both the scheduler and SMP/hotplug functionality have been updated and improved. At first this came at the cost of power consumption but as of the latest updates this seems to be fixed. A lot of the updates included are also preparatory patches for HMP support.
It is not my main focus at the moment but I haven't really made a final decision in that regard.
Click to expand...
Click to collapse
Ok, I understand. I am only asking because with another kernel I have used "weathley" and had a good balance between speed and battery!
DirkStorck said:
Hi. Do you plan to add other govenors ?
Thank you!
Click to expand...
Click to collapse
Governors is my job once I rebase BrokenNote kernel to use this as the base.
Andmoreagain said:
Performance is significantly better compared to stock as both the scheduler and SMP/hotplug functionality have been updated and improved. At first this came at the cost of power consumption but as of the latest updates this seems to be fixed. A lot of the updates included are also preparatory patches for HMP support.
It is not my main focus at the moment but I haven't really made a final decision in that regard.
Click to expand...
Click to collapse
Sent from my SCH-R530U using Tapatalk
Orion116 said:
Governors is my job once I rebase BrokenNote kernel to use this as the base.
Click to expand...
Click to collapse
Cool! I personally don't have any particular interest in custom governors so this sounds like a good solution for those who want more customizable options.
But anyway...
I added SCHED_HMP to see if the scheduler was ready for it. Two additional commits and one revert later, that turned out to be the case indeed.
I won't be adding it in to my distribution here until I've made sure everything else is in good shape. MCPM still needs to be pulled in. RaymanFX has it partially backported, but like I've said before I have no idea whether it will actually work with the current CCI implementation. I wonder if it would be possible to support the upstream CCI driver by parsing a minimal FDT to the kernel at boot, something like:
Code:
/ {
compatible = "samsung,exynos5420", "samsung,exynos5";
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu0: [email protected] {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x0>;
clock-frequency = <1800000000>;
cci-control-port = <&cci_control1>;
};
cpu1: [email protected] {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x1>;
clock-frequency = <1800000000>;
cci-control-port = <&cci_control1>;
};
cpu2: [email protected] {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x2>;
clock-frequency = <1800000000>;
cci-control-port = <&cci_control1>;
};
cpu3: [email protected] {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x3>;
clock-frequency = <1800000000>;
cci-control-port = <&cci_control1>;
};
cpu4: [email protected] {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x100>;
clock-frequency = <1000000000>;
cci-control-port = <&cci_control0>;
};
cpu5: [email protected] {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x101>;
clock-frequency = <1000000000>;
cci-control-port = <&cci_control0>;
};
cpu6: [email protected] {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x102>;
clock-frequency = <1000000000>;
cci-control-port = <&cci_control0>;
};
cpu7: [email protected] {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x103>;
clock-frequency = <1000000000>;
cci-control-port = <&cci_control0>;
};
};
cci: [email protected] {
compatible = "arm,cci-400";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x10d20000 0x1000>;
ranges = <0x0 0x10d20000 0x6000>;
cci_control0: [email protected] {
compatible = "arm,cci-400-ctrl-if";
interface-type = "ace";
reg = <0x4000 0x1000>;
};
cci_control1: [email protected] {
compatible = "arm,cci-400-ctrl-if";
interface-type = "ace";
reg = <0x5000 0x1000>;
};
};
};
New build is up. It's far from being stable, but I have removed the stock big.LITTLE switcher and replaced it with the upstream version along with multi-cluster PM (MCPM). These are the main prerequisites for HMP/true octa support. It boots, it runs, but it has a few hiccups as well.
In light of this latest testing build, I thought I'd share this clip. It's an interesting interview with Nicolas Pitre who developed the big.LITTLE switcher, and did it blindly in a very literal sense.
Andmoreagain said:
New build is up. It's far from being stable, but I have removed the stock big.LITTLE switcher and replaced it with the upstream version along with multi-cluster PM (MCPM). These are the main prerequisites for HMP/true octa support. It boots, it runs, but it has a few hiccups as well.
In light of this latest testing build, I thought I'd share this clip. It's an interesting interview with Nicolas Pitre who developed the big.LITTLE switcher, and did it blindly in a very literal sense.
Click to expand...
Click to collapse
Very cool. Once I get my device files straight back out and have time I am going to rebase my kernel. I am just very short on time, lol.
Sent from my SM-P600 using Tapatalk
Andmoreagain said:
New build is up. It's far from being stable, but I have removed the stock big.LITTLE switcher and replaced it with the upstream version along with multi-cluster PM (MCPM). These are the main prerequisites for HMP/true octa support. It boots, it runs, but it has a few hiccups as well.
In light of this latest testing build, I thought I'd share this clip. It's an interesting interview with Nicolas Pitre who developed the big.LITTLE switcher, and did it blindly in a very literal sense.
Click to expand...
Click to collapse
It's both sad and impressive that the community does what Samsung does not for her own devices.
Good luck good sir! A proper hmp implementation also helps with battery life which -I believe- is much needed for our device (no more big core switching for the simplest things)...
Stevethegreat said:
It's both sad and impressive that the community does what Samsung does not for her own devices.
Good luck good sir! A proper hmp implementation also helps with battery life which -I believe- is much needed for our device (no more big core switching for the simplest things)...
Click to expand...
Click to collapse
This is just the nature of the Linux Kernel. Samsung have done an excellent job at maintaining and developing the Exynos platform in mainline and even the max77802 PMIC got supported not too long ago. The rest is up to the community. The fact that our stock kernel is stuck at 3.4 is just as much Google's fault as it is Samsung's due to them relying on LTS releases instead of following Linus Torvalds' motto: "release early, release often".
Andmoreagain said:
This is just the nature of the Linux Kernel. Samsung have done an excellent job at maintaining and developing the Exynos platform in mainline and even the max77802 PMIC got supported not too long ago. The rest is up to the community. The fact that our stock kernel is stuck at 3.4 is just as much Google's fault as it is Samsung's due to them relying on LTS releases instead of following Linus Torvalds' motto: "release early, release often".
Click to expand...
Click to collapse
Yeah but Galaxy Notes are Samsung's flagships and most expensive devices. One can see why they can't support every last of their devices, I can't see why they don't do it for many of their most expensive devices neither. iPad 2 , a 4 and a half year old device which was cheaper at its release time than this Note, is still getting updates (it's going to get ios9!).
I know that the nature of Linux's mainline is to be often developed by the community, but Samsung could at least offer great documentation, update drivers, etc ... I think we paid that much (for it). "If you can't develop for your expensive devices anymore, at least make it easy for your community to do so". That's my understanding, at least when expensive hardware is involved in the equation...
Andmoreagain said:
New build is up. It's far from being stable, but I have removed the stock big.LITTLE switcher and replaced it with the upstream version along with multi-cluster PM (MCPM). These are the main prerequisites for HMP/true octa support. It boots, it runs, but it has a few hiccups as well.
In light of this latest testing build, I thought I'd share this clip. It's an interesting interview with Nicolas Pitre who developed the big.LITTLE switcher, and did it blindly in a very literal sense.
Click to expand...
Click to collapse
How long does your tablet usually take to boot after flashing the kernel?
Sent from my SCH-R530U using Tapatalk
---------- Post added at 05:31 AM ---------- Previous post was at 05:28 AM ----------
Andmoreagain said:
valexKernel
For SM-P600, AOSP/CM-based 5.1.1 ROMs ONLY!
Hey, you may have seen my other thread where I'm researching the possibility of porting the entire upstream kernel to our device. Of course that will take time, especially with no other experienced developers by my side. In the meantime I wanted to give you guys a little treat, so I took RaymanFX's base and did some cherry-picking and backporting of upstream features. Not particularly flashy features like blahblahblah-governor or blehblehbleh-iosched; just lots of updates from upstream, backports, and some patches from CAF and Linaro.
The scheduler has mostly been updated to something between linux 3.10 and 3.16, sched_deadline has been added, updates to topology and SMP have been added-including the generic smpboot code, per-platform SMP operations and exynos support for SMP operations. Rbtree, cpuidle, mutex, futex, blahblablah has been updated, f2fs has been pulled in with its respective 'exynos patch' from oloendithas' tree, rwsem and zsmalloc have been updated to 3.10, arch_timer has been added, power-efficient workqueues, new hashtable implementation, and the list goes on.
I also backported the gic and vic changes from linux 3.9, so if anyone is wondering where they went then they're in the drivers/irqchip directrory. A word of warning: this might be affecting some bL_switcher functionality because the stock kernel relies on a hacky backport of the bL_switcher. I plan on removing that altogether and add an upstream-ish version instead with MCPM support. The gic changes make such backporting easier to implement so thank god I'm done with it lol.
Despite this potential issue it seems to run smoothly so far. If you hit any bugs, please let me know. Enjoy! :victory:
INSTALL INSTRUCTIONS:
1) Download
2) Flash in recovery + wipe chache/dalvik
3) ???
4) PROFIT!
Highlighted changes
Code:
[U]v2.0 - MCPM-testing[/U]
- Multi-cluster PM
* MCPM is now working, at least with the big.LITTLE switcher. Full
eight core support is still not active because of lacking device
tree- and CCI support.
- big.LITTLE switcher
* Replaced the existing implementation with the upstream patches.
- OF: a few updates to fix build breakage when FDT support is enabled.
* This is still broken since device tree support for ARM is still
incomplete in 3.4 overall. I'll see if I can make it work but no
promises.
- Config options
* Multi-core scheduler enabled
* MCPM enabled
* MobiCore disabled
- Misc changes
* cpumask: preparatory patches for the CCI driver
* lib/devres: same as above
* ARM/PMU: preparatory patches for the big.LITTLE MP patch set.
* ARM: use built-in byte swap function
* mm: remove compressed copy from zram in-memory
* ARM/nommu: prevent generation of kernel unaligned memory accesses
* panic: fix incomplete panic log in panic()
* ARM: SMP: remove redundant instances of __cpuinit
* GCC optimizations
See commit history for full changelog.
- Notes
* At the current stage it could be said that the kernel almost
supports HMP. The only thing standing in the way at the moment
is the ARM CCI-400 driver which relies on device tree support in
order to work, and the Exynos5420-specific MCPM implementations
which in turn rely on the CCI driver. The next step would therefore
be improving device tree support in the kernel.
WARNING: The MCPM-enabled kernel is still buggy. There are a few
instances of kernel panics such as random reboots and sleep of death
issues. It still boots and runs fine aside from these. I've seen worse.
I can't say for sure what exactly is causing these issues. It might
not even be the MCPM or the big.LITTLE switcher. I'll have to do more
testing to find out.
Go ahead and check it out, it's not going to blow up your tablet.
Just make sure to collect the logs ;)
[U]v2.0 - RC2[/U]
- GIC:
* Synced GIC with upstream.
* 3.4 compatibility stuff is no longer needed.
- More: see commit history
* Loads of updates to ARM, especially for PM,
sleep, suspend, cpuidle, etc. These are also
preparatory changes for MCPM integration.
- Reverted commits from v1.5
* Left out some non-critical commits that were
introduced in v1.5 and were causing buggy
behavior and kernel panics. Otherwise this
release contains everything found in v1.5.
- Notes on this release:
* I have tested the kernel and so far I have
not come across any bugs or kernel panics.
If you come across anything unusual, please
let me know, provide a description of the
issue and preferably accompany your report with
a dmesg or a logcat if possible.
[U]v2.0 - RC1[/U]
- BACKPORT v2: Move GIC and VIC to drivers/irqchip
* My previous version of this backport turned
out to be a bit bloated with commits that were
not part of this particular patch set. This
has now been fixed and these additional commits
have been applied separately.
* Fixed the placement of the gic_raise_softirq
function and made sure 3.4 compatibility was
properly in check.
* Fixed some missing includes in platform-
specific code.
- SMP: formalize an IPI for wakeup
* Reverted the old ping IPI patch in exchange
for the upstream wakeup IPI. This is one of
the minor dependencies for the GIC/VIC changes.
- More: see commit history
* WM5102 sound control by AndreiLux
* Whitelisted F2FS in SELinux
* Cortex-A15 optimizations for memcpy
* kexec_hardboot support
* Disabled some of Samsung's debug bloat
* Enabled KSM, Cacheflush, Loadable module support, and a few other options.
- Notes on this release:
* I have tested the kernel and so far I have
not come across any bugs or kernel panics.
If you come across anything unusual, please
let me know, provide a description of the
issue and preferably accompany your report with
a dmesg or a logcat if possible.
[U]v1.5 - testing - Build 20151307[/U]
[INDENT]* cacheflush: upstream updates
* exynos/hotplug: use v7_exit_coherency_flush macro for cache disabling
* smp/hotplug: more or less updated to upstream, very little left to add there
* arm/opcodes: updated to latest upstream version
* kexec: kexec hardboot support
* arm: generic timer broadcast support
* clockevents: generic timer broadcast receiver
* arm/virt: allow the kernel to be entered in HYP mode
* drivers: moved some samsung drivers to staging
- This does not affect the performance of the kernel,
it's more for my own convenience when dealing with
the source code.
* gic/vic: removed some redundant leftovers in arm/common
- We are now using the upstream GIC in drivers/irqchip.
No need to keep the old one.
* Sound: Wolfson WM5102 sound control by AndreiLux
* Enabled NTFS write support
* Cortex-A15 optimizations
* init.d support in ramdisk
* misc tweaks and fixes
[/INDENT]
[U]v1.0 - stable - Build 20150710[/U]
[INDENT]* sched: updated to a more upstream version, introducing SCHED_DEADLINE
* smp: updated to a more upstream version
* smp: backported per-platform SMP operations with Exynos support
* smpboot: added generic-idle patches from upstream
* arm: added arch_timer from upstream
* arm: NEON in kernel mode
* arm/crypto: NEON optimizations
* arm/gic: backported the 3.9 version of GIC and moved to drivers/irqchip
* workqueue: power-efficient workqueues
* fs: upstream updates
* fs: pulled in F2FS support
* rbtree: upstream updates
* mutex: upstream updates
* softirq: upstream updates
* cpuidle: upstream updates
* futex: upstream updates
* removed __cpuinit
* new hashtable implementation
* zsmalloc: updated to 3.10 version
* rwsem: updated to 3.10 version
* misc optimizations
* WIP: iov-iter (the patches from faux123 are not applicable to our tree, gonna do this manually)
* WIP: arch_timer (had to revert a bunch of patches due to leaving out the patch for DT-only support)
* TODO: big.LITTLE improvements
* TODO: dig up my backported patch of kexec_hardboot for universal5420 and add it to the mix
* TODO: fix Samsung's max77803 mfd driver[/INDENT]
Special thanks to: RaymanFX, SyntheticNightmar3, dorimanx, oloendithas, xluco, AndreiLux, halaszk, faux123, and everyone I might be forgetting.
Source
Changelog
DOWNLOADS:
Testing Releases:
v2.0-MCPM-TEST
WARNING: The "MCPM/bL-switcher" build is still buggy and is for testing purposes only. Don't complain if you encounter instances of random reboots, sleep of death, etc. Log or it didn't happen!
Stable Releases:
v2.0-RC2
v2.0-RC1
v1.0-Stable
XDA:DevDB Information
valexKernel, Kernel for the Samsung Galaxy Note 10.1 (2014 Edition)
Contributors
Andmoreagain, RaymanFX
Source Code: https://bitbucket.org/sigma-1/linux...e2ef0312b2922a8c9a1cc4871bb79d4870e?at=master
Kernel Special Features:
Version Information
Status: Beta
Current Beta Version: 1.0
Created 2015-07-10
Last Updated 2015-07-11
Click to expand...
Click to collapse
Orion116 said:
How long does your tablet usually take to boot after flashing the kernel?
Sent from my SCH-R530U using Tapatalk
Click to expand...
Click to collapse
I want to know so I can get a log in the morning.
Sent from my SCH-R530U using Tapatalk
Orion116 said:
How long does your tablet usually take to boot after flashing the kernel?
I want to know so I can get a log in the morning.
Sent from my SCH-R530U using Tapatalk
Click to expand...
Click to collapse
v2 RC2: About 4 minutes in total if we count "Optimizing apps" as part of the boot process. Up until that part it takes slightly over a minute.
MCPM build: Got a freeze/kernel panic during the boot animation now. I suspect it was due to a root app having been updated before I flashed the kernel and it was requesting to be granted root access again. I've seen this pattern before with some of my unstable kernels. Last time I tested it though it took slightly longer to boot than RC2.
Stevethegreat said:
I know that the nature of Linux's mainline is to be often developed by the community, but Samsung could at least offer great documentation, update drivers, etc ... I think we paid that much (for it). "If you can't develop for your expensive devices anymore, at least make it easy for your community to do so". That's my understanding, at least when expensive hardware is involved in the equation...
Click to expand...
Click to collapse
I totally agree. It's not exactly a smart move to release a kernel source without a slightest hint of documentation. At least if they'd provide a changelog of patches applied on top of the 3.4 base then it would be easier to track down the actual patches. The truth is that some of the patches they rely on are early and incomplete revisions, while others are custom hacks plain and simple.
One good example is the max77803 driver. The P600 uses it a bit differently than other devices so what they did was modifying the max77888 driver to be used as a secondary driver for the max77803, just so that it could be handled "correctly" on the P600. Sure, there are instances of combined drivers for the Maxim PMICs such as the 77686/802 driver but that's actually the opposite of what Sammy did. Instead of making the actual driver smarter they just duplicated it. I'm starting to think that one of the reasons why Samsung don't want to provide documentation with their kernels is because of instances like this one: bloat, poor coding and lazy hacks.
Thought I'd also say that I made some progress with my other kernel tree (Linaro Stable Kernel - Linux v3.13) yesterday. It now supports the max77802 pmic and I've just begun pulling in the base which I will use for porting over the max77803 drivers. Everything compiles so far. Also, I've decided to just hire someone to port over the LCD driver as soon as I can afford it. So far it's the only driver that's an actual hindrance since it can't be found in any of Samsung's 3.10 kernel trees and I haven't been able to find any similar drivers either. If all turns out well, then maybe Sammy could be convinced to push it into mainline lol.
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.
The goal of this kernel is above all stability with the secondary goals of increased performance and increased battery life. I use this phone for several hours a day for work and therefore it must be reliable. I am not focusing on providing a million options for governors, etc. In addition to those main goals of the kernel, I have an additional secondary goal of removing as much HTC code as possible from the kernel.
This is based on the 2.04 kernel source release from HTC with a huge number of modifications. Thanks to faux123, showp, harsh, mdeejay, zarboz and dsb9938 whose kernels I have pulled some commits from.
The unique features of this kernel are:
New init.d scripts to allow some tweaking without needing any 3rd party apps
* See the next post for details.
Replaced HTC's mpdecision with a new custom hot-plug driver that I created:
* This hot-plug driver is more aggressive about bring cores on and off-line to match the load on the system.
* Bringing cores online earlier makes your phone more responsive / smooth.
* Taking cores offline earlier improves battery life.
* It ramps up very quickly on resume to avoid lag.
Replace HTC's thermald with a new custom thermal driver that I created:
* Unlike all other thermal drivers, it uses "trip-points" to let the phone tell the kernel when it is overheating. The other thermal drivers poll every X ms and read the temperature instead.
* By using trip-points, there is 0 battery consumption unless the phone is overheating.
* By using trip-points, there is an instant reaction to temperature changes.
* It's probably nearly impossible to cause thermal shutdown without being in a desert!
Replaced HTC's bluetooth drivers with Code Aurora Forums (CAF) version.
Replaced HTC's lightsensor table with one that is more sensible and that matches what other devices use. If you have custom auto-brightness settings, you'll probably need to tweak them after installing this kernel.
There are many additional changes to boost performance and battery life:
* Linaro -O3 compiled (Linaro 4.8).
* Overclocking from mdeejay's kernel.
* Underclocking to 192MHz.
* I disable tons of HTC debugging crap left enabled and needlessly consuming battery.
* Improvements to the core locking code of the kernel.
* Patches that transform traditional locks into RCU backed data structures.
* CAF version of the ondemand and conservative governors.
* hsic wakelock changes from dsb9938's kernel.
* CAF changes to power management to sleep faster and waste less CPU during suspend.
* Improved code for moving data to/from user-space and manipulating strings within the kernel.
Other features:
* Include all mainline Linux changes to keep up-to-date on bug fixes.
* Voltage control (faux123) to allow user-space under-volting.
* BFQ I/O scheduler.
* CAF lowmemorykiller.
* Force fast charge.
Links
A link to each version is included in the changelog entry. Scroll down to the changelog to download the latest version.
Source (GitHub):
* Kernel source
* Merging of upstream into the stock kernel
* Build tools
Installation Instructions:
If you are S-OFF you can flash the update.zip in recovery.
If you are S-ON, then after you flash the update.zip in recovery then, while still in recovery, you must run
Code:
adb pull /tmp/boot.img
<reboot into bootloader>
fastboot flash boot boot.img
Changelog:
Version 2.0.41: August 25, 2013: Linux 3.4.58, HTC colour "enhancement"
* Merged Linux versions 3.4.53 - 3.4.58
* Added the ability to enable / disable the HTC colour enhancement (this lets you see if you like it or not)
Version 2.0.38: July 7, 2013: Linux 3.4.52
* Linux version 3.4.51 / 52 merged in
* Reverted a small change to the PWM values used for the display (it wasn't giving any value so why change ti)
Version 2.0.34: June 24, 2013: colour enhancement, fixes, debug messages
* Toned done yet more HTC debugging messages
* Enable UTF-8 codepage support for Windows file-systems
* Fix error in HTC's light-sensor calibration table (overflows the 16-bit number they are using)
* Avoid buffer overflow in acdb driver
* Remove HTC's colour enhancement gamma correction (beaups)
Version 2.0.32: June 15, 2013: linux 3.4.49, scheduler & mutex improvements
* Linux 3.4.49
* Three scheduler performance improvements
* Move to more standard and slightly faster mutex implementation
Version 2.0.30: June 8, 2013: linux 3.4.48, small fixes
* Linux 3.4.48
* Fix CVE-2013-2595
* Decrease latency in cpufreq frequency changes
Version 2.0.27: May 26, 2013: init.d governor, 3.4.47
* Ability to specify the cpufreq governor at boot time (see second post).
* Linux 3.4.47
* Remove an annoying HTC debugging message
Version 2.0.26: May 23, 2013: init.d tweaks, 3.4.46, no default undervolting
* Added PVS information to /proc/cpuinfo in case you wanted to knoiw what it is for your phone.
* Linux upstream version 3.4.46
* Improve how I set the CPU frequences to safe levels for boot without having to reset them every time a core is hot-plugged in.
* New init.d scripts for some common tweaks (see post #2).
Version 2.0.23: May 13, 2013: Lightsensor fix, 3.4.45, faster freq. changes:
* Fix an error transcribing the lightsensor ranges into the source.
* Update to Linux 3.4.45
* cpufreq: use a high priority to target new frequencies to allow faster changes under load
Version 2.0.20: May 12, 2013: Lightsensor, 3.4.44, undervolt for "fast":
* Use a new lightsensor table to get a more granular light reading If you have custom auto-brightness settings, you'll probably need to tweak them after installing this kernel.
* Update to Linux 3.4.44
* Undervolted for devices binned "fast" by -100mV.
* CAF fix for cpufreq driver.
Version 2.0.17: May 7, 2013: Linaro 4.8.0 build, minor CAF fixes:
* Moved to updated Linaro 4.8.0 based toolchain (theoretically faster, less battery likely it's unnoticeable)
* CAF: change boot-up order for cpufreq
* CAF BT: recover from a hardware error by resetting the device
Version 2.0.15: May 2, 2013: boot hang fix, 3.4.43, CPU frequencies, brightness, misc fixes:
* Linux 3.4.43
* Small fixes from CAF (bluetooth, usb)
* Restore the CPU frequences/voltages from 1.x.y kernels (previously I was using HTC's new tables)
* simple_plug: keep cores online during boot
* use the correct brightness ranges for our display (HTC cut off the lowest brightnesses).
* fix a race condition on boot with the binder kernel services
Version 2.0.9: April 23, 2013: 3.4.41 and small fixes:
* Linux 3.4.41
* Small fixes from CAF
* Clean up some more HTC crap in the kernel
Version 2.0.6: April 17, 2013: boot changes, linux 3.4.40:
* Linux 3.4.40 (upstream).
* Limit CPU speeds during boot to stock speeds.
* Enable the thermal driver 5 seconds into the boot (previously was 30 seconds).
* Small changes to the ramdisk from the 2.04 update (I forgot these before).
Version 2.0.3: April 15, 2013: on_demand, battery, HTC spew:
* HTC insists on adding more and more debugging messages to the kernel log. Clean these up.
* OnDemand: revert a CAF change I made and disable io_is_busy.
* Remove HTC's over-volting for CPUs binned anything other than nominal.
* defconfig changes to ease building the kernel for CM10.1 (no you can't use this one for CM10.1!).
Version 2.0.0: April 11, 2013: 2.04 (OTA) source drop:
* Updated to Linux 3.4.39
* Updated to HTC's release of 2.04 source
* cgroup permissions fix
* Otherwise the same as 1.2.6
* Note: After running this for a day, I feel like the battery is draining faster and the phone is hotter than it should be. I'm looking into that.
Changelog from 1.2.x
Version 1.2.6: April 4, 2013: ramdisk fix, lowmemorykiller, hsic wakelocks:
* Fix a problem where the ramdisk was no longer disabling mpdecision and thermald. This issue causes a very minor additional battery drain that has now be fixed (Thanks t1gartist!).
* CAF updates to lowmemorykiller.
* Reapply elkay's HSIC fixes by pulling the real commits from CAF (instead of his hand copied commits) which fixes two problems in his commits.
1.2.2: April 1, 2013: linux 3.4.38, lag fixes, bluetooth drivers, cleanup:
* Undo some dubious commits (or extra code included in unrelated commits, what I meant by "early mistakes"). I reexamined every commit in the kernel to decide whether to keep it or remove it.
* Bluetooth drivers are the current CAF msm-3.4 drivers.
* Additional CPU speed and governor information added in /proc/cpuinfo.
* Cleaner patching to upstream linux (see my github repo for the clean upstream patching).
* Linaro -O3 compilation was redone from scratch because there were some problems found by kern3l in the original patches I pulled, I wanted to ensure that there were no other problems so I redid the work myself.
Changelog from the 1.0.x series:
1.0.27: Mar 25, 2013: thermald, simple_plug
* Make the previous changes to simple_plug less aggressive about turning cores back off when applications force them online. We now detect that this has occurred and give the application 2 minutes to be in charge before we force the state back to what we want.
* Change thermald default throttling to be slightly less strict.
1.0.25: Mar 21, 2013: Linux 3.4.37, simple_plug, performance
* Linux 3.4.37
* simple_plug: add a verify mode (every 5 seconds => almost 0 cost) that fixes the state when apps bring cores on/off-line (e.g. kernel tuner).
* rwsem performance improvements
* CAF improvements (correctness, performance) of the power management layer
1.0.21: Mar 16, 2013: Linux 3.4.36
* Linux 3.4.36
* Small bug fixes from CAF
1.0.18: Mar 7, 2013: Linux 3.4.35
* Linux 3.4.35
1.0.17: Mar 4, 2013: Linux 3.4.34, Linaro 4.7-2013.02, thermald fix
* Linux 3.4.34.
* Linaro 4.7: stopped using 4.8 beta builds due to stability fears and lack of apparent benefit from it. The latest 4.7 drop back-ports some optimizations anyway.
* lowmemorykiller: switch to the CAF version of the low memory killer.
* Fixed several bugs in HTC's thermal driver that could cause the termal driver to miss thermal events.
1.0.15: Feb 26, 2013: Battery optimization, performance, thermal & hotplug improvements
* governor: make ondemand the default governor
* GPU: Very minor GPU overclock to 487MHz (from mdeejay).
* msm_thermal: react better when temperature decreases.
* simple_plug: be slightly less aggressive about bringing cores online.
* New suspend mode PM_SUSPEND_FREEZE
* Oprimization for RWSEM lock handoffs.
* RCU locking in cpufreq!
* Disable more HTC debugging code.
1.0.11: Feb 22, 2013: Battery optimizations, Linaro 4.8 build, update.zip format
* Disable HTC's PNP power manager and adaptive policy services (used for thermald / mpdecision which are already disabled).
* Turn off all the kernel code that was polling to compute the state needed for thermald / mpdecision.
* Turn off a bunch of HTC statistic collection and debugging that isn't needed and wastes battery.
* Linux 3.4.33: fixes a kernel memory corruption/hang in all 3.0 and 3.4 kernels
* Sparkco's 4.8 Linaro build is now being used to compile the kernel
* Moved to update.zip format with less commonly used modules moved to loadable modules.
1.0.8: Feb 19, 2013: Switch to different OC values
* Now using mdeejay's over/unclocking (hopefully solving the L2 cache corruption panic).
* thermal driver is less aggressive about throttling the phone with an additional early step down to stock speed
(50C => 1.5GHz, 75C => 1.3GHz, 83C => 918MHz, 90C => 384MHz).
* Linux 3.4.32 (although no changes that would affect our phone).
1.0.7: Feb 15, 2013: thermal driver no longer polls for state
* Linux 3.4.31.
* Now using the 2013-01 build of the Linaro toolchain.
* Major rewrite of the thermal driver to remove polling (now uses essentially no power).
* Tweaks to the hot-plug driver to reduce CPU consumed to reduce power consumed.
1.0.5: miscellaneous optimizations
* Optimization: use optimized memcpy for user-space copies
* Update to linux 3.4.30
* Tons more cleansing of excessive debugging output
* Use RCU_FAST_NO_HZ as caf claims to have found that this improves battery life
* More linaro -O3 fixes from kern3l via dsb
1.0.2
* cm3629 driver, removed power button pocket check (sounds like a good idea, doesn't work and is a likely candidate for an infrequent sensor drain coming from the proximity sensor not turning off).
* cm3629 remove some unused functionality.
* Two small fixes from kern3l via dsb9938's kernel.
* clean some log messages.
1.0.0
* Merge linux 3.4.29
* simple_plug: a new CPU hot-plug driver (default)
* msm_thermal: a new thermal throttling driver (default)
* faux123's intelli_plug (disabled by default)
* faux123's intellidemand governor (default)
* disable mpdecision and thermald in initrd
* dsb9938's overclocking tables, GPU fix and more -O3 changes
* optimizations/fixes from faux123's mako kernel
* Based on elkay's LK kernel which is based on dsb9938's kernel.
* Includes all elkay's HSIC fixes, but nothing beyond that.
* Linaro -O3 compilation (zarboz) and other compiler flags (dsb9938).
* Disabled remote assistance because that just creeps me out.
* NTFS and CIFS.
* Various optimizations and improvements (faux123's mako kernel, similar to dsb9938's pulls from there).
* Force fast-charge (dsb9938).
* Voltage control (faux123).
* Latest OnDemand and Interactive governors from faux123's mako kernel.
* Large set of scheduler fixes / improvements (faux123).
* Underclocking (but not overclocking right now) to 192 MHz.
* BFQ I/O scheduler (default).
* Cleaned up debugging to make the kmsg more useful.
FAQ
sweep2wake: I have no plans to add that to this kernel at this time.
FAQs
init.d tweaks
I really like Zarboz's goal of trying to get rid of the need for 3rd party apps to make the common changes that we want to make to some of the configurable parameters of the kernel. I created some scripts that run on boot (init.d) because I install my kernel so many times that I would go insane if I had to use an installer. By using these scripts and configuration files on the sdcard, I can just configure it once and keep installing away to my heart's content.
After installing this kernel, there will be:
/system/etc/init.d/99crpalmer
run at boot, even if you switch to another kernel. It is safe to leave this file there and to let it run as it only makes changes if the kernel contains "crpalmer" in the version.
The tweaks are:
CPU Frequencies
* Frequencies loaded from /sdcard/crpalmer-cpufreq-min and /sdcard/crpalmer-cpufreq-max
* Governor loaded from /sdcard/crpalmer-cpufreq-governor
* If you specify either or both of these frequencies, it will lock down all of the CPU frequency controls. I had to do this because HTC overrides them in a script that is run very late in the boot process (thanks HTC!).
* E.g. adb shell su -c "echo 192000 > /sdcard/crpalmer-cpufreq-min"
* E.g. adb shell su -c "echo 1728000 > /sdcard/crpalmer-cpufreq-max"
* E.g. adb shell su -c "echo interactive > /sdcard/crpalmer-cpufreq-governor"
Undervolting
* + or - value loaded from /sdcard/crplamer-uv
* The undervolting in 2.0.23 for FAST binned CPUs would be specified as:
* E.g. adb shell su -c "echo -100 > /sdcard/crpalmer-uv"
Lightsensor
* My light sensor changes didn't sound like they worked well for everyone. If you don't like them you can disable them by:
* E.g. adb shell touch /sdcard/crpalmer-stock-lightsensor
HTC Colour "Enhancement"
* If this file is present then the stock colour "enhancement" will be used, otherwise it will be disabled.
* Introduced in kernel 2.0.41.
** E.g. adb shell touch /sdcard/crpalmer-color-enhancement
My WIFI Won't Turn On
If your WIFI won't turn on then the most likely cause is that either you didn't flash the boot.img (e.g. not S-OFF) or your modules don't match the kernel. To figure out what's wrong, first boot the ROM after having installed my kernel. Second, verify that you are running my kernel by running
adb shell cat /proc/version
and seeing that it says crpalmer in (it should match the version that you think you installed, but at least saying crpalmer is a good start). Then do:
adb shell dmesg -c
(turn on wifi)
adb shell dmesg
and look for an error that says crpalmer in it (something like a module version mismatch error). If you see that, it should tell you the version number of the modules that are installed and the version of the kernel.
Re: [Kernel] [Linaro] [Linux 3.4.29] Version 1.0.0 - Feb 7
Thanks for this. Looks good. :thumbup:
Sent from my ViperDNA
nice, moar kernel development :highfive:
welcome aboard
Re: [Kernel] [Linaro] [Linux 3.4.29] Version 1.0.0 - Feb 7
So no modules to flash?
Sent from my HTC6435LVW using Tapatalk HD
idkwhothatis123 said:
So no modules to flash?
Click to expand...
Click to collapse
That's right. No need to flash the return-to-stock modules either.
Thank you for this! I also find it hilarious that you including instructions for benchmarking. To this day I still wonder why people actually care about benchmarks as they have little to no impact on real world performance.
Re: [Kernel] [Linaro] [Linux 3.4.29] Version 1.0.0 - Feb 7
azndan2 said:
Thank you for this! I also find it hilarious that you including instructions for benchmarking. To this day I still wonder why people actually care about benchmarks as they have little to no impact on real world performance.
Click to expand...
Click to collapse
Self defense... I didn't want to deal with people getting 8K scores and blaming me.
Antutu is actually really useful for testing the thermal driver.
Very nice, does this have the latest changes that were just removed from elkays kernel? Also, could you add the lionheart gov?
Nice to see another kernel to choose from, I will give it a shot this weekend. Will you eventually put any you tweaks? Also, can this be flashed with FlashGui?
Re: [Kernel] [Linaro] [Linux 3.4.29] Version 1.0.0 - Feb 7
orangechoochoo said:
Nice to see another kernel to choose from, I will give it a shot this weekend. Will you eventually put any you tweaks? Also, can this be flashed with FlashGui?
Click to expand...
Click to collapse
just tried, flashgui won't even let you flash it. Gotta wait till I get home I guess!
Sent from my HTC6435LVW using Tapatalk 2
Thanks for giving it a shot.
Re: [Kernel] [Linaro] [Linux 3.4.29] Version 1.0.0 - Feb 7
codezzie said:
Very nice, does this have the latest changes that were just removed from elkays kernel? Also, could you add the lionheart gov?
Click to expand...
Click to collapse
I looked at elkays changes and it removes a background task that encourages a USB device to power down. This may or may not be a good thing. I'll see how elkay's testing goes before I pull in the change. If it goes well, I'll give it a try.
Re: [Kernel] [Linaro] [Linux 3.4.29] Version 1.0.0 - Feb 7
orangechoochoo said:
Nice to see another kernel to choose from, I will give it a shot this weekend. Will you eventually put any you tweaks? Also, can this be flashed with FlashGui?
Click to expand...
Click to collapse
What tweaks? It.already has a lot of improvements...
Any idea what flashgui accepts as input?
I didn't see any mention of gpu tweaks so I didn't want to make assumptions, hence my question.
EDIT: I just noticed my autocorrect changed "gpu" to "you" in my post you responded to.
Re: [Kernel] [Linaro] [Linux 3.4.29] Version 1.0.0 - Feb 7
crpalmer said:
Any idea what flashgui accepts as input?
Click to expand...
Click to collapse
Flashgui worked for me. Renamed file to "boot.img" and ignored the warnings. I like living on the edge. Booted up and shows this kernel version. Thanks for this.
Stay thirsty, my friends
Re: [Kernel] [Linaro] [Linux 3.4.29] Version 1.0.0 - Feb 7
Had a glitch with it already, phone was sleeping, got a message on gtalk and it locked full on vibration, blinking the led, wouldn't wake up and eventually rebooted after maybe 10 seconds. I've had this happen on one of the dsb kernels too, I think. Wiped caches again, hasn't occurred again so far.
Happened not 10 minutes after flashing it so I'm chalking it up to kernel making itself at home, just a note that it happened.
Edit: just rebooted again getting an email notification, UKB 1.3. Seems I can't receive a notification while the phone is sleeping or it jams up and reboots.
Sent from my HTC DNA
Re: [Kernel] [Linaro] [Linux 3.4.29] Version 1.0.0 - Feb 7
matteebee said:
Flashgui worked for me. Renamed file to "boot.img" and ignored the warnings. I like living on the edge. Booted up and shows this kernel version. Thanks for this.
Stay thirsty, my friends
Click to expand...
Click to collapse
Just did the same thing, was coming back to edit my last post lol
Sent from my HTC6435LVW using Tapatalk 2
pio_masaki said:
Had a glitch with it already, phone was sleeping, got a message on gtalk and it locked full on vibration, blinking the led, wouldn't wake up and eventually rebooted after maybe 10 seconds. I've had this happen on one of the dsb kernels too, I think. Wiped caches again, hasn't occurred again so far.
Happened not 10 minutes after flashing it so I'm chalking it up to kernel making itself at home, just a note that it happened.
Edit: just rebooted again getting an email notification, UKB 1.3. Seems I can't receive a notification while the phone is sleeping or it jams up and reboots.
Sent from my HTC DNA
Click to expand...
Click to collapse
After it reboots, can you try to get a log with
adb shell cat /proc/last_kmsg > last_kmsg.txt
and send a link to the last_kmsg.txt file?
orangechoochoo said:
I didn't see any mention of gpu tweaks so I didn't want to make assumptions, hence my question.
EDIT: I just noticed my autocorrect changed "gpu" to "you" in my post you responded to.
Click to expand...
Click to collapse
Ah, that makes more sense... I'm planning on including dsb's changes to any overclocking, etc. but I don't have the knowledge to tweak these settings myself.
duki994 Kernel for Stock TouchWiz LP ROMs
A personal project that had good results and I wanted to share it with others
It's based on official Samsung sources for Lollipop firmware.
Important note:
This kernel should work on any custom ROM that is stock lollipop based
Features:
* Wolfson Audio control (thanks to @AndreiLux)
* Battery charging control (thanks to @AndreiLux)
* CPU voltage control for both A7 and A15 cluster (thanks to @AndreiLux)
* Exposed all OPP voltage controls (thanks to @AndreiLux)
* Powersuspend v1.7 by @faux123 and @Yank555
* LMK, MM and FS powersuspend mods ported from @dorimanx's LG G2 kernel
* SCHED code fixes
* SCHED: HMP thresholds changed and new patches implemented
* Many changes related to ARM instruction code and lowlevel ARM core management
* Enabled NEON mode in kernel with full VFPV4 support
* Added new SHA256 and SHA512 NEON accelerated algortihms - now blazing fast
* UKSM (Ultra Kernel Samepage Merging) - algorithm that's better optimized than standard KSM
* WiFi standby wakelocks (PNO wakelock) reduced
* WiFi userspace power mode/DTIM change (for advanced users ONLY)
* WiFi driver switched from deprecated earlysuspend to use newer powersuspend driver (this is to fix some of bugs that could lead device kernel crash)
* NET updates
* Enabled all TCP congestion protocols and set Westwood as default (best wireless performance)
* Disabled KNOX
* SELinux disabled in kernel
* Fully configurable in Synapse (download from Google Play)
/* Important note to other devs */
You cannot include this to your ROMs. I can't be responsible if anything goes wrong, I can't help with any issues without knowing kernel version and users should be routed to this thread if they want this kernel, or if you recommend it. I think that it's best to separately view custom ROM and custom Kernel, so each dev (ROM or Kernel one) can work on bugs/features and make it as compatible as it can.
However, you can add this thread link and mention me in your thread, so people would know where to ask if some kernel problem arises
Warranty void
By flashing this kernel you will void your warranty. I'm not responsible if you brick your device, or if someone starts nuclear war.
Note:
Don't change voltages on "Busses" tab if you don't know what you are doing. It can reboot your phone if your memory controllers, ISP or MMC controllers can't handle low voltage.
WiFi pasword resetting fix:
Code:
1. open your build.prop file
2. find line ro.securestorage.support
3. change it from true to false (if not already false)
This line being on true will make your WiFi not work good with this kernel. This is due to Samsung's rooting restriction and other Samsung specific workarounds to stop rooting and flashing. Any custom ROM probably has this line changed to false.
Changelogs:
Version 1.4 BETA
Billion critical updates from my G900H version:
* MM code
* new LMK driver
* Exynos interactive governor updated
* IRQ code revamped
* OF code revamped
* New 8-band EQ sound-control
* Numerous ALSA updates and fixes
* Numerous Wolfson DAC driver updates
* MemInfo code updates
etc. list is enormous
Version 1.3
*MM page allocation changes. and others. Now more than 50% faster page_alloc
*RCU and SRCU updates from S6 and upstream + CAF
*NET updates
*USB fixes and updates
*dma mapping ARM fix
Version 1.2.1
*Synapse
->added ROW scheduler to test (experimental)
*Several BLOCK code updates and typo fixes. Some serious bugs fixed.
*Fully updated ROW I/O sched added (experimental)
Version 1.2
* Synapse:
-> disabled min cpu freq control. not needed.
-> added new I/O schedulers
* Massive updates to BLOCK, SHCED, MM, WORKQUEUE critical code
* Added FIOPS and BFQ I/O schedulers
* EXT4 updates to fix possible kernel crashes
* ZSWAP now uses ultra fast and light on cpu LZ4 compression
* CPUFREQ optimizations
* Updated BFQ, FIOPS, DEALINE scheds with fixes and optimizations
Version 1.1
*Synapse:
* Added live cpu stats for all 8 cores (quad A7 and quad A15 cores)
* Added live CPU temperature monitoring
* Added live battery temperature and health status
* Disabled broken battery input current feature (shows 0mA for our PMIC chip)
* Added misc tab:
+ ability to take logcat,dmesg,last_kmsg
+ HMP Little packing switch ON/OFF and explanation
* Added optimized ARM RWSEM algorithm
* Fixed HMP so HMP little packing would work good with our implementation
* thermal IPA(Intelligent Power Aware) now updates power tables immediately when voltage changed from Synapse
* entropy depletion fixes
* Enabled FRANDOM random number generator module for more entropy and less lag
* Added NEON instruction accelerated SHA256/SHA224 algorithm. Now we have SHA384/SHA512, SHA256/SHA224 and SHA1 algorithms NEON accelerated - blazing fast
* HMP little packing switch for Synapse
Experimental option made by nvidia. It groups tasks so more of them would be scheduled across power saving cores (A7 cores in our CPU). It may or may not save battery depending on your usage.
Downloads:
Here it is
https://app.box.com/s/vt70dzo7fzgnlyik4mxkiaaj7xkhjaot
Special thanks:
@AndreiLux for his awesome Synapse app, audio control, charging control, sources and many features/updates and upgrades to Exynos kernel code
@UpInTheAir for his source that I looked when I had bugs, and for his fixes/workarounds
@dorimanx for inspiring me to start developing and his LMK and MM mods
@bonuzzz for his custom KitKat kernel for Galaxy Alpha and his sources
@apb_axel for UKM and his scripts that helped me a lot in making custom Synapse config
XDA:DevDB Information
G850, Kernel for the Samsung Galaxy Alpha
Contributors
duki994
Source Code: https://github.com/duki994/SM-G850_Kernel_LP/
Kernel Special Features:
Version Information
Status: Beta
Current Beta Version: 1.0
Beta Release Date: 2016-08-12
Created 2015-11-02
Last Updated 2016-08-12
Reserved
How to build this kernel guide
PREREQUISITES
What you need installed to compile
gcc, gpp, cpp, c++, g++, lzma, lzop, ia32-libs flex
If on 64bit Linux, install gcc multilib
Project folder structure
--project_root/ #### can have any name
-----ramdisk_source/ ## defined by RAMDISK_TMP var in script
-----ramdisk_tmp/ ## defined by RAMDISK_DIR var in script
-----kernel_source/ #### can have any name
-----RELEASE/
TOOLCHAIN INFO
Toolchain is already into kernel dir. You just need to have
correct folder structure and run this script. Everything will be auto-built
FLASHABLE ZIP
Flashable zip will be located in project_root/RELEASE directory
and will have name Kernel-slte.zip
All other explanations here:
https://github.com/duki994/SM-G850_Kernel_LP/blob/master/build_kernel.sh
Clone ramdisk source in ramdisk_source
Clone kernel in kernel_source folder
Be sure to have project directory structure as written above
After that, you just need to run:
sudo bash build_kernel.sh
in kernel folder. And voila. After finished you have Kernel-slte.zip in RELEASE directory
If it show any errors, open kernel source and type in terminal:
chmod -R 755 *
Then repeat sudo bash build_kernel.sh
awesome job, thank you
finally undervolt .. yay
ayamgoreng said:
awesome job, thank you
finally undervolt .. yay
Click to expand...
Click to collapse
When you have time, report how it works
Sent from my LG-D802 using Tapatalk
Is it possible to other variants like Galaxy Alpha SM-G850L Korean? Thanks
duki994 said:
When you have time, report how it works
Sent from my LG-D802 using Tapatalk
Click to expand...
Click to collapse
I reduce voltage A15,A7 (every speed) by roughly 20mv
gaming (coc,asphalt,etc) for roughly 1 hour; result=stable :good:
edit: volume in the audio also work, louder headphone.
Thanks, I'll try it.
how the battery with this kernel?
gtrs36 said:
Thanks, I'll try it.
how the battery with this kernel?
Click to expand...
Click to collapse
Battery? It's better than stock for me. For screen on, this morning I had 50mins SOT and 87% battery left. That's even better than my LG G2, which is a beast according to tests
My father uses Galaxy Alpha, and yesterday he managed to get 4h SOT with HSDPA data on.
When screen off (in suspended mode) it's very low power consumption due to Powersuspend driver. It's better than stock.
exaflare said:
Is it possible to other variants like Galaxy Alpha SM-G850L Korean? Thanks
Click to expand...
Click to collapse
I have no access to G850L model. I don't know if it will work.
During this week, if I have enough time, I'll download G850L source and build it with all mods/features and give you to test it
thanks duki994.
which app I need install to control on the kernel?
hi!
1. how do You undervolt by 20mv, in synapse i have steps like 1x,xxMv and can set up -25Mv??
2. I have strange warning message after installed this kernel. it says phone needs to reboot. after reboot the same. just annoying
duki994 said:
Battery? It's better than stock for me. For screen on, this morning I had 50mins SOT and 87% battery left. That's even better than my LG G2, which is a beast according to tests
My father uses Galaxy Alpha, and yesterday he managed to get 4h SOT with HSDPA data on.
When screen off (in suspended mode) it's very low power consumption due to Powersuspend driver. It's better than stock.
Click to expand...
Click to collapse
did you UV or what settings did you use ?
m_p11 said:
hi!
1. how do You undervolt by 20mv, in synapse i have steps like 1x,xxMv and can set up -25Mv??
2. I have strange warning message after installed this kernel. it says phone needs to reboot. after reboot the same. just annoying
Click to expand...
Click to collapse
1. Our voltage regulator accepts 6.25mV step. So you can UV/OV in multiples of 6.25. When you do math, 6.25mV x 4 = 25mV
You can't UV -20mV. You can UV -18.75m (3 x 6.25mV). Next step is -25mV (4 x 6.25mv).
Ursurobertt said:
did you UV or what settings did you use ?
Click to expand...
Click to collapse
No UV. All stock. Only changed earpiece volume (incall speaker volume) to higher (+4dB if I recall good from this morning). It's for better hearing incall
UV generally doesn't reduce battery consumption (it's maybe 1%-3% less power usage). Real benefit of UV is lower CPU heat and prolonged life of motherboard.
Some chips can't handle UV at all. Some can be UV by as much as -150mV. It all depends on specific chip that came out of fabric process. Note that UV brings instability on some devices.
Sent from my LG-D802 using Tapatalk
duki994 said:
Battery? It's better than stock for me. For screen on, this morning I had 50mins SOT and 87% battery left. That's even better than my LG G2, which is a beast according to tests
My father uses Galaxy Alpha, and yesterday he managed to get 4h SOT with HSDPA data on.
When screen off (in suspended mode) it's very low power consumption due to Powersuspend driver. It's better than stock.
Click to expand...
Click to collapse
hi dude
what setting are used on your father Alpha,stok or I should change in synapse
hensk said:
hi dude
what setting are used on your father Alpha,stok or I should change in synapse
Click to expand...
Click to collapse
Look at post above yours. I explained everything
Sent from my LG-D802 using Tapatalk
recent button does not works after flashing this kernel.. recent button works fine with stock kernel...
likhon02 said:
recent button does not works after flashing this kernel.. recent button works fine with stock kernel...
Click to expand...
Click to collapse
On which ROM are you? Everything works for me on stock. I have to see if anything changes it.
Did you set secure storage to false in build prop?
I'l automate that in next build.
Kernel doesn't mess with options like recent buttons and Java written parts of Android OS.
Sent from my LG-D802 using Tapatalk
duki, you didn't answer to my question.
gtrs36 said:
duki, you didn't answer to my question.
Click to expand...
Click to collapse
Please read OP before asking. Everything is said there.
Synapse is the app with which you can change settings of this kernel.
duki994 said:
On which ROM are you? Everything works for me on stock. I have to see if anything changes it.
Did you set secure storage to false in build prop?
I'l automate that in next build.
Kernel doesn't mess with options like recent buttons and Java written parts of Android OS.
Sent from my LG-D802 using Tapatalk
Click to expand...
Click to collapse
I am on ozcan rom 4.1. my recent button only works with Nordic based stock which is NEE G850FXXU2COI3 5.0.2 11.09.2015 5614954 and ozcan rom..and with any other rom like rr and cm12.1 my recent button does not work.. secure storage is false by default on build.prop .
ZigZag Kernel
Disclaimer:
Code:
#include
/*
* Your warranty is now void
*
* I am not responsible for bricked devices, dead SD cards, thermonuclear
* war, or the current economic crisis caused by you following these
* directions. YOU are choosing to make these modificiations, and
* if you point your finger at me for messing up your device, I will
* laugh at you.
*/
Features:
Zipped using anykernel2 by @osm0sis
Latest linux patches
-O3 Optimizations
a57/a53 optimizations
CDROM emulation drive support (DriveDroid support)
CPU Overclock
Wake Gestures: doubletap2wake, sweep2wake
UKSM(Ultra Kernel Samepage Merging)
KCAL Color control
F2FS
Frandom
Zram, Zsmalloc, and Zpool
UFS ICE driver
Advanced TCP Congestion controls
Kexec Hardboot Support
Franco Sound Control
Governors: ElementalX, ZZMoove, Impulse and the usual
I/O Schedulers: BFQ, SIOPlus and the usual
Many, many fixes to many stuff from CAF
More fixes to stuff, check git
Downloads: ZigZag builds
Note: Builds with '-exp' in the suffix are not meant for daily users! Try at your own risk!
Credits:
Google
@faux123
@flar2
@franciscofranco
@Imoseyon
@savoca
CAF
CM
Changelogs on post #2
Enjoy people!
XDA:DevDB Information
ZZ Kernel, Kernel for the Huawei Nexus 6P
Contributors
##W4TCH0UT##
Source Code: https://github.com/W4TCH0UT/ZZ_angler
Kernel Special Features:
Version Information
Status: Stable
Current Stable Version: R6
Stable Release Date: 2016-06-14
Created 2016-04-19
Last Updated 2016-06-14
Changelogs:
R6
* Latest f2fs patches
* Latest linux patches(Updated to 3.10.102)
* Usual tweaks from CAF
* Use franco's sound control instead of faux's
* Same Changelog for R6-exp with minor CAF experimental tweaks
R5-exp
* Enhanced sound quality(patches from CAF)
* Enhanced video quality(patches from CAF)
* Enhanced camera quality(patches from CAF)
* Fixes to major things
* Governors: ZZMoove, Impulse
R5
* Governors: ZZMoove, Impulse
R4
* More F2FS patches from kernel.org
* Upstream patches from google and CM
* Whole lotta fixes from CAF(check git for wide list of commits)
* Enable Zram, Zsmalloc and Zpool
* Squashfs file system intro
R3
* CDROM emulation drive support (DriveDroid support)
* Latest F2FS patches from kernel.org
* -O3 optimizations
* Kill some logspam
* Fixes from CAF
R2
* UKSM(Ultra Kernel Samepage Merging) 0.1.2.3
* Frandom
* Implemented UFS ICE driver
* I/O Schedulers: SIOPlus
* Advanced TCP Congestion controls(default: cubic)
* Fix Sound issues
R1
* Initial build
Added to Nexus 6P index thread:
[INDEX] Huawei Nexus 6P
Good job on the support for F2FS. I hope more devs start to add support for their kernels and roms soon as F2FS continues to mature.
Hello supported Ciyanogen? Very thanks
Regards
Enviado desde mi Nexus 6P mediante Tapatalk
Welcome. :laugh::laugh::laugh::laugh::laugh:
iron maiden01 said:
Hello supported Ciyanogen? Very thanks
Regards
Enviado desde mi Nexus 6P mediante Tapatalk
Click to expand...
Click to collapse
Yes works on cm/aosp too(not sure about aosp though)
##W4TCH0UT## said:
Yes works on cm/aosp too(not sure about aosp though)
Click to expand...
Click to collapse
Works on AOSP (PureNexus) though I believe there is a sound issue. Have to double check and report back later.
HesThatGuy said:
Good job on the support for F2FS. I hope more devs start to add support for their kernels and roms soon as F2FS continues to mature.
Click to expand...
Click to collapse
F2FS support is great and all but worthless at the moment since we don't have a way to format the three partitions ( system, data, cache) to really take advantage of potential gains f2fs as the offer.
The solution is pretty straightforward but I don't have the knowledge to know if it's feasible or not.
The road block is the fact that the 6p cache partition is under 1GB, which is a minimum requirement for f2fs to work.
There is TWRP custom build out there that's support f2fs but it only works on the data partition and that's meaningless as f2fs relies heavily on using the cache partition.
We could increase the size of the cache partition easily because the data partition is right next to it on the device and we could take space from data and allocate it to cache. I just have no idea of the possible repercussions of resizing partitions on an Android device.
My guess is that it would screw with Google releases and maybe there's something in the bootloader or kernel that needs to be edited so the device knows which blocks belong to which partition.
If it isn't a big deal to resize partitions, then its trivial. Use the latest f2fs-tools off github and make a TWRP kernel.
I remember jt1134 modifying partitions for new ROMs to work on the Fascinate. Even coding RIL stuff single handedly for CM. I miss those days, when locked bootloader wasn't even heard of ?
ZigZag R2 is out now!
R2
* UKSM(Ultra Kernel Samepage Merging) 0.1.2.3
* Frandom
* Implemented UFS ICE driver
* I/O Schedulers: SIOPlus
* Advanced TCP Congestion controls(default: cubic)
* Fix Sound issues
Click to expand...
Click to collapse
Kernel is stable from R2 onwards!
Cheers!
shag_on_e said:
I remember jt1134 modifying partitions for new ROMs to work on the Fascinate. Even coding RIL stuff single handedly for CM. I miss those days, when locked bootloader wasn't even heard of
Click to expand...
Click to collapse
Making a custom TWRP that allows the 6P to fully use F2FS has been on my "to-investigate/to-do" list for a while now. I've msg'd a couple people with experience in modifying the TWRP kernel and a few devs to see the feasability about changing partition sizes, but have gotten no responses
* UKSM(Ultra Kernel Samepage Merging) 0.1.2.3
* Implemented UFS ICE driver
* I/O Schedulers: SIOPlus
* Fix Sound issues
Click to expand...
Click to collapse
I saw these and thought "oh thats new".. But I'm perplexed. Your kernel is a fork of CyanogenMod/android_kernel_huawei_angler with only a few commits done recently, https://github.com/W4TCH0UT/ZZ_angler/commits/53a3c39ecd976558df111fcd874e2d5edc391d1d. If that's the wrong repo/branch somehow then my bad but I just followed the link in OP.
Not sure why you're enabling ICE (Inline Crypto Engine) when the OEMs won't even use it because its unstable. Ofc HW backed encryption is better than software-only but Google also vastly improved it's keystore on M (compare the Nexus 6 encryption performance to the 6p).
From Android Explorations @ http://nelenkov.blogspot.com/
Unfortunately, while the current implementation performs pretty well, there are still some problems, especially when the device is in sleep mode. If the devices is in sleep mode for a relatively long period of time, read errors can occur, and the userdata partition may be mounted as read only (which wreaks havoc with the system's content providers); the device may even power off. While a reboot seems to fix the issue, if the the userdata was mounted read-only, the SQLite databases storing system configuration and accounts may get corrupted, which in some cases can only be fixed by a factory reset. Thus, hardware-accelerated disk encryption is unfortunately currently not quite suitable for daily use on the Nexus 6.
Click to expand...
Click to collapse
CAF even tried using it for our chipset then reverted it:
ICE (Inline Crypto Engine) support requires Key restoration after UFS power collapse. This operation adds long latency to exit from power collapse and will impact the performance even when ICE is not in use.
Click to expand...
Click to collapse
I mean, its worth experimenting with for sure. You don't until you try. But ICE has been around for a long time and there must be a reason no one uses it.
And I don't see where you added UKSM. Could you link the merge?
bobbarker2 said:
I saw these and thought "oh thats new".. But I'm perplexed. Your kernel is a fork of CyanogenMod/android_kernel_huawei_angler with only a few commits done recently, https://github.com/W4TCH0UT/ZZ_angler/commits/53a3c39ecd976558df111fcd874e2d5edc391d1d. If that's the wrong repo/branch somehow then my bad but I just followed the link in OP.
Not sure why you're enabling ICE (Inline Crypto Engine) when the OEMs won't even use it because its unstable. Ofc HW backed encryption is better than software-only but Google also vastly improved it's keystore on M (compare the Nexus 6 encryption performance to the 6p).
From Android Explorations @ http://nelenkov.blogspot.com/
CAF even tried using it for our chipset then reverted it:
I mean, its worth experimenting with for sure. You don't until you try. But ICE has been around for a long time and there must be a reason no one uses it.
And I don't see where you added UKSM. Could you link the merge?
Click to expand...
Click to collapse
https://github.com/W4TCH0UT/ZZ_angler/commit/0b91f685a025db3c2c549aad51a2565fb1467755 , this is the commit for uksm, following it were some missing bits for it.
And, yes it is a fork of cm to support cm based ROMs.
If you could check the merges, then there's a lot that has been done.
I thought it would be a good way to experiment using the ICE driver as to what it brings. I know 6p's encryption system is better than 6, but what's the harm in experimenting?
##W4TCH0UT## said:
https://github.com/W4TCH0UT/ZZ_angler/commit/0b91f685a025db3c2c549aad51a2565fb1467755 , this is the commit for uksm, following it were some missing bits for it.
And, yes it is a fork of cm to support cm based ROMs.
If you could check the merges, then there's a lot that has been done.
I thought it would be a good way to experiment using the ICE driver as to what it brings. I know 6p's encryption system is better than 6, but what's the harm in experimenting?
Click to expand...
Click to collapse
There's no harm at all, except for users who will try this kernel and experience the instability and latency issues described above. If the users don't realize that you are experimenting with some untested features then they will just end up writing this kernel off and never use it. So maybe it would be a good idea to put a disclaimer or perhaps two different buildsl?
And it isn't just the 6p that was improved it was all Android 5.0 and up.
This ice chip has been on Qualcomm SOCs for a long time now and by that I mean since at least 2011. I'm sure they've made improvements over the past five years, but I suspect there's a reason no developer uses this in their kernel. Qcoms website has very little detail about even the existence of ICE, most of what we know has come from then submitting it to get FIPS certified.
bbarker2 said:
There's no harm at all, except for users who will try this kernel and experience the instability and latency issues described above. If the users don't realize that you are experimenting with some untested features then they will just end up writing this kernel off and never use it. So maybe it would be a good idea to put a disclaimer or perhaps two different buildsl?
And it isn't just the 6p that was improved it was all Android 5.0 and up.
This ice chip has been on Qualcomm SOCs for a long time now and by that I mean since at least 2011. I'm sure they've made improvements over the past five years, but I suspect there's a reason no developer uses this in their kernel. Qcoms website has very little detail about even the existence of ICE, most of what we know has come from then submitting it to get FIPS certified.
Click to expand...
Click to collapse
I have not experienced 1 damn issue and been on R2 since release. in fact im getting better battery life than both kylo and elemental. im not sh***ing on their kernels, just stating my experience thus far. on latest DU TEST 4/18
opz187 said:
I have not experienced 1 damn issue and been on R2 since release. in fact im getting better battery life than both kylo and elemental. im not sh***ing on their kernels, just stating my experience thus far. on latest DU TEST 4/18
Click to expand...
Click to collapse
I kept getting a phone and SystemUI force close on 4/18. About to try zigzag 2 then retry 4/18 DU, then maybe the combo of the two.
shag_on_e said:
I kept getting a phone and SystemUI force close on 4/18. About to try zigzag 2 then retry 4/18 DU, then maybe the combo of the two.
Click to expand...
Click to collapse
Try clean flashing the rom, then the kernel.
Regards
I can't speak on the battery life yet, but in terms of smoothness & scrolling; this kernel is ?. (Stock x Zigzag).
Any recommended settings @##W4TCH0UT##
Sent from my Nexus 6P using XDA-Developers mobile app
This kernel is running really really smooth. I am very impressed so far with the performance and also battery life seems great as well. Please keep up the great work, as i see no reason to change kernels now. Only thing i ask for is maybe drive droid support and f2fs. Thanks so much
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?