[KERNEL] valexKernel [SM-P600 | CM13/AOSP 6.x ]

Search This thread

AndyYan

Recognized Contributor
Jan 30, 2012
4,442
3,784
Beijing
Can't imagine this is still usable for the latest nightlies... The sleep-of-death problem is partially eased with this, and the governors behave much better than stock. Nicely done!

Sent from Google Nexus 6P @ CM13
 

Andmoreagain

Senior Member
Dec 19, 2013
101
191
vhyfxm.jpg


I'm working on porting my kernel to the latest CM13 Marshmallow builds. Currently testing and tinkering. Should be up for download here in a few days.
 

Andmoreagain

Senior Member
Dec 19, 2013
101
191
Do I still have permission to use in BrokenOS? Been so long since if seen you around.

Of course, just go ahead! See my updated description:

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.
 

Andmoreagain

Senior Member
Dec 19, 2013
101
191
@Andmoreagain I am adding governors to your kernel but I am getting a weird error: http://pastebin.com/JBZnSNH9 . Here is my source https://github.com/Project-lt03wifi/kernel_lt03wifi_orbiter . These are the same governors I used in LP.

Yeah this has to do with some of the scheduler updates. The sched/rt code has been moved around and it now has its own header. MAX_RT_PRIO is now declared in include/linux/sched/rt.h instead of include/linux/sched.h. Add the following line to the file that's giving you the error and it should solve the issue:

Code:
#include <linux/sched/rt.h>

Edit: Saw you already fixed this in your source. Let me know if the issue persists and I'll try to look into it further :)
 
Last edited:
  • Like
Reactions: Orion116

Orion116

Senior Member
Nov 20, 2014
955
527
Yeah this has to do with some of the scheduler updates. The sched/rt code has been moved around and it now has its own header. MAX_RT_PRIO is now declared in include/linux/sched/rt.h instead of include/linux/sched.h. Add the following line to the file that's giving you the error and it should solve the issue:

Code:
#include <linux/sched/rt.h>

Edit: Saw you already fixed this in your source. Let me know if the issue persists and I'll try to look into it further :)

Yeah asked someone someone else for help too, and they pointed that out. Also do you know what is causing the display to freeze randomly. And which TC are you using.



P.S. Man do I sound needy, hahaha
 

Andmoreagain

Senior Member
Dec 19, 2013
101
191
Yeah asked someone someone else for help too, and they pointed that out. Also do you know what is causing the display to freeze randomly. And which TC are you using.

Don't know about the display, sorry. I currently assume most of the display issues are caused by flaws in the CM code itself or the android device tree for our device. I at least haven't done any modifications to the display drivers in the kernel.

This is the toolchain I'm using: http://www.mediafire.com/?9h19841nsm44z58

Edit: Also, a small tip. If you run into compiling errors such as "undeclared identifier" errors you can refer to http://lxr.free-electrons.com to search where things may be located in linux versions above 3.4. This is useful for kernels with lots of backports such as mine where things may have been moved or renamed.
 
Last edited:
  • Like
Reactions: Orion116

Orion116

Senior Member
Nov 20, 2014
955
527
Don't know about the display, sorry. I currently assume most of the display issues are caused by flaws in the CM code itself or the android device tree for our device. I at least haven't done any modifications to the display drivers in the kernel.

This is the toolchain I'm using: http://www.mediafire.com/?9h19841nsm44z58

Edit: Also, a small tip. If you run into compiling errors such as "undeclared identifier" errors you can refer to http://lxr.free-electrons.com to search where things may be located in linux versions above 3.4. This is useful for kernels with lots of backports such as mine where things may have been moved or renamed.

Thanks mate.
 

Andmoreagain

Senior Member
Dec 19, 2013
101
191
Which governors are included? I flashed but only see, userspace/interactive/ondemand

I only include the governors that are found in the mainline kernel. Same with the ioscheds, with the exception of bfq since it's regularly maintained. Since I'm working with backports and mainline updates I don't add custom features that aren't maintained for different versions of linux to avoid potential future conflicts.
 
  • Like
Reactions: hipocrazy

hipocrazy

Senior Member
Mar 13, 2008
318
54
Any further thought to adding other governors? Im sure you are busy with builds and such but thought id ask.

Thanks!
 

Top Liked Posts

  • There are no posts matching your filters.
  • 17
    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
    9
    Anyway, back on topic: @Andmoreagain: Are you still working on 8 core support? Especially now that you've got the switcher and power management to work? Or there are more pressing issues currently? I think there are boards (like ODROID-XU2) running Exynos 5420 with fully functioning core migration...

    Yes I am. However, even though the switcher will probably work with the 3.4 kernel there is still a problem with device tree support. In order for this to work properly I would have to rebase the kernel on either the ChromiumOS 3.8 branch or continue my work with the 3.13 branch based on Linaro Stable Kernel.

    I've been experimenting with both and I kind-of managed to merge in 3.8's support for the exynos5420 platform, but device tree support was still too messed up and gave me some werrors that I just couldn't resolve. It particularly had to do with the clock drivers and the CCI driver as DT support is just too incomplete in 3.4. Otherwise the board files and drivers compiled just fine.

    Since I've already begun adding necessary support to the 3.13 branch I think I'll just stick with that one. I'm just searching for a developer that would be willing to port over the display driver since that's the biggest hindrance here and I'm not skilled enough to do it myself.

    I'm not using the upstream MCPM code in my main release yet, though I did figure out a way to add partial support for it with the stock switcher at some point. Thanks to my terrible organizing skills I just can't remember if I actually kept this implementation on a separate branch or if I accidentally discarded it somehow. I'm gonna try and see if I can do it again so I can test it. If all goes well then it will be included in the next release.
    8
    Just to let you guys know, I’m working on a brand new kernel tree based on the upstream android and android-exynos trees. It’s more or less free of Samsung bloat and debug spam and has better compatibility with upstream cherry-picks. I’ve located all of the upstream patches and backports used by Samsung in the stock kernel and all that’s additionally specific to the stock kernel has either been added separately or simply left out depending on whether it’s really needed. Additionally, my backports will be updated with bugfixes and improvements. Due to popular demand I will also be pulling in additional governors and the stock optimized ondemand governor has been renamed to “exynosdemand” so that the upstream ondemand governor can more easily be updated. Finally, it will have all the new features of the (still-unreleased) unified Exynos 5420 kernel..
    6
    Before you go into Bug Mode I would like to chime-in & advise that I once removed the s-pen just to see what it looked like, stuck it back in & never touched it since. Recently I began using a standard type rubber tipped stylus for basically checking little boxes and keyboard accuracy & have never had an issue what-so-ever, of coarse i have absolutly no artistic talent when it comes to drawing so this maybe of no importance to the issue.
    Additionally...
    IMHO your work on the Valex kernel is outstanding :good::good::good: and its compatability with Temasek is most excellent (excluding the drawing issue which i too would believe falls more on a Samsung driver issue than your kernel). Hopfully you will squash the s-pen bug quickly & be able to concentrate on the Linux/kernel mods. :)

    Good luck in bugland, thanks for your awesome kernel work & where is your "Donate" link? (you will surely need beverages while hunting) ;)

    It must have something to do with the memory management (mm) updates. It's basically on par with Linux 3.7 at the moment, though a few things are still in 3.4 territory. I'm going to try to sync mm and arch/arm/mm completely with 3.7 and see if that fixes the issue. Otherwise I'll just have to hard reset the branch to an earlier point in history and do more frequent testing between the cherry-picks and merges.

    The whole area of memory management is probably the most sensitive part of the kernel when it comes to making changes to it, but then again these are all mainline commits. It's a bit strange how it's only affecting the wacom/s-pen input drivers. Most likely the culprit is just one single commit that needs to be reverted lol.

    Unfortunately I don't have much time to maintain my kernel at the moment since I just started my first semester at uni (multimedia) but I'll fix this as soon as I find the time to go through this.

    As for a donation button, I should definitely arrange that. For those who are hungry for true octa support then I'm also working on a bare-bone kernel project based on Android's 3.14 kernel branch (gonna try migrating to 3.18 later on since it has better support for our SoC). I've pulled in most of the core drivers needed for booting, but porting over the LCD display driver is posing an issue because it's a territory that I'm simply not familiar with. A co-worker just got me in contact with a programmer who's willing to take a look at it but he expects some payment in return.

    The ultimate goal for the new kernel is also utilizing its multiplatform support. That way, the same kernel image could be successfully flashed on literally any Exynos5420-based device. Maybe I should just start a new thread for this and cross-post it over at the Tab S/Note Pro/Note 3 forums as well...
    5
    Mind if I include some of this in my feature rich kernel[emoji6]

    Sent from my SM-P600 using Tapatalk

    Do it! :good: