[MTD][TW][DEV][INIT.D]Base boot.cpio.gz for TW on MTD - Epic 4G Android Development

I have been trying out the various TW roms that run on MTD and have noticed some problems with the init.rc files that are being used, so I decided to create something that could be used as a base by others. I'm not sure who created the first TW rom on MTD, but they all seem to have mostly the same init.rc file, so I started from the one in tortel's EI22-Stock-ish MTD.
Things I changed:
Various changes and additions from the CM7 version
Removed plus tweaks (all of this can be taken care of elsewhere)
Added init.d support
Added support for /etc/init.local.rc
For init.d support to work, your rom must have the file /system/bin/sysinit, containing something like so:
Code:
#!/system/bin/sh
export PATH=/sbin:/system/sbin:/system/bin:/system/xbin
/system/bin/logwrapper /system/xbin/run-parts /system/etc/init.d
Every rom I've seen so far has, so it shouldn't be a problem.
How to use:
If you're not familiar with the format of the boot.img file that is flashed to the boot partition, check my other thread here. Basically is contains the zImage, and two ramdisks: boot and recovery. The zImage contains the kernel and a ramdisk: initramfs. The init.rc is located in the boot ramdisk, so I will distribute a copy of that. You can put this into your rom or kernel by deconstructing your boot.img with extract_boot.sh, replacing the boot.cpio.gz with this, then rebuilding the boot.img with mkshbootimg.py
Download:
boot.cpio.gz - 1.2 MB

Thank you. What I need is what changes the the kernel are needed to make a kernel work with MTD. I tried comparing my source tree with Tortell's but he had so many tweaks that it was hard to know what was really needed to make it work.

I thank you greatly for this good sir, and for all of your help !

Related

[SOURCE] Jelly Bean Kernel - Update 1 [Fixes Included]

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.

[Q] Kernel Compiling

Hello guys,
i have compiled a kernel for the oneplus one. But i am not sure if it will work so i want to know if these steps are right.
At first i forked francos kernel source + ramdisk.
After that i went into kernel source directory and typed this into the termnial.
Check my make.sh script https://github.com/DerRomtester/one_plus_one/blob/cm-11.0/make.sh
After that i went into the ramdisk source and extracted francos boot.img and deleted a file like this boot.img - zImage
Than i went into the kernel directory and started the build.sh file to get an boot.img file.
Everything went fine.
I had no errors. Are these steps correct.
My kernel source: https://github.com/DerRomtester/one_plus_one
Ramdisk source: https://github.com/DerRomtester/ramdisk_one_plus_one
I hope some devs can help me.

[ZIP] LazyFlasher - the swiss army knife of flashing custom kernels!

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

init.d support for Nougat based ROMs

I wanted a working init.d to mod some stock Interactive Gov settings in AospExtended ROM so I took the clever universal init.d enabler created by @_alexndr and modified it for a slightly different outcome.
The untouched version ends up using /system/bin/debuggerd as the host file to launch init.d support. This works perfectly well except debuggered is called at the post-fs-data point in the boot process.
This is too early for some init.d settings to stick as they can be overwritten later in the boot process by stock settings. I found /system/bin/mpdecision is called on property:sys.boot_completed=1 making it a much better candidate to use for our phone. So the original script has been modified to use mpdecision instead of debuggerd as the host file to start init.d
I also removed some lines automatically setting up a 99SuperSUDaemon init.d script since we may have magisk instead
All the magic is done in update-binary for those wondering how this works.
Tested working on AospExtended V4.2
Edit: to completely uninstall - delete /system/bin/mpdecision and rename /system/bin/mpdecision_real to mpdecision. Too easy!
Edit, edit: Some custom kernels disable mpdecision by renaming the same file that is being used here. That will prevent correct operation but can be easily overcome by first letting the custom kernel rename mpdecision (to mpdecision.bak) then make another (empty) file called mpdecision so it will become the host to launch init.d functionality. The key to correct operation is that the init.qcom.rc file still has the line that starts mpdecision.
Edit, edit, edit: What is wrong with the built in sysinit script to enable init.d you might well say.......2 problems: it requires busybox and it runs too early in the boot process (on post-fs-data)
Hope this comes in useful.

Multi kernel flash script for custom roms

I used this script to make my rom to be flashed on multiple variants with different kernel, ideal for Samsung devices but it will work on any device, either use whole script or just use the kernel flash script
Master branch includes full script including rom, kernel and magisk flash
Experimental branch includes only kernel flash script (copy and paste to end of your updater script)
https://github.com/Dyeide/multikernel-flash-script

Categories

Resources