Database Users

[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

Problems Unpacking/Packing kernel

Hi!
I am trying to create a custom kernel for my Galaxy Note 3. I have successfully modified and built the kernel. Now I want to actually test it. I've searched for possible methods to create a boot.img file from my zImage. I've tried
mkbootimg and unmkbootimg
kernel kitchen
I was able to create a boot.img with both methods and both of them failed to boot. I thought I messed up the kernel, BUT then I tried to just unpack a stock boot.img and repack it again - and this also failed with both methods.
Seeing as there are already people who made custom kernels for the Note 3, I'm wondering what I am doing wrong. Also I'm a bit new to this, that may also be a factor. Could someone possibly give a hint what might be going awry? Will of course provide additional information, if required.
Edit: nevermind that, found out I need Snapdragon 800 patched mkbootimg tools. found binary versions of them on github (Can't post link because I'm a new user). unsure where the source code is though.

New file_contexts.bin format and make_ext4fs

Trying to alter a stock ROM and resign with my own custom key just for myself. This process will allow me to use a device with custom changes (NOT root), but still allow me to use Android Pay.
This process involves using the "make_ext4fs" tool. However, this tool (as far as I can tell) requires using the old plaintext version of "file_contexts". Android 7+ uses a new binary version of this file instead ("file_contexts.bin").
So if anyone can solve either of these questions, I would be very grateful:
1) Is there a tool to convert my device's binary "file_contexts.bin" to the old plaintext "file_contexts"? -OR-
2) Is there a build of "make_ext4fs" that accepts the new binary format "file_contexts.bin"? I tried to build the new nougat version myself from AOSP, but after a successful build of the tool, I can't get the thing to read files on either 64-bit or 32-bit systems. It yields an error "No such file or directory" when trying to point to file_contexts. I am not a great C developer, so I don't know if I built it wrong. For reference, no, I am not missing the lib32stdc++6 libraries. I have attached the binary if you want to see if you can get it to work. -OR-
3) If anyone has the file_contexts text file for the OnePlus 3, ROM version 7.X Nougat, that would work too!​
Any help anyone can offer in any way would be fantastic! Thank you so much for your time to look at this!

A good question

1) yes, see my signature

munjeni said:
1) yes, see my signature
Click to expand...
Click to collapse
I'm trying to do the same with a 7.1.1. rom. I convert the file_contexts.bin to file_contexts, unpack the rom, do the modifications to the rom, repack the rom then replace the original system.new.dat and system.transfer.list with the newly packed ones (original file_contexts.bin is still in the original zip) and when I go to flash it in TWRP it doesn't flash the system and I get a No OS installed Is there something I have to do to the file_contexts.bin after I repack the system.new.dat?

"file_contexts.bin" to the old plaintext "file_contexts" tool: http://blog.cofface.com/archives/2255.html

puargs said:
I tried to build the new nougat version myself from AOSP, but after a successful build of the tool, I can't get the thing to read files on either 64-bit or 32-bit systems. It yields an error "No such file or directory" when trying to point to file_contexts. I am not a great C developer, so I don't know if I built it wrong. For reference, no, I am not missing the lib32stdc++6 libraries.
Click to expand...
Click to collapse
Try building with the pie (Position Independent Executable) flag. Had this exact same problem when trying to compile a CVE for android.
Hopefully this should work for you and sorry for the Necro post

[TOOLS] Necessary tools for building the Pixel 2 (XL) Kernel

THIS IS NOT A "HOW TO BUILD A KERNEL" POST
The Pixel 2, unlike other phones I've worked with, requires two extra tools: dtc (Device Tree Compiler) and mkdtimg.
Yes, dtc is available in the main repos for most linux distros, but the Pixel 2 kernel requires the AOSP modified version of dtc.
First, grab the Pixel 2 + XL Unified kernel source (wahoo) from https://android.googlesource.com/kernel/msm/+/android-msm-wahoo-4.4-oreo-dr1
Then download wahoo-kernel-tools.zip file attatched to this post and unzip it. Make sure that the 2 files in the bin folder are available in your path (possibly by moving them to ~/bin) and symlink or move the libc++.so into an included library directory, such as /lib, /usr/lib, or /usr/local/lib.
These specific binaries were compiled on Arch Linux by me, so they may not work on every system. To build binaries compatible with your system, sync any android oreo source (AOSP, Lineage, Carbon, etc.) and run "make dtc mkdtimage -jX" instead of "make bacon" or your normal command. The binaries will be located in out/host/linux-x86/.
This is tested and working with the stock google 4.9 toolchain and the initial source as of Oct 23rd, 2017.

frap129 said:
THIS IS NOT A "HOW TO BUILD A KERNEL" POST
The Pixel 2, unlike other phones I've worked with, requires two extra tools: dtc (Device Tree Compiler) and mkdtimg.
Yes, dtc is available in the main repos for most linux distros, but the Pixel 2 kernel requires the AOSP modified version of dtc.
First, grab the Pixel 2 + XL Unified kernel source (wahoo) from https://android.googlesource.com/kernel/msm/+/android-msm-wahoo-4.4-oreo-dr1
Then download wahoo-kernel-tools.zip file attatched to this post and unzip it. Make sure that the 2 files in the bin folder are available in your path (possibly by moving them to ~/bin) and symlink or move the libc++.so into an included library directory, such as /lib, /usr/lib, or /usr/local/lib.
These specific binaries were compiled on Arch Linux by me, so they may not work on every system. To build binaries compatible with your system, sync any android oreo source (AOSP, Lineage, Carbon, etc.) and run "make dtc mkdtimage -jX" instead of "make bacon" or your normal command. The binaries will be located in out/host/linux-x86/.
This is tested and working with the stock google 4.9 toolchain and the initial source as of Oct 23rd, 2017.
Click to expand...
Click to collapse
Thanks for the files dude, you saved me some serious time since I don't need to sync AOSP

DespairFactor said:
Thanks for the files dude, you saved me some serious time since I don't need to sync AOSP
Click to expand...
Click to collapse
No problemo, I figured I'd post this since my fastboot is being retarded and I can't do much else

Forgive me for being a noob, but would these new requirements for the Pixel 2 cause existing tools used to pack/unpack the boot image fail or at least partially fail? I'm wondering if this is why we can't get Magisk to work
edit: to be clear, when I unpack the boot.img file all I see are kernel and ramdisk. When I unpack the boot.img from the Pixel 1 XL, I see those same 2 files along with devicetree.dtb and kernelimage

skaforey said:
Forgive me for being a noob, but would these new requirements for the Pixel 2 cause existing tools used to pack/unpack the boot image fail or at least partially fail? I'm wondering if this is why we can't get Magisk to work
edit: to be clear, when I unpack the boot.img file all I see are kernel and ramdisk. When I unpack the boot.img from the Pixel 1 XL, I see those same 2 files along with devicetree.dtb and kernelimage
Click to expand...
Click to collapse
Maybe? It doesn't seem like how the boot image is packed has been changed, just how the actual kernel image is put together.

nathanchance said:
Maybe? It doesn't seem like how the boot image is packed has been changed, just how the actual kernel image is put together.
Click to expand...
Click to collapse
Strange. Thanks for the response though. In the Magisk thread here, someone has posted a boot image that was simply unpacked/repacked (no changes) and we can't get it to boot. I don't want to derail this thread any further though.

skaforey said:
Forgive me for being a noob, but would these new requirements for the Pixel 2 cause existing tools used to pack/unpack the boot image fail or at least partially fail? I'm wondering if this is why we can't get Magisk to work
edit: to be clear, when I unpack the boot.img file all I see are kernel and ramdisk. When I unpack the boot.img from the Pixel 1 XL, I see those same 2 files along with devicetree.dtb and kernelimage
Click to expand...
Click to collapse
skaforey said:
Strange. Thanks for the response though. In the Magisk thread here, someone has posted a boot image that was simply unpacked/repacked (no changes) and we can't get it to boot. I don't want to derail this thread any further though.
Click to expand...
Click to collapse
No they don't, these just build the dtb/dtbo. The magisk issue is with patching sepolicy likely.

frap129 said:
No problemo, I figured I'd post this since my fastboot is being retarded and I can't do much else
Click to expand...
Click to collapse
Did you try to flash a factory image and get stuck in the bootloader? If so, extract 'image-walleye-[build number].zip' and flash each image manually. fastboot -w update doesn't work for some reason. After you flash all the images, do fastboot format userdata, and you should be back to normal. Took me a couple hours to figure this out.

ryanbg said:
Did you try to flash a factory image and get stuck in the bootloader? If so, extract 'image-walleye-[build number].zip' and flash each image manually. fastboot -w update doesn't work for some reason. After you flash each image, do fastboot format userdata, and you should be back to normal. Took me a couple hours to figure this out.
Click to expand...
Click to collapse
Thanks! I don't get stuck in the bootloader, but it won't let me flash boot images. Fastboot either hangs or spits out "remote: error: max size not reported"