My kernel doesn't wipe your cache or dalvic, so you can flash and reboot in less than a minute. Read this.

What is MTP?
Firstly, huge props to krfoy for making this work with the any-kernel script. Great work!

Microsoft's Media Transfer Protocol. It allows for dramatically faster transfers too the phone, so it is really good when you are copying over films or mp3 folders. What's really good is that you can continue to use your apps while these transfers happen. Faster? More functional? You bet! The limitations are that it is relatively unsupported on non-Windows platforms. However, you can investigate these possibilities: Ubuntu: here. --- --- Mac: here.

Big thanks: ...to the community! So many people supported my research that it's impossible to thank them all individually. Particular thanks to tchaari and Harbb. Credit goes to: _thalamus for getting me started with git, correcting my misconceptions about merging; KalimochoAz for CM; ezekeel for the incredible variety of mods; mathkid95 for ondemand tweaks; steve.garon for help with scripting; morfic for his advice and permission to use his colour settings; and supercurio for voodoo. Big thanks to krarvind for MTP, legend! Congrats to krfoy for enabling MTP via the any-kernel script. Nice work! Thanks to caliban2 for his consistent and unbiased feedback. Thanks to brainmaster, when I originally joined the forums for being so helpful. Hopefully I treat newcomers just as kindly.

Download ICS version: v1.5b (For ICS 4.0.4)
NOTE: Opening AnTuTu breaks Deep Idle! If you have to use this app, disable DI until you can reboot.
Flashable Patch for BiggerMem: http://d-h.st/NSx

This kernel is based on the work of the cyanogenmod team:

Quote:

Cyanogenmod base features:
- Merged to 3.0.39 from mainline.
- Voodoo sound v10
- "Biggermem" 404MB (morfic's idea if I remember right)
- BLN
- SLUB memory allocator*
- Deep Idle:- Kalim included code that limits the maximum frequency to 800MHz when DI is active. Great innovation Kalim! I have modified this code to fix the screen off frequency to 400MHz for efficiency.

I have enabled the things I like:
- CFQ scheduler. It's a tiny notch down from deadline in performance, but very consistent. Kalim disabled it in the nightlies where I got my base configuration, so I've brought it back.
- Deadline I/O scheduler adjusted for flash for lowest I/O latencies (thanks thalamus)
- BLX
- BLD
- Voodoo colour
- Gamma settings by morfic, thank him for giving permission
>>> Try these settings in Voodoo: raise all gamma to 20, then set RGB to 189-185-214
- SmartassV2 governor*
- Deep Idle locks to 400MHz regardless of your governor settings. This is an adaptation of kalim's code. Why? Because I proved that 400MHz is the most power saving state for Deep Idle. Excerpt from research: here.
- Removed pointless governors
- Removed noop scheduler
- Removed OC and custom voltage
- PM_FAST (fast wifi with screen off: power saving for downloading files, but slightly higher power use when idle compared to PM_MAX)
- 1.2 GHz step
- v0.6 onward have MTP working for ROMs that support it. Krarvind is the one who made this work (donate to him here), with the help of another dev, so kudos to them.

Version History
v1.5b: http://d-h.st/BhK
-Morfic's colours fixed!
-Merged to 3.0.39
-DI fixed at 400 MHz, the most power saving state, using thalamus' code, which is stable!
-ICS ONLY!!

v1.4d http://d-h.st/66r (ICS ONLY)
-stable
-probably last version I'll do for ICS
-DI fixed at 800MHz
-reorganised fixed DI code a little
-If you have no video on MIUI, check out this tip!

v1.4b http://d-h.st/l7X
-Made some code reorganisation based on thalamus suggestion
-Created a patch!

v1.3c: http://d-h.st/HJY
-Stable
-Minor bugfix release (bugs in freq stepping that were my own faulty code merges)
-_thalmus' DI patch
-If you have no issues with 1.3b skip this, and wait for v1.4

v1.3b http://d-h.st/n55
-Frequency stepping bugfix
-Stable (I really mean it this time ) ...so I deleted the other download links, apart from the early _thalamus based one.
-Shrank the download to a normal size: I'd forgotten to remove the redundant zImage from the any-kernel script. (I don't use that since I flash a boot image).

v1.3
-thalamus' mutex to spinlock patch has been integrated. I've tested this, as I'm sure thalamus has, and DI of course still works fine, but because this is the first time anyone has touched the DI code in a few months, I think it's safer to call this a TEST release.
-I fixed the minimum fq getting stuck 200MHz issue, which was an issue actually caused by myself: when I was altering the available OC I failed to adjust all the levels correctly.
-Having trouble with 200MHz? >Read this<

All previous releases have been pulled. Use the current stable please! Remember: enjoy marmite!

Big thanks: ...to the community! So many people supported my research that it's impossible to thank them all individually. And big thanks to the developers who have selflessly helped a total noob get his kernel off the ground. Credit goes to: KalimochoAz for representing cyanogenmod in this forum and his tweaks; _thalamus for his patience and getting me started with git and modules, correcting my misconceptions about merging; ezekeel for the mods; mathkid95 for ondemand tweaks; steve.garon for help with scripting; morfic for his advice and permission to use his colour settings; and supercurio for voodoo. Big thanks to krarvind for MTP, legend!

In that spirit, I'm going to attempt to write a plain-English tutorial on what to do to build this kernel. In fact, change one or two URLs, and you could build practically any kernel!

Note: I'm assuming you're on a PC here. I'm also assuming this isn't your first trip to linux-land, and you've at least used the terminal a few times before now. I'm also going to assume that even if you are a noob, you're not mentally sub-normal.

Note2: If this is your first time building a kernel, you may want to print this out, and go slowly, and if you get stuck, post about it in the thread! It will help me improve the guide.

Quote:

What makes this different to other tutorials?

I'm a noob at building, but a professional at teaching. It's literally my job! In my noobishness, I made good records of pretty much every step, and I've got lots of time for explaining what each step actually does.

THE STEPS

Quote:

Got a computer?

You'll need one to compile stuff. "For Gingerbread (2.3.x) and newer versions, including the master branch, a 64-bit environment is required." (source)

OK. You're probably thinking of compiling a kernel for ICS or higher right? Is your computer only 32 bit? Pull the processor off the motherboard and count the pins. Just kidding. It won't matter if it is AMD or Intel, but it needs to be a 64 bit processor. I can compile a kernel with just 2GB of RAM and my processor is approaching its 9 year. Even with this lousy set-up, compiling a whole kernel from scratch takes only five minutes.

Install Ubuntu 10.04 64-bit. (Click on this link to download the install CD.)

If you've got a spare hard drive, use the whole thing. If you're good at partitioning, you might consider putting the linux swap partition on a separate disk. You'll want it to be at least 8GB. Putting it on a separate disk will speed things up.

If you don't have a spare disk, you're going to have to resize a partition of an existing OS, to make some new space for Ubuntu. Lets say a minimum of 12GB for the OS plus 8GB for the swap. The more space you can give to the OS, the easier your life will be if you're serious about building stuff.

At the end of the installation it will ask to install a boot-loader. This should be on sda (not sda1!) but you may need to adjust your BIOS to point at the right hard-drive if you later find it doesn't boot into Ubuntu when you restart. Don't worry about Windows, Ubuntu provides a boot menu, so you have the option of booting to Windows instead.

Once Ubuntu is installed, reboot then open a terminal and sort out your credentials:

Code:

sudo passwd root

Type in the password you set during the install, then decide on a password for the root user, and enter it once, then again for confirmation. It can be the same as your user password if you like.

Do some updates (this could take a while):

Code:

sudo apt-get update && sudo apt-get dist-upgrade

When it's finally finished, you'll have to reboot, then repeat until there's no updates left.

Quote:

You're ready to set up a build environment!

First, you need a whole bunch of packages. You could copy and paste this into your terminal:

Follow this link to Mentor Graphics Sourcery CodeBench LITE and do a free signup to get the download link. You can get hold of other ones, like Linaro or Google's own, but I'm using this as an example, because it's the one I use, and Ezekeel published some R&D here that showed there was no measurable benefit to one toolchain over another.

Note- Obviously that's not the actual name of the file! But you can see what it's really called when you download it.

Now go to /opt and unpack it:

Code:

cd /opt
tar xjf arm-some-date-some-version-some-arch.tar.bz2

Quote:

So I've got all the tools. Now what?

So now you need to get some source code. You can use 'git clone' if you don't plan on publishing your kernel. But if you've made some modifications and want to share your end result, you need to obey the GPL terms for the linux kernel, which is Open Source, meaning that you are required to make your source available publicly.

Go to github: https://github.com/
...and sign up. It's just a free registration provided you are non-commercial. Github has some useful getting started tutorials, which I suggest you follow:https://help.github.com/articles/set-up-git
(just follow that first page for now. I will walk you through git in a bit...)

Next, fork a repo:
Go to whichever kernel you like: https://github.com/bedalus/bedalusKERNEL
I'm using mine as an example. Look for the big 'Fork' button.
You've now got your own copy on github, and you can do whatever you like with it, without affecting the original.

However, it's no use if it exists only in the cloud. You need to get a local copy. You'll also want something called a 'remote tracking branch', which will enable you to keep up-to-date with the changes going on in the original repository that you have forked-off from.

Quote:

Critical Step:

Shout 'fork-off!' at the top of your voice.

Uh... okay. Now, to get a local copy, and set up your remote-tracking branches, execute:

Code:

cd /home/<username>/
mkdir mykernel

...you can name your new directory whatever you want. It doesn't have to be 'mykernel', then:

Code:

git clone https://github.com/<your github username>/bedalusKERNEL.git

In the above, put your git username, and substitute bedalusKERNEL.git for whatever your fork is called. You can actually copy and paste the URL from the top of your new github repo's page if you want.

It's going to download about 800MB if I remember correctly. This will take a while, so go have some marmite on toast.

The 'git remote add upstream' creates a new branch called upstream, and any changes that the original developer uploads to github can be fetched to your machine with the 'git fetch upstream' command. Notice how this time, the download time is much shorter? That's because of 'delta downloads' which only downloads the differences between what you have, and what they have. (There's some technical detail here.)

Quote:

Git Tip No. 1: What branches do I have?

You can now enter:

Code:

git branch

...to see all your branches. At this point there should be 'origin' and 'upstream'.

Quote:

Git Tip No. 2: How do I change branches?

Changing branches (you might as well do this now just to have a little go):

Code:

git checkout upstream

That will move you onto the upstream branch, as long as you haven't made any 'uncommited' changes in origin. (More on that later.) Change back to origin with:

Code:

git checkout origin

Quote:

Git Tip No. 3: How do I rename a branch?

You might want to rename your branches to help personalise them, just to make remembering which is which a little bit easier. To change origin to 'my_version' do this:

Code:

git branch -m origin my_version

You can change upstream to 'their_version' or something else if you want to. It won't stop anything from working.

More Git Tips later. Let's sort out a build script. If you tinker with any code, you'll inevitably break stuff, and need to fix it, and then need to try building again... So, having a build script is going to save you a lot of time, because there are several steps that can be automated.

This is just a little precaution that I put in to give myself the chance to abort the build before it starts if I'm on the wrong branch. If I don't hit y then the script aborts, and I can checkout the right branch, then restart the script.

Code:

echo -e "\nSTARTING...\n"

The \n prints a new line, then on that new line the message 'STARTING...' and then begins another new line. If you put \n\n you can print a blank line. The echo command is a good way of putting notices in a script so you know what stage it is at.

If you put these lines in your script, it sets 'environment variables' that tells the make program where to find the compiler, and what processor it's compiling for (ARM).

If you now save your script in the /mykernel directory you created earlier, git can keep track of it as well as the files integral to the kernel. Save it as whatever you like, e.g. "myscript.sh"
...It's important to have the .sh extension so the system knows it is a script.

To make your script executable, run:

Code:

chmod a+x myscript.sh

Before you execute the script, you need a .config file in the mykernel directory. If you've cloned my repo, you can get a working one by executing:

Code:

cp arch/arm/configs/crespo_release_defconfig ./.config

...this command will only work properly if you are in the mykernel directory when you execute it.

You can mess with this config file if you like! But it's very easy to break the kernel. However, you can always just copy the crespo_release_defconfig again.

Now, to execute the build script run:

Code:

./myscript

If you execute your script, your compiler will now build the kernel. It will take time, but even on my ten-years-old PC it takes less than ten minutes from scratch.

The compiler will spit out a lot of messages. Most of the time it's telling you that it has compiled an object (i.e. a .o file, which will all be linked up later to form the kernel) and sometimes you'll see warnings, which is the compiler telling you it thinks something might be wrong. Don't worry, most of the time the compiler is just being over-cautious.

If the compiler hits a real problem with the code, it will print an error, and tell you what file, and what line, and how far along that line it managed to get to before it didn't know what to do. I'll get back to this later. For now, let's assume everything compiled.

You'll see a message about the zImage being created. That's the kernel. You can't use it as it is, you need to put it into a boot.img so you can flash it.

I find it useful to add this command in my build-script:

Code:

ls -l /home/dave/mykernel/arch/arm/boot/zImage

ls -l means list with long format. It'll print out the entire contents of a directory with size, time, permissions, etc. if you execute it in a directory, or point it to a directory. However, in the command above, I've pointed it specifically at the zImage file, so it only prints out the details for that. This is so I can check the time. If the time is from yesterday, I can see quickly that there has been an error in the build, and the zImage is still the same one I built yesterday, or an hour ago... etc. depending on the time-stamp printed out.

If you get a 'No such file' error, it's because there is no old zImage, because you haven't ever successfully built one yet.

If you sat and watched the entire thing build, then the timestamp should show the current time, minus a few seconds.

Quote:

How do I make this zImage into a CWM flashable .zip file?

Yay! You've built a kernel. Now you need to make everybody else flash it to their phones too

To do this you need to put it into a boot.img, and then into a .zip file.

It's a small download. It's some very simple tools that can split an existing boot image into a ramdisk and zImage, and can also stitch them back up.

Move mkboot.zip into your mykernel folder, right click on it, and select 'Extract Here'. You can now delete mkboot.zip. There is a tool called unbootimg, that can take apart existing boot.img files, I've made things simple by including my own ramdisk, which is compatible with AOSP and CM ROMs. That file is called cyan2disk_new.cpio.gz

We now need to add some new stuff to the script to stitch our zImage and ramdisk together.

If you've not already added the ls -l command I mentioned above, also add this now. Then:

Remember, your username is not dave! Unless it is. Make the appropriate changes to the path.

Quote:

How do I make the CWM flashable .zip file?

We're nearly there! This bit is relatively painless. At this point you could save and run the script to check that mkboot is working. If it has worked you can use the same ls -l trick from before, but this time target the boot.img file you just created. If the time-stamp is fresh, it means your boot.img is correct.

TIP: If you haven't switched branches, or run 'make clean', all your .o files are unchanged. The make program keeps track of changes, and only recompiles .o files when the corresponding .c file has been altered. If nothing has changed, your build script will execute very quickly!

To make a flashable .zip file, the easiest thing to do is modify an existing .zip file. You can download my kernel for simplicity, since it already has the necessary script for flashing the entire boot partition. (Most kernels here use koush's any-kernel script, which updates only the zImage and keeps the boot partition's existing ramdisk, so if you try to use another kernel .zip as a template, make sure you correct their updater-script. Using my ramdisk and kernel script will also ensure you keep MTP!)

Once you've downloaded my kernel you should extract it in your home folder, then rename the directory to something like 'myzip'

"What's that second line? With the .ko file?" I hear you say. Depending on what modules you build, you'll need to copy all of them to the folder specified above. Fortunately, when the kernel finishes building, it tells you what modules have also been built. If you don't want modules in your kernel, you can remove the second line above. However, you must edit your .config file: Open it in gedit, use CTRL+F to open the find dialogue, then type "=m" Now, change every one you find into a "=y" ...so now instead of building modules, the kernel will now incorporate all that code into the zImage instead.

Finally, add this line to your build-script:

Code:

7z a -r -tzip /home/dave/mykernel.zip /home/dave/myzip/*

Run the script again. if everything has gone smoothly, then you now have a flashable .zip in your home directory!

Congratulations!

* * * * * * * * *

Quote:

More git tips!

I've compiled a list of commands you may find handy when getting to know git.

Restore to a particular point
(IMPORTANT! Don't do this if you've already pushed your commits to github!)
git reset --hard <sha1 hash>

Restore to your last commit
git reset --hard HEAD

Restore to one commit before your last commit:
git reset --hard HEAD^

Restore to two commits before your last commit:
git reset --hard HEAD^^ (etc.)

As long as you haven't pushed to github,
squash all your recent commits into one:
git rebase -i <sha1> ...then change push to squash (or fixup) for all except the first one
git rebase -i --abort (to abort!)

Delete a remote branch
(WARNING: This will delete the entire branch from github
Note: You cannot do this to the default github branch, but you can change the default branch in the admin tab on the website)
git push <repo_name> :<branch to be deleted>

Quote:

General tips! File management, searching... etc.

Find a file (useful for troubleshooting in some situations)
find /home/dave/ -name 'buildlean.sh'
(searches the home folder and subdirectories for 'buildlean.sh')

I've decided to attempt to build my own version of thalamus' kernel with some mods.

If I'm not too retarded, hopefully i can achieve this in the next few days.

As a result of learning to manage git and c, I'll have less time for forum posts.

This is good news, Dave. I've been hearing a lot of good things about the new stable release of thalamus in the thread for his kernel that I've been moderating. However, a lot of people including me will be missing BLD and BLN so it's nice to see how it would perform with these mods. With those two plus Voodoo sound that's already cooked in the last release, this may be a kernel to be reckoned with. Cheers!

XDA Developers was founded by developers, for developers. It is now a valuable resource for people who want to make the most of their mobile devices, from customizing the look and feel to adding new functionality.Are you a developer?