This is about the toolchain kindly posted by chulri in http://forum.xda-developers.com/showthread.php?t=891056 . Since I'm apparently not allowed to post in the devel forum (grr), I'm posting this here.
Chulri's instructions work fine, and I've successfully compiled me a kernel with IPv6 support -- thanks chulri. Beware, though, if building userspace binaries -- this toolchain does not create portable Android binaries.
Apparently there are two sets of Linux libraries available on Gen8 devices. The libraries in /lib and /usr/lib depend on uClibc, while the libraries in /system/lib depend on the usual Android "bionic" libc.
The toolchain posted by chulri builds against uClibc; binaries built that way will most likely not work on other Android devices, although they might work on uClibc-based Linux distributions (e.g. OpenWRT). In order to build binaries portable across Android devices, you'll want to use the toolchain included in Google's "Android NDK" (see the file docs/STANDALONE-TOOLCHAIN.html if you don't want to use Google's somewhat idiosyncratic build system).
Since chulri's toolchain is based on uClibc, most Unix utilities build out of the box. Typically, you just need to do:
Code:
cross ./configure --host armel-unknown-linux
make
(A side note -- Archos' libc is compiled with no IPv6 support, just like their kernel.)
Google's toolchain is more tricky, since it uses a non-standard libc. I've been fairly successful with variants of the following command-line:
Code:
make CC=$NDK/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc CFLAGS="--sysroot $NDK/platforms/android-5/arch-arm -Os -mthumb"
--jch
Wow does this ever seem appropriate for the development threads...
It sure does. Problem is you have to have ten posts before you can post in Dev sections. Real PITA for new users that aren't noobs.
Sent from my HTC Vision using XDA App
Moved to android development
Related
Hello,
I actually have successfully build some kernels. Mainly, this is the linux way:
- get kernel sources
- get hardware specific changes
- get the toolchain -> i'm using google prebuilt tree, with ARM tool chain 4.4.3 already compiled
- build with usual steps: def_config, configure, kernel, modules
All is ok.
Now, i found Android.mk files. Precisely, a previous kernel, with sensors related to my device, that i would like to port.
But here comes the trouble. I have hard time to do the link between Linux kernel for ARM and Android makefile. I don't see how it goes with my kernel, how i could compile this using the prebuilt tools i could grab from Google.
In short, how to include .mk files into a classic kernel ? What should i get in the end ? A module ? A replacement binary ? More precisely, what is exactly NDK and where it stands in the above layers ?
ARM Linux Kernel <--> Dalvik JVM <--> APK
Last, is it possible with Google prebuilt to compile the .mk without referencing your kernel ?
Thank you !
Thank you for your help
Damn ! Either the questions is too obvious, either it is too complex. Any help ?
Self reply: downloading the NDK is mandatory
- you can use your favorite toolchain, provided with the NDK
- you can embed the .mk into your application, for Eclipse / Android studio, it will use the NDK to compile
Dear Developers
I'm sure you already heard about the GPL around the forums. In case you did not, the GPL ("GNU General Public License") is the most common license that affects many projects, like the Linux Kernel (the Linux Kernel is licensed under the GPLv2). This affects us, XDA and its members, as we are often working with the Linux Kernel (every Android platform runs on top of the Linux Kernel).
You may ask yourself now "Well, that's nice, but how does this affect me and what does the GPL do?" The answer is pretty simple actually: The GPL guarantees users to examine, modify and share their and others code by enforcing open-sourceness. This means you are free to use any GPL'ed sourcecode for your project, but you must make your used code publically available again.
Now, as many advantages this has, it also means quite some work for us developers. All used sources must be completely public by the time the compiled binary (like a Kernel) goes online. Another requirement is, that the OP must include all information to compile the exact same binary as uploaded by the developer. This means you need to specify:
The used toolchain including its version (linking to your toolchain source is always a good idea)
The used defconfig
The link to your sourcecode (including the used branch, tags,...)
If used, also upload your scripts used for the compilation
If you upload a kernel, publish the source, but the source is not compilable, it means you are breaking the GPL as you did not release the used source. Breaking the GPL actually means breaking the law, which means the sanctions on XDA could possibly be the least of your problems...
Example:
GPL:
- Used sources (cm-10.1 branch)
- Used defconfig
- Used toolchain
- Used scripts
Click to expand...
Click to collapse
@ROM devs, using a precompiled kernel
As you are not compiling the kernel yourself, you do not have to give the above information. However, you have to link to the source of your kernel binary (for example: link to the OP of the used kernel). If you use the stock kernel, you must state this. Linking to the stock sources is not a requirement, but it is not the worst idea.
Keep in mind; if the kernel used is not GPL compliant, your ROM is not GPL compliant either. This may cause your thread to be closed and/or further action on your account may be taken.
Example:
GPL:
The kernel included in this ROM is located HERE. I have not altered anything.
Click to expand...
Click to collapse
If you need/want further information, you might want to take a look at THIS news article written by our Developer Admin pulser_g2
Whilst compiling Cyanogenmod I got this error:
Code:
ccache: FATAL: Could not find compiler "arm-eabi-gcc" in PATH.
Based on the manifest
https://github.com/LineageOS/android/blob/cm-12.1/default.xml#L542
the compiler is platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.8
from
https://android.googlesource.com/pl...inux-x86/arm/arm-eabi-4.8/+/android-5.1.1_r37
If I add that full path to my PATH variable I can compile the ROM successfully.
However, that seems wrong to me.
The compiler is already part of the source tree.
Shouldn't something in one of the make files or build scripts be setting this rather than me setting it manually?
Note: I am not using a custom toolchain, it is the standard one from aosp.
opticyclic said:
Whilst compiling Cyanogenmod I got this error:
Code:
ccache: FATAL: Could not find compiler "arm-eabi-gcc" in PATH.
Based on the manifest
https://github.com/LineageOS/android/blob/cm-12.1/default.xml#L542
the compiler is platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.8
from
https://android.googlesource.com/pl...inux-x86/arm/arm-eabi-4.8/+/android-5.1.1_r37
If I add that full path to my PATH variable I can compile the ROM successfully.
However, that seems wrong to me.
The compiler is already part of the source tree.
Shouldn't something in one of the make files or build scripts be setting this rather than me setting it manually?
Note: I am not using a custom toolchain, it is the standard one from aosp.
Click to expand...
Click to collapse
Toolchains aren't automatically set, at least for now. Possible causes being...
There are multiple versions of Toolchain that are synced together, and it isn't necessary that the newer version of the same toolchain "must" compile the code with success, which was properly compiled by an older version.
Also, by this, the developer has complete freedom to change the ROM/Kernel toolchain.
Coming to the Question in Thread Title, If you're building a ROM, then toolchain has to be added in PATH
Arvind7352 said:
Toolchains aren't automatically set, at least for now. Possible causes being...
There are multiple versions of Toolchain that are synced together, and it isn't necessary that the newer version of the same toolchain "must" compile the code with success, which was properly compiled by an older version.
Also, by this, the developer has complete freedom to change the ROM/Kernel toolchain.
Coming to the Question in Thread Title, If you're building a ROM, then toolchain has to be added in PATH
Click to expand...
Click to collapse
Thanks for clarifying.
Ideally it should scan the source tree for the compiler by default so it has something to fall back to in case a custom one is not specified.
What confused me is that I don't see this nugget of information specified in any of the guides I read about compiling ROMs.
Hello!
This is a development thread for the project of upgrading of the Linux kernel for the U8500 platform.
Builds provided here (at the moment of writing this message) are not considered to be used as a daily driver, by any means, - these are rather a dev preview versions.
For now, there are a several LK builds (the highest currently supported kernel version is 3.10).
Because builds here are really not stable, I'll just leave a disclaimer here.
Code:
#include <std/disclaimer.h>
/*
* I am not responsible for bricked devices, dead SD cards, thermonuclear
* war, or the current economic crisis caused by you following these
* directions. YOU are choosing to make these modificiations, and
* if you point your finger at me for messing up your device, I will
* laugh at you.
*/
Working features
RIL
Camera (front & rear) - only works in <3.8
Video (playback & recording)
Audio (playback & recording)
Wifi
Bluetooth (broken in >=3.8, needs a workaround to manually startup)
USB, ADB
Tethering (not tested)
GPS (not tested)
Sensors
Known bugs
IRQs are mishandled by some device drivers (abb_btemp, abb_fg)
proximity sensor might not work (not tested, cause it's broken on my device)
deep sleep might not work at a times
MMC driver works unreliably in >=3.8 (contiguous usage might lead in a data corruption)
networking is not fully-functional (no mobile data)*
camera is broken in 3.8
*some other features of the android kernel might not present - it's because these kernels lacks android-specific patches.
Sources
LK 3.5
LK 3.6
LK 3.7
LK 3.8
LK 3.9
LK 3.10
Downloads
http://xda.mister-freeze.eu/XDA-files/ChronoMonochrome/misc/upgrading
Installation
install chrono kernel r5.2 or higher (this is needed to pick up the necessary scripts, incl. bootscripts, etc)
reboot to recovery
install build linked in "Downloads" section
Credits
Linux kernel development community
Google
ST-Ericcson
Samsung
Team Canjica
XDA:DevDB Information
U8500 Linux kernel upgrading project, Kernel for the Samsung Galaxy Ace II
Contributors
ChronoMonochrome
Kernel Special Features:
Version Information
Status: Alpha
Created 2017-05-09
Last Updated 2017-05-10
Reserved
Porting
The porting a higher kernel version tehnique I'll describe here is not intended to be a guide for dummies. I'll assume you've already built a kernel for your device, familiar with git versioning control usage and with some porting / coding tehniques.
Firstly, you need a cleaned source for your device. By "cleaned" I mean, there are no Linux incremental patches, android changes applied, manufacture-specific patches are avoided when possible and so on - you need sources as closest to a "pure" Linux kernel as possible. Otherwise you'll have later need to deal with conflicts resolution, you'll most likely be unable to resolve and the kernel won't boot.
So, without a further forewords, the tehnique is below:
1) As was previously mentioned, a clean kernel source is required, I'll assume we are starting from LK-3.4 ( https://github.com/ChronoMonochrome/Chrono_Kernel-1/commits/ea228ee0f5e9935841aff25c62fa163cd78dc01d ) and porting a higher kernel versions. A kernel base needs to be tested for any bugs just to distinguish, which bugs were intruduced during porting from those ones that already present in a kernel base.
2) The following steps will mostly use git bisect and git merge commands in order to merge all the changes from a higher kernel versions and help to find / resolve the bugs that were introduced. I suggest copying a git kernel repo that you use for building to a somewhere else, so you can use it , e.g. for grepping a different versions source, bisecting the revisions and so on, so don't need to bother messing up in your main repo that you use for build.
3) Firstly, lets just try to merge a higher kernel version, e.g. LK 3.5 by issuing a command git merge lk-3.5. You'll likely have a lot of merge conflicts, most of which you can resolve with resetting the paths to a some revision (either a kernel base - lk 3.4, or the version you do port, or just another suitable conflict resolution). So I suggest to write those paths to a text file, like so:
Code:
arch/arm/boot
arch/arm/mach-ux500
arch/arm/plat-nomadik
drivers/mmc
include/linux/mmc
drivers/usb
include/linux/usb
drivers/mfd
include/linux/mfd
...
Write all the paths you intend to reset to the kernel base, you most likely need to re-use them later. To actually perform a resetting source, you can issue
Code:
for path in $(cat file_with_a_paths.txt | xargs)
do
git checkout COMMIT $path
done
Be sure not to put to this file anything not the device-specific! Resetting to the kernel base should be avoided when possible (never ever try resetting archictecture-specific paths, e.g. arch/arm/kernel, arch/arm/mm and so on - unless you really know that kernel will boot thereafter, instead, you have to manually resolve such conflicts). Resolve any other conflicts by resetting paths to the porting source (e.g. LK 3.5).
Note. While resetting with a paths is probably not the most accurate tehnique, but people don't live that long to use more accurate approach, e.g. performing git cherry-pick for every upstream commit and then manually resolving all the conflicts, you'll just sooner or later get bothered and will abandon it.
4) When you're done with the previous steps you can try building kernel. You'll likely have a build errors - because some part of a source got not updated (e.g. the device-specific drivers), you need manually implement the necessary by a higher kernel version changes. Firstly check if an upstream kernel contains the necessary fixes (example: https://github.com/ChronoMonochrome/Chrono_Kernel-1/commit/9fae8c449b710f502662da1cbcf26ece5a098af9 , https://github.com/ChronoMonochrome/Chrono_Kernel-1/commit/fe027c25d6db0d100937deb5248e249ec5b24ee7 ). If the driver you are porting doesn't exist in the upstream, you can also try to find a similar change and mimic it: https://github.com/ChronoMonochrome/Chrono_Kernel-1/commit/5f2e7afbf2ac3284dc62b3d96a0627c7f99ed4e9 ( ported similarly to https://github.com/ChronoMonochrome/Chrono_Kernel-1/commit/526c597 ). In the worst case scenario you will need to examine the upstream changes and apply the changes so that the drivers complies to the upstream changes: https://github.com/ChronoMonochrome/Chrono_Kernel-1/commit/ea6432d167 .
5) If everything is done properly and you're lucky enough, the compiled kernel might already bootup. If not, you'll need to find a culprint that doesn't let the device to boot up. Switch to a copy of your kernel sources, reset the source to the base kernel version (e.g. LK 3.4), issue git bisect good, then issue git bisect bad lk-3.5, git will reset to a somewhere in a middle between of LK 3.4 and LK 3.5.
6) Save your changes in the kernel repo, by assigning a some branch to it, switch to the source base, merge all the fixes you've already introduced, then merge the revision you have got in the previous step by bisecting the tree. Repeat these steps until you'll find a first bad commit.
7) If you are already on this step, the most trickiest part starts here - testing (hopefully) working kernel for bugs (if any). While logs can be useful sometimes (so you can google the failing messages and find something useful), there are also many bugs you can find only performing git bisect tehnique decribed above.
The decribed algorithm only possible thanks to having a clean kernel source. The usage of this guide is not limited only to the kernel porting, it can be used on other projects as well, this is just what I've come across to, when I've ever started porting Linux kernel versions higher than LK3.4.
Reserved
I wonder if any of this expertise couldn't look pretty cool here too.
Wooooowwwewe
Oooh
Look whose good boys have been trying to win the STE mastermind prize as of lately
https://github.com/novathor-mainline/linux
https://git.kernel.org/pub/scm/linu...inux-nomadik.git/log/?h=ux500-skomer-v5.5-rc1
mirhl said:
Oooh
Look whose good boys have been trying to win the STE mastermind prize as of lately
https://github.com/novathor-mainline/linux
https://git.kernel.org/pub/scm/linu...inux-nomadik.git/log/?h=ux500-skomer-v5.5-rc1
Click to expand...
Click to collapse
Seriously!
mirhl said:
Oooh
Look whose good boys have been trying to win the STE mastermind prize as of lately
https://github.com/novathor-mainline/linux
https://git.kernel.org/pub/scm/linu...inux-nomadik.git/log/?h=ux500-skomer-v5.5-rc1
Click to expand...
Click to collapse
Wow, that's incredible
Exynos4412 already got some mainline support, it would be very nice to have this one supported too.
Aaaaand it's done, kinda.
ST-Ericsson NovaThor U8500 - postmarketOS
wiki.postmarketos.org
device/testing/linux-postmarketos-stericsson · master · postmarketOS / pmaports · GitLab
postmarketOS package build recipes
gitlab.com
Introduction
I am writing this guide as I was unable to find a well-documented thread over XDA (there are just a lot of them). In case there is anything that concerns this guide, feel free to ask in this thread. I expect you to know the basics of Linux, GIT, Android. Please look over some guides in the forum in case you are not familiar with them. In case you want to contribute to this, feel free to do so. I welcome everyone's contribution to be it fixing my derp, pointing a mistake or adding a new section.
Links to some nice documentations:
Git Documentation
Linux Kernel Newbies
How to take logs in Android
How to get an Android kernel up to date with linux-stable
Checking Current CAF Tag of the Kernel
We will be using best_kernel for this purpose, whose aim is to compare your current kernel source code with different CAF tags and select the best possible match using git diff.
Clone/Download your kernel repo and commit your changes(if not already committed) as best_kernel depends upon git diff to compare changes.
Depending upon your kernel version, add required CAF kernel repo as remote and fetch it. best_kernel will use this fetched data to compare changes.
After fetch is done, run best_kernel. It should run automatically if you have placed dotfiles in the $BIN directory and have the necessary dependencies installed.
best_kernel will compare changes and will provide results based on that. However, depending on the number of tags, it will take time. A lot of time, so go and grab a cup of coffee till then.
A Dummy Example:
Downloading stock kernel source code from OEM’s website
Code:
wget http://nokiaphones-opensource.azureedge.net/download/phones/Nokia6.1_V2.22J.tar.bz2 && tar xvjf Nokia6.1_V2.22J.tar.bz2 && cd kernel
Adding and committing all files due to lack of a .git dir.
Code:
git init && git add --all && git commit -m "Initial Commit"
As the kernel source code version is 4.4, I will add 4.4 remotes from CAF and fetch it.
Code:
git remote add caf https://source.codeaurora.org/quic/la/kernel/msm-4.4/ && git fetch caf
After fetch, I will check for the current CAF tag using best_kernel. As my device platform is sdm660 and CAF has been releasing sdm660 tags as sdm660.0, I will be using it as an argument in best_kernel. This will ensure that best_kernel doesn’t waste time checking CAF Tags of other platforms and will speed up the process considerably.
Code:
best_kernel "*sdm660.0"
RESULT will be something like this:
Code:
Best match TAG: LA.UM.6.2.r1-06900-sdm660.0 Lines changed: 177924
What is CAF/Code Aurora | CodeAurora Android Releases Page | CAF Kernel Sources
Creating/Importing GIT History for Kernel Source
A lot of OEMs release kernel sources in a compressed format excluding the .git dir which results in no git history. Creating or it's better to say to import one is simple and easy.
Download and check the current CAF tag of your Android kernel source.
Note: If your chipset is not Qualcomm, you should visit Linux Kernel Source or AOSP's Kernel Common and use that as a base while checking out to the specific version of your kernel source you are going to copy-paste. Qualcomm devices can also use that as a ref but I will recommend them to use CAF source.
Based on that CAF tag, download the respective kernel repository from CAF and checkout for that specific tag.
Copy and paste your downloaded kernel source (with no history) over the CAF one (which has the history of that CAF tag).
Commit the changes.
You have accomplished creating/importing history.
A Dummy Example:
My current CAF tag is LA.UM.6.2.r1-06900-sdm660.0.
Therefore, cloning kernel source from CAF and checking out for this tag while creating a new branch named rebase.
Code:
git clone https://source.codeaurora.org/quic/la/kernel/msm-4.4/
cd msm-4.4/
git checkout tags/LA.UM.6.2.r1-06900-sdm660.0 -b rebase
Now, I will copy-paste the kernel source that I downloaded from OEM's website over the CAF one. Assuming the downloaded kernel is in ~/Downloads/kernel and CAF kernel source is in ~/msm-4.4 directories.
Code:
#Renaming the dir so, that it will get merged while copying due to similar names
mv kernel/ msm-4.4/
cp -avr msm-4.4/ ~/msm-4.4
cd ~/msm-4.4
git status
git commit -m "Import Nokia Kernel Source"
Keep in mind that a .gitignore is generated which can and will ignore files during commit which were not getting ignored earlier due to its absence. In case during compilation you encounter any error stating about missing file, add it forcefully and commit again.
Remember, its always good to split that one big commit into small parts. It's helpful when you start rebasing your kernel usually when new CAF Tag for new android versions come out. Solving a few conflicts ina lot of commit is much better than solving a load of them in one. It also gives you a chance to easily diff on websites like GitHub so that you can figure what's a particular line is doing.
Doing that is also easy. Just reset head for a particular folder like driver/touchscreen and commit them separately. Check git rebase documentation which will help you with this.
Upstreaming your Kernel
Merging upstream versions is a really good thing. It brings in security patches, stability, new features and much more. The usual and best way is to visit Linux Kernel Source and check if there are upstream updates available. If yes, start merging them in your kernel source one by one.
Note: If your chipset is not Qualcomm, you should visit Linux Kernel Source or AOSP's Kernel Common and use that as a base. Qualcomm devices can also use that as a ref but I will recommend them to use CAF source.
A Dummy Example:
Assuming my current kernel version is v4.4.205, I will fetch v4.4.206 from Linux Kernel Source and merge that. I can also fetch and merge different branches from CAF Source which are usually upstreamed with Linux-stable (for example, aosp/upstream-linux-4.4.y branch)
Code:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git v4.4.206
git merge FETCH_HEAD
Fix conflicts if you get some. What to keep and what not is a question that depends upon the device to device. Usually, you should compare local changes and upstream and try to figure out what could be the best way to fix it. I will advise to check the history of that file in upstream and see which commit caused that conflict and why. You can also check similar merges by other same kernel versions to see if they had the same conflict and how they fixed it.
I will also advise merging AOSP's kernel/common and new CAF upstream tags (Only QCOM devices should merge new CAF tags) regularly when available. The reason is pretty simple. There are commits that get merged in AOSP like which improves performance or other stuff which doesn't get merged in Linux Kernel Source. This way you can get the benefit from all sources. This, however, is not pretty easy and might result in a huge number of conflicts considering if OEM has modified the source a lot from upstream.
CAF also hosts f2fs and other file system changes on their servers. Merge it if you want and use it.
Compiling Standalone Kernel
Compiling a kernel standalone requires you to have a compatible toolchain like GCC or Clang. The best way to figure out which one suits your need is testing and debugging. The standard AOSP GCC toolchains are recommended for devices with old kernels, to begin with, while newer ones can use clang with backports or upstream merges. In case you want to compile with clang, checking out android-kernel-clang is a good way, to begin with.
Compiling standalone kernels can give a lot of missing headers errors/warnings. This is due to not compiling it in a ROM environment. This can be easily fixed either by correcting paths of those header files being included or creating an out dir manually and using it as output. You can also use this commit to do that automatically.
Clone your kernel source and desired toolchain(s). Export arch and cross compiler arguments. Choose the desired defconfig to make and compile.
A Dummy Example:
I will clone the kernel source and toolchain in the same dir and export the following arguments in kernel source root dir.
Code:
export ARCH=arm64
export CROSS_COMPILE=/media/hdd/aayush/kernel/aarch64-elf-gcc/bin/aarch64-elf-
make nokia_defconfig
make -j$(nproc --all)
Kernel conflicts might occur. You can search on GitHub to check if someone has fixed that already, otherwise fix the issues yourself. Comparing code with upstream repositories is also a way to figure out the differences. Choosing defconfig can be a bit tricky if you are doing bringups. I recommend pulling the current defconfig from your device itself. Its usually by the name of config.gz in /proc/ of your device.
Links to some cross compiler
GNU Toolchain by ARM
DragonTC
GNU and Linaro
Working with TWRP from Scratch
This post is supposed to help you with building TWRP from scratch for the first time if you are a newbie. There are some good resources already available for that over the web, specially XDA. I am linking some good ones below that you can read for more info on it.
How to compile TWRP Touch Recovery
The aim of a device tree is to contain the device-specific code for the build you are doing. In this case, as we are building TWRP which is a custom recovery, only flags relating to building TWRP and a normal recovery are enough to build it. Adding system specific codes like partition sizes for the system, vendor, boot and other doesn't contribute anything. An example tree can be begonia's tree hosted on TeamWin's org maintained by me.
Now coming to the device you want to build TWRP for, you will the following :
- A working kernel
- Device-specific binaries/libraries etc required for features like encryption which heavily differs on OEM implementation
AB devices need an extra commit in their kernel to make 'fastboot boot' command work: init: initramfs: disable do_skip_initramfs . Additionally if your device ships a separate DTBO image you will also need the following flag and the DTBO image: begonia: Build DTBO image into recovery
Newer devices are nowadays coming with 'fastboot boot' command disabled. Nokia 8.1 is an example of it. To make it work again, you might need to tweak bootloader which can prove to be risky.
Now coming to creating a device tree for TWRP. The very first step is to look out if someone else has booted TWRP on a similar SOC, OEM or same device. It can be used as a reference to fix similar/OEM related bugs and hacks quickly. In case, one doesn't exist, just pick a latest one from Teamwin's Github org for the android version you are compiling for.
Reserved (2)
Wew many thanks,
Thanks
Have just started exploring xda chef central.
I cam across this guide, really ahlepful Hope you complete it soon.
Updated the thread. Fixed formatting, links and added a new section.
How To Unofficially Unlock Bootloader For LG G8
We all know LG G8 is a android device. It's open source. But I recently bought a LG G8 only but it's locked to sprint sim . No any sim work. I can't unlock bootloader. I can't root. I can't flag firmware or install custom recovery. Anyone know here , how to totally remove firmware and but another firmware ? Why we can't build a method to do that?
TheImpulson said:
Updated the thread. Fixed formatting, links and added a new section.
Click to expand...
Click to collapse
Can you create a guide for, "How to Rebase an Android Kernel". Like from Android 9 to Android 10?
thanks for this guide bro
While using best caf kernel, Prefix of the caf tag should start with a -
For example, "*- sdm660.0"
@theimpulson
Hey there,
Am getting this error del.dog/megupebinu.txt
While trying execute best_kernel script
This is helpful, thanks mate
@theimpulson I had a question: (Before reading this guide) I had already downloaded stock Samsung sources and git init push the thing to my Github. So will anything bad happen if I did it this way or do I have to rebase it with CAF?
Also what are the benefits of these so-called CAF based kernels everywhere? Improved performance? Cuz I really wanted to compile my own kernel specifically for performance with WSL-2 (shameless plug)
Thanks in advance and sorry if the @ bothered you,
Ishaq
NullCode said:
@theimpulson I had a question: (Before reading this guide) I had already downloaded stock Samsung sources and git init push the thing to my Github. So will anything bad happen if I did it this way or do I have to rebase it with CAF?
Also what are the benefits of these so-called CAF based kernels everywhere? Improved performance? Cuz I really wanted to compile my own kernel specifically for performance with WSL-2 (shameless plug)
Thanks in advance and sorry if the @ bothered you,
Ishaq
Click to expand...
Click to collapse
The existing sources are fine, no issues if you are fine without any git history.
SOC specific optimizations, bug fixes etc. Nothing more. So, yeah, if you want SOC specific optimizations, performance improvements, you will want to merge latest CAF tags for your kernel.
theimpulson said:
The existing sources are fine, no issues if you are fine without any git history.
SOC specific optimizations, bug fixes etc. Nothing more. So, yeah, if you want SOC specific optimizations, performance improvements, you will want to merge latest CAF tags for your kernel.
Click to expand...
Click to collapse
thanks a lot for the reply! Another thing, because of your suggestion I tried to Import the git history (and i succeeded). Then I wanted to upload these sources to my own Github, which I can't figure out how to do. It only gives Github repo for the place where it came from (msm-3.18). Help me please
Edit: The guides which I found for merging CAF tags say that my base also has to be CAF (which it isn't) and this guide here basically does not work