Development [Kernel][08.06.2022][Android 12.1.0]Kirisakura 3.0.1 for Pixel 6/Pro aka "RAVIOLE"

Search This thread

Freak07

Recognized Developer / Recognized Contributor
Jan 2, 2011
5,585
18,582
I have found the May update to be a huge step backwards from April, I have the QPR3 beta running on my device now and it is far more stable. More acceptable battery and temperatures.
Not the case for me. Battery and temps are the same as before on my end.
There has been nothing that's not stable in May for me too.

Phone temperature 38 degrees Celsius when using telegram :( The set of applications is minimal) Wi-fi and lte - the temperature is the same (((Probably it's still in the May update._.

I'm sorry, I'm just afraid that something is wrong with the phone. I thought that others also have problems with overheating.
Depends on your ambient temperature if that's normal or not.
I'd check if something is pinning the CPU in background, could be an app getting stuck or a service.

Could be something else that was introduced in May update and only affects some users and not others.

Check the post here that links how to do this:

In this case it turned out to be Facebook.

2 weeks on the kernel running stock 12.1. Things I have noticed:
1) Battery life is maybe 10% better on average, mostly during standby and heavy usage. There are a few medium use days that do worse, but over all its a bit better. My battery life was already pretty good even on stock.
2) Yes the thermals are better. But I noticed that there is absolutely nothing you can do against 5G or LTE overheating. Using data pretty much guarantees higher temps, but on wifi it heats up less, but my device didn't have much issues.
3) Overall everything is as stable if not more stable than stock, if you have bugs, this may or may not help. Things like the swipe up freeze bug still happens occasionally, as app related bugs won't be fixed by a kernel.
Nope, if mobile network has a weak signal it takes more battery (which also causes more heat due to higher power draw), you're entirely correct. (y) most of this is due to baseband and not kernel, so the kernel doesn't have much impact on that, just like other userspace/framework related issues.
 
  • Like
Reactions: roirraW "edor" ehT
Could be MGLRU then. Though if you´re the only one with the issue it might be something else.

I wonder where those Google Play services errors in the logs before the OOM situation happens though.

The userspace lowmemorykiller handles most of the management on pixels. I wonder if MGLRU somehow interferes with that and you´re usage triggers a very specific bug. Or an app triggers a very specific bug, that leads to the situation.
You can try to gather more logs, but at the moment I´m unsure what´s happening.

If I find time I´ll compile a build without MGLRU for you and sent it via PM.
Hi freak, is it possible to make a version like this? Not a demand or anything of course, only if you have the time and will.
 

Freak07

Recognized Developer / Recognized Contributor
Jan 2, 2011
5,585
18,582
Hi freak, is it possible to make a version like this? Not a demand or anything of course, only if you have the time and will.
sorry, I completely forgot about that.

I´ll send you a PM once I have a build with it completely removed. Alternatively you can set /sys/kernel/mm/lru_gen/enabled to "N" (for example in EXKM, tools, user settings simply add the node) to disable it at runtime. (please note that this setting might be overwritten each time you boot, so wait a while after the phone booted successfully to change this setting)
If you´re still running the kernel I´d appreciate if you could report back with it disabled that way. If not I´ll try to get a build out for you. :)
 
  • Like
Reactions: yyz71 and arvylas

Admiral2145

Senior Member
Sep 28, 2010
2,074
362
Xiaomi Poco F3
Google Pixel 6
dtbo dtbo.img
vendor_boot vendor_boot.img

How often do we have to update or flash these files... I'm asking because after I root May then I use fkm to flash this kernel or another one I get bootloops until I flash the stock kernel then root via magisk.... This is the 1st time I've ever ran into this issue... April March and Feb was flawless with fkm and 24.3 stable.
I'm new and can't seem to find where I was or the article/guide that shows how to do this part of vendor and enable /disable this part... I have to manually download the whole factory image instead of doing the Ota to update via computer.... If that matters/i see it overwrites vendor with this process.
 

awarman

Senior Member
Sep 19, 2010
76
47
Google Pixel 6 Pro
To get back to stock conditions after flashing the kernel.zip follow the instructions in the FAQ.

You can try to fastboot boot an older boot.img (from april or march stock firmware, after you restored stock images as described in the FAQ), let the phone try to boot once and crash, flash correct boot.img and afterwards try again. Sometimes that resolves issues for people.

This is not a kernel issue, but some other stuff is wonky on the Pixel 6, so I can´t really help.
I think by now it´s advisable to keep verity/verification disabled when updating the phone each month as that seems to be the root cause of all the problems. No matter if it´s magisk related or something with verity is up on pixel 6 devices on stock firmware too.



What a bummer :( Sorry to hear that. I suppose you tried the fingerprint calibration tool google provides already?

As far as I´m aware fingerprint sensor and display need to be paired correctly. Sometimes this is a very finicky process. I know this from other phones as well, where even official repair centers are not able to do this process without jumping through loops and holes and need to order proper equipment. This is really a pain on modern devices.
On the other hand most people probably enjoy if their devices are factory calibrated and this calibration happens unique to every display for example. Problem is, if you switch the screen in most cases you end up with the "wrong" calibration. Maybe it´s something similar here.

I don´t see any log attached to your post. It seems the upload went wrong.

I tried to reproduce at my end constantly yesterday and today too. Also in retrospect to this post from you I can´t reproduce it. I´m at 1 1/2 day of uptime and used the device pretty heftily throughout. Scrolling in launcher is smooth while taking a screenrecord.

I´ll take a look at your log once you´ve uploaded it and you also get a DM from me :)

as @roirraW "edor" ehT said this is not really a welcome subject in any development threads here.

Best advice is to try both kernels and compare for yourself. :)

34°C as battery temp reported in EXKM/FKM is I´d say still acceptable depending on what you´re doing with the device and your ambient temperatures. If you´re slowly starting into summer/spring, this will only get worse as ambient temps rise.

The last few gens of SoCs were pushed to achieve higher and higher peak performance. While they got more efficient as well, the "price" measured in peak power draw those SoCs have to pay to achieve those higher levels of peak performance is a lot higher as well.
None of those SoCs, be it Snapdragon, Exynos or Tensor can sustain their peak performance for even 2 minutes without significantly heating up.
Higher power draw means more heat inside a closed system without active cooling.


To better understand the picture as a whole.
There are loads of temp sensors in the phone. So let´s say you´re actively using the phone while doing a lot of scrolling, loading different apps, doing some multitasking. Depending on ambient temp and the overall temp the phone has (let´s take the battery temp exkm reports as a fixed point, which represents a sensor close to the battery) while starting this experiment the SoC right where the CPU sits will be between 50-90°C while your actively using the phone in the way described above. The heat produced there must go somewhere. It will inevitably heat up the phone as there´s no active cooling. If ambient temp is higher, the phone will heat up quicker, if you´re starting with a warm phone, the phone will heat up quicker than starting with a cool phone. If the overall phone is warmer, the SoC area will also be accordingly "warmer" during the exact same experiment compared to a colder phone.
To give another good indicator of the state of modern smartphone SoCs: While an app is launched and the powerhal requests high/max performance from the phone, the big cores ramp up to 90°C in less than a second.

Another example: Just watching a youtube video indoors on WiFi (let´s say 21°C inside) with not so bright screen will produce a very slight amount of heat as well. But usually the phone can sustain this or even cool down passively while doing so. CPU temps as long as you´re not touching the screen will probably stay below 40°C and it will groove probably in at just about 30°C battery temp reported in EXKM.
Watching a youtube video outside in the sun, display brightness to the fullest, on mobile data with a not so good signal quality and it´s a whole different scenario. CPU temps won´t stay below 40°C as the whole phone is warmer, display draws a lot more power, radio draws more power. All of this heat needs to go somewhere and heats up the phone.


It´s probably best to flash this if banking apps are not working on this kernel, while working on stock kernel yes. I´ll include all of those changes in the next release. :)
We'll try this again. It didn't let me edit my message and add it for some reason.

I am getting lag right now when recording but it's not awful. Performed a couple reboots when I was trying to disable the fingerprint service and since it only jitters or lags after a number of hours.

Do you have any idea how I would disable it? I definitely want to rule that out as a factor and so far I've come up short. I read that I could unmount the driver but I'm not sure what driver it is.
 
  • Like
Reactions: Freak07
sorry, I completely forgot about that.

I´ll send you a PM once I have a build with it completely removed. Alternatively you can set /sys/kernel/mm/lru_gen/enabled to "N" (for example in EXKM, tools, user settings simply add the node) to disable it at runtime. (please note that this setting might be overwritten each time you boot, so wait a while after the phone booted successfully to change this setting)
If you´re still running the kernel I´d appreciate if you could report back with it disabled that way. If not I´ll try to get a build out for you. :)
Didn't know it was that easy. I'll flash back 2.4.0 and report back using the flag.
Edit: which value should I set? 0x0000?
Btw I was using radioactive kernel for the past week and didn't face the same issue. Do you know if it has the MGLRU patch as well?
 

Attachments

  • Screenshot_20220518-012512.png
    Screenshot_20220518-012512.png
    72.4 KB · Views: 61
Last edited:
  • Like
Reactions: Freak07

Freak07

Recognized Developer / Recognized Contributor
Jan 2, 2011
5,585
18,582
Didn't know it was that easy. I'll flash back 2.4.0 and report back using the flag.
Edit: which value should I set? 0x0000?
Btw I was using radioactive kernel for the past week and didn't face the same issue. Do you know if it has the MGLRU patch as well?
yeah, either that or just simply "N" or "0" :)
Wanted to do a separate build as disabling via runtime is not exactly the same as reverting all the needed code for MGLRU.

Yes radioactive has MGLRU included as well according to the source. So it might not be that after all, but well hard to say.

You should soon receive a PM with something to test on your end. :)

We'll try this again. It didn't let me edit my message and add it for some reason.

I am getting lag right now when recording but it's not awful. Performed a couple reboots when I was trying to disable the fingerprint service and since it only jitters or lags after a number of hours.

Do you have any idea how I would disable it? I definitely want to rule that out as a factor and so far I've come up short. I read that I could unmount the driver but I'm not sure what driver it is.
I tried constantly over the day yesterday and I still can´t reproduce lag during screenrecording similar to the one you shared.
Might need to put the log in a zip, like you did with the dmesg previously. XDA is somtimes a bit finicky.

Unfortunately I don´t know how to stop the phone trying to poll there with a simple adb command.

I think rmmod´ing the driver won´t work as it´s not allowed to unload the driver during runtime. the command would be similar to this:
rmmod /vendor/lib/modules/5.10.116-Kirisakura_Raviole_2.5.1-992957-geed62cb785cd/kernel/drivers/input/fingerprint/goodixfp.ko

where you replace the kernel version, with the version of the kernel you´re currently on.
Maybe it works for you as you´re fp scanner is already broken, but I don´t think so.
 

awarman

Senior Member
Sep 19, 2010
76
47
Google Pixel 6 Pro
yeah, either that or just simply "N" or "0" :)
Wanted to do a separate build as disabling via runtime is not exactly the same as reverting all the needed code for MGLRU.

Yes radioactive has MGLRU included as well according to the source. So it might not be that after all, but well hard to say.

You should soon receive a PM with something to test on your end. :)


I tried constantly over the day yesterday and I still can´t reproduce lag during screenrecording similar to the one you shared.
Might need to put the log in a zip, like you did with the dmesg previously. XDA is somtimes a bit finicky.

Unfortunately I don´t know how to stop the phone trying to poll there with a simple adb command.

I think rmmod´ing the driver won´t work as it´s not allowed to unload the driver during runtime. the command would be similar to this:
rmmod /vendor/lib/modules/5.10.116-Kirisakura_Raviole_2.5.1-992957-geed62cb785cd/kernel/drivers/input/fingerprint/goodixfp.ko

where you replace the kernel version, with the version of the kernel you´re currently on.
Maybe it works for you as you´re fp scanner is already broken, but I don´t think so.
Tried it and it looks to still be polling even with a successful command. As for the lag I rebooted and it ran overnight but it's not lagging at all which leads me to believe it's something I am running through the day? Not sure.

I have tried the google fingerprint calibration too but it always ends up telling me I have a newer version thus I've had no success.

I realize this is unrelated to kernel but would you know of a way to stop or disable the ServiceManager from trying to start the FP reader? Maybe a magisk mod? Understood if you don't want to discuss this on your kernel thread.

Thanks for the help! We'll see if 2.5.1 changes anything.
 

Freak07

Recognized Developer / Recognized Contributor
Jan 2, 2011
5,585
18,582
Tried it and it looks to still be polling even with a successful command. As for the lag I rebooted and it ran overnight but it's not lagging at all which leads me to believe it's something I am running through the day? Not sure.

I have tried the google fingerprint calibration too but it always ends up telling me I have a newer version thus I've had no success.

I realize this is unrelated to kernel but would you know of a way to stop or disable the ServiceManager from trying to start the FP reader? Maybe a magisk mod? Understood if you don't want to discuss this on your kernel thread.

Thanks for the help! We'll see if 2.5.1 changes anything.
if my suggestion above did not work for unloading the fingerprint module/driver and thereby stopping the polling I don´t have any other ideas sorry.

maybe a rom developer knows how to prevent that single part from starting, but I don´t have any other ideas. I´m also not sure if magisk can help as the file vendor/etc/init/fingerprint-goodix.rc gets parsed before magisk can change any files during bootup.
 

Sonoo

Senior Member
Hi, I am trying to flash this kernel (2.4.0) on stock Pixel 6 pro rooted with magisk and updated to the latest canary (24312) and May update. Every time I flash it via EXKM or FKM it flashes normally but after reboot, it gets up to the google logo but then hard crashes and starts looping. I managed to go to the bootloader and was able to restore it to the stock kernel. What am I doing wrong here? I can't figure it out! Any suggestions.
 

bleez99

Senior Member
May 1, 2011
284
215
Hi, I am trying to flash this kernel (2.4.0) on stock Pixel 6 pro rooted with magisk and updated to the latest canary (24312) and May update. Every time I flash it via EXKM or FKM it flashes normally but after reboot, it gets up to the google logo but then hard crashes and starts looping. I managed to go to the bootloader and was able to restore it to the stock kernel. What am I doing wrong here? I can't figure it out! Any suggestions.
Use Magisk stable 24300
 

Sonoo

Senior Member

V0latyle

Forum Moderator
Staff member
Sorry, but I was referring to the above guideline. Returning to stable now. :)
This is only for the stock kernel. A few things have changed with the Pixel 6 boot image that have required Magisk fixes. If a kernel developer is using the stock kernel as a base and incorporates the same changes, then yes one would want to use the latest Canary. However, many developers either use an old base, or build their kernel from scratch using the original kernel source; in those cases one could probably use almost any version of Magisk since 24000.
 

Sonoo

Senior Member
This is only for the stock kernel. A few things have changed with the Pixel 6 boot image that have required Magisk fixes. If a kernel developer is using the stock kernel as a base and incorporates the same changes, then yes one would want to use the latest Canary. However, many developers either use an old base, or build their kernel from scratch using the original kernel source; in those cases one could probably use almost any version of Magisk since 24000.
Didn't know that. Thank you.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 34
    Update to 3.0.0

    Hey guys and girls,


    Alright here´s the next update and it´s a very big one that´s why I decided to bump the kernel version to 3.0.0.

    I decided to rebase the kernel ahead of time. The base kernel is now build upon the Android 13 branch, but made to work on A12 by reverting a few changes that depend on too much firmware updates outside the kernel. That will also ease the transition for me once A13 stable is dropped.
    Thanks to the way the kernel is build the GKI way, the rest of the device specific drivers could be adjusted to work on A12 as well.
    There are quite a few improvements overall on the A13 branch and now we can take advantage of them before A13 drops as stable. Please note this kernel is made to work on A12 stable June firmware, not A13 beta.

    Thanks to @capntrips and all his hard work on hashtree patcher, there should be no problems flashing the updated kernel.zip on latest magisk canary (which some users may want to use to fix certain apps otherwise detection root) while leaving the verity/verification flags enabled when updating the phone as it´s integrated in the kernel.zip now. A huge thanks to @capntrips at this point.

    I will also stop distributing the files for the manual install as flashing via @capntrips kernel flasher app, which can be found here, is open source and free, works perfectly fine for me and that spares me a lot of work for each release.

    Now to the actual kernel changes:

    The kernel was rebased on the A13 branch for the Pixel 6 Pro but made to work on A12, which brings a lot of improvements all around.

    There´s a PMU limiting feature introduced in the A13 kernel. It was imported in the previous 2.4.0 release too and configured to try to reduce heat, reduce the usage of high cpu freqs when it isn´t needed. The explanation can be found in the release post of 2.4.0.
    I went ahead and refined the implementation and usage of that feature again.
    Short explanation: The PMU limiter can cut back max cpu freq if the PMU (performance monitoring unit) doesn´t cross a certain threshold. If that threshold is crossed the limit is lifted and the phone is allowed to use peak performance.
    While the previous approach restricted the cores just to a single limit of 1,4GHZ/1,6GHZ/2,4GHZ (for little/mid/big cores), the new approach restricts to different limits based on interaction and scenario what´s happening.
    That means there are different limits and thresholds for app launches, interaction (tapping the screen, scrolling), display idle (no movement on screen content, nothing interactions with the display, no tapping the screen etc).

    If none of the conditions below are met the limits are 1,19GHZ/1,32GHZ/1,42GHZ (for little/mid/big cores) if the performance threshold is not crossed.
    During app launches we keep the limit of 1,4GHZ/1,6GHZ/2,4GHZ (for little/mid/big cores) if the performance threshold is not crossed. (that´s useful to not boost too much if an app is already in memory)
    During scrolling limits of 1,4GHZ/1,6GHZ/1,8GHZ (for little/mid/big cores) will be set. The reason for that I will explain later.
    During idle screen limits of 1,19GHZ/1,0GHZ/1,1GHZ (for little/mid/big cores) will be set if the threshold is not crossed.

    If the device really needs max perf, the limits will be crossed and it will also perform to its max. The performance impact by the PMU limiter is minimal to negligible/non-existent.

    Uclamp value of top-app tasks, rt-tasks and sf-tasks are raised during interaction. This improves scrolling performance as it biases tasks to start on a mid or big CPU rather than a small one. By restricting the maxfreq of mid and big cores via the PMU limiter during scrolling/interaction we do not generate additional heat by doing that. The threshold was specifically tuned by doing a lot of tracing to achieve not crossing the PMU limit during scrolling. For example gmail scrolls a lot smoother now. Some apps like twitter just need to fix scrolling on their own end.

    BFQ improvements from linux-main were backported.
    Scheduler updates for pelt, load, tasks placement were backported from linux-main.
    LRNG was bumped to V45.
    An improved energy model for thermal control is used.

    And a huge bunch of additional changes.

    If you´re one of the unfortunate ones that suffer from the device is corrupt bug on pixel 6 series please take a look at the FAQ at the beginning of this thread it contains a solution. The issue is probably caused by a bug that affects pixel 6 devices and has nothing to do with magisk or a kernel, it just happens to get triggered when using any of those.



    Changelog:


    - Rebase kernel on A13 branch and make it work on A12
    - preserve all previous features and improvments
    - Linux-stable merged to 5.10.120
    - Use prebuilt Google Clang 14.0.7 for compilation
    - Scheduler improvements from latest linux kernel
    - BFQ improvements from latestlinux kernel
    - LRNG bumped to V45
    - use improved energy model for exynos cpu cooling/thermal control
    - MGLRU changes and updates
    - affine IRQS to CPU 7 during camera usage for improved performance as it tends to overload the little cores
    - allow GPU to scale down to 150mhz, but boost to higher value in case of interaction via powerhal
    - safetynet issues some users were experiencing while running 2.4.0 official release, but fixed later via the release here are solved and gone (if your app does not work due to root on stock kernel, the same will be the case here)
    - updated anykernel3.zip (thanks to @osm0sis) -> allow flashing using latest canary with enabled vbmeta flags ( huge thanks to @capntrips )
    - loads of other changes, please check github



    Download:

    If you´re coming from another kernel restore stock boot.img, dtbo.img, vendor_boot.img and vendor_dlkm.img before flashing. Thank you.

    I wish everybody a great day/evening!
    Have fun, enjoy the kernel and your phone.


    If you like my work please consider a donation.
    Donations are not mandatory but very welcome.
    If you like my work and want to buy me a coffee/green tea: http://paypal.me/freak07
    20
    I assume the touchscreen will need the updated drivers that were needed for QPR beta builds before.

    It´s getting late here and usually google is pushing the source somewhere during nighttime in my timezone. I´ll try to get the kernel updated as soon as possible once I know it´s stable.

    I wish everybody a great day/evening.
    20
    Update to 3.0.1

    Hey guys and girls,


    Alright here´s a hotfix for 3.0.0 which had broken netflix, amazon prime video, HBO and other streaming apps playback that relies on a trusted secure connection to establish playback. (thanks to @Gungrave223 for the report)
    The A12 hal is not yet ready for some driver changes introduced in the A13 kernel base. Those changes were identified and reverted. Thanks to @TotallyAnxious for providing me the logs via PM.
    Playback for those services works fine again on 3.0.1.
    Seems like during testing for just a little bit over the last two weeks no time was found to watch a single stream on the phone and that little bug slipped through. 🤠

    I´ll include the changelog for 3.0.0 again in this post in hide tags as I´m sure not everyone has yet upgraded and that post contains a lot of vital info.
    The original release post for 3.0.0 can be found following this link.

    I wish everyone a nice day.
    Changelog for 3.0.0 below:

    Alright here´s the next update and it´s a very big one that´s why I decided to bump the kernel version to 3.0.0.

    I decided to rebase the kernel ahead of time. The base kernel is now build upon the Android 13 branch, but made to work on A12 by reverting a few changes that depend on too much firmware updates outside the kernel. That will also ease the transition for me once A13 stable is dropped.
    Thanks to the way the kernel is build the GKI way, the rest of the device specific drivers could be adjusted to work on A12 as well.
    There are quite a few improvements overall on the A13 branch and now we can take advantage of them before A13 drops as stable. Please note this kernel is made to work on A12 stable June firmware, not A13 beta.

    Thanks to @capntrips and all his hard work on hashtree patcher, there should be no problems flashing the updated kernel.zip on latest magisk canary (which some users may want to use to fix certain apps otherwise detection root) while leaving the verity/verification flags enabled when updating the phone as it´s integrated in the kernel.zip now. A huge thanks to @capntrips at this point.

    I will also stop distributing the files for the manual install as flashing via @capntrips kernel flasher app, which can be found here, is open source and free, works perfectly fine for me and that spares me a lot of work for each release.

    Now to the actual kernel changes:

    The kernel was rebased on the A13 branch for the Pixel 6 Pro but made to work on A12, which brings a lot of improvements all around.

    There´s a PMU limiting feature introduced in the A13 kernel. It was imported in the previous 2.4.0 release too and configured to try to reduce heat, reduce the usage of high cpu freqs when it isn´t needed. The explanation can be found in the release post of 2.4.0.
    I went ahead and refined the implementation and usage of that feature again.
    Short explanation: The PMU limiter can cut back max cpu freq if the PMU (performance monitoring unit) doesn´t cross a certain threshold. If that threshold is crossed the limit is lifted and the phone is allowed to use peak performance.
    While the previous approach restricted the cores just to a single limit of 1,4GHZ/1,6GHZ/2,4GHZ (for little/mid/big cores), the new approach restricts to different limits based on interaction and scenario what´s happening.
    That means there are different limits and thresholds for app launches, interaction (tapping the screen, scrolling), display idle (no movement on screen content, nothing interactions with the display, no tapping the screen etc).

    If none of the conditions below are met the limits are 1,19GHZ/1,32GHZ/1,42GHZ (for little/mid/big cores) if the performance threshold is not crossed.
    During app launches we keep the limit of 1,4GHZ/1,6GHZ/2,4GHZ (for little/mid/big cores) if the performance threshold is not crossed. (that´s useful to not boost too much if an app is already in memory)
    During scrolling limits of 1,4GHZ/1,6GHZ/1,8GHZ (for little/mid/big cores) will be set. The reason for that I will explain later.
    During idle screen limits of 1,19GHZ/1,0GHZ/1,1GHZ (for little/mid/big cores) will be set if the threshold is not crossed.

    If the device really needs max perf, the limits will be crossed and it will also perform to its max. The performance impact by the PMU limiter is minimal to negligible/non-existent.

    Uclamp value of top-app tasks, rt-tasks and sf-tasks are raised during interaction. This improves scrolling performance as it biases tasks to start on a mid or big CPU rather than a small one. By restricting the maxfreq of mid and big cores via the PMU limiter during scrolling/interaction we do not generate additional heat by doing that. The threshold was specifically tuned by doing a lot of tracing to achieve not crossing the PMU limit during scrolling. For example gmail scrolls a lot smoother now. Some apps like twitter just need to fix scrolling on their own end.

    BFQ improvements from linux-main were backported.
    Scheduler updates for pelt, load, tasks placement were backported from linux-main.
    LRNG was bumped to V45.
    An improved energy model for thermal control is used.

    And a huge bunch of additional changes.

    If you´re one of the unfortunate ones that suffer from the device is corrupt bug on pixel 6 series please take a look at the FAQ at the beginning of this thread it contains a solution. The issue is probably caused by a bug that affects pixel 6 devices and has nothing to do with magisk or a kernel, it just happens to get triggered when using any of those.



    Changelog:


    - Rebase kernel on A13 branch and make it work on A12
    - preserve all previous features and improvments
    - Linux-stable merged to 5.10.120
    - Use prebuilt Google Clang 14.0.7 for compilation
    - Scheduler improvements from latest linux kernel
    - BFQ improvements from latestlinux kernel
    - LRNG bumped to V45
    - use improved energy model for exynos cpu cooling/thermal control
    - MGLRU changes and updates
    - affine IRQS to CPU 7 during camera usage for improved performance as it tends to overload the little cores
    - allow GPU to scale down to 150mhz, but boost to higher value in case of interaction via powerhal
    - safetynet issues some users were experiencing while running 2.4.0 official release, but fixed later via the release here are solved and gone (if your app does not work due to root on stock kernel, the same will be the case here)
    - updated anykernel3.zip (thanks to @osm0sis) -> allow flashing using latest canary with enabled vbmeta flags ( huge thanks to @capntrips )
    - loads of other changes, please check github



    Download:


    If you´re coming from another kernel restore stock boot.img, dtbo.img, vendor_boot.img and vendor_dlkm.img before flashing. Thank you.

    I wish everybody a great day/evening!
    Have fun, enjoy the kernel and your phone.


    If you like my work please consider a donation.
    Donations are not mandatory but very welcome.
    If you like my work and want to buy me a coffee/green tea: http://paypal.me/freak07
    16
    Hello everyone,

    I just found a very small oversight regarding the powerhal, which I corrected in the kernel.zip now. The kernel itself hasn´t changed.

    I re-uploaded the zips for 3.0.0. If you flashed them already prior to this post, feel free to reflash. It probably won´t hurt, that much to run the old zip, but it´s better to flash the new one. Just flash over 3.0.0 if you´re already running it.
    You can grab the updated 3.0.0 zips from the release post by following this link.

    Sorry for any inconvenience caused. I wish everyone a great day.
    10
    Now to my question, if I am on June update, magisk 25 beta installed and rooted, should the 3.0.1 kernel install with FKM successfully even though I still have Verity and verification enabled?
    The issue is Magisk 24303+ no longer strips avb from fstab, so when the phone boots, first stage mount looks at the fstab entry for vendor_dlkm, which references vbmeta, so it looks at the hashtree descriptor for vendor_dlkm in vbmeta and tries to setup a verity device using those values, but vendor_dlkm for the kernel is different from stock, so those values are incorrect, mounting fails, and the device bootloops.

    If you have verity or verification disabled, first stage mount ignores avb in the fstab entry and mounts the partition directly.

    When flashing the kernel with AK3, if you have verity or verification disabled, AK3 skips the patching step. If you have a stock vbmeta, then AK3 will run Hashtree Patcher on your vbmeta and vendor_dlkm partitions, updating the hashtree descriptor in vbmeta and appending the hashtree and FEC data to the vendor_dlkm partition.

    tl;dr While the method differs slightly, 3.0.1 should flash and boot successfully with or without either of the disable flags.
  • 100
    Kirisakura-Kernel for the Pixel 6/Pro

    Hello everyone,

    To keep it short: Here is Kirisakura - Kernel for the Google Pixel 6 Pro aka Raven and the Pixel 6 aka Oriole, together Raviole.
    I would appreciate if everybody that flashes the kernel, reads at least once through this opening post and the following ones.

    The kernel aims to keep most of the subsystems updated, way ahead of the stock kernel, thereby improving security, stability and performance!
    This includes Linux-Stable, F2FS-Stable and kernel/common!
    If that got you curious, have a read about linux-stable and why it is important here. The stable-process is not the same for every subsystem, but the general idea, rule of thumb and benefits are applicable for other subsystems as well.

    The kernel includes a lot of improvements and contributions from other developers as well. Without this kernel would not exist.
    A big part of improvements originate from @arter97´s, @kdrag0n´s and @Sultanxda´s work. Many others contributed in some way or another to this kernel.
    A big thanks to all of them at this place!

    Now lets continue with a list of features in the next paragraph!

    Features:
    Main Features:
    - Based on latest A13 kernel sources from Google, Kernel is made for Android 12
    - Linux-Stable-Upstream included to 5.10.120
    - Compiled with prebuilt Google clang 14.0.7
    - merged kernel/common (improvements to android-common-kernel straight from google)
    - Multi-gen LRU backported (more info here, here as well and here) to improve mm and reduce cpu cycles
    - Utilize an additional kswapd thread to increase throughput for memory reclaim
    - pelt multiplier tied into powerhal to speed up scheduler during interaction (more info here)
    - prevent frequency spikes caused by small transient tasks when the device is idle(more info here)
    - tie mechanism to prevent frequency spikes caused by small tasks also into powerhal
    - scheduler improvements for RT (realtime) tasks
    - introduce and setup PMU limiter (prevents CPU from spiking to max when it isn´t needed, based on PMU reads, more information here)
    - improve camera performance by tuning the powerhal during recording
    - bias tasks of rt, sf and ta groups to prefer high capacity cpus during app launches, interactions
    - improve app launches via powerhal
    - improve trusty driver performance which connects to fingerprintscanner-hal by using high perf wq during fp unlock
    - restrict maximum CPU-Freqs during screen off/ idle to 1.1GHZ for all clusters to save power
    - introduce unfair f2fs rwsems to prevent writer starvation and improve IO perf under heavy load
    - fuse: give wakeup hints to scheduler to speed up compress/decompress in internal storage (details)
    - enable RCU_BOOST (details here), also fix RCU_BOOST behaviour
    - F2FS-Stable updated
    - TCP backports from mainline
    - BFQ updates backported from mainline
    - Scheduler updates from linux-main
    - use improved energy model for exynos cpu cooling/thermal control
    - allow GPU to scale down to 150mhz, but boost to higher value in case of interaction via powerhal
    - affine IRQS to CPU 7 during camera usage for improved performance as it tends to overload the little cores
    - use bbr as default TCP congestion algorithm (fasted algo according to this excellent research from @kdrag0n found here )
    - Enable support for TTL spoofing
    - Include LRNG, see here and here for more info, bump to v45 with 3.0.0
    - important patches from kernel/common for 5.10 (here are more details)
    - CleanSlate Features from @tbalden, big applause here! (s2s, notification booster, battery saver, flashlight notifications. Please note: cleanslate features that work otherwise with rooted devices like kadaway (adblocking) are not implemented on this kernel since I´m running rooted)
    - dirty pipe exploit fixed
    - supports direct usb access for hi-res playback over USB-C DACs
    - flashing the kernel will preserve root

    Various Optimizations:
    - update several drivers to use power efficient workingqueues (for example wlan driver)
    - kernfs: use buffer from the stack space
    - printk: use buffer from the stack space
    - kthread: use buffer from the stack space
    - bpf: avoid dynamic memory allocation for small value buffers
    - binder: Reserve caches for small, high-frequency memory allocations
    - kernfs: use kmem_cache pool for struct kernfs_open_node/file
    - cgroup: use kmem_cache pool for struct cgrp_cset_link
    - f2fs: reduce timeout for uncongestion
    - f2fs: Demote GC thread to idle scheduler class
    - f2fs: set ioprio of GC kthread to idle
    - mm: vmstat: use power efficient workingqueues
    Wakelock Blocker:
    - advanced wakelock blocker with the ability to block any wakelocks (dangerous, use with caution)
    - please read [URL="https://arstechnica.com/gadgets/2018/08/p-is-for-power-how-google-tests-tracks-and-improves-android-battery-life/"]this for further info

    AK3 Helper Module:
    - restrict little cluster to 1,19ghz mid cluster to 1,19ghz and big cluster to 1,1ghz during screen off, to reduce battery usage for example during music playback
    - only use little cores during screen off/device suspend
    - tie pelt multiplier into the powerhal (more info here)
    - prevent frequency spikes caused by small transient tasks during idle operation (more info here)
    - boost scheduler using the pelt multiplier during fingerprint unlock operation
    - setup and control PMU limiter via powerhal (more info here)

    DOWNLOAD:
    Download is always located in this folder:

    Changelog:
    Android 12.0.0

    1.0.0 Initial Release
    1.0.2 https://forum.xda-developers.com/t/...r-pixel-6-pro-aka-raven.4358435/post-85910621
    1.0.5 https://forum.xda-developers.com/t/...r-pixel-6-pro-aka-raven.4358435/post-85924419
    1.3.0 https://forum.xda-developers.com/t/...pixel-6-pro-aka-raviole.4358435/post-85976139
    1.4.0 https://forum.xda-developers.com/t/...pixel-6-pro-aka-raviole.4358435/post-86109665
    1.5.0 https://forum.xda-developers.com/t/...pixel-6-pro-aka-raviole.4358435/post-86259863
    1.7.0 https://forum.xda-developers.com/t/...pixel-6-pro-aka-raviole.4358435/post-86390563
    1.8.4 https://forum.xda-developers.com/t/...pixel-6-pro-aka-raviole.4358435/post-86541727

    Android 12.1.0 Stable (March feature drop and more recent)
    2.0.0 https://forum.xda-developers.com/t/...pixel-6-pro-aka-raviole.4358435/post-86617873
    2.0.1 https://forum.xda-developers.com/t/...pixel-6-pro-aka-raviole.4358435/post-86637233
    2.1.0 https://forum.xda-developers.com/t/...pixel-6-pro-aka-raviole.4358435/post-86695911
    2.3.0 https://forum.xda-developers.com/t/...pixel-6-pro-aka-raviole.4358435/post-86821331
    2.4.0 https://forum.xda-developers.com/t/...pixel-6-pro-aka-raviole.4358435/post-86834981

    Android 12.1.0 Stable (June feature drop and more recent)
    3.0.0 https://forum.xda-developers.com/t/...pixel-6-pro-aka-raviole.4358435/post-86992705
    3.0.1 https://forum.xda-developers.com/t/...pixel-6-pro-aka-raviole.4358435/post-86996237



    Android 12L QPR Beta - Deprecated

    Requirements

    - unlocked Bootloader
    - USB-Debugging in developer options enabled
    - latest adb and fastboot binaries
    - working adb and fastboot environment so you can flash back to stock in case something goes wrong
    - working magisk environment (a device rooted with latest magisk stable in case you want to be absolutely safe)


    How to flash the Kernel:
    1a. Make sure you tick all the requirements above
    1. Download the correct kernel.zip depending on your device (Pixel 6 = oriole || Pixel 6 Pro = raven)
    2. Flash the correct kernel.zip via EXKM, FKM or kernel flasher. Root will be preserved. The AK3 magisk helper module will be automatically installed during flashing the kernel.zip and be present on next reboot.
    Do not remove or disable the AK3 Magisk Helper Module otherwise the device will bootloop.
    3. Reboot and profit.


    Manual installation is no longer supported starting with release 3.0.0, as there´s a free open-source option to flash kernel.zips now.
    Instead use the free kernel flasher, which can be found here.

    Manual installation without relying on paid apps like fkm/exkm:
    Please have a look at the linked post.



    Donations:
    Donations are not mandatory but very welcome if you want to support development or just buy me a coffee/tea/beer :)
    If you like my work: http://paypal.me/freak07

    Credits:
    @osm0sis for all his work on AK3.
    @tbalden for being the best HTC, Pixel, OnePlus and Asus wingman!
    @capntrips for all his work on the pixel 6!
    @LeeDroid and @mwilky for their awesome roms and work I used on multiple devices!
    @Captain_Throwback for all the mentoring and guidance!
    @Eliminater74 for bringing me into the game and the Inspiration
    @nathanchance for his upstream guidance and assistance
    @RenderBroken for helping me out
    @flar2 for all his work
    @joshuous for all the help he provided to me in the past!
    @arter97 for giving me advice
    @kdrag0n for his help and advices!
    @topjohnwu for magisk and his entire work!


    Source Code: https://github.com/freak07/Kirisakura_Raviole
    37
    Update to 1.8.4

    Hey guys and girls,


    So here´s the next update. It´s kind of an off schedule update, as I planned to update the kernel with the next security update/feature drop.

    But in the light of recent events regarding the new exploit called "Dirty Pipe" (more info here), which is similar to the "Dirty Cow" exploit from a while ago, but easier to exploit this time, I decided to release an update ahead of schedule.

    This exploit was fixed in linux-stable 5.10.102, as opposed to a single commit in AKC (android kernel common, commit here). This shows once more why merging linux-stable is beneficial as explained in detail in the OP.

    Since one of the key aspects of this kernel is security and staying on par with upstream (which often fixes exploits way ahead of android security bulletin updates, even before an exploit is even known or fixed via a patch on the security bulletin) I decided to release this update as quickly as possible, so this exploit is fixed on devices running this kernel.

    Several other notable improvements and changes in this release:
    Bring in scheduler updates from Android 13 Developer Preview, which aim at improving task placement. (adjust powerhal accordingly)
    BFQ IO-Sched is now on par with linux-mainline.
    Several fixes to mm subsystem, f2fs and others.

    Several other improvements are included as well. More details in the changelog.
    Download is below.
    Updated instructions in the OP!


    Changelog:
    - linux-stable 5.10.103
    - contains fix for the dirty pipe exploit
    - built with clang 14.0.2 prebuilt by google
    - improvments from kernel/common
    - fix memory leaks
    - security related patches
    - mm improvments
    - f2fs fixes
    - scheduler fixes
    - for details please check github
    - built with improvements from A13 Dev Preview to display driver
    - other changes please look at my github


    Download:


    Instructions can be found in the OP! Please follow the instructions to avoid any issues.
    If you´re coming from another kernel restore stock boot.img, dtbo.img, vendor_boot.img and vendor_dlkm.img before flashing. Thank you.
    37
    Update to 1.7.0

    Hey guys and girls,


    So here´s the next update. It includes the february security update. Most of the changes brought by the February kernel source drop, were already included in this kernel by merging kernel/common and linux-stable.


    Several other notable improvements and changes in this release:
    Improve f2fs performance by merging a patchset to prevent writer starvation for the checkpoint thread. This was discussed this month in the f2fs mailing list and is already merged to the kernel/common tree. It´ll improve performance under heavy I/O utilization.
    You can find more information following the discussion here.
    Necessary backports were brought to the kernel and the platform specific f2fs-implementation was also adjusted.
    Latest f2fs-stable was also merged to the kernel.

    Update the patchset to prevent frequency spikes caused by small tasks as well. Tie those new changes into the powerhal. (That means users not flashing the kernel.zip, but instead use the manual installation method, which are only a handful from the download count, need to flash the updated magisk helper module. Users that flash the kernel.zip via FKM/EXKM have to just flash and forget)

    Several other improvements are included as well. More details in the changelog.
    Download is below.
    Updated instructions in the OP!


    Changelog:
    - February Security update merged
    - linux-stable 5.10.96
    - include latest f2fs-stable
    - improvments from kernel/common
    - fix memory leaks
    - security related patches
    - mm improvments
    - for details please check github
    - introduce unfair f2fs rwsems to prevent writer starvation and improve IO perf
    - update patchset to prevent freq spikes caused by small transient tasks (also tie this into powerhal)
    - give pelt multiplier power hint for scheduler performance boost during fingerprint unlock
    - fuse: give wakeup hints to scheduler to speed up compress/decompress in internal storage (details)
    - enable RCU_BOOST (details here), also fix RCU_BOOST behaviour
    - update LRNG implementation (thanks to arter97 )
    - improvements/fixes for CleanSlate features
    - other changes please look at my github


    Download:


    Instructions can be found in the OP! Please follow the instructions to avoid any issues.
    If you´re coming from another kernel restore stock boot.img, dtbo.img, vendor_boot.img and vendor_dlkm.img before flashing. Thank you.
    36
    Update to 2.1.0

    Hey guys and girls,


    Alright here´s the next update. And it´s again a really big update! :)
    A few weeks ago google pushed a backport of Multi-Gen LRU for the 5.15 kernel to their aosp/kernel common branches. I went ahead and backported that to our 5.10 tree alongside other mm-improvements from linux-mainline. By now google pushed their own backport for 5.10, but I decided to go with my original implementation as it contains a lot more improvements alongside the main Multi-Gen LRU backport and ran stable for well over 3 weeks.

    Powerhal was adjusted quite significantly too. CPU-freqs are restricted to 1.1GHZ max during screen off/device idle operations to save more power. App launches and camera operation are improved as well in the powerhal. General usage benefits from those changes too.

    Latest linux-stable, f2fs-stable and kernel/common were merged as well.

    Users that decide to not use the CleanSlate features and don´t install the apps won´t see the kernel parsing for the config files extensively.
    Vibration Booster from CleanSlate was improved as well to kind of counter the weaker haptic feedback since the March update. Please check the linked thread from the changelog. Huge thanks to @tbalden for this. If you want to give a little bit back consider purchasing the apps via playstore or maybe a small donation. :)



    I´ll keep the warning as to preferably using magisk stable to avoid potential issues as well here in this post.
    Please note that 24305 works fine for me though on non beta, stable April firmware!
    Important:
    Make sure you´re being rooted with magisk 24300 stable before flashing the kernel if you´re unsure. Any magisk version above 24303 might potentially lead to a reboot back to bootloader since android 12.1.0 and A12L QPR3 Beta. At the moment this only affects canary, but I put the warning just in case this will not get resolved in upstream magisk in time until the next stable drops. I saw a post that some modules also have problems with latest canary, so there´s a lot going on at magisk´s side at the moment.
    A post containing a short write-up how to "downgrade" magisk can be found following this link.



    Changelog:

    - Update for April Source
    - Linux-stable merged to 5.10.109
    - f2fs-stable merged
    - fixes and improvements from kernel/common including several subsystems
    - multi-gen LRU ( more info here, here as well and here)
    - general LRU improvements from Linux-Mainline
    - improve camera performance by tuning the powerhal during recording
    - improve app launches via powerhal
    - restrict maximum CPU-Freqs during screen off/ idle to 1.1GHZ for all clusters to save power
    - remove cleanslate config files getting parsed excessively even if user did not install the CleanSlate apps
    - improve vibration boosting feature in CleanSlate config app to allow stronger vibration again(please have a look at this post )
    - other fixes for CleanSlate features such as sweep to sleep
    - updated anykernel 3 zip, thanks to @osm0sis
    - probably a lot more I forgot as time is short for me.


    Download:


    Instructions can be found in the OP! Please follow the instructions to avoid any issues and read this post carefully. Don´t use magisk canary 24303 or more recent to avoid potential issues!
    If you´re coming from another kernel restore stock boot.img, dtbo.img, vendor_boot.img and vendor_dlkm.img before flashing. Thank you.

    I wish everybody a great day/evening!
    Have fun, enjoy the kernel and your phone.


    If you like my work please consider a donation.
    Donations are not mandatory but very welcome.
    If you like my work and want to buy me a coffee/green tea: http://paypal.me/freak07
    35
    Update to 2.4.0

    Hey guys and girls,


    Alright here´s the next update and it´s fine to flash on May firmware. As I suspected we already had all the changes for May by merging upstream.
    I´ll include the changelog from 2.3.0 as well in this release post, since I think a lot of people flash the kernel on a monthly basis when the security updates drop. So this post pictures the changes going from 2.1.0 to 2.3.0! As I said 2.3.0 was kind of a final rehearsal to make sure everything is good for the May update.
    I´ll put a remark behind changes going from 2.3.0 to 2.4.0.
    This release is made for stable Android 12.1.0 May firmware. Not QPR Beta or A13 Beta!
    Once I find enough time or QPR beta gets updated, I might update the QPR beta release. No plans to support A13 beta.

    I also finished up the tables/graphs in regards to different binnings with the respective voltages on different tensor chips thanks to the dmesgs you all provided. I really want to put out a big thanks here to everyone for taking the time and participating. It was really great to see this kind of response.
    I´ll provide them in a post in this thread soon.
    So with that in mind we´ll get to the next paragraph were I could put those tables to good use.

    A few changes from A13 Beta are merged to the kernel so we can enjoy the improvements on A12 ahead of time. Most of them aim to improve the scheduler and task placement.

    However the recently dropped A13 Beta source contains a commit that can restrict max-cpufreqs based on PMU (Power monitor unit) reading. I setup this mechanism (lets call it "PMU Limiter") to mildly cut back max-freqs when they aren´t needed. It works quite well so far, with no performance impacts during scenarios where max cpufreq is beneficial. (e.g. app launching, camera launching, interaction etcetc)
    That means if a certain threshold is not crossed the max-freqs will be restricted to 1,4GHZ/1,6GHZ/2,4GHZ (for little/mid/big cores). As soon as the PMU detects enough pressure, those limits will be lifted.
    The frequency limits are based on tracing during various scenarios, benchmarking and also factor in the voltage table I was able to create. For example: 2.4GHZ for the big cores is the last freq step where a steady linear increase in voltage can be seen. Freq steps higher than 2,4ghz have a steeper slope.
    Keep in mind CPU-Freqs shouldn´t be touched in EXKM/FKM or other kernel managers. They are controlled by various mechanisms now (thermal hal, powerhal, pmu limiter etc) and values will get overwritten based on input.
    That means if you open the CPU section in a kernel manager, the maxfreqs will not be the actual maxfreqs that are possible. or the minfreqs might be raised. That´s normal and there´s nothing wrong if that´s the case.

    Additionally to the previous changes tasks of rt, sf and ta groups are now biased to start on high capacity CPUs during app launches, interactions etc.
    As usual, depending on your usage you may or may not notice a difference during these scenarios. :)

    While tracing I noticed kswapd often takes 100% cpu share when reclamation is happening. Since we use an 8 core cpu, an additional kswapd thread is being spawned during boot, which increases throughput for kswapd in these scenarios. Reasoning behind this can be found here.

    The trusty driver which connects to the fingerprintreader hal uses now a high prio workqueue when the phone is unlocked via fingerprint scanner. This means better performance, especially under stress. Keep in mind this is a kernel level change, it won´t magically improve fingerprint reader times manifold.

    DAMON and DAMON-Reclaim were removed from 2.3.0 going to 2.4.0. I tested the feature privately and it unfortunately collides with googles EH zram implementation causing the phone to crash at the moment. Tried to debug this issue, but no luck for the May release here.
    If you previously enabled the feature without adjusting the parameters properly and your phone didn´t crash, DAMON-Reclaim just didn´t do anything.

    2.4.0 also has an updated anykernel3.zip, which includes all the latest anykernel3 changes.
    Thanks to @capntrips we now have full support to resize vendor_dlkm partition which is part of the super partition. That means we finally can flash larger than stock vendor_dlkm partitions via anykernel3.zips and resize the partition properly instead of just dd´ing to it.
    A huge thanks to @capntrips for working on this and to @osm0sis for maintaining anykernel3.


    Disclaimer:
    I´ll keep the warning as to preferably using magisk stable to avoid potential issues as well here in this post.
    Please note that 24306 works fine for me though on non beta, stable May firmware!
    Important:
    Make sure you´re being rooted with magisk 24300 stable before flashing the kernel if you´re unsure. Any magisk version above 24303 might potentially lead to a reboot back to bootloader since android 12.1.0 and A12L QPR3 Beta. At the moment this only affects canary, but I put the warning just in case this will not get resolved in upstream magisk in time until the next stable drops. I saw a post that some modules also have problems with latest canary, so there´s a lot going on at magisk´s side at the moment.
    A post containing a short write-up how to "downgrade" magisk can be found following this link.

    If you´re one of the unfortunate ones that suffer from the device is corrupt bug on pixel 6 series please take a look at the FAQ at the beginning of this thread it contains a solution. The issue is probably caused by a bug that affects pixel 6 devices and has nothing to do with magisk or a kernel, it just happens to get triggered when using any of those.



    Changelog:

    - Linux-stable merged to 5.10.113
    - Use prebuilt Google Clang 14.0.5 for compilation
    - Utilize an additional kswapd thread to increase throughput for memory reclaim
    - remove DAMON and DAMON-Reclaim from kernel build (2.4.0)
    - improve trusty driver performance which connects to fingerprintscanner-hal by using high prio wq during fp unlock (2.4.0)
    - mm improvements from kernel/common (2.4.0)
    - improvements from kernel-common a13 to page_pinner
    - mainline backports for BFQ scheduler
    - rework Multi-Gen LRU implementation
    - scheduler improvements for RT (realtime) tasks
    - other scheduler improvements
    - include scheduler improvements from A13 Beta regarding better task placement
    - introduce and setup PMU limiter (prevents CPU from spiking to max when it isn´t needed, based on PMU reads)
    - bias tasks of rt, sf and ta groups to prefer high capacity cpus during app launches, interactions, camera launches, etc
    - updated anykernel3.zip (thanks to @osm0sis) -> adds full support for resizing vendor_dlkm ( huge thanks to @capntrips )



    Download:


    Instructions can be found in the OP! Please follow the instructions to avoid any issues and read this post carefully. Don´t use magisk canary 24303 or more recent to avoid potential issues!
    If you´re coming from another kernel restore stock boot.img, dtbo.img, vendor_boot.img and vendor_dlkm.img before flashing. Thank you.

    I wish everybody a great day/evening!
    Have fun, enjoy the kernel and your phone.


    If you like my work please consider a donation.
    Donations are not mandatory but very welcome.
    If you like my work and want to buy me a coffee/green tea: http://paypal.me/freak07