[KERNEL] [Y300/G510] Stock Huawei

[Guest]

Thx for the sugar, but if I really was the kernel's performance would be much much better

[Guest]

When I got time i'll start an experiment with "double tap to wake". This requires to keep the touchscreen's interrupts enabled, which will result into an higher battery drain however. But we will see. It's worth a try at least.

[Guest Domino2115]

I think that"double tap to wake" isnt that right what we need :p

[Guest fonz93]

Thx for the sugar, but if I really was the kernel's performance would be much much better

 

It's already a very good kernel, don't be modest :), if wasn't for you now the stock huawei rom was been the same sh1t that was previously

Edited May 22, 2014 by fonz93

[Guest]

There are other kernel's (chil360 or cexstel) which can get used, too :P

 

But I appreciate that ppl got use of the work I share

[Guest fonz93]

There are other kernel's (chil360 or cexstel) which can get used, too :P

 

But I appreciate that ppl got use of the work I share

 

Chil is only for kitkat, cextel kernel is good but your kernel is on another planet.., of course i don't want to belittle ceastel's work

 

 

also i am curious to see what can become this kernel with msm patches

Edited May 22, 2014 by fonz93

[Guest jor1196]

I would like to disable and enable things like the synopsis, also oc gpu, and some things like the kernel cexstel but more stable

[Guest]

If you exchange chil360 kernel's ramdisk with mine or the one of the stock kernel it will work, too.

 

I wanted to update kernel's android drivers too.

 

There are toooooo many things I actually wanna work on. This kernel source is sooooo old

[Guest]

I can work on CPU oc (~ +50 Mhz, more aren't possible right now by multiplier overclocking)

 

GPU overclock isn't a big deal neither. I already changed the code for it, but didn't enable higher clocks above 300 Mhz, yet --> https://github.com/moddingg33k/android_kernel_huawai_Y300-J1/commit/c581a9dbe1bb482fb06ba933d1112e4d78877f3c

Edited May 22, 2014 by Guest

[Guest]

I would like to disable and enable things like the synopsis, also oc gpu, and some things like the kernel cexstel but more stable

 

Give me some examples of what features you are missing ;)

[Guest jor1196]

1And to enable and disable some things like your kernel android, the synopsis400786647"]Give me some examples of what features you are missing ;)

[Guest ZolaIII]

@jor1196

Fast charging is not a big problem to implement bat it will work only over the USB 3.0 & you don't really want to charge battery fast as it will reduce charged capacity & reduce battery life spin due the temperatures.

Fsync & dinamic shifting between synchronous & asynchronous will be implemented right after we settle down basic IOs that represent a real problem & we are on the best path to do so after yesterday's resolve.

We playing so much with compiler flags so much that I am getting a sea sick even when I think of it.

Encryption is useful on Android as a winter snow as nothing will actually use it. It's plain stupid on every ARM chip to even try to use it as it lacks power to handle it, even desktop x86 CPUs have a special crypto blocks to handle it. ARM did introduce optional crypto block for the V8 A57 bat aiming at server market. Even on huge FPGAs crypo block is optional!

We already tried timer slack & it didn't go so well. As it is it it's hard to implemented it not to case problems with processes and on the long run. Anyway plan is to merge main msm 3.4 branch with weak lock awareness...

As it's go for the CK Kolivas tweaks selection of them (ck3,2,1) will be merged. We even tried to merge a BFS bat damn thing just didn't want to work as it's written for x86, we even tried a PI arm port bat it just bricks kernel. Shame about this one as it would be really useful!

About CPU & GPU OC it will come at the end as it's not about how animal is fast bat how you feed it. This especially goes for GPU.

Primary goal is to tune IO system as much as possible as only then other things make sense. I got a record real life performance on not OCd system as it's really sum of all parts especially on SoC!

Best regards!

[Guest]

Fast Charge

Dynamic fsync

ARM flags optimization

Optimized AES and SHA1 routines

Timer slack controller

Ck3 Tweaks

I know some are cexstel kernel but I would like to be in yours, because this is more stable

 

Well...it's cexstels adoption of: http://forum.xda-developers.com/showthread.php?s=c81a449d83f698099d9b4cc4e64abb1f&t=2183378 (to be precisely)

 

 

ARM flags optimization are a bit fishy. I add all necessary flags already (-march=armv7-a & -mcpu=cortex-a5). Some other flags like for FPU (floating point unit) aren't suitable for kernel build, since the kernel's scripts use integer-math only, no floating point.

 

Timer Slack Controller is causing more issues than providing any improvements for now, so I skipped it.

 

 

I can re-apply dynamic fsync soon. And i'll work on (optional) OC, too.

 

EDIT: cexstel also add "vdd sysfs cpu voltage control". Unluckily only the voltage-levels are getting exported through this interface, not the actual voltages itself. It's not useful on this way imho.

Edited May 23, 2014 by Guest

[Guest thetonyxx]

 

 

 Unluckily only the voltage-levels are getting exported through this interface, not the actual voltages itself. It's not useful on this way imho.

downvolt cpu works but is not controllable 

once I turned down a lot of evidence for the cpu voltage and cpu performance have been very compromised 

I had riflash rom

[Guest c3v90]

@moddingg33k

 

is it possible to add ROW scheduler?

[Guest]

I wanted to add it before I went sleep yesterday, but I were too tired

 

Give me a few days when finding some spare time and it will be added.

[Guest]

Regarding "F-Random":

 

Although it might be considered as possible security risk, here's a short script to replace the default random number generator by FRANDOM
 

#!/system/bin/sh

#
#  FRANDOM enabler
#        by moddingg33k
#
# This script will replace the kernel's default random number generator device
# with FRANDOM (if supported by the kernel).
#
# Although Android's Dalvik-Engine doesn't seem to make use of /dev/random
# some drivers however do. Especially TCP related tasks might profit from the
# fast random number generator.
#
# Figure it out by your own. Good luck and happy testing! :)
#
# NOTE: those changes made by this script do NOT persist after rebooting
#       your device. Place this script into your init.d folder or use
#       any APP of your choice, which will execute the script after each boot.
#

########################################
# DO NOT EDIT THE CODE BELOW
# (unless you know what you are doing)
########################################

# does /dev/frandom exist?
if [ -e /dev/frandom ]; then
    # renaming /dev/random
    mv /dev/random /dev/random.orig
 
    # linking /dev/frandom to /dev/random
    ln /dev/frandom /dev/random
 
    # ensuring correct permissions
    chmod 0666 /dev/random
fi

# does /dev/erandom exist?
if [ -e /dev/erandom ]; then
    # renaming /dev/urandom
    mv /dev/urandom /dev/urandom.orig
 
    # linking /dev/erandom to /dev/urandom
    ln /dev/erandom /dev/urandom
 
    # ensuring correct permissions
    chmod 0666 /dev/urandom
fi

#
# END OF SCRIPT
#

INFO: FRANDOM exists on kernel builds of 23.05.2014 (and later)

 

EDIT: on kernel builds AFTER 09.06.2014 this will be enabled by default, as combined with another commit it keeps the entropy up @ 4096 most of the time.

Edited June 8, 2014 by Guest

[Guest Victod]

F-Random ENABLER.zip

 

 

F-Random ENABLER v1.1.zip

Edited May 24, 2014 by Victod

[Guest]

I should have mentioned that I didn't test the script, yet. Let me know if there are any issues

[Guest Victod]

I should have mentioned that I didn't test the script, yet. Let me know if there are any issues

 

No Issues so far... btw how do I know if Frandom is working?? 

 

EDIT:

 

I made a test like @Christopher83 said and here is my results... all seems be ok, isn't it?

 

Edited May 24, 2014 by Victod

[Guest]

Hm...the results for frandom seem to be too high.

 

Can you do an:

ls /dev/*random*

an attach an screenshot of the output please.

 

EDIT: Never mind. Frandom itself is working fine. The issue is more likely realted to urandom, as it takes a lot of time for execution

Edited May 24, 2014 by Guest

[Guest Victod]

Hm...the results for frandom seem to be too high.

 

Can you do an:

ls /dev/*random*

an attach an screenshot of the output please.

 

 

Edited May 24, 2014 by Victod

[Guest]

Thx for testing & reporting, Victod. Could you maybe do another test please, after you have updated your attached script?

 

I exchanged random with frandom, but forgot to do the same with urandom <-> erandom.

 

The previous script got just updated (fixed)

Edited May 24, 2014 by Guest

[Guest kannasbor0]

Hi everyone!

I have a question, but I don't now, that is kernel related or not.

On wifi I have 6 hours screec on time, but when I'm on 3G, it drains my battery extremely high.. If I'm on 3G with good signal, my screen on time about an hour.. :/

Anyone have the same issues?

It's because of kernel, or I have to flash b199 baseband? Can it fix the problem? I'm on cm10.1..

And the last one, could you build a base kernel for cm10.1 with zram and updated bases, as we talked from it before?

I tried SlimStock with your kernel, and that's absolutely awesome!

Thanks for your work!

Regards

[Guest fonz93]

It's ok this result?, i am using new fixed script

 

Edited May 24, 2014 by fonz93