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

Search This thread

phone_user

Senior Member
Nov 13, 2011
791
644
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​









 
Last edited:

phone_user

Senior Member
Nov 13, 2011
791
644


◆ 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
 
Last edited:

zephiK

Inactive Recognized Developer
Aug 23, 2009
21,655
37,705
New York, NY
The developer wanted to keep the kernel as a RootzWiki exclusive. Kind of a silly thing to do in my opinion as it hurts the users to split the community.

Glad to see this kernel make its way to the Galaxy Nexus though. Was a great kernel for the Nexus S. Now we just need morfic

Sent from my Galaxy Nexus using xda premium
 
Last edited:
I

Id Arcanum

Guest
The developer wanted to keep the kernel as a RootzWiki exclusive. Kind of a silly thing to do in my opinion as it hurts the users to split the community.

Glad to see this kernel make its way to the Galaxy Nexus though. Was a great kernel for the Nexus S. Now we just need morfic

Sent from my Galaxy Nexus using xda premium
Well he got a phone from them.. but yeah he said please link to that thread, but I don't see it living for long here..

morfic.. hopefully soon :)
 

zephiK

Inactive Recognized Developer
Aug 23, 2009
21,655
37,705
New York, NY
Well he got a phone from them.. but yeah he said please link to that thread, but I don't see it living for long here..

morfic.. hopefully soon :)

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
 
  • Like
Reactions: sert00
I

Id Arcanum

Guest
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
ah I see now I misread your post :/.. anyways, 2 forums to check now for me also (ROM).
 

skyhigh2004

Senior Member
Oct 10, 2010
1,116
65
Saint Cloud MN
Only sounds for now.. doesn't boot on my GN and clean installed AOKP b15 (both versions).

There's a second version of the kernel in that thread that ezekeel posted that has less of a ram/gpu/bus OC. He posted for people that can't boot the one in the OP, try that. I'm lucky, I must have a good soc I can run the one in the OP with AOKP 15 no problem.

Sent from my Galaxy Nexus
 

Ezekeel

Retired Recognized Developer
Jun 21, 2011
715
1,680
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.
 

zephiK

Inactive Recognized Developer
Aug 23, 2009
21,655
37,705
New York, NY
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.

I know you can be a member of both. It splits the community in terms of discussions. Because one forum thread on XDA can be discussing about a bug within the kernel; where on RW, the discussion is about something else. You can fill in the rest of the points.

Pretty much what I said about developers updating their threads having the latest exclusive to Rootzwiki. Some developers don't update their threads and have it a few versions behind and not even link Rootzwiki.

I certainly have the time to visit both forums, no doubt in my mind about that. I visit both, but I mainly "lurk" on Rootzwiki and don't really put any effort into contributing to the forum discussion.

Unfortunately, for some users they don't have the time to go through two forums and view all the forum pages that they weren't able to read then to find out that there's a bug with the current release (or having a outdated thread where it's fixed in the newer version). Pretty much the point I'm making is that the OP thread is not equal to the Rootzwiki thread (or vice versa) in some ROMs or kernels. But pretty much since you made a rule about not having download links on any other forum, it pretty much voids my point but not generally speaking as not all devs follow this.

As much credit as Rootzwiki give to the developers. XDA can deserve the same amount of credit for providing a source for developers to distribute their custom made ROMs / kernels for mass consumption due to it's popular user base.
 
Last edited:

zeekiz

Senior Member
May 9, 2011
622
177
Western Australia
I know you can be a member of both. It splits the community in terms of discussions. Because one forum thread on XDA can be discussing about a bug within the kernel; where on RW, the discussion is about something else. You can fill in the rest of the points.

Pretty much what I said about developers updating their threads having the latest exclusive to Rootzwiki. Some developers don't update their threads and have it a few versions behind and not even link Rootzwiki.

I certainly have the time to visit both forums, no doubt in my mind about that. I visit both, but I mainly "lurk" on Rootzwiki and don't really put any effort into contributing to the forum discussion.

Unfortunately, for some users they don't have the time to go through two forums and view all the forum pages that they weren't able to read then to find out that there's a bug with the current release (or having a outdated thread where it's fixed in the newer version). Pretty much the point I'm making is that the OP thread is not equal to the Rootzwiki thread (or vice versa) in some ROMs or kernels. But pretty much since you made a rule about not having download links on any other forum, it pretty much voids my point but not generally speaking as not all devs follow this.

As much credit as Rootzwiki give to the developers. XDA can deserve the same amount of credit for providing a source for developers to distribute their custom made ROMs / kernels for mass consumption due to it's popular user base.


If you don't have the time to do some extra reading, you probably don't have the time to root, and if you can't afford to do some extra reading in order to quash any bugs that may occur whilst you are using a ROM, then once again, maybe you should stay on stock.

Think about it this way, having certain distributions on RootzWiki will eventually increase their community, which will give users a choice in regards to where they wish to settle to collect their distributions from. There's no point constricting everything into one place, especially considering certain communities really do have a poor reputation in regards to quality of users, posts, content, and hosting. RootWiki I'm pretty sure are also responsible for actually supplying a few developers with devices, which is rather generous in a sense, don't see many communities doing this (most likely wrong).

Not my place to argue this, but I don't think you have a leg to stand on with your argument.
 

zephiK

Inactive Recognized Developer
Aug 23, 2009
21,655
37,705
New York, NY
If you don't have the time to do some extra reading, you probably don't have the time to root, and if you can't afford to do some extra reading in order to quash any bugs that may occur whilst you are using a ROM, then once again, maybe you should stay on stock.

Think about it this way, having certain distributions on RootzWiki will eventually increase their community, which will give users a choice in regards to where they wish to settle to collect their distributions from. There's no point constricting everything into one place, especially considering certain communities really do have a poor reputation in regards to quality of users, posts, content, and hosting. RootWiki I'm pretty sure are also responsible for actually supplying a few developers with devices, which is rather generous in a sense, don't see many communities doing this (most likely wrong).

Not my place to argue this, but I don't think you have a leg to stand on with your argument.

I have the time to do the extra reading. I'm not saying it on my part, I'm saying for everybody else. And not everybody has to read to be using custom ROMs and kernels. That's why there are "nightlies" and "stable" releases. Stable releases are releases that are meant for people who don't have the time to sit here and flash every other release. I myself flash the newest and latest all the time. You can validate this by looking at my posts as I'm a very active poster and help many individuals out with their phones when they're having problems.

Not everybody are addicted to flashing because they don't have the time and they're not always available to be near a computer. This causes a misconception when it comes to ROM/kernel releases (as I mentioned earlier so you can stop directly calling me out).

As I mentioned previously, I respect RootzWiki for what they're doing and I have mentioned this numerous times. I'm not disliking RootzWiki or the developer's choices whatsoever. As much as RootzWiki has for its developers, the same goes with XDA for mass consumption. And that's that, developers and users both go the same way.

Developers want mass consumption for people to find bugs with their kernels / ROMs to have it fixed. The more people, the more chance of stability.
Users want more developers for more production of ROMs / Kernels. Kinda like how XDA & Rootzwiki correlate with each other.

I personally like Ezekeel's work with the lazy governor and what he's done for the Nexus S and I'm really happy to see him developing for the Galaxy Nexus. Just stating my two cents for the casual flashers (yes they do exist) although I'm not one of them. If you'd like to have this debate, feel free to inbox me. This is way too irrelevant out of this thread.

But anywho getting back on topic. Can't wait for this kernel to mature and see what it has to bring to the table. It'll definitely be a good thing overall when the kernel is stabilized then source is revealed for other creative kernel developers to implement the 'lazy' governor and additional features to improve overall kernel performance.
 
Last edited:

b15love

Senior Member
Aug 21, 2010
157
1
Its not that big a deal to write a damn book on it. Who cares where the kernel is posted, them more devs the better.
 

matt2053

Senior Member
Dec 17, 2010
2,066
295
40
Clearwater, FL
Trust me, the issues have nothing to do with making sure the users see all the discussions and updates. It boils down to the fact XDA is not really happy when someone uses their reputation and brand and web presence to drive traffic to a competing site. Good or bad? I'm just saying, that is why the rules about this subject exist. It's naive to think otherwise.

The other rule is that the Development forum is a place for developers to share their own work. It is not a place for users to post links to someone else's work on some other site. That is why I think this thread belongs in General. But whatever.

But with all that said, I know that Ezekeel is one of the most talented and creative kernel developers working on Android today (I know his work from Nexus S) and I'm very happy his work is available for the Galaxy Nexus now. Cheers!

Sent from my Galaxy Nexus using XDA App
 

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.