The porting a higher kernel version tehnique I'll describe here is not intended to be a guide for dummies. I'll assume you've already built a kernel for your device, familiar with git
versioning control usage and with some porting / coding tehniques.
Firstly, you need a cleaned source for your device. By "cleaned" I mean, there are no Linux incremental patches, android changes applied, manufacture-specific patches are avoided when possible and so on - you need sources as closest to a "pure" Linux kernel as possible. Otherwise you'll have later need to deal with conflicts resolution, you'll most likely be unable to resolve and the kernel won't boot.
So, without a further forewords, the tehnique is below:
1) As was previously mentioned, a clean kernel source is required, I'll assume we are starting from LK-3.4 ( https://github.com/ChronoMonochrome/...fa163cd78dc01d
) and porting a higher kernel versions. A kernel base needs to be tested for any bugs just to distinguish, which bugs were intruduced during porting from those ones that already present in a kernel base.
2) The following steps will mostly use git bisect
and git merge
commands in order to merge all the changes from a higher kernel versions and help to find / resolve the bugs that were introduced. I suggest copying a git kernel repo that you use for building to a somewhere else, so you can use it , e.g. for grepping a different versions source, bisecting the revisions and so on, so don't need to bother messing up in your main repo that you use for build.
3) Firstly, lets just try to merge a higher kernel version, e.g. LK 3.5 by issuing a command git merge lk-3.5
. You'll likely have a lot of merge conflicts, most of which you can resolve with resetting the paths to a some revision (either a kernel base - lk 3.4, or the version you do port, or just another suitable conflict resolution). So I suggest to write those paths to a text file, like so:
Write all the paths you intend to reset to the kernel base, you most likely need to re-use them later. To actually perform a resetting source, you can issue
for path in $(cat file_with_a_paths.txt | xargs)
git checkout COMMIT $path
Be sure not to put to this file anything not the device-specific! Resetting to the kernel base should be avoided when possible (never ever try resetting archictecture-specific paths, e.g. arch/arm/kernel, arch/arm/mm and so on - unless you really know that kernel will boot thereafter, instead, you have to manually resolve such conflicts). Resolve any other conflicts by resetting paths to the porting source (e.g. LK 3.5).
Note. While resetting with a paths is probably not the most accurate tehnique, but people don't live that long to use more accurate approach, e.g. performing git cherry-pick
for every upstream commit and then manually resolving all the conflicts, you'll just sooner or later get bothered and will abandon it.
4) When you're done with the previous steps you can try building kernel. You'll likely have a build errors - because some part of a source got not updated (e.g. the device-specific drivers), you need manually implement the necessary by a higher kernel version changes. Firstly check if an upstream kernel contains the necessary fixes (example: https://github.com/ChronoMonochrome/...f26ece5a098af9
). If the driver you are porting doesn't exist in the upstream, you can also try to find a similar change and mimic it: https://github.com/ChronoMonochrome/...0627c7f99ed4e9
( ported similarly to https://github.com/ChronoMonochrome/...commit/526c597
). In the worst case scenario you will need to examine the upstream changes and apply the changes so that the drivers complies to the upstream changes: https://github.com/ChronoMonochrome/...mit/ea6432d167
5) If everything is done properly and you're lucky enough, the compiled kernel might already bootup. If not, you'll need to find a culprint that doesn't let the device to boot up. Switch to a copy of your kernel sources, reset the source to the base kernel version (e.g. LK 3.4), issue git bisect good
, then issue git bisect bad lk-3.5
, git will reset to a somewhere in a middle between of LK 3.4 and LK 3.5.
6) Save your changes in the kernel repo, by assigning a some branch to it, switch to the source base, merge all the fixes you've already introduced, then merge the revision you have got in the previous step by bisecting the tree. Repeat these steps until you'll find a first bad commit.
7) If you are already on this step, the most trickiest part starts here - testing (hopefully) working kernel for bugs (if any). While logs can be useful sometimes (so you can google the failing messages and find something useful), there are also many bugs you can find only performing git bisect
tehnique decribed above.
The decribed algorithm only possible thanks to having a clean kernel source. The usage of this guide is not limited only to the kernel porting, it can be used on other projects as well, this is just what I've come across to, when I've ever started porting Linux kernel versions higher than LK3.4.