Database Users

[kernel]Unhelpful Kernel v1.7 2010-10-04-0018

WARNING
Overclocking/undervolting could cause crashes with loss of data, or even damage hardware including the CPU or GPU.
Voodoo support included since 1.5, remove all non-Voodoo lagfixes before installing.
This works for me, but you are ultimately responsible for what happens to your device and your data - have backups, preferably on an external SD that you remove for initial testing.
These are unsigned and will not flash via stock recovery. Use ROM Manager to flash, with ROM Manager you also don't need to rename them as it can select any zip file from internal storage.
Features:
Voodoo lagfix support - should work correctly flashed over other Voodoo beta4 kernels, remove non-Voodoo lagfixes before installing.
BLN support to allow use of touch-button lights to indicate pending notifications when screen is off. The lights will light for all statusbar notifications, unless disabled in the app producing the notification (not all apps will have an option to do this, I don't think any stock Samsung apps do).
Stock voltages/clocks at boot, runtime configuration of clocks and voltages via sysfs, nilfs2 and ext2/3/4 filesystem support, two-stage user init - early scripts for mounting filesystems, late ones for running services. Default I/O scheduler is BFQ, BFQ/CFQ/anticipatory all perform roughly the same in benchmarks with multiple threads competing for I/O. Typical wakeup between instant and about one second, built with the binutils 2.19.1 / gcc 4.3.4 toolchain.
User clock/voltage configuration can be read from/written to /sys/devices/system/cpu/cpu0/cpufreq/freq_volt_table. Copy this file to get the defaults, edit your copy and write back over the original to update, or save your new file in /sdcard/sd/config, /sdcard/config, or /system/etc/config to have it applied on boot. The first column is CPU clock, the second GPU clock, the third CPU voltage, the fourth internal voltage. Changing values besides CPU clock/voltage is not recommended. You must keep 100MHz as the lowest speed. Clocks are in KHz, voltages in mV. Modify at your own risk, I find that my phone runs 1.2GHz @ 1.3V just fine, but yours may vary.
Be aware that your phone might appear to run fine with overclock/undervolt at first but crash later due to some error in calculation or data transfer - i recommend a good number of runs on something like Quadrant, and at least five minutes or so of SetCPU stress test for each frequency you add or change.
User inits must be placed in /system/etc/init.d, and properly named - names starting with "E" will run before /data and /dbdata are mounted, names starting with "S" will run right before startup is completed and normal Android services start. Inits are sorted by name, so you can follow the initial E or S with a number to change the order in which they will run. Scripts need not be executable, and will be run with the shell provided in initramfs for Voodoo support (busybox ash). If either /data or /dbdata is not a mount point after E scripts are completed, /user_early_init.sh will attempt to mount an rfs filesystem there from the usual location. If you want to mount a filesystem that is some other type, you will need to do so in a user script. If you want to format /data with another filesystem, you must edit the partition table to change the partition number - I have disabled the code in /sbin/init that rewrites the partition table, but if it finds something on standard /data partition that does not look like a valid RFS filesystem, it will reformat it.
If you want to build yourself, see the toolchains thread for known-working tools. Run
Code:
make ARCH=arm i897_defconfig
make ARCH=arm menuconfig [COLOR="blue"]optional[/COLOR]
make CROSS_COMPILE=/path/to/toolchain/arm-none-eabi- zImage [COLOR="blue"]change if using a different toolchain[/COLOR]
tar c -C arch/arm/boot/zImage >captivate_zimage.tar
Flash captivate_zimage.tar as PDA in Odin - see other threads for how to use Odin and where to get it. Use menuconfig to select a different initramfs source if you wish, by default an included one at usr/initrd_files will be used.
Starting with v1.4, create a .build_config file to change any variables and run build_kernel.sh to build tar flashable with Odin or update.zip. As of v1.5.2 you can also use .build_config to inject commands and files into update.zip builds.
CREDITS
raspdeep - the original OC code
curio - Voodoo lagfix original concept and script
neldar - BLN support
atinm - BLN port for Captivate
BusyBox, buildroot, crosstool-ng, nilfs2 - see respective projects for original contributors and source
v1.7ClockworkMod Recovery
flashable binary: mediafire mirror | github mirror
github source
BETA ClockworkMod Recovery replaces stock recovery
BETA support for backup/restore with Voodoo enabled
v1.6BLN Support
flashable binary: View attachment i897-unhelpful-v1.6.zip | mediafire mirror | github mirror
github source
BLN support - use the touch-button lights to alert of pending notification when screen is off.
Disable check for SGH-I897 device, since this can fail on Captivate hardware if an alternate ROM is flashed.
v1.5.3Bugfix release
flashable binary: View attachment i897-unhelpful-v1.5.3.zip | mediafire mirror | github mirror
github source
Revert from the config based on kepler_rev02_defconfig, suggested by the 9/6 code drop, to aries_rev02_defconfig. The config change appears to have been responsible for the power drain problems seen in v1.5.1 and v1.5.2.
v1.5.2Bugfixes and Voodoo lagfix support
flashable binary: View attachment i897-unhelpful-v1.5.2.zip | View attachment i897-unhelpful-v1.5.2.tar.7z | mediafire mirror | github mirror
github source
Odin-flashable tar file (inside 7z to allow upload to XDA), please use only to recover from bad flash of v1.5.1, the update.zip contains scripts that are important if you're running SRE.
Voodoo lagfix support
Restore correct stock voltage (1.275V) for 1GHz
Update sources and config from Captivate 9/6 source drop
Update modules from JH7 OTA
LZMA initramfs compression to reduce compressed kernel size / allow larger initramfs
Enhanced update.zip support allows developers to easily inject their own commands and files into update.zip on build, and allows run_programs scripts to produce screen output and can flash kernel/modem partitions directly.
v1.4.1BUGFIX for SRE users
flashable binary: View attachment i897-unhelpful-v1.4.1.zip | View attachment i897-unhelpful-v1.4.1.tar.7z | mediafire mirror | github mirror
github source
Bug with SRE + 1.4 causing storage to become unavailable should be fixed by this kernel, fix works on my phone but some have reported problem spontaneously ifxing itself.
v1.4Load OC/UV config from file, system early init (for developers).
downloads removed due to bugs
github source
Built with gcc-4.4.3
build_kernel.sh reads variables from .build_config, or from config file specified by $BUILD_CONFIG, so you can keep the script file clean.
Early system init - E* scripts in /sbin/init.d run before user early init, for developers to include startup scripts.
System init loading of OC/UV table - searches for config/freq_volt_table on external SD, then internal SD, then in /system/etc.
ADB checks uses the first shell found from the list bash, ash, /system/xbin/sh, /system/bin/sh, sh.
Correctly set cpufreq policy on table change - should fix resets of maximum clock to 1GHz after new tables are loaded.
v1.3.1OC/UV configuration
flashable binary: View attachment i897-unhelpful-v1.3.1.zip | mediafire mirror | github mirror
github source
Stock clocks/voltages at boot, user can add new clocks and change voltages at runtime - see above for details.
Modify stock init to avoid rewriting partition table at boot - change the partition table for internal SD, resize partitions or remake /data with a different partition number so it can be safely formatted with another filesystem.
v1.2Bugfix / update.zip / dev features
flashable binary: View attachment 389189 | mediafire mirror | github mirror
github source
Fix scaling bug, performance level was set past end of table on sleep
Scaling enhancement, selectable clock source for GPU
GPU clocked at 222MHz for all speeds except 100MHz, where it matches CPU clock
Basic build_kernel.sh script, edit to change configuration - builds unsigned update.zip with default kernel config by default
Add interactive CPU governor - enabled in build but conservative is still configured as the default
v1.1Bugfix release
flashable binary: mediafire mirror | github mirror
github source
Rework of user init, resolves lost-settings-on-boot issue for me.​
v1.0Initial release for Captivate I897
flashable binary: mediafire mirror | github mirror
github source
nilfs2, ext2/3/4 filesystems
separate early and late user init
600MHz and 1.2GHz speeds, use SetCPU to enable 1.2GHz
fast scaling from low speed, skipping from 100MHz to 800MHz​Other Downloads
User Init Scripts
mediafire, github - enable 1.2GHz overclock on startup
mediafire, github - start Mobile AP background service

Does this include the ability to clock at 1000 mhz?
Sent from my Nexus One using XDA App

You're my hero.
*edit*
_Opiate_ said:
Does this include the ability to clock at 1000 mhz?
Sent from my Nexus One using XDA App
Click to expand...
Click to collapse
Yea it is, I have it set at 1200 in setcpu and I saw it hit 1000mhz a few times just watching it.

Yes, the scaling steps are 100MHz, 200MHz, 400MHz, 600MHz, 800MHz, 1GHz, and 1.2GHz. 1.2GHz is disabled at startup until the user enables it, so that the kernel can be used without overclocking.
Sent from my SAMSUNG-SGH-I897 using XDA App

So will this undo the MobileAP that was just put out. I know we had to flash a custom kernel to enable that. Will this undo it?

Clienterror said:
You're my hero.
*edit*
Yea it is, I have it set at 1200 in setcpu and I saw it hit 1000mhz a few times just watching it.
Click to expand...
Click to collapse
Never mind I just flashed it. No On demand?

Unhelpful said:
Yes, the scaling steps are 100MHz, 200MHz, 400MHz, 600MHz, 800MHz, 1GHz, and 1.2GHz. 1.2GHz is disabled at startup until the user enables it, so that the kernel can be used without overclocking.
Sent from my SAMSUNG-SGH-I897 using XDA App
Click to expand...
Click to collapse
Thats great. Hell just running it at 1000mhz is a slight improvement in Quadrant. Before when I was running the stock kernel I never saw it clock above 800mhz.

Also no wake up lag at all!!!!!!!!! Great fraking job man!!!!!

jhernand1102 said:
So will this undo the MobileAP that was just put out. I know we had to flash a custom kernal to enable that. Will this undo it?
Click to expand...
Click to collapse
This does not run wlp2pservice in the init.rc, but a user script can easily be written to do that - I already have one on my phone, I'm going to add a section for init scripts in the OP when I get the chance.

Can you toss up a donation link plz :-D

Unhelpful said:
This does not run wlp2pservice in the init.rc, but a user script can easily be written to do that - I already have one on my phone, I'm going to add a section for init scripts in the OP when I get the chance.
Click to expand...
Click to collapse
Thanks for the info...looking forward to trying this out once there is a script so MobileAP still works...

jhernand1102 said:
Thanks for the info...looking forward to trying this out once there is a script so MobileAP still works...
Click to expand...
Click to collapse
Yeah that's one reason I still use my Nexus One mainly. The ability to tether is built right in to Froyo. But I can wait for tethering till we have a kernel that will do both. I prefer to play with this kernel now. Lol
Sent from my Nexus One using XDA App

_Opiate_ said:
Yeah that's one reason I still use my Nexus One mainly. The ability to tether is built right in to Froyo. But I can wait for tethering till we have a kernel that will do both. I prefer to play with this kernel now. Lol
Sent from my Nexus One using XDA App
Click to expand...
Click to collapse
Yeah hopeful it can be put in the same kernel then we can have the best of both worlds...

I just found something strange. When I reboot and enter set cpu the phone say I have to chose my device again so I have to choose autodetect again.
Sent from my SAMSUNG-SGH-I897 using XDA App

do we just flash this with odin ? in the op there are many intrsuctions on putting stuff here and there i got lost

_Opiate_ said:
I just found something strange. When I reboot and enter set cpu the phone say I have to chose my device again so I have to choose autodetect again.
Sent from my SAMSUNG-SGH-I897 using XDA App
Click to expand...
Click to collapse
Every time I reboot it's all in Russian again like the first boot with JM5 lol.
Crizthakidd said:
do we just flash this with odin ? in the op there are many intrsuctions on putting stuff here and there i got lost
Click to expand...
Click to collapse
Yep, just use 7zip and extract the .tar then flash with odin3 as PDA.

Wow, unhelpful you are the MAN. Put up a donate link, I'll send a few beers your way.

Works!!
Unhelpful, you're probably one of the MOST helpful people on this forum. haha

minor bug, usb debugging doesn't seem to stay on between reboots.
and i can't seem to send emails using the gmail client anymore

IStern said:
minor bug, usb debugging doesn't seem to stay on between reboots.
and i can't seem to send emails using the gmail client anymore
Click to expand...
Click to collapse
ditto on the usb debugging, wont stay on between reboots

[EXPERIMENTAL/TOOLS/GUIDE/ADV.] Toolchain gcc 4.6.3 Cygwin/Linux/OSX; kernel builds

The following contains binaries, and instructions for use of an experimental newer toolchain than those included in the android pre-built package.
This is provided to allow existing linux kernel developers experiment with the updated version of GCC (besides the complicated building instructions the code just has a small patch for a known issue with android and 4.6.* otherwise is directly from GNU (see build information below)
The packages I'm also providing to help developers current on windows (With cygwin but no other virtual environment) to start exploring android Linux kernel development for their devices. (In addition to a OSX toolchain for more advanced mac users)
due to the slight differences between kernels on different devices this How To is intended to be used for advanced users who can adjust for the differences required for the devices specific kernel.
I may add additional guides to this thread if I find a need for them.
[size=+1]Binary Toolchains[/size]
I have two versions of a GCC-4.6.3 toolchain
1) For x86 linux: toolchain-4.6.3.tar.bz2 (Sha1: c8c57aba6ad92e9acddf29ba8620ba880be09a81)
2) For Cygwin (windows): toolchain-4.6.3.cygwin.tar.bz2 (Sha1: 6947e1c1ba95195019f542eb8ba0708667b63eca)
3) For OSX (mac/darwin): toolchain-4.6.3.darwin.tar.bz2 (Sha1: 9a977f0672863fdd9501383a6ad1e30723281f68)
[size=-1]> The linux version was built via this script: http://pastebin.com/b2dZ8YtG (or in the included toolchain_notes.txt)
> The cygwin/darwin version uses the same source however has a slightly modified script (see the included toolchain_notes.txt for the updated script)[/size]
[size=+1]System Requirements[/size]
Note I have a 64bit debian linux box, and a 64bit version of WIndows7 Pro running cygwin, while I believe these binaries ought to be compatible with all x86 linux and cygwin installs these have not been tested by a wide number of people yet.
> Linux users: If you have a working android build environment likely no additional requirements are needed. In addition you must build any kernel/android utilities from a case sensitive filesystem or disk image.
> OSx users: the cygwin packages will give you an idea of what is required, please also see the README in the tar.bz2 about manually installing elf.h
> Cygwin users: as its unlikely you have compiled a kernel with cygwin up to this point you may wish to ensure the following packages are installed (as well as any cygwin recommends to be used with them):
vim
vim-common
make
cmake
lzop
gcc
gcc-core
gcc-g++
wget
git
git-compleation
libncurses-devel
python​
Cygwin users must also set their NTFS file partition to allow case sensitive files:
To do this open regedit and change:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel\obcaseinsensitive
to 0
after this reboot and the NTFS kernel will allow cygwin to use case sensitive files (ie 'AbC' and 'aBc' as two different files)​
[size=+1]Advanced Kernel Building Guide[/size]
Since may devices are slightly different this can only be a high level kernel building guide
Please ask for any specific directions from the current kernel maintainer.
To most people who have built kernels before this will look familiar, the most important part is preparing your local environment to use the new toolchain,
1) If you have not already download the tar.bz2 above, (pick the one for the computer you are preparing to build kernels on)
2) extract the file (for the sake of this guide I will assume it is extracted into a ~/android directory)
ie on cygwin you might:
mkdir -p ~/android
cd ~/android
tar -xjvf toolchain-4.6.3.cygwin.tar.bz2
Note: steps one and two are just properly installing the toolchain, you will not need
to repeat them to build a different kernel.
2.b) OSX Only: check elf.h
open ~/android/toolchain-4.6.3/README in a text editor and check if elf.h is installed, otherwise manually install it as per the readme
3) fetch your kernel source into the ~/android directory and change into the
source codes root directory
(this can be via a git repo or tarball)
example if you wanted my ACER a100/a500 source you might run:
git clone git://github.com/ezterry/AcerTabKernel.git
cd AcerTabKernel
change this to match the source you are fetching
4) In the root directory of the kernel source (~/android/AcerTabKernel in the about a100/a500 example) update the environment for the cross compiler
add the toolchain to your path:
export PATH=$HOME/android/toolchain-4.6.3/bin:$PATH​
set the cross compile:
export ARCH=arm
export CROSS_COMPILE=arm-linux-androideabi-
export KERNEL_DIR=`pwd`​
(this will need to be done once for each terminal you use to run any of the following make commands)
5) Grab your configuration
From the device:
adb pull /proc/config.gz
gzip -dc config.gz > .config
or from a prepared configuration if it's included in your code base by running
make _defconfig
example for the a100/a500 code base is 'make vangogh_defconfig' for the a100 and 'make picasso_defconfig' for the a500
6) Customize configuration
just run menuconfig and use the UI to update settings
make menuconfig​
7) building the kernel (zImage)
This is normal at this point with 'make -j'
so for a quad core CPU you can run
make -j5​
(note: the wrong number in the -j argument will not harm the build but may slow down the building process by either using too few threads or needing to keep track of too many)
8) If it worked you will now have the kernel in arch/arm/boot/zImage
this can be injected into the boot.img (as the kernel, using an existing ramdisk) as is
If it failed for your kernel your kernel source may need one of the common patches
9) Building modules
the following will prepare the modules in subdirectory mod:
make modules
rm -rf mod
mkdir mod
cp `find ./ | grep .ko$` modules.order mod/​
After these commands [if no errors] you can simply copy the contents of mod/ to /system/lib/modules on your device, note it is recommended usually to remove the existing contents of /system/lib/modules unless there is a closed source module required from the previous build despite the new kernel.
[size=+1]Common Patches Required[/size]
If your kernel has not been built for the new toolchain or on cygwin before you may require some of these common patchs: (I've thus far only tested this on my Acer A100/A500 source)
wireless/bcm4329 for GCC-4.6.3:
https://github.com/ezterry/AcerTabKernel/commit/123f32e27e2c74f1c1789ae5d6d5a1c04e1e264c
linux kernel module patch for cygwin (broken elf.h):
https://github.com/ezterry/AcerTabKernel/commit/220db49593cf6b9f3b556e2f4b75b2f6d3ff556c
Error compiling security/smc/bridge_pub2sec.S (I required the cygwin elf patch and this patch to build the Franco galaxy nexus kernel)
0001-Fix-build-error-with-4.6.3-toolchain-smc-0.patch
(use 'git am 0001-Fix-build-error-with-4.6.3-toolchain-smc-0.patch' to apply)
OSX stat patches (fixes errors between GNU and BSD stat):
https://github.com/ezterry/AcerTabKernel/commit/0c49df3cc1a05a0ccd98201511cdc0534aaeb35a
Errors loading newly built modules (modules appear to build cleanly but wont install):
simply add -fno-pic to CFLAGS_MODULE
https://github.com/ezterry/AcerTabKernel/commit/c5ed0fcb014d36936a86ad253f15af43de2f644a
(I can add others here if highlighted to me, and as I find them)
[size=+1]Other Toolchain uses[/size]
The linux toolchain can be used to build android components, however this requires various manipulation to the android /build git repository as currently various other toolchains have hard coded paths into the prebuilt repo. If you intend to incorporate this into your build it may be best to inject the toolchain into your prebuilt repo rather than expect your users to download the links above, ensure to keep the compile notes as it explains how to get the source code to the toolchains)
On cygwin/osx it may also be possible to build android applications however I've not yet tested this as the scripts to make a proper build are complex when attempted outside the android build tree.

Excellent!!! thanks Man!!! Has been looking for one of these

Added in the OSX version of the toolchain (and some related patches)
Also if you are having problems with your modules built with this toolchain a CFLAG fixes it. (see note in common patches)

FINALLY!!! Great Instructions followed them to the T and BAM got my kernel compiled!!!

wow your toolchain is so small, many thanks, just compiled a kernel for my LG P500 gonna test it, thanks again

Bookmarked for testing when I wake up...
I can almost put: "Building under Windows is not currently supported." (quote from google), unofficially at least, out of my mind...
I have been spoiled by Windows for far too long I fear, my attempt for this last week at getting Linux setup and building CM9 has been nothing but a complete FAILURE, too many single line entrys for different distributions/package combo's, commands I dont know and cant find because of wildcard portions of them and lack of understanding, and not enough scripts like the wonderful Compile CM9 script someone put up (cant run it because all the pre-req's arent setup).
Good god Ill be jumping for joy if this works tomorrow on WinBlows!

EDIT: never mind, problem solved, what I need to know now won't be solved here

I wish i knew how to go about doing this..

Thanks
Thanks For ........... i Really need It .........

Hammerfest said:
Bookmarked for testing when I wake up...
I can almost put: "Building under Windows is not currently supported." (quote from google), unofficially at least, out of my mind...
I have been spoiled by Windows for far too long I fear, my attempt for this last week at getting Linux setup and building CM9 has been nothing but a complete FAILURE, too many single line entrys for different distributions/package combo's, commands I dont know and cant find because of wildcard portions of them and lack of understanding, and not enough scripts like the wonderful Compile CM9 script someone put up (cant run it because all the pre-req's arent setup).
Good god Ill be jumping for joy if this works tomorrow on WinBlows!
Click to expand...
Click to collapse
If you succeed tell me how to do it in a more familiar way

I get errors regading the processor not being supported?

brfield said:
I get errors regading the processor not being supported?
Click to expand...
Click to collapse
Sorry I can't support devs that have not learned cut copy and paste.
You probably forgot to export some of the environment variables or are just trying to run a arm binary on your PC and or a x86 binary on your arm device.
But why am I guessing? Why don't we know what you tried to run and what the actual text of the error was.. what type of kernel you tried to build, what you are running?
These packages are for developers if you feel like using them its time to learn to how to trouble shoot a problem and write a ticket to explain said problem clearly to others with at least some information to give us a chance to understand.
Sent from my Galaxy Nexus using Tapatalk 2

Great guide. Have the bcm4329 wireless module, so followed the tips and everything compiled and works!
Thanks!

one question,how to compiled android kernel with -O3 optimization?

jxxhwy said:
one question,how to compiled android kernel with -O3 optimization?
Click to expand...
Click to collapse
Um, in general its recommended you don't:
-O3 is not recommended for the kernel as many low level parts require the assembly code generated to remain as is and not be optimized as will be by some of the options -O3 enables thus likely reducing the stability of your kernel.
---
That said the menuconfig has an option to optimize for size (-Os) if enabled else -O2
For other optimization (including tuning for your cpu) you can add them to the CFLAGS_KERNEL/CFLAGS_MODULE in the make file.)
For -O3 like functionality you could add the increment to the line:
-finline-functions, -funswitch-loops, -fpredictive-commoning, -fgcse-after-reload, -ftreel-vectorize, -ftree-partial-pre and -fipa-cp-clone
-Ofast is -O3 with -ffast-math as well
If you do build with all the -O3 or-Ofast options ensure you test the kernel for stability and run some benchmarks. (as it may not actually be faster depending on the cache misses)
The first option I'd start pruning was the one mentioned in my reference below -fgcse-after-reload.
If you really insist on -O3 rather than just adding the optimization you want that are not in O2,it can be added also in the Makefile where the configure flag is checked and its added to KBUILD_CFLAGS
Obviously all and any of this is at your own risk, anything that breaks you have to find a way to fix it.
Reference:
Gcc optimize options:
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
Talk of O3 and the kernel (not android specific)
http://unix.stackexchange.com/questions/1597/compiling-gnu-linux-with-o3-optimization

ezterry,thank you very much!
I want to build cm9 kernel using toolchain 4.6.3.
How to replace the default GCC 4.4.3 to 4.6.3 version?
BTW,I use the way -- make bootimage

jxxhwy said:
ezterry,thank you very much!
I want to build cm9 kernel using toolchain 4.6.3.
How to replace the default GCC 4.4.3 to 4.6.3 version?
BTW,I use the way -- make bootimage
Click to expand...
Click to collapse
If you are asking in a cm9 build tree.. its a pain, best is to update the cm kernel makefile to point the build chain temporarily.
If you mean just to compile by hand as described in the op
Once the kernel is compiled find an anykernel update.zip or manually use mkbootimg or fastboot to merge it with the ram disk. Cm9 targets mkbootimg and unpackbootimg (if I'm not mistaken) will build the applications to unpack your current (or the default cm9) boot image and re-create them with your custom kernel built from hand.

Now,I runing script file:
#Let's make sure the environment is clean and ready to compile the kernel
echo "Cleaning house!!"
make mrproper
echo "House cleaned, lets build a kernel!!!"
#
# Lets set the kernel defconfig
echo "defconfig = cyanogenmod_iprj_defconfig"
make ARCH=arm cyanogenmod_iprj_defconfig
#
# Let's build a kernel
echo "Now compiling kernel, go get a soda! "
ARCH=arm CROSS_COMPILE=~/Android/sourcecm9/cm9/toolchain-4.6.3/bin/arm-linux-androideabi- make zImage -j4
#
if [ -f arch/arm/boot/zImage ]; then
echo "Plague has been compiled!!! You can find it in arch/arm/boot/zImage"
else
echo "Kernel did not compile, please check for errors!!"
fi
but,I got some error output:
/home/xxx/cm9/toolchain-4.6.3/bin/arm-linux-androideabi-ld: cannot find usr/initramfs_data.o: No such file or directory
thanks again!!!

I think that means there is an issue with your config..
Most android kernels require initramfs, but don't specify a file, as its provided by the bootloader.. However in your case it is trying to embed it into the kernel.
Sent from my A500 using Tapatalk 2

ezterry said:
I think that means there is an issue with your config..
Most android kernels require initramfs, but don't specify a file, as its provided by the bootloader.. However in your case it is trying to embed it into the kernel.
Sent from my A500 using Tapatalk 2
Click to expand...
Click to collapse
issue has been resolved by myslef.Thanks for your time.

[GUIDE] [Updated] Compiling and putting together a kernel for the X8

Second thread in a week. Read on, young dev, for you are about to enter a world of Android goodness soon.
WHAT IS A KERNEL?
A kernel, as explained by viper001 in his thread, is the software layer between the ROM and the hardware. It contains the crucial init process of the boot sequence. So an Android phone with a faulty kernel may mean a very expensive paperweight. But fear not I have compiled several kernels for my phone (released a few of them too) and I have never ever bricked my phone (not even a bootloop, strange right?).
WHY THE NEW THREAD AND WHY YOU SHOULD COMPILE A KERNEL?
viper001's thread is pretty outdated (it was published in 2010, it's nearly 2013 now) and uses the FXP source (which is also pretty old). Therefore if you compile a kernel following that guide, you'll only be able to use it with FXP ROM (which is almost ancient by now). That is why I decided, after considering Rohin's suggestion, to write a new kernel building guide, for members who wish to step into the dev world by compiling a kernel. Keep in mind, neither the XDA-ians nor I am to be held responsible if you do brick your phone (even if you pee on it due to sheer excitement, though I am pretty sure you'll handle it....LIKE A BOSS).
THE ACTUAL GUIDE
Okay so you want to compile your kernel, huh? Well, you're gonna need some packages and toolchains and sources and blah blah. In short these are the requirements:
1. An Ubuntu build (Linux Mint will do too but I haven't tried using it) on a fast computer (preferably a quad core but a dual core 2.4GHz will do too, 2GB of RAM) or a virtual installation (Google installing ubuntu on vbox).
2. Some packages that you can get by typing this in the Terminal:
sudo apt-get install git unrar libncurses5-dev qt3-dev-tools
3. A kernel source
4. A toolchain
5. Flashtool in your Windows installation (you must have one)
KERNEL SOURCES AND TOOLCHAINS
nAa GB (L)
nAa ICS (L)
nAa JB (L)
Alfs GB (use master branch; test has problems) (L)
LINARO (L sources only)
LINUX GNU Compiler for ARM
INSTRUCTIONS
Make a folder where you'll be working for the time being. Name it conveniently. Unpack a source there and a toolchain (use the Linaro one, it makes the kernel slightly faster and each of the sources I mentioned is compatible with it). Rename the toolchain folder, and the source folder too, to something simpler. It's better if all this is done without root, because that may screw your Ubuntu installation beyond recovery. Even so I did it in root. You, however, should do it in any place other than root, and make sure you can easily navigate to the place through Terminal.
Now for the tough Terminal bit. Navigate to the source folder and type in this:
export ARCH=arm
export CROSS_COMPILE=/path/to/toolchain/folder/bin/arm-linux-gnueabihf-
This will tell Terminal to build the kernel for the ARM platform using the Linaro toolchain.
Then type in:
make xxxx_shakira_defconfig
Where xxxx is the part of the name before _shakira. Check the /arch/arm/configs directory for either semc_ (for Alfs kernels) or nAa_ (for nAa kernels). Or you can make your own defconfig if you're up to the challenge.
Then type in:
make menuconfig
This will display a GUI version of your defconfig. Edit anything you want to there or directly in the defconfig.
Then type in:
make -j#
Where # is the number of cores your CPU has + 1.
If all goes well, you should have your kernel image. Grab the Image file form /arch/arm/boot.
You do have Windows installed, right? Good, because you're gonna need it now. Download the bootloader unlocking tool (not Flashtool, the one posted by the_laser).
You have to copy your Image file and a ramdisk, check my other guide, to the sinTools folder of the bootloader unlock tool. A suitable ramdisk, not a GB one for an ICS kernel and vice versa. Then rename the Image file to image and double-click on example_build.cmd. You should get a result.zip. Exatract it and rename result.sin to kernel.sin. Copy it over to a folder and place a loader.sin from a working kernel there too. Open up Flashtool. Go to Advanced > Bundle creation. Navigate to the folder and select both files and move them over to the right-side (by clicking the > button). Give it a proper name and branding and click OK. FLASH! FLASH! You are done with your kernel. First ever, huh? Wish to know more.
If your build failed, type in
make mrproper
or
make clean
Coming soon, TIPS AND TRICKS and more.
P.S.
It is pretty obvious that I'm not a RD, or any D for that matter, this guide may have petty mistakes. Therefore I request any member to let me know if there are any mistakes should he/she find any.
Stay safe and pray that your PC doesn't explode while you're doing this.
If any of the Forum Mods are reading this, you may wonder why I posted this when there already was a guide. viper001's thread is a bit outdated although some users have compiled kernels following it. Therefore to help users who are quite new to this, I wrote this. I sincerely hope I do not get warned for posting a guide twice, just to help people compile newer kernels.
NEITHER THE XDA-IANS NOR I AM TO BE HELD RESPONSIBLE FOR ANY DAMAGE THAT THIS MAY CAUSE TO YOUR PHONE. YOU ARE SOLELY RESPONSIBLE FOR WHATEVER YOU DO TO YOUR PHONE.
But do ask for help if you need it.
EDIT: You can also use the zImage file (you have to rename it to image) as pilu1978 said in his post (check second page and thank him). If you use this, you can attach a larger ramdisk.

COMPILING WiFi MODULES
After you compile a kernel, you need to compile a set of WiFi modules for the kernel. Otherwise your WiFi won't turn on and when you check in Terminal Emulator, you'll get blah blah.ko magic version errors. So after every compile, you also need to compile your WiFi modules.
For nAa based kernels, all you gotta do is issue the ./build_wifi.sh command right after compiling your kernel. It'll result in 3 files in the source's parent folder: tiwlan_drv.ko, tiap_drv.ko and sdio.ko. You have to copy these files to the ramdisk's modules folder, replacing the ones already there.
For nAa .32 kernel, you don't have to do anything. Just grab the following modules:
net/compat-wireless/net/mac80211/mac80211.ko
net/compat-wireless/drivers/net/wireless/wl12xx/wl12xx_sdio.ko
net/compat-wireless/drivers/net/wireless/wl12xx/wl12xx.ko
Thanks to @btisserand and @pilu1978.
For alfs based kernels, I have no idea. You can ask alfsamsung like I did. I tried it using his method and failed. However I tried copying the vendor_ti_wlan and the build_wifi.sh files from nAa's source to alfs' source and it worked, just once. I couldn't test the modules myself but my tester said the kernel didn't even boot o_0. Therefore I find it safer to stick to the nAa kernel source. But even if you do try with alfs and somehow manage to succeed, do post how you managed to compile it.
EDIT: Thanks to Daveee10, you now have another source for the WiFi modules. Download this as a zipball and extract in Ubuntu. Then execute nAa's build_wifi.sh script in Terminal and you should have the modules. Oh and if you get any permission denied error just chmod it. It works for me.
Next post covers TIPS AND TRICKS.

TIPS AND TRICKS
So compiling a kernel, a bland, vanilla kernel is pretty mainstream. You want more tweaks. That's up to you to find out how you're gonna manage that. All I can do is help you with some things that'll make the kernel your very own, your precious.
Changing the name of the kernel...like completely
You want to change the name of the kernel like
xxxxx
[email protected]#1
[TIMESTAMP]
The xxxxx in the first line can be changed in the defconfig or in the menuconfig (easier). Go to General Setup. Then scroll down to the KERNEL_VERSION line (in menuconfig). Then change the name to anything you like (for example, X8-kernel).
The [email protected]#1 can also be changed. Go to /source-folder/scripts and open up the mk_compile.h file. Scroll down to line 66 and change the word within inverted commas to anything you like (for example, X8). Then in the next line, change the word within inverted commas to anything you like as well (for example, XDA).
After you flash your compiled kernel and go to Settings > About phone, you'll see
X8-kernel
[email protected]#1
[TIMESTAMP]
I'm not sure if you can change the TIMESTAMP.
Editing CPU freqs
Editing CPU frequencies via kernel is also pretty easy (thanks fotak-x for the suggestion).
Go to /arch/arm/mach-msm and open up acpuclock.c.
Scroll to line 202 (the line which says "7x27 with GSM capable modem PLL0 and PLL1 swapped" or something) and just below that you'll see the frequency table which also has the GPU frequencies (??)
The value after { 0, is the CPU frequency, the one you want to change.
You can delete any frequency that you don't use (19MHz and so on) but don't delete 600MHz or add any beyond 864MHz. No X8 will ever go beyond that without freezing up.
The values just before the last number are the voltage units (ranging from 1 to 7). You can experiment with that too but it's better not to.
If you do not know what you are doing, please do not attempt this.
Adding/Deleting I/O schedulers
First look at this commit from DooMLorD: https://github.com/DooMLoRD/Xperia-...mmit/0ae625f7561c559d4933284f489733bf5eb66e96
I'm pretty sure you understood what you gotta do. If you still didn't, read on.
What Sir DooMLorD did was change some lines in the Kconfig.iosched of /block directory to add the Simple I/O scheduler. Then he edited the Makefile to include the building of SIO. The most important thing he did was to make a new file and paste the code that is the script that tells SIO what to do, basically it's core ingredient. You have to perform similarly and change the defconfig to include the I/O scheduler.
Deleting is way simpler than that. You just have to write n after the line in the defconfig where the inclusion of the scheduler is mentioned.
50% FPS-uncap in ICS (and JB?) kernels
It's pretty obvious that I'm referring to the nAa-ICS kernel source. Navigate to the arch/arm/mach-msm directory and open up the board-delata.c file.
Go to line 1915 (the one that begins with panel_data->panel_info.lcd.vsync_enable). Change the value to FALSE. This disables HW vSync.
Then go to line 1999 (it also begins with panel_data->panel_info.lcd.vsync_enable). Change this value to FALSE as well.
Compile the kernel as you would normally. Flash to see a slight increase in performance, and a massive improvement in gaming.
Thanks to pilu1978
That's it for now. Will be updated soon.

CREDITS in no particular order
-viper001
-nobodyAtall
-alfsamsung
-djnilse
-Daveee10
-CyanogenMod team
-pilu1978
-RohinZaraki
-fotak-x
-DooMLorD
-paxChristos
-Google and the Android team

is it possible to compile it from stock kernel?

Thanks sgt may try compiling a kernel just for my ROMs

cool
@fotak-x
yes you can download the stock sources and compile it but it's a little complicated. and all kernels are basically improvements over the stock kernel, so in a way you are compiling a not-so-stock stock kernel.

Thread updated. More tips and tricks now.

Some additions
About the compiler (arm gcc). Today everyone prefer linaro. After a lot of testing, I can say: NO real performance differences between the different compilers (tried google/codesourcery/linaro with lot of versions between 4.4.x and 4.7.x series). Sometime the older is better. The linaro gcc contains optimized libgcc for each instruction set, but we are on the bottom of the list, without the armv7 extensions, extended float unit (thumb-2) and vector processing unit (NEON) the linaro gcc can't give real boost for our phone.
About the cpu frequencies: yes, possible to add/remove/modify these values, but without enough knowledge, better if you not do anything. You use an android phone, so you must know, your best friend: google. Use it. And try to understand how to generate the cpu freqs. Learn about the PLLs, their values, dividers, bus frequencies (axi, ahb, etc...) before start to play with frequencies. You can't set directly the gpu freq, in the msm7x27 SoC series the gpu freq depends on the axi clock (can't work in async mode). Modify the VCC levels, bus frequencies the easiest way to make the phone unstable.
About the wifi modules: you can use the wifi drivers from nAa sources if you want to compile modules to alfs kernel. Or you can find the tiwlan1271 driver sources in the cyanogenmod source tree too. If not working, or you can't compile, try another compiler, or other sources. If you successfully build the modules, you NOT must recompile it after a new kernel build. If you change the kernel versions (2.6.29.xx-xyz) you MUST recompile the modules (the wifi modules linked directly to the kernel version).

good addition mate. i never added any freq and that's why i don't know the exact amount it multiplies by at every step. or even if it works that way. and i never succeeded in compiling the WiFi modules for alfs. and yeah there is basically no improvements in terms of performance between Linaro and Codesourcery. Linaro just seems cool and that's why everyone wants to use it. simple as that. that being said, Linaro does indeed work good on ARMv7 devices as you said in your post.

Some additions (again)
Differences between make clean and make mrproper (if you need to clean the sources after a failed build). The make clean command delete the most generated files and builded objects, but keep the .config file (what contains the changes of actual defconfig) and keep enough informations to build external modules. The make mrproper command delete ALL generated files/objects, after this command you need to configure the kernel config again (make blabla_defconfig and make menuconfig for example). If you use alfsamsung sources, never use the mrproper command, because this source not contains defconfigs, only a predefined .config, the make mrproper delete it, and need to extract this file again.
About the Image and zImage: the difference between these files is only one, the Image contains the raw kernel code, the zImage starting with a decompressing code and the compressed image. When build the kernel.sin, you can use the zImage too, just rename to Image. The result is a smaller kernel, you can attach bigger ramdisk. The maximum size of the kernel (the complete kernel.sin) is around 8.300.000 byte. A typical kernel image is around 5,5MB (you can use ramdisks with maximum 2,5MB) the compressed image size is less than 3MB (you can use ramdisks around 5MB size)
As sgt. meow wrote: "Linaro just seems cool and that's why everyone wants to use it." This is the general problem in the development section, every "developer" want to make "cool" things, I think better if they concentrate to make "good" things, instead of making "cool" sh!ts...
Some tips:
If you make a kernel, never post it: based on LATEST xyz source. The latest is relative. Write a correct commit version, if you don't know what is it, need to learn before publish kernels.
To the members who have low bandwidth. Download sources as zipball, it needs less data transfer than a repository sync (when you sync a repo, you download a lot of deltas, additional files too), a typical kernel zipball is around 90MB. This method works with rom sources too (but more complicated, because you need to download and extract manually more than 200 files), for example the minicm7 sources with manual download as zipballs is only 600MB (without the prebuilts what is around additional 700MB).
If you want to be "cool" and use linaro, use the standalone linaro gcc (the arm-none-eabi version) instead of the linaro toolchain (arm-linux-gnueabi version) it will give less compiling errors.

true dat, brother.
and is minicm7 really about 1.3GB in size as zipballs? one more thing i heard (read, probably) that the zImage is the compressed version of the Image with a decompression code. so if we use that, won't booting time be a lil bit slower?
added all your suggestions bro. thanks a lot for helping out. you should apply for RC.

No, the compressed image not give significant slower boot time. All nAa kernels use compressed images, and boot faster than the alfs (the alfs8 use normal image, the alfs9 use compressed).
Yes, the minicm7 source only 614MB if you download as zipballs. For example: the settings app size is 3,5MB if you download as zip, but the git repo is around 90MB (this is an extreme example, with some part of code you can't decrease the download size).
Tips to use this method.
Make the repo init, but not start the sync. Check the default.xml in .repo/manifests, and you can see all needed repo.
You can make download links from this file in this form:
https://github.com/"name value"/zipball/"revision value"
Concrete example:
You see this line:
<project path="bootable/recovery" name="CyanogenMod/android_bootable_recovery" />
The link what you need: https://github.com/CyanogenMod/android_bootable_recovery/zipball/gingerbread
(the most line in default.xml not contains revision, if you not see it use gingerberad for minicm7, or ics for minicm9)
If the download finished, you must extract manually the downloaded file into the "project path". With this example: in your source folder you must make the bootable/recovery folder, and extract the downloaded zip into this folder (warning: the zip contains a folder named in this form - project name+commit number, you must extract the files into the "project path" folder WITHOUT this folder (you need the files INSIDE this folder))

gonna try that soon.
okay so the line has to be edited like this:
<project path="bootable/recovery name="CyanogenMod/android_bootable_recovery/zipball" />
i'm trying it on the MiniCM9 source.
oh yeah android source from googlesource can't be zipballed that way.

sgt. meow said:
gonna try that soon.
okay so the line has to be edited like this:
<project path="bootable/recovery name="CyanogenMod/android_bootable_recovery/zipball" />
i'm trying it on MiniCM9.
Click to expand...
Click to collapse
No.
The correct method for get direct links:
You can see in the default.xml: <project path="external/compcache" name="CyanogenMod/android_external_compcache" revision="master" />
The link what you need:
https://github.com/CyanogenMod/android_external_compcache/zipball/master
The text with puple color: need to write it manually
Text with green color: the repo what you need
Text with blue color: the branch name what you need. Usually you not see the revision in the default.xml, if not exist, use the default branch name (gingerbread or ics, depends on what source needed)
The downloaded file will be this: CyanogenMod-android_external_compcache-cm-7.0.0-0-g5fdea21.zip
Inside the zip package you can see a folder with same name, this folder NOT needed, go inside this folder, and extract the files into the folder what marked with orange colour.
You must do it with ALL project (over 200 files), but you need to download only 600MB, and not need to sync the repo (what is much bigger).
EDIT: You not need anything from google sources if you want CM7 (just the prebuilt binaries, but you can find it somewhere in the minicm nightlies threads, eagleeyetom uploaded it when the aosp servers was unavailable)

EDIT: what about platform/abi/cpp and some others?

sgt. meow said:
EDIT: what about platform/abi/cpp and some others?
Click to expand...
Click to collapse
Please explain it in longer form (I not understand what is the question)

i saw this line in the default.xml
<project path="abi/cpp" name="platform/abi/cpp/zipball" remote="aosp" revision="refs/tags/android-4.0.4_r2.1"/>
this is important. how do i zipball or tarball it?

sgt. meow said:
i saw this line in the default.xml
<project path="abi/cpp" name="platform/abi/cpp/zipball" remote="aosp" revision="refs/tags/android-4.0.4_r2.1"/>
this is important. how do i zipball or tarball it?
Click to expand...
Click to collapse
Okay, understand I checked only the cm7 sources, what not contains codes from aosp servers (only the prebuilt toolchains, but this is available on mediafire servers, eagleeyetom upload it when the prebuilts was unavailable ). So, at this moment no idea how to download code from google servers.
Try this: remove all minicm/cyanogenmod related lines from default.xml, leave only the lines that contains: remote="aosp", and sync the repo with only the aosp code. Or send your default.xml (just copy/paste the contents, and send it in a pm.

sorry for off-topic but @pilu you should be recognized developer

[ULTIMATE GUIDE][Noob Friendly]Compile your own android kernel from source

Hey, Guys
Today I'm going to show you a nice tutorial on how to compile your own android kernel from source, this tutorial will be a little bit focused on Sony devices as i had an experience with 'em, but that is not going to prevent that this way can be good for other manufacturers as all of them are Android based (Same programing language)
I have included screenshots and examples of codes to accompany each step of the way. :good:
On XDA Portal:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Chapters:
1.Installing Ubuntu (Alongside with Windows OS)
2.Downloading the source code
3.Installing libraries
4.Preparing the toolchain
5.Adding Features to the Kernel
6.Compiling
7.Trying out your kernel
8.Additional Tips
Click to expand...
Click to collapse
Requirments:
Ubuntu 12.04 LTS or Newer
Manufacturer sources (Links located down for most of the manufacturers)
Linaro Toolchain
Simple background about executing Linux terminals
Click to expand...
Click to collapse
1.Installing Ubuntu
As we all know, Ubuntu is free open source OS that allows you to use it alongside your already installed OS without any problems, you will be promoted at every startup to choose whether your Default OS or Ubuntu OS
So, don't get freaked guys no partitions are going to be formatted or no data loss is going to happen at all.
1)Get the Ubuntu ISO
Go to Ubuntu site (Downloads section)
Choose whether you are on 32-bit or 64-bit (We'll be assuming that we are on 32-bit)
Download the ISO then burn the ISO to DVD then boot it (or you can write install your ubuntu via usb by using this tutorial
Choose "install Ubuntu alongside your windows OS version"
Manage the partitions yourself
You got your Ubuntu ready. Time for some business
2.Downloading the Source Code
Motorola: opensource.motorola.com/
LG: http://opensource.lge.com/osList/list?m=Mc001&s=Sc002
Huawei: http://emui.huawei.com/en/plugin.php?id=hwdownload
Sony: http://developer.sonymobile.com/downloads/xperia-open-source-archives/
HTC: http://www.htcdev.com/
Samsung: http://opensource.samsung.com/
Download the TAR Source file that suits your firmware version for e.g (11.2.A.0.31)
To find your firmware version go to settings then about phone. You will see your firmware version there

Reserved
3.Installing Libraries and Preparing the Environment
As you know guys there are several libraries needed for any software to terminate properly so, if you want to succeed in compiling you have to get these libraries that we're gonna write through the Linux terminal
1)Open the Linux Terminal
2)Write these commands
Code:
sudo apt-get install -y build-essential kernel-package libncurses5-dev bzip2
Code:
sudo apt-get install lib32z1 lib32ncurses5 lib32bz2-1.0
Code:
mkdir android
3)Copy the source code archive into the folder android (that has been created throughout the “mkdir android” command
4)Run these commands
Code:
cd android
Code:
tar -xjvf [COLOR="DarkSlateBlue"]Source Name[/COLOR]
Replace Source Name with the Archive name
4.Preparing the toolchain
(You should download the whole toolchain of DoomLord, But to save our time I decided not to download the whole toolchain since that we're going to use only one folder of it)
The folder will be: arm-eabi-4.33 (Took from Linaro 4.6) (So you can consider your kernel is compiled using Linaro 4.6
Download arm-eabi-4.4.3
and extract it in the root of your home
And if you want to download the whole source run these commands
Code:
cd android
Code:
cd kernel
Code:
git clone git://github.com/DooMLoRD/android_prebuilt_toolchains.git toolchains

Reserved
5.Adding Features to the Kernel
A)Automatic Way (Using the toolchain menu)
Code:
cd android
Code:
cd kernel
Code:
ARCH=arm CROSS_COMPILE=~/arm-eabi-4.4.3/bin/arm-eabi- make Device Name
Code:
make ARCH=arm CROSS_COMPILE=~/arm-eabi-4.4.3/bin/arm-eabi- menuconfig
Replace Device Name with the configuration file found at:
Source/arch/arm/configs
It's written in this way something_DeviceCodename_user_defconfig
A menu like this will appear
Choose the features you want.
B)Manual Way
1)Adding Governors
The CPU is just 1 C file (Can be found at sources of any of kernel developers)
Get the Governor file
1.1 If you cant get it through github just view it and use other stock governor file like this
my kernel has already got performance governor, you are going to take it from Kernel Source/drivers/cpufreq/cpufreq_performance.c
Copy cpufreq_performance.c from kernel source to desktop then open it with text editor
delete all the lines in it then copy the lines from the viewed governor on github and rename the whole file name
1.2
Copy the governor C file to KernelSource/drivers/cpufreq and paste it
Open Kconfig
Then Add these lines with proper replacment
Code:
config CPU_FREQ_GOV_GOVNAMEHERE
tristate "'gov_name_lowercase' cpufreq governor"
depends on CPU_FREQ
help
governor' - a custom governor!
For BadAss (For Example)
Code:
config CPU_FREQ_DEFAULT_GOV_BADASS
bool "badass"
select CPU_FREQ_GOV_BADASS
help
Use the CPUFreq governor 'BADASS' as default
Find endchoice
Add these lines below it
Code:
config CPU_FREQ_GOV_BADASS
tristate "'badass' cpufreq governor"
depends on CPU_FREQ
help
'badass' - This driver adds a dynamic cpufreq policy governor.
The governor does a periodic polling and
changes frequency based on the CPU utilization.
The support for this governor depends on CPU capability to
do fast frequency switching (i.e, very low latency frequency
transitions).
If in doubt, say N.
1.3
Open Makefile
Add the line according to the Governor
HTML:
obj-$(CONFIG_CPU_FREQ_GOV_BADASS) += cpufreq_badass.o
1.4
Open Kernel Source/include/linux.* now open cpufreq.h
Add these lines (With Proper Replacments)
Code:
#elif defined(CONFIG_CPU_FREQ_DEFAULT_GOV_badass)
extern struct cpufreq_governor cpufreq_gov_badass;
#define CPUFREQ_DEFAULT_GOVERNOR (&cpufreq_gov_badass)
2)Adding I/O Schedulers
Get the I/O .c file as the same way you got the Governor File
Paste it to Kernel Source/block
2.1
Now Open Kconfig.iosched
Let's Assume that we now see SIO
HTML:
config IOSCHED_SIO
tristate "Simple I/O scheduler"
default y
---help---
The Simple I/O scheduler is an extremely simple scheduler,
based on noop and deadline, that relies on deadlines to
ensure fairness. The algorithm does not do any sorting but
basic merging, trying to keep a minimum overhead. It is aimed
mainly for aleatory access devices (eg: flash devices).
And we will add the I/O Scheduler VR Below it like:
We will put VR below it
HTML:
config IOSCHED_VR
tristate "V(R) I/O scheduler"
default y
---help---
Requests are chosen according to SSTF with a penalty of rev_penalty
for switching head direction.
Let's assume that we saw SIO (But in different way)
config DEFAULT_SIO
Code:
bool "sio" if IOSCHED_SIO=y
We will put VR below it
Code:
config DEFAULT_VR
bool "V(R)" if IOSCHED_VR=y
Let's assume that we saw SIO (But in another different way)
Code:
default "sio" if DEFAULT_SIO
We will put VR below it
Code:
default "vr" if DEFAULT_VR
2.2
Open the Makefile at the same folder
Lets Assume that we saw SIO And we will put VR below it
Code:
obj-$(CONFIG_IOSCHED_SIO) += sio-iosched.o
Add VR Now
Code:
[obj-$(CONFIG_IOSCHED_VR) += vr-iosched.o
Done We have added the VR I/O Scheduler !
3)Overclocking
Unfortunately, overclocking can't be told the way i said the Governors and I/O Schedulers way because every device has its specific CPU frequencies
But, here is a little help
Go to KernelSource/arch/arm/mach-msm/acpuclock-XxXX.c
You will find files like these
acpuclock-7x30.c
acpuclock-8x50.c
You will see each one of them has only .c file
except one which will have .c and .o file
the one with both .c and .o files will be edited
Explanation will be added as soon as possible

Last
6.Compiling
Part.A
Code:
cd android
Code:
cd kernel
Code:
export ARCH=arm
Code:
export CROSS_COMPILE=~/android/kernel/arm-eabi-4.4.3/bin/arm-eabi-
Part.B (Wanna do some modifications ?)
Code:
make <your_config_name>_defconfig
Replace <your_config_name> with the one found at Source/arch/arm/configs
Code:
make menuconfig
Code:
make -j<cpucore>
Replace <cpucore> with the number of cpu cores that the device has if you are on single core write 1 and if you are on dual core write 2[
Quad core=4
Octa core=8
Part.C
Code:
make clean
Code:
make oldconfig
Code:
make -j<cpucore>
Same as before.

7.Trying out your kernel
Once you have got an output which will be kernel.elf
You have now to try it
Flash it using fastboot
Whether CMD or Androxyde Flashtool
You will have to install your fastboot drivers in both ways
CMD way
Code:
fastboot -i 0x0fce flash boot kernel.elf
Using Androxyde Flashtool (XPERIA Only)
Download it from here
Install the drivers found at (C:/Flashtool/drivers/Flashtool-drivers.exe)
Press on the thunder button above
Then Choose Fastboot mode
Connect your device in fastboot
After that choose the kernel output (.ELF)
Wanna my help fast ?
Mention me or PM me
8.Additional Tips
*To find the number of cores of your CPU, just open terminal and type the following:
Code:
cd android
cd kernel
cat /proc/cpuinfo
You will find the number of cores of CPU in a tag called "cpu cores" (Great Thanks to @#buzz)
*Some other useful packages from apt-get, especially on newer Qualcomm devices. (Might help you if you want to compile whole AOSP ROMs from source)
Code:
sudo apt-get install liblz4-dev liblz4-tool lzop device-tree-compiler
(Thanks bro @savoca)
Android & GPL
Once you have done your kernel and of course you used some parts from past kernel developers, you will also have to give your sources to other people "This which is called GPL Licence"
So, the best way for this process is "GIthub"
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.
Click to expand...
Click to collapse
Credits @TheWizardOfROMs @thewadegeek @DooMLoRD @SatrioDwiPrabowo @Haze028 @abcdjdj
XDA Universty

Good tutorial ! :good::good::good:

DanielFlorin said:
Good tutorial ! :good::good::good:
Click to expand...
Click to collapse
@DanielFlorin
Thanks Bro.

Step 7 just for Sony Xperia Tamsui device like Miro , J , E , Tipo this is different with an other Xperia device so please justify and one more don't re-upload / mirror my files please use original link on my github thanks ....

Truly amazing and descriptive guide. Was thinking about making my own kernel from source just the other day and now this is up!

Nice guide well done:good:

Hi,
Great tutorial. I'm going to try it for my device!
Kernel has more than just I/O, schedulers and governers.
Are you going to expand the tutorial gradually i.e. explain other features? (Would be great if Yes)

Very good . subscribed

Nikhil said:
Hi,
Great tutorial. I'm going to try it for my device!
Kernel has more than just I/O, schedulers and governers.
Are you going to expand the tutorial gradually i.e. explain other features? (Would be great if Yes)
Click to expand...
Click to collapse
Of course bro, but the problem that for now i'm studying but if you need any thing go ahead and message me.
Dilesh Perera said:
Very good . subscribed
Click to expand...
Click to collapse
Thanks very much..... :laugh:

Thanks very much my bro......
Your comment made me really happy ^^
:thumbup:
Sent from my ST26i using XDA Free mobile app

What a coincidence!!
Eliminator79 said:
XDA Universty
Click to expand...
Click to collapse
I don't know whether it a coincidence or not but I have exactly the same wallpaper applied on to my Ubuntu 14.04 x64 bit operating system also with dual boot of Windows 7 Ultimate along side Ubuntu.
Also the second coincidence is, I made the same tutorial on building kernel except for the fact that it is for building linux kernel rather than an android kernel.
Anyway, Good Job! :good:
---------- Post added at 07:13 AM ---------- Previous post was at 07:03 AM ----------
Eliminator79 said:
Code:
make -j<cpucore>"
Replace <cpucore> with the number of cpu cores that the device has if you are on single core write 1 and if you are on dual core write 2
Click to expand...
Click to collapse
To find the number of cores of your CPU, just open terminal and type the following:
Code:
cat /proc/cpuinfo
You will find the number of cores of CPU in a tag called "cpu cores"
Hope that helps.
@Eliminator79 You can add this to your guide.

Eliminator79 said:
3.Installing Libraries and Preparing the Environment
As you know guys there are several libraries needed for any software to be successful so if you want to succeed in compilng you have to get the libraries that i'm going to write through the Linux Terminal
1)Open the Linux Terminal
2)Write these commands
Code:
sudo apt-get install -y build-essential kernel-package libncurses5-dev bzip2
Click to expand...
Click to collapse
Some other useful packages from apt-get, especially on newer qcom devices.
Code:
sudo apt-get install liblz4-dev liblz4-tool lzop device-tree-compiler
#buzz said:
To find the number of cores of your CPU, just open terminal and type the following:
Code:
cat /proc/cpuinfo
You will find the number of cores of CPU in a tag called "cpu cores"
Hope that helps.
@Eliminator79 You can add this to your guide.
Click to expand...
Click to collapse
Code:
make -j$(grep -c ^processor /proc/cpuinfo)
^ Works as well, and it's universal.

Wow, I was always curious how people do it. Thanks a lot man.

Nikhil said:
Hi,
Great tutorial. I'm going to try it for my device!
Kernel has more than just I/O, schedulers and governers.
Are you going to expand the tutorial gradually i.e. explain other features? (Would be great if Yes)
Click to expand...
Click to collapse
+1

Thanks a lot!
You got me what I wanted! :victory:

savoca said:
Some other useful packages from apt-get, especially on newer qcom devices.
Code:
sudo apt-get install liblz4-dev liblz4-tool lzop device-tree-compiler
Code:
make -j$(grep -c ^processor /proc/cpuinfo)
^ Works as well, and it's universal.
Click to expand...
Click to collapse
@savoca Thanks so much dude.
Do you give me permisssions to add these tips to the post ?
You motivated me alot bro...Thanks
DarkFalcon said:
Thanks a lot!
You got me what I wanted! :victory:
Click to expand...
Click to collapse
Anytime bro
#buzz said:
I don't know whether it a coincidence or not but I have exactly the same wallpaper applied on to my Ubuntu 14.04 x64 bit operating system also with dual boot of Windows 7 Ultimate along side Ubuntu.
Also the second coincidence is, I made the same tutorial on building kernel except for the fact that it is for building linux kernel rather than an android kernel.
Anyway, Good Job! :good:
---------- Post added at 07:13 AM ---------- Previous post was at 07:03 AM ----------
To find the number of cores of your CPU, just open terminal and type the following:
Code:
cat /proc/cpuinfo
You will find the number of cores of CPU in a tag called "cpu cores"
Hope that helps.
@Eliminator79 You can add this to your guide.
Click to expand...
Click to collapse

Samsung Galaxy Grand Duos Oreo Kernel Source

Samsung Galaxy Grand Duos Oreo Kernel Source​
download link-> bottom of the thread.
Linux kernel release 3.x <http://kernel.org/>
These are the release notes for Linux version 3. Read them carefully,
as they tell you what this is all about, explain how to install the
kernel, and what to do if something goes wrong!!
WHAT IS LINUX?
Linux is a clone of the operating system Unix, written from scratch by
Linus Torvalds with assistance from a loosely-knit team of hackers across
the Net. It aims towards POSIX and Single UNIX Specification compliance.
It has all the features you would expect in a modern fully-fledged Unix,
including true multitasking, virtual memory, shared libraries, demand
loading, shared copy-on-write executables, proper memory management,
and multistack networking including IPv4 and IPv6.
It is distributed under the GNU General Public License - see the
accompanying COPYING file for more details.
ON WHAT HARDWARE DOES IT RUN?
Although originally developed first for 32-bit x86-based PCs (386 or higher),
today Linux also runs on (at least) the Compaq Alpha AXP, Sun SPARC and
UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, Cell,
IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64, AXIS CRIS,
Xtensa, Tilera TILE, AVR32 and Renesas M32R architectures.
Linux is easily portable to most general-purpose 32- or 64-bit architectures
as long as they have a paged memory management unit (PMMU) and a port of the
GNU C compiler (gcc) (part of The GNU Compiler Collection, GCC). Linux has
also been ported to a number of architectures without a PMMU, although
functionality is then obviously somewhat limited.
Linux has also been ported to itself. You can now run the kernel as a
userspace application - this is called UserMode Linux (UML).
DOCUMENTATION:
- There is a lot of documentation available both in electronic form on
the Internet and in books, both Linux-specific and pertaining to
general UNIX questions. I'd recommend looking into the documentation
subdirectories on any Linux FTP site for the LDP (Linux Documentation
Project) books. This README is not meant to be documentation on the
system: there are much better sources available.
- There are various README files in the Documentation/ subdirectory:
these typically contain kernel-specific installation notes for some
drivers for example. See Documentation/00-INDEX for a list of what
is contained in each file. Please read the Changes file, as it
contains information about the problems, which may result by upgrading
your kernel.
- The Documentation/DocBook/ subdirectory contains several guides for
kernel developers and users. These guides can be rendered in a
number of formats: PostScript (.ps), PDF, HTML, & man-pages, among others.
After installation, "make psdocs", "make pdfdocs", "make htmldocs",
or "make mandocs" will render the documentation in the requested format.
INSTALLING the kernel source:
- If you install the full sources, put the kernel tarball in a
directory where you have permissions (eg. your home directory) and
unpack it:
gzip -cd linux-3.X.tar.gz | tar xvf -
or
bzip2 -dc linux-3.X.tar.bz2 | tar xvf -
Replace "XX" with the version number of the latest kernel.
Do NOT use the /usr/src/linux area! This area has a (usually
incomplete) set of kernel headers that are used by the library header
files. They should match the library, and not get messed up by
whatever the kernel-du-jour happens to be.
- You can also upgrade between 3.x releases by patching. Patches are
distributed in the traditional gzip and the newer bzip2 format. To
install by patching, get all the newer patch files, enter the
top level directory of the kernel source (linux-3.x) and execute:
gzip -cd ../patch-3.x.gz | patch -p1
or
bzip2 -dc ../patch-3.x.bz2 | patch -p1
(repeat xx for all versions bigger than the version of your current
source tree, _in_order_) and you should be ok. You may want to remove
the backup files (xxx~ or xxx.orig), and make sure that there are no
failed patches (xxx# or xxx.rej). If there are, either you or me has
made a mistake.
Unlike patches for the 3.x kernels, patches for the 3.x.y kernels
(also known as the -stable kernels) are not incremental but instead apply
directly to the base 3.x kernel. Please read
Documentation/applying-patches.txt for more information.
Alternatively, the script patch-kernel can be used to automate this
process. It determines the current kernel version and applies any
patches found.
linux/scripts/patch-kernel linux
The first argument in the command above is the location of the
kernel source. Patches are applied from the current directory, but
an alternative directory can be specified as the second argument.
- If you are upgrading between releases using the stable series patches
(for example, patch-3.x.y), note that these "dot-releases" are
not incremental and must be applied to the 3.x base tree. For
example, if your base kernel is 3.0 and you want to apply the
3.0.3 patch, you do not and indeed must not first apply the
3.0.1 and 3.0.2 patches. Similarly, if you are running kernel
version 3.0.2 and want to jump to 3.0.3, you must first
reverse the 3.0.2 patch (that is, patch -R) _before_ applying
the 3.0.3 patch.
You can read more on this in Documentation/applying-patches.txt
- Make sure you have no stale .o files and dependencies lying around:
cd linux
make mrproper
You should now have the sources correctly installed.
SOFTWARE REQUIREMENTS
Compiling and running the 3.x kernels requires up-to-date
versions of various software packages. Consult
Documentation/Changes for the minimum version numbers required
and how to get updates for these packages. Beware that using
excessively old versions of these packages can cause indirect
errors that are very difficult to track down, so don't assume that
you can just update packages when obvious problems arise during
build or operation.
BUILD directory for the kernel:
When compiling the kernel all output files will per default be
stored together with the kernel source code.
Using the option "make O=output/dir" allow you to specify an alternate
place for the output files (including .config).
Example:
kernel source code: /usr/src/linux-3.N
build directory: /home/name/build/kernel
To configure and build the kernel use:
cd /usr/src/linux-3.N
make O=/home/name/build/kernel menuconfig
make O=/home/name/build/kernel
sudo make O=/home/name/build/kernel modules_install install
Please note: If the 'O=output/dir' option is used then it must be
used for all invocations of make.
CONFIGURING the kernel:
Do not skip this step even if you are only upgrading one minor
version. New configuration options are added in each release, and
odd problems will turn up if the configuration files are not set up
as expected. If you want to carry your existing configuration to a
new version with minimal work, use "make oldconfig", which will
only ask you for the answers to new questions.
- Alternate configuration commands are:
"make config" Plain text interface.
"make menuconfig" Text based color menus, radiolists & dialogs.
"make nconfig" Enhanced text based color menus.
"make xconfig" X windows (Qt) based configuration tool.
"make gconfig" X windows (Gtk) based configuration tool.
"make oldconfig" Default all questions based on the contents of
your existing ./.config file and asking about
new config symbols.
"make silentoldconfig"
Like above, but avoids cluttering the screen
with questions already answered.
Additionally updates the dependencies.
"make defconfig" Create a ./.config file by using the default
symbol values from either arch/$ARCH/defconfig
or arch/$ARCH/configs/${PLATFORM}_defconfig,
depending on the architecture.
"make ${PLATFORM}_defconfig"
Create a ./.config file by using the default
symbol values from
arch/$ARCH/configs/${PLATFORM}_defconfig.
Use "make help" to get a list of all available
platforms of your architecture.
"make allyesconfig"
Create a ./.config file by setting symbol
values to 'y' as much as possible.
"make allmodconfig"
Create a ./.config file by setting symbol
values to 'm' as much as possible.
"make allnoconfig" Create a ./.config file by setting symbol
values to 'n' as much as possible.
"make randconfig" Create a ./.config file by setting symbol
values to random values.
You can find more information on using the Linux kernel config tools
in Documentation/kbuild/kconfig.txt.
NOTES on "make config":
- having unnecessary drivers will make the kernel bigger, and can
under some circumstances lead to problems: probing for a
nonexistent controller card may confuse your other controllers
- compiling the kernel with "Processor type" set higher than 386
will result in a kernel that does NOT work on a 386. The
kernel will detect this on bootup, and give up.
- A kernel with math-emulation compiled in will still use the
coprocessor if one is present: the math emulation will just
never get used in that case. The kernel will be slightly larger,
but will work on different machines regardless of whether they
have a math coprocessor or not.
- the "kernel hacking" configuration details usually result in a
bigger or slower kernel (or both), and can even make the kernel
less stable by configuring some routines to actively try to
break bad code to find kernel problems (kmalloc()). Thus you
should probably answer 'n' to the questions for
"development", "experimental", or "debugging" features.
COMPILING the kernel:
- Make sure you have at least gcc 3.2 available.
For more information, refer to Documentation/Changes.
Please note that you can still run a.out user programs with this kernel.
- Do a "make" to create a compressed kernel image. It is also
possible to do "make install" if you have lilo installed to suit the
kernel makefiles, but you may want to check your particular lilo setup first.
To do the actual install you have to be root, but none of the normal
build should require that. Don't take the name of root in vain.
- If you configured any of the parts of the kernel as `modules', you
will also have to do "make modules_install".
- Verbose kernel compile/build output:
Normally the kernel build system runs in a fairly quiet mode (but not
totally silent). However, sometimes you or other kernel developers need
to see compile, link, or other commands exactly as they are executed.
For this, use "verbose" build mode. This is done by inserting
"V=1" in the "make" command. E.g.:
make V=1 all
To have the build system also tell the reason for the rebuild of each
target, use "V=2". The default is "V=0".
- Keep a backup kernel handy in case something goes wrong. This is
especially true for the development releases, since each new release
contains new code which has not been debugged. Make sure you keep a
backup of the modules corresponding to that kernel, as well. If you
are installing a new kernel with the same version number as your
working kernel, make a backup of your modules directory before you
do a "make modules_install".
Alternatively, before compiling, use the kernel config option
"LOCALVERSION" to append a unique suffix to the regular kernel version.
LOCALVERSION can be set in the "General Setup" menu.
- In order to boot your new kernel, you'll need to copy the kernel
image (e.g. .../linux/arch/i386/boot/bzImage after compilation)
to the place where your regular bootable kernel is found.
- Booting a kernel directly from a floppy without the assistance of a
bootloader such as LILO, is no longer supported.
If you boot Linux from the hard drive, chances are you use LILO which
uses the kernel image as specified in the file /etc/lilo.conf. The
kernel image file is usually /vmlinuz, /boot/vmlinuz, /bzImage or
/boot/bzImage. To use the new kernel, save a copy of the old image
and copy the new image over the old one. Then, you MUST RERUN LILO
to update the loading map!! If you don't, you won't be able to boot
the new kernel image.
Reinstalling LILO is usually a matter of running /sbin/lilo.
You may wish to edit /etc/lilo.conf to specify an entry for your
old kernel image (say, /vmlinux.old) in case the new one does not
work. See the LILO docs for more information.
After reinstalling LILO, you should be all set. Shutdown the system,
reboot, and enjoy!
If you ever need to change the default root device, video mode,
ramdisk size, etc. in the kernel image, use the 'rdev' program (or
alternatively the LILO boot options when appropriate). No need to
recompile the kernel to change these parameters.
- Reboot with the new kernel and enjoy.
IF SOMETHING GOES WRONG:
- If you have problems that seem to be due to kernel bugs, please check
the file MAINTAINERS to see if there is a particular person associated
with the part of the kernel that you are having trouble with. If there
isn't anyone listed there, then the second best thing is to mail
them to me ([email protected]), and possibly to any other
relevant mailing-list or to the newsgroup.
- In all bug-reports, *please* tell what kernel you are talking about,
how to duplicate the problem, and what your setup is (use your common
sense). If the problem is new, tell me so, and if the problem is
old, please try to tell me when you first noticed it.
- If the bug results in a message like
unable to handle kernel paging request at address C0000010
Oops: 0002
EIP: 0010:XXXXXXXX
eax: xxxxxxxx ebx: xxxxxxxx ecx: xxxxxxxx edx: xxxxxxxx
esi: xxxxxxxx edi: xxxxxxxx ebp: xxxxxxxx
ds: xxxx es: xxxx fs: xxxx gs: xxxx
Pid: xx, process nr: xx
xx xx xx xx xx xx xx xx xx xx
or similar kernel debugging information on your screen or in your
system log, please duplicate it *exactly*. The dump may look
incomprehensible to you, but it does contain information that may
help debugging the problem. The text above the dump is also
important: it tells something about why the kernel dumped code (in
the above example it's due to a bad kernel pointer). More information
on making sense of the dump is in Documentation/oops-tracing.txt
- If you compiled the kernel with CONFIG_KALLSYMS you can send the dump
as is, otherwise you will have to use the "ksymoops" program to make
sense of the dump (but compiling with CONFIG_KALLSYMS is usually preferred).
This utility can be downloaded from
ftp://ftp.<country>.kernel.org/pub/linux/utils/kernel/ksymoops/ .
Alternately you can do the dump lookup by hand:
- In debugging dumps like the above, it helps enormously if you can
look up what the EIP value means. The hex value as such doesn't help
me or anybody else very much: it will depend on your particular
kernel setup. What you should do is take the hex value from the EIP
line (ignore the "0010:"), and look it up in the kernel namelist to
see which kernel function contains the offending address.
To find out the kernel function name, you'll need to find the system
binary associated with the kernel that exhibited the symptom. This is
the file 'linux/vmlinux'. To extract the namelist and match it against
the EIP from the kernel crash, do:
nm vmlinux | sort | less
This will give you a list of kernel addresses sorted in ascending
order, from which it is simple to find the function that contains the
offending address. Note that the address given by the kernel
debugging messages will not necessarily match exactly with the
function addresses (in fact, that is very unlikely), so you can't
just 'grep' the list: the list will, however, give you the starting
point of each kernel function, so by looking for the function that
has a starting address lower than the one you are searching for but
is followed by a function with a higher address you will find the one
you want. In fact, it may be a good idea to include a bit of
"context" in your problem report, giving a few lines around the
interesting one.
If you for some reason cannot do the above (you have a pre-compiled
kernel image or similar), telling me as much about your setup as
possible will help. Please read the REPORTING-BUGS document for details.
- Alternately, you can use gdb on a running kernel. (read-only; i.e. you
cannot change values or set break points.) To do this, first compile the
kernel with -g; edit arch/i386/Makefile appropriately, then do a "make
clean". You'll also need to enable CONFIG_PROC_FS (via "make config").
After you've rebooted with the new kernel, do "gdb vmlinux /proc/kcore".
You can now use all the usual gdb commands. The command to look up the
point where your system crashed is "l *0xXXXXXXXX". (Replace the XXXes
with the EIP value.)
gdb'ing a non-running kernel currently fails because gdb (wrongly)
disregards the starting offset for which the kernel is compiled.
Download.​
OREO KERNEL SOURCE 3.x
credits:-
@osas514
@GHsR

vasanth36 said:
Samsung Galaxy Grand Duos Oreo Kernel Source​
download link-> bottom of the thread.
Linux kernel release 3.x <http://kernel.org/>
These are the release notes for Linux version 3. Read them carefully,
as they tell you what this is all about, explain how to install the
kernel, and what to do if something goes wrong!!
WHAT IS LINUX?
Linux is a clone of the operating system Unix, written from scratch by
Linus Torvalds with assistance from a loosely-knit team of hackers across
the Net. It aims towards POSIX and Single UNIX Specification compliance.
It has all the features you would expect in a modern fully-fledged Unix,
including true multitasking, virtual memory, shared libraries, demand
loading, shared copy-on-write executables, proper memory management,
and multistack networking including IPv4 and IPv6.
It is distributed under the GNU General Public License - see the
accompanying COPYING file for more details.
ON WHAT HARDWARE DOES IT RUN?
Although originally developed first for 32-bit x86-based PCs (386 or higher),
today Linux also runs on (at least) the Compaq Alpha AXP, Sun SPARC and
UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, Cell,
IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64, AXIS CRIS,
Xtensa, Tilera TILE, AVR32 and Renesas M32R architectures.
Linux is easily portable to most general-purpose 32- or 64-bit architectures
as long as they have a paged memory management unit (PMMU) and a port of the
GNU C compiler (gcc) (part of The GNU Compiler Collection, GCC). Linux has
also been ported to a number of architectures without a PMMU, although
functionality is then obviously somewhat limited.
Linux has also been ported to itself. You can now run the kernel as a
userspace application - this is called UserMode Linux (UML).
DOCUMENTATION:
- There is a lot of documentation available both in electronic form on
the Internet and in books, both Linux-specific and pertaining to
general UNIX questions. I'd recommend looking into the documentation
subdirectories on any Linux FTP site for the LDP (Linux Documentation
Project) books. This README is not meant to be documentation on the
system: there are much better sources available.
- There are various README files in the Documentation/ subdirectory:
these typically contain kernel-specific installation notes for some
drivers for example. See Documentation/00-INDEX for a list of what
is contained in each file. Please read the Changes file, as it
contains information about the problems, which may result by upgrading
your kernel.
- The Documentation/DocBook/ subdirectory contains several guides for
kernel developers and users. These guides can be rendered in a
number of formats: PostScript (.ps), PDF, HTML, & man-pages, among others.
After installation, "make psdocs", "make pdfdocs", "make htmldocs",
or "make mandocs" will render the documentation in the requested format.
INSTALLING the kernel source:
- If you install the full sources, put the kernel tarball in a
directory where you have permissions (eg. your home directory) and
unpack it:
gzip -cd linux-3.X.tar.gz | tar xvf -
or
bzip2 -dc linux-3.X.tar.bz2 | tar xvf -
Replace "XX" with the version number of the latest kernel.
Do NOT use the /usr/src/linux area! This area has a (usually
incomplete) set of kernel headers that are used by the library header
files. They should match the library, and not get messed up by
whatever the kernel-du-jour happens to be.
- You can also upgrade between 3.x releases by patching. Patches are
distributed in the traditional gzip and the newer bzip2 format. To
install by patching, get all the newer patch files, enter the
top level directory of the kernel source (linux-3.x) and execute:
gzip -cd ../patch-3.x.gz | patch -p1
or
bzip2 -dc ../patch-3.x.bz2 | patch -p1
(repeat xx for all versions bigger than the version of your current
source tree, _in_order_) and you should be ok. You may want to remove
the backup files (xxx~ or xxx.orig), and make sure that there are no
failed patches (xxx# or xxx.rej). If there are, either you or me has
made a mistake.
Unlike patches for the 3.x kernels, patches for the 3.x.y kernels
(also known as the -stable kernels) are not incremental but instead apply
directly to the base 3.x kernel. Please read
Documentation/applying-patches.txt for more information.
Alternatively, the script patch-kernel can be used to automate this
process. It determines the current kernel version and applies any
patches found.
linux/scripts/patch-kernel linux
The first argument in the command above is the location of the
kernel source. Patches are applied from the current directory, but
an alternative directory can be specified as the second argument.
- If you are upgrading between releases using the stable series patches
(for example, patch-3.x.y), note that these "dot-releases" are
not incremental and must be applied to the 3.x base tree. For
example, if your base kernel is 3.0 and you want to apply the
3.0.3 patch, you do not and indeed must not first apply the
3.0.1 and 3.0.2 patches. Similarly, if you are running kernel
version 3.0.2 and want to jump to 3.0.3, you must first
reverse the 3.0.2 patch (that is, patch -R) _before_ applying
the 3.0.3 patch.
You can read more on this in Documentation/applying-patches.txt
- Make sure you have no stale .o files and dependencies lying around:
cd linux
make mrproper
You should now have the sources correctly installed.
SOFTWARE REQUIREMENTS
Compiling and running the 3.x kernels requires up-to-date
versions of various software packages. Consult
Documentation/Changes for the minimum version numbers required
and how to get updates for these packages. Beware that using
excessively old versions of these packages can cause indirect
errors that are very difficult to track down, so don't assume that
you can just update packages when obvious problems arise during
build or operation.
BUILD directory for the kernel:
When compiling the kernel all output files will per default be
stored together with the kernel source code.
Using the option "make O=output/dir" allow you to specify an alternate
place for the output files (including .config).
Example:
kernel source code: /usr/src/linux-3.N
build directory: /home/name/build/kernel
To configure and build the kernel use:
cd /usr/src/linux-3.N
make O=/home/name/build/kernel menuconfig
make O=/home/name/build/kernel
sudo make O=/home/name/build/kernel modules_install install
Please note: If the 'O=output/dir' option is used then it must be
used for all invocations of make.
CONFIGURING the kernel:
Do not skip this step even if you are only upgrading one minor
version. New configuration options are added in each release, and
odd problems will turn up if the configuration files are not set up
as expected. If you want to carry your existing configuration to a
new version with minimal work, use "make oldconfig", which will
only ask you for the answers to new questions.
- Alternate configuration commands are:
"make config" Plain text interface.
"make menuconfig" Text based color menus, radiolists & dialogs.
"make nconfig" Enhanced text based color menus.
"make xconfig" X windows (Qt) based configuration tool.
"make gconfig" X windows (Gtk) based configuration tool.
"make oldconfig" Default all questions based on the contents of
your existing ./.config file and asking about
new config symbols.
"make silentoldconfig"
Like above, but avoids cluttering the screen
with questions already answered.
Additionally updates the dependencies.
"make defconfig" Create a ./.config file by using the default
symbol values from either arch/$ARCH/defconfig
or arch/$ARCH/configs/${PLATFORM}_defconfig,
depending on the architecture.
"make ${PLATFORM}_defconfig"
Create a ./.config file by using the default
symbol values from
arch/$ARCH/configs/${PLATFORM}_defconfig.
Use "make help" to get a list of all available
platforms of your architecture.
"make allyesconfig"
Create a ./.config file by setting symbol
values to 'y' as much as possible.
"make allmodconfig"
Create a ./.config file by setting symbol
values to 'm' as much as possible.
"make allnoconfig" Create a ./.config file by setting symbol
values to 'n' as much as possible.
"make randconfig" Create a ./.config file by setting symbol
values to random values.
You can find more information on using the Linux kernel config tools
in Documentation/kbuild/kconfig.txt.
NOTES on "make config":
- having unnecessary drivers will make the kernel bigger, and can
under some circumstances lead to problems: probing for a
nonexistent controller card may confuse your other controllers
- compiling the kernel with "Processor type" set higher than 386
will result in a kernel that does NOT work on a 386. The
kernel will detect this on bootup, and give up.
- A kernel with math-emulation compiled in will still use the
coprocessor if one is present: the math emulation will just
never get used in that case. The kernel will be slightly larger,
but will work on different machines regardless of whether they
have a math coprocessor or not.
- the "kernel hacking" configuration details usually result in a
bigger or slower kernel (or both), and can even make the kernel
less stable by configuring some routines to actively try to
break bad code to find kernel problems (kmalloc()). Thus you
should probably answer 'n' to the questions for
"development", "experimental", or "debugging" features.
COMPILING the kernel:
- Make sure you have at least gcc 3.2 available.
For more information, refer to Documentation/Changes.
Please note that you can still run a.out user programs with this kernel.
- Do a "make" to create a compressed kernel image. It is also
possible to do "make install" if you have lilo installed to suit the
kernel makefiles, but you may want to check your particular lilo setup first.
To do the actual install you have to be root, but none of the normal
build should require that. Don't take the name of root in vain.
- If you configured any of the parts of the kernel as `modules', you
will also have to do "make modules_install".
- Verbose kernel compile/build output:
Normally the kernel build system runs in a fairly quiet mode (but not
totally silent). However, sometimes you or other kernel developers need
to see compile, link, or other commands exactly as they are executed.
For this, use "verbose" build mode. This is done by inserting
"V=1" in the "make" command. E.g.:
make V=1 all
To have the build system also tell the reason for the rebuild of each
target, use "V=2". The default is "V=0".
- Keep a backup kernel handy in case something goes wrong. This is
especially true for the development releases, since each new release
contains new code which has not been debugged. Make sure you keep a
backup of the modules corresponding to that kernel, as well. If you
are installing a new kernel with the same version number as your
working kernel, make a backup of your modules directory before you
do a "make modules_install".
Alternatively, before compiling, use the kernel config option
"LOCALVERSION" to append a unique suffix to the regular kernel version.
LOCALVERSION can be set in the "General Setup" menu.
- In order to boot your new kernel, you'll need to copy the kernel
image (e.g. .../linux/arch/i386/boot/bzImage after compilation)
to the place where your regular bootable kernel is found.
- Booting a kernel directly from a floppy without the assistance of a
bootloader such as LILO, is no longer supported.
If you boot Linux from the hard drive, chances are you use LILO which
uses the kernel image as specified in the file /etc/lilo.conf. The
kernel image file is usually /vmlinuz, /boot/vmlinuz, /bzImage or
/boot/bzImage. To use the new kernel, save a copy of the old image
and copy the new image over the old one. Then, you MUST RERUN LILO
to update the loading map!! If you don't, you won't be able to boot
the new kernel image.
Reinstalling LILO is usually a matter of running /sbin/lilo.
You may wish to edit /etc/lilo.conf to specify an entry for your
old kernel image (say, /vmlinux.old) in case the new one does not
work. See the LILO docs for more information.
After reinstalling LILO, you should be all set. Shutdown the system,
reboot, and enjoy!
If you ever need to change the default root device, video mode,
ramdisk size, etc. in the kernel image, use the 'rdev' program (or
alternatively the LILO boot options when appropriate). No need to
recompile the kernel to change these parameters.
- Reboot with the new kernel and enjoy.
IF SOMETHING GOES WRONG:
- If you have problems that seem to be due to kernel bugs, please check
the file MAINTAINERS to see if there is a particular person associated
with the part of the kernel that you are having trouble with. If there
isn't anyone listed there, then the second best thing is to mail
them to me ([email protected]), and possibly to any other
relevant mailing-list or to the newsgroup.
- In all bug-reports, *please* tell what kernel you are talking about,
how to duplicate the problem, and what your setup is (use your common
sense). If the problem is new, tell me so, and if the problem is
old, please try to tell me when you first noticed it.
- If the bug results in a message like
unable to handle kernel paging request at address C0000010
Oops: 0002
EIP: 0010:XXXXXXXX
eax: xxxxxxxx ebx: xxxxxxxx ecx: xxxxxxxx edx: xxxxxxxx
esi: xxxxxxxx edi: xxxxxxxx ebp: xxxxxxxx
ds: xxxx es: xxxx fs: xxxx gs: xxxx
Pid: xx, process nr: xx
xx xx xx xx xx xx xx xx xx xx
or similar kernel debugging information on your screen or in your
system log, please duplicate it *exactly*. The dump may look
incomprehensible to you, but it does contain information that may
help debugging the problem. The text above the dump is also
important: it tells something about why the kernel dumped code (in
the above example it's due to a bad kernel pointer). More information
on making sense of the dump is in Documentation/oops-tracing.txt
- If you compiled the kernel with CONFIG_KALLSYMS you can send the dump
as is, otherwise you will have to use the "ksymoops" program to make
sense of the dump (but compiling with CONFIG_KALLSYMS is usually preferred).
This utility can be downloaded from
ftp://ftp.<country>.kernel.org/pub/linux/utils/kernel/ksymoops/ .
Alternately you can do the dump lookup by hand:
- In debugging dumps like the above, it helps enormously if you can
look up what the EIP value means. The hex value as such doesn't help
me or anybody else very much: it will depend on your particular
kernel setup. What you should do is take the hex value from the EIP
line (ignore the "0010:"), and look it up in the kernel namelist to
see which kernel function contains the offending address.
To find out the kernel function name, you'll need to find the system
binary associated with the kernel that exhibited the symptom. This is
the file 'linux/vmlinux'. To extract the namelist and match it against
the EIP from the kernel crash, do:
nm vmlinux | sort | less
This will give you a list of kernel addresses sorted in ascending
order, from which it is simple to find the function that contains the
offending address. Note that the address given by the kernel
debugging messages will not necessarily match exactly with the
function addresses (in fact, that is very unlikely), so you can't
just 'grep' the list: the list will, however, give you the starting
point of each kernel function, so by looking for the function that
has a starting address lower than the one you are searching for but
is followed by a function with a higher address you will find the one
you want. In fact, it may be a good idea to include a bit of
"context" in your problem report, giving a few lines around the
interesting one.
If you for some reason cannot do the above (you have a pre-compiled
kernel image or similar), telling me as much about your setup as
possible will help. Please read the REPORTING-BUGS document for details.
- Alternately, you can use gdb on a running kernel. (read-only; i.e. you
cannot change values or set break points.) To do this, first compile the
kernel with -g; edit arch/i386/Makefile appropriately, then do a "make
clean". You'll also need to enable CONFIG_PROC_FS (via "make config").
After you've rebooted with the new kernel, do "gdb vmlinux /proc/kcore".
You can now use all the usual gdb commands. The command to look up the
point where your system crashed is "l *0xXXXXXXXX". (Replace the XXXes
with the EIP value.)
gdb'ing a non-running kernel currently fails because gdb (wrongly)
disregards the starting offset for which the kernel is compiled.
Download.​
OREO KERNEL SOURCE 3.x
credits:-
@osas514
@GHsR
Click to expand...
Click to collapse
How is it going to help us?

Repo deleted