[LG V30 Guides, News, & Discussion] Caffination:
(I'd love to post this in the dev section, but seeing as I've always been an XDA downloader I don't have the post count. )

What I've gathered around the 'net is that there isn't really a good place to get started with development on Android kernels when presented with an OEM source zip drop. This "guide" if you can call it that is nothing more than my musings in stumbling through the kernel dev learning process. My goal is to get both me and maybe you from "ok, I can download source" to doing some basic kernel tasks.

My LG V20 gave up the ghost, but to my surprise my insurance didn't deliver a replacement h918, but instead a T-Mobile LG V30 H932. That messed my restore plans up a good deal. Upon perusing the XDA forums I'm seeing that this model isn't popular with developers. This walkthrough is written with its current latest firmware release in mind, 30d. I won't be updating this guide for newer firmwares as I feel I've documented my process -extremely- thoroughly. If they do miraculously release another update be assured that it'll eventually be in my git's commits.

The first thing I'll note is that this is my first foray into Android kernel development. I've been a Linux sysadmin for 13 years though, so most of my solutions to problems are going to come from that realm rather than Android development. I've been hacking phones using the great releases on XDA since my UTStarcom XV6800 running Windows Mobile 6. It's time to give back.

The second note is that while I tried to keep this guide as generic as possible, that's an impossible task because the process itself is intrinsically tied to what device you're doing this for. I concede 100% that these are the dev notes on my work towards better h932 ROMs w/VoLTE and VoWiFi. If you're working with something else you can follow the same process but change some names around. If your image isn't CAF based, the process is the same except utilizing whatever repository your manufacturer started with.

My last note is that I will not be doing this process on other device kernels unless they're supportable by my base work. The H932 is unloved enough. ;)

------------------------------------------​

GETTING STARTED

Start from a Linux host of your choosing. I'll be doing this from Arch Linux. Make sure your basic build tools are installed and you've got lots of disk space (and free time :\ ).

Get the 30d source through your browser: (apparently I can't post links yet- you're gonna have to Google for now)

Inside the file you download from LG will be another compressed tarball named "LGH932SV_Kernel_Pie.tar.gz". This is where the stock kernel source is stored. Keep this file handy as we'll need to extract the stock kernel's contents a few times.

Alright. We have kernel source and the means to build it. Is that all we can do though? Surely LG didn't just magic this whole platform together. They probably started from an upstream base. The most widely used base for starting development on a Snapdragon device would be the Code Aurora (REALLY missing the links) repo. Just by coincidince CAF contains a branch named "msm-4.4", exactly the same as our stock release's kernel folder. It's likely they started here. But where?

CAF uses some extremely hideous tags to mark their releases. I haven't deciphered the full meaning from the CAF tag strings themselves yet but they do correspond to commits in their git repository. That's good enough for us to start guessing at stuff!

(If you're doing this for the H932 30d release, you can skip CAF-dentification and go straight to "Your Kernel Repo". I already have the magic answers for 30d.)

CAF-DENTIFICATION

Extract your stock kernel sources (located within LGH932SV_Kernel_Pie.tar.gz in the file you download from LG) and go into the msm-4.4 directory via bash terminal.

cd msm-4.4

Initialize this folder as a git repo

git init

Add all the stock kernel files into git's tracking and make your initial commit

git add .
git commit -m "LG V30 30d Stock Open Source Files - (link removed)"

Add the CAF upstream repo for our kernel (msm-4.4)

git remote add msm https://source.codeaurora.org/quic/la/kernel/msm-4.4

Fetch all their tags (this will take some time/~3.3GB folder size after this command)

git fetch msm 'refs/tags/*:refs/tags/*'

Download the best-caf-kernel python script to identify which version CAF LG based the image from

wget https://raw.githubusercontent.com/LineageOS/scripts/master/best-caf-kernel/best-caf-kernel.py

Set it executable

chmod 755 best-caf-kernel.py

Search through the msm-8998 builds to see which one is most similar

./best-caf-kernel.py "*-8x98.0"

This command will take a long while to complete because it's checking each release individually and comparing how much of the source code differs. The least changed kernel represents our best chance to merge LG's changes back into a CAF release as a patch.

Again, the secret answer for the H932 30d kernel is: LA.UM.7.4.r1-03500-8x98.0

LG more than likely started from this base for their 30d release and implemented their custom kernel changes atop LA.UM.7.4.r1-03500-8x98.0. Had they released a repository instead of a bespoke zip we wouldn't have to do all this guesswork. We could just review the commit history and see where the two projects match up.

It's never the easy way...

START YOUR KERNEL REPO

Go ahead and delete the msm-4.4 directory you made before (if you did the CAF-dentification step). We'll start fresh here and explain some of the more common git commands as we go. I know some will not be familiar with git so these examples in motion may help.

Go home (or some place with a lot of storage) and make a directory to store your nascent kernel repository.

cd ~
mkdir -p ./kernel/msm-4.4/
cd ./kernel/msm-4.4/

Initialize this folder as a git repo

git init

Start by making a master branch we'll use for our "good" code. We have to add a file to start the master branch so just drop a description of what we're coding here.

echo "# Custom kernel source repo for the LG V30 H932.
" > caffy.readme
git add .
git commit -m "initial commit"

You can see that the master branch was automatically created via the commit:

git branch -a

Before we move on we should enable a git feature called rerere, short for "Reuse recorded resolution of conflicted merges". This comes in insanely handy in the advanced steps later because it will record how you resolve git conflicts when merging branches. If you merge that code again into a similar branch, git will already know how to automagically fix most of the conflicting issues.

In fact, it's so useful, I recommend enabling it globally. Use branches people!

git config --global rerere.enabled 1

For now add a staging branch that we'll test our code updates in. This will come into play later.

git branch staging

Tracking every change we make and the differences between versions is going to play a VERY vital role in maintaining your kernel source. We'll make heavy use of branches to make merging differences easier later.

Add a third branch that will contain the stock LG H932 30d source files.

git branch LG.H932.30d_stock

Note that you weren't automatically placed in the LG.H932.30d_stock branch. If you do another "git branch -a" you'll see master is still selected. Switch!

git checkout LG.H932.30d_stock

Extract the file "LGH932SV_Kernel_Pie.tar.gz" from the source you downloaded from LG. Now open that compressed tarball to reveal a ./kernel/ folder. This is your actual kernel source code. Extract their ./kernel/ into your ./kernel/.

Now that the files are in place there are a couple small changes that need to be made to the original source so git can catalog it correctly. Looks like LG missed a few files that changed between software versions behind the scenes (for other devices - just know it may not compile as delivered and you'll have to dig).

Make sure you're back in the msm-4.4 folder before running these commands.

echo '!vmlinux.scr' >> ./arch/sh/boot/.gitignore
sed -i '/*.pdf/d' ./Documentation/DocBook/.gitignore
rm ./.get_maintainer.ignore

Update our readme breadcrumb with this branch's details. Personal notes will save you eternal frustration down the road when things are much more complicated.

echo "# This source tree represents the latest LG V30 H932 kernel, version 30d.
#
# Find the original release at:
# (link temporarily removed)
" > caffy.readme

Once all that is in place, add the files into your repo and make a commit for this branch, noting the changes you made from master.

git add .
git commit -m "Clean version of the LG V30 H932 stock kernel (release 30d)"

You can verify your changes by checking your git logs, which will report your commit history on your selected branch.

git log

Your two commit messages should be visible in the log.

Switch back to the master branch so we can add s'more kernel branches.

git checkout master

Note that the directory cleared out again after checking out the master branch. All we have now is our readme file from our initial commit and the .git directory itself (which you should RARELY modify directly).

Now we'll make a new branch to host our stock kernel's closest CAF cousin. Finding out what your CAF tag is can be its own adventure. Normally here is where you have to do the CAF-dentification step (you can refer to that section above). Since this is an example I'll cheat and tell you the closest CAF tag for the H932 30d image: LA.UM.7.4.r1-03500-8x98.0.

git branch LA.UM.7.4.r1-03500-8x98.0
git checkout LA.UM.7.4.r1-03500-8x98.0

Update our breadcrumb with how we got to this point, just in case someone pulls this code and for some reason and blows the .git dir away.

echo "# This source tree represents the original "LA.UM.7.4.r1-03500-8x98.0" CAF release.
#
# Find the full original repo at:
# https://source.codeaurora.org/quic/la/kernel/msm-4.4/refs/tags?h=BosSen-msm-44/master
" > caffy.readme

Add the CAF upstream repo for our kernel (msm-4.4 I'm guesing, since the LG kernel is delivered in a folder named that)

git remote add msm https://source.codeaurora.org/quic/la/kernel/msm-4.4

Grab the most similar version to your CAF as identified by the best-caf-kernel.py script. This is "git fetch" followed by your CAF repo (msm-4.4 here) then the CAF tag.

git fetch msm LA.UM.7.4.r1-03500-8x98.0

Merge this fetched code into our branch, ignoring that it has no common "history" (commits) with our readme-only-containing branch.

git merge --allow-unrelated-histories FETCH_HEAD

(Optional sanity check) You can verify that we're using Qualcomm's code now because we have the commit logs available (unlike with the LG releases). The git log will show you looooooots of dev notes.

git log

Now we have two branches with kernel source code, one of which we suspect is a modified version of the other. Without LG's git history to detail what they changed and where, we're going to have to reconcile the differences ourselves. That sounds easy... right? Wait, did you do the CAF-dentification step? ...remember "Lines changed: 1174716"? :p

In theory this would be simple and software would note all the changes automagically, sort them, and generate a pretty list. In practice it never works that way.

Here's the basic intro to get you started down the path... Be aware that git merge conflict resolution could be a masters level class depending on what you're starting from and where you're trying to go.

Switch back to your empty staging branch

git checkout staging

Pull the code from our CAF branch into our staging branch

git merge LA.UM.7.4.r1-03500-8x98.0

Update your breadcrumb for what's about to come...

echo "# This source tree represents the "LA.UM.7.4.r1-03500-8x98.0" CAF release,
# with the LG customizations added on top of the standard release code.
#
# Find the full original repos at:
# https://source.codeaurora.org/quic/la/kernel/msm-4.4/refs/tags?h=BosSen-msm-44/master
# (apparently CAF links are fine but LGE opensource links are NOT ok)
" > caffy.readme

Now do basically the same process for the H932 30d kernel files. This will result in A LOT of conflicts because LG added a lot of drivers/fixes.

git merge LG.H932.30d_stock

Merging these modifications is a process that is kinda outside of the scope of an "introductory" document. My first attempt on this step took almost a full day of verifying file contents and locations. Even after all that I had to go back and find some missed changes between the two versions manually. Kernel modding is not for the faint of heart. I'm still figuring parts of it out!

"git mergetool" is a good place to start your web searches. meld is a graphical tool you can install on Linux hosts to allow merging between LOCAL, BASE, and REMOTE concurrently via GUI.

This step is where the real art comes in, it seems.

git mergetool -t meld

ANYWAYS, once that whole mess is sorted, you may or may not have a functional stock kernel merged with its closest CAF relative. Preserve your work by adding and committing.

git add .
git commit -m "CAF release tag: LA.UM.7.4.r1-03500-8x98.0 + LG H932 30d kernel source merged.
LG's kernel release finally gets an upstream commit history. >:D"

Since this was such a huge merge I like to park it in (you guessed it) another branch for posterity. Issue these commands to copy our staging work elsewhere.

git branch LA.UM.7.4.r1-03500-8x98.0+H932.30d

At this point you've tracked down where LG started with their kernel source, rebuilt the commit history they started with, and created a patch delta between what Qualcomm handed LG and the 30d image that LG eventually shipped. Very nice!

How do we know it works, though? Maybe we fudged one of the merges up and completely disabled a piece of hardware. Maybe there's no sound. The ONLY way to know the final outcome is to compile, flash, and test. If you weren't "an artist" in the previous step this can be a long repetitive slog.

Some notes to help you diagnose stuff: If you know your 30d kernel compiles and works fine on your phone, but your merged CAF tag + 30d release does not, it must be a difference somewhere between the two sets of files. I had missed a few files the first time around which resulted in a ton of build errors in the final stage. I was able to track this down because most of the errors were "net" related, so I started my search for differences in that directory.

git diff HEAD LG.H932.30d_stock -- ./net/*
git checkout LG.H932.30d_stock -- ./net/Makefile
git checkout LG.H932.30d_stock -- ./net/core/dev.c
git checkout LG.H932.30d_stock -- ./net/core/sock.c

You can go down every directory similarly and VERY SLOWLY verify that you've copied the changes 100%. If you haven't noticed by now this process is a labor of love. Continue until it compiles. Flash. Test. Verify. Progress!