Related
Hi,
since many people asked me how I build my ROMs for locked bootloaders, I have decided to write a short guide.
Getting started
As always, you need to set up a build environment. Since I don’t want to elaborate on this, I suggest you to follow the building instructions on the CyanogenMod wiki. You can also use the AOKP website as a reference.
Initializing the repos
To start, you may want to initialize the repos that you will use later on. Just open a terminal and issue the following command:
Code:
repo init -u git://github.com/aosp-lb-nozomi/manifest.git -b <ROM>
Where <ROM> is the ROM you want to build. You have to choice between aokp, pac, slimbean and mokee.
So, let's say you want to build AOKP - this would be the command you would have to issue:
Code:
repo init -u git://github.com/aosp-lb-nozomi/manifest.git -b aokp
Syncing the code
Now that this is done, you can start syncing (this may take some time):
Code:
repo sync -jX
Replace the X with your core count (eventually +1 or -1). (e.g. If you have a dualcore processor, it can be -j2 or -j3)
Building
Start with:
Code:
. build/envsetup.sh
Now you should be good to go. Lunchtime!
Code:
lunch <ROM>_<device>-userdebug
(e.g. lunch aokp_nozomi-userdebug OR lunch slim_aoba-userdebug)
Finally, you are ready to build.
Code:
make -jX bacon
Patching the ROM to work with LB
If everything went right, you should find an AOKP build in your out folder. But this build is unpatched, so it can be flashed on UB devices only. To patch it, go to your root directory (type "cd"), clone my repo and navigate to it:
Code:
git clone [email protected]:aosp-lb-nozomi/rom_builder.git -b [B]<ROM>[/B] patcher;cd patcher
Again, you have to replace <ROM> by the ROM you want to build. Possible ROMs: aokp, pac, slimbean and mk.
NOTE: If you build for the Sony Xperia Ion (aoba), you have to add that. (e.g. git clone [email protected]:aosp-lb-nozomi/rom_builder.git -b aokp-aoba patcher;cd patcher)
Finally, execute the script (to patch the ROM):
Code:
sh makezip
That’s it! Find your build in the folder “patcher” and flash it.
Since this port is not completed yet, had many compilation errors. but some how i passed many errors (which i shall list them here and solution as well )
i am seeking for developers to help me out, in order to compile it successfully.
Sources i am using
Ubuntu touch Source phablet-4.4.2_r1
Code:
repo init -u https://code-review.phablet.ubuntu.com/p/aosp/platform/manifest.git -b phablet-4.4.2_r1
Sources from CyanogenMod for tomato (kk4.4.4):
cm-11.0 kernel source msm8916, Device Tree, android_device_qcom_common
Click to expand...
Click to collapse
Currrent Error
Code:
/phablet/kernel/yu/msm8916/kernel/sched/core.c:9110:18: error: invalid operands to binary != (have 'kuid_t' and 'kuid_t')
/phablet/kernel/yu/msm8916/kernel/sched/core.c:9110:46: error: invalid operands to binary != (have 'kuid_t' and 'kuid_t')
XDA:DevDB Information
Project Ubuntu-Touch Port For Yureka, ROM for the YU Yureka
Contributors
sheikhrr
ROM OS Version: 4.4.x KitKat
Based On: CyanogenMod
Version Information
Status: Snapshot
Created 2016-01-21
Last Updated 2016-01-21
Reserved
Reserved
when man iam waiting for it
I am waiting too
Dude!!!!!!!!!!!!! ****in' awesome, you are.
Hey guys, I am new to kernel building.
I have encountered the following error.
"In file included from arch/arm64/kernel/signal.c:36:0:
/media/dragacy/Android/kernel/arch/arm64/include/asm/vdso.h:30:36: fatal error: generated/vdso-offsets.h: No such file or directory
#include <generated/vdso-offsets.h>"
when building the kernel.
I am using the sonyAOSP kernel source. The patch i have applied so far is just the safety net patch.
This is the development thread for Lineage 16.
Everyone who knows C, Java and strace is welcome to participate. Please send git formatted patches!
Device Trees
https://github.com/cryptomilk/android_kernel_sony_msm8998
https://github.com/cryptomilk/android_device_sony_common-treble
https://github.com/cryptomilk/android_device_sony_yoshino
https://github.com/cryptomilk/android_device_sony_lilac
I've started to get TWRP building.
I've finally successfully started TWRP based on Android 9.0. However the data partition doesn't get upgraded. So I'm trying to figure out what is failing there now ...
I think I got a working TWRP recovery. First step towards Pie done. I think @derf elot has the Kernel update almost ready. We are just waiting for Customized DE update to Android Pie to start building a new Lineage 16.
modpunk said:
I think I got a working TWRP recovery. First step towards Pie done. I think @derf elot has the Kernel update almost ready. We are just waiting for Customized DE update to Android Pie to start building a new Lineage 16.
Click to expand...
Click to collapse
Thank you very much, I just want to ask if there will gcam HDR+ support in this version?
modpunk said:
I think I got a working TWRP recovery. First step towards Pie done. I think @derf elot has the Kernel update almost ready. We are just waiting for Customized DE update to Android Pie to start building a new Lineage 16.
Click to expand...
Click to collapse
The new 47.2.A.0.306 stock kernel is merged into an up-to-date LA.UM.7.4.r1 kernel following both CAF and Linux updates (thank again @nathanchance ). Sony is also using LA.UM.7.4.r1 as a base now, so the switch made sense (we/Sony used LA.UM.6.4.r1 before). But we will always be updated to upstream, as is the case for 15.1 already, sometimes even months before some patches for security issues make it on to the ASB.
So far, the kernel builds fine. Will now test it on stock, then "LOS'ify" it - which is pretty straightforward - and we are ready to go.
Hi, first of all, thank you very much for your work on LineageOS!
I'm reposting a message from LineageOS 15.1 thread as it is EOL and you probably missed it and it contains two bugs not listed in OP that I believe are worth investigating on next release or so:
- On calls, we can't hear with headset (unless you unplug and plug back in). It was noted that it worked with beta4 so I investigated and found that this commit was added between beta 4 and 5 so you may have a look at it: https://github.com/cryptomilk/andro...mmit/c4a8569c492b343a0e22b31dd51d0821c9b75b47
- Some apps can't write on their own data folder (/storage/emulated/0/Android/data/<appname>/) if READ/WRITE_EXTERNAL permission not listed in Manifest, so the workaround you mentioned in Known Issues of the thread doesn't work + even if it is listed, it's a privacy issue because we don't want the app to look at other folders.
Examples of apps trying to write in its own data folder with no READ/WRITE_EXTERNAL permission in Manifest:
- com.tinyco.potter (instantly crash)
- com.c4mprod.rtm (instantly crash)
The only workaround possible it to apktool the app, add permission to the Manifest, and in some cases (Harry Potter for example) remove the license verification due to wrong signature after new signing, but the privacy issue remains.
Android documentation about this: https://developer.android.com/reference/android/Manifest.permission#WRITE_EXTERNAL_STORAGE
Starting in API level 19, this permission is not required to read/write files in your application-specific directories returned by Context.getExternalFilesDir(String) and Context.getExternalCacheDir().
Click to expand...
Click to collapse
That's why older versions of apps targeting a lower API than 19 works because they have the writing external permission
This is a DEVONLY thread and not the appropriate place to discuss bugs in a completely different version of the ROM.
Gairtial said:
This is a DEVONLY thread and not the appropriate place to discuss bugs in a completely different version of the ROM.
Click to expand...
Click to collapse
Why do you say it is a "completely different version of the ROM"?
Device and kernel trees are based on 15.1 work, look at the commits, there is almost no differences, so the same bugs will be inherited on 16.
I'm not sure I understand what you mean by "DEVONLY", I'm a dev and I talked of the bugs from a developer point of view (link to commit from the tree, logs, Android documentation).
I don't want to derail the thread (my original goal was to stop the thread from being derailed) but to explain myself some more (and this will be my last post on the matter, this has gotten bad enough as it is):
Yurienu said:
Why do you say it is a "completely different version of the ROM"?
Device and kernel trees are based on 15.1 work, look at the commits, there is almost no differences, so the same bugs will be inherited on 16.
Click to expand...
Click to collapse
16 is in a very early state and we don't know for sure whether the bugs can be reproduced on 16. We can't verify them, we can't diagnose them, we can't test fixes. We can't take any action on them, therefore they don't really belong here. They'd be much better suited to the LOS 15.1 thread, or left until 16 is functional enough that they can at least be verified.
Yurienu said:
I'm not sure I understand what you mean by "DEVONLY", I'm a dev and I talked of the bugs from a developer point of view (link to commit from the tree, logs, Android documentation).
Click to expand...
Click to collapse
I brought up DEVONLY because you're presenting bugs (discussion really belongs in a user thread) rather than fixes, or even work towards fixes (discussion totally belongs in a developer thread). You've presented one bug with some details but nothing that really contributes to fixing it and one with a possibly related commit. However you haven't done anything to determine whether that commit is actually the problem. You could verify for sure by building and testing before and after it. If you did that, you could even look into offering a fix.
I'm not saying this to pick a fight with you or because I hate you or think you're an idiot, I just want to make sure the right discussions are in the right threads so that devs are able to communicate with us and each other without too much pain. Putting your bug report in the 15.1 thread where it belongs ensures that this thread can be used to discuss LOS 16 development, as was clearly the intention of creating it.
Time to fork xD
Do you have a gerrit?
modpunk said:
We are just waiting for Customized DE update to Android Pie to start building a new Lineage 16.
Click to expand...
Click to collapse
It just arrived. :good:
beggar23 said:
It just arrived. :good:
Click to expand...
Click to collapse
Download is already running ...
The deep sleep bug affecting Yoshino platforms on Pie is being fixed here: https://github.com/kholk/kernel/commits/232r14-sleep-bug-research
According to the pull request to official kernel, this should mitigate the issue.
Please keep us informed if there is anything else preventing a release.
I was not able to boot LineageOS 16 compiled from your repos but if you can provide a flashable package, I can help testing if you need help?
Can you provide a status update please? How are things going? Is there something bootable at least (even if self-compiling is required)?
There is something which can be compiled. I dunno if it boots yet.
Read on Reddit that what's holding back LOS16 is "LineageHW deprecation in favor of new "treble-ready" HALs".
From the thread "What's holding back the LOS16 release ?" posted 9 days ago in r/LineageOS by u/FishTheFish152.
Any news here? How to participate?
building LineageOS 16.0 including TWRP for pie
I am sharing my steps used to build los16 with repos provided by @modpunk in the OP, in the hope that more devs could participate in the development.
Disclaimer: the result of this does not boot, so I am not sure at all if my howto and modifications are good or wrong.
Still hoping it might be useful to someone or maybe @modpunk or @derf elot could provide some hints to reach current status of this project?
Big thanks to @modpunk and @derf elot for working on this project.
Basically I tried to follow los15 howto as provided in the README.md of the modpunk's android_device_sony_lilac repository - just adapting it for los16 instead of los15:
initialize repo: used branch "lineage-16.0", first sync was done on 2019-03-18 with resync on 2019-03-19 (for the record of the los16, twrp and modpunk's repos source tree state)
for local manifest I've used this:
Code:
<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<!-- SONY -->
<project name="cryptomilk/android_kernel_sony_msm8998" path="kernel/sony/msm8998" remote="github" revision="lineage-16.0-LA.UM.7.4.r1" />
<project name="cryptomilk/android_device_sony_common-treble" path="device/sony/common-treble" remote="github" revision="TESTING" />
<project name="cryptomilk/android_device_sony_yoshino" path="device/sony/yoshino" remote="github" revision="TESTING" />
<project name="cryptomilk/android_device_sony_lilac" path="device/sony/lilac" remote="github" revision="TESTING" />
<!-- Pinned blobs for lilac -->
<project name="cryptomilk/android_vendor_sony_lilac" path="vendor/sony/lilac" remote="github" revision="lineage-16.0" />
<!-- TWRP recovery -->
<remove-project path="bootable/recovery" name="LineageOS/android_bootable_recovery" groups="pdk" />
<project name="omnirom/android_bootable_recovery" path="bootable/recovery" remote="github" revision="android-9.0" />
<remove-project path="vendor/qcom/opensource/data-ipa-cfg-mgr" name="LineageOS/android_vendor_qcom_opensource_data-ipa-cfg-mgr" groups="qcom,pdk-qcom" />
</manifest>
Please note, I've used TESTING branch instead of lineage-16.0 as it seems that the newest changes happen there for los16 development. Similarly I tried to guess the right kernel branch based on the most recent commits: lineage-16.0-LA.UM.7.4.r1 - hopefully that is right.
Also I tried to build TWRP in the process, so replacing los recovery with upstream twrp for pie one in the local manifest.
There has been a conflict in los source tree with data-ipa-cfg-mgr that has been pulled also from modpunk's local manifest, so that is why I am removing the los one in my local manifest here.
to speed up the sync and reduce the disk space, I am using this command:
Code:
repo sync --no-tags --no-clone-bundle -c -j8
in the Extract vendor blobs step, I am using
Code:
SRC=/path/to/unpacked-fw/xz1c-pie-8.24 ./extract-files.sh
command, having full fw unpacked into plain files all readable for normal user including fixes for symlinks to be relative instead of pointing to / directory. As I was not sure about the right fw version, I've tried pie 4.45 too for the blobs extraction. During the build, some blob was missing, so I've added proprietary-files-rootfs.txt file into device/sony/lilac directory with following content:
Code:
# ROOTFS_TRIMAREA
-sbin/tad_static;rootfs
for Setup the environment, I am using following:
Code:
unset JDK_HOME
unset JAVA_HOME
unset JAVAC
export OUT_DIR_COMMON_BASE=/path/to/lineageos/output
export WITH_TWRP=true
source build/envsetup.sh
lunch lineage_lilac-userdebug
Those unset's I had to use to avoid build problem complaining about javac different versions for .mk and soong - quite difficult to find that workaround.
The OUT_DIR_COMMON_BASE is to make compiled stuff to go outside the source tree to speed up greping there.
The WITH_TWRP option seems to be needed to let some makefiles know we like to build twrp recovery.
I've tried lineage_lilac-userdebug first, after lots of fixes during the build, the result did not boot, so I tried lineage_lilac-eng lunch target too with basically the same result unfortunately.
before Build LineageOS step, you may try to apply my changes/fixes that I had to use to avoid build errors (some were quite tricky actually) - please see the attachment here for the combined patch.
This is my repo status after the changes:
Code:
project bootable/recovery/ (*** NO BRANCH ***)
-m applypatch/Android.bp
-m applypatch/applypatch.cpp
-m crypto/lollipop/cryptfs.c
-m minui/events.cpp
-- mtdutils/Android.bp
-m otautil/Android.bp
-m otautil/Android.mk
-m updater/Android.mk
-m updater/install.cpp
project build/make/ (*** NO BRANCH ***)
-m tools/releasetools/common.py
project device/sony/common-treble/ (*** NO BRANCH ***)
-m sepolicy/vendor/file.te
project device/sony/lilac/ (*** NO BRANCH ***)
-- proprietary-files-rootfs.txt
project device/sony/yoshino/ (*** NO BRANCH ***)
-m recovery/twrp.fstab
-m sepolicy/vendor/file.te
-m sepolicy/vendor/hal_livedisplay_default.te
-m sepolicy/vendor/startup-logger.te
-m sepolicy/vendor/toolbox.te
project vendor/sony/lilac/ (*** NO BRANCH ***)
-m proprietary/framework/qti-telephony-common.jar
following command would build los16 including twrp recovery:
Code:
make -j5 bacon
The built images and installation zip can be found under ${OUT_DIR_COMMON_BASE}/lineage-16.0/target/product/lilac directory:
twrp recovery image: recovery.img
kernel boot image: boot.img
los16 installation zip: lineage-16.0-20190321-UNOFFICIAL-lilac.zip
Here are the results for lineage_lilac-eng build:
tried to boot recovery.img first, got hanging on twrp splash screen.
Installed the zip file via modpunk's twrp, tried to boot it, got a hanging black screen after SONY splash screen.
Flashed userdata from stock fw to do an erase: that made built twrp bootable and actually working - installed the built los16 zip just fine.
So this twrp is the only working thing for me so far. But it seems my built twrp is not that flexible as modpunk's as mine needed userdata erase to boot while modpunk's did not.
I tried to get some logs from main los16 boot, but logcat is not reachable. Have seen also the commit to redirect logcat into /cache for charging boot mode - tried that, but the log file was not created there.
The lineage_lilac-userdebug behaved similarly if I remember correctly (tried that build first), only twrp I could not boot as the userdata erase thing has been discovered with the -eng build. But re-tested that, it helped also with -userdebug twrp build, so both variants seem to behave the same.
The blobs from pie 8.24 vs pie 4.45 did not make a difference (after a quick rebuild followed the extraction).
In order to check my build environment, I tried similarly to build sony's aosp-9.0 - it also needed some fixes, but the result has been working (needed the special oem partition image flashed as described in sony's howto to make it boot - it would hang without it).
Attached result of following command (git added the new files first):
Code:
repo diff -u >my-changes.diff
Hopefully this helps anybody who likes to participate.
Thanks for any hints.
hi there,
yes those are the right branches you are using there. I was planning to PR some of the changes needed to build to the testing branches this weekend. I'll also look more closely at your patches, but from what I can tell you fixed the neverallow selinux issues - great!
the main issue right now is still the init, I know of at least a couple of crucial things missing from stock (there is more than one fstab now, for example - this is not implemented yet), but I was waiting for modpunk to push his recent changes before working on it again. he also told me that he has some uncommitted stuff, but hasn't had the time yet to sort them out.
also, feel free to PR your patches to modpunk's git. any help is much appreciated!
edit: instead if re-adding the proprietary-files-rootfs.txt, you can just remove the references to it from extract-files.sh and setup-makefiles.sh
(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
Modified instructions from:
abhishekan - can't post links yet. To be filled. :\
Click to expand...
Click to collapse
Only necessary if you don't know your base - I already did this for our example.
LG H932 release 30d script results:
Code:
Best match
TAG: LA.UM.7.4.r1-03500-8x98.0
Lines changed: 1174716
That's a LOT of changes! I hope it's not too bad to sort through...
Click to expand...
Click to collapse
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.
Code:
cd msm-4.4
Initialize this folder as a git repo
Code:
git init
Add all the stock kernel files into git's tracking and make your initial commit
Code:
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)
Code:
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)
Code:
git fetch msm 'refs/tags/*:refs/tags/*'
Download the best-caf-kernel python script to identify which version CAF LG based the image from
Code:
wget https://raw.githubusercontent.com/LineageOS/scripts/master/best-caf-kernel/best-caf-kernel.py
Set it executable
Code:
chmod 755 best-caf-kernel.py
Search through the msm-8998 builds to see which one is most similar
Code:
./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.
Code:
cd ~
mkdir -p ./kernel/msm-4.4/
cd ./kernel/msm-4.4/
Initialize this folder as a git repo
Code:
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.
Code:
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:
Code:
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!
Code:
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.
Code:
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.
Code:
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!
Code:
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.
Code:
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.
Code:
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.
Code:
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.
Code:
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.
Code:
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.
Code:
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.
Code:
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)
Code:
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.
Code:
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.
Code:
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.
Code:
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"?
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
Code:
git checkout staging
Pull the code from our CAF branch into our staging branch
Code:
git merge LA.UM.7.4.r1-03500-8x98.0
Update your breadcrumb for what's about to come...
Code:
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.
Code:
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.
Code:
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.
Code:
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.
Code:
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.
Code:
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!
COMPILE KERNEL
If you've followed this guide top to bottom as written, we may be a bit ahead of ourselves. I recommend trying the following steps on the 30d stock files FIRST, and then once you're sure of your methods on the original files you can try your hand at compiling your merged CAF tagged version. This helps isolate issues between your process and your code.
Switch back over to the pristine stock branch.
Code:
git checkout LG.H932.30d_stock
Unless you're doing this from a 64-bit Raspberry Pi (AND 64-bit OS!) or similar platform you'll need to grab the cross-compile toolchain for arm64 (here called aarch64) from Google. There's a slight problem with using the latest release though. Commit fc97ce6abfe822403eb219dcbd1067a53c49e4f1 removed the GCC compiler completely!
Checking back through the git log we can see where they've made changes to GCC, so let's roll back to a version more suitable for our platform. I found the last commit that contains GCC before they started introducing the deprication warnings - 22f053ccdfd0d73aafcceff3419a5fe3c01e878b. We'll leave the msm-4.4 directory first so this toolchain isn't downloaded into our code.
Code:
cd ../..
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9
cd aarch64-linux-android-4.9
git checkout 22f053ccdfd0d73aafcceff3419a5fe3c01e878b
git reset --hard HEAD
You can verify that we have gcc again by checking the ./bin/ directory here.
Code:
ls -lah ./bin | grep gcc
While we're here we need to set some environment variables so the compiler will know to use this location. You'll have to redo this from this directory any time you close your shell (in this case, the terminal probably), if you want to recompile the kernel.
Code:
export CROSS_COMPILE=$(pwd)/bin/aarch64-linux-android-
export ARCH=arm64 && export SUBARCH=arm64
Head back into the msm-4.4 directory for punishment time.
Code:
cd ../kernel/msm-4.4
This next part I'm pretty sure is not the correct way to perform it. I'm not a C developer - just a sysadmin - so I've worked out a way to get it running at least. Yes, this does mean that the code is no longer pristine. Someone let me know how to get the stock code compiling without modification. Click the button below for my steps that are -extremely- specific to the h932 30d image.
In ./Makefile, Remove the gcc-wrapper script from the equation. All it does is stop the build on warnings. Google made a similar change with their commit e7fb62baa7c8b803d7e3b3f3d8bf4e2b916b659d. Change this line:
Code:
REAL_CC = $(CROSS_COMPILE)gcc
to this:
Code:
CC = $(CROSS_COMPILE)gcc
And remove this line:
Code:
CC = $(srctree)/scripts/gcc-wrapper.py $(REAL_CC)
-OR- if you really like stopping on compiler warnings, you need to make the wrapper executable.
Code:
chmod 755 ./scripts/gcc-wrapper.py
Note that this wrapper breaks newer GCC toolchains so it's advised you choose to remove it.
./arch/arm64/kernel/vdso/gen_vdso_offsets.sh has incorrect permissions. It needs to be executable.
Code:
chmod 755 ./arch/arm64/kernel/vdso/gen_vdso_offsets.sh
You're going to need to apply a Linux kernel commit from 4.4.218 (commit ce513359d8507123e63f34b56e67ad558074be22) to prevent compile errors about "multiple definition of `yylloc'". Remove the line "YYLTYPE yylloc;" (or in later versions "extern YYLTYPE yylloc;") from two files:
Code:
# ./scripts/dtc/dtc-lexer.l
# ./scripts/dtc/dtc-lexer.lex.c_shipped
Go into the ./arch/arm64/boot/dts/ directory. Delete the qcom file and make it a link instead. This fixes a missing file error that msm8998-joan_tmo_us_rev-0.dts otherwise runs into.
Code:
cd arch/arm64/boot/dts/
rm qcom
ln -s ../../../../arch/arm/boot/dts/qcom qcom
cd ../../../..
Go into the ./include/uapi/linux/ directory. We're going to delete some files and link them instead. This fixes ambiguous errors like: "../include/uapi/linux/oneshot_sync.h:1:1: error: expected identifier or '(' before '.' token". It's LITERALLY parsing the link in the file. Make it a link instead.
Code:
cd ./include/uapi/linux/
rm oneshot_sync.h
ln -s ../../../drivers/staging/android/uapi/oneshot_sync.h oneshot_sync.h
rm sync.h
ln -s ../../../drivers/staging/android/uapi/sync.h sync.h
cd ../../..
Edit the #include statements in ./arch/arm/boot/dts/qcom/msm8998.dtsi to point to the current file locations. Leave the first #include alone! Change the other three to:
Code:
#include <../../../../../include/dt-bindings/clock/msm-clocks-8998.h>
#include <../../../../../include/dt-bindings/regulator/qcom,rpm-smd-regulator.h>
#include <../../../../../include/dt-bindings/interrupt-controller/arm-gic.h>
Another #include needs to be fixed in ./include/dt-bindings/interrupt-controller/arm-gic.h
Code:
#include "irq.h"
Two #includes in ./arch/arm/boot/dts/qcom/msm-pmi8998.dtsi
Code:
#include <../../../../../include/dt-bindings/interrupt-controller/irq.h>
#include <../../../../../include/dt-bindings/spmi/spmi.h>
The same thing in reverse on ./arch/arm/boot/dts/qcom/msm-pm8005.dtsi
Code:
#include <../../../../../include/dt-bindings/spmi/spmi.h>
#include <../../../../../include/dt-bindings/interrupt-controller/irq.h>
Some common culprits over in ./arch/arm/boot/dts/qcom/msm8998-regulator.dtsi
Code:
#include <../../../../../include/dt-bindings/clock/msm-clocks-8998.h>
#include <../../../../../include/dt-bindings/interrupt-controller/arm-gic.h>
ANOTHER set of #includes in ./arch/arm/boot/dts/qcom/msm-pm8998.dtsi
Code:
#include <../../../../../include/dt-bindings/spmi/spmi.h>
#include <../../../../../include/dt-bindings/interrupt-controller/irq.h>
#include <../../../../../include/dt-bindings/msm/power-on.h>
One in the similarly namned ./arch/arm/boot/dts/qcom/msm8998-pm.dtsi
Code:
#include <../../../../../include/dt-bindings/interrupt-controller/arm-gic.h>
Seeing a pattern yet? The include directory must be defined in something I've missed. Another over in ./arch/arm/boot/dts/qcom/msm-arm-smmu-8998.dtsi
Code:
#include <../../../../../include/dt-bindings/clock/msm-clocks-8998.h>
#include <../../../../../include/dt-bindings/msm/msm-bus-ids.h>
#include <../../../../../include/dt-bindings/interrupt-controller/arm-gic.h>
Moar. ./arch/arm/boot/dts/qcom/msm8998-vidc.dtsi
Code:
#include <../../../../../include/dt-bindings/interrupt-controller/arm-gic.h>
#include <../../../../../include/dt-bindings/msm/msm-bus-ids.h>
#include <../../../../../include/dt-bindings/clock/msm-clocks-8998.h>
Moar. ./arch/arm/boot/dts/qcom/msm8998-bus.dtsi
Code:
#include <../../../../../include/dt-bindings/msm/msm-bus-ids.h>
Moar. ./arch/arm/boot/dts/qcom/msm-smb138x.dtsi
Code:
#include <../../../../../include/dt-bindings/interrupt-controller/irq.h>
Moar. ./arch/arm64/boot/dts/lge/msm8998-joan/msm8998-joan_tmo_us/msm8998-joan_tmo_us.dtsi
Only the first #include on this file needs to be changed.
Code:
#include <../../../../include/dt-bindings/interrupt-controller/irq.h>
Locate the devconfig file you'd like to use for your device under the directory ./arch/arm64/configs/.
Code:
ls -lah ./arch/arm64/configs/
The closest in my instance will be the "joan_tmo_us-perf_defconfig" file. Joan is the codename for the LG V30, T-Mobile's my carrier, US is my country, and while using the stock ROM the uname -r command returns "4.4.153-perf+" so I assume they used the perf config. The defconfig will instruct the compiler what options to include in the kernel. We're going with the LG stock options to start with.
Make a few directories for the clean/mrproper scripts. The build process throws some (harmless) errors otherwise.
Code:
mkdir -p out/drivers/staging/qcacld-3.0
mkdir -p out/drivers/staging/qca-wifi-host-cmn
mkdir -p out/arch/arm64/boot/dts
Now run through the make steps. Clean, prepare the environment, prep the make with your devconfig, then run the actual make specifying that it use all the cores your PC has to speed things up. You can change that to a manually specified number like 3 cores if you're using the PC for other stuff with "-j3".
Code:
make O=./out clean
make O=./out mrproper
make O=./out joan_tmo_us-perf_defconfig
make O=./out KERNEL_COMPRESSION_SUFFIX=gz -j$(nproc)
Your kernel should compile successfully and output the file "./out/arch/arm64/boot/Image.gz-dtb". AnyKernel3 will need this so your kernel can be included in the installer.
PACKAGE & FLASH KERNEL
Download the latest AnyKernel3. Make sure you're not in your kernel directory.
Code:
cd ~
wget https://github.com/osm0sis/AnyKernel3/archive/master.zip
Unzip the archive and go into the AnyKernel3 directory.
Code:
unzip master.zip
cd AnyKernel3-master
Place your Image.gz-dtb file into the AnyKernel3-master folder.
Edit the anykernel.sh file, it comes pre-populated with demo values. Copy my example below for the V30 and feel free to change kernel.string (make sure not to use a ' though). If you aren't using a V30 and therefore not making a Joan kernel, change the device.name1 and block lines for your device. You can either pull the values from another kernel for your device, or boot into TWRP or similar, go to the terminal, and try a find /dev/block -name boot to see if you can garnish any clues as to where your real boot is. Some devices just hard specify this under /fstab.${devicecodename} - ours is at /fstab.joan but has no /boot/.
Code:
# AnyKernel3 Ramdisk Mod Script
# osm0sis @ xda-developers
## AnyKernel setup
# begin properties
properties() { '
kernel.string=CAF Test Kernel
do.devicecheck=1
do.modules=0
do.systemless=1
do.cleanup=1
do.cleanuponabort=0
device.name1=joan
'; } # end properties
# shell variables
block=/dev/block/bootdevice/by-name/boot;
is_slot_device=0;
ramdisk_compression=auto;
## AnyKernel methods (DO NOT CHANGE)
# import patching functions/variables - see for reference
. tools/ak3-core.sh;
## AnyKernel install
dump_boot;
write_boot;
## end install
Finally, pack up the entire folder.
Code:
zip -r9 UPDATE-AnyKernel3.zip * -x .git README.md *placeholder
You've created your first kernel release! Most XDA users would know what to do with this file at this point. Remember that if you're using a Pie release like we are that not all versions of TWRP support the newer standard of encryption. I'm using 3.3.1 personally.
That first flash is perilous. You'll swear it's the slowest your phone has ever booted and there's no way this could be working. Patience. If it doesn't work and you have no access to another kernel for your device you'll have to reflash a working image, find out what you did wrong, fix it, and try again.
Once you have a known working kernel the other flashes are much less risky - if it doesn't work, just go back into TWRP and flash the working one.
SWITCHING TOOLCHAINS
Switching between Google Android 4.9 builds
I've pulled some of the commits from the aarch64-linux-android-4.9 git logs which correlate to when they introduced new build versions. Might help someone track down an errant compiler issue or two.
Code:
93092903254cba0b6950c94170332973a85b450f - final gcc build 5790414 + very long delays added to dissuade use
22f053ccdfd0d73aafcceff3419a5fe3c01e878b - build 4983606 - last version before warnings
e7c51da4d09616dcff4a9d0f1190c3403079c462 - build 4682334
ce9d77505072450d2f16a4bf06673f31d8d67ff0 - build 3335333
2d6950d80de80ab7b1252816a2f543d07180deeb - build 2734602
d65210cccc244bf9a92a1ff56953314e9908e0fd - build 2617618
b5845835b5e6a5266c56d554c0c1f282d30f8c3f - build 2492827
8f7279e3d34a45f084fdb23bd434c01d5e598bf4 - they don't mention the builds this early
For anything older checkout this last commit and do: git log --grep 'prebuilts for aarch64'
You can change which gcc build your toolchain is on by going into your aarch64-linux-android-4.9 directory and performing the following commands, making sure to replace the commit with the one reflecting the build you'd like.
git checkout 22f053ccdfd0d73aafcceff3419a5fe3c01e878b
git reset --hard HEAD
Switching to Alternatives
From what I understand reading around XDA, it's best practice to try to compile your kernel with Google's aarch64-linux-android-4.9 toolchain first to make sure that nothing's wrong with it. Relative to the Linux community however, Google has been extremely conservative with its toolchain. If you're looking to bleed every last drop of performance out of your platform you should try a few different toolchains and see which one results in code that's most efficient for your workflow.
There are LOTS of toolchains out there. XDA has entire threads on dedicated to this topic. On Linux your distribution also probably bundles a premade toolchain for aarch64, Arch Linux is currently on GCC 10 (aarch64-linux-gnu-gcc)!
I'm going to focus on a popular performance-focused toolchain here, Linaro. They produce an aarch64 toolchain for most of the GCC release versions with enhancements specific to ARM based targets. Their latest release as of this writing is 7.5.0.
Go back to your home directory and download the aarch64-7.5.0 release of Linaro, then unpack.
Code:
cd ~
wget https://releases.linaro.org/components/toolchain/binaries/latest-7/aarch64-linux-gnu/gcc-linaro-7.5.0-2019.12-x86_64_aarch64-linux-gnu.tar.xz
tar -xf gcc-linaro-7.5.0-2019.12-x86_64_aarch64-linux-gnu.tar.xz
Now, whenever you want to compile your kernel following the steps in this guide, you'll go into this directory instead of your previous aarch64-linux-android-4.9 one. Then you'll need to set your CROSS_COMPILE variable a different string which corresponds to Linaro 7.5.0's file structure.
Code:
cd gcc-linaro-7.5.0-2019.12-x86_64_aarch64-linux-gnu
export CROSS_COMPILE=$(pwd)/bin/aarch64-linux-gnu-
I've tested this on my LA.UM.7.4.r1-03500-8x98.0+H932.30d and it completes albeit with a few warnings. Coding standards and compilers evolve as time moves on and code that isn't maintained can find itself stranded with the ancients - these warnings are to help developers work in the right direction so that doesn't happen to their projects.
To that end, to actually compile a functional kernel using a GCC 7.x+ toolchain there's a flag that needs to be added to your ./Makefile: "-fno-store-merging". I found this tidbit over at https://github.com/nathanchance/angler/commit/406d54a7f006142372157d4fb49d7e76a5564d00
Add the following at line 634 in ./Makefile:
Code:
# Needed to unbreak GCC 7.x and above
KBUILD_CFLAGS += $(call cc-option,-fno-store-merging,)
UPDATE CAF
Repeating history isn't what we came for though. From our CAF base the fun begins. We didn't do all that work to end up with a stock image! The entire reason to figure out what CAF we started with is so we could change it. Now that we have a kernel with the CAF commit history, as we download newer CAF bases, we'll simply reapply the same commits that they did to update our kernel's base.
We're going to download the latest CAF base image for our hardware. Go to the codeaurora.org page for your device's source tags. Search for your chip (here 8x98 referring to the msm8998 aka Snapdragon 835) and find a similar build string to your identified one.
For the H932 this page would be: https://source.codeaurora.org/quic/la/kernel/msm-4.4/refs/tags?h=BosSen-msm-44/master
In this instance, 30d identified closest as "LA.UM.7.4.r1-03500-8x98.0 ", so I'm looking for a "LA.UM.7.4.r1" release for the "8x98.0" architecture.
Just a heads up - I'm not sure if this is right! There are much newer msm8998 releases listed, such as "LA.UM.8.4.r1-05500-8x98.0". I've yet to experiment with these to see if they are of value to us. I went with the "most similar looking" to get my feet wet with the process.
Code:
git fetch https://source.codeaurora.org/quic/la/kernel/msm-4.4.git LA.UM.7.4.r1-06000-8x98.0
Go back to master since it's our only clean branch. Then make a home for our selected CAF release. Then switch to using it.
Code:
git checkout master
git branch LA.UM.7.4.r1-06000-8x98.0
git checkout LA.UM.7.4.r1-06000-8x98.0
Do the same process we did to import the original CAF's code. We already set the LA.UM.7.4.r1-06000-8x98.0 commit as our FETCH_HEAD earlier.
Code:
git merge --allow-unrelated-histories FETCH_HEAD
Head back to staging. It currently has a copy of the LA.UM.7.4.r1-03500-8x98.0+H932.30d branch's code.
Code:
git checkout staging
Now merge the changes from 06000 into our 03500 base.
Code:
git merge LA.UM.7.4.r1-06000-8x98.0
Notice how this produces A TON fewer conflicts than our original go around. Also, rerere has captured how we modified some of the files when we added 30d into the CAF branch so it has a basic concept of what we're trying to achieve, and makes some of these for us automagically. The day is saved!
Break out your git mergetool of choice again and get to work.
Code:
git mergetool -t meld
Then add and commit your changes.
Code:
git add .
git commit -m "LA.UM.7.4.r1-06000-8x98.0 + LG H932 30d kernel source merged"
You also need to update some tertiary CAF drivers like qcalcd-3.0. You may need to check the CAF repo to make sure you've nabbed all that apply. I'm going to assume you can merge a repo at this point.
qcacld:
Code:
git remote add qcacld https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/wlan/qcacld-3.0
git fetch qcacld LA.UM.7.4.r1-06000-8x98.0
fw-api:
Code:
git remote add fw-api https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/wlan/fw-api
git fetch fw-api LA.UM.7.4.r1-06000-8x98.0
qca-wifi-host-cmn:
Code:
git remote add qca-wifi-host-cmn https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/wlan/qca-wifi-host-cmn
git fetch qca-wifi-host-cmn LA.UM.7.4.r1-06000-8x98.0
If your image compiled /before/ adding the CAF drivers but didn't compile /after/, check that your config flags are up to date before changing code around. qcacld-3.0 threw some errors for me in the upgrade from 3500 to 6000 unless I /also/ enabled WLAN_TX_FLOW_CONTROL_V2 in the defconfig, then reverted some of LGE's older custom patches (check OEM patches before modifying CAF code!).
The easiest way to poke around at flags is by doing a menuconfig after you run your "make O=./out joan_tmo_us-perf_defconfig" equivalent.
Code:
make O=./out menuconfig
UPDATE LINUX
Coming soon. Still ascertaining the easiest process. Git merge sounds like an obvious choice.
<reserved>
When you get enough posts we can request a Mod move it to Development section. Thank you for your efforts in developing the V30 more.
ChazzMatt said:
When you get enough posts we can request a Mod move it to Development section. Thank you for your efforts in developing the V30 more.
Click to expand...
Click to collapse
My only other post was apparently waaay back in 2009 about my HTC Touch Pro 2. I'm hoping I can bounce off of questions on this thread and hit 10 posts relatively quickly. And thank you! Without all the work the community had done already I wouldn't be this far along.
I've found the flag to allow the latest GCC 10.1 to compile now. Looks like it became a lot more picky in version 9 and the qcacld-3.0 build fails a buffer paranoia check.
Wow, very impressive write-up. Thanks a lot for sharing it.
I spent quite some time studying parts of the H932 kernel (and other models too) to better understand how the QuadDAC is implemented (es9218p codec). But my background is almost the opposite of yours: I was a prolific assembly language and C programmer back in the days, but have almost zero Unix/Linux experience. I would never be able to build the kernel, not even with your guide, so I couldn't make any changes to the codec, as much as I wanted.
Anyways, great contribution to the community. Thanks again!
TheDannemand said:
I spent quite some time studying parts of the H932 kernel (and other models too) to better understand how the QuadDAC is implemented (es9218p codec). But my background is almost the opposite of yours: I was a prolific assembly language and C programmer back in the days, but have almost zero Unix/Linux experience. I would never be able to build the kernel, not even with your guide, so I couldn't make any changes to the codec, as much as I wanted.
Anyways, great contribution to the community. Thanks again!
Click to expand...
Click to collapse
Collaboration is going to be key moving forward since we're probably not getting any more help from upstream. If you do make some improvements I'd be more than happy to fold it into a kernel release for testing.
I know a few other languages like Java and Python; I never had a reason to get my hands dirty with good ol' C until now. The syntax makes sense to me but I don't always have an underlying knowledge of the big picture. I won't be making my own kernel patches, instead pulling in known working code from newer sources.
CAF tag 6000 is running albeit with some obvious errors in the dmesg log. All the hardware seems to be working fine. I've had one soft reboot in 24 hours so it's getting to a point where I'll be able to release my source code/alpha build. I'm resisting the urge to name it "30e" to avoid confusion with official updates.
Caffination said:
Collaboration is going to be key moving forward since we're probably not getting any more help from upstream. If you do make some improvements I'd be more than happy to fold it into a kernel release for testing.
Click to expand...
Click to collapse
I'm sure you saw these other V30 custom kernel stuff:
https://github.com/zachariasmaladroit/kernel_lge_msm8998
Haumea kernel is the one I hear most about on Telegram group.
Of course compatibility is concern because T-Mobile H932 has different RSA encryption but maybe there's something there to give you ideas.
Caffination said:
Collaboration is going to be key moving forward since we're probably not getting any more help from upstream. If you do make some improvements I'd be more than happy to fold it into a kernel release for testing.
Click to expand...
Click to collapse
Thank you for the offer. It's over a year ago I looked at V30 kernels, and unfortunately that window has since closed for me. For one thing, I no longer have H932 (now on US998). But also, I lost much of my hearing to a nerve disease, so my interest in the QuadDAC is now purely academic.
Once again, I love your project and spirit, and much look forward to your postings around here.
TheDannemand said:
But also, I lost much of my hearing to a nerve disease, so my interest in the QuadDAC is now purely academic.
Click to expand...
Click to collapse
Very sorry to hear that.
ChazzMatt said:
Very sorry to hear that.
Click to expand...
Click to collapse
Thank you, buddy. Yeah it sucks.