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

Orion116

Senior Member
Nov 20, 2014
955
527
0
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.


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.
What ROM do you test your kernel on?

I waited 10 minutes for the tablet to boot. I used thishttps://play.google.com/store/apps/details?id=eu.chainfire.liveboot to get a log. I notice as it booted there were a bunch of errors. I will upload the log for you.

Sent from my SCH-R530U using Tapatalk
 
Last edited:

Andmoreagain

Senior Member
Dec 19, 2013
101
191
0
Thanks I'll have a look at it as soon as I can. If there turn out to be some critical errors I'll throw together a debug build to get a more detailed log.

I'm using Temasek CM12.
 
  • Like
Reactions: Orion116

Orion116

Senior Member
Nov 20, 2014
955
527
0
Thanks I'll have a look at it as soon as I can. If there turn out to be some critical errors I'll throw together a debug build to get a more detailed log.

I'm using Temasek CM12.
Thanks man. Do you use hangouts? It maybe easier to troubleshoot that way.

I will also experiment with building it inline with BrokenOS. Then adding features to it.

Sent from my SCH-R530U using Tapatalk
 
Last edited:

Andmoreagain

Senior Member
Dec 19, 2013
101
191
0
I've never used hangouts but I think that might be a good idea. I'll have to do it after the weekend though since I'm out of town with some very poor connection.
 
  • Like
Reactions: Orion116

Andmoreagain

Senior Member
Dec 19, 2013
101
191
0
I thought you're not able to use custom kernels on the temasek builds?
Where did you read that nonsense? :eek:

I took a log using chainfire's app as well but made it only show the kernel dmesg log plus logcat errors. The actual errors seem mostly to be coming from android's side and not the kernel, and none of them seemed to be critical ones. I'll test it with BrokenOS as well when I have time and see what I can find. :)
 

Attachments

Orion116

Senior Member
Nov 20, 2014
955
527
0
Where did you read that nonsense? :eek:



I took a log using chainfire's app as well but made it only show the kernel dmesg log plus logcat errors. The actual errors seem mostly to be coming from android's side and not the kernel, and none of them seemed to be critical ones. I'll test it with BrokenOS as well when I have time and see what I can find. :)
Yeah custom kernels bootloop on every ROM but the one they are compiled for it seems. I can try letting the tablet sit for an hour and see if it boots. I will also try building it inline with BrokenOS for some reason custom kernels seem to bootloop on certain Roms.

Sent from my SM-P600 using Tapatalk
 

Andmoreagain

Senior Member
Dec 19, 2013
101
191
0
Yeah custom kernels bootloop on every ROM but the one they are compiled for it seems. I can try letting the tablet sit for an hour and see if it boots. I will also try building it inline with BrokenOS for some reason custom kernels seem to bootloop on certain Roms.

Sent from my SM-P600 using Tapatalk
There was also an issue with RaymanFX's kernel source some time ago that has since then been fixed. I remember trying to build it while it was still broken and it just wouldn't boot no matter what. After syncing with RaymanFX a few weeks later everything was fine again and I've been able to boot my kernels without an issue.

This temporary issue in the kernel was also causing joshndroid's temasek builds to bootloop before someone pointed out to him that he just had to sync his kernel source with RaymanFX if I remember correctly.

It actually seems quite ridiculous that installing a new kernel should cause bootloops unless the kernel itself was broken somehow. Also, I use Philz recovery since it doesn't seem to suffer the same issues as TWRP. Maybe that helps...

Edit:

In any case there is something fishy about these bootloops because I haven't been experiencing this issue. I think it might be a good idea to get to the bottom of this.

My setup:

Base source: Latest RaymanFX tree
- Compiled outside of any particular ROM source
Toolchain: Cortex-A15 optimized Linaro GCC 4.9.3
Rootfs: Prebuilt CM12.1 boot.img - I use ArchiKitchen to unpack/repack
- I have also enabled support for all decompression methods in the kernel config which may or may not help.
Recovery: Philz Touch, because it has never failed me unlike TWRP which tends to mess things up :S

I'll install BrokenOS today and see if I get these same strange results. I find it very unlikely that the kernel itself is the issue here. I think it's more likely that the issue may be differences in the ramdisks, which could be resolved by packing several different ramdisks within the boot.img and tell it to decompress them according to the build.prop information.
 
Last edited:
  • Like
Reactions: Orion116

Orion116

Senior Member
Nov 20, 2014
955
527
0
There was also an issue with RaymanFX's kernel source some time ago that has since then been fixed. I remember trying to build it while it was still broken and it just wouldn't boot no matter what. After syncing with RaymanFX a few weeks later everything was fine again and I've been able to boot my kernels without an issue.

This temporary issue in the kernel was also causing joshndroid's temasek builds to bootloop before someone pointed out to him that he just had to sync his kernel source with RaymanFX if I remember correctly.

It actually seems quite ridiculous that installing a new kernel should cause bootloops unless the kernel itself was broken somehow. Also, I use Philz recovery since it doesn't seem to suffer the same issues as TWRP. Maybe that helps...

Edit:

In any case there is something fishy about these bootloops because I haven't been experiencing this issue. I think it might be a good idea to get to the bottom of this.

My setup:

Base source: Latest RaymanFX tree
- Compiled outside of any particular ROM source
Toolchain: Cortex-A15 optimized Linaro GCC 4.9.3
Rootfs: Prebuilt CM12.1 boot.img - I use ArchiKitchen to unpack/repack
- I have also enabled support for all decompression methods in the kernel config which may or may not help.
Recovery: Philz Touch, because it has never failed me unlike TWRP which tends to mess things up :S

I'll install BrokenOS today and see if I get these same strange results. I find it very unlikely that the kernel itself is the issue here. I think it's more likely that the issue may be differences in the ramdisks, which could be resolved by packing several different ramdisks within the boot.img and tell it to decompress them according to the build.prop information.
BrokenNote kernel is using the latest raymanFX updates and it bootloops on temasek.

Sent from my SCH-R530U using Tapatalk
 

Andmoreagain

Senior Member
Dec 19, 2013
101
191
0
Works on P601 ?
Not yet, but I plan on adding support for P601 as well. :)


In other news: I have resolved the bootloop issue. When the kernel is installed in such a way that only the kernel itself is replaced instead of the entire boot partition, the ROM will not bootloop. I assume it's because the boot partitions differ slightly depending on the ROM such as that a Temasek boot.img won't work with BrokenOS etc.

This here should work regardless of the ROM in question. Tested and working normally on BrokenOS: https://drive.google.com/file/d/0B7Ui4IHpV48JV0Q5el91X3ljVXc/view?usp=sharing
 

dimex

Senior Member
Nov 28, 2012
746
143
63
Running your kernel. Antutu score puts it about 200 points less than the stock Temasek kernel.

It feels snappy though, I'll continue running it to see what happens.
 

Andmoreagain

Senior Member
Dec 19, 2013
101
191
0
Running your kernel. Antutu score puts it about 200 points less than the stock Temasek kernel.

It feels snappy though, I'll continue running it to see what happens.
That may well be. I did the Antutu benchmark twice and got some very different results each time. The second time it outperformed stock. I guess these benchmark apps aren't all that reliable in the end.

You can also try tweaking some settings with Kernel Aduitor or a similar app. I have KSM turned on with its default settings and LMK set to very aggressive. Then I'm also finishing up and testing the next release which includes all the custom IO schedulers, BFQ being my personal recommendation (I'm actually surprised it hasn't been mainlined yet).
 

dimex

Senior Member
Nov 28, 2012
746
143
63
That may well be. I did the Antutu benchmark twice and got some very different results each time. The second time it outperformed stock. I guess these benchmark apps aren't all that reliable in the end.

You can also try tweaking some settings with Kernel Aduitor or a similar app. I have KSM turned on with its default settings and LMK set to very aggressive. Then I'm also finishing up and testing the next release which includes all the custom IO schedulers, BFQ being my personal recommendation (I'm actually surprised it hasn't been mainlined yet).
I'm mirroring your settings now. What's funny is I'm trying to see if the Note 10.1 2014 works as my note taking device for college. I was using Windows tablets before and dual booting Android-x86. I'm kind of spoiled after running Android natively on Core i3/i5/i7; it's just so smooth and fast on those processors.

Only reason I'm trying to use the Note 10.1 2014 is because the size/weight is absolutely perfect.
 

Stevethegreat

Senior Member
Nov 28, 2010
1,200
326
0
@dimex: Core i's come with the notable downside of added weight and low(er) battery life. I was just using Xperia Tablet Z4 and I can confidently say that we already are there (a tablet as smooth as a laptop only with a fraction of its weight) but in our tablets a lot of it eclipsed -sadly- by the bad drivers on one hand (lack of documentation from Samsung's part), lack of optimized software (if you're using TW rom) and of course the hardware itself is 2 years old already...

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...