I was working on this since some time and here it is
Please read FAQ first
- Can I compile a MT6589 kernel for every phone ?
As you know, a MT6589 kernel won't fit in every MT6589 smartphone because of specific configs/files in the kernel source tree.
So, if you compile my kernel which is expected to work on a Faea F2S don't expect it to work on a Acer Liquid E3 for example.
Conclusion : You have to get the kernel source for your phone
- How can I check my kernel source ?
Of course, this is not enough to see "source code for ZTE N986", you have to check if it's full or not and if it works.
Most people don't know what is working kernel source. You just have to read the GPL guidelines that every manufacturer have to complain with :
“ The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. ”
The part which has not to be included is the toolchain but there should reference to it (which toolchain to use)
For MT6589 kernel, the toolchains arm-eabi-4.6 and arm-linux-androideabi-4.6 should be used. (mtk used arm-linux-androideabi-4.6 for kernel but it should be arm-eabi-4.6)
So now you know which toolchain to grab and then for kernel source you have to check this minimal structure :
- If I have kernel source, can I build it for my device ?
Erm... Sometimes the structure is here but the kernel source is messy... Why ?
Because you were not provided the matching source of the kernel used on your smartphone and the reasons are multiple (I won't give details).
So, the idea is to run a first build. If you get errors, then check the step above about toolchain and structure.
The next step for fixing errors is to play with source. Good luck for that.
- What are the benefits of a custom kernel for MT6589 ?
First big benefit is to introduce kitkat compatibility because there was an issue on android binder driver in mtk kernel source.
Next benefit is to be able to remove some stuff from mtk which is useless on user side and waste ressources (a lot of debug for example).
Others benefits will be in optimizations or new features (see frandom for example)
Build from my repo (specific devices supported) - It's not for compiling your kernel source but to understand how kernel build works
I explain how to build from my repo first because it can help you to understand how you should build kernel source
Prerequisites : A build environment (actually Ubuntu Saucy x64 with build-essentials, ccache, repo, java, perl v5.14+ and openssl) and I won't explain how to get one as there is multiple howto on the net.
For repo, the idea is to create a bin directory in your $HOME (usually /home/accountname/), copy repo binary inside it and then add this bin to $PATH var.
BE CAREFULL TO WHAT YOU DO WITH $PATH VAR ! I always see people doing :
this is erasing $PATH var, just check before and after with echo $PATHCode:export PATH=/home/foo/bin
So the idea is to introduce your path AFTER the actual $PATH var
This is easy...
And of course, $PATH is reset once you close terminal and I won't explain how to set $PATH automatically.Code:export PATH=$PATH:/home/foo/bin
Once you got this, everything should be working and it will be easy
Then you should get this in your workdir :Code:mkdir workdir cd workdir repo init -u https://github.com/Dr-Shadow/android_kernel_mt6589_manifest.git -b master repo synckernelJust do :
./certificates.sh is needed only once (it's for signing flashable zip and it will setup some keys for it, just reply to questions and don't add passphrase)Code:cd kernel ./certificates.sh ./build.sh
And of course, the build.sh contains most things you need to know on steps for building kernel (which commands to use) and you need to know how it works
Build from your own kernel source
I'm building the doc... I have to remind which vars need to be overriden