Related
https://github.com/StarKissed/starkissed-kernel-ekgc100
This repository will include the kernel source from the "Update 1" version of the kernel.
The compile instructions included with the source do not cover making any modifications to the kernel and the previous thread seems to mirror those instructions, so this one will be dedicated to creating custom kernels.
The buildKernel.sh script is fairly straight forward to demonstrate the process, but the config files have a few eccentricities when building the wifi. When loading the config during the build, there are prompts for the bcmdhd parameters that are not referenced anywhere, as the system image does not include any bcmdhd firmware files.
The repository includes a generic ramdisk, as none is provided. Odin flashes the boot.img as a compiled file, so the ramdisk cannot be merged during install like most phones do to maintain the current version. A key note to this is that modules are built into the boot.img ramdisk, which is confusing not coming from any device that does not require Odin.
Edit: The last comment on ramdisk flashing during the install may soon be resolved. There are compatible tools to pack a ramdisk made for the recovery platforms, allowing those items to be included in a zip with the kernel. All that is needed is a custom recovery and that is in the works.
Hello..
Yesterda I do some test to port MultiROM recovery on our phone, after apply 6 of kexec hardboot patches files, compiling zImage was fine and after test and boot fine but kernel doesn't really stable (perhaps for missed patches), reading Tasssadar porting guide, there are 3 files that should be patches to get multirom work.
@GHsR
@CoolDevelopment
what are the evquivalent files of device_lge.c and restart.c on our kernel source to apply the rest of pacthes? thanks a lot
Porting guide:
https://github.com/Tasssadar/multirom/wiki/Porting-MultiROM
Capri patches:
https://github.com/hak86/capri_implement_kexec_hardboot/tree/aosp
Device tree:
https://github.com/hak86/android_device_samsung_i9105p/tree/omni-5.0
There are no completely equivalent files. The capri mach kernel works in a different way than qualcomm ones. You need to understand the source code and implement things by yourself. Important is, that you wipe the memory at the correct addresses
Good luck
CoolDevelopment said:
There are no completely equivalent files. The capri mach kernel works in a different way than qualcomm ones. You need to understand the source code and implement things by yourself. Important is, that you wipe the memory at the correct addresses
Good luck
Click to expand...
Click to collapse
to not talk about compatible device tree to build recovery.img, it's generate a 10mb of recovery.img that image we can't install on our recovery partition due to space issue.
I found this one called DualBoot Patcher, actually it's for qualcomm devices, but I think we can port quickly, we just need to add ramdisk from our phone,
http://forum.xda-developers.com/showthread.php?t=2447534
haky 86 said:
to not talk about compatible device tree to build recovery.img, it's generate a 10mb of recovery.img that image we can't install on our recovery partition due to space issue.
I found this one called DualBoot Patcher, actually it's for qualcomm devices, but I think we can port quickly, we just need to add ramdisk from our phone,
http://forum.xda-developers.com/showthread.php?t=2447534
Click to expand...
Click to collapse
You can get a dualboot recovery but to actually use multirom you need kexec-hardboot
LazyFlasher & no-verity-opt-encrypt
INTRODUCTION
Hello Users and Developers of XDA!
LazyFlasher is a custom kernel flashing tool designed to make it easy to dynamically modify ramdisks and inject kernel binaries into the current boot image.
It's the swiss army knife of kernel flashing for use in Team Win Recovery Project.
The intent behind it was to allow a 1 custom kernel fits all approach, where your users can flash single zip on any ROM for a particular device,
allowing your kernel to be compatible with the vast majority of custom ROMs already out there. It takes away the pain of building custom boot.img
for each and every variant a user requests and puts it into 1 low maintenance intelligent universal flashable zip.
You might already know of @osm0sis's AnyKernel2 project. This approach is similar to that. Back in late 2015 I decided to design a more compatible, more friendly, and more feature filled version. Since then, AnyKernel2 has apparently improved a lot so if LazyFlasher doesn't accomplish what you need, AnyKernel2 probably will.
LazyFlasher does not currently support ELF boot images.
For users of no-verity-opt-encrypt: This thread can also be used to discuss the no-verity-opt-encrypt project which is just a minimal version of the LazyFlasher framework.
Disqus thread: https://www.xda-developers.com/xda-...-is-an-alternative-to-the-anykernel2-project/
THE GITHUB REPOSITORY
You can find LazyFlasher's development and download it here: https://github.com/jcadduono/lazyflasher
LazyFlasher source code is distributed under the BSD 2-clause license. You can do anything you want with it, however, some of the binaries used by it are under GPLv2 or GPLv3 licenses.
FEATURES
ChromeOS support (ChromeOS test-key signing and recognition)
MediaTek device support (MTK headers)
SELinux policy injection support via sepolicy-inject
Example scripts to disable dm-verity or forced encryption during the install process (010-no-force-encrypt, 015-no-dm-verity)
A process that executes a sorted list of scripts for making the desired modifications (separate from the framework)
Handily unpacks, decompresses, applies changes, compresses, and repacks boot images quickly and safely
Supports Gzip, LZ4, Bzip2, and LZO ramdisks. Support for LZMA and XZ is a work in progress
Supports arm (armv7), arm64 (aarch64), x86 (i386), x86_64 (amd64), mips, and mips64 architectures
Supports dtb.img replacement (place it in the root folder named "dtb.img")
Scans fstab and partition locations for the boot partition, optionally allows a preset location
Intelligently installs kernel modules by copying the previous layout of /system/lib/modules and creating symlinks
Creates modprobe supported /lib/modules aliases if kernel modules are included in the installer (030-kernel-modules)
Installs new files to the ramdisk and sets their permissions automatically based on file type from ramdisk-patch (020-patch-ramdisk)
Includes an optional bbe tool for applying binary patches
Unnecessary architectures and tools can be removed to save space
Many useful functions and variables included in the patch.d environment to simplify modification/patching scripts (patch.d-env)
Simple "make" build system
SETTING UP LAZYFLASHER
LazyFlasher is only designed for building on Unix based systems such as Linux, Mac OS X, and FreeBSD.
To download it (feel free to fork it so you can have a copy on your GitHub to modify instead!):
Code:
cd ~/build
git clone -b kernel-flasher https://github.com/jcadduono/lazyflasher.git
cd lazyflasher
To use LazyFlasher, you'll probably want to take a look at the Makefile, config.sh, and META-INF/com/google/android/update-binary (a shell script).
There's a few things you can change there to personalize it to your needs.
(make another git commit to save your setup!)
You should also check out the README! There is a lot of useful information there.
Once the installer is set up to your liking, all you have to do to build it is copy the resulting kernel binary from your kernel build output into the lazyflasher folder.
If you have built with kernel modules (make modules_install), copy build/lib/modules -> lazyflasher/modules.
Now simply run:
Code:
make
A TWRP flashable zip and sha1sum is created!
You should consider signing the zip with AOSP test-keys so that users can verify its integrity before flashing it.
LOOKING TO TRIM DOWN THE INSTALLER?
I have forked the kernel-flasher branch to a branch called kernel-flasher-arm64-minimal. This provides all the features of kernel-flasher except sepolicy injection and bbe, and only supports arm64 devices. It reduces the minimum zip size from 1860 KB to 200 KB.
You can use this branch instead if you like. If you're using another architecture, just look at the trimming commit as an example and apply it for your arch.
BUT I AM ON LE WINDOWS!
How did you build your kernel binary?!
Anyways, there is an alternative for building it on Windows.
You can download the LazyFlasher kernel-flasher branch as a zip file from GitHub and extract it somewhere on your PC.
Make your modifications using Notepad++.
You can then use a tool such as 7-zip to create a zip file by selecting everything in the folder, right clicking, and going to 7-Zip -> Add to "lazyflasher.zip".
LIMITATIONS AND KNOWN ISSUES
It will not run on TWRP built in Android 4.3 or earlier (usually builds older than 2.8.0.0)
Requires Busybox to exist in the TWRP build. All official builds should have this.
There may occasionally be some devices that are unsupported due to extreme modifications made to the boot image format by the manufacturer. If you have one of these devices, feel free to contact me and I will try to add support for it if it is worth the effort.
If you have an issue, please gather a recovery.log from TWRP after flashing and I will try to look into it. I can't do anything to diagnose your problem without a recovery log.
Code:
adb pull /tmp/recovery.log
JUST WANT TO DISABLE VERITY/ENCRYPTION?
You can build lazyflasher by itself, empty, without a kernel image or modules and flash it!
It's already set up to automatically disable verity and make encryption optional.
Alternatively, there's a branch already set up called no-verity-opt-encrypt. You can find prebuilt official zips at: https://build.nethunter.com/android-tools/no-verity-opt-encrypt/
WHO ELSE IS USING LAZYFLASHER?
I'll keep a list here of cool projects that are using it. Feel free to ask for yours to be added.
The Kali Linux NetHunter project (GitHub, Website)
no-verity-opt-encrypt, no-verity-force-encrypt, twrp-data-fstype-swap (Website/Download)
WHAT IS LAZYFLASHER USING?
LazyFlasher makes use of a few open-source projects. You can find their source code here:
bootimg / libbootimg for boot image unpacking/repacking - https://github.com/jcadduono/android_external_libbootimg
bbe for binary patching - https://github.com/jcadduono/android_external_bbe
bzip2 for ramdisks - https://github.com/jcadduono/android_external_bzip2
lz4 for ramdisks - https://github.com/jcadduono/android_external_lz4
futility for ChromeOS boot image signing - https://github.com/jcadduono/platform_external_vboot_reference
sepolicy-inject for sepolicy policy injection - https://github.com/jcadduono/android_external_sepolicy-inject
XDA:DevDB Information
LazyFlasher, Tool/Utility for the Android General
Contributors
jcadduono
Source Code: https://github.com/jcadduono/lazyflasher
Version Information
Status: Stable
Current Stable Version: 5.1
Stable Release Date: 2017-02-01
Created 2017-02-02
Last Updated 2017-02-07
We should give this man award.
The Job that he has done with this and Nethunter is just amazing.
Thank you and keep up the good work
Nice tool. Keep up a good work
Great Work! Hope i can include it into my Projects in the Future...
Thanks a lot for that!
You are a goddamn god.
Honestly Annoying said:
You are a goddamn god.
Click to expand...
Click to collapse
thx dude, usually that phrase is reserved for Chainfire accomplishments
y u nu support mah Indian AF MTK fone @jcadduono
Kidding, awesome work on this though!
Good one , this man develops for the developers !
Is it possible to have this on i9100 ? AnyKernel2 doesn't work with i9100
Skyline said:
Is it possible to have this on i9100 ? AnyKernel2 doesn't work with i9100
Click to expand...
Click to collapse
nope, no plans to support that device, surprised they are still out there, i would expect most to be dead emmc by now. :|
you can probably modify boot-patcher.sh to copy partitions to split-img folder then flash them back instead of using bootimg
i don't even know if lazyflasher's binaries will run on any of the i9100 twrp builds. might be too old.
if i can get an example layout of i9100's partitions i can fork it to a new branch, called kernel-flasher-sgs2 and make it compatible for you guys.
jcadduono said:
nope, no plans to support that device, surprised they are still out there, i would expect most to be dead emmc by now. :|
you can probably modify boot-patcher.sh to copy partitions to split-img folder then flash them back instead of using bootimg
i don't even know if lazyflasher's binaries will run on any of the i9100 twrp builds. might be too old.
if i can get an example layout of i9100's partitions i can fork it to a new branch, called kernel-flasher-sgs2 and make it compatible for you guys.
Click to expand...
Click to collapse
They are too old but still supported by lineage 14.1 and official twrp 3.0.2-1 without any problems
osmOsis dev of anykernel2 said that i9100 and older devices are having different boot img header format when i tried to run anykernel2 script it says Android magic is not found something like that
interesting tnx
Wow...
I'm just recognizing now, how powerful lazyflasher is ...
Setting default.prop values and settings. Disable Encryptions and so on. Wish I could contribute something but I'm still learning how it works. For now I've just included lazyflasher into my PATCH to disable DM Verity and forced Encryption and to make some edits on the default.prop. That's really useful since the build.prop doesn't allows such deep changes.
@jcadduono what would be in the Theory possible with the Lazyflasher? Could we add things like Gouverneurs or default Kernel Clockings? Init.d Support? Sorry if I sound noobish :angel:
So, uh, is there a TL;DR for lazy people? :silly: :laugh:
@jcadduono this is absolutely awesome. thank you for your hard work.
Hope that someone can dev nethunter to Asus zenfone 5 t00f :fingers-crossed:
can you please make a tutorial vedio of it because i don't get it and i'm sorry for my stupidity
Will it work for Android Oreo / LOS 15?
Did anyone succeeded in removing dm-verity? I got this error
good
The Kernal Source has been released by Razer.
Links to the source is at the bottom of this page:
http://support.razerzone.com/mobile/razer-phone
Here are the links to the source just in case:
MR1 Releases:
Build 853
Build 851
Production Releases:
Build 822
Build 813
It has been talked about already but not in this section. This is where it belongs and nice job posting direct links to it.
https://forum.xda-developers.com/razer-phone/how-to/source-code-posted-t3719665
MedicStuder said:
Surprised no one else posted in the section with this. The Kernal Source has been released by Razer which means modding can start.
https://www.xda-developers.com/razer-phone-kernel-source-code/
http://www.androidpolice.com/2017/12/15/kernel-source-code-just-released-razer-phone/
https://www.gizchina.com/2017/12/16/razer-releases-kernel-source-files-razer-phone/
Links to the source is at the bottom of this page:
http://support.razerzone.com/mobile/razer-phone
Here are the links to the source just in case:
MR1 Releases:
Build 853
Build 851
Production Releases:
Build 822
Build 813
Click to expand...
Click to collapse
I mentioned it in the factory image thread 5 days ago
Mods, can we pin this in the dev section since it contains the links to the needed source code for development purposes. Seems appropriate to have it pinned in this thread. thanks.
I've also got the kernel source going with CAF history included (based on LA.UM.5.7.r1) at https://github.com/jcadduono/android_kernel_razer_msm8998/tree/android-7.1
Fixed a minor bug and added some build scripts to simplify the process of configuring and building.
Added qcacld-3.0 sources into the kernel build for WiFi drivers but I appear to be missing something so it doesn't build. :/
I'm sure someone here can figure that out!
For TWRP support, essentially you'll need to build the stock kernel with additional options like f2fs and exFAT if desired. The OS and TWRP will be sharing the same kernel binaries due to the A/B setup so you *will* need to build the WiFi driver, even for recovery.
If someone is daring enough, they can simply build TWRP normally (ex. for a non-A/B device), flash it to boot_b or boot_a partition (depending what's active), boot up TWRP, and make backups of the opposite A/B partitions.
This can't actually be too hard to do, Dees_Troy has already done most of the work by supporting A/B on Pixel devices already.
I suppose I'm willing to give it a try if anyone is willing to possibly lose the ability to get into the OS until Razer releases factory images.
The chance of that happening is pretty slim, as long as we're only flashing the *active* boot partition (we'll check that in OS using mount command), we should be able to simply grab a copy of the opposite boot partition and restore it to how it was.
YOU CAN simply use fastboot to swap to the other boot partition, restoring your OS to bootable even if TWRP fails to work. (we will test this first to make sure Razer has enabled this option...)
Probably safe, but there's just that risk.
As I'm unsure exactly how to compile the WiFi drivers right now, I'll do this:
Create a normal TWRP image, which you can flash to your *active* boot partition.
Create a TWRP flashable zip that will take the ramdisk from the active boot partition and flash it to the inactive boot partition's boot image, then flash the inactive boot partition's image to your active boot partition.
Result: Both partitions contain the original stock kernel image with TWRP support and a fully working OS.
Slight issue: F2FS won't be supported because the stock kernel will have module signing enabled and TWRP won't be able to load it.
I'm also fairly certain I'll never get decryption working myself for this device...it looks like the vendor partition may be required and it is already encrypted itself? (not encrypted on the Pixel 2 so this is new)
Dees_Troy will be getting his Razer Phone next week. If anyone can get TWRP working it's him. No need to worry ?
MishaalRahman said:
Dees_Troy will be getting his Razer Phone next week. If anyone can get TWRP working it's him. No need to worry ?
Click to expand...
Click to collapse
No way! :victory:
That's the best news I've heard yet
---------- Post added at 04:44 AM ---------- Previous post was at 04:30 AM ----------
jcadduono said:
I've also got the kernel source going with CAF history included (based on LA.UM.5.7.r1) at https://github.com/jcadduono/android_kernel_razer_msm8998/tree/android-7.1
Fixed a minor bug and added some build scripts to simplify the process of configuring and building.
Added qcacld-3.0 sources into the kernel build for WiFi drivers but I appear to be missing something so it doesn't build. :/
I'm sure someone here can figure that out!
For TWRP support, essentially you'll need to build the stock kernel with additional options like f2fs and exFAT if desired. The OS and TWRP will be sharing the same kernel binaries due to the A/B setup so you *will* need to build the WiFi driver, even for recovery.
If someone is daring enough, they can simply build TWRP normally (ex. for a non-A/B device), flash it to boot_b or boot_a partition (depending what's active), boot up TWRP, and make backups of the opposite A/B partitions.
This can't actually be too hard to do, Dees_Troy has already done most of the work by supporting A/B on Pixel devices already.
I suppose I'm willing to give it a try if anyone is willing to possibly lose the ability to get into the OS until Razer releases factory images.
The chance of that happening is pretty slim, as long as we're only flashing the *active* boot partition (we'll check that in OS using mount command), we should be able to simply grab a copy of the opposite boot partition and restore it to how it was.
YOU CAN simply use fastboot to swap to the other boot partition, restoring your OS to bootable even if TWRP fails to work. (we will test this first to make sure Razer has enabled this option...)
Probably safe, but there's just that risk.
As I'm unsure exactly how to compile the WiFi drivers right now, I'll do this:
Create a normal TWRP image, which you can flash to your *active* boot partition.
Create a TWRP flashable zip that will take the ramdisk from the active boot partition and flash it to the inactive boot partition's boot image, then flash the inactive boot partition's image to your active boot partition.
Result: Both partitions contain the original stock kernel image with TWRP support and a fully working OS.
Slight issue: F2FS won't be supported because the stock kernel will have module signing enabled and TWRP won't be able to load it.
I'm also fairly certain I'll never get decryption working myself for this device...it looks like the vendor partition may be required and it is already encrypted itself? (not encrypted on the Pixel 2 so this is new)
Click to expand...
Click to collapse
I'm willing to temporarily sacarfic my device for this. I will message you tomorrow morning and we can give it a shot.
We have lift off! @jcadduono you were right :highfive:
Waiting on you for further instructions on how to proceed.
Even if this leads to no where it sure feels damn good to see the twrp logo.
Everything is going well, we're getting copies of each partition and I'm working on making factory restorable images right now.
I am fairly certain I can even support encryption on this device with no issues.
The device itself actually supports hardware Qualcomm full-disk encryption like most non-Google Qualcomm devices so it's nothing new!
However, the Razer Phone supports HW encrypted SDcards like LG does, so TWRP needs support in the actual crypto code used in the project to work with encryptable sdcards. Maybe Dees_Troy will be up to that task when he gets his phone.
TWRP images will be distributed like so:
- A twrp.img file that you flash to your active boot partition
- A zip file that copies the TWRP ramdisk from your active boot partition into your inactive boot partition, then copies your inactive boot partition to your active boot partition
The zip file will effectively install TWRP and the next time you boot TWRP it will be relying on your ROM's kernel instead of the TWRP kernel.
jcadduono said:
Legend!
Mad props to you, can't wait to see more! :good: This will be a good Christmas, can I ask whether being carrier or not will matter for installation?
Click to expand...
Click to collapse
@jcadduono Legend!
Mad props to you, can't wait to see more! :good: This will be a good Christmas, can I ask whether being carrier or not will matter for installation?
P.s I'll take a pop if you want a second test
thread stuck like Chuck for now, hopefully we can get some dev going for this device.
yeahh !!!!!!! wake up dev teams !!
Any information regarding Franco kernel?
Introduction
In this guide, I will be using @krasCGQ's https://github.com/KudProject/AnyKernel2
You should know-
How to build a kernel properly.
How to use AnyKernel2 for making flashable zips.
I might not be able to answer all your questions as I am a bit busy these days so sorry!
Part 1: Changes to the kernel
1. You must firstly disable BUILD_ARM64_APPENDED_DTB_IMAGE in your defconfig(Check this for reference - https://github.com/rupansh/chimera_nich/commit/7af580533c79e179d146516a845301a32fe99220)
2. Secondly, you will have to find which dts your device uses. Its quite easy to figure that out just open arch/arm/boot/dts/qcom/Makefile in your source and find your chipset's config line. To figure out which one you should use, you can
check the history of the qcom folder in the dts folder.(You can check the history of the Makefile as well) here's are two example commits -
https://github.com/rupansh/chimera_...90747ba#diff-fb8cf9a1a0b868557516caf54f4e966b (My non treble source)
https://github.com/rupansh/chimera_...a778661#diff-fb8cf9a1a0b868557516caf54f4e966b (My treble source)
As you can see, the dtb i will need is msm8937-pmi8950-qrd-wt88537_64.dtb for non treble source and msm8937-pmi8950-qrd-sku1.dtb for Treble source. Sometimes it is just obvious which one to use(i.e it will have your device codename in some cases)
3.All right once you have found out which dtb you will need, build the kernel like you normally do(In this case an Image.gz-dtb won't be made by the way)
Next, you need to cd to <outdir>/arch/arm64/boot/dts/qcom and you will find your required dtb there in your respective sources.
Part 2: Changes to AnyKernel2
1. either you can clone https://github.com/KudProject/AnyKernel2 and delete the files in ramdisk and edit anykernel.sh according to your AnyKernel2 script, or
2. you can use these two commits for reference-
https://github.com/KudProject/AnyKernel2/commit/b55c00085c5bd3859627f579150cbd6d9687c0a0 && https://github.com/KudProject/AnyKernel2/commit/f4602f721631f95134a78b8c7eccccd3f5cd98f5 and edit your anykernel2 script accordingly. The changes are quite simple to understand. He simply added an "if" condition. It looks for ro.treble.enabled in buildprop and "if" the script finds it, treble DTB is combined with Image.gz(Which I will explain where to get) "else", (which means the other possibility which is if it doesn't find ro.treble.enabled) it simply flashes non-treble DTB with Image.gz . (Someone with basic coding knowledge can figure that out + it is quite well explained in the commit)
3. Once you have made your AnyKernel2 script ready to integrate, lets move to the next part
Part 3: Adding Required Files
1. Make a folder called "treble-supported" in the modified AnyKernel2 and copy your device specific dtb from your treble source to the folder.
2. Similarly, Make a folder called "treble-unsupported" in the modified AnyKernel2 and copy your device specific dtb from non-treble source to the folder.
3. make a dir called "kernel" in the Anykernel2 folder and copy Image.gz from any one of your source from <outdir>/arch/arm64/boot to it. (I just used the one from my treble source, Maybe you can use other sources as well but I can't confirm! An experienced person will tell you about that )
4. Zip the folder like you usually do and flash it! If it doesn't boot, You may have done something wrong with the script or more likely used an incorrect dtb!(Please don't use Image.gz-dtb). If it does boot, Congratulations!
Notes
1. You can name the folders(treble-supported and treble-unsupported) anything you want them to be as long as you make changes to the update binary
2. This script only detects on devices that have actually ported treble instead and it won't work with those that have only ported a seperste vendor
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
Also this is my first guide so please do tell if I did/said something wrong
Here's my fork if you want to check - https://github.com/rupansh/AnyKernel2
Credits -
1. @krasCGQ
2. @osm0sis
3. @tanish2k09 (For bringing me to the the android dev world)
Anyone I missed! (Please reply here or message me if I have!)
To note,
You can name them anything, as long as update-binary is also modified to point to the respective folders correctly.
Detection only works for differentiating treble-enabled and non-treble. It won't work for device that has "ported" separate vendor partition but not enabling treble yet.
Sent from my Redmi Note 4 using XDA Labs
krasCGQ said:
To note,
You can name them anything, as long as update-binary is also modified to point to the respective folders correctly.
Detection only works for differentiating treble-enabled and non-treble. It won't work for device that has "ported" separate vendor partition but not enabling treble yet.
Sent from my Redmi Note 4 using XDA Labs
Click to expand...
Click to collapse
Thanks for telling i will add this to notes
Awesome @rupanshji