[EOL] [KERNEL] [AOSP/Samsung/Ports] [ArchiToolchain 5.2] [01/10/15] ArchiKernel V2.1

Search This thread

d1rekt0r

Senior Member
Aug 14, 2012
1,062
262
Using 1.5.1 almost entire day now on AOSPA , very very good performance and battery life :fingers-crossed:
 

katolink

Senior Member
Aug 12, 2011
254
85
Bucharest
Meanwhile what version are you on? i guess its 1.5 as stated on your signature. Would you mind to share your config?
My bad, forgot to change signature. [emoji52]

CPU oc'ed 1600, touch boost 800, touch-to-wake, zzmoove battery yank, deadline, 128 int/256 ext cache, logging disabled. All other settings standard preloaded with AK.

I noticed that with noop as governor battery life is even better, but the phone starts losing its smoothness. [emoji41]

Tapatalk'ed from my Galaxy S3-I9300 running ArchiDroid 1.7.18 powered by ArchiKernel 1.5.1
 

loris100

Senior Member
Oct 7, 2014
341
118
Very good kernel like all the work that comes from @JustArchi, super smooth and very very friendly with battery.I don't understand what is special with this kernel that it gives me much better battery than Boeffla even with same configuration, maybe Archi can give me the answer [emoji4]

to me it doesnt look smoother then boeffla one, lower cpu OC capability...i tried any governor and finally found one which is smooth but kills the battery life...the other governors disable cores mostly but also lowers performance...

i think most of you cant tell the difference and dont help to improve things just make more confusion:eek:....this kernel is inferior to boeffla one, which is the best after i tried all kernels avaiable.
 
  • Like
Reactions: Code124Y

JustArchi

Inactive Recognized Developer
Mar 7, 2013
8,739
38,807
Warsaw
to me it doesnt look smoother then boeffla one, lower cpu OC capability...i tried any governor and finally found one which is smooth but kills the battery life...the other governors disable cores mostly but also lowers performance...

i think most of you cant tell the difference and dont help to improve things just make more confusion:eek:....this kernel is inferior to boeffla one, which is the best after i tried all kernels avaiable.

I don't want to start a war, but you're wrong mate - there's no best kernel, it all depends on the user what he expects from one.

ArchiKernel has totally different objective than boeffla kernel. Here we experiment with everything we can, in order to achieve the best possible combination. I applied a ton of deep optimizations, which increased size of the whole binary by 2 Megabytes, so it's physically impossible that it's a placebo and doesn't change anything. Kernel is a kernel, it doesn't do complicated work and flashing even the ultimately optimized masterpiece like this one may, or may not, make a difference in terms of speed. However, considering the fact that kernel is running whole the time, this is one of the most mayor things to optimize, both for performance and battery life gain.

This is one of the most cutting-edge and stable kernels currently available for SGS3. People that search for more cutting-edge features can try arter's kernel, people that look for more stable kernel, can take a look at Andi's masterpiece called Boeffla kernel. ArchiKernel is somewhere between those two. The objective is to start from stock base, apply all cool third-party features (mostly known from boeffla kernel), then optimize everything to push the whole project to the border between awesomness, and unstability.

Everybody has his/her own opinion, and you can have your own top kernels, but calling this kernel inferior to other one is a bit disrespectful, especially because you're wrong, as this is one of the most optimized kernels available and definitely is more optimized than Boeffla one, because Andi prefers ultimate stability over cutting-edge optimizations such as Linaro toolchain. As I said, different objectives. If there were really no improvement, Linaro toolchain wouldn't cause any problems. And if it does, then definitely it acts differently, tries to optimize some things much more. Code generated by Linaro toolchain is completely different to Google's GCC, and this is just one thing that differs AK from Boeffla. In 1.5.1 I pushed this project even higher by enabling -Ofast optimizations, that may cause serious problems and only beta tests will tell me if it was the right, or wrong move. First signs say that it doesn't cause problems, and these are great news because -Ofast emits NEON code, which benefits CPU by utilizing FPU which is normally not generated due to breaking IEEE 754 standard.

If the selected floating-point hardware includes the NEON extension (e.g. -mfpu=‘neon’), note that floating-point operations are not generated by GCC's auto-vectorization pass unless -funsafe-math-optimizations is also specified. This is because NEON hardware does not fully implement the IEEE 754 standard for floating-point arithmetic (in particular denormal values are treated as zero), so the use of NEON instructions may lead to a loss of precision.

So, yeah, this is not a simple fork which may be compared to other kernel. This is totally different look at common things that we can improve. I'm not a big fan of customizing kernel by endusers, same as Yank555, we both think that developer knows better and kernel is a "flash & forget" rather than tweaking things some people have no idea about. In fact, STweaks support was added ONLY thanks to Moster2, which itself is a great thing as it's always nice to cooperate with other experienced developers. This is not my project, Moster2 contributions to AK are comparable to mine, he's a developer of this project same as I am, and I'm sure that he likes the idea behind AK as well.
 
Last edited:

JustArchi

Inactive Recognized Developer
Mar 7, 2013
8,739
38,807
Warsaw
@JustArchi dont feed the troll. You are one of the most talented devs around xda. It's your kernel, your time and you don't own anything to anybody. But i would like to f2fs support one day. hehehe

It's the only thing that keeping me for using AK.

Cheers!

F2FS requires upstreaming the kernel to particular point. Of course you can also backport the whole filesystem, but in the same time you risk stability, as backports may always make things worse :).

However, we'll see.
 

loris100

Senior Member
Oct 7, 2014
341
118
I don't want to start a war, but you're wrong mate - there's no best kernel, it all depends on the user what he expects from one.

ArchiKernel has totally different objective than boeffla kernel. Here we experiment with everything we can, in order to achieve the best possible combination. I applied a ton of deep optimizations, which increased size of the whole binary by 2 Megabytes, so it's physically impossible that it's a placebo and doesn't change anything. Kernel is a kernel, it doesn't do complicated work and flashing even the ultimately optimized masterpiece like this one may, or may not, make a difference in terms of speed. However, considering the fact that kernel is running whole the time, this is one of the most mayor things to optimize, both for performance and battery life gain.

This is one of the most cutting-edge and stable kernels currently available for SGS3. People that search for more cutting-edge features can try arter's kernel, people that look for more stable kernel, can take a look at Andi's masterpiece called Boeffla kernel. ArchiKernel is somewhere between those two. The objective is to start from stock base, apply all cool third-party features (mostly known from boeffla kernel), then optimize everything to push the whole project to the border between awesomness, and unstability.

Everybody has his/her own opinion, and you can have your own top kernels, but calling this kernel inferior to other one is a bit disrespectful, especially because you're wrong, as this is one of the most optimized kernels available and definitely is more optimized than Boeffla one, because Andi prefers ultimate stability over cutting-edge optimizations such as Linaro toolchain. As I said, different objectives. If there were really no improvement, Linaro toolchain wouldn't cause any problems. And if it does, then definitely it acts differently, tries to optimize some things much more. Code generated by Linaro toolchain is completely different to Google's GCC, and this is just one thing that differs AK from Boeffla. In 1.5.1 I pushed this project even higher by enabling -Ofast optimizations, that may cause serious problems and only beta tests will tell me if it was the right, or wrong move. First signs say that it doesn't cause problems, and these are great news because -Ofast emits NEON code, which benefits CPU by utilizing FPU which is normally not generated due to breaking IEEE 754 standard.



So, yeah, this is not a simple fork which may be compared to other kernel. This is totally different look at common things that we can improve. I'm not a big fan of customizing kernel by endusers, same as Yank555, we both think that developer knows better and kernel is a "flash & forget" rather than tweaking things some people have no idea about. In fact, STweaks support was added ONLY thanks to Moster2, which itself is a great thing as it's always nice to cooperate with other experienced developers. This is not my project, Moster2 contributions to AK are comparable to mine, he's a developer of this project same as I am, and I'm sure that he likes the idea behind AK as well.

i was responding to gabyif, he says your kernel is supersmooth and more battery efficient then the boeffla one....which is incorrect and basicallly a lie.

i tried your kernel and when choosing the power efficients governors all they do is disabling cores, thats is a good way to save battery but definitely you would notice that overall performance is not the same, it feels laggy choppy and not responsive at all.

when i choose performance governor its smooth yeah, but not smoother or faster then the boeffla one...also very power hungry.

also with boeffla you can OC your cpu at 1704mhz which will make it faster by say 1-20milliseconds maybe more, are they noticeable?..thats a good question...but definitely wont hurt.

im not talking about features or optimizations because they dont bother me...but the things i notice i feel like i have to tell them not spread bull**** like some guys do here...

i change roms and kernels any day so im not a fanboy of any kind if you were wondering.:fingers-crossed:
 

Sargos76

Senior Member
Oct 31, 2013
824
162
Sesimbra
Google Pixel 6 Pro
i was responding to gabyif, he says your kernel is supersmooth and more battery efficient then the boeffla one....which is incorrect and basicallly a lie.

i tried your kernel and when choosing the power efficients governors all they do is disabling cores, thats is a good way to save battery but definitely you would notice that overall performance is not the same, it feels laggy choppy and not responsive at all.

when i choose performance governor its smooth yeah, but not smoother or faster then the boeffla one...also very power hungry.

also with boeffla you can OC your cpu at 1704mhz which will make it faster by say 1-20milliseconds maybe more, are they noticeable?..thats a good question...but definitely wont hurt.

im not talking about features or optimizations because they dont bother me...but the things i notice i feel like i have to tell them not spread bull**** like some guys do here...

i change roms and kernels any day so im not a fanboy of any kind if you were wondering.:fingers-crossed:
hey loris100 talking and criticise is easy, if you can do better put your money where your mouth is and bring as a better kernel made by you, now this is real talking not bul....

SGS3 GT-I9300 / ArchiDroid 1.7.18
 

malachow

Senior Member
May 14, 2013
2,577
3,568
i was responding to gabyif, he says your kernel is supersmooth and more battery efficient then the boeffla one....which is incorrect and basicallly a lie.

i tried your kernel and when choosing the power efficients governors all they do is disabling cores, thats is a good way to save battery but definitely you would notice that overall performance is not the same, it feels laggy choppy and not responsive at all.

when i choose performance governor its smooth yeah, but not smoother or faster then the boeffla one...also very power hungry.

also with boeffla you can OC your cpu at 1704mhz which will make it faster by say 1-20milliseconds maybe more, are they noticeable?..thats a good question...but definitely wont hurt.

im not talking about features or optimizations because they dont bother me...but the things i notice i feel like i have to tell them not spread bull**** like some guys do here...

i change roms and kernels any day so im not a fanboy of any kind if you were wondering.:fingers-crossed:
Oh, wait! Stahp! You forgot completely about posting some ultra trust worthy antutu benchmark scores! Come on, we all, especially ahead with Archi, would love to see those neat comparison! Dat battle! This unpredictable plot!
..
:rolleyes:
 

abhibnl

Senior Member
Oct 13, 2011
3,594
1,464
to me it doesnt look smoother then boeffla one, lower cpu OC capability...i tried any governor and finally found one which is smooth but kills the battery life...the other governors disable cores mostly but also lowers performance...

i think most of you cant tell the difference and dont help to improve things just make more confusion:eek:....this kernel is inferior to boeffla one, which is the best after i tried all kernels avaiable.
Let me give you a free advice. Never ever post disrespectful comments in the thread of one of the most talented devs actively developing for s3, unless you want to unleash the wrath and anger of all the Archi/boeffla fans on you. The thing you just mentioned, it's the most diarespectful thing you could ever say in a dev's thread. Why are you comparing two different kernels having a totally different objective? Do you know that AK is the only kernel that offers R4P0 support with stock sources, which makes is fly even further. I'm not even using AK but i'm a fan of archi's work. Learn to respect. If you think boeffla is superior, keep that thought to yourself. I'm sure 99.99% of us will not be even interested what you think at all. Instead you could have said "boeffla is more stable for me, but this one is not working well, may be due to beta version or my settings." Next time, DO NOT POST DISRESPECTFUL COMMENT or believe me, many fans wills will burn you with theirs.

Sent from Galaxy S3 Powered by AD 1.x + Boeffla
 

EP21

Senior Member
Jul 22, 2010
440
106
Vilnius
Xiaomi Poco F1
loris100 if you think this kernel is inferior you do not understand what inferior means. One does not buy a McLaren for day to day driving, good fuel economy and mobility is superior to gas guzzling power.
 

Buckycasuals

Senior Member
Oct 1, 2013
702
294
Bolton
to me it doesnt look smoother then boeffla one, lower cpu OC capability...i tried any governor and finally found one which is smooth but kills the battery life...the other governors disable cores mostly but also lowers performance...

i think most of you cant tell the difference and dont help to improve things just make more confusion:eek:....this kernel is inferior to boeffla one, which is the best after i tried all kernels avaiable.

With regards to his XDA profile name LORIS100, i guess he is french. His first language is not English. Damn Google translator or otherwise :laugh:
What he is trying to say sounds disrespectful to the dev for the amount of time they spent in making a smooth and solid kernel.
 

Code124Y

Senior Member
Oct 19, 2010
1,167
251
georgetown
anyway, im not judging any side, but smooth to A dosnt mean its same to B, while maybe fast respone (a 0.3sec delay on opening random apps) to A is a delay but not to B(0.7sec delay on opening app), not everyone responsive are EQUAL... as what i know, even antutu also can not tell anything... i got both 21K score over sammy and AOSP, but the delay on sammy really high vs AOSP... so how u judge by any smooth?
judge it on ur phone...

Sent from my GT-I9300 using Tapatalk
 

cangcan

Senior Member
Nov 24, 2012
624
228
ASUS ROG Phone II
ASUS ROG Phone 5
1st..i am no developer..
2nd..im a flasholic..looking for the most battery saving rom/kernel till this day..and im still not satisfied with it..
3rd..ive been registered as xda member for a long time but just recently active on posting coz i wanna learn/ask from these honorable s3 devs..

my point is..i think eventho im am still indeed a noob..i always read the post and keep learning about s3 custom rom/kernel/apps and hit the search button first before questioning someone..im from malaysia..i think people around me and near me didnt even know xda existence, even 'root' word seems strange to them..and theres no need to even question archikernel/boeffla/arter97 kernel to them..

IMO..honestly ive been quietly looking at xda s3 android development thread for almost every second, looking for updates..and keep flashing and flashing..im really proud and thankful for developers such as archi, andip, arter, temasek, yank, and other imfamous developer for their support and development for our old S3 phone..and most importantly..their doing it for FREE, i wish i am born rich, so i can donate to them :p but honestly..we should respect their own work..and each of their work has their own pro and con..there is no perfect one..REALLY! but they all keep getting good and really good with their work..and its all up to us to choose or to use which one depends on our own mood or our own necessity..but please..

RESPECT THEIR WORK
they all are the best..i really wish that i studied programming or coding and contribute some too for the community..btw keep up the good work @JustArchi..and also to other developers too..you all know it better than us..:D

Sent from my GT-I9300 using XDA Free mobile app
 

Buckycasuals

Senior Member
Oct 1, 2013
702
294
Bolton
to me it doesnt look smoother then boeffla one, lower cpu OC capability...i tried any governor and finally found one which is smooth but kills the battery life...the other governors disable cores mostly but also lowers performance...

i think most of you cant tell the difference and dont help to improve things just make more confusion:eek:....this kernel is inferior to boeffla one, which is the best after i tried all kernels avaiable.

i was responding to gabyif, he says your kernel is supersmooth and more battery efficient then the boeffla one....which is incorrect and basicallly a lie.

i tried your kernel and when choosing the power efficients governors all they do is disabling cores, thats is a good way to save battery but definitely you would notice that overall performance is not the same, it feels laggy choppy and not responsive at all.

when i choose performance governor its smooth yeah, but not smoother or faster then the boeffla one...also very power hungry.

also with boeffla you can OC your cpu at 1704mhz which will make it faster by say 1-20milliseconds maybe more, are they noticeable?..thats a good question...but definitely wont hurt.

im not talking about features or optimizations because they dont bother me...but the things i notice i feel like i have to tell them not spread bull**** like some guys do here...

i change roms and kernels any day so im not a fanboy of any kind if you were wondering.:fingers-crossed:

i tried arter97 kernel which has this 1800mhz but i cant complete a benchmark...cant overvolt...and i dont like that kernel overall.
so comon Andi....;) pls add another frequency....im sure with overvolt we can get that frequency stable.
thanks.

Jeez! I feel like i want to grab this boy ... and beat the hell out of him :mad:
 

gabyif

Senior Member
Jul 23, 2012
847
239
Bucharest
I want to get in this...because it seems that from my post,started all this useless discussion.In my post I was refering at MY OWN experience with AK and Boeffla,I was not talking in general,only ME.And if anyone tries to interpret my words to demonstrate something,I don't know what,it is his/her own problem.What is good for me,could be bad for you and vice-versa.I want to apologize to @JustArchi and all xda members that felt offensed by my post and the things that followed after that.Archi,I am sorry that from my post,started a spamming discussion and I want to ask the moderators to delete these useless posts to keep the thread as clean as possible.Again sorry :angel::good:
 

marcero

Senior Member
Nov 22, 2010
297
58
near Aachen
since 1.5.1 I have some UI lafs especially when and shortly after turning on screen. In cool tool it shows that cpu is running at 1600 MHz all the time, sometimes process system_server pops up.
Cannot tell if its AD 3.0.0 pre-experimental or 1.5.1, since I flashed them to shortly after each other to tell about that.
 

katolink

Senior Member
Aug 12, 2011
254
85
Bucharest
since 1.5.1 I have some UI lafs especially when and shortly after turning on screen. In cool tool it shows that cpu is running at 1600 MHz all the time, sometimes process system_server pops up.
Cannot tell if its AD 3.0.0 pre-experimental or 1.5.1, since I flashed them to shortly after each other to tell about that.
Have not tried AD 3 exp so far, but I think it is not caused by AK 1.5.1. No lags here and cool tool shows diferent values for CPU.

Tapatalk'ed from my Galaxy S3-I9300 running ArchiDroid 1.7.18 powered by ArchiKernel 1.5.1
 

Top Liked Posts

  • There are no posts matching your filters.
  • 261
    linux-logo-600x300.png


    • Base: N7100 KK Sources
    • Linux 3.0.31
    • Compiled using latest ArchiToolchain 5.2.0
    • ArchiDroid Optimizations
    • Using AnyKernel method (compatible with all ROMs for both AOSP and Samsung)
    • And many other awesome things I have no time to list

    ArchiDroid Optimizations:
    - Fully optimized for Samsung Galaxy S3 (-marm -march=armv7-a -mcpu=cortex-a9 -mtune=cortex-a9 -mfpu=neon -mfloat-abi=softfp)
    - Compiled with O3 optimization level (-O3)
    - Performed interprocedural pointer analysis and interprocedural modification and reference analysis (-fipa-pta)
    - Performed loop invariant motion on trees. It also moved operands of conditions that are invariant out of the loop, so that we can use just trivial invariantness analysis in loop unswitching. The pass also includes store motion (-ftree-loop-im)
    - Created a canonical counter for number of iterations in loops for which determining number of iterations requires complicated analysis. Later optimizations then may determine the number easily (-ftree-loop-ivcanon)
    - Performed induction variable optimizations (strength reduction, induction variable merging and induction variable elimination) on trees (-fivopts)
    - Tried to reduce the number of symbolic address calculations by using shared “anchor” symbols to address nearby objects. This transformation can help to reduce the number of GOT entries and GOT accesses on some targets (-fsection-anchors)
    - Assumed that loop indices do not overflow, and that loops with nontrivial exit condition are not infinite. This enables a wider range of loop optimizations even if the loop optimizer itself cannot prove that these assumptions are valid (-funsafe-loop-optimizations)
    - Moved branches with loop invariant conditions out of the loop (-funswitch-loops)
    - Attempted to avoid false dependencies in scheduled code by making use of registers left over after register allocation. This optimization most benefits processors with lots of registers (-frename-registers)
    - Re-ran common subexpression elimination after loop optimizations are performed (-frerun-cse-after-loop)
    - Didn't keep the frame pointer in a register for functions that don't need one. This avoids the instructions to save, set up and restore frame pointers; it also makes an extra register available in many functions (-fomit-frame-pointer)
    - Made a redundant load elimination pass performed after reload. The purpose of this pass is to clean up redundant spilling (-fgcse-after-reload)
    - Ran a store motion pass after global common subexpression elimination. This pass attempts to move stores out of loops (-fgcse-sm)
    - Eliminated redundant loads that come after stores to the same memory location, both partial and full redundancies (-fgcse-las)
    - Constructed webs as commonly used for register allocation purposes and assigned each web individual pseudo register. This allows the register allocation pass to operate on pseudos directly, but also strengthens several other optimization passes, such as CSE, loop optimizer and trivial dead code remover (-fweb)
    - Performed tail duplication to enlarge superblock size. This transformation simplifies the control flow of the function allowing other optimizations to do a better job (-ftracer)

    Download


    What to expect:
    - Awesome stock battery life on AOSP ROMs (due to Samsung sources and not smdk4x12)
    - Blazing fast (Deep advanced optimizations, Linaro toolchain, this is the beast)
    - High compatibility (AnyKernel method, the kernel should work on all ROMs)

    What to expect in future:
    - You tell me

    What to NOT expect:
    - Many CPU or I/O governors # We don't need overhead, you can achieve nearly the same just by tweaking governor to your needs
    - Features I don't like/need
    - Dualboot (see above ^)
    - F2FS (see above ^, however this one depends on kernel upstreaming, as f2fs is merged)

    ArchiKernel is provided in 4 different variants, 2 for AOSP ROMs and 2 for SAMSUNG ROMs.

    AOSP -> 29 MALI blobs AOSP variant. Should cover all Lollipops for SGS3.
    AOSP_OLD -> 23 MALI blobs AOSP variant. Should cover all KK and pre-KK ROMs for SGS3.
    SAMSUNG -> 23 MALI blobs Sammy variant. Should cover all JB ROMs and also some KK ROMs based on N7100 port (such as ArchiPort)
    SAMSUNG_NEW -> 29 MALI blobs Sammy variant. Should be used only on KK+ Sammy ROMs based on korean port

    ArchiKernel is using my own AnyKernel flashing method, therefore it does not suffer from a need to update it with maintenance ramdisk updates, and that's one of the reason why it should work properly with all ROMs, even those not officially supported, as long as variant matches.

    Flashing instructions:
    1. Make sure that you have stock kernel already flashed (the one which comes with your ROM), if you're running custom kernel already, reflash your ROM without wipe, this will also flash stock kernel. This is ultimately important, DON'T FLASH ARCHIKERNEL ON ANOTHER CUSTOM KERNEL, you may face various issues you've never seen before.
    * This is because ArchiKernel uses AnyKernel method - it pulls ramdisk from your current kernel. If you brick your phone by flashing AK on top of custom kernel, you know who will be responsible for that.
    2. Flash ArchiKernel zip.
    3. Profit!

    Updating instructions:
    1. If you arleady have older ArchiKernel version flashed properly with above instructions, and changelog doesn't state otherwise, just flash the .zip with new version of AK.
    2. No wipes, cleaning dalvik cache or anything else is required, flashing zip is enough.
    3. Profit!

    Bugs:
    None known

    XDA:DevDB Information
    [EOL] [KERNEL] [AOSP/Samsung/Ports] [ArchiToolchain 5.2] [01/10/15] ArchiKernel V2.1, Kernel for the Samsung Galaxy S III I9300

    Contributors
    JustArchi, Moster2
    Source Code: https://github.com/ArchiDroid/ArchiKernel

    Kernel Special Features:

    Version Information
    Status: No Longer Updated

    Created 2014-06-17
    Last Updated 2015-11-12
    112
    Okay.

    After a second thought, yes, I'm releasing my Git repository open for everyone.

    You guys are right. It's about the entire community, not me.

    It's the entire community we want to improve, not a specific one or a group.

    I'd like to contribute to the community.
    I'd like to see other developers take commits from this repository and make things better.

    The Git is at https://bitbucket.org/arter97/arter97-i9300-release

    So,
    @JustArchi , go fix your kernel's camera issue and delight the users.
    @Lord Boeffla , let's both work on improving Knock-On(or dt2w).
    @beeeto , thanks for persuading me.

    We love XDA.
    We love to share things and make things better.

    Me too. I love to apply things from other developers.
    But with proper credits.

    I'd like to see other developers take commits from this repository and make things better.
    Contribute to the entire community.

    But with proper credits.

    'Opensource' does not mean 'no-respect'.
    Leave credits to original author.

    That's all I want.

    Thanks for your support.
    49
    ArchiKernel V1.5

    Linaro toolchain update, 4.9.1 -> 4.9.2, 14.07 -> 14.09
    - SEA2 -> Update14 (really misc update from samsung)
    - Added BFQ scheduler # Thanks to @Moster2
    - STweaks: ZRAM, BFQ, Knock-on corrections, Sharpness tweak and more misc bugfixes/improvements # Thanks to @Moster2
    - Added ArchiKernel logo after booting of the kernel
    - Silenced some more debug informations (including touchscreen)
    - Updated ZZmoove to 0.9 beta4
    - Merged N8000 sources for all variants (this should fix graphical glitches for ArchiPort and other ported Sammy ROMs, AOSP also benefits from that) # Thanks to @LordBoeffla
    - Fixed graphical glitches on AOSP ROMs which happened after above merge # BIG THANKS to @Moster2
    - Many R4P0 fixes and improvements # Thanks to @Moster2
    - Fixed sharpness tweak # Thanks to @Moster2
    - Added some misc LD optimizations (-Wl,--sort-common + -Wl,--O1)
    - More on github

    Download, changelog, and cookies

    I've moved downloads and changelogs to github, as it should be more reliable than XDA servers. Also you can get updates just by watching github repo.

    Please let me know if you find any issues, I tested only AOSP variant due to lack of time recently, however, AK is using unified tree so it's very unlikely that other variants will see any issues.

    Have fun and don't forget to SMASH THAT THANKS BUTTON FOR MOSTER2, as he's doing more than me for this kernel lately! Not even mentioning that N8000 merge works on AOSP fully thanks to him (I'd simply revert it otheriwse).

    Yes, I guess this is the only AOSP kernel with kitkat sources right now. Andi made a perfect commit with N8000 additions for his ArchiPort Boeffla, I merged it and resolved the conflicts, while Moster2 fixed graphical glitches on AOSP, I love this community :).
    47
    ArchiKernel V1.3


    [SIZE="+1"]Changelog is strong with this one :cool:.[/SIZE]


    Changelog

    ArchiKernel V1.3

    - Enabled LED fading/blinking support @Moster2
    - Enabled haptic control on AOSP roms like CM/Omni @Moster2
    - Enabled voltage control of the CPU @Moster2
    - Enabled overclocking of the CPU to 1600Mhz @Moster2
    - Enabled GPU clock control and voltage interface @Moster2
    - Enabled touch LED control @Moster2
    - Updated ZZmoove to 0.9 beta3 @JustArchi
    - Enabled SELinux @JustArchi
    - Enabled ext4 security labels @JustArchi # This fixes being unable to mount ext4 sd cards, reported by @Senior_Limpio
    - Enabled OC by default @JustArchi # This enables 1600 MHz by default, you can still go back to 1400 via sysfs
    - Fixed CVE-2014-3153 @JustArchi
    - Fixed frequency slider in performance settings @JustArchi # Found i.e. in Omni
    - Cleanup of ArchiKernel settings @JustArchi

    BIG thanks to @Moster2 for backporting features in a clean and professional way!



    Download
    Remember to flash ArchiKernel on top of Stock kernel for your ROM (fresh install) OR on top of older ArchiKernel (update).


    Have Fun! :cool:
    39
    @JustArchi, the graphical glitches with the new sources should be fixed now. Finally had some time and will to fix it :D