Saturday, 10 November 2012

Goodbye XDA, Goodbye Android development

So today I finally requested my XDA account be deleted after toying with the idea for some weeks, although they didn't comply with my request to have everything deleted, posts, threads etc, so I have taken that up with them and will continue until it has all been deleted.

The non-contributing morons who comment from the sidelines have finally got what they wanted, but I feel very good about my decision to leave.
I don't want to be part of a community full of fakes, liars and idiots who contribute nothing who think they can criticise someone who has spent countless hours doing various stuff for the community.

I know I said I was scaling back in the last post I made, but this time, I'm finishing completely. I've utterly lost interest in Android kernel development and pretty much in the entire Android platform.

I don't see the point in spending hundreds of hours on something to be told that I haven't done anything for the community by some prick hiding behind a computer screen who has done *nothing* for the community as far as I can tell.
Or another prick who implied that I had 'given up', as if I *must* carry on developing and releasing kernels without the option of stopping development on a frustratingly slow, laggy and obsolete device.
I'm sorry, but with all due respect you people have a lot to learn about what you can and can't expect, mostly about what you can't expect. Stop demanding things of people who *give* their time, their life and their energy for free. It's unfair, cheeky and downright insulting.
Take a look at your own conduct first and foremost, then realise why I bite and come across as apparently 'arrogant and egotistical'.

Anyway, I have always believed that the bigger, better person knows when enough is enough and moves on to better things. It's pointless trying to change the unchangeable or fix what is utterly broken, it just makes you look foolish, and I am no fool.

Moving on is exactly what I am doing and I feel surprisingly good about it, like a rather large weight has been lifted off my shoulders.

I'll be deleting all the uploaded binaries and making my public git repos private or deleting them either later today or tomorrow, so if you want anything, download or fork it now, because it'll be gone otherwise.
The reason why I am doing this is that there is not much point in leaving my binaries and source out there when it doesn't contribute anything to the community, and apparently never has. That would be foolish.

I would like to apologise to the people that have been supportive, have helped and haven't made unwelcome comments or criticisms from the sidelines. The thing is, I never really wanted to do public releases and the attention and demands caused me to completely burn out.

I started kernel development because I wasn't happy with what was on offer and wanted some changes.

I started projects like IDLE2 for something to do because I was off work sick with severe depression and had a ton of time on my hands and needed to occupy my brain, although I ended up heaping too much on myself. The moron that claimed that it was 'just' a port clearly hasn't looked at the code, or he doesn't understand it. It's about 10% port and 90% original after I rewrote it several times in the pursuit of perfection, so put that in your pipe and smoke it...

I didn't start it to be bitched at, demanded on, criticised for my alleged 'lack of contribution' or otherwise because I do that to myself anyway and don't need help there.

By the way, I've got a Galaxy Nexus for sale if anyone wants one.


Monday, 1 October 2012

Android Kernel Development Update

UPDATED 5th October 2012

So, it's been a while since I posted an update.

There are a few reasons for this, mainly real life stuff which has taken the front seat in the past few weeks, such as moving flat and having no DSL connection, but now I have a vDSL connection. :P

I've also taken the time to think about future development plans regarding Android kernel development.

To be quite honest, I've totally lost the motivation to develop Android kernels. There are several reasons for this, the main ones being the development 'community' on XDA and the lack of collaboration.

As this is my blog, I am going to speak freely here, so if you are easily offended, or if your XDA username is faux123, r_data, showp1984*, et al, (you all know who you are) please close the page now, because you will not like the below, and if you don't like it, you know what you can do.

*I made an error here, and I apologise for it. I mistook noobishness, errors of judgement and uncertainty for intentional, malicious actions. Having spoken to showp at length, I don't believe what he has done was malicious or fits into any of the below. The fact is, the stuff I was referring to was quite old and had stuck in my mind because it irritated me at the time, whereas the other 2 individuals mentioned are actively pursuing the below style of development.

To be brutally honest, the XDA community is a fucking shambles. It is full of a plethora of copycats and cherry-picking morons, all trying to pass off their copying as their own innovations. None of them have got any development skills, any ability to logically solve problems, or any common sense what so ever. Yet, unsuspecting users see them as Godlike beings who produce magical things, when in reality all they have done is compiled code written by someone else, which the users themselves could do by following a simple set of instructions, it really is that easy.

Alas, the Godlike aurora that these cherry-pickers emit is bullshit, and any individual with an ounce of common sense knows that, but try telling n00b users that.

There is no collaboration and there is no attempt, whatsoever, to make anything better for the community as a whole. They compete to provide the biggest list of moronic 'features' possible. Their 'work' offers nothing good or useful, and just makes the XDA development community look moronic. The only reason why they do it is for their ego. Perhaps long feature lists makes up for something else which is lacking length, who knows.

The other thing which seriously pisses me off about these morons is their selective adherence to the GPL, even though it isn't their code they are compiling. It really is simple: you release the binary and push code at the same time. You don't release a 'test' release with 'new features' then push the code a week later. That is out of order and you are *not* GPL compliant. And you only do that because you don't want the other cherry-picking morons to cherry-pick the cherry-picks you have cherry-picked. Seriously, why the stupid competition? Nobody gives a fuck, apart from you.

This is pretty much non-existent. Doing something like IDLE2 is not for the faint of heart. It is complicated, it contains a lot of logic, and for the most part it works well, but there are bugs, which I could use some help with, because coding and working so close to the hardware is very new to me. Alas, no help has been forthcoming. Perhaps it is because nobody is interested in the Nexus S anymore. I don't blame them to be honest, it's old and slow, which is why I am selling mine in the next week or so. The fact is though, I embarked on a fairly ambitious project which has been, for the most part, successful. I published my work on XDA hoping that other developers would see the potential and assist, in fact, I actively requested this, but to date, not one person has approached me offering to help with development, which is really fucked up if you ask me.

I can't do it all on my own, I have spent countless hours attempting to fix the outstanding issues, but I can't. Basically, the IDLE2 project is on hiatus as far as I am concerned.

So...that stuff has been boiling up for months, as you probably know from some of my recent posts on XDA. I can't and won't deal with the fact that noise from the moronic crap outlined above blasts away the small amount of real development which takes place on XDA.

Seriously, XDA, sort the shit out. Move these morons into their own subforums or something. Make 'original' development actually mean that, and don't just allow any old cherry-picked crap to reside in there.

Anyway...fuck XDA and it's plethora of pseudo developers.

Some people may think 'well, you aren't exactly a master of kernel development either, you are an arsehole with an attitude problem'.

I totally agree. I'm not. I'm quite n00bish when it comes to writing code, but I try to make things better, I don't do stuff for my ego and I do genuinely do things to try to better the community.
But what is the point in putting countless hours in when it is drowned out by moronic shit and when you receive abuse from moronic users for trying to tell them that their favourite 'developer' is a fake?
As for an attitude problem, appearances can be deceptive. Being intolerant of morons and fakes does not equal an attitude problem. It just means I see past the bullshit, which is a good thing.

Future Plans
Future plans are pretty much to cease 'official' Android kernel development. I won't be releasing any other Android kernel binaries officially via my blog or via XDA. I will announce developments on my blog and may provide binaries to test, but that will be the limits of my Android development.

There *may* be more regular 'unofficial' releases for Nexus Prime and Nexus 7 available in my IRC channel, #thalamus-hacking on FreeNode, but it will be what I'm working on personally.

IDLE2, as previously mentioned, is on permanent hiatus unless somebody assists me with the outstanding bugs, but it would have to be more than just talk to rekindle my interest there, because I've wasted too much time on it already, and I'm not into flogging dead horses.

Nexus S kernel will not be updated any more. It's old, slow and I'm not sure how people use it as a daily device without throwing it against the wall. I couldn't now, it would be too frustrating.

I've been doing a bit of collaboration with morfic with things I'm trying out, so you'll probably find some of my recent work in test Trinity kernels. We have a fairly similar development ethos, slim, fast and no bullshit, so it works well. The fact he isn't a cherry-picking, feature list wanking moron certainly helps. :)

My personal plans are to do more kernel development with 'proper' Linux on development boards such as the PandaBoard. Much of this work will likely be able to be used in Android kernels. This will also mean I will be able to develop with the latest versions of the Linux kernel instead of being constrained to older versions.
Anyone fancy buying me a Versatile Express? ;)

Current development plans

  • ARM auto hotplug driver needs some work.
  • BFS for ARM SMP is currently broken and I would like to fix it as I believe it would be extremely beneficial to multi-core ARM devices.
  • Work on my personal NP an N7 kernels, although the NP one is pretty perfect as is and the N7 one just needs the ARM auto hotplug improvements.
Apologies for the long blah blah blah post, but I really needed to get the above off my chest.

By the way, I look forward to the abuse in the least I'll get a laugh out of it. :)

Friday, 10 August 2012

Future development plans…

I've made an executive decision to roll back to 3.0.31 for the next crespo (Nexus S) release and not apply any mainline patches. This will also give me chance to clean the garbage out of my git which I should have never carried over from the ICS kernel.

There are a few reasons for this:

  1. Mainline stable updates often introduce subtle issues/bugs. I can recall many bugs which have been introduced by merging mainline ‘stable’ code.
  2. They are of little benefit, if any benefit at all to our phones. If you look through a lot of the fixes in mainline stable, it's all for very large systems. All those 3.0.39 mm patches for instance, after looking through them all, they are all for huge systems and will not benefit our devices in the slightest.
  3. Mainline stable has become a complete farce, with far too much code being merged. There are far too many updates, there is far too much code churn. It is supposed to be stable, updates should be small, infrequent and well tested to fix critical bugs or security issues only, but that appears to have been forgotten, with new features being added, unnecessary code refactoring, and general churn that shouldn’t be happening.

My tests on maguro (Nexus Prime) show that between 3.0.31 and 3.0.40, boot time slowed by 4 seconds, which is approximately 15% on that device. This doesn't make me happy, and although I haven't tested specifically on crespo (Nexus S) yet because I’m still waiting for it back from repair, I expect the impact to be just as severe.

And this slowdown is for what benefit? Extra subtle bugs. Having the latest version number. Meh.

As regards user experience, the .31 kernel certainly 'feels' quicker than the .40 kernel on maguro, and 'feel' and perception is what it is about as far as I am concerned.

So, from now on, I won't be applying any mainline stable updates to any of my 3.0 based kernels, except patches for exploitable critical security vulnerabilities.

Latest is certainly not always best, especially when there is as much code churn as there is within the 3.0 kernel.

Saturday, 4 August 2012

Stable Nexus S kernel release 3.0.39-27 (ICS & JB)

So, finally another stable release. This is the first stable release for JB and will be the final release for ICS.

As per usual, my releases aren’t about pointless features. They concentrate on stability and performance.

The most interesting thing about this release is the memory management performance backports which were merged into 3.0.39.

Changelog compared to 3.0.36-14:

  • For ICS, base as is per 3.0.36-14. For JB, base is AOSP 3.0.31 merged up to 3.0.39 from mainline.
  • Various other compiler warnings have been fixed
  • Interactive governor with interactivity boost now in use instead of ondemand as it provides a smoother user experience on JellyBean and apparently also on ICS.
  • Fixed a NULL pointer dereference in the i2c code which was causing occasional kernel panics for some users.


  • Deadline I/O scheduler adjusted for flash for lowest I/O latencies
  • Config: As stock AOSP with the following modifications: Deadline I/O scheduler, Interactive CPU governor, Tiny Preempt RCU, Voodoo sound, cifs, utf8
  • Wifi PM_FAST for bcm4329 (ICS) and bcmdhd (JB)

Features not implemented for this release:

  • IDLE2 – although the code / implementation is stable, there are some issues with the actual powersaving which is being attained, or not, as the case may be due to a bug which I haven’t found yet. Bricking my Nexus S didn’t help with that either, so IDLE2 development is paused until I get by Nexus S back from repair

ICS, JB and i9023 version available here.

Saturday, 28 July 2012

Test Nexus S kernel release 3.0.38-25 (ICS & JB) – IDLE2 v0.212

Quick post, bugfix update:

  • Fixed issue in IDLE2 causing ANR in systemui and subsequent soft reboot when turning screen on after being in call or playing music.
  • Fixed issue where some users with a specific AMOLED panel would get a yellow / green tint.

3.0.38-25 kernel releases for ICS, JB, JB-i9023 & JellyBelly available from here.

Thursday, 26 July 2012

Test Nexus S kernel release 3.0.38-23 (ICS & JB) – IDLE2 v0.210

So, another test release.

Short changelog this time, the main improvement is IDLE2 v0.210 which implements the DEEP-IDLE TOP ON state for use when bluetooth or GPS is active. This should hopefully bring some power savings in those situations, but your mileage may vary.

I also implemented a load of micro-optimisations of variables and functions in the idle2 code to hopefully speed up the hot paths even more and make them cheaper.


  • Interactive governor boost enabled and set as default
  • IDLE2 v0.210
  • Version provided for i9023 users which contains the patch from codeworkx which should fix the CRT off animation


Update: Please use –24 instead, –23 has been removed due to a bug which is fixed in –24 which is available here.

I will write a blog post shortly detailing the bug and changes in –24.

Wednesday, 25 July 2012

Test Nexus S kernel release 3.0.38-22 (ICS & JB)

So, another test release for both ICS and JB.

This one includes my new implementation of IDLE2, which seems to work much better and save significantly more power than the last one.


  • Adjusted ondemand tunables to make ramping up occur faster for better responsiveness.
  • Implemented bigmem hack which should work on all ROMs and give an additional ~50MB of RAM
  • Disabled the expensive KSM due to the above.
  • New implementation of IDLE2, enabled by default. Please see my previous post on IDLE2 for details.

Available here for ICS and here for JB.

And for anyone feeling adventurous, there is one here for JB with the interactive governor set as default with interaction boost mode enabled.

Source here as always.

IDLE2 v0.201

So, I have spent a lot of time recently thinking about how best to implement IDLE2.

I decided to do something which hadn’t been done before, and implement both IDLE states so they are available concurrently without having to ‘switch’ between them, as was being done previously.

I implemented 2 idle states, IDLE (which was already implemented) and IDLE2, which is better described as DEEP IDLE TOP OFF, referred to as IDLE2 mode from hereon in.

I spent a lot of time making the hot paths as cheap as possible, wherever possible using variables for storage and checking them instead of polling (expensive) functions. This has paid off with a doubling of the number of times the CPU enters IDLE2 mode.

I also implemented PM notifiers to disable IDLE2 mode when suspend is active instead of hooking into the suspend sequence. However, due to the implementation, IDLE2 mode should never be enabled when the device is suspending, so it is just a failsafe.

Bluetooth caused me a massive headache, and although I have managed to partially solve the issue, I’m not entirely happy with the fix. Due to the way bluetooth works in ICS/JB, it is permanently enabled. This causes an issue, as IDLE2 mode is incompatible with bluetooth, enabling IDLE2 mode whilst the bluetooth is actively working breaks the link. The fix for this is a bit of a fudge. I added a hook to herring-rfkill to call a function when the GPIO_BT_HOST_WAKE goes high. This sets the external_active variable to true in cpuidle.c, which tells cpuidle to ignore the IDLE2 mode. When the gpio goes low again, a function is called which sets external_active to false, but it queues it for 60 seconds time. If another interrupt occurs, the queued inactive work will be cancelled and so on. This should work for the majority of bluetooth use cases. If the devices don’t ping each other every minute, I would be surprised. But, if this doesn’t work for you, IDLE2 mode can be disabled with a switch.

I implemented a hook into the audio subsystem so IDLE2 mode will not be activated unless audio playback has been active for 30 seconds. This choice was made to stop spurious activations of IDLE2 mode when there are system notifications, for example.

IDLE2 mode will now be activated under the following circumstances:

  • The disabled switch is not set
  • Audio playback has been active for 30 seconds
  • USB cable is disconnected
  • Bluetooth is inactive (see above)
  • Earlysuspend is active (screen is turned off)
  • Various clocks are gated and various subsystems are power gated
  • No interrupts pending

Added code to disable cpufreq and clamp the CPU at 800MHz when the conditions are right for IDLE2 mode to be entered. This appears to save significantly more power.

Codewise, many of the IDLE2 specific functions have been moved into idle2.h, to keep them separate from the standard cpufreq code. The asm has also been further cleaned up, with calls to the generic flush_cache_all() and cpu_do_idle() functions instead of using asm calls. The remaining asm is involved in saving and restoring registers for IDLE2 mode. Exit latency has been set to 400, which is what is stated in the S5PC100 TRM. Residency time has been reduced to 2000, as even going into IDLE2 for short periods is more efficient than using regular idle or not idling at all.

IDLE2 mode now has a disable switch, which can be activated with the following command:

echo 1 > /sys/module/cpuidle/parameters/idle2_disabled

As the IDLE2 state is now implemented concurrently with IDLE, info can be obtained from the standard cpuidle interfaces.

For normal IDLE these can be found here:


And IDLE2 can be found here:



I think that is all the improvements.

Patches v0.200 and v0.201 are available on my github which will need to be applied on top of all the rest of the IDLE2 patches.

My kernel, implementing IDLE2 v0.201, is available here.

I will squash them and release a standalone patch at some point in the near future.

Update: Standalone patch is available here.

Sunday, 22 July 2012

Test Nexus S kernel release 3.0.38-21 (ICS and JB)

Another test release, both for Android 4.0 (ICS) and Android 4.1 (JB) this time.

Status of ICS support is that it will be supported for another month, although I don’t expect many people to be using it because JB is far superior.


  • Disabled IDLE2 until I decide exactly how the invocation code will be implemented and get the implementation completed and bugfree.
  • Fixed a ton of complier warnings which had been irritating me for a while (21 commits in total).
  • Merged to mainline 3.0.38 and merged in android-common-3.0.

ICS version here.

JB version here.

Source: ICS JB.

Thursday, 19 July 2012

Test Nexus S kernel release 3.0.37-18 & IDLE2 v0.130

New test release today, following on from yesterdays IDLE2 release.

This release contains a bugfix for bluetooth audio streaming, which was broken when IDLE2 was entered.

The fix simply checks to see if the GPIO_BT_HOST_WAKE is high and if it is, it puts the SoC into TOP ON DEEP-IDLE mode instead of TOP OFF DEEP-IDLE mode.

Simply enabling bluetooth will not make you go into TOP ON mode. The bluetooth has to be active and doing something, such as streaming or otherwise communicating with another device.

The only other small change in IDLE2 v0.130 is the argument to s5p_set_idle2_lock() was changed from an int to a bool.

New kernel available here, IDLE2 patches available on my github.

Wednesday, 18 July 2012

Test Nexus S kernel release 3.0.37-17

So, a test release today, with something new, my idle2 port from Samsungs P1000 kernel. Read about that here.

There is no point in repeating what I have already written there. If you have any questions about the implementation, please comment in that post, but no stupid questions please, they will be deleted.

As 3.0.36-14 stable with the following changes:

  • idle2, which is a replacement for deep-idle.
  • Merged to 3.0.37 from mainline – nothing scary there.
  • Merged android-common-3.0 – just a wifi module bugfix.

Available here.

IDLE2 for s5pv210 SoC v0.122

As some of you will know, I have been working on a port of Samsungs IDLE2 / LPAUDIO feature from their 2.6.32 P1000 kernel to the 3.0.x i902x kernel.

This implements the same thing as deep idle attempts to do, but it has several benefits over the original deep-idle patch, as will be explained below.

I’m pleased to say that I am going to release the source and a kernel with it included today.

This release comes after a large amount of debugging of lockups caused by interactions with the coresight tracing driver and general other breakage, including some asm issues. I did get to a point where I couldn’t get it stable at all, I wasn’t getting any useful output from last_kmsg and I was almost about to give up, but thanks to a decent last_kmsg trace or 2 and gdb <3 I was able to find the problem, fix the issue and get it stable. :) Myself and several others have been running it for about 2 days now, so altogether we have probably amassed about 500 hours of testing, with no issues reported so far.

Differences / Advantages compared to deep-idle:

  • Enabled by default and automatically invoked whenever the conditions are right.
  • When the screen is on, the idle mode is set to NORMAL, which skips all the idle2 code and works as normal, so no change there.
  • When the screen is turned off (earlysuspend), the mode is switched to IDLE2 which is used when all the following conditions are met:
  1. PowerManagerService is holding a wakelock
  2. USB is not plugged in
  3. GPU is not running
  4. MMC & NAND aren’t in use
  5. DMA is clock gated
  6. Audio DMA is not in use
  7. No RTC interrupts pending
  8. It also checks the Vector Interrupt Controller status immediately before saving register state / calling WFI and bails if an interrupt is active
  • Cleaner code paths, optimised for the most likely scenario to save some cycles on branching. Many critical functions inlined to make their execution quicker and cheaper. Many int type functions modified to use the cheapest type possible, normally bool or void.
  • No expensive stat collecting sysfs interface chewing up cpu cycles. I know people will moan that this stops you seeing what it is doing, but, does it really matter if it is working? Just accept that it *is* working. If you really want to check what it is doing, recompile the kernel with the debugging messages enabled and it will spam dmesg with everything that idle2 is doing. :)
  • ASM modified to use existing generic platform cache flush and idle routines rather than duplicate them. Certainly more could be done here, and that is something for a future version, but I’ve made a good start at it.
  • It doesn’t require the CPU to be forced to an artificial frequency for stability. The CPU scales as normal and ranges 100 <> 1000 whilst idle2 is active.
  • DEEP-IDLE TOP OFF mode is default. TOP-ON is not used.
  • There is no requirement for the config_bluetooth_adapter_quick_switch disabling patch as it works perfectly without it.
  • Due to it being hooked into a wakelock, it cannot be invoked at the same time as suspend is called, so it has no way of racing with the suspend code.
  • It seems to be completely stable (so far anyway).

I think that is about it for the advantages, but as you can see, it is a worthwhile improvement.

To do:

  • More code cleanups.
  • Try to make some code paths cheaper.
  • Try to use generic platform asm or unify with platform asm.

Patches and improvement suggestions are welcome. This is one of the most complex things I have released, so there will be improvements to be made and suggestions and patches are more than welcome, specially for any of the todo items.

Wilful kanging, not clearly giving proper credits and not contributing back is extremely unwelcome. Open source is not about copying other peoples work, a principle which some developers don’t get, The GPL was never designed for the purpose of copying code verbatim and riding on other peoples work, it was designed to allow freedom of code, a continual cycle of improvement and peer review, so consider that please.

Tuesday, 26 June 2012

Stable Nexus S kernel release 3.0.36-14

So, another stable release. A few updates, a new base for the kernel and of course merged up to the latest mainline stable release. It should be faster and more stable, but there is nothing mind blowing here, except perhaps the addition of Voodoo sound by popular demand.

I spent lots of time benchmarking toolchains and kernel sources, and I’ve settled on the one which appears to be the fastest and most stable.

I also built non-essential drivers as modules so they aren’t in the zImage. This has the advantage of code not being loaded for features which aren’t being used by the majority of users. This has the other advantage that if users request a particular driver/filesystem/etc, I can easily add it as a module without affecting users who aren’t using it. Unfortunately, modprobe is broken as it looks for the modules in the wrong place, so you will need to load the modules with insmod, and they are located in /system/lib/modules

Wifi will also work now if installed on a CM based ROM, as they moved the module and broke compatibility with stock.


  • Third stable release, slightly different base this time. The kernel is based on AOSP common (3.0.31) with the AOSP Samsung kernel (3.0.8) patches applied on top. It has then been merged to 3.0.36 from mainline.
  • Voodoo sound v10 patches applied.
  • Wifi will now work if installed with a CM based ROM.
  • Moved cifs and utf8 from the zImage into /system/lib/modules
  • Various compiler warnings and section mismatches fixed
  • Disabled a stack of debug options resulting in a slightly faster kernel
  • Compiled with a FSF GCC 4.6.3 toolchain built with crosstool-ng – .config here for interested people.


  • Deadline I/O scheduler adjusted for flash for lowest I/O latencies
  • Ondemand governor adjusted to sample less at higher frequencies to reduce overhead
  • Config: As stock AOSP with the following modifications: Deadline I/O scheduler, Ondemand CPU governor, Tiny Preempt RCU, Voodoo sound
  • Additional modules provided: CIFS, utf8
  • PM fast for wifi


Available here.


Dismissed ideas:

If something appears on here, the answer is no, so please don’t ask for it again.

  • Interactive CPU governor – no improvement in responsiveness, but much more expensive in terms of CPU usage
  • Conservative GPU governor – worse responsiveness, higher latency, slower race to idle so in theory could result in higher power usage depending on usage model. Perhaps it is useful on older hardware, but it’s not particularly useful on our phones
  • Any other CPU governor – lets just cut to the chase, ondemand is the best and cheapest one I have tried. It also doesn’t involve maintaining non-mainline code, it is the one I like, it’s tried, tested, stable, works extremely well and is mainlined, unlike governor X, Y & Z
  • Linaro GCC – Surprisingly enough, Linaro GCC actually produces a slightly worse performing kernel than FSF GCC
  • CFLAG (compiler) optimisations – Tested various optimisations with various toolchains, none made any measurable improvement, some made the kernel perform slightly worse
  • Overclock – I did consider implementing some overclock, basically to improve the boot time more than anything else. After trying it, it made no significant difference so I decided it wasn’t worth the possible instability it could bring. Unfortunately, the hummingbird apps processor is still gutless, even with overclock
  • Voodoo colour – I considered this, but I don’t believe it adds value to the kernel. It’s not a necessary feature and there are plenty of kernels with this. As regards colours, I also tested reverting the change which was brought about in 2.3.3, but it left the screen with a blue tinge so backed it out again
  • BLN – it’s very hackish and totally unnecessary and certainly does not add any value to the kernel. Again, there are plenty of other kernels with this awful feature
  • Deep Idle – I’m not convinced that it is stable enough. It wasn’t implemented by Samsung/Google for some reason or other, lets just leave it at that

Sunday, 24 June 2012

Test Nexus S kernel release 3.0.36-13

Changelog (as –12 with the following changes):

  • Wifi will now work if installed with a CM based ROM (funky symlinking magic in the updater-script.
  • Moved cifs and utf8 from the zImage into /system/lib/modules – if you need these modules you will need to load them with insmod /system/lib/modules/cifs.ko etc (unfortunately modprobe doesn’t work correctly as it looks for modules in /lib instead of /system/lib). But CifsManager will do that automatically for you.

Known issues:

  • None

Tested and dismissed for this release:

  • Tested interactive CPU governor again, didn’t notice any difference with responsiveness of the device, but found that it was quite expensive in terms of CPU cycles, *much* more so than ondemand. I will stick with ondemand.
  • Tested change of colour temperature for Super AMOLED devices. Going to pre 2.3.3 colours made the whites very cold and blueish and the colours weren’t right at all so backed out of that change.
  • No, I’m not adding BLN. :p

Available here.

Saturday, 23 June 2012

Test Nexus S kernel release 3.0.36-12

So, I made a few decisions to make a few changes in the way I was developing the kernel:

Firstly, I have changed the versioning. The kernel version will be the additional digits at the end from now on. This will be incremented every time I make a release. I didn’t want to start at 1, so I counted up the number of releases so far, added a couple for good measure and started at that number. I will also be tagging the git repo before every release, test also as I will need to rebase more often due to the next decision I have made. The zip filenames will also change and will be based on the git describe output.

Secondly, I have decided to completely change the kernel base. Instead of using the (basically abandoned) AOSP Samsung S5PC110 kernel as a base and merging mainline stable updates into that, I have rebased it against AOSP common 3.0, which will bring in the improvements the Android team has made recently. It also brings the added benefit that there is much less mainline code to merge, as the common repo is much closer to current mainline. This should also make the kernel more stable and result in less fuckage, of which there has been more than enough lately.

Thirdly, I dumped the compiler optimisations which I applied last time, they really don’t make any measurable difference.

Fourthly, for the next stable release, I plan to build as modules any drivers / filesystems etc that are not essential to Android so they can be loaded as required. I will place them in such a place that modprobe will work correctly to load them without having to mess about with insmod. It seems somewhat counter intuitive to have a load of stuff built in to the image that not many people use, and it could theoretically be harming performance. The leaner the better eh?


  • Rebased against AOSP common and merged up to 3.0.36 from mainline
  • Dumped compiler optimisations
  • Voodoo Sound v10 is still here, don’t worry :p
  • Same Newlib based bare metal toolchain as previous release

Known issues:

  • None currently

Available here.

Sunday, 10 June 2012

Experimental Nexus S Kernel (3.0.34_r1) release


As 3.0.29_r1 stable with the following changes:

  • Voodoo Sound v10
  • Merged to 3.0.34 from
  • Compiled using a Newlib based bare metal GCC 4.6.3 toolchain, config here if anyone interested.
  • Some experimental compiler optimisations applied to Makefile: KBUILD_CFLAGS which increase benchmarked performance: -mtune=cortex-a8 -mfpu=neon -ftree-vectorize -floop-interchange -ftree-loop-distribution -floop-strip-mine -floop-block.
  • Optimised vfp code compilation: KBUILD_AFLAGS -mfpu=neon
  • Optimised PVR code compilation: -O2 instead of -Os

    Known issues:

    • None

    Available here.

    Monday, 21 May 2012

    Experimental Nexus S Kernel (3.0.32_r1) release


    As 3.0.29_r1 stable with the following changes:

    • Added Voodoo Sound v10
    • Merged to 3.0.32 from
    • Compiled using a custom built GCC 4.7 toolchain

      Known issues:

      • None

      Available here.

      This will become the next stable release in a couple of days assuming no issues.

      Saturday, 12 May 2012

      Experimental Nexus S Kernel (3.0.31_r1) release


      As 3.0.29_r1 stable with the following changes:

      • Added Voodoo Sound v10
      • Merged to 3.0.31 from
      • Compiled using a custom built GCC 4.7 toolchain

        Known issues:

        • None

        Available here.

        Friday, 4 May 2012

        Experimental Nexus S Kernel (3.0.30_r1) release


        As 3.0.29_r1 stable with the following changes:

        • Added Voodoo Sound v10 by popular demand and promising test results
        • Merged to 3.0.30 from

          Known issues:

          • None

          Available here.

          Sunday, 29 April 2012

          Experimental Nexus S Kernel (3.0.29_r2) release


          As 3.0.29_r1 stable with the following changes:

          • Added Voodoo Sound v10 by popular demand and promising test results.

          Known issues:

          • None

          Available here.

          Thursday, 26 April 2012

          Stable Nexus S Kernel (3.0.29_r1) release


          • Second stable release based on AOSP 3.0.8 source, merged up to 3.0.29 from mainline
          • PM Fast for wifi
          • Deadline I/O scheduler tweaked for flash for lowest I/O latencies
          • Ondemand governor tweaked to sample less at higher frequencies to reduce overhead
          • Config: CFS CPU scheduler, Deadline I/O scheduler, Ondemand CPU governor, SLUB allocator, Tiny Preempt RCU, Tun/Tap, IP advanced routing and CIFS built in
          • Various compiler warnings and section mismatches fixed
          • Disabled a stack of debug options resulting in a slightly faster kernel
          • Built with latest Linaro toolchain (GCC 4.6-2012.03)

          All in all, no major changes since the last stable version, only config changes. I've mainly just been keeping it in sync with mainline, of which there has been many point releases, and it's been merged with the 4.0.4 AOSP push too.

          Available here.

          GPL source code here.

          Wednesday, 25 April 2012

          Experimental Nexus S Kernel (3.0.29_r1) release


          • Merged to 3.0.29 from

          • Compiled with latest Linaro toolchain – GCC 4.6-2012.03.

          • Added some debug code back into the test releases to get better stacktraces when / if it falls over. Doesn’t really introduce any noticeable overhead.

          Available here.

          Monday, 16 April 2012

          Experimental Nexus S Kernel (3.0.28_r1) release


          • Merged to 3.0.28 from

          • Compiled with latest Linaro toolchain – GCC 4.6-2012.03.

          • Added some debug code back into the test releases to get better stacktraces when / if it falls over. Doesn’t really introduce any noticeable overhead.

          Available here.

          Friday, 6 April 2012

          Experimental Nexus S Kernel (3.0.27_r1) release

          It seems ages since I did a stable update for the Nexus S, but I’m waiting for the flux to slow down with the 3.0 kernel. It seems every week or so there is yet another ‘stable’ point release for it, which is getting old quickly.

          Still, it gives me something to do I suppose.

          So, 3.0.37_r1 experimental is todays release with the following changelog:

          • Added some debug code back into the test releases to get better stacktraces when / if it falls over. Doesn’t really introduce any noticeable overhead.
          • Merged to 3.0.27 from mainline.
          • Compiled with latest Linaro toolchain – GCC 4.6-2012.03.

          Available here.

          Thursday, 5 April 2012


          Yes, it still works. I hadn’t forgotten about it, it’s just the Oxygen forum seemed the easiest place to do releases.

          A new experimental Nexus S kernel will be released shortly, as 3.0.27 has been released. I will probably build it with GCC 4.7.0 also.