[Tutorial] Building Your First Kernel

Search This thread

thewadegeek

Senior Member
Mar 20, 2011
696
869
Cedar Rapids
Preface

OK a lot of people have been asking about building kernels, so here is my best shot at a tutorial. I want to preface this all by saying I AM NOT A DEVELOPER. I am a hacker and modder at best, I like doing my own thing, fiddling, and learning what I can, but I don't claim to know/understand everything about the process of building a kernel. You guys shouldn't expect my little walk through here plus another person’s source to make you a "developer", all it will prove is that you can copy/paste. ;) Also if you follow this guide, I am not responsible for anything that you may do that results in destruction, death, or other negative side-affects. You really shouldn't be messing with this stuff unless you know what you are doing, or doing a LOT of research along the way.

However please use this guide as a springboard for knowledge, to give you some key terms to google, to turn on those lightbulbs in your head and get those gears churning.

Note: This is not a newbie's guide to Linux. Before you post your question please look at it. If it involves the syntax of the command/what a command does you need to do your own research elsewhere before attempting to continue with this guide.

Step 1. Build Environment
A. Install Ubuntu 12.04(Not holding your hand here, if you can't do this you shouldn't be messing with kernels)
B. Required packages: git-core, gnupg, flex, bison, gperf, libsdl-dev, libesd0-dev, libwxgtk2.6-dev, build-essential, zip, curl, libncurses5-dev, zlib1g-dev, ia32-libs, lib32z1-dev, lib32ncurses5-dev, gcc-multilib, g++-multilib, and Adb.
C. Open a terminal
D. Type "mkdir android"
E. Type "cd android"
G.Type "mkdir kernel"

The above steps explained:
A. Installing a linux distro. You could really install any Linux distro(Arch = epicness :p) however Ubuntu in my eyes is the easy to use and install, and widely supported.
B. Installing needed packages. I believe are these are needed(I'm sure someone will correct if they aren't), these are just the one's I was told I needed the first time I built CyanogenMod. No I can't tell you what every single package does, it is your job to research and figure that out.
C. Ummm...duh?
D-G. Building a directory structure that will help keep us organized. The "mkdir" command creates a directory, and the "cd" command moves you into that directory. You could also combine these steps using the command "mkdir -p android/kernel", however I left it broken apart up there to enforce the typing bit of this. The more you type these commands the more familiar you will become with them.


Step 2. Your Source
A. Open your Terminal Prompt
B. Type "cd android/kernel"
C. Type "git clone git://github.com/DooMLoRD/android_prebuilt_toolchains.git toolchains"
D. Now comes the tricky part, you need to have some-type of source for your kernel. Check the following two sites for your device as appropriate. Once you have it download it is extracted/cloned into a folder in your kernel directory.

http://www.htcdev.com/
http://opensource.samsung.com/
http://developer.sonymobile.com/wportal/devworld/search-downloads/opensource
http://www.lg.com/global/support/opensource/opensource.jsp

The above steps explained: Ok all we are doing here is grabbing some tool chains and the kernel source.
A. Ok...you got this one! ;)
B. Moving into our working directory
C. Grabbing DooMLoRD's very handy pre-built toolchains. What is a toolchain? Check this out http://en.wikipedia.org/wiki/GNU_toolchain. These toolchains are unstable, and as such they aren't completely endorsed yet. They are the versions I use though, and if you would like to use the stable version(4.5.3 as of 07/06/12) you can find links with Google.
D. I typically put my kernel in a directory like "~/android/kernel/<devicename>_<androidversion>_kernel" but that's just me.​


Step 3. Modifications
This is the part people are curious about, they want to make modifications to the kernel to make it "special". Start all these from the root directory of your kernel source.

Mod 1. Applying a patch
A. Download the patch you wish to apply, in this case this one should work.
B. Save that file as "kernelPatch" in your kernel directory.
C. Open a Terminal
D. Move into the root directory of the kernel you wish to patch.
E. Type "patch -p1 < ../kernelPatch"

The above steps explained:
A. Pretty simple, I mean we need a patch. The patch itself is quite simply a diff between the original kernel source tree and the source tree containing the changes. I'll post a quick tutorial on how to create a patch in the third post. The patch above contains multiple governors to be added to your kernel.
B. Self-explanatory
C. Self-explanatory
D. Self-explanatory
E. Basically we run the patch command on our source using the patch we downloaded previously. The "patch" portion is the binary itself, the "-p1" option allows you to control the number of forward slashes to remove from file paths(You'll need to look at this option more if you are using weird directory structures or applying the patches from a odd location). The "<" operator directs the content of our "../kernelPatch" file into the command.
Mod 2. Adding a Governor Alone
A. Open "drivers/cpufreq/Kconfig"
B. Add the following lines in appropriate spot amongst the other govenor's

Code:
config CPU_FREQ_DEFAULT_GOV_SMARTASS
            bool "smartass"
            select CPU_FREQ_GOV_SMARTASS
            select CPU_FREQ_GOV_PERFORMANCE
            help
              Use the CPUFreq governor 'smartass' as default.

Code:
config CPU_FREQ_GOV_SMARTASS
           tristate "'smartass' cpufreq governor"
           depends on CPU_FREQ
           help
             smartass' - a "smart" optimized governor!
             If in doubt, say N.
C. Open "drivers/cpufreq/Makefile"
D. Add the following line in the appropriate spot.
Code:
    obj-$(CONFIG_CPU_FREQ_GOV_SMARTASS)     += cpufreq_smartass.o

E. Create a file called "drivers/cpufreq/cpufreq_smartass.c"
F. Put the following code in that file.
http://pastebin.com/f0Bk9kVZ
G. open "include/linux/cpufreq.h"
H. Under the "Cpufreq Default" section add
Code:
#elif defined(CONFIG_CPU_FREQ_DEFAULT_GOV_SMARTASS)
extern struct cpufreq_governor cpufreq_gov_smartass;
#define CPUFREQ_DEFAULT_GOVERNOR (&cpufreq_gov_smartass)

Ok there is a governor added, do the exact same steps for any other one's you would like to add.

The above steps explained:
A. Just opening a file, you guys have this. The Kconfig ties into our "make menuconfig" command later, making our mod a selectable option.
B. Adding the appropriate code for our governor to get it in our .config file. The first chunk would allow us to set our governor as the default one for our kernel, the other allows us to totally remove or add it to the build as we wish.
C-D. This step tells the linker to tie our module in with the rest of the code.
E-F. Creating the actually governor itself, don't skip this step. ;) I would suggest reading through this and trying to understand how it works, it's some pretty awesome stuff.
G-H. Open a file and add the code needed to tie our module into the rest of the source. Without this we would not be able to compile due to the rest of the source not knowing our module exists.​

Step 4. Getting a Config file

Option A. Pulling a config file from a kernel.
A. Hook up a device that is using a kernel similar to one you are using as your base.
B. Open a terminal
C. Change to your root kernel directory
D. Type "adb pull /proc/config.gz"
E. Type "gunzip config.gz"
F. Type "mv config arch/arm/configs/<your_config_name>_defconfig"

The above steps explained:
A. This will allow us to pull a base configuration file from a known working kernel. It makes it a lot easier to start out and let's us take baby steps through the whole process. As a note though not all kernel's support this, so you may have to try a few different one's to get it working. If that doesn't work, see option B.
B. Hehe, you are getting good at this step
C. Navigate to the uppermost directory of your kernel source.
D. Use adb to pull a copy of a working config file to use as your source.
E. Unzipping the config file.
F. Moving the configuration file you pulled to the config directory so we can reference it later.
Option B. Using the manufacturers config.
Unfortunately as stated above, not all kernels support the "/proc/config.gz" method. You can typically find a manufacturer's configuration file in "arch/arm/configs". I believe the one for my HTC Flyer was called "flyer_hc_defconfig", so look for a layout similar to that one. Also read the README to get a better idea of how to modify it. I would personally make a copy of it called "<your_config_name>_defconfig" and use that as my base.
Step 5. Building

Time to start the real "build" section of this tutorial.
Part A. Pre-build Steps
A. Open terminal and change to the root of your kernel directory
B. Type "export ARCH=arm"
C. Type "export CROSS_COMPILE=~/android/kernel/toolchains/arm-eabi-linaro-4.6.2/bin/arm-eabi-"

Part B. The First Build
A. Type "make <your_config_name>_defconfig"
B. Type "make menuconfig" and make the required changes to use any modules you added or similar changes.
C. Type "make -j<maximum number of jobs>"

Part C. Re-Builds
A. Type "make clean"
B. Type "make oldconfig"
C. Type "make -j<maximum number of jobs>"

Part D. Building Modules
You have two options:
A. Type "make modules"
B. Type "make path/to/your/module.ko"

The above steps explained:
Part A.(These steps are required every time you close your terminal and re-open it to build again.)
A. Ok shouldn’t need to explain this.
B. This command sets your target architecture.
C. Defines the path to the toolchain we are going to use to compile our kernel. You can change this to point towards whatever toolchain you have downloaded or feel like using, the way it is currently configured it will use the Linaro toolchain that we downloaded above.

Part B.(These only need to be run the first time you build a kernel.)
A. Load's your configuration file from earlier.
B. Open up a menu to configure your kernel. It will use the config file you loaded in the previous step as a base.
C. Viola start the build. I typically allow 1 job per core, so on my quad core machine I put "make -j4". Just raising that number will not make your build faster, your processor needs to be able to support the number of jobs you are assigning it.

Part C. (Use the command's when you are building any-time outside of the first)
A. This command gets rid of any old/outdated binaries or modules you compiled before, and let's start fresh. I like to run it every I build unless my changes are really small and localized.
B. A very awesome command, it parses through what has changed and only prompts you about new options.
C. See the explanation for the above "Part C.".

Part D.(Use these for just building kernel modules.)
A. This will re-build all modules.
B. Will rebuild just the module you need. Very useful when you need to rebuild a WiFi module.​

Step 6. Now what

Ok we have now started our build and we are waiting for it to finish, so there are two possible outcomes:

Outcome A. Build Succeds

W00t!! You have a kernel built by your self from source. There are a couple things you need in-order to use this kernel on your device any ".ko" modules and the zImage binary. If you pay attention to the output of your compiler then you will see the location of those objects. However the following commands will make your life a bit easier(Thanks Recognized Developer Hacre):
A. Open a terminal
B. Change to your root kernel directory
C. Type "mkdir ../<your_kernel>_output"
D. Type "cp arch/arm/boot/zImage ../<your_kernel>_output/zImage"
E. Type "find . -name "*.ko" -exec cp {} ../<your_kernel>_output \;"

The above steps explained:
A-C. Self-Explanatory
D. Move our kernel binary into our output folder
E. This handy bit of magic finds all ".ko" modules and also copies them into your output file.

You will also need to assemble a kernel image containing a initramfs for your device, along with the kernel binary and such. That however is beyond the scope of this tutorial. To get started though try searching the following phrases.

Code:
building android kernel image
xda build kernel image
xda unpack boot.img
Outcome B. Build Fails

Oh dear. It failed. Well guess what...this is going to happen..a LOT. Get used to it, and get used to googling and experimenting with different solutions. The following are some tips that will help you with debugging your issues.
Running a "Clean" build
A. Backup your config file(Type "cp .config ../backupConfig")
B. Re-run the build process using just your defconfig from earlier.

Limiting Output(Thanks Hacre.)
A. Another good tip is to run "make -j1" to get the error, as it will limit the amount of text you need to scroll through.​
Credits
Hacre-Feedback
cdesai-Feedback
Leedroid-Being willing to answer a noob's question's ;)
Doomlord- Having such handy Git repo's :)

Enjoy. That's all it takes to build a kernel, it's actually rather simple. I will try to answer what questions I can in this thread, and continue to add to it.
 
Last edited:

thewadegeek

Senior Member
Mar 20, 2011
696
869
Cedar Rapids
Please Read. The GPL is VERY important.
The Rules as they apply on XDA

As XDA has no legal power to uphold the GPL (and frankly we want to stay as far away from doing so as possible), we can’t force any of our users to abide by the GPL. However it is in XDA’s interests as well as the interests of our developer-base to ensure all GPL-derived materials hosted or linked on XDA comply fully with the GPL.

GPL-derived materials that do not come with the complete sources used to compile the GPL components are considered warez, and will be treated as such under forum rule 6 and 9.
If you use GPL components, but do not make any modifications to them whatsoever, you should provide a link to the original source of your GPL code.
Sources accompanying a release should be complete, and contain all the necessary source code for any modules, scripts or definition files. Complete sources will be defined as those which compile correctly and completely against the platform for which the software is distributed, and which contain any and all modifications made to the released General Public Licenced code. The source code supplied should be the exact version for which the source code is being requested, complete with all modifications.

EXAMPLE: Here’s a bit of code that could be used as a template to post your releases

<Kernel Or Author Name> <Kernel Nr>:
<Source>|<ReadMe>|<Credits>|<Other>

The Very Quick Summary of General Public License (GPL)

The text of the GPL Licence itself will be used to reach any final conclusion regarding any disputes over GPL Licenced materials. The above is a summary of what XDA expects of members using GPL code, and the complete text can be read at the GNU website.



The GPL states that anyone who modifies GPL licenced code is required to make available the sources used to compile it. This is to further improve and encourage collaborative work, as well as to ensure that the best code possible is produced, and to encourage peer-review of all work. This benefits both developers and end users in numerous ways, including:

Allowing anyone to verify the code they are trusting with their data, and its authenticity
Encouraging community collaboration to produce faster fixes and updates, and better code
Helping bring new developments from other devices and fields to your own, letting you benefit from new code that wouldn’t have been available without this sharing.
The GPL imparts great freedom for GPL end users. It ensures innovation is never stifled and no project is dependent upon any single developer.

It is in everyone’s interest for the GPL to be adhered to, as it gives us all better ROMs, better transparency, and a better atmosphere for developers to work together to make great code.
 

mDroidd

Senior Member
Aug 27, 2011
1,844
1,362
mappz-development.com
Oh find, grep, and sed are all one's I use on a regular basis, we could add a quick walk through on repo/git, maybe vi. And come to think of it talking about shell scripting would probably help out as well, it's pretty commonly used for tweaking around here.

A while ago I wanted to add a BASH guide. I think that it will be greatly appreciated if you create a guide for it.

If you need any help, just PM me ;)

Remember to post 8 "reserved" posts if you create a guide for feature expanding

Sent from my Galaxy Nexus using Tapatalk 2
 

zainthesnipe

Senior Member
Jan 8, 2011
362
40
Mississauga
definatly want to do this!
one question though how can i get source from lets say FXP's github? i keep getting stuck there
like what directory do i need? staright to the kernel file the have or what/? if thats a yes what directory is it?
this is the git hub https://github.com/freexperia

ur help would be greatly appreciated
 

zainthesnipe

Senior Member
Jan 8, 2011
362
40
Mississauga
sorry it was arc or "anzu"
it is cm9 kernel im looking to make
or i could use the one from cyanogen mod if thats easier since it has the RC1 kernel
 

zainthesnipe

Senior Member
Jan 8, 2011
362
40
Mississauga
Last edited:

thewadegeek

Senior Member
Mar 20, 2011
696
869
Cedar Rapids
Open that file, and then add that line. However I'm guessing this kernel has all the Govenor's you'll need for this. Also pay attention to the bit about the GPL, and make sure you ask the original creator's permission.
 
  • Like
Reactions: zainthesnipe

thewadegeek

Senior Member
Mar 20, 2011
696
869
Cedar Rapids
Ah good catch, updated. Ok so you know you created a "android/kernel" folder? In your terminal type "cd ~/android/kernel" and press enter. Then type "ls" and press enter again. Tell me what it says.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 490
    Preface

    OK a lot of people have been asking about building kernels, so here is my best shot at a tutorial. I want to preface this all by saying I AM NOT A DEVELOPER. I am a hacker and modder at best, I like doing my own thing, fiddling, and learning what I can, but I don't claim to know/understand everything about the process of building a kernel. You guys shouldn't expect my little walk through here plus another person’s source to make you a "developer", all it will prove is that you can copy/paste. ;) Also if you follow this guide, I am not responsible for anything that you may do that results in destruction, death, or other negative side-affects. You really shouldn't be messing with this stuff unless you know what you are doing, or doing a LOT of research along the way.

    However please use this guide as a springboard for knowledge, to give you some key terms to google, to turn on those lightbulbs in your head and get those gears churning.

    Note: This is not a newbie's guide to Linux. Before you post your question please look at it. If it involves the syntax of the command/what a command does you need to do your own research elsewhere before attempting to continue with this guide.

    Step 1. Build Environment
    A. Install Ubuntu 12.04(Not holding your hand here, if you can't do this you shouldn't be messing with kernels)
    B. Required packages: git-core, gnupg, flex, bison, gperf, libsdl-dev, libesd0-dev, libwxgtk2.6-dev, build-essential, zip, curl, libncurses5-dev, zlib1g-dev, ia32-libs, lib32z1-dev, lib32ncurses5-dev, gcc-multilib, g++-multilib, and Adb.
    C. Open a terminal
    D. Type "mkdir android"
    E. Type "cd android"
    G.Type "mkdir kernel"

    The above steps explained:
    A. Installing a linux distro. You could really install any Linux distro(Arch = epicness :p) however Ubuntu in my eyes is the easy to use and install, and widely supported.
    B. Installing needed packages. I believe are these are needed(I'm sure someone will correct if they aren't), these are just the one's I was told I needed the first time I built CyanogenMod. No I can't tell you what every single package does, it is your job to research and figure that out.
    C. Ummm...duh?
    D-G. Building a directory structure that will help keep us organized. The "mkdir" command creates a directory, and the "cd" command moves you into that directory. You could also combine these steps using the command "mkdir -p android/kernel", however I left it broken apart up there to enforce the typing bit of this. The more you type these commands the more familiar you will become with them.


    Step 2. Your Source
    A. Open your Terminal Prompt
    B. Type "cd android/kernel"
    C. Type "git clone git://github.com/DooMLoRD/android_prebuilt_toolchains.git toolchains"
    D. Now comes the tricky part, you need to have some-type of source for your kernel. Check the following two sites for your device as appropriate. Once you have it download it is extracted/cloned into a folder in your kernel directory.

    http://www.htcdev.com/
    http://opensource.samsung.com/
    http://developer.sonymobile.com/wportal/devworld/search-downloads/opensource
    http://www.lg.com/global/support/opensource/opensource.jsp

    The above steps explained: Ok all we are doing here is grabbing some tool chains and the kernel source.
    A. Ok...you got this one! ;)
    B. Moving into our working directory
    C. Grabbing DooMLoRD's very handy pre-built toolchains. What is a toolchain? Check this out http://en.wikipedia.org/wiki/GNU_toolchain. These toolchains are unstable, and as such they aren't completely endorsed yet. They are the versions I use though, and if you would like to use the stable version(4.5.3 as of 07/06/12) you can find links with Google.
    D. I typically put my kernel in a directory like "~/android/kernel/<devicename>_<androidversion>_kernel" but that's just me.​


    Step 3. Modifications
    This is the part people are curious about, they want to make modifications to the kernel to make it "special". Start all these from the root directory of your kernel source.

    Mod 1. Applying a patch
    A. Download the patch you wish to apply, in this case this one should work.
    B. Save that file as "kernelPatch" in your kernel directory.
    C. Open a Terminal
    D. Move into the root directory of the kernel you wish to patch.
    E. Type "patch -p1 < ../kernelPatch"

    The above steps explained:
    A. Pretty simple, I mean we need a patch. The patch itself is quite simply a diff between the original kernel source tree and the source tree containing the changes. I'll post a quick tutorial on how to create a patch in the third post. The patch above contains multiple governors to be added to your kernel.
    B. Self-explanatory
    C. Self-explanatory
    D. Self-explanatory
    E. Basically we run the patch command on our source using the patch we downloaded previously. The "patch" portion is the binary itself, the "-p1" option allows you to control the number of forward slashes to remove from file paths(You'll need to look at this option more if you are using weird directory structures or applying the patches from a odd location). The "<" operator directs the content of our "../kernelPatch" file into the command.
    Mod 2. Adding a Governor Alone
    A. Open "drivers/cpufreq/Kconfig"
    B. Add the following lines in appropriate spot amongst the other govenor's

    Code:
    config CPU_FREQ_DEFAULT_GOV_SMARTASS
                bool "smartass"
                select CPU_FREQ_GOV_SMARTASS
                select CPU_FREQ_GOV_PERFORMANCE
                help
                  Use the CPUFreq governor 'smartass' as default.

    Code:
    config CPU_FREQ_GOV_SMARTASS
               tristate "'smartass' cpufreq governor"
               depends on CPU_FREQ
               help
                 smartass' - a "smart" optimized governor!
                 If in doubt, say N.
    C. Open "drivers/cpufreq/Makefile"
    D. Add the following line in the appropriate spot.
    Code:
        obj-$(CONFIG_CPU_FREQ_GOV_SMARTASS)     += cpufreq_smartass.o

    E. Create a file called "drivers/cpufreq/cpufreq_smartass.c"
    F. Put the following code in that file.
    http://pastebin.com/f0Bk9kVZ
    G. open "include/linux/cpufreq.h"
    H. Under the "Cpufreq Default" section add
    Code:
    #elif defined(CONFIG_CPU_FREQ_DEFAULT_GOV_SMARTASS)
    extern struct cpufreq_governor cpufreq_gov_smartass;
    #define CPUFREQ_DEFAULT_GOVERNOR (&cpufreq_gov_smartass)

    Ok there is a governor added, do the exact same steps for any other one's you would like to add.

    The above steps explained:
    A. Just opening a file, you guys have this. The Kconfig ties into our "make menuconfig" command later, making our mod a selectable option.
    B. Adding the appropriate code for our governor to get it in our .config file. The first chunk would allow us to set our governor as the default one for our kernel, the other allows us to totally remove or add it to the build as we wish.
    C-D. This step tells the linker to tie our module in with the rest of the code.
    E-F. Creating the actually governor itself, don't skip this step. ;) I would suggest reading through this and trying to understand how it works, it's some pretty awesome stuff.
    G-H. Open a file and add the code needed to tie our module into the rest of the source. Without this we would not be able to compile due to the rest of the source not knowing our module exists.​

    Step 4. Getting a Config file

    Option A. Pulling a config file from a kernel.
    A. Hook up a device that is using a kernel similar to one you are using as your base.
    B. Open a terminal
    C. Change to your root kernel directory
    D. Type "adb pull /proc/config.gz"
    E. Type "gunzip config.gz"
    F. Type "mv config arch/arm/configs/<your_config_name>_defconfig"

    The above steps explained:
    A. This will allow us to pull a base configuration file from a known working kernel. It makes it a lot easier to start out and let's us take baby steps through the whole process. As a note though not all kernel's support this, so you may have to try a few different one's to get it working. If that doesn't work, see option B.
    B. Hehe, you are getting good at this step
    C. Navigate to the uppermost directory of your kernel source.
    D. Use adb to pull a copy of a working config file to use as your source.
    E. Unzipping the config file.
    F. Moving the configuration file you pulled to the config directory so we can reference it later.
    Option B. Using the manufacturers config.
    Unfortunately as stated above, not all kernels support the "/proc/config.gz" method. You can typically find a manufacturer's configuration file in "arch/arm/configs". I believe the one for my HTC Flyer was called "flyer_hc_defconfig", so look for a layout similar to that one. Also read the README to get a better idea of how to modify it. I would personally make a copy of it called "<your_config_name>_defconfig" and use that as my base.
    Step 5. Building

    Time to start the real "build" section of this tutorial.
    Part A. Pre-build Steps
    A. Open terminal and change to the root of your kernel directory
    B. Type "export ARCH=arm"
    C. Type "export CROSS_COMPILE=~/android/kernel/toolchains/arm-eabi-linaro-4.6.2/bin/arm-eabi-"

    Part B. The First Build
    A. Type "make <your_config_name>_defconfig"
    B. Type "make menuconfig" and make the required changes to use any modules you added or similar changes.
    C. Type "make -j<maximum number of jobs>"

    Part C. Re-Builds
    A. Type "make clean"
    B. Type "make oldconfig"
    C. Type "make -j<maximum number of jobs>"

    Part D. Building Modules
    You have two options:
    A. Type "make modules"
    B. Type "make path/to/your/module.ko"

    The above steps explained:
    Part A.(These steps are required every time you close your terminal and re-open it to build again.)
    A. Ok shouldn’t need to explain this.
    B. This command sets your target architecture.
    C. Defines the path to the toolchain we are going to use to compile our kernel. You can change this to point towards whatever toolchain you have downloaded or feel like using, the way it is currently configured it will use the Linaro toolchain that we downloaded above.

    Part B.(These only need to be run the first time you build a kernel.)
    A. Load's your configuration file from earlier.
    B. Open up a menu to configure your kernel. It will use the config file you loaded in the previous step as a base.
    C. Viola start the build. I typically allow 1 job per core, so on my quad core machine I put "make -j4". Just raising that number will not make your build faster, your processor needs to be able to support the number of jobs you are assigning it.

    Part C. (Use the command's when you are building any-time outside of the first)
    A. This command gets rid of any old/outdated binaries or modules you compiled before, and let's start fresh. I like to run it every I build unless my changes are really small and localized.
    B. A very awesome command, it parses through what has changed and only prompts you about new options.
    C. See the explanation for the above "Part C.".

    Part D.(Use these for just building kernel modules.)
    A. This will re-build all modules.
    B. Will rebuild just the module you need. Very useful when you need to rebuild a WiFi module.​

    Step 6. Now what

    Ok we have now started our build and we are waiting for it to finish, so there are two possible outcomes:

    Outcome A. Build Succeds

    W00t!! You have a kernel built by your self from source. There are a couple things you need in-order to use this kernel on your device any ".ko" modules and the zImage binary. If you pay attention to the output of your compiler then you will see the location of those objects. However the following commands will make your life a bit easier(Thanks Recognized Developer Hacre):
    A. Open a terminal
    B. Change to your root kernel directory
    C. Type "mkdir ../<your_kernel>_output"
    D. Type "cp arch/arm/boot/zImage ../<your_kernel>_output/zImage"
    E. Type "find . -name "*.ko" -exec cp {} ../<your_kernel>_output \;"

    The above steps explained:
    A-C. Self-Explanatory
    D. Move our kernel binary into our output folder
    E. This handy bit of magic finds all ".ko" modules and also copies them into your output file.

    You will also need to assemble a kernel image containing a initramfs for your device, along with the kernel binary and such. That however is beyond the scope of this tutorial. To get started though try searching the following phrases.

    Code:
    building android kernel image
    xda build kernel image
    xda unpack boot.img
    Outcome B. Build Fails

    Oh dear. It failed. Well guess what...this is going to happen..a LOT. Get used to it, and get used to googling and experimenting with different solutions. The following are some tips that will help you with debugging your issues.
    Running a "Clean" build
    A. Backup your config file(Type "cp .config ../backupConfig")
    B. Re-run the build process using just your defconfig from earlier.

    Limiting Output(Thanks Hacre.)
    A. Another good tip is to run "make -j1" to get the error, as it will limit the amount of text you need to scroll through.​
    Credits
    Hacre-Feedback
    cdesai-Feedback
    Leedroid-Being willing to answer a noob's question's ;)
    Doomlord- Having such handy Git repo's :)

    Enjoy. That's all it takes to build a kernel, it's actually rather simple. I will try to answer what questions I can in this thread, and continue to add to it.
    75
    Please Read. The GPL is VERY important.
    The Rules as they apply on XDA

    As XDA has no legal power to uphold the GPL (and frankly we want to stay as far away from doing so as possible), we can’t force any of our users to abide by the GPL. However it is in XDA’s interests as well as the interests of our developer-base to ensure all GPL-derived materials hosted or linked on XDA comply fully with the GPL.

    GPL-derived materials that do not come with the complete sources used to compile the GPL components are considered warez, and will be treated as such under forum rule 6 and 9.
    If you use GPL components, but do not make any modifications to them whatsoever, you should provide a link to the original source of your GPL code.
    Sources accompanying a release should be complete, and contain all the necessary source code for any modules, scripts or definition files. Complete sources will be defined as those which compile correctly and completely against the platform for which the software is distributed, and which contain any and all modifications made to the released General Public Licenced code. The source code supplied should be the exact version for which the source code is being requested, complete with all modifications.

    EXAMPLE: Here’s a bit of code that could be used as a template to post your releases

    <Kernel Or Author Name> <Kernel Nr>:
    <Source>|<ReadMe>|<Credits>|<Other>

    The Very Quick Summary of General Public License (GPL)

    The text of the GPL Licence itself will be used to reach any final conclusion regarding any disputes over GPL Licenced materials. The above is a summary of what XDA expects of members using GPL code, and the complete text can be read at the GNU website.



    The GPL states that anyone who modifies GPL licenced code is required to make available the sources used to compile it. This is to further improve and encourage collaborative work, as well as to ensure that the best code possible is produced, and to encourage peer-review of all work. This benefits both developers and end users in numerous ways, including:

    Allowing anyone to verify the code they are trusting with their data, and its authenticity
    Encouraging community collaboration to produce faster fixes and updates, and better code
    Helping bring new developments from other devices and fields to your own, letting you benefit from new code that wouldn’t have been available without this sharing.
    The GPL imparts great freedom for GPL end users. It ensures innovation is never stifled and no project is dependent upon any single developer.

    It is in everyone’s interest for the GPL to be adhered to, as it gives us all better ROMs, better transparency, and a better atmosphere for developers to work together to make great code.
    31
    Grabbing this on the off chance that this thread takes off.
    Tutorial coming on how to make a patch when I have time.(Hopefully later tonight.)
    10
    Nope I wasn't really thinking, but I WAS planning on fixing and updating it as I went. There was some people who wanted a quick and dirty guide so I posted it to help them out. I didn't realize people(you) would freak out about it. I'll fix it up here and re-post. Once I get the new version up will you skim through it again and tell me what you think?

    You still don't need java to compile a kernel.

    I wasn't the only one to give you valid advice on your OP:
    D. Type "mkdir android"
    E. Type "cd android"
    G.Type "mkdir kernel"

    mkdir -p android/kernel

    I'd highly recommend that you turn the addition of the smartass governor into a patch. Anyone interested in kernel development will be picking up third party changes 99% of the time as patch files. You can still explain what the patch is doing (perhaps link to some kernel programming tutorials in reference to the actual C code that gets pulled in).

    D. Type "adb pull /proc/config.gz"

    The problem with this is very few handset manufacturers enable this option. Samsung don't and the last I looked, HTC don't (if they changed this, great). This would explain some of the "problems" other people have replied to this thread with. This is where you guide your prospective kernel maker into -reading- things, like the READMEs that usually come with the kernel source from the manufacturer, containing information on the defconfig file that already exists for the handset in that source tree.

    "export CROSS_COMPILE=~/android/kernel/toolchains/arm-eabi-linaro-4.6.2/bin/arm-eabi-"

    I'd strongly suggest changing this to export CROSS_COMPILE=arm-eabi-
    then adding export PATH=$PATH:~/android/kernel/toolchains/arm-eabi-linaro-4.6.2/bin

    Further to that, be very careful recommending unstable compilers. At time of writing, 4.5.3 is the stable version of GCC.

    There's no need for make clean at this step, you haven't built anything so have nothing to clean. It would be a good idea to separate out "make defconfig" and "make menuconfig" into their own configuration section as well as making sure the user knows that you only need make defconfig once. Help them backup the .config file, prior to building, to arch/arm/configs/<name>_<new>_defconfig or something.

    You also need a summation at the end of your guide, most XDA users trying this will either get to the end of the build process and think "urrr now what" or the build will fail. For the latter option, add to your instructions retrying the build but with make -j1 (saves scrolling back in the buffer to find the error), detailing how to revert to the unchanged config (make whatever_defconfig created earlier) and see if it builds then.

    For the former, they should at least know that the zImage is in arch/arm/boot and that mkdir ../modules/ followed by find . -name *.ko -exec cp {} /path/to/modules/ will pull the modules out of the source tree and into one directory where they can start looking at building a kernel image. Then provide some sample links to tools that do this depending on phone manufacturer, already existing guides on doing this or at the very least, suggest some google terms to search for.

    Yes, people at the stage of actually building a kernel should know most of this, but it's XDA and they don't. You've already had someone, with Linux installed, type Is instead of ls to list directory contents, so you can't take anything for granted, unfortunately.
    8
    Go for it, let me know if you have any problems with it.

    Sent from my SCH-R760 using Tapatalk 2