Database Develop

[DEVS ONLY][BCM21553] Samsung Galaxy Pocket GT-S5300 (Cori) Development Discussion

General informations:
This thread's aim is only to represent a central meeting and discussion point for BCM21553 developers and, in particular, for the open Kernel/ROM sources development for the Samsung Galaxy Pocket GT-S5300 (codenamed Cori).
Information for common users:
As already described in the previous section, if you are not a developer, please restrict your posts to the general discussion thread so that developers can maintain good communication. Every post that is not strictly respecting these rules will be reported to the forum moderators. Thanks for your understanding.
For any other BCM21553 device related question or information, please, use this thread as a reference point, instead:
[DEVS ONLY][BCM21553 series] CyanogenMod 11 for BCM21553 Development Discussion

As someone already might know, I'm streambinder, from MoltenMotherBoard team.
I have already followed some projects for the GT-S5300, but especially kept in contact
with some of the events related to the porting of ROM and Kernel sources for BCM21553 chipset based devices.
In this precise moment, the sources in my possession allow you to be able to compile
a bugfree CWM 5.0.2.8 (based on CyanogenMod 7 code) with a kernel based on the Samsung stock one.
The only - fundamental - problem was due to the fact that unless I hadn't used the prebuilt INIT binary
token in the Samsung stock firmware boot.img, the phone would not work - or, better, boot up.
This means that until the situation - regarding this issue - doesn't change, our access to the porting of custom ROM
would be barred.
Recently, I decided to give Cori another chance and rework my sources, looking at the wonderful work brought
by the BroadcomCM team on CyanogenMod 9 (in particular, thanks to @bieltv.3 and @Alberto96) and @psyke83 on CyanogenMod 11.
They've not only been able to run these two ROMs in a more or less crude way, but this developer has been able to write
the necessary strings to make the INIT binary of some of these BCM21553 devices opensource.
Strong of this informations, I readjusted some of the sources of BroadcomCM's CyangenMod 9, which includes
all the progress carried out by both the team and psyke83, in order to make them work even on Cori,
and am now next to the first test of the CWM 6.X.X.X, based on IceCreamSandwich code.
At the same time, @akhbh is working on the KitKat code based CWM.
I hope I can give more information about any progress as soon as possible.

The General Discussion thread for non-development issues is here:
*.[DISCUSSION] CyanogenMod 11 For Galaxy Pocket GT-S5300 Discussion Thread

Made a first test of CWM based on CyanogenMod 9 code.
It seems it cannot flash it as it weighs so much compared to its partition configuration value: in fact, the maximum boot partition size is set up to 5.0MB, but the compiled boot.img weighs 5.3MB.
Will have to resize its weight in order to make it fill into the partition.
@akhbh, have you had any complication in these terms, with CyanogenMod 11 sources?
@psyke83, what do you suggest to do? Do you think an increasement of boot partition would be a better idea?

streambinder said:
Made a first test of CWM based on CyanogenMod 9 code.
It seems it cannot flash it as it weighs so much compared to its partition configuration value: in fact, the maximum boot partition size is set up to 5.0MB, but the compiled boot.img weighs 5.3MB.
Will have to resize its weight in order to make it fill into the partition.
@akhbh, have you had any complication in these terms, with CyanogenMod 11 sources?
@psyke83, what do you suggest to do? Do you think an increasement of boot partition would be a better idea?
Click to expand...
Click to collapse
No, I didn't faced those complications. My boot.img weighted around 4.5 MB in lzma compression mode. In gzip, it increased to more than 5 mb.

akhbh said:
No, I didn't faced those complications. My boot.img weighted around 4.5 MB in lzma compression mode. In gzip, it increased to more than 5 mb.
Click to expand...
Click to collapse
Perfect.
Which kernel have you based your build on?

streambinder said:
Perfect.
Which kernel have you based your build on?
Click to expand...
Click to collapse
Well, I took the GeTux kernel for cori, had to change the board name though and then compile it. CWM was booting even before changing the board name but there was no reaction from the phone on trying to boot cm9/cm11
And after changing board name, a black screen on trying to boot
Another info: When tried to merge cori source into the bcm21553 common one, it did compile but gave bootloop of GT-S5300 logo on trying to boot as well as when trying to go in CWM.
Bieltv.3 recommended to use cori source instead of the bcm21553 common one so we used cori sources

akhbh said:
Well, I took the GeTux kernel for cori, had to change the board name though and then compile it. CWM was booting even before changing the board name but there was no reaction from the phone on trying to boot cm9/cm11
And after changing board name, a black screen on trying to boot
Another info: When tried to merge cori source into the bcm21553 common one, it did compile but gave bootloop of GT-S5300 logo on trying to boot as well as when trying to go in CWM.
Bieltv.3 recommended to use cori source instead of the bcm21553 common one so we used cori sources
Click to expand...
Click to collapse
I suggest to use our Kernel sources for now, too: it will automatically bypass few errors/issues/bootloops that we cannot now fight with.
The most important thing is to make INIT working from sources (hope it will be working
on my CM9 sources, too) and check that every our configuration is correctly working and
making Cori boot into recovery.
Once we'll make it perfectly working without any kind of issue, will be the right time to try
to make Cori supported with the BC21553-common kernel.

streambinder said:
I suggest to use our Kernel sources for now, too: it will automatically bypass few errors/issues/bootloops that we cannot now fight with.
The most important thing is to make INIT working from sources (hope it will be working
on my CM9 sources, too) and check that every our configuration is correctly working and
making Cori boot into recovery.
Once we'll make it perfectly working without any kind of issue, will be the right time to try
to make Cori supported with the BC21553-common kernel.
Click to expand...
Click to collapse
Okay, I will use your kernel sources and try if something is changed once I reach home. For now, I neither have this device nor a PC, as I'm in another city.
Will be keenly watching your work. Will start after reaching home around the end of September

akhbh said:
Okay, I will use your kernel sources and try if something is changed once I reach home. For now, I neither have this device nor a PC, as I'm in another city.
Will be keenly watching your work. Will start after reaching home around the end of September
Click to expand...
Click to collapse
No problem, mate.
Here you have every source in my possession:
platform_kernel_samsung_cori
platform_device_samsung_cori
Keep in contact with me, as I will need some informations by you.
Anyway I'm now making another build, keeping some not so much important binaries excluded, so that I can make the compiled boot.img fill into our little Cori's boot partition. I know it's a dirty workaround, but if it works, I'll use it untill @psyke83 will suggest me a better way to do.

streambinder said:
No problem, mate.
Here you have every source in my possession:
platform_kernel_samsung_cori | github.com
platform_device_samsung_cori
Keep in contact with me, as I will need some informations by you.
Anyway I'm now making another build, keeping some not so much important binaries excluded, so that I can make the compiled boot.img fill into our little Cori's boot partition. I know it's a dirty workaround, but if it works, I'll use it untill @psyke83 will suggest me a better way to do.
Click to expand...
Click to collapse
have u tried to build cwm v6 from cm9 source ??

cleverior.ipul said:
have u tried to build cwm v6 from cm9 source ??
Click to expand...
Click to collapse
Of course, mate. I'm working on it, right now.
It doesn't seem to boot, strange if the same INIT binary sources are working for @akhbh.
#UPDATE
In order to troubleshoot, I'll give you some info.
For his build I used these sources:
platform_kernel_samsung_cori
platform_device_samsung_cori
android_device_samsung_bcm21553-common
Applied some lines on our bcm21553-bootimg.mk, too, in order to exclude parted and mke2fs and make the compiled boot.img weigh less.
@cleverior.ipul, can you link me your kernel sources, as akhbh said he used your ones for CM11.
@akhbh, which modifies have you applied in order to compile CWM based on CM11 code? Which device tree?
#UPDATE 2
Attached my compiled boot.img.
If anyone of you would extract it (you can easily use this tool: bootimgtools - read how to use it in the README) and make a diff with the CM11 one (just extract the ramdisk of both boot.imgs and - in the terminal - use this command: diff -urN /path/to/cm9/ramdisk /path/to/cm11/ramdisk > diff.patch), would make to me a huge favour.
Let me know.

streambinder said:
Of course, mate. I'm working on it, right now.
It doesn't seem to boot, strange if the same INIT binary sources are working for @akhbh.
#UPDATE
In order to troubleshoot, I'll give you some info.
For his build I used these sources:
platform_kernel_samsung_cori
platform_device_samsung_cori
android_device_samsung_bcm21553-common
Applied some lines on our bcm21553-bootimg.mk, too, in order to exclude parted and mke2fs and make the compiled boot.img weigh less.
@cleverior.ipul, can you link me your kernel sources, as akhbh said he used your ones for CM11.
@akhbh, which modifies have you applied in order to compile CWM based on CM11 code? Which device tree?
#UPDATE 2
Attached my compiled boot.img.
If anyone of you would extract it (you can easily use this tool: bootimgtools - read how to use it in the README) and make a diff with the CM11 one (just extract the ramdisk of both boot.imgs and - in the terminal - use this command: diff -urN /path/to/cm9/ramdisk /path/to/cm11/ramdisk > diff.patch), would make to me a huge favour.
Let me know.
Click to expand...
Click to collapse
I think we didn't had significant changes. Perhaps the same as totoro. But, that resulted in the internal_sd not mounting error in cwm.
Sadly, as said before, I am away from my home city and can't provide the files to you and can't do the boot.img diffs as well
Try to ask psyke83, he might have a solution for that

akhbh said:
I think we didn't had significant changes. Perhaps the same as totoro. But, that resulted in the internal_sd not mounting error in cwm.
Sadly, as said before, I am away from my home city and can't provide the files to you and can't do the boot.img diffs as well
Try to ask psyke83, he might have a solution for that
Click to expand...
Click to collapse
Then, if you didn't make any massive change upon the sources, then I'll only try using your kernel.
Can you give me your kernel sources, mate, please?

streambinder said:
Then, if you didn't make any massive change upon the sources, then I'll only try using your kernel.
Can you give me your kernel sources, mate, please?
Click to expand...
Click to collapse
Currently, I can provide you the boot.img only. For the sources, @cleverior.ipul can provide the kernel sources coz as said earlier, his kernel is used. Well, we were working together to bring cm11 but weren't successful

akhbh said:
Currently, I can provide you the boot.img only. For the sources, @cleverior.ipul can provide the kernel sources.
Click to expand...
Click to collapse
Ok, please send it to me, will compare it with my package.

streambinder said:
Ok, please send it to me, will compare it with my package.
Click to expand...
Click to collapse
Here it is:
http://www.4shared.com/zip/1nKFbOJ2ba/ccccGetux_CM11.html

streambinder said:
Of course, mate. I'm working on it, right now.
It doesn't seem to boot, strange if the same INIT binary sources are working for @akhbh.
#UPDATE
In order to troubleshoot, I'll give you some info.
For his build I used these sources:
platform_kernel_samsung_cori
platform_device_samsung_cori
android_device_samsung_bcm21553-common
Applied some lines on our bcm21553-bootimg.mk, too, in order to exclude parted and mke2fs and make the compiled boot.img weigh less.
@cleverior.ipul, can you link me your kernel sources, as akhbh said he used your ones for CM11.
@akhbh, which modifies have you applied in order to compile CWM based on CM11 code? Which device tree?
#UPDATE 2
Attached my compiled boot.img.
If anyone of you would extract it (you can easily use this tool: bootimgtools - read how to use it in the README) and make a diff with the CM11 one (just extract the ramdisk of both boot.imgs and - in the terminal - use this command: diff -urN /path/to/cm9/ramdisk /path/to/cm11/ramdisk > diff.patch), would make to me a huge favour.
Let me know.
Click to expand...
Click to collapse
here the link source https://github.com/cleverior/android_kernel_samsung_cori
i've changed the board name. If your device can not boot after using the zImage from this source, then rename init.bcm21553.rc to init.gt-s5300.rc.

@streambinder, what is grom? As bieltv.3 said that init built grom for cori is required to fix adb over cwm recovery. If adb gets working, then possibly the black screen while booting cm11 might get fixed

akhbh said:
@streambinder, what is grom? As bieltv.3 said that init built grom for cori is required to fix adb over cwm recovery. If adb gets working, then possibly the black screen while booting cm11 might get fixed
Click to expand...
Click to collapse
Sincerely don't what are you talking about.
Anyway, have to try to understand where's the problem with the not-booting CWM.
Will try with your sources and let you know.

[MODS DELETE THIS THREAD] exNoShadez-eas

Mod edit: Thread closed on owner's request!
exNoShadez-EAS Kernel
FEATURES
- Current LTS release -> Linux-3.18.114
- Energy Aware Scheduling
- Schedutil (default Cpu Governor)
- RCU infrastructure backport (with expert mode enabled)
- Cpu-Boost / Input Boosting (enabled by default)
- BINFMT_MISC support (NOT mounted on boot).
- Kernel Hardening/Protection (CopperheadOS/Grsec/Pax Marlin kernel hardening features)
- leds-qpnp: Notification LED control - V1.1c (Boeffla) - Adapted for Marlin
- Binder_rt = My own re-implementation of AOSP Binder that uses rt_mutexes; supporting priority inheritance
- Improved scheduling/determinism for high priority threads/tasks
- Backported Scheduling, Locking and Workqueue subsystem code from Newer Linux kernels.
- Audio Driver enhancements / backports (from Wahoo/Pixel 2)
- Sound/Audio driver Tweaks (bug fixes, scheduling improvements)
- forced Interrupt threading enabled
- Wifi Mac Address Randomization
- WireGuard VPN kernel module support (more info soon)
- KCal Advanced Colour control
- Improved ASLR (in kernel)
- USB Fast Charge
- Wake Gestures
- GCC 6/7+ Fixes
- Built with GCC-8.x-dev
- and more
Contains code from everywhere: Code Aurora, Flar2/Marlin, CopperheadOS, AOSP, Project-EAS, Freak7/Kirisakura, Linaro, Pixel 2 kernel sources, mainline linux and elsewhere. Modifications and backports by me, as well.
BACKGROUND
I wanted a kernel for My Pixel that had 'all of the things', it didn't exist... So I'm working on my own kernel. I try to balance Security/hardening, experimental features with high Performance and battery life. <- not an easy task! ... Some of the security features do come with overhead, but if you use apps that are CPU heavy / processing and/or require low latency - they will perform well (at the cost of chewing some battery life, of course).... Battery life and SOT are very reasonable though.
WARNING / VERY IMPORTANT: This kernel isn't compatible with installing TWRP ~> meaning; you must use the fastboot version of TWRP (used in RAM) , flash the kernel and NOT install TWRP to your system (the kernel is too big for TWRP to co-exist).... This may sound inconvenient, but there are a number of valid reasons to avoid reducing a kernel's size in order to support TWRP installation, in the boot partition.
***Fun facts on this subject below => in the 2nd post: PLEASE READ: to understand my motivation***
TWRP REMOVAL
*To remove TWRP from your system; You need the stock boot.img from your running/current firmware (which is inside of the factory image zips) or use the Nov Stock boot.img provided here. Then it's as simple as flashing the boot.img to wipe TWRP;
fastboot flash boot_a /path/to/boot.img
fastboot flash boot_b /path/to/boot.img
Stock 8.1 July 2018 Boot.img => https://github.com/nine7nine/Apps/raw/master/SailfishStockJulyBoot.img
Now you can proceed with using the TWRP fastboot boot.img to flash my kernel, magisk/supersu or whatever else....
Fastboot twrp boot image => https://dl.twrp.me/sailfish/twrp-3.2.2-0-sailfish.img
WARNING: This shouldn't need to be said, but we did have someone who did this, so I'm adding a sticky/warning here; do NOT EVER re-lock your bootloader after flashing any kind of custom software, kernels, etc to your device - *it will brick your phone*. Meaning you are screwed would need an RMA / replacement device ... everyone in the XDA community should know better, but still; worth mentioning....
IMPORTANT:
Before asking questions; Please read through the thread (starting with the last few pages) - I shouldn't need to be repeatedly answering the same questions over and over again. It's good practice to get into the habit of reading through threads before asking questions in any thread on XDA, as more often then not; you're question has probably been answered. Thanks!
EXNS-EAS KERNEL DOWNLOAD:
JULY 2018 OREO 8.1 RELEASE exNoShades-eas Kernel Flashable zip
https://github.com/nine7nine/Apps/raw/master/exNoShadez_eas_v2.8.2_f94351f.zip
It is stable, high performance and very responsive...
Important: You will need root; I don't support non-rooted devices && some features require it. I recommend using Magisk; https://forum.xda-developers.com/apps/magisk/beta-magisk-v13-0-0980cb6-t3618589 ...
NOTE: Make sure to flash the latest Magisk beta *before* flashing the kernel zip. ...
More Background / Important Notes:
Binder_RT:
My own port and re-implementation of the Binder Kernel Driver; a slightly modified version of The AOSP binder.
Binder_RT uses rt_mutexes as opposed to mutexes for locking in Binder, ion, ashmem, etc... rt_mutexes support priority inheritance and should improve determinism in Binder, speed up IPC, Ion and Ashmem => Allowing applications that require low-latency, tight deadlines, low jitter and deterministic behaviour to perform better ~ This re-implementation is proving to be the great for those types of applications. The goal here is to help ensure that the Kernel and Binder's high priority && time critical threads and tasks are properly prioritized... Example; audio buffers arriving on time / no buffer underruns... *Further development work is planned to research, experiment with and improve Binder_RT.
rt_mutex documentation, for those interested;
https://github.com/nine7nine/Marlin_exns-eas/blob/EXNS_EAS/Documentation/locking/rt-mutex.txt
https://github.com/nine7nine/Marlin_exns-eas/blob/EXNS_EAS/Documentation/locking/rt-mutex-design.txt
CPU-Boost / Input Boosting:
Touch inputs boost CPU frequencies (thus improves performance and responsiveness).
# Cpu-boot / Input boost settings
write /sys/module/cpu_boost/parameters/input_boost_enabled 1
write /sys/module/cpu_boost/parameters/input_boost_freq "0:1363200 1:0 2:1900800 3:0"
write /sys/module/cpu_boost/parameters/input_boost_ms 100
IO/ CPU Governors:
This kernel doesn't include a thousand io/cpu governors. IO-wise; CFQ is the default, but we've got a few in there. chose your poison, but know that the majority of my testing is centered around cfq and deadline. CPU Governor-wise the common Linux CPU governors are there; along with Sched and Schedutil....
Stick with Schedutil - on idle, it draws very little power and in most 'peak performance situations, it should do very well..... I'm getting great battery life, sot and performance.
Managing Kernel Settings:
Get EX Kernel Manager - my original code on github was forked from EX kernel, before rebasing it - but EXKM will give you access to 99% of my kernel's settings.
My 8.1 Kernel Sources: https://github.com/nine7nine/Marlin_exns-eas
Donations via PayPal very much appreciated. I do put a significant amount of energy and time into researching, development, testing / QA and also providing support/help to end-users... It's definitely not mandatory to donate; but If you appreciate the effort, see value or benefits from using my kernel on your device and can afford to; Use the "Donate to me" button or the below link... It makes a big difference. thanks!
https://www.paypal.me/jrdnjhnstn

Why TWRP Installations are NOT supported:
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
(and why I'm not using it!)
Most custom/android kernel devs are using the above configuration in kernel compilation, which is arguably very BAD... I understand that boot partitions are small and the desire to install TWRP to them, thus there is a need to reduce the kernel's size....and yes, this will achieve that - However;
1. SUSE, RedHat, etc (Enterprise linux) disable CONFIG_CC_OPTIMIZE_FOR_SIZE -> it's original use case has proven to be invalid. Even Google (in their own documentation) advise against using this; https://source.android.com/devices/tech/perf/boot-times ....
2. It suppresses useful compiler warnings....
3. As SOCs have become more powerful, google has come to the same conclusion that Enterprise Linux did back in 2012.
4. by turning off CONFIG_CC_OPTIMIZE_FOR_SIZE, we achieve better performance, boot time and better cache utilization.
Clark Williams / Redhat Bugzilla said:
* Cause: CONFIG_CC_OPTIMIZE_FOR_SIZE set with assumption that smaller code would yield hot cache lines and good performance
* Consequence: this config caused gcc to generate jump-to-jump code which causes cache line bouncing, hurting performance
* Fix: turn off CONFIG_CC_OPTIMIZE_FOR_SIZE
* Result:slightly larger kernel but better cache utilization
Click to expand...
Click to collapse
(The Above is quoted from Clark Williams, A Senior Software Architect @ RedHat -> https://bugzilla.redhat.com/show_bug.cgi?id=796297)
I know of no other way to significantly reduce kernel size. Disabling some debugging, unneeded features, etc helps - but not enough.... I am focusing on optimization, using newer builds of GCC/Linaro, performance enhancements, fixing compilation errors, etc, etc -> these things are more important than trying to support TWRP installation. Therefore; I do NOT support installing TWRP....

I like it so far, very good kernel.

Awesome! Always nice to have choices
I've seen you post around that you made x change to your own kernel, glad you finally made it public!
Does it have all of franco's wakelocks blocked by default?

グリッチ said:
Awesome! Always nice to have choices
I've seen you post around that you made x change to your own kernel, glad you finally made it public!
Does it have all of franco's wakelocks blocked by default?
Click to expand...
Click to collapse
hey, it includes franco's wakelocks stuff. I don't think all are blocked, I actually don't touch them in my init rc. ... but some are blocked by default, for sure. can be set by user...
yeah, I've got my kernel to a point now, where it is somewhat unique && is drawing in most of the best features from every custom kernel for the pixel (my opinion). very stable too, thus far. so makes sense to make it public.
it's got the RCU (read copy update) infrastructure from linux-4.9... a ton of core, sched, Walt, etc from linux-4.4+ (specifically, from EAS-Project / msm8998 OP5 - which was painful to backport. wish we didn't have a 3.18 kernel. lol) afaik, it's the only Marlin kernel with Dynamic Stune Boost and aside from CopperheadOS; the only marlin kernel with a subset of the PAX/grsec kernel security enhancements and the Mac randomization... also has all of the audio enhancements from the kernel ur running ?

siheals said:
I like it so far, very good kernel.
Click to expand...
Click to collapse
Hey! thanks for testing it out. let me know how things go, your impressions, etc.
I'll be updating this kernel constantly, so if u end up liking it; you can expect that it will always include security patches, linux LTS incremental patches, etc...
it's my daily driver, so i keep on top of it.

Superb! Thanks for clarifying.
I will give it a run when November update releases cuz I'm lazy >.< but am excited and looking forward to it ^_^

グリッチ said:
Superb! Thanks for clarifying.
I will give it a run when November update releases cuz I'm lazy >.< but am excited and looking forward to it ^_^
Click to expand...
Click to collapse
no probz. As soon as the november updates arrive, i will be adding whatever patches are needed... so expect that to be there...
i also pull from Code Aurora msm-3.18 for 8996, so my kernel gets updates to drivers, core, etc that google hasn't picked up yet.

Just Testing 3.18.79 + latest Code Aurura updates for today ....AND;
re-enabling a hardening feature that I thought was draining battery life (Likely not, was probably another removed patch - that isn't in the current release.)
I'll update the link later on and - on my github; where I link to for downloads; there will be older releases labeled - ie:
exNoShadez_eas.zip (current release / link) will become -> exNoShadez_eas_3.18.78_oct.zip,
when it is replaced by 3.18.79 + other updates / patchwork.... The current release will always be -> exNoShadez_eas.zip
UPDATE:
While I haven't updated exNoShadez_eas.zip link/version, * I have posted a zip with the above changes - I'll be testing it for a while before updating the link because it's hard to gauge battery life without a lot of testing / time spent.... So I would say, if anyone is eager - they can test it, but wait at least 12-24hours from testing the current available release - so you can actually make some sort of real-usage comparision.
link: https://github.com/nine7nine/Apps/raw/master/exNoShadez_eas_3.18.79_harden.zip

Glad to see you have posted this man. Setting up a pixel for my friend and as i was browsing the forums noticed you have a lot of good kernel work. Was literally about to PM you a few days ago for your kernel and then happened to see this post today. Can't wait to try it out!

Warrimonk said:
Glad to see you have posted this man. Setting up a pixel for my friend and as i was browsing the forums noticed you have a lot of good kernel work. Was literally about to PM you a few days ago for your kernel and then happened to see this post today. Can't wait to try it out!
Click to expand...
Click to collapse
All good, man.
It only makes sense that I would share my kernel, when I felt it was ready for that - just keep in mind, that for now - I have marked it as Beta / Testing, as it's pretty new (although, aside from the EAS code / Dynamic Stune Boost - the rest has been thoroughly vetted)....
So yeah, give it a run, let me know how things go! thanks

Unsure if I am doing something wrong or not, but when I try to flash your kernel I get an error stating : "New Image larger than boot partition. Aborting...."
EX Kernel flashed fine. Using TWRP 3.1.1-1

Warrimonk said:
Unsure if I am doing something wrong or not, but when I try to flash your kernel I get an error stating : "New Image larger than boot partition. Aborting...."
EX Kernel flashed fine. Using TWRP RC1.
Click to expand...
Click to collapse
Why aren't you using the newest stable version of TWRP?
RC1 = release candidate 1
afaik, latest release is 3.1.1-1 stable for the pixel.... https://dl.twrp.me/sailfish/
Using an old version might be your issue. Update, then try.

nine7nine said:
Why aren't you using the newest stable version of TWRP?
RC1 = release candidate 1
afaik, latest release is 3.1.1-1 stable for the pixel.... https://dl.twrp.me/sailfish/
Using an old version might be your issue. Update, then try.
Click to expand...
Click to collapse
Apparently I am using TWRP3.1.1-1 . The thread was called RC1 So I mistakenly assumes that was still the current version.

Warrimonk said:
Apparently I am using TWRP3.1.1-1 . The thread was called RC1 So I mistakenly assumes that was still the current version.
Click to expand...
Click to collapse
Can confirm this, I'm on 3.1.1-1 too and got this issue.
I'm running 8.0.0 (OPR3.170623.008, Oct 2017) build.

Keasby said:
Can confirm this, I'm on 3.1.1-1 too and got this issue.
I'm running 8.0.0 (OPR3.170623.008, Oct 2017) build.
Click to expand...
Click to collapse
kk. I'll look into this - I (obviously) do not have this problem..... What firmware images do you use?
I'm on Rogers/Canada, maybe the boot partition is a different size on some firmwares (?)....
I can also look at shrinking the boot.img, which could fix it. My boot.img is slightly bigger than the shipped boot.img and I do have an idea on how to shrink it a bit, you'll have to wait until later on for me to look at it though / not home right now.

nine7nine said:
kk. I'll look into this - I (obviously) do not have this problem..... What firmware images do you use?
I'm on Rogers/Canada, maybe the boot partition is a different size on some firmwares (?)....
I can also look at shrinking the boot.img, which could fix it. My boot.img is slightly bigger than the shipped boot.img and I do have an idea on how to shrink it a bit, you'll have to wait until later on for me to look at it though / not home right now.
Click to expand...
Click to collapse
32MB is the boot image max size AFAIK.

nine7nine said:
kk. I'll look into this - I (obviously) do not have this problem..... What firmware images do you use?
I'm on Rogers/Canada, maybe the boot partition is a different size on some firmwares (?)....
I can also look at shrinking the boot.img, which could fix it. My boot.img is slightly bigger than the shipped boot.img and I do have an idea on how to shrink it a bit, you'll have to wait until later on for me to look at it though / not home right now.
Click to expand...
Click to collapse
Maybe it's caused by the image size. Other custom Kernels are sized bout 13mb.
I'm running the Google Stock Build OPR3.170623.008, October 2017.
Hope you can fix it - TIA!

nine7nine said:
kk. I'll look into this - I (obviously) do not have this problem..... What firmware images do you use?
I'm on Rogers/Canada, maybe the boot partition is a different size on some firmwares (?)....
I can also look at shrinking the boot.img, which could fix it. My boot.img is slightly bigger than the shipped boot.img and I do have an idea on how to shrink it a bit, you'll have to wait until later on for me to look at it though / not home right now.
Click to expand...
Click to collapse
Personally I tried on these 2 firmwares:
sailfish-ota-opr3.170623.008
sailfish-ota-opr6.170623.012
The phone was originally a Project Fi device.. if that matters. Dev which firmware and TWRP are you using?

Warrimonk said:
Personally I tried on these 2 firmwares:
sailfish-ota->>>>opr3.170623.008<<<<<
sailfish-ota-opr6.170623.012
The phone was originally a Project Fi device.. if that matters. Dev which firmware and TWRP are you using?
Click to expand...
Click to collapse
I'm using the latest twrp-3.1.1-1 (but and idk if this makes a difference or not), I only use the twrp fastboot img (Ihave ZERO reason to actually install TWRP on my system).... and also, Others have installed and are using my kernel - so it must be a difference in firmwares / boot partition size (or image size)
Keasby said:
Maybe it's caused by the image size. Other custom Kernels are sized bout 13mb.
I'm running the Google Stock Build >>>>>OPR3.170623.008<<<<<, October 2017.
Click to expand...
Click to collapse
So yeah, I'm using a different build **OPR1.170623.027**, Oct 2017, Fi/Canada.... you both are having problems on >>>>>OPR3.170623.008<<<<< ~> Something is different in that build... If you like (and happen to have that image kicking around, you could send me the boot.img and I'll compare it to mine? later on)
I'm thinking it's not the kernel size, although - I do plan on making the kernel smaller on production builds, by reducing a lot of debugging that really isn't needed on a production build (I already have a defconfig for doing so);

[MATA] [CAF] [UNIFIED] [EAS] [4.4.166] [CLANG 8.0] Neutrino Kernel (hercules)

Neutrino Kernel began as an effort to keep the stock LineageOS 15.1 kernel up-to-date with the latest linux-stable releases and has since evolved into an intensive crash course in maintaining my own custom kernel. Although some of you would accuse me of modesty, I think it's important to acknowledge that I am a "kernel developer" in the same way that Amy Schumer is a "comedian". That is to say, my work is highly derivative and built on the backs of individuals who are far more talented than I am. My role here is to have a vision, establish a design philosophy, and use the resources at my disposal to bring that vision to fruition.
Those of you who've perused my staging repo will know that I'm very particular about cleanliness. All changes and additions are vetted based on viability and purpose. Neutrino is based on kernel.lnx.4.4.r35-rel, pure CAF source for Android 9.0 tracking and upstreamed to the latest linux-stable release. I have manually rebased Essential's stock kernel source on top of CAF using relevant OEM commits from PPR1.181005.034. All major features and patchsets are assembled on independent staging branches of this codebase base and merged into the release repository.
I do not commit changes that I cannot justify or explain, and I do not go on indiscriminate cherry-picking sprees. There are a handful of developers that I highly respect, and who's projects have served as inspiration for my own. My intention is to incorporate the best of what they've brought to the table in a way that most effectively achieves and enhances this project's design goals.
I like to think that Neutrino is relatively subdued in terms of "features", with a stronger focus on optimizations over fluff. That being said, there have been quite a few additions which I feel have merit in terms of increased performance and/or efficiency provided the former does not compromise the later:
Revamped EAS implementation for Pie
sultanxda's CPU/GPU Boost Drivers
Dynamic SchedTune Boosting
Maple I/O Scheduler
Broader subsystem support for Power Efficient Workqueues
KCAL Color Control
Backlight Dimmer
Fsync Toggle (enabled by default)
GPU Underclock @ 180 MHz
CPU (partial) Overclock, Silver Cores @ 2035 MHz
Boeffla Wakelock Blocker v1.1.0
Wireguard Support
VDSO Support
Treewide memory allocation/overflow patches from mainline
OOM Reaper and various memory management enhancements to improve LMK
Treewide compiler warnings corrected
Built with self-compiled Clang 8.0.3 and GCC 8.2.0 toolchains, with a local initialization sanitizer and polly optimization flags
INSTALLATION:
**Neutrino now utilizes AnyKernel2 zip format for universal compatibility**
As a result, you can now flash this kernel on just about anything including Oreo/Pie custom and stock ROMs. The only requirement is that your firmware is current and up-to-date with PPR1.180905.036 at a minimum. Flashing on older firmware will result in broken input detection and a non-functional touchscreen.
That being said, this is an EAS kernel and is best suited for use on EAS-compatible ROMs. Just because it can be flashed on stock does not mean that you should do so. Installation on ROMs which do not natively support EAS (such as stock) will likely result in sub-optimal battery performance and I will not entertain any complaints stemming from the use of Neutrino on ROMs which are incompatible with EAS. Stock support is a perk and an experiment on my part, please do not make me regret giving you the ability to flash on stock, I will drop public support for it if this disclaimer is routinely ignored. If you choose not to heed my recommendations, you are doing so at your own discretion.
For ease of use, I would recommend using an app with built-in zip flashing functionality such as EX Kernel Manager or FK Kernel Manager. Of course, I cannot expect all of you to utilize a paid app for installation and as such, conventional installation via TWRP is certainly possible as well.
Neutrino will preserve existing Magisk installation during kernel update, meaning if you already have Magisk installed on your device you need not worry about reflashing Magisk when updating your kernel. If you do not already have Magisk installed and desire root access then Magisk zip must be flashed following kernel zip via TWRP.
DOWNLOADS:
Current releases can be downloaded here.
Archival builds (boot images) for lineage-15.1 can be found here.
SOURCE & SPECS:
Neutrino Kernel Source
Neutrino Staging Repo
Changelog
Linux Kernel Version: 4.4.166
CAF Release: LA.UM.7.4.r1-03900-8x98.0
Neutrino Kernel Version: hercules
Clang Version: neutrino clang 8.0.0-r348460
Build Date: 20181206

@return.of.octobot Awesome! Thanks for bringing us upstream updates! So if I've understood it correctly if I do flash the root version and want to take an ota update, I'll have to revert to stock kernel for the lineage os version I was on or flash the non root version that you've provided us with before updating?

You're as awesome as you are humble. Thank you for this. Life is getting easier and easier for common users thanks to contributions like this. Awesome.

Arju said:
@return.of.octobot Awesome! Thanks for bringing us upstream updates! So if I've understood it correctly if I do flash the root version and want to take an ota update, I'll have to revert to stock kernel for the lineage os version I was on or flash the non root version that you've provided us with before updating?
Click to expand...
Click to collapse
When I had magisk installed and was running lineage... The OTA program didn't care about signatures...
Since it's not a Delta... It's not patching anything... Just overwriting what is currently there... So it SHOULDN'T matter...
Sent from my PH-1 using XDA Labs

rignfool said:
When I had magisk installed and was running lineage... The OTA program didn't care about signatures...
Since it's not a Delta... It's not patching anything... Just overwriting what is currently there... So it SHOULDN'T matter...
Sent from my PH-1 using XDA Labs
Click to expand...
Click to collapse
Hey, great to see you here. I remember you from the Nexus 6 forums. Thanks for the answer

Arju said:
Hey, great to see you here. I remember you from the Nexus 6 forums. Thanks for the answer
Click to expand...
Click to collapse
Yeah... I couldn't help myself... When I found out buying this phone was a direct thank-you to Andy Rubin...
Sent from my PH-1 using XDA Labs

Arju said:
@return.of.octobot Awesome! Thanks for bringing us upstream updates! So if I've understood it correctly if I do flash the root version and want to take an ota update, I'll have to revert to stock kernel for the lineage os version I was on or flash the non root version that you've provided us with before updating?
Click to expand...
Click to collapse
rignfool said:
When I had magisk installed and was running lineage... The OTA program didn't care about signatures...
Since it's not a Delta... It's not patching anything... Just overwriting what is currently there... So it SHOULDN'T matter...
Sent from my PH-1 using XDA Labs
Click to expand...
Click to collapse
He is right, I was recommending that the unrooted image be flashed prior to OTA but you could also certainly restore the boot.img that was originally included in invisiblek's build for maximum peace of mind. I would tend to agree that it doesn't actually matter as the OTA should be installing a completely new image on the opposite slot so I'm not sure what difference it would make, I was just leaning my instructions towards the safe side, perhaps I'll try and clean them up.

only for lineage can it work on aosp rom?
Sent from my PH-1 using Tapatalk

kakabobo said:
only for lineage can it work on aosp rom?
Click to expand...
Click to collapse
Yeah, it's literally built from Lineage source with upstream Linux kernel merged in. I wouldn't recommended flashing this on AOSP any more than I would recommended flashing the stock Lineage kernel on an AOSP build. Even if it booted I imagine there's a good chance it would break things to the point of being unusable. That being said, I haven't tried it so I'm only speculating. If you do, make sure you've got a copy of your ROMs stock boot.img to recover with. But seriously, I wouldn't.

return.of.octobot said:
Will be uploading 4.4.118 images within the next day or two, currently experimenting with merging the latest CAF tags into upstream source. Jury's still out on whether or not that's going to prove successful but I will be releasing standard linux-stable builds regardless.
Click to expand...
Click to collapse
Without further ado, 4.4.118 images are available for download here.
Same deal as before, built from unadulterated upstream linux-stable source. Stock and Pre-Patched Magisk variants available.
I did manage to get a CAF-based version of this kernel building and booting, however it broke my touchscreen and is clearly not ready for public consumption. So, until further notice we're going to stick with the 'if it ain't broke..' philosophy, although you may or may not see me releasing some experimental builds in the future.
For now, enjoy 4.4.118

***OP updated for 4.4.118 release, revised comprehensive installation instructions***

return.of.octobot said:
***OP updated for 4.4.118 release, revised comprehensive installation instructions***
Click to expand...
Click to collapse
That's for the build today right?

shooterlgk said:
That's for the build today right?
Click to expand...
Click to collapse
In theory these images should work on any LineageOS install, regardless of build date, but yes it's compatible with both the 02/26 and 02/28 releases from invisiblek. I've updated the screenshot in OP which shows this kernel installed on the latest Lineage OTA.

return.of.octobot said:
***OP updated for 4.4.118 release, revised comprehensive installation instructions***
Click to expand...
Click to collapse
flashed your kernel with magisk support on todays (28th) lineageos build. Magisk is not passing safteynet.
edit: followed your instruction to patch the boot img using magisk and now it passes safteynet. had to use the non patched on from here.

Arju said:
flashed your kernel with magisk support on todays (28th) lineageos build. Magisk is not passing safteynet.
edit: followed your instruction to patch the boot img using magisk and now it passes safteynet. had to use the non patched on from here.
Click to expand...
Click to collapse
Good to know, I'll have to make note of your findings in the OP. I would've never figured that out myself as I've got xposed installed and to the best of my knowledge my SafetyNet checks will always fail because if it. I've really just been offering the prepatched images because I thought it would be helpful to allow some to bypass the step of patching manually. However, I'll have to consider whether it might be a better idea to just provide the clean image with instructions on how to patch it.

return.of.octobot said:
Good to know, I'll have to make note of your findings in the OP. I would've never figured that out myself as I've got xposed installed and to the best of my knowledge my SafetyNet checks will always fail because if it. I've really just been offering the prepatched images because I thought it would be helpful to allow some to bypass the step of patching manually. However, I'll have to consider whether it might be a better idea to just provide the clean image with instructions on how to patch it.
Click to expand...
Click to collapse
So this is what I did.
1. Flashed lineage os. Set it up.
2. Flashed your kernel (non magisk version) using fastboot and booted back into rom. (Not sure if this is necessary as I later on flash the patches version by magisk manager).
3. Install magisk manager. Have the non magisk version of your boot image on my phone. Patch it with magisk manager.
4. Transfered the patched boot image to computer.
5. Flashed the patches boot image using the computer (fastboot). Reboot into system.
6. Safetynet check passes.

Arju said:
So this is what I did.
1. Flashed lineage os. Set it up.
2. Flashed your kernel (non magisk version) using fastboot and booted back into rom. (Not sure if this is necessary as I later on flash the patches version by magisk manager).
3. Install magisk manager. Have the non magisk version of your boot image on my phone. Patch it with magisk manager.
4. Transfered the patched boot image to computer.
5. Flashed the patches boot image using the computer (fastboot). Reboot into system.
6. Safetynet check passes.
Click to expand...
Click to collapse
Thanks for sharing. I essentially went through the same process to patch these images myself after they were built, perhaps there is some kind of security measure in place where the boot.img needs to be installed to the same device it was patched on? I find it strange that it would successfully root the device, but not pass SafetyNet. I'll think on that and figure out if it makes more sense to just release unpatched builds in the future.

return.of.octobot said:
Yeah, it's literally built from Lineage source with upstream Linux kernel merged in. I wouldn't recommended flashing this on AOSP any more than I would recommended flashing the stock Lineage kernel on an AOSP build. Even if it booted I imagine there's a good chance it would break things to the point of being unusable. That being said, I haven't tried it so I'm only speculating. If you do, make sure you've got a copy of your ROMs stock boot.img to recover with. But seriously, I wouldn't.
Click to expand...
Click to collapse
I flashed it on AOSIP without issue. Not sure if it's considered the same as AOSP.....

return.of.octobot said:
Thanks for sharing. I essentially went through the same process to patch these images myself after they were built, perhaps there is some kind of security measure in place where the boot.img needs to be installed to the same device it was patched on? I find it strange that it would successfully root the device, but not pass SafetyNet. I'll think on that and figure out if it makes more sense to just release unpatched builds in the future.
Click to expand...
Click to collapse
I wouldn't realy mind and I think it would make it easier for you too. If the patching is unique per phone then it makes sense that we patch it ourselves. But we need upstreamed updated kernels!!! so don't stop doing those!!

Arju said:
I wouldn't realy mind and I think it would make it easier for you too. If the patching is unique per phone then it makes sense that we patch it ourselves. But we need upstreamed updated kernels!!! so don't stop doing those!!
Click to expand...
Click to collapse
Yeah of course, no sooner had I uploaded 118 than 119 was pushed. I'm not sure if I'll be able to get one out for each release before the next one comes out, but I'm going to be keeping these updated a frequently as I can. Anyway, I was only speculating about device-specific images, but I'm going to try and flash an image that was patched by my buddy and see if I can reproduce any issues. Regardless, I'll likely stick to uploading unpatched images in the future.

[ROM][UNOFFICIAL][Oreo 8.1] CypherOS 6.0.0 [h901] 5/6/2018

This has reached a point that those who don't depend BT calling may be able to use it as a daily driver. Just be sure to backup first!
The flashing on first boot during setup may cause issues for those with epilepsy. This is due to how to disable the second screen.
Working:
Camera! https://www.celsoazevedo.com/files/android/google-camera/f/GCam5.1.018-Arnova8G2-V1.7Beta2.apk is recommended with Nexus 6 HDR config in advanced settings.
Bluetooth (skips with wifi, and doesn't work in call)
NFC
Wifi -- two users have reported issues on their devices, while it works for others.
GPS
Sensors
Sound
Calls
Fingerprint
Data
WiFi tethering
Second screen disable hack
Not working and issues:
Screen glitches on first boot. Reboot and will be good after (part of hack to disable 2nd screen)
Tap to wake
Flashlight tile: install flashlight tile for kenzo in play store with root to workaround.
Slight animation glitch when switching activities due to second screen hack.
BT issues above, and doesn't work in call.
If you use camera immediately after turning on, it may not work. You must wait about a minute after powering for it to work (it will always work after).
Probably more.
TODO
BT fixes
Tap to wake
flashlight tile
get a proper 2nd screen fix like v20 working without additional issues. v20 dtsi hack doesn't work for us due to dual panel depending on partial update (most likely).
Repos (kernel is lineage-15.1 branch):
Kernel
v10-common
h901
blobs
Changes from AOSCP
Using Ruthless launcher instead of Luna
Two reverts to support substratum themes in addition to CypherOS' color manager.
Use opengapps for gapps, magisk for superuser (may have issues with modules).
Download
Buy me a beer with Bitcoin: 1h9o1Ei9thLd8JKRz3z7PUGhX6dtfnktY

Bugs with workarounds:
Wifi doesn't connect and MAC address is all zeroes (only some users):
This is a misc partition that has MAC address hardcoded to a randomly generated address. This should work permanently on any device with the issue so long as two aren't on the same network. If anyone would like instructions on how to modify with a new MAC address, let me know.
Image https://www.androidfilehost.com/?fid=818222786056033811
Instructions:
Place on /sdcard
Reboot to recovery (for advanced reboot in CypherOS hold reboot button for full menu)
From twrp terminal or adb shell, run: dd if=/sdcard/misc.img of=/dev/block/bootdevice/by-name/misc
Reboot and enjoy fixed wifi
No charging indicator (but still charges):
Boot device plugged into power or USB and the indicator will work the entire power cycle. Working on a fix but not as trivial as I'd hoped.
Bootloop bug:
I recently got hit by the infinite bootloop bug, with the only workaround of disabling the big cluster. Here's a modified TWRP that only uses the little cluster (used Eliminator74's image):
https://www.androidfilehost.com/?fid=818222786056035329
And here's a little cluster only boot image from the titan kernel (our CAF kernel has msm_thermal issues with booting with disabled big cores, needs modifications):
https://www.androidfilehost.com/?fid=674106145207491774

nvm, fixed in current build

Just uploaded a new build. Changes:
Tweaked touch offset
Synced CypherOS to 6.0.0 (fixes navbar on first boot and some others)
Fixed init script to set display res (part of the second screen disable hack)
Updated Ruthless Launcher

two questions: the kernel you mention in repo is the original one or is a Lineage Kernel for LG V10? it for all variants of V10?
thanks

sun_is_shinning said:
two questions: the kernel you mention in repo is the original one or is a Lineage Kernel for LG V10? it for all variants of V10?
thanks
Click to expand...
Click to collapse
That lineage-15.1 branch that is being used is based on the lineage 14.1 g4 kernel. I added a h901 defconfig, three commits needed for v10 (incl 2nd screen hack), fast charging, all commits needed for Oreo (since g4 isn't supported on los 15.1), then merged in CAF.
Regarding the other variants (which are now all unlockable thanks to g4 guys), I added a commit by ehem which added the panel dtsi for other variants, but as of yet only h901 builds have been tested on the kernel. Other variants should work with the correct defconfigs and device repos adapted from their g4 counterparts.
Hope I answered fully.

johngalt1 said:
That lineage-15.1 branch that is being used is based on the lineage 14.1 g4 kernel. I added a h901 defconfig, three commits needed for v10 (incl 2nd screen hack), fast charging, all commits needed for Oreo (since g4 isn't supported on los 15.1), then merged in CAF.
Regarding the other variants (which are now all unlockable thanks to g4 guys), I added a commit by ehem which added the panel dtsi for other variants, but as of yet only h901 builds have been tested on the kernel. Other variants should work with the correct defconfigs and device repos adapted from their g4 counterparts.
Hope I answered fully.
Click to expand...
Click to collapse
Will you add the other version? For H960, H960TR vs.

Kasimpasali1921 said:
Will you add the other version? For H960, H960TR vs.
Click to expand...
Click to collapse
It's planned.

Hey, I just have a question, I'm sorry probably borrowing your thread to ask, but how'd you get the ROM to build using 15.1/14.1? I've been working on a port horrible the h901, but for the life of me I can't get the ROM to build.
Also, when I get a chance I'll check out your ROM, haven't gotten to play with oreo much as of yet.

TheEnekaign said:
Hey, I just have a question, I'm sorry probably borrowing your thread to ask, but how'd you get the ROM to build using 15.1/14.1? I've been working on a port horrible the h901, but for the life of me I can't get the ROM to build.
Also, when I get a chance I'll check out your ROM, haven't gotten to play with oreo much as of yet.
Click to expand...
Click to collapse
Ask any question you want here! I'm not sure specifically what issue you ran into while attempting to build, but the repo links in OP are fully up to date (incl the lineage-15.1 branches).
Unfortunately los 15.1 has the graphical glitches (due to 2nd screen hack) after the second boot as well, so I'll be sticking with cypheros for testing for now.
I'll make a project manifest shortly to further simplify building.

johngalt1 said:
Ask any question you want here! I'm not sure specifically what issue you ran into while attempting to build, but the repo links in OP are fully up to date (incl the lineage-15.1 branches).
Unfortunately los 15.1 has the graphical glitches (due to 2nd screen hack) after the second boot as well, so I'll be sticking with cypheros for testing for now.
I'll make a project manifest shortly to further simplify building.
Click to expand...
Click to collapse
Sweet, I'll have to have a look at those repos. Only ones I could find before were cm 13.1. I was working on a RR 14.1 port, since that's one of my fav roms, but basically the error I got was a brunch error as it couldn't find the needed files (maybe the manifest? It's been about a week since I poked it). It kept looking at the lineage servers and couldn't find the right cm versions. It also couldn't find other things as well, but I'll have to poke it again to remember what exactly.
Thank you though!
(I also just realized that my auto correct called the h901 horrible. It's def not horrible. xD)

TheEnekaign said:
Sweet, I'll have to have a look at those repos. Only ones I could find before were cm 13.1. I was working on a RR 14.1 port, since that's one of my fav roms, but basically the error I got was a brunch error as it couldn't find the needed files (maybe the manifest? It's been about a week since I poked it). It kept looking at the lineage servers and couldn't find the right cm versions. It also couldn't find other things as well, but I'll have to poke it again to remember what exactly.
Thank you though!
(I also just realized that my auto correct called the h901 horrible. It's def not horrible. xD)
Click to expand...
Click to collapse
For building without the manifest, clone the device and vendor repos to their correct folders, check aoscp.dependencies to clone additional repos to their correct folders, then just run . build/envsetup.sh ; breakfast aoscp_h901-userdebug, and then you can make bacon ?
I based the device repos off the g4 repos for aoscp, which are just los 14.1 with Oreo and now v10 changes. The kernel is based on the los 14.1 lge msm8992 kernel with changes necessary for Oreo, CAF merged in, fast charging support, the second screen disable hack, a commit for building properly with a lge display flag, the dtsi for other v10 variants (thanks to ehem), and a defconfig for h901.
Edit: keep in mind RR may have the same display corruption issue with our second screen hack that LOS has for us.

New build uploaded. Changes:
- Fixed touchscreen alignment. Bottom of navbar now works.
- Synced with upstream CypherOS
- Testing navbar theme settings from gerrit.

New build uploaded. Changes:
- Possibly fixed occasional no sim on boot (ty kessaras/steadfasterx)
- Synced with CypherOS
- A few upstream ALSA kernel changes
- Ruthless launcher updated
- Two upstream reverts to fix substratum themes.
There's now also a local_manifest for users who would like to build themselves https://github.com/amillogical/local_manifest

Is this compatible to my lg v10 h962 (from taiwan)?

ViciousDiplomat said:
Is this compatible to my lg v10 h962 (from taiwan)?
Click to expand...
Click to collapse
No, but it can be. Is your device bootloader unlocked? If so, I'll do a build from h815 (g4 equiv) you can test. If not, I can help bootloader unlock it with USU.
I'm not sure how many know, but all v10 variants are now bootloader unlockable with USU. I just haven't had a chance to build for them or post details.

well, will this Kernel of this ROM compatible with H960A variant? and what really changes in this Kernel?
Thank u.

sun_is_shinning said:
well, will this Kernel of this ROM compatible with H960A variant? and what really changes in this Kernel?
Thank u.
Click to expand...
Click to collapse
Yes, it only needs a config for h960 at this point. Ehem imported the panels for all the other variants so we can use a unified kernel between all g4 and v10 variants.

Will done sir i'll buy you a bear on your bitcoin wallet for sure.. Gr8 job
An old user for v10 (p20 pro now) but still love this beast

New build uploaded. This won't fix wifi issues for those that have them. This build needs a dalvik-cache wipe after dirty flash due to memory override changes (last bullet). I've also started using AndroidFileHost for uploads.
Changes:
- Synced with upstream CypherOS (bumped to april security bulletin and a few new features).
- NFC should be fixed. This needs more testing, as I don't have anything to test the functionality but it turns on/off.
- Corrected STM laser permissions (autofocus seems to be like in stock rom now).
- Changed link to modified google camera in OP since the previous version didn't have functional HDR+.
- Dalvik heap and hwui memory overrides updated for our device's 4G ram and high res display.
And thank you @sherif2222222

[KERNEL][UNOFFICIAL][TB-X605F] kernel for Lenovo Smart Tab M10 (wifi)

Code:
#include <std_disclaimer.h>
/*
*
* We are not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this kernel
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at us for messing up your device, we will laugh at you.
*
*/
Warnings: this kernel has been tested on the TB-X605F (SDA450) only. It will not work for the:
TB-X605F (M10) released with the SDA429 chipset
TB-X605L (M10 LTE). This kernel is currently for the wifi variant only.
TB-X505F/L (M10 HD) or any of the other M10 variants that use the SDA429 chipset.
TB-X605FC (M10 FHD). See the opensource released by Lenovo. Note that the X605FC kernel is 4.9.112.
Introduction
On 4 June 2020, Lenovo released the kernel source for the TB-X605F/L.
Prior to that, this kernel was developed by porting the kernel source for the the P10 (TB-X705F) released by Lenovo in January 2019.
Current version is: 3.18.120 merged with CAFCAF LA.UM.5.5.r1-05300-8x96.0.
The update zip will load some modules. So backup the "System Image", "Vendor Image" and boot partitions with TWRP before loading this kernel.
For kernel developers
Lenovo have released the opensource for the TB-X705F (Smart Tab 10 wifi) dated 31 January 2019 at s000018_20180913_row. This kernel is based on that kernel source (3.18.71). The default config (YM_X605F_defconfig) is almost identical to the kernel config of the M10. Some of the main differences with the P10 source are:
removed the MM8013 chipset config. The P10 uses the MM8013 for battery stats etc. There is no MM8013 on the M10.
upgraded drivers for the primary autofocus camera.
set CONFIG_MODULE_SIG_FORCE to "n" - so kernel will load stock modules from any version. Thanks to @yener90 for the suggestion.
While Lenovo releases the (compiled) stock M10 kernel at 3.18.120, the P10 kernel opensource is 3.18.71. Great job Lenovo!
The source will build signed system modules, if you want them. If you want the wifi driver it's pronto_wlan.ko, compile with CONFIG_PRONTO_WLAN=m.
Features
This kernel compiles and runs. It seems to be stable.
Working:
- wifi
- bluetooth
- power charging (USB and dock)
- camera
- FM radio
- touchscreen (including DT2W)
- audio
- OTG
Known bugs
you tell me
Installation
I assume you have unlocked bootloader, TWRP and Magisk. If not, follow these instructions.
The update zip is packaged using AnyKernel3 by @osm0sis .
if you are still on stock ROM & kernel, backup "System Image", "Vendor Image" and boot partitions in TWRP. You only have to do this once, not everytime you load a new version of this kernel.
download update_X605F_kernel.zip and copy it to your sdcard/OTG
boot to TWRP and use "update" to update the zip file
check that the update was successful, then reboot
confirm the kernel is loaded. It should start with "3.18.120-X605F-YM":
Code:
X605F:/ $ uname -r
3.18.120-X605F-YM-xxx
To return to stock kernel, just restore the stock boot, system and vendor backups you made in TWRP. If that doesn't work, then you'll have to reload system ROM using LMSA.
Changelog
Code:
11/03/2020 - 3.18.120-X605F-YM-g02f9b3e-00023-gcef72f9
- fixed camera - it's now recognised and autofocus works
- cleared out some dead code that's not needed for M10 (hangover from P10 source)
05/03/2020 - 3.18.120-X605F-YM-g02f9b3e-00018-g818259c3
- rebased kernel to 3.18.120
- merge CAF LA.UM.5.5.r1-05300-8x96.0
- added DT2W
- fixed "adb reboot". The rebase fixed it.
- added a defconfig for LineageOS
- included signed modules in zip file (including wlan)
20/01/2020 - 3.18.71-X605F-kernel-g0a9bdb1
- disabled signed module enforcement
- removed system and vendor modules from update zip
17/01/2020 - initial commit
Download
current release: update_X605F_kernel.zip
XDA:DevDB Information
M10 kernel, Kernel for the Lenovo Thinkpad Tablet
Contributors
Yahoo Mike
Source Code: https://github.com/Yahoo-Mike/android_kernel_lenovo_X605F
branch: msm-3.18.120 is source for this release (default branch)
branch: official-3.18.120 is official source released by Lenovo on 4 June 2020.
branch: msm-3.18.71 is the initial port from P10 kernel source
Kernel Special Features:
Version Information
Status: Testing
Created 2020-01-16
Last Updated 2020-06-05

Yahoo Mike said:
Lenovo releases the stock M10 kernel at 3.18.120. However, the P10 kernel source is 3.18.71. This means that system modules and the wifi driver need to be re-compiled, signed and distributed with this kernel. This means that the /system and /vendor partitions need to be touched, not just the boot image.
Click to expand...
Click to collapse
Just disable the modules, the kernel wont build it anymore. It's also not urgently required.

yener90 said:
Just disable the modules, the kernel wont build it anymore. It's also not urgently required.
Click to expand...
Click to collapse
Thanks for the neat suggestion.
I disabled signed module enforcement (CONFIG_MODULE_SIG_FORCE) so we can use stock modules. That means no need to update system or vendor partitions.
I left in *_SIG_ALL in the defconfig, so you can compile and sign modules if you really want to. But I haven't included any modules in the new update zip. If you've used the old version of the update zip, then restore stock boot, system and vendor images before using this new update zip.

I've released a new version. Main changes are:
rebased kernel to 3.18.120
merge CAF LA.UM.5.5.r1-05300-8x96.0
added DT2W
fixed "adb reboot". The rebase fixed it.
added a defconfig for LineageOS
included signed modules in zip file (including wlan)
I've updated the OP.
I've added a new (default) branch called msm-3.18.120 in the github repo: Yahoo-Mike/android_kernel_lenovo_x605f.
The camera auto-focus is still not working. I haven't looked at it. Lenovo have not released the source code. It looks like the P10 uses different cameras. The main camera is a hynix hi556 variant called: hi556_m10. I'll have a look at this soon. One of the ASUS Zenfone Max Pro (M1) variants uses the hi556. That might have a usable driver. There's also a new video driver for the hi556 (CONFIG_VIDEO_HI556) released by intel for the linux kernel.
If anyone wants me to rebase to 3.18.140, just ask.

Latest version fixes camera issues. Camera (Hynix hi556) is now recognised and autofocus works.
I copied the Hynix (eeprom OTP) code from the Lenovo Tab4 kernel source. The code in the P10 kernel source never worked - probably because the P10 was never released with Hynix hi556. The P10 uses OmniVision ov8856 (8MP) and GalaxyCore gc5025 (5MP). Whereas the M10 uses Hynix hi556 (5MP) and Superpix sp2519 (2MP).
This kernel is stable. I can't find anything wrong with it. I've tested it using stock ROM with no issues. So I guess it's safe to load up with the stock ROM (Android Pie)...at your own risk. Just be sure to backup the system & vendor images, plus the boot image in TWRP. You'll need these when an OTA comes along, anyway. The updater-script in the OTA will refuse to apply, because it won't recognise this kernel.
So until someone finds some issues with this kernel, I guess it's time to polish up some LineageOS code...

Two exciting announcements:
prima drivers added to staging
I've added prima drivers to the kernel github repository. It's used by the lineageos_X605F_defconfig to build the wlan.ko module (CONFIG_WLAN_PRONTO).
Lenovo released official kernel source yesterday
The official kernel source for the X605F and X605L has just appeared on Lenovo's support site.
I'll have a closer look over the next few weeks, but here's some preliminary observations:
it is released at msm 3.18.120. This is the stock kernel version. (Lenovo released 3.18.71 for the P10.)
there is only one download for both X605F and X605L. This might be good news.
the autofocus camera drivers for the Hynix appear to be included. I'll take a closer look.
kernel compiles without any changes. I haven't loaded it yet to test it.
edit: I've added the official source to the Yahoo-Mike/android_kernel_lenovo_X605F repo in the official-3.18.120 branch.

The opensource drop for the X605F from last week includes code for the kernel at msm-3.18.120. Surprisingly, it includes a defconfig for the P10. This confirms that the M10 (X605F/L) and P10 (X705F/L) are very similar.
I'm going to test Lenovo's kernel source on my TB-X605F this weekend. Is there anybody with a TB-X705F/L and the skills to build and test this code on their P10 ? PM me and we can coordinate.
The only differences I can see are:
Code:
m10_msmcortex_defconfig | p10_msmcortex_defconfig | Kconfig definition
----------------------- | ----------------------- | ------------------
| CONFIG_BATTERY_BQ27x00=y | drivers/power
CONFIG_CAMERA_TAB5_M10=y | | drivers/media/platform/msm/camera_v2
| CONFIG_CAMERA_TAB5_P10=y | drivers/media/platform/msm/camera_v2
| CONFIG_FOUR_PA=y | sound/soc/codecs & sound/soc/msm
| CONFIG_SENSORS_HALL=y | drivers/input
CONFIG_TP_MP_DIFF=y | | arch/arm64
The TP_MP_DIFF setting is used to load different firmware for the touchscreen drivers: one set for the M10s; another for the P10s.

Deleted

happyponcho42 said:
Great find! I've successfully built the kernel and was also pleasantly surprised I could use the browsable menuconfig (like the setup for my Linux Desktop) after using the P10 defconfig i.e.
Code:
make -j24 ARCH=arm64 CROSS_COMPILE=aarch64-linux-android- O=out p10_msmcortex_defconfig && make -j24 ARCH=arm64 CROSS_COMPILE=aarch64-linux-android- O=out menuconfig
I've disabled requiring signing of loadable kernel modules, as well as generated some modules for USB-to-Serial chipsets I use (pl2303.ko, ftdi, etc.) for projects.
Now to test the Image.gz-dtb: I have not had much luck unpacking boot-TB-X705F_S210120_191029_ROW.img and repacking with my tools. I just end up on a blank screen on the P10.
Do you have a recommended set of tools that have worked with your M10?
Click to expand...
Click to collapse
Glad to hear it compiled for P10.
I use AnyKernel3 to inject the kernel for me. It can also load kernel modules, if you build any.
I use these properties in the AK3 mod script. Modify it to suit your purposes:
Code:
# begin properties
properties() { '
kernel.string=X605F kernel built by Yahoo Mike @ xda-developers
do.devicecheck=1
do.modules=1
do.cleanup=1
do.cleanuponabort=0
device.name1=X605F
supported.versions=9
supported.patchlevels=- 2020-06
'; } # end properties
Then in my script I copy the kernel to AK3 root directory and modules to ./modules/system/lib/modules directory (or vendor equivalent) & zip it all up.
Code:
# zip it all up, ready for installing in TWRP
# this zip will replace kernel, plus any modules you included (if any)
# don't forget to TWRP-backup boot, system and vendor images
# also good idea to copy /system/lib/modules/* and /vendor/lib/modules/pronto/*
cd ~/tools/AK3
zip -r9 update_X605F_kernel.zip * -x .git README.md *placeholder
adb push update_X605F_kernel.zip /external_sd/
Optionally, you can also create a "version" file with something like this (before zipping):
Code:
MY_KERNEL_IMG="$(pwd)/out/arch/arm64/boot/Image.gz-dtb"
MY_KERNEL_VERSION="$(make kernelversion)"
cd ~/tools/AK3
# create a "version" file
MY_ZIP_DATE=$(date +'%Y-%m-%d %H:%M:%S')
MY_BUILD_DATE=$(stat ${MY_KERNEL_IMG} --format=%y | cut -c1-19)
echo "**************************************************" > $MY_ANYKERNEL_DIR/version
echo "unofficial kernel for Lenovo Smart Tab M10 (TB-X605F)" >> $MY_ANYKERNEL_DIR/version
echo " version: $MY_KERNEL_VERSION" >> $MY_ANYKERNEL_DIR/version
echo "compiled: $MY_BUILD_DATE" >> $MY_ANYKERNEL_DIR/version
echo " zipped: $MY_ZIP_DATE" >> $MY_ANYKERNEL_DIR/version
echo "**************************************************" >> $MY_ANYKERNEL_DIR/version

The Lenovo opensource seems to be working on the TB-X605F. The modules are also building and installing ok.
There is something odd about the device tree, so make sure you use Image, not Image-dtb.gz. When I used the dtb kernel, I kept getting the dreaded "Qualcomm HS-USB Diagnostics 900E" mode.
I'll add a "lineage-17.1" branch to the github repo. It includes an M10_lineageos_defconfig for building the kernel and modules, and wlan.ko source from CAF for Android 10:
Code:
June 01, 2020 LA.UM.8.6.2.r1-07600-89xx.0 msm8953_64 LA.UM.8.6.2.r1-07600-89xx.0.xml 10.00.00

Yahoo Mike said:
There is something odd about the device tree, so make sure you use Image, not Image-dtb.gz. When I used the dtb kernel, I kept getting the dreaded "Qualcomm HS-USB Diagnostics 900E" mode.
Click to expand...
Click to collapse
I can get the dtb kernel to work by replacing the arch/arm/boot/dts/qcom/ directory from Lenovo's opensource with the same directory from the "msm-3.18.120" branch of the repo. It boots fine with the stock ROM and LOS.
The "msm-3.18.120" branch is based on the original P10 opensource from January 2019.
So yes, there is definitely something screwy about the dt blobs from the June 2020 codedrop.

Not sure if this would be a valid kernel or not - On the back it says model is TB-X605F. I
In settings it says hardware is TB-X606F and so is the software.
It's the m10 gen 2 tablet. I believe Mediatek chipset.

dustofdeath said:
Not sure if this would be a valid kernel or not - On the back it says model is TB-X605F. I
In settings it says hardware is TB-X606F and so is the software.
It's the m10 gen 2 tablet..
Click to expand...
Click to collapse
If you have the gen 2, then this is the wrong kernel.
Lenovo has published the TBX606F/X kernel.
dustofdeath said:
I believe Mediatek chipset.
Click to expand...
Click to collapse
The CPU-Z app from the playstore will tell you which SOC you have.

I added pstore/ramoops support on branch msm-3.18.120. I have no idea why Lenovo never configured pstore/ramoops in the first place.
The ramoops device will dump console-ramoops, dmesg-ramoops-0, pmsg-ramoops-0 into /sys/fs/pstore/.
I'll add pstore support to TWRP for the TB-X605F in the next update. I'll use this branch (msm-3.18.120) to build the kernel.
I'm hoping pstore will tell me why GSI images fail to boot when installed over stock Pie.

Hello and thanks to all of you to invest so much time and effort. I'm not the best in this android world so forgive me if I ask something stupid Recently I got a Lenove Tab M10 TB-X605L and well I rooted it (with magisk) to use Linux on it. As I said I don't use android so much and I just got this product as present so when I saw this post I thought If I can put a new Kernel why not compile it with NetHunter Kernel and give it a try. After some effort (I'm not sure if it will work) I made the kernel. My problem is:
1st I rooted my Tablet with Magisk (as the same way you mentioned in another post) after the rooting I download twrp from google play. Till here all is good. Now:
TWRP is working when I boot it. But asks for a Password. I tried some swipe data, cache etc. but still I see that PASSWORD field. I can't pass it. (And when I pass it without Password I can't see the kernel neither yours nor mine)
I don't care what happens to my Tablet as I said I'm not a android user. I would even would try a crazy Idea even if its end with a dead tablet but I would really wanna check if the compiled NetHunter kernel works.

saizzou38 said:
...TWRP is working when I boot it. But asks for a Password. I tried some swipe data, cache etc. but still I see that PASSWORD field. I can't pass it...
Click to expand...
Click to collapse
TWRP will ask for a password if you have a password, PIN or pattern set on your tablet, and/or your data partition is encrypted.
If you have a password or PIN set on your tablet, try entering that. If you had a pattern, try this.
You can unencrypt the data partition by reformatting it and then installing Disable_Dm-Verity_ForceEncrypt.zip (created by Zackptg5). Just be aware that this wipes all your data and breaks OTA updates. (Magisk also needs to be uninstalled before OTAs work.)
saizzou38 said:
...And when I pass it without Password I can't see the kernel neither yours nor mine...
Click to expand...
Click to collapse
Remember: android recovery (twrp) uses the kernel in the recovery partition, not the boot partition.
So, where are you injecting your kernel?
If you are injecting your kernel into TWRP's recovery image, which kernel do you see when you issue this command?
Code:
adb shell uname -r
If you are injecting your kernel into the system ROM's boot.img, then you won't see your kernel in TWRP. You'll see the kernel with which twrp was compiled.
BTW...interesting project. Good luck. Let us know if you get it working.

Hi there,
　　I just compiled your kernel source you've uploaded on the Github (official branch) with m10_msmcortex_defconfig. Then, I flashed it to my device with anykernel 3, also included all modules, but the wifi does not work(It cannot be turned on). Before I flash it, my device was running well at the stock firmware, so I wonder what's wrong with my compilation.
　　After that, I also tried to compile the lineage branch, with lineageos_tbx605_defconfig. I flashed it to my device running well on AOSP 10(project treble), but the problem was same as the official source.
　　Could you please tell me that what's wrong with my compilation or how to compile it to work well? Thanks a lot .
Jun ASAKA
2021/02/03 (CST)

浅香ジュン said:
Hi there,
　　I just compiled your kernel source you've uploaded on the Github (official branch) with m10_msmcortex_defconfig. Then, I flashed it to my device with anykernel 3, also included all modules, but the wifi does not work(It cannot be turned on). Before I flash it, my device was running well at the stock firmware, so I wonder what's wrong with my compilation.
　　After that, I also tried to compile the lineage branch, with lineageos_tbx605_defconfig. I flashed it to my device running well on AOSP 10(project treble), but the problem was same as the official source.
　　Could you please tell me that what's wrong with my compilation or how to compile it to work well? Thanks a lot .
Jun ASAKA
2021/02/03 (CST)
Click to expand...
Click to collapse
It sounds like the wlan_pronto.ko module is not loading. That's why wifi is not working.
It might be easier to build the msm-3.18.120 branch with YM_x605f_deconfig. That should work.
It does not force module signature checks (CONFIG_MODULE_SIG_FORCE=n). So the stock wlan module (/vendor/lib/modules/pronto/wlan_pronto.ko) should load ok.
If that fails, check the kernel log (dmesg) for errors loading the wlan module. Let me know what the errors are.
official source
The stock wifi module won't work with the kernel from the official branch because CONFIG_MODULE_SIG_FORCE=y. You'll have to download the wlan source from CAF and build it with the same signature. That's a lot of work.
I also had some DT and dm-verity issues with the official source.
lineage-17.1
The lineage-17.1 branch includes the CAF wlan module (in drivers/staging/prima) for Android 10.0. I'm not sure why it's not working for you. Check the kernel log for wlan load errors.
The included CAF wlan module (and your GSI system) are Android 10. Your vendor is Android 9.0 or 8.1. Maybe there's a compatibility issue ? I'm guessing. I haven't tried that kernel with a GSI ROM.

Yahoo Mike said:
It sounds like the wlan_pronto.ko module is not loading. That's why wifi is not working.
It might be easier to build the msm-3.18.120 branch with YM_x605f_deconfig. That should work.
It does not force module signature checks (CONFIG_MODULE_SIG_FORCE=n). So the stock wlan module (/vendor/lib/modules/pronto/wlan_pronto.ko) should load ok.
If that fails, check the kernel log (dmesg) for errors loading the wlan module. Let me know what the errors are.
official source
The stock wifi module won't work with the kernel from the official branch because CONFIG_MODULE_SIG_FORCE=y. You'll have to download the wlan source from CAF and build it with the same signature. That's a lot of work.
I also had some DT and dm-verity issues with the official source.
lineage-17.1
The lineage-17.1 branch includes the CAF wlan module (in drivers/staging/prima) for Android 10.0. I'm not sure why it's not working for you. Check the kernel log for wlan load errors.
The included CAF wlan module (and your GSI system) are Android 10. Your vendor is Android 9.0 or 8.1. Maybe there's a compatibility issue ? I'm guessing. I haven't tried that kernel with a GSI ROM.
Click to expand...
Click to collapse
It's working! thanks a lot！