Development [Kernel][04.08.2023][Android 13] Kirisakura 1.0.1 for Asus ROG Phone 5 aka "Anakin"

[Freak07]

Update to 1.2.0

Hey guys and girls,

I hope everyone is having a good day or starting into one. Here´s the next update.
The kernel is updated for the latest firmware:
18.0840.2109.176. Make sure to update to the latest firmware before flashing the kernel to have no compatibility issues.
Some device specific changes, which should fix a touchscreen issue was in the source code.
All other security related updates on the kernel side, were already included by merging CAF-Upstream previously.
Caf-Upstream was also merged, which includes several improvements from QCOM to different subsystems like the scheduler, gpu driver etc. Details on github as usual.

The link to the WW firmware can be found here:

https://dlcdnets.asus.com/pub/ASUS/..._I005_1-ASUS-18.0840.2109.176-1.1.96-user.zip

More changes in the Changelog below:


Changelog:
- Import ASUS_I005_1-18.0840.2109.176 source code
- Linux-Stable Upstream to 5.4.150
- Merge CAF (QCOM) upstream up to tag LA.UM.9.14.r1-18300-LAHAINA.0
- Scheduler improvements from QCOM and Google
- Enable NAP power saving state for GPU
- updates from kernel common for several subsystems
- for details please check github


Important: If flashing the kernel via TWRP, flash the DLKM magisk module found in the download folder that matches the kernel version.

Download:

https://www.androidfilehost.com/?w=files&flid=328305

Instructions can be found in the OP!
But look at this post too

Have fun, enjoy the kernel and your phone.

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

 

[mohammed510]

Thanks @Freak07. Really appreciate your work. I can also confirm that flashing the new ROM update and the kernel update by TWRP works fine. Just tick the option to reflash TWRP after flashing ROM. Then reboot recovery then flash Kernel -> Magisk alpha -> kernel again then reboot system

 

[Freak07]

Thanks @Freak07. Really appreciate your work. I can also confirm that flashing the new ROM update and the kernel update by TWRP works fine. Just tick the option to reflash TWRP after flashing ROM. Then reboot recovery then flash Kernel -> Magisk alpha -> kernel again then reboot system

It works, but the magisk helper module is still broken I suppose if flashing from twrp. Need to update the flashable module for that and adjust the instructions.

Thanks for the reminder

 

[nexusnerdgeek]

Thank you very much for supplying this community your custom kernel build.

Please pardon my newbie question here.

My phone's running ASUS firmware WW_18.0840.2107.151 & Kirisakura kernel 1.1.0 (which was flashed using EXKM).

Now to successfully install Kirisakura kernel 1.2.0:
1. I need to apply UL-ASUS_I005_1-ASUS-18.0840.2109.176-1.1.96-user.zip (strange that it has Zenfone label in the ASUS URL provided)
2. Skip reboot
3. Apply Magisk to the inactive slot
4. Reboot
5. Using EXKM, apply Kirisukura kernel 1.2.0
6. Reboot

I'm not missing any steps there, right?

Thanks for your help.

 

[JazonX]

Thank you very much for supplying this community your custom kernel build.

Please pardon my newbie question here.

My phone's running ASUS firmware WW_18.0840.2107.151 & Kirisakura kernel 1.1.0 (which was flashed using EXKM).

Now to successfully install Kirisakura kernel 1.2.0:
1. I need to apply UL-ASUS_I005_1-ASUS-18.0840.2109.176-1.1.96-user.zip (strange that it has Zenfone label in the ASUS URL provided)
2. Skip reboot
3. Apply Magisk to the inactive slot
4. Reboot
5. Using EXKM, apply Kirisukura kernel 1.2.0
6. Reboot

I'm not missing any steps there, right?

Thanks for your help.

You got it right, Firmware update, then dont reboot,
Open magisk - install to inacive slot.. Then it will request for a reboot.

Afterwards, Flash the kernel via EXKM or TWRP.

@Freak07 - Do we still need to use the DLKM module if flashing over TWRP ?
I already have it installed anyway..

 

[Freak07]

Thanks @Freak07. Really appreciate your work. I can also confirm that flashing the new ROM update and the kernel update by TWRP works fine. Just tick the option to reflash TWRP after flashing ROM. Then reboot recovery then flash Kernel -> Magisk alpha -> kernel again then reboot system

@Freak07 - Do we still need to use the DLKM module if flashing over TWRP ?
I already have it installed anyway..

Yes if flashing via TWRP the DLKM magisk module still needs to be installed. It seems to maybe not be a problem only present on this specific device, but due to virtual A/B and the way the ak3 zip, gets the strings to create the helper module while being flashed in twrp.

For now if flashing via TWRP, flash kernel inside TWRP then DLKM module that matches the kernel. so kernel 1.2.0 and dlkm module 1.2.0.

I uploaded the DLKM module to the download link the in the release post.

I´ll update the instructions until this is fixed.

 

[Quiexo]

Does your kernel help fix stutter in games? Your first post mentions "tune scheduler for improved jitter and less jank frames"

 

[Madbullben]

Hey, not sure what the problem is, but rarely, once maybe twice a week, my phone stops responding and restarts with this screen saying waiting for flashing full ram dump, it did this on v1.1 as well. Any idea?

 

[Freak07]

Hey, not sure what the problem is, but rarely, once maybe twice a week, my phone stops responding and restarts with this screen saying waiting for flashing full ram dump, it did this on v1.1 as well. Any idea?

The problem could be anything really... a ROM issue, an issue from a magisk module or also a kernel panic that I introduced.

I haven't had a single random reboot or ramdump screen with the releases on xda.
Now is the time I would usually ask you for a kernel log. Unfortunately I found no way yet to get ramoops working on the ROG 5. That means there's no way to recover a kernel log after the device crashed.
There's ASDF which Asus uses but usually it produces nothing useful for me.
So if you find something in asdf/ or asdf/ASDF/ that matches the time of the crash please upload it here.

The only thing that might help is if you'd knew how to exactly reproduce the bug and try to take logs exactly in the moment the device crashes and boots to ramdump.

So unfortunately there's not much I can do...

If flashed through TWRP did you flash the additional magisk module?
Do you use any other magisk modules, tweaks or mods?
Is there something you always do when this happens?

 

[twistedumbrella]

Unfortunately I found no way yet to get ramoops working on the ROG 5. That means there's no way to recover a kernel log after the device crashed.

https://xdaforums.com/t/asus-proprietary-logs.4303809/

Not ideal, but better than nothing at all (kind of).

 

[Freak07]

Does your kernel help fix stutter in games? Your first post mentions "tune scheduler for improved jitter and less jank frames"

The best thing is to try for yourself. Backup the stuff mentioned in the OP. It's very easy to revert.

I tried ICEY with my kernel and couldn't see the sign stutter that you mentioned in your thread:

https://xdaforums.com/t/frame-skips-in-games-at-60fps.4342359/

Might be something else though who knows.

 

[Freak07]

https://xdaforums.com/t/asus-proprietary-logs.4303809/

Not ideal, but better than nothing at all (kind of).

Yeah I know about ASDF. Unfortunately it's more miss (almost exclusively miss for me, seems it's similar for you ) than hit for me.
But thanks for reminding me, I'll edit the post above. Who knows maybe we get something and if we get something it's not corrupted

 

[Devaanp]

Finally

 

[twistedumbrella]

Yeah I know about ASDF. Unfortunately it's more miss (almost exclusively miss for me, seems it's similar for you ) than hit for me.
But thanks for reminding me, I'll edit the post above. Who knows maybe we get something and if we get something it's not corrupted

I believe when it happened for me mine was in the middle of benchmarking 'import-instr-limit' (You call it LTO inlining). It hasn't happened again since keeping that below 40, but that may also be pure coincidence. I was never able to trace it back to a specific cause before it stopped.

 

[Freak07]

I believe when it happened for me was in the middle of benchmarking 'import-instr-limit' (You call it LTO inlining). It hasn't happened again since keeping that below 40, but that may also be pure coincidence. I was never able to trace it back to a specific cause before it stopped.

Never had a crash to ramdump screen or other crash on the releases here on xda and on the next kernel(s) that will be released shortly.

So I doubt it's that.
Without a way to reproduce those crashes and a way to reliably get logs it's basically impossible to say what the issue is or debug a kernel issue. It could be just a combination of magisk modules or something else entirely.

 

[JazonX]

...... on the next kernel(s) that will be released shortly.

Cant wait !!

Cheers !

 

[twistedumbrella]

Never had a crash to ramdump screen or other crash on the releases here on xda and on the next kernel(s) that will be released shortly.

So I doubt it's that.
Without a way to reproduce those crashes and a way to reliably get logs it's basically impossible to say what the issue is or debug a kernel issue. It could be just a combination of magisk modules or something else entirely.

A little too coincidental to be magisk modules. More likely it was something in the .176 changes. The timing lines up almost perfectly.

 

[Freak07]

A little too coincidental to be magisk modules. More likely it was something in the .176 changes. The timing lines up almost perfectly.

Here a user reported ramdump happens rarely once a week, also on v 1.1 which was prior to .176 release.

For all we know there could be multiple reasons for a ramdump to be happening.
On previous Asus devices the phones never rebooted to ramdump but instead just crashed/looped. So I think it's quite new to some parts of the community and occurrences might not be reported.

Unfortunately it could be caused by anything. There's no lead or clue for me to follow on.
I had to debug several kernel panics during the bringup of the kernel, that crashed the device to ramoops caused by caf-upstream or Linux-stable. Might just be one of those again that never happened to me.
Might be something in the .176 firmware, some special usecase, a certain router firmware combo, not necessarily a kernel issue, a combination of apps, etc....
Without a way to reproduce I can't do anything.
Tried to get ramoops working a few times now to no avail.
Not a single crash to ramdump for me the last month since the kernel was released either.

 

[twistedumbrella]

Here a user reported ramdump happens rarely once a week, also on v 1.1 which was prior to .176 release.

For all we know there could be multiple reasons for a ramdump to be happening.
On previous Asus devices the phones never rebooted to ramdump but instead just crashed/looped. So I think it's quite new to some parts of the community and occurrences might not be reported.

Unfortunately it could be caused by anything. There's no lead or clue for me to follow on.
I had to debug several kernel panics during the bringup of the kernel, that crashed the device to ramoops caused by caf-upstream or Linux-stable. Might just be one of those again that never happened to me.
Might be something in the .176 firmware, some special usecase, a certain router firmware combo, not necessarily a kernel issue, a combination of apps, etc....
Without a way to reproduce I can't do anything.
Tried to get ramoops working a few times now to no avail.
Not a single crash to ramdump for me the last month since the kernel was released either.

unguard (and restore) printk_buffer_rebase and write_to_asus_log_buffer()

It won't fix the root cause, but should turn the ramdump back into a reboot and possibly even fill in the logs.

 

[C.T.Richter]

What are the chances this kernel would work on a ROG Phone 5S?