Requiem-Kernel
Requiem-Nightly-27012023-LEMONADE.zip
tested and won't work on F11 fw (OOS13)
i'm not in mood to support OOS13, i will do this when majority of the community has completely shifted to 13
Forwarded from Komaru Gang (Cybersecbyte ALT)
Finally we have made our own bot from scratch for making demotivators🥳 🥳 🤩
Go try and use it at 👉🏻 @demotivatorgif_bot👨💻
😎 Suggestions for improvements will be appreciated at @komarugangchat 😇
Go try and use it at 👉🏻 @demotivatorgif_bot
Please open Telegram to view this post
VIEW IN TELEGRAM
On 5.10, building standalone kernels is a big mess in and of itself.
To build the qcom kernels on 5.10 and above there's kernel_platform, a sort of split build system where the kernel is built first in a kind of prebuilt kernel format, and then you build the ROM separately.
Well, what about the standalone kernels?
There's 3 ways to mostly do this as far as I know.
First method is a slight hacky way devised by arter97, the lazy initcall
https://github.com/arter97/hdk-kernel/commit/1ad367f0f821a70e5a766e267515aa6be022a44e
The second way is just bypassing those modules by not inlining them in the kernel, as such they are initialised as is from vendor_dlkm.
However here comes the biggest caveat: kmi
https://source.android.com/docs/core/architecture/kernel/stable-kmi
For the kernel to be able to load precompiled kernel modules (ko), the kernel must be compiled with Google clang 12.0.5. This means we cannot compile the kernel with the latest clang.(this is mostly just applicable for stock kernel and if ur gonna target stock rom)
The third way is by unpacking the vendor_dlkm, replacing the module inside, repacking it then shipping the img alongside the kernel Image in ak3.
To build the qcom kernels on 5.10 and above there's kernel_platform, a sort of split build system where the kernel is built first in a kind of prebuilt kernel format, and then you build the ROM separately.
Well, what about the standalone kernels?
There's 3 ways to mostly do this as far as I know.
First method is a slight hacky way devised by arter97, the lazy initcall
https://github.com/arter97/hdk-kernel/commit/1ad367f0f821a70e5a766e267515aa6be022a44e
The second way is just bypassing those modules by not inlining them in the kernel, as such they are initialised as is from vendor_dlkm.
However here comes the biggest caveat: kmi
https://source.android.com/docs/core/architecture/kernel/stable-kmi
For the kernel to be able to load precompiled kernel modules (ko), the kernel must be compiled with Google clang 12.0.5. This means we cannot compile the kernel with the latest clang.(this is mostly just applicable for stock kernel and if ur gonna target stock rom)
The third way is by unpacking the vendor_dlkm, replacing the module inside, repacking it then shipping the img alongside the kernel Image in ak3.
Requiem-Nightly-20082023-ZEUS.zip
37.9 MB
Initial build for zeus (Ximmi 12 Pro)
Note:
- kernel will flash vendor_dlkm partition image during installation. If you want to replace it with another kernel or go back to stock you may need to revert to the original vendor_dlkm partition, so back up ur partitions.
- this build doesn't work for newer ROM builds like the latest los
Note:
- kernel will flash vendor_dlkm partition image during installation. If you want to replace it with another kernel or go back to stock you may need to revert to the original vendor_dlkm partition, so back up ur partitions.
- this build doesn't work for newer ROM builds like the latest los
Requiem-Nightly-29082023-ZEUS.zip
36.3 MB
this should fix alot of stuff
Requiem-Nightly-03092023-ZEUS.zip
36.8 MB
Works for newer los
Those on roms older can test and send logs
Those on roms older can test and send logs