(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.
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.
For developers: Say I have a CM source tree and I want to start building LineageOS instead. To save bandwidth, time, and disk space I don't want to start from a fresh "repo init". What set of commands can I use to convert my CM source tree to LineageOS?
For bonus points, separate instructions for a repo downloaded via a simple "repo init" vs one using the --reference option.
aaopt said:
For developers: Say I have a CM source tree and I want to start building LineageOS instead. To save bandwidth, time, and disk space I don't want to start from a fresh "repo init". What set of commands can I use to convert my CM source tree to LineageOS?
For bonus points, separate instructions for a repo downloaded via a simple "repo init" vs one using the --reference option.
Click to expand...
Click to collapse
https://gist.github.com/fourkbomb/0d94e286dc6f173eb9053c0d75e84783
The only thing I had to do different was to use the normal repo init command (not using ssh) on step 1, then the rest worked perfectly.
repo init -u git://github.com/LineageOS/android.git -b cm-14.1
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
CRUEL KERNEL S10 V2.3
The development moved to this thread. From V3 kernel supports multiple devices.
Introduction
This kernel is based on BTA8 samsung sources. Only G973F device for now. It is possible to use it on BSKO, BSL4, BTA8 firmware. All sources are open on GitHub.
Continuous integration with GitHub Actions is set up. This means you can customize the kernel from browser and build the version suitable for you without leaving the browser (see сustomization section).
Features
Customizable build with config presets
Only part of samsung security features disabled (DEFEX, Process Authentification, root restrictions)
Switchable SELinux (by default it's locked in "always enforcing" mode in samsung sources)
Built-in in Magisk
Wireguard for VPN
CIFS for SMB
Iptables TTL and HL editing modules for bypassing tethering restrictions
Build commands (configuration presets) used for V2.3 kernel:
Code:
$ ./build mkimg name=CRUEL-V2.3-BTA8 +magisk +nohardening +wireguard +ttl +cifs
$ ./build mkimg name=CRUEL-V2.3-BTA8-CANARY +magisk+canary +nohardening +wireguard +ttl +cifs
Installation Instructions
First of all, TWRP Recovery + multidisabler should be installed in all cases. This is a preliminary step. Backup your existing kernel. You will be able to restore it in TWRP Recovery in case of any problems.
Dowload an *.img file and
With TWRP: Reboot to recovery. Install > Install Image > CruelKernel.img > BOOT.
With Heimdall: Reboot to Dowload mode.
Code:
sudo heimdall flash --BOOT CruelKernel.img
With FK Kernel Manager: Flasher > Manual Flasher.
ChangeLog
V1 is based on BSKO sources and was privately used. You can find V1 by the link.
V2 is based on BTA8 sources. nohardening, nohardening2, cifs configuration presets added.
V2.1 is for internal use only (testing release) +nohardening preset activated by default
V2.2
Canary Magisk updated to 20305 version
MALI_KUTF kernel driver removed (it's required only for kernel developers)
Pin code problem fix (thanks geiti94)
+nohardening (disable samsung protections)
V2.3
Canary Magisk updated to 20306 version
Small fixes for image format
Downloads
CruelKernel-G973F-BTA8-v2.3
CruelKernel-G973F-BTA8-v2.3-CANARY
Sources
How to customize the kernel build
It's possible to customize the kernel and build it from the browser. First of all, create and account on GitHub. Next, fork this repository. Switch to the "Actions" tab and activate GitHub Actions. At this step you've got your own copy of the sources and you can build it with GitHub Actions. You need to open github actions configuration file (.github/workflows/main.yml) and edit it from the browser. For example, to alter the kernel configuration you need to edit lines:
Code:
- name: Kernel Configure
run: |
./build config name=CRUEL-V2-BTA8
+magisk
+ttl
+wireguard
+cifs
You can change the name of the kernel by replacing name=CRUEL-V2-BTA8 with, for example, name=my_own_kernel. You can remove wireguard from the kernel if you don't need it by changing "+" to "-" or by removing the "+wireguard" line and "" on the previous line.
Available configuration presets can be found at kernel/configs folder. Only the *.conf files prefixed with "cruel" are meaningful. For example:
magisk - integrates magisk into the kernel. This allows to have root without booting from recovery. Enabled by default.
magisk+canary - integrates canary magisk into the kernel.
ttl - adds iptables filters for altering ttl values of network packets. This helps to bypass tethering blocking in mobile networks.
wireguard - adds wireguard VPN module to the kernel.
cifs - adds CIFS (SMB) support.
nohardening - removes Samsung kernel self-protection mechanisms. Potentially can increase the kernel performance. You can enable this config if you face rooting or some other kind of restrictions. Other kernels usually use settings from this config by default. It's safe to enable this config, it just makes your system less secure.
nohardening2 - removes Android kernel self-protection mechanisms. Potentially can increase the kernel performance. Don't use it if you don't know what you are doing. Almost completely disables kernel self-protection. Very insecure.
nodebug - remove debugging information from the kernel.
300hz - increases kernel clock rate from 250hz to 300hz. Potentially can decrease response time. Disabled by default, untested.
1000hz - increases kernel clock rate from 250hz to 1000hz. Potentially can decrease response time. Disabled by default, untested.
For example, you can alter default configuration to something like:
Code:
- name: Kernel Configure
run: |
./build config name=CruelCanary
+magisk+canary
+wireguard
+nohardening
After editing the configuration in the browser, save it and commit. Next, you need to switch to the "Actions" tab. At this step you will find that GitHub starts to build the kernel. You need to wait about 25-30 mins while github builds the kernel. If the build is successfully finished, you will find your boot.img in the Artifacts section. Download it, unzip and flash.
To keep your version of the sources in sync with main tree (following updates), please look at this tutorial.
Support
This thread. Feature requests accepted.
Telegram (testing and intermediate releases).
GitHub Pull Requests if you want to contribute.
Credits
Samsung for kernel sources
topjohnwu for Magisk
geiti94 for showing that it's possible to built-in Magisk into the kernel. Initially I experimented with ASIG kernel, but ASIG+Magisk on ASIG firmware just stucks on boot with an SELinux initialization problem. At that time I doubted that built-in Magisk will work.
geiti94 for his help and advices
franciscofranco for FK Kernel Manager
XDA:DevDB Information
CRUEL KERNEL S10 , Kernel for the Samsung Galaxy S10
Contributors
evdenis, evdenis
Source Code: https://github.com/CruelKernel/exynos9820-beyond1lte
Kernel Special Features:
Version Information
Status: No Longer Updated
Current Stable Version: v2.3
Stable Release Date: 2020-02-12
Created 2020-02-10
Last Updated 2020-03-16
Reserved
How to build the kernel locally on your PC
This instruction assumes that you are using Linux. Install: mkbootimg, heimdall (if you want to flash the kernel with it).
Next:
Code:
$ git clone https://github.com/CruelKernel/exynos9820-beyond1lte
$ cd exynos9820-beyond1lte
# List available branches
$ git branch -a | grep remotes | grep cruel | cut -d '/' -f 3
# Switch to the branch you need
$ git checkout samsung-g973f-bta8-cruel
# Install compilers
$ git submodule update --init --recursive
# Compile (install mkbootimg first)
$ ./build mkimg name=CustomCruel +magisk+canary +wireguard +ttl +cifs +nohardening
# You will find your kernel in boot.img file after compilation.
$ ls -lah ./boot.img
# You can automatically flash the kernel with heimdall
# if you connect your phone to the PC and execute:
$ ./build :flash
# Or in a single command (compilation with flashing).
# ./build flash name=CustomCruel +magisk+canary +wireguard +ttl +cifs +nohardening
Boots phone but after entering pin goes to black screen then right back to the pin screen.g973f
gillim74 said:
Boots phone but after entering pin goes to black screen then right back to the pin screen.g973f
Click to expand...
Click to collapse
What ROM are you using? I tested it mostly on samsung BTA8 firmware.
evdenis said:
What ROM are you using? I tested it mostly on samsung BTA8 firmware.
Click to expand...
Click to collapse
Ambassadi same firmware but i think i know what it is.i never uodated the bootloader.i will try that first
gillim74 said:
Ambassadi same firmware but i think i know what it is.i never uodated the bootloader.i will try that first
Click to expand...
Click to collapse
If your phone was able to boot to pin screen, then I doubt the problem is in bootloader. Could you try V1 kernel https://github.com/CruelKernel/exynos9820-beyond1lte/releases/tag/v1.0
If it will work, then probably V2 will also work with +nohardening option. V1 compiled with this option, V2 without it. I will rebuild V2 then.
evdenis said:
If your phone was able to boot to pin screen, then I doubt the problem is in bootloader. Could you try V1 kernel https://github.com/CruelKernel/exynos9820-beyond1lte/releases/tag/v1.0
If it will work, then probably V2 will also work with +nohardening option. V1 compiled with this option, V2 without it. I will rebuild V2 then.
Click to expand...
Click to collapse
Same thing with version 1.could it be the twrp im using?
gillim74 said:
Same thing with version 1.could it be the twrp im using?
Click to expand...
Click to collapse
No, it's definitely not related to twrp. Well, I don't know what is an exact problem here, but some guys told me they were able to flash the kernel on ambassadi with data wipe or immediately after flashing the rom itself.
It would be very nice if people will just write if the kernel works or not on their roms. This will be a huge help for me.
evdenis said:
No, it's definitely not related to twrp. Well, I don't know what is an exact problem here, but some guys told me they were able to flash the kernel on ambassadi with data wipe or immediately after flashing the rom itself.
Click to expand...
Click to collapse
Data wipe or format data
gillim74 said:
Data wipe or format data
Click to expand...
Click to collapse
Data wipe should be enough. I will test compatability with Ambassadi today-tomorrow and will provide more detailed feedback. Thanks!
hello installation successfully the nikel kernel market for now
evdenis said:
Data wipe should be enough. I will test compatability with Ambassadi today-tomorrow and will provide more detailed feedback. Thanks!
Click to expand...
Click to collapse
Worked with data wipe
evdenis said:
It would be very nice if people will just write if the kernel works or not on their roms. This will be a huge help for me.
Click to expand...
Click to collapse
write me on telegram so i can say you why all get the pin code problem so you can fix it
Does this work with BSL7? Or know of kernel that will. Need my su permission to work
Paulturn84 said:
Does this work with BSL7? Or know of kernel that will. Need my su permission to work
Click to expand...
Click to collapse
Hi, no it will not work on BSL7. This kernel is for S10 (G973F) device. This device has only BSL6 firmware. BSL7 is for other devices. Try to look at nemesis kernel.
Is it possible to build magisk rooted kernel for pie (9) roms? Or it's only for Q like LOS 17?
vomad said:
Is it possible to build magisk rooted kernel for pie (9) roms? Or it's only for Q like LOS 17?
Click to expand...
Click to collapse
Download: https://cruelkernel.org/release/special/CruelKernel-G973F-ASJG-v1.1-LOS.img
This version is based on Android 9 (ASJG) sources and should work on ASIG firmwares. I've included some patches from ivanmeler LOS tree specifically for LOS. Features: Magisk v20.3, wireguard, ttl modules and cifs. Not tested
will he s10+ every be supported with this kernel?
Introduction
Based on samsung sources and android common tree. Supported devices: G970F/N, G973F/N, G975F/N G977B/N, N970F, N975F, N971N, N976B/N. All sources are open on GitHub.
Continuous integration with GitHub Actions set up. This means you can customize the kernel from browser and build the version suitable for you without leaving the browser (see сustomization section).
Features
Customizable build with config presets
Only part of samsung security features disabled (DEFEX, Process Authentification, root restrictions)
Switchable SELinux (by default it's locked in "always enforcing" mode in samsung sources)
Built-in in Magisk v21.1
Various toolchains (cruel,arm,samsung,proton,arter97...) supported
Wireguard for VPN
CIFS for SMB
Iptables TTL and HL editing modules for bypassing tethering restrictions
NTFS module for OTG usb drives
Moro sound module
Boeffla WakeLock Blocker
sdfat driver for vfat and exfat filesystems
reiser4 filesystem added. reiser4progs (https://github.com/CruelKernel/reiser4progs/releases)
DEX cable vendor lock for WQHD resolution removed
ZIP installer with XZ compression
ZIP installer with automatic os_patch_level patching
Build commands (configuration presets) used for V3.9 kernel:
Code:
$ ./cruelbuild pack model=<MODEL> name=CRUEL-V3.9 +magisk +nohardening +force_dex_wqhd +ttl +cifs +ntfs +sdfat +nodebug +noaudit +noksm +nomodules +wireguard +usb_serial +sched_powersave +sched_performance +morosound +boeffla_wl_blocker +fake_config +dtb
Where model can be one of G970F/N, G973F/N, G975F/N G977B/N, N970F, N975F, N971N, N976B/N.
Installation Instructions
First of all, TWRP Recovery + multidisabler should be installed in all cases. This is a preliminary step. Backup your existing kernel. You will be able to restore it in TWRP Recovery in case of any problems. Download an *.zip file. Reboot to TWRP. Install > Install ZIP > Flash CruelKernel.zip. Reboot to system.
ChangeLog
V3 - Support for G970F, G975F, G977B, N970F, N975F, N976B models.
V3.1 - Boeffla wl blocker, BTB5 sources for N10 models.
V3.2 - Magisk update v20.4, wireguard update, sdfat for VFAT, exFAT, ntfs module.
V3.3 - CTC9 sources. The camera will work only on CTC9 based firmwares.
V3.4 - CTE9/CTF1 sources. Small fixes, overall improvements, more customization configs for building on github.
V3.7 - Various toolchains added (arm, arter97, samsung, proton, system, default)
V3.8 - DTI1 sources added for N971N, N976N.
DTH7 sources added for G977N model.
Some debugging flags disabled. performance config fixed (-O3).
Cruel toolchain added (gcc 10.2 with PGO/LTO and inlining params from gcc 9 branch)
simple_lmk added (github.com/kerneltoast/simple_lmk)
V3.9 - G977N, G973N models added.
G970F/N, G975F/N, G973F/N updated to DTJA.
N976B, N970F, N975F updated to DTJ4.
Magisk updated to v21.1 version.
Vendor lock for dp cable for DEX removed (thanks, fart1-git).
Zip installer implemented.
Automted os_patch_level level patching in installer (https://github.com/CruelKernel/clone_header).
Downloads
OS Patch Level: 2020-11
V3.9 Download folder
Sources
If you like the work and want to help me with hosting: https://www.paypal.me/evdenis Hitting star button on GitHub and thanks button on XDA really helps to stay motivated.
Instructions here could be outdated a bit, one can find the latest version in project's readme at github.
How to customize the kernel build
It's possible to customize the kernel and build it from the browser. First of all, create and account on GitHub. Next, fork this repository. Switch to the "Actions" tab and activate GitHub Actions. At this step you've got your own copy of the sources and you can build it with GitHub Actions. You need to open github actions configuration file (.github/workflows/main.yml) and edit it from the browser. For example, to alter the kernel configuration you need to edit lines:
Code:
- name: Kernel Configure
run: |
./build config
model=G973F
name="CRUEL-V3.3"
+magisk
+nohardening
+ttl
+wireguard
+cifs
+sdfat
+ntfs
+tcp_cibuc
+morosound
+boeffla_wl_blocker
First of all, you need to change G973F model to the model of your phone. Supported models: G970F/N, G973F/N, G975F/N G977B/N, N970F, N975F, N971N, N976B/N.
You can change the name of the kernel by replacing name="CRUEL-V3" with, for example, name="my_own_kernel". You can remove wireguard from the kernel if you don't need it by changing "+" to "-" or by removing the "+wireguard" line and "" on the previous line. OS patch date can be changed with os_patch_level=2020-02 argument, the default current date is in build.mkbootimg.G973F file.
Available configuration presets can be found at kernel/configs folder. Only the *.conf files prefixed with "cruel" are meaningful. For example:
+magisk - integrates magisk into the kernel. This allows to have root without booting from recovery. Enabled by default.
magisk+canary - integrates canary magisk into the kernel.
bfq - enable bfq I/O scheduler in the kernel.
sched_... - enable various (conservative, ondemand, powersave, userspace, performance) CPU schedulers in the kernel.
ttl - adds iptables filters for altering ttl values of network packets. This helps to bypass tethering blocking in mobile networks.
wireguard - adds wireguard VPN module to the kernel.
cifs - adds CIFS (SMB) support.
tcp_cubic - use CUBIC as default TCP congestion control.
tcp_westwood - use WestWood as default TCP congestion control.
sdfat - use sdfat for exFAT and VFAT filesystems.
ntfs - enable ntfs filesystem support (read only).
boeffla_wl_blocker - enable boeffla wakelock blocker module.
morosound - enable moro sound control module.
+nohardening - removes Samsung kernel self-protection mechanisms. Potentially can increase the kernel performance. Enabled by default. Disable this if you want to make your system more secure.
nohardening2 - removes Android kernel self-protection mechanisms. Potentially can increase the kernel performance. Don't use it if you don't know what you are doing. Almost completely disables kernel self-protection. Very insecure.
nodebug - remove debugging information from the kernel.
noksm - disable Kernel Samepage Merging (KSM).
nomodules - disable loadable modules support.
noaudit - disable kernel auditing subsystem.
300hz - increases kernel clock rate from 250hz to 300hz. Potentially can improve ui responsiveness.
1000hz - increases kernel clock rate from 250hz to 1000hz. Potentially can improve ui responsiveness.
For example, you can alter default configuration to something like:
Code:
- name: Kernel Configure
run: |
./build config
os_patch_level=2020-12
model=G975F
name="OwnKernel"
+magisk+canary
+wireguard
+nohardening
+1000hz
After editing the configuration in the browser, save it and commit. Next, you need to switch to the "Actions" tab. At this step you will find that GitHub starts to build the kernel. You need to wait about 25-30 mins while github builds the kernel. If the build is successfully finished, you will find your boot.img in the Artifacts section. Download it, unzip and flash.
To keep your version of the sources in sync with main tree, please look at one of these tutorials:
How can I keep my fork in sync without adding a separate remote?
How do I update a GitHub forked repository?
Support
This thread. Feature requests accepted.
Telegram (testing and intermediate releases).
GitHub Pull Requests if you want to contribute.
Credits
Samsung for kernel sources
fart1-git for disabling DEX cable vendor lock
corsicanu for default blocklist of wakelocks for boeffla_wl_blocker driver
Nico (@NicoMax2012) for porting moro sound module
bamsbamx for porting boeffla_wakelock_blocker
thehacker911 for general improvements and advices
ExtremeGrief for overall improvements, porting maple scheduler
geiti94 for his advices
topjohnwu for Magisk
franciscofranco for FK Kernel Manager
and testers.
I'm sorry if I missed someone, just write me and I will update the list.
XDA:DevDB Information
[KERNEL] CRUEL KERNEL S10/Note10, Kernel for the Samsung Galaxy S10
Contributors
evdenis, evdenis
Source Code: https://github.com/CruelKernel/samsung-exynos9820
Kernel Special Features:
Version Information
Status: Testing
Current Stable Version: v3.9
Stable Release Date: 2020-12-01
Created 2020-03-08
Last Updated 2020-12-01
How to build the kernel locally on your PC
This instructions assumes you are using Linux. Install mkbootimg (AIK tool) from osm0sis, heimdall (if you want to flash the kernel automatically).
Next:
Code:
# Install prerequisites
# If you use ubuntu or ubuntu based distro then you need to install these tools:
$ sudo apt-get install build-essential libncurses-dev libtinfo5 bc bison flex libssl-dev libelf-dev
# If you use Fedora:
$ sudo dnf group install "Development Tools"
$ sudo dnf install ncurses-devel ncurses-compat-libs bc bison flex elfutils-libelf-devel openssl-devel
# Install mkbootimg
$ wget https://github.com/osm0sis/mkbootimg/archive/master.zip
$ unzip master.zip
$ cd mkbootimg-master
$ sed -i -e 's/-Werror//g' Makefile
$ make
$ sudo mv mkbootimg /usr/local/bin/mkbootimg
# Get the sources
$ git clone https://github.com/CruelKernel/samsung-exynos9820
$ cd samsung-exynos9820
# List available branches
$ git branch -a | grep remotes | grep cruel | cut -d '/' -f 3
# Switch to the branch you need
$ git checkout cruel-v3
# Install compilers
$ git submodule update --init --recursive
# Compile
$ ./build mkimg name=CustomCruel model=G973F +magisk+canary +wireguard +ttl +cifs +nohardening
# You will find your kernel in boot.img file after compilation.
$ ls -lah ./boot.img
# You can automatically flash the kernel with heimdall
# if you connect your phone to the PC and execute:
$ ./build :flash
# Or in a single command (compilation with flashing)
# ./build flash name=CustomCruel model=G973F +magisk+canary +wireguard +ttl +cifs +nohardening
Pin problem
The problem is not in sources. It's due to os_patch_level mismatch with you current kernel (and/or twrp). CruelKernel uses common security patch date to be in sync with the official twrp and samsung firmwares. You can check the default os_patch_level in build.mkbootimg.* files. However, this date can be lower than other kernels use. When you flash a kernel with an earlier patch date on top of the previous one with a higher date, android activates rollback protection mechanism and you face the pin problem. It's impossible to use a "universal" os_patch_level because different users use different custom kernels and different firmwares. CruelKernel uses the common date by default in order to suite most of users.
How can you solve the problem? 5 ways:
You can restore your previous kernel and the pin problem will gone
You can check the os_patch_level date of your previous kernel here https://cruelkernel.org/tools/bootimg/ and patch cruel kernel image to the same date. If your previous kernel is nemesis, patch cruel to 2099-12 date.
You can reboot to TWRP, navigate to data/system and delete 3 files those names starts with 'lock'. Reboot. Login, set a new pin. To fix samsung account login, reinstall the app
You can rebuild cruel kernel with os_patch_level that suites you. To do it, you need to add the line os_patch_level="<your date>" to the main.yml cruel configuration. See the next section if you want to rebuild the kernel.
You can do the full wipe during cruel kernel flashing
Good job!
Thanks Dev! Does this kernel work also with LineageOS and AOSP roms?
evdenis said:
...
After that you need to add the line os_patch_level="<your date>" to the main.yml cruel configuration and rebuild it. See the customization section if you want to rebuild the kernel.
Click to expand...
Click to collapse
Did you checked it if it works for you? For me the oneliner didnt work in main.yml. I must edit the build.mkbootimg.G975F file and rebuild. Then i got no pin problems cause the OPL was now changed.
hanspampel said:
Did you checked it if it works for you? For me the oneliner didnt work in main.yml. I must edit the build.mkbootimg.G975F file and rebuild. Then i got no pin problems cause the OPL was now changed.
Click to expand...
Click to collapse
Yes, I checked that it works. Here you did't use os_patch_level setting and the date is 2020-02. Next, you updated os_patch_level and you can see the date changed if you unfold "Show information about build" section in build log. In the third commit you removed the os_patch_level and cancelled the build, so the date reverted to default one 2020-02. And in finial commit the date was changed in build.mkbootimg.G975F file. If you doubt the date changed, you can check the build settings either in "Show information about build" section in build log or in "Kernel Configuration Info" file next to the kernel image in "Artifacts". Thanks!
Valentino911 said:
Thanks Dev! Does this kernel work also with LineageOS and AOSP roms?
Click to expand...
Click to collapse
As for now, it compatible only with Samsung based firmwares. Works on native samsung firmwares, BeyondROM, on Ambasadii it's better to use Nemesis kernel (you will face pin problem if you try to install cruel). The kernel doesn't work on LOS.
Anybody want gcam for exynos.. u can see tgis video it for android Q one ui 2.0 for s10plus exynos
I have a question . The hadest rum was established, respectively the hadest kernel. I install the cruel kernel, but after the reboot the kernel of the hadest returns. Why? The first time I encounter this phenomenon, How to solve the problem?
Before rebooting the cruel core, the necessary functions work. After a reboot, the hades kernel returns.
@evdenis
I got problems with your latest sources (3.0 and 3.1). It doesnt boot to recovery with an app. This works for a few commits earlier(last week or so). Now its not working. And the OSPL in main.yml doesnt work for me too. Doesnt pass the restart pin. But thats not a problem, changed it in the other side.
Cant test your compiled versions, pin problem, i was on nemesis kernel, so i have to compile it myself.
Another problem ive saw, the device doesnt shut down. It only reboots. Compiled with 3.0 and 3.1 sources. With the older source a week ago, it works.
Edit: So tried your released v3.1 and changed the OSPL manually for PIN Fix, seems to work(recovery and shutdown). Maybe something went wrong on my side till compiling. Have no clue atm.
hanspampel said:
Another problem ive saw, the device doesnt shut down. It only reboots. Compiled with 3.0 and 3.1 sources. With the older source a week ago, it works.
Edit: So tried your released v3.1 and changed the OSPL manually for PIN Fix, seems to work(recovery and shutdown). Maybe something went wrong on my side till compiling. Have no clue atm.
Click to expand...
Click to collapse
This could be due to enabling non-default configuration presets, like +nodebug or +nohardening2.
elchinemil said:
I have a question . The hadest rum was established, respectively the hadest kernel. I install the cruel kernel, but after the reboot the kernel of the hadest returns. Why? The first time I encounter this phenomenon, How to solve the problem?
Before rebooting the cruel core, the necessary functions work. After a reboot, the hades kernel returns.
Click to expand...
Click to collapse
Hades rom uses very good kernel. Technically, I don't see any reason to change it on hades rom, unless you really want to experiment with, for example, +1000hz or +bfq scheduler.
The reason the previous kernel restores back could be again due to patch level mismatch.
I will update installation method in the next version to dynamically repack kernel during installation procedure. Hope, this will solve os_patch_level problem (pin issue) once and for all.
nice kernel
Thanks for this wonderful kernel! It is an honour for me to be able to participate in this!
G975N
Working in 975N or not
hamidru said:
Working in 975N or not
Click to expand...
Click to collapse
If it works om F/FD devices. It will work on N devices
hamidru said:
Working in 975N or not
Click to expand...
Click to collapse
If it's an exynos device ... no reason to this