[INFO][KERNEL] GLaDOS by Ezekeel | GSM / Verizon / Sprint

Search This thread

neok44

Senior Member
May 19, 2009
1,557
162
Florida
Open root explorer:
Go to /sys/class/misc/colorcontrol
Open multiplier with an editor.
Change the 3 values to: 2204318071 2004318071 2354318071
save and open v1_offset
Change the 3 values to -4 0 4
save
enjoy!
:D

lol. guess that answers that question. thank you!

but i'm still curious about the battery life/overclocking things. this is the first kernel i've ever even considered installing so i'm very new to this.
 

loveact

Senior Member
Sep 22, 2010
240
18
Jakarta
lol. guess that answers that question. thank you!

but i'm still curious about the battery life/overclocking things. this is the first kernel i've ever even considered installing so i'm very new to this.

well, ezekeel has stated some things :

This kernel is optimized to run best at the default options. There no need to change options like for example CPUfreq governor or min/max frequency - changing anything can have a negative effect on stability and performance.

Do not use profiles or hotplugging, they are unnecessary and only lead to instabilities.

If you experience any problems and are on a nightly or kanged ROM, try the latest stable version of that ROM first. I will not give support or answer any questions if you do not try this before reporting a problem with the kernel.

If you experience stability problems like reboots, freezes, FCs and SoDs and you did OC, first try changing back to the stock settings. If this solves the problems, your OC configuration is not stable. There are some indications that OC settings which run fine at high battery charges might still cause problems at lower battery charges. So to be safe always check that your OC configuration runs fine at low battery like 5%.

When reporting a bug always include information about your ROM and hardware model. Also be as precise as possible when describing the problem. Just because a single person is experiencing a problem, it does not mean there actually is a problem with the kernel. I always wait until at least one other person can confirm the issue before I look into it. So if you see someone posting a bug report, do not be shy and feel free to confirm the issue or if you do not have the problem let me know that too.

When asking for a feature you would like to see implemented in GLaDOS always provide a link with information about this tweak and preferably also a link to the source code.

just use the default setting, and you're good to go!
personally i'm just overclocking for benchmarking using antutu or quadrant.. :)
 

neok44

Senior Member
May 19, 2009
1,557
162
Florida
just one last question here.

if for whatever reason i have to go back to the stock kernel, how do i do that?
 

DJ "suMo*

Senior Member
Jul 29, 2011
195
15
Cool I flashed it. Thanks, it works great!

Sent from my Galaxy Nexus using XDA App

If you flash a new Ir11 build over remember to flash fracnco's before GLaDOS. Again I don't know why this is but you see it works. GLaDOS won't boot on Ir11 without doing this - it was the same with Ir10.

Sent from my GN
 
Last edited:

neok44

Senior Member
May 19, 2009
1,557
162
Florida
Is this supposed to stick? It doesn't for me. Did the steps, saved the reopen and it reverted right back to what it was before.

haven't tried it yet but i'd like to know how to make it stick too, i have to reboot my phone a decent amount of times due to tmos stupidity and i don't want to have to do this every single time.
 

neok44

Senior Member
May 19, 2009
1,557
162
Florida
i changed the 1 to a 0 but it's still not sticking. if i reboot it goes back to 1 and the offset goes back to 0 0 0 instead of -4 0 4

aside from that, i'm noticing a pretty good improvement. still a little yellow/warm though. wish there was a way to totally get rid of it. need color temperature settings like on pc monitors

*edit* also i've been playing around with different offsets that i've seen and i've noticed no difference at all when changing them. think something may be wrong, or i'm doing something wrong.
 
Last edited:

irishrally

Senior Member
Jun 13, 2009
3,386
524
California
i changed the 1 to a 0 but it's still not sticking. if i reboot it goes back to 1 and the offset goes back to 0 0 0 instead of -4 0 4

aside from that, i'm noticing a pretty good improvement. still a little yellow/warm though. wish there was a way to totally get rid of it. need color temperature settings like on pc monitors

*edit* also i've been playing around with different offsets that i've seen and i've noticed no difference at all when changing them. think something may be wrong, or i'm doing something wrong.

You can get the settings to stick after a reboot by running a script with ROM Toolbox or gscript at boot.

Write this into a new script:

Code:
#! /sys/bin/sh

echo 0 >/sys/class/misc/colorcontrol/safety_enabled

echo 2001234567 2001234567 2301234567 >/sys/class/misc/colorcontrol/multiplier

echo -4 0 4 >/sys/class/misc/colorcontrol/v1_offset

Select the option to run at boot and requires root.

v1_offset is working fine for me and I can immediately see the change when I save changes in text editor.
 

abz54

Senior Member
Jul 21, 2010
137
11
Hi, been using this kernel for a week, tried Franco's kernel to see if my phone can run 1.65Ghz, its runs without any problems, but with this kernel I can't seem to get past 1.5Ghz, gonna stay with this kernel due to the amount of tweaks, but would like to know if anyone can help me. Thanks

Sent from my Galaxy Nexus using xda premium
 

!crazy

Senior Member
Dec 16, 2011
2,081
633
LG G6
Xiaomi Poco F3
have you run any benchmarks with Franco's 1.65 GHz kernel?
It would be interesting to know how well it really performs compared to GLaDOS but maybe clocked even lower like 1.4 GHz. My phone runs much better with MPU clocked to 1.4 then 1.5 GHz. Actually it runs better at 1.2 then 1.5.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 33
    V1.xx for ICS - the last V1.34
    V2.xx for JB

    584673157.png


    Ezekeel is the dev of GLaDOS kernels for Android Devices​

    ◇ The Official Thread ◇

    ☞click GSM

    ☞click LTE

    Ezekeel said:
    Before you ask... Yes this kernel will work with your Sprint Galaxy Nexus.


    I'm a general user, just link for the XDA members' information

    To download does not require registering, it's Rootzwiki forum

    Ezekeel said:
    "Permission is granted to distribute these zips and links on non-English speaking sites and forums. However permission is not granted to distribute these zips and links on sites and forums with English as their main language; instead please link to this thread."


    536964881.gif



    Features:

    Features:
    - Based on stock Android kernel Jelly Bean 4.1.1 JRO03C
    - Live OC version 2
    - Custom Voltage version 3
    - Battery Life eXtender (BLX) version 1
    - SLQB memory allocator
    - Color Control version 4 (based on supercurio's idea)
    - CPUfreq governor 'Wheatley'
    - Additional 1.4GHz, 1.6GHz, 1.8GHz and 2.0GHz MPU frequency slots
    - Sound Control version 1
    - Temp Control version 1
    - Vibrator Control version 1
    - FSync Control version 1
    - USB Fast Charge
    - Gamma control
    - WiFi low latency power mode
    - CIFS (as module)
    - TUN (as module)
    - NFS client + server (as module)
    - NTFS read/write support (as module)
    - Cleaned out all unnecessary kernel features and drivers
    - Various other tweaks​









    23
    V1.4 updated
    GLaDOS-V1.4
    • Added 'Wheatley' CPUfreq governor and made it default.

    Ezekeel's commentary on V1.4

    wheatley05jpg3ceb65945f.jpg


    I have release GLaDOS V1.4 including my new CPUfreq governor 'Wheatley' which is the new default governor.

    The previous benchmarks of the usage of the C4 state for different activities have shown that for 'light' tasks like browsing the internet, reading (for example emails or eBooks) and the average app the device spends about 40% of the time in C4 with acceptable average residencies of around 11ms. For more demanding tasks like games and video playback the C4 state is still being used however the efficiency is reduced due to the low average residencies of below 5ms (considering that the wakeup latency is 1.3ms).

    I have run a few tests and as it turns out, for demanding tasks the efficiency of the C4 state is significantly reduced due to these low residency times (= large number of wakeups) to a point that the good old frequency scaling is indeed more efficient with larger battery savings. So unfortunately, relying on the C4 state alone for power savings for all tasks is not a good option.

    However, unfortunately we also cannot simply use one the available standard governors since always try the minimize the frequency without taking account that this behaviour diminishes the efficiency of the C4 state since it hinders a proper race-to-idle. So taking advantage of this knowledge what a good governor should do, is using the maximum frequency whenever the C4 state is properly used with acceptable average residencies and only scale down when the average residencies get too low (or the C4 is not used at all, of course).

    Building on the classic 'ondemand' governor I implemented this idea in my new Wheatley governor. The governor has two additional parameters:

    target_residency - The minimum average residency in µs which is considered acceptable for a proper efficient usage of the C4 state. Default is 10000 = 10ms.

    allowed_misses - The number sampling intervals in a row the average residency is allowed to be lower than target_residency before the governor reduces the frequency. This ensures that the governor is not too aggressive in scaling down the frequency and reduces it just because some background process was temporarily causing a larger number of wakeups. The default is 5.

    I have run some benchmarks to make sure that Wheatley works as planned and does not hinder the proper C4 usage for task where the C4 can be used properly (as seen in the previous benchmarks).

    glados_1.4.png


    For internet browsing the time spend in C4 has increased by 10% points and the average residency has increased by about 1ms. I guess these differences are mostly due to the different browsing behaviour (I spend the last time more multi-tabbing). But at least we can say that Wheatley does not interfere with the proper use of the C4 state during 'light' tasks. For music playback with screen off the time spend in C4 is practically unchanged, however the average residency is reduced from around 30ms to around 18ms, but this is still more than acceptable.

    So the results show that Wheatley works as intended and ensures that the C4 state is used whenever the task allows a proper efficient usage of the C4 state. For more demanding tasks which cause a large number of wakeups and prevent the efficient usage of the C4 state, the governor resorts to the next best power saving mechanism and scales down the frequency. So with the new highly-flexible Wheatley governor one can have the best of both worlds.

    Wheatley for governor!
    8
    Yeah I appreciate what rootzwiki does for the developers. It definitely favors them, it just hurts the users because they are unaware of these great and talented developer's work that's being exclusive to rootzwiki. Because, lets be honest, rootzwiki is nice to developers, but its not as popular as XDA causing a lack of awareness of releases.

    I already feel this because the rom I use gets updated the fastest on rootzwiki. The xda thread of the rom is 1-2 builds behind.

    That's just my take on rootzwiki. It definitely makes people go to their site. But I just don't think its right to split the community between the two websites.

    Sent from my Galaxy Nexus using xda premium

    You can be member of XDA and RW at the same time. So I do not see how this is splitting up the community. You can link XDA threads on RW and vice versa. No matter what forum you are currently on, the other always is only one click away. All barriers you might see that split up the community, are in reality only in your mind.

    I agree that it can cause a little more effort for the users since they might have to check two forums for updates. But let me be frank here, compared to all the effort I invested in writing this kernel this tiny bit of extra work for the users is hardly anything to complain about. If you have the time to play around with custom kernels and ROMs on your device, you got the time to check a second forum once in a while for updates.
    7


    ◆ Reset GLaDOS Control

    If the device can't boot due to inappropriate settings, install Reset_GLaDOS.Control.app.zip in CWM recovery.

    (deleting /data/data/aperture.ezekeel.gladoscontrol/shared_prefs/)

    Reset_GLaDOS.Control.app.zip


    ◆ Switching Kernels

    Switching from one kernel to the other dev's kernel, flash Preparation.for.Installing.Kernels.zip in Recovery before flashing the kernel

    (the residues from previously installed kernels are cleaned)

    Preparation.for.Installing.Kernels.zip


    ◆ Adding init.d to the existing ramdisk

    In GN forum, most of ROMs have init.d function (busybox run-parts)

    But Stock and Peter Alfonso do not have that

    Flashable zip in recovery, Adding init.d to the existing ramdisk and busybox installer


    GN_Add_init.d.zip

    Busybox_v1.20.1_CM9.zip

    or

    http://play.google.com/store/apps/details?id=stericson.busybox






    ◆ ICS Stock Kernel - 4.0.3 / 4.0.4 compatible



    ◆ Jelly Bean Stock Kernel - 4.1 / 4.1.1 compatible
    4.1 JRN84D

    boot.img format

    4.1_JRN84D_boot.img.zip

    Any Kernel format

    4.1_JRN84D_AnyKernel.zip
    4.1.1 JRO03C

    boot.img format

    4.1.1_JRO03C_boot.img.zip

    Any Kernel format

    4.1.1_JRO03C_Any.Kernel.zip


    579013459.png
    7
    V1.14 released

    ☞click GLaDOS for Galaxy Nexus (aka Nexus Prime)

    Ezekeel's commentary on that

    I have released GLaDOS V1.14.

    The OMAP4 processor build in the GN come out of production in different qualities and some chips are able to run higher frequencies than others. To account for this the processors are binned in the factory and the information about the quality is fused into a certain chip register. Among other things this information contains the MPU DPLL trim value which (indirectly) limits the maximum MPU frequency which the chip will be able to support.

    Overriding this factory-set MPU DPLL trim value removes the hard limit for the maximum MPU frequency. For example, the chip build my GN device is binned for a maximum MPU frequency of 1.2GHz and the maximum frequency I was able to reach with LiveOC was 1.32GHz (there seems to be some leeway). After overriding the trim value I was able to achieve 1.62GHz.

    screenshot2012021601041.png


    GLaDOS-V1.14
    • Override factory-set limitations for the MPU greatly increasing the OC potential.