Database Develop

[PATCH] Kexec-hardboot patch

In this post, I would like to explain what kexec-hardboot patch is.
@kernel developers: I would like to ask you to merge this patch to your kernels, because it is essential part of MultiROM - it allows to boot any kernel without changing the boot partition. I realize that it is no small request, but the patch is not big, touches relatively stable parts of kernel and should not cause any problems. Thank you.
What is kexec?
It is syscall of Linux kernel, which allows you to boot another Linux kernel without restarting the device - "Linux boots itself". The functionality is equivalent to fastboot -c *cmdline* boot zImage initrd.img, but without PC and fastboot. It is fairly known thing, so more info at wikipedia and man kexec.
What is the difference between normal and hardboot exec?
Kexec-hardboot patch adds a real device restart to that process, so that all the drivers can be properly reinitialized. It stores new kernel to RAM, reboots the device as usual, and kernel from boot partition immediately jumps to the one which was stored to RAM before reboot.
Unlike grouper's kexec-hardboot patch, this one only requires the host kernel to be patched. This is one of the improvements Tasssadar made, and I think it is pretty significant.
To sumarize the process:
kexec --load-hardboot.... is called and kernel it loaded into RAM.
kexec -e is called. Special info is written to memory (to area which is not overwritten on reboot) and the device is rebooted.
After reboot, very early in the boot process, kernel checks if that special info is present in RAM and if so, it loads new kernel from RAM and jumps to it.
Kexecd' kernel starts and boots.
For more info, read the original thread.
Patches:
Kernel patch: https://gist.github.com/PatrikKT/50faf32e8931d51c0c9a,
This is the kernel patch. Only the host kernel needs to be patched.
Related CONFIG options:
CONFIG_KEXEC=y
CONFIG_KEXEC_HARDBOOT=y
CONFIG_PROC_DEVICETREE=y
CONFIG_ATAGS_PROC=n # This one is turned on automatically, but it is not needed, so you can disable it.
All these options must be enabled.​
Userspace kexec binary: https://github.com/Tasssadar/kexec-tools
I had to change some things in kexec userspace binary because of some kernel bugs, complete description is in that repository. You can get statically built binary at https://github.com/Tasssadar/multirom/blob/master/install_zip/prebuilt-installer/multirom/kexec​
Usage:
Once you have the kernel patches and kexec userspace binary in place, just run following command to boot into new kernel:
Code:
kexec --load-hardboot zImage --initrd=initrd.img --mem-min=0x20000000 --command-line="$(cat /proc/cmdline)" --dtb
kexec -e
Note the command line parameter - cmdline from bootloader is not added automatically, you have to put it there by yourself.
Authors:
This patch was made by Mike Kasick for Samsung Epic 4G. Since that, it was ported to several devices, one of them is Asus Transformer TF201 - he used patch from TF201 and modified it a bit (basically just changed few SoC specific constants). People at #ubuntu-arm helped him out with that, thanks.
For hammerhead, he has improved the patch a bit - only the host needs to be patched now and he has added support for DTB.
This thread was used as a template Credits to @Tasssadar for his Nexus 5 patch

Awesome people helping with our G2's development. Thank YOU!

patrik.KT said:
I would like to ask you to merge this patch to your kernels, because it is essential part of MultiROM - it allows to boot any kernel without changing the boot partition.
Click to expand...
Click to collapse
What benefit would there be to non-MultiROM users? (Just curious.)

blastagator said:
What benefit would there be to non-MultiROM users? (Just curious.)
Click to expand...
Click to collapse
Any. Just any.

Actually I can't think of anything. It's only to bring the device to a full reboot to load a new kernel.
Odoslané z môjho HTC Desire 601

blastagator said:
What benefit would there be to non-MultiROM users? (Just curious.)
Click to expand...
Click to collapse
Not for common user, in epic4g kexec used by kernel devs to test a new kernel build without replace the existing kernel.
They just load a temporary kernel to test. Then that kernel will gone after a reboot.

Hope to see new kernels that support MultiRom! Great work man!

Would this allow a multiboot with AOSP and Stock roms?

AbdulrahmanAmir said:
it doesnt work while i have stock and the secondary is aosp (dU-dirty.unicorn) when i boot the secondary it works sound only but no display just black screen plzz help
Click to expand...
Click to collapse
The patch is not necessary at the moment, because of the locked bootloader. It's just for devs to be prepared with their kernel when we can unlock the bootloader, so that multirom will work as it should.
Odoslané z môjho HTC Desire 601

Thanks for your great thread. But there is no instruction about how we can add that patch to kernel source. Could you write more details about implanting this patch?

No response??

mohamaadhosein said:
No response??
Click to expand...
Click to collapse
Download the patch file from first post and place it in the kernel root directory. Then you should use this command to check if there are any conflicts: git apply --check <path_to>.patch
If there are no errors, use this to apply: git apply <path_to>.patch
Sorry for the late response but I checked xda when I wasn't home and I forgot to reply when I got home
Odoslané z môjho HTC Desire 601

Hey, some changes need to be made to the patch.
On line 353, change the number from 22 to 21. Also, it has some errors when modifying head.S, which I had to fix manually..
But guys, my kernel is building with the latest multirom. This **** is going to maybe work soon!
I'll keep you all posted.

Thank you man

Guys, I think I've done it. Kexec hardboot patched kernel for 5.1.1 and thus multirom compliant, which I am preparing to build with twrp. this is very exciting.

When will it be ready?

Are you kidding me? No ETAs. I literally haven't even announce it yet and somebody asks for an ETA.... It will be ready once I test everything to boot well on my device.

patrik.KT said:
Download the patch file from first post and place it in the kernel root directory. Then you should use this command to check if there are any conflicts: git apply --check <path_to>.patch
If there are no errors, use this to apply: git apply <path_to>.patch
Sorry for the late response but I checked xda when I wasn't home and I forgot to reply when I got home
Odoslané z môjho HTC Desire 601
Click to expand...
Click to collapse
It says the patch is corrupted on the line 375

[Kernel]***[M8] B14CKB1RD AOSP [11/27]***

[Kernel]***[M8] B14CKB1RD AOSP [11/27]***
B14CKB1RD
Kernel for the HTC ONE M8
~THE MOST UP TO DATE KERNEL FOR THE HTC ONE M8! YOUR ANSWER FOR PERFORMANCE AND SECURITY!~​
B14CKB1RD is a custom kernel meant for AOSP KitKat based Roms. There are 8 governors and 8 I/O schedulers. It's built with the 4.10 sabermod toolchain and -O3 compiled for best optimizations and performance. It comes fully stable and suitable for what uses you want from your phone. From best battery life to best performance you can find for your phone. As usual happy flashing. Just note I am not responsible if you (the user) messes up your phone. I will always be around to help in any way i can so if any issues arise please feel free to send me a pm or ask in the thread. ABSOLUTELY NO TROLLING, BASHING, OR ARGUING on the post please. Actions will be taken and you will loose my personal support.
How to Install:
1. Boot to recovery
2. Flash Kernel .zip
3. Wipe Cache
4. Wipe Dalvik Cache
5. Reboot to profit
Click to expand...
Click to collapse
Features:
Governors:
Dancedance
Intelliactive
interactive
Ondemand
Optimax
Performance
Smartmax
Wheatley
I/O Schedulers:
Bfq
Cfq
Deadline
Fiops
Noop
Sio
Vr
Zen
TCP Congestion Controls:
Bic
Cubic
Highspeed
Htcp
Hybla
Illinois
Lp
Reno
Scalable
Vegas
Veno
Westwood
Yeah
After Install Instructions:
I personally Prefer the use of Trickster MOD for kernel tuning. if you want to switch to using trickster i recommend removing built in kernel tweaking app if possible. I used rom toolbox's app manager to do so. Trickster can be found on Play Store or on xda. For frequency changes to stick: In Trickster Mod, change to the frequency you want and tap on "Frequency Lock" to enable it and tap on the checkmark at the top right to apply and save
Notes:
Again, if you need any kind of support, do not be afraid to ask politely in this thread! Check back often, as I am patching this kernel on an almost daily basis to continue to update it, I am a stickler for security just as much as performance.
Click to expand...
Click to collapse
Credits & Thanks
@Snuzzo (for teaching me all he knows about kernel and his code used on many devices)
@REV3NT3CH ( for being a great source of support, guidance and inspiration. Also for allowing me to build his famous B14CKB1RD Kernel for our M8)
@savoca (for his work and code used on the m8 and many devices, for helping me with the zip script and for releasing the furnace kernel which I used as my starting point)
@xboxfanj (for his work, code, and answering my [at times silly] questions and sharing fixes with me)
and to any other devs i missed...all your work is very much appreciated. if you feel i should put you on the list let me know via pm and ill do so
XDA:DevDB Information
[Kernel]***[M8] B14CKB1RD AOSP [11/27]***, Kernel for the HTC One (M8)
Contributors
Damacy, REV3NT3CH
Source Code: https://github.com/VanirRezound/B14CKB1RD_kernel_m8
Kernel Special Features:
Linux Kernel 3.4.34 (We are updating the kernel often, we started on 3.4.0
UnderVoltage Control
DoubleTap2Wake
Battery Optimizations
Version Information
Status: Stable
Current Stable Version: 3.4.34
Stable Release Date: 2014-11-20
Created 2014-11-27
Last Updated 2016-08-13

A Special thank you to @jtommyj for the donation!
FAQs:
Q: Damacy, is there an available, up to date features list?
A: Yes there is! @JennyLikesSka' s FULL FRONTAL, uncensored, IN-YOUR-FACE Feature list!
Q: Damacy, do you have a Lollipop version of thsi kernel available?
A: Why yes I do! See the above post!
Q: Damacy, what ROM do you use for your phone and for your testing purposes?
A: I use EXODUS or Vanir, Here is the nightlies folder for EXODUS: http://www.vanir-exodus.from-me.org/exodus/m8/
Here's the nightlies folder for Vanir: http://www.emccann.net/nuclearmistake/VanirAOSPNightlies/m8/
Q: Why do you have 2 different sources posted above?
A: I'm an IT guy by trade, and it comes down to 3 simple rules: BACKUPS, BACKUPS, BACKUPS!
Q: Damacy, why are you updating this once or twice (or more) a day or once a week?
A: I'm working on patching this kernel, and patching can either be really fast in the case of small patches, or large (like 3.4.12) that take much longer.
Q: What numbering system are you using for kernel versions?
A: I use the number of the patch as the number for the kernel version.
Q: Do you test every patch that you post?
A: Yes, I test EVERY patch that I post before I post it. I won't update the kernel with a patch that causes poor performance (In the case of 3.4.28 caused stuttering and made the phone unable to register with the network provider!)
Q: Why haven't you include feature _____ in the kernel?
A: I am slow to add new features to the kernel because patching is my main focus at the moment. @JennyLikesSka is the lovely feature queen! She adds features that she and I both think will add performance tweaks to the kernel.
Q: I hear you repeatedly mention 'patching' the kernel, what IS patching?
A: Patching is the means for updating the files used to compile the B14CKB1RD (Linux) kernel. Usually, patching is pretty quickly done, but in the case of HTC kernel files, this is the exact opposite. HTC removed all of the comments from the kernel files, so most of the patching I have to do manually (i.e. BY HAND! :X)
Q: How many patches ARE there?
A: In the current 3.4.X kernel line, there are a total of 106 patches. (Yes, dems a lotta patches!)
Q: "Do you have changelogs for these patches/updates. ? "
A: Yes I do! On the kernel source, there's a file called "PatchLog.txt" that has a list of the files changed by the patch.
Q: Damacy, this kernel is so bleedingly fast! Is this even legal?
A: Yes it is legal! >
Q: Does this kernel have a Flux Capacitor or TARDIS Framework inside of it?
A: Well, I think that would be best answered by asking Candle Jac

Awesome awesome work dude!! So happy to see a kernel built with the Sabermod toolchain. Keep it up, flawless

Hope you all enjoy it.... I know @Damacy here has spent many weeks, days and hours working on bringing my kernel to you guys. No need to really thank me...he did all the hard work for you guys to have it...with very minimal help from me

'Course, I find this after I jump on the L train!
Sent from my HTC6525LVW using Tapatalk

nice one! only thing i miss, is multi-rom support!

_moelle said:
nice one! only thing i miss, is multi-rom support!
Click to expand...
Click to collapse
this can be easily added

Nice kernel m8....thanks for the drop
Sent from my One M8 using XDA Free mobile app

Thanks for the kernel downloading and going to run it and see what it's all about
OK just flashed and I see that Faux Sound is on V32 do you plan on updating it to the latest v36
One more question just curious about the governor optimax never heard of this one

dandan2980 said:
Thanks for the kernel downloading and going to run it and see what it's all about
OK just flashed and I see that Faux Sound is on V32 do you plan on updating it to the latest v36
One more question just curious about the governor optimax never heard of this one
Click to expand...
Click to collapse
To answer your first question, we will get to it. This is a DevDB board post, so go ahead and request the feature. Kernel patching is my main priority at the moment.
To answer about Optimax... "This is based on ONDEMAND, like almost all governors that have arisen from XDA. It contains some enhancements from LG, particularly to freq boost handling so it will boost to a set level, almost like HTC's governor. It has different tunables to the HTC governor but it behaves pretty similar, the tunables it comes with default are a bit more conservative."

Can this kernel be used on Android L?

TouchscreenLover1 said:
Can this kernel be used on Android L?
Click to expand...
Click to collapse
I haven't tested it on L yet. I'm curious to see if it is.

Nice job, Larry!

xboxfanj said:
Nice job, Larry!
Click to expand...
Click to collapse
Thanks bro!
It IS a task to get it patched, but I've been learning a ton.
Thanks again for your input and putting up with my silly questions.

Thanks for the kernel!
Sent from my One M8 using Tapatalk

Any idea why trickster mod is not giving me the option to undervolt on this kernel? Normally there's a list of all the frequencies and I undervolt from anywhere between 50 and 65. Thx!

Damacy said:
I haven't tested it on L yet. I'm curious to see if it is.
Click to expand...
Click to collapse
Just reporting in, doesn't boot on latest cm12
Sent from my 831C using XDA Free mobile app

Maestertk said:
Just reporting in, doesn't boot on latest cm12
Sent from my 831C using XDA Free mobile app
Click to expand...
Click to collapse
Thanks. That'll be added on the list of things to add.

Damacy said:
Thanks. That'll be added on the list of things to add.
Click to expand...
Click to collapse
PM sent

I added an FAQ. I hope that this will answer a few of your questions! Not to mention I have followed up with some kernel updates.

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

[ALL][Kernel][8.0][Stock 4.4.78] Pantheon Kernel {Beta}

What is Pantheon?
A Temple dedicated to all the gods.
That is what this kernel is for: dedication to everyone on the Nash.
Features:
Edits to avoid Safetynet/CTS (If you have root, it will fail signature check inherently without SUhide or Magisk hide)
Disabled CRC check
Built With Linaro as the cross compiler
Over Clock / Under Clock on CPU Frequencies added:
Little CPU: 175 MHz, 230 MHz, 2035 MHz, 2112 MHz
Big CPU: 175 MHz, 230 MHz, 2476 MHz; 2592 MHz
Slight undervolt (our device is overvolted compared to other msm8998 devices)
UC GPU (added 180 Mhz step for battery savings when web browsing, low GPU usage)
OC GPU (changed 710 MHz to 750 MHz)
Same Adrenoboost tweaks as the Pixel 2 ElementalX kernel.
Wakelock fixes by Boeffla
Added Zen, FIOPS, BFQ, and SIO IO schedulers
CPU wake boost driver
Option in Aroma to UC the Big Cluster to 1.9 GHz
Options in Aroma to set the Max frequency of both Clusters (the above option will override this for Big Cluster)
Bugs/Issues:
None! In Alpha Phase, it boots and works...
Download:
Google Drive Link
Instructions:
Download ZIP to phone
Boot to TWRP.
Flash and follow prompts in Aroma
Reflash root if you want root.
Version Information
Status: Beta
Current Stable Version:
Stable Release Date:
Created 2018-06-18
Last Updated 2018-07-04
Source: https://github.com/Uzephi/Nash_Oreo
Git Branch: oreo-8.0.0-release-nash
Cross Compiler: Linaro 4.9
Branch: Android 8.0.y
Kernel Version: 4.4.y
defconfig: nash_defconfig
Credits: @joemossjr - for collaborating and getting this working and debugging w/ me to get the best possible experience for our community. @invisiblek for all the work he's done for our device tree @npjohnson for his work on our device tree.
Thanks and Mentions:
@Lord Boeffla for his wakelock code. @nathanchance for the assistance and amazing guides and keeping msm-8998 up to date with linux-stable @jbats for being awesome on this device.
@flar2 for his work on our chipset, msm8998
All other developers shown in commit history.
(Quoted from Nathan Chance)
A note about donations
Quite a few people have asked to donate to me in the past and I have turned them down. I am not in this for the money, this is my hobby, something I truly enjoy. If you truly want to donate to something (it is not expected in the slightest), I recommend an entity like the Open Source Initiative, the Free Software Foundation, XDA, or any one of the people I have thanked in the OP. Additionally, you are free to copy any and all of my work; the only thing I request is that you not ask for donations as well (though I can't really enforce this lol). Thank you.

Change Log:
2018-06-18
Initial Release - Alpha (No updates from Motorola since Nov 2017 per their Nash Git. See post 4)
2018-07-04
Updated with new tags pushed by Motorola on their Git.

Reserved x2

Disclaimer:
Motorola has not released source code for our device's kernel for the March or May Security updates. So if Feb, Mar, Apr, or May Android security patches had any kernel changes, this kernel does not have those in it. See below with link to open issue on Motorola's Github.
Issue has been fixed and issue 152 has been closed by me.
https://github.com/MotorolaMobilityLLC/kernel-msm/issues/152

first!
i was just trying to do my own stock kernel build and it failed miserably. gonna give this a go

Midnight_Rider said:
first!
i was just trying to do my own stock kernel build and it failed miserably. gonna give this a go
Click to expand...
Click to collapse
Everyone has permission to fork from my kernel, just give credits like OP states.

Unfortunately it seems that this kernel, just like your previous releases, causes my device to randomly freeze and reboot, sometimes throwing it into a loop. :/

I'm on stock 27.1.2 and there has been some improvement as far as wifi drops, but on rare occasions it still freezes and reboots. This is on a straight stock setup and a known issue for moto/lenovo by the way. Seems to happen most noticeably when something cpu or graphic intense it taking place. Wifi resume from screen off is a little slow, but better than 27.1 and completely dropping out. This isn't because of Pantheon, this is all stock moto.
I'm hoping with Pantheon the cpu wake boost will help with wifi resume and maybe an overclock with give that little extra to keep it from freezing/rebooting when demand is high. Hopefully after a little tweaking and testing those stock issues will be resolved and moto/lenovo can finally come to terms with their wonky kernel and wifi.
If they would just go a little more open source in those areas they'd have a killer phone because I don't have those problems when I run custom roms and kernels, just stock.
So thanks @Uzephi and the other devs out there for keeping things on the up n' up.

donjuro said:
Unfortunately it seems that this kernel, just like your previous releases, causes my device to randomly freeze and reboot, sometimes throwing it into a loop. :/
Click to expand...
Click to collapse
Sorry. This was made by request. I have not personally tested it. It has the same commits as my aosp kernel minus the upstream done to my aosp kernel. All modifications I have added outside of upstream to Linux stable have been added. These modifications run just fine for me on aosp. I will not go back to stock unless I have to. I would need a kernel panic log, which I think Motorola disabled on a ROM level. If you can PM me a last_kmesg I can look through it, but last I was on stock, I couldn't find it in the proc folder.

Thanks, i'm gonna test it!

no data /wifi drop/ no random boot, testing battery and performance
thanks mate

Whats the difference between this one and your previous stock kernel besides the underclock.

mookiexl said:
Whats the difference between this one and your previous stock kernel besides the underclock.
Click to expand...
Click to collapse
https://github.com/Uzephi/Nash_Oreo/commits/oreo-8.0.0-release-nash
Some optimizations that don't need to be discussed. Everything pushed on the 18th of June.
Edit: CPU wake boost. Little cluster getting 2112 MHz OC, WiFi driver fix and a few other fixes as well, like to the Adreno driver (GPU).

Uzephi said:
https://github.com/Uzephi/Nash_Oreo/commits/oreo-8.0.0-release-nash
Some optimizations that don't need to be discussed. Everything pushed on the 18th of June.
Edit: CPU wake boost. Little cluster getting 2112 MHz OC, WiFi driver fix and a few other fixes as well, like to the Adreno driver (GPU).
Click to expand...
Click to collapse
Thanks, testing now. I will add that stock plus your original oreo kernel has been the best experience I've had with this device thus far for battery and performance.

Not bad for a test run, been running sio i/o scheduler. Gonna tweak some more and see how good it gets.

@Uzephi, this caused a bootloop on Encrypted device.

pvsgh said:
@Uzephi, this caused a bootloop on Encrypted device.
Click to expand...
Click to collapse
No log, no go. I don't run stock to even test this. I can't fix if you just state it doesn't work. I need a log of when it happens.

Uzephi said:
No log, no go. I don't run stock to even test this. I can't fix if you just state it doesn't work. I need a log of when it happens.
Click to expand...
Click to collapse
The device was not even being detected by PC, so not sure how to capture the logs. I restored the stock kernel from backup for now.

pvsgh said:
The device was not even being detected by PC, so not sure how to capture the logs. I restored the stock kernel from backup for now.
Click to expand...
Click to collapse
Others have used it fine. The device is encrypted by default. There has to be something else that would cause a boot panic other than encryption when others who are encrypted did not run into the issue. Are you able to boot into recovery? If so, encryption and other stuff that would prevent a boot are fine as recovery will boot with the same kernel as system does.

Uzephi said:
Others have used it fine. The device is encrypted by default. There has to be something else that would cause a boot panic other than encryption when others who are encrypted did not run into the issue. Are you able to boot into recovery? If so, encryption and other stuff that would prevent a boot are fine as recovery will boot with the same kernel as system does.
Click to expand...
Click to collapse
Yes, I was able to boot into recovery after the bootloop. That's how I restored the kernel from backup.
I don't need the encryption on the device, just trying to avoid another format to remove encryption.
Just got this phone rooted yesterday, hoping to build a flashable stock debloated ROM for this phone in near future.