Database Users

[HACK] Run scripts at boot-time on stock rooted 3.2 without reflashing (nfs modules)

Hi,
When you want to perform some scripts at boot-time, there is two possibilities :
- modify init.rc, but it requires to reflashing the rootfs image (modification in / does not hold after a reboot),
- using an android app like script manager, which will load your scripts at java/dalvik platform boot-time.
I've managed to find a way based on activating tf-daemon, which is a script called by the asus/ventana initrc, but disabled at boot-time. Basically, we're re-enabling this daemon by setting the property tf.enable to yes, and then creating a script called tf-daemon and put it in /system/bin. Since this script is called by init.ventana.rc as root, you can put whatever you want inside this script.
I don't know what is the original purpose of this daemon, but probably it's used by the asus team for internal and debugging purpose.
Be aware that in the next firmware update, this possibility could disappear.Let's hope the asus team does not read this post. Or at least they could allow power users to call custom scripts at boot-time.
As a case study, you will find as attachment a script for loading nfs modules at boot-time.
PS: damn, can't upload. Here is a temporary link : http://dl.free.fr/hwTZ0YBq2
Untar the archive, then su, and sh install.sh
At reboot, you should have nfs modules loaded.

Good find:
I gave this a try just to load a couple of my own modules that work with the kernel I'm using. Works fine -- Thanks, -

Another method is to make a script and just call it in the init.rc. After a firmware update you only have to add the "exec myscript.sh" line to init.rc. I personally prefer this method because it allows me to control when the script is executed, whereas the tf-daemon method is always executed at the same point(AFAIK). Good research though, always nice to know all the boot calls.

Modifying the init.rc was my first shot, but the problem is that init.rc lies in ramdisk. So when trying to modify, the modification does not hold
after reboot. So a real modification involves to reflash rootfs with nvflash, too much hassle for me. The method I'm providing is for lazy ones. ;-)

nice find, but the link is dead, could you please provide a new link for the script?
also, how do I load nfs module for there is none under /lib/modules, compile the kernel myself?

[TOOL] KernelModCorner - Extract and modify ramdisk - Rebuild kernel

This script is built from the knowledge gathered from:
http://forum.xda-developers.com/showthread.php?t=1332629
http://nookdevs.com/NookColor:_Build_the_Original_Kernel
http://nookdevs.com/User_talk:Warewolf
This script will let you extract the ramdisk off of the working kernel and will create a directory with the ramdisk for you to edit to your heart's content. The script will then download dalingrin's kernel source and move back to a known working commit (if it hasn't done this already.) The script will then compile said kernel and merge the new ramdisk to the kernel. The script will give you the option of backing up your current kernel and then pushing the new kernel into your touchpad.
Warning: I am not responsible for any damage that come to your touchpad.
Requirements:
It assumes you have all the required programs to compile the kernel. Maybe v2 will check for this and install the required items.
You must have adb somewhere in your user's PATH.
You must have mkimage in your path. Later versions may do thi for you.
How to use:
Place the script in a folder with a known working boot.img from the Touchpad's CM7.
Open a terminal window and browse to that folder.
Give the script execute permissions:
Code:
$ chmod +x KernelModCorner
Run the script:
Code:
$ ./KernelModCorner
This command bring up the following menu:
Code:
What do you want to do?
1: Extract from boot.img (Warning: This will delete any previously extracted ramdisk.)
2: Recompile kernel and merge with new ramdisk
3: Backup current uImage and transfer new one.
4: Clean up all temporary files and ramdisk (Note: This does not include the kernel sources.)
5: Restore backup.
6: Exit
You can probably figure out which options do what...
I just used it successfully to compile the following kernel (which I also started trying to overclock the GPU in... not sure if it is overclocked at the moment as most adreno's in the past have had their GPU clock locked... test it if you'd like and let me know.)

Great job on this invaluable tool
Thanks

I would suggest posting which kernel/CM release this script is intended to work with
since it is highly version specific.
The ramdisk offset being used will only work with one version. Also, there could be a mismatch between the git commit being used and any newer ramdisk/system.
To make the script less version specific, you could use uimage-extract available in the tools dir of the moboot source (see http://code.google.com/p/moboot/source/browse/#git%2Ftools). To compile, add "-lz".

[GUIDE] All you need to know about the ramdisk of the kernel

WHAT'S IN THE RAMDISK
So anyone who has compiled a kernel (for the X8) or is about to step into the world of developing android awesomeness through kernel building, should know that there are 2 (two) parts to the kernel:
The kernel image compiled from source code, and
The ramdisk
Both are equally important and are inter-dependent; without the kernel, the ramdisk is nothing (unless of course the devs come up with any other use) and without the ramdisk, the kernel is incomplete (again, this may change in the near future).
You (XDA-ians as I like to call you guys), especially those in the X8 sub-forums must have read viper001's kernel building guide. If you haven't, and do not want to read just 4 posts because of your laziness, it tells you how to compile your kernel image. Hah, now you are almost dying to read it. Well go ahead, read it.
Done reading. Well if you followed that guide to the letter (which I am sure many of you haven't), you'll have compiled your kernel with the FXP ramdisk. Now you want to build it from another source. It's pretty much the same process. However the FXP ramdisk won't work with this kernel. Not a chance (maybe a little). You need the ramdisk so you unpack the kernel using DooMLorD's tool (and forget to thank him; go thank him right now) and see a folder named kernel.sin-unpacked. You open it and see a bunch of files that you've never even heard of. You drop the kernel-building project.
This guide will hopefully eradicate that fear, or ignorance (maybe), and cover up what's in the ramdisk.
The parent (or root) directory of the ramdisk folder itself contains a bunch of files and folsers, which also contain more files.
Let's look at the contents in the root directory:
1 “modules” folder – This one is pretty easy. It contains the kernel specific modules that are loaded up at boot.
2 “res” folder – This folder contains another folder named “images” which contains images to be used in the recovery (more on that later).
3 “sbin” folder – Inside this folder are about 200 files (may vary), most of which are responsible for basic functioning of the phone.
4 default.prop – This file contains only a few lines of code that allow adb to run (line 4) and also makes the kernel insecure to give us permanent root.
5 init – This program initializes elements of the android OS and looks at the two following files:
6 init.rc – This file contains generic initialization code
7 init.<machine_name>.rc – This file contains device-specific initialization code.
8 initlogo.rle – This is the bootlogo (not the bootanimation which comes with the ROM).
9 pre_hw_config.sh – This file is executed at boot to get settings like cpu freq and governors just right.
10 recovery.fstab – This file specifies how the different partitions and file systems are to be mounted.
11 ueventd.rc – This file sets user or group (or root?) permissions on /dev nodes. (I got this line from the Internet and have no idea myself what the hell this means o_0).
12 ueventd.goldfish.rc – This file is empty in our kernels. Dunno why, though.
Now for the files in the /res/images directory:
1 icon_clockwork.png – This is the background seen in CWM.
2 icon_error.png and icon_firmware_error.png – These images are displayed on the screen when there is an error. Not sure though as I have never encountered any such error before in my life.
3 icon_firmware_install.png and icon_installing.png – These images are displayed when installing anything via CWM.
4 indeterminateX.png (where X is a number from 1 to 6, both inclusive) – This is basically the animation of the progress bar (the grey stripes moving forwards, or backwards, or both).
5 progress_empty.png – This is the progress bar during the initial stages of flashing anything in CWM.
6 progress_fill.png – This is the progress bar fill.
These are the files in the /modules folder:
1 sdio.ko – This is a file related to WiFi.
2 tiwlan_drv.ko – This is the tiwlan WiFi driver module.
3 tiap_drv.ko – This is the tiap WiFi driver module.
4 x8uv.ko – This is the undervolting module.
5 synaptics_i2c_rmi4_no_dt.ko – This disables dual touch in Synaptics.
6 synaptics_i2c_rmi4_dt.ko – This enables dual touch in Synaptics.
NOTE: I am not an expert.
More to come soon. See you and I hope sincerely that I do not get banned for this.

THE DREADED SBIN DIRECTORY
Going into the /sbin directory, we see a lot of files, the names of each sending shivers down your spine. But fear not, for sgt. meow will help you understand the functions of some important ones:
1. adbd – The file that allows you to use the adb shell. “adbd” stands for “Android Debugging Bridge Daemon”.
2. bootlogo – This file starts the kernel bootlogo (according to some user on the androidcentral forum; just saw a snippet on google search, opened the page and there was no thread).
3. bootrec – This file basically tells a kernel how to boot up a recovery
4. busybox – It lets you run LINUX / UNIX based commands (ls, gzip, uname etc.) that are required for root-level tasks.
5. dmesg – It is the Linux kernel's own logging system and is similar to logcat.
6. fix_permissions – This file applies and fixes permissions on the Android data folders.
7. insmod – This file is basically what is executed when you type insmod /..../../../../ xxx.ko (or similar) to load up the modules. An alternative way to do this is to write the line in hw_config.sh of /system folder (I guess) to load up modules at every boot. Or you could place the modules in the /modules directory of the kernel.
8. killrecovery.sh – This file, as the name suggests, kills the recovery when you exit it and boots into Android.
9. nandroid – The file responsible for nandroid backups.
10. nandroid-md5.sh – This file generates MD5 checksums for nandroid backups to verify its integrity.
11. reboot – This file reboots the phone when prompted to.
12. recovery – This is the recovery binary. For our devices, it is CWM recovery. This file can be changed easily (what I did with oxydo ICS) to other recoveries for this device for that version of Android.
Most of the other files are LINUX / UNIX based commands and some are files the functions of which cannot be explained by me.
More to come soon. Hope you enjoyed it so far.

FILES YOU CAN EASILY EDIT IN THE RAMDISK
There are some files in the ramdisk that can be edited pretty easily. There are also other files editing which means you gotta be RD or gotta have similar talent. Let's not go into that for now. The easy ones are:
1. initlogo.rle - The file that is easiest to edit. Basically you can convert any image to .rle format and replace it. make sure it is the right resolution.
2. /sbin/recovery - You can use recovery from another kernel (for the same Android version)and replace it in yours. You can also compile your own recovery binary by issuing the make recovery command after a successful CM build.
3./sbin/bootrec - You may have to change this when you change the recovery. Just a simple copy paste, that's all.
4. /sbin/rec_input - This file may need changing too when you change recovery.
5. /res/images/.. - Every .png file in this directory can be easily changed to any other .png file. Just make sure the resolutions are right, or else you will not be able to navigate properly in recovery.
6. init.rc - This file is easily changeable but you need to know what you are doing, otherwise you may mess up the boot sequence.
You can have a shot at changing other files, too. Lemme know how it goes.

CREDITS:
1. Allah Almighty (yes I'm a Muslim)
2. All XDA-ians, especially those in the X8 sub-forum for help (and for pressing thanks)
3. The Internet (Google, Wikipedia and Github mostly) for info
4. Me, for spending hours behind this guide.
5. My family, for not disturbing me while I was doing this. LOL

thank you
that is what i'm trying to understand :good:

This is for sure a valuable thread. Thanks for this!!
Sent With My Brains To Yours. Duh.

Nice thread , Captain Meow Meow
Sent from my X8 using xda app-developers app

sbin will take some time to cover but i will try my best.

sgt. meow said:
sbin will take some time to cover but i will try my best.
Click to expand...
Click to collapse
Its good to see that you are working hard...
Keep it up

great thread.thanks
sent from my x8™ using gingerzaraki®

THREAD UPDATED WITH SBIN CONTENTS. OMG. :wink:

Dude, you should make an *updated* Kernel Building Guide with new sources (i.e. alfs kernel or nAa kernel). Old one still uses FXP kernel source and outdated toolchain instead of Linaro.

RohinZaraki said:
Dude, you should make an *updated* Kernel Building Guide with new sources (i.e. alfs kernel or nAa kernel). Old one still uses FXP kernel source and outdated toolchain instead of Linaro.
Click to expand...
Click to collapse
And link to your sources as an example for others..

Banned? And why? This is usefull =))
Sent from my E15i using xda premium

@Rohin
yeah I might
@Elmir
that was a joke
@all
THREAD UPDATED WITH FILES THAT CAN BE EDITED AND CREDITS. :BIG GRIN:

TWRP 2.8.7 Recovery for including in Boot Image

This is TWRP 2.8.7, i.e. ramdisk-recovery..cpio built from source including the latest commit fixing failure to back to external SD. See here.: https://github.com/omnirom/android_bootable_recovery/commit/85161af11117431ff3a1d6b845e8faf35ef07b2c . I have also reduced annoyingly loud default vibration values...
This is not FOTA image, but rather a pre-built cpio ready to be included in your boot.img. It is built specifically for Xperia Z1 with all the appropriate flags.
Instructions:
1. Unzip the attached image, if you don't, you'll have a bootloop
2. Use Archi Kitchen to unpack your boot.img. Download from here: http://forum.xda-developers.com/showthread.php?t=2597220
3. Unpack kitchen, open terminal in that directory and do chmod a+x archi; then execute ./archi
4. Follow script directions and create a new project
5. Put your boot.img where the script tells you to
6. Execute ku to unpack kernel: you will have kernel directory in your project;
7. Go to /kernel/boot.img-ramdisk/sbin: you will see ramdisk-recovery.cpio file; just replace it with the attached one and execute kr to re-pack kernel.
8. You will have the new boot.img in project directory ready to be fastboot flashed.
9. If you touch anything else in unpacked kernel, your phone won't boot
10. From now and on, when you open archi kitchen, just pick (e) option for existing project and you can use any other boot.img to do the same.

optimumpro said:
This is TWRP 2.8.7, i.e. ramdisk-recovery..cpio built from source including the latest commit fixing failure to back to external SD. See here.: https://github.com/omnirom/android_bootable_recovery/commit/85161af11117431ff3a1d6b845e8faf35ef07b2c . I have also reduced annoyingly loud default vibration values...
This is not FOTA image, but rather a pre-built cpio ready to be included in your boot.img. It is built specifically for Xperia Z1 with all the appropriate flags.
Thanks. That is what I'm searching for for 2 days.
But it would be much better, if i could get totally rid of build in recovery.(TWRP will probabliy update.)
Click to expand...
Click to collapse
Click to expand...
Click to collapse

Building arm64 kernel for Galaxy S7 Edge (SM-G935F) question.

Hello,
First of all, im new to android modding and linux. I tried to build a kernel from stock G935FXXU1BPH6 source based on their readme file. My problem is, I don't have a zImage file after build that I could put into a flashable zip. I only have Image and Image.gz (I guess thats normal for arm64 kernels?) and I don't know how to make them flashable. I found a youtube video where the dude placed the Image file in a directory called "tools" in his flashable zip, I tried it and TWRP said I installed it successfully but when I start up my phone and check kernel version its still the previous one not mine.
Used this toolchain: aarch64-linux-android-4.9/bin/aarch64-linux-android-
I've set up CROSS_COMPILE path, then I set up configuration:
make ARCH=arm64 exynos8890-hero2lte_defconfig
make menuconfig (to tweak it a little bit more, like custom kernel version string so I can see if it worked)
Then I started build:
make ARCH=arm64
Output when build finished:
>>>>> Time used for generated all hashes is 6 sec
OBJCOPY arch/arm64/boot/Image
GZIP arch/arm64/boot/Image.gz
DTC arch/arm64/boot/dts/exynos8890-smdk8890.dtb
DTC arch/arm64/boot/dts/exynos8890-universal8890.dtb
Anyone knows how could I make it flashable? Thanks.

keezay said:
Hello,
First of all, im new to android modding and linux. I tried to build a kernel from stock G935FXXU1BPH6 source based on their readme file. My problem is, I don't have a zImage file after build that I could put into a flashable zip. I only have Image and Image.gz (I guess thats normal for arm64 kernels?) and I don't know how to make them flashable. I found a youtube video where the dude placed the Image file in a directory called "tools" in his flashable zip, I tried it and TWRP said I installed it successfully but when I start up my phone and check kernel version its still the previous one not mine.
Used this toolchain: aarch64-linux-android-4.9/bin/aarch64-linux-android-
I've set up CROSS_COMPILE path, then I set up configuration:
make ARCH=arm64 exynos8890-hero2lte_defconfig
make menuconfig (to tweak it a little bit more, like custom kernel version string so I can see if it worked)
Then I started build:
make ARCH=arm64
Output when build finished:
>>>>> Time used for generated all hashes is 6 sec
OBJCOPY arch/arm64/boot/Image
GZIP arch/arm64/boot/Image.gz
DTC arch/arm64/boot/dts/exynos8890-smdk8890.dtb
DTC arch/arm64/boot/dts/exynos8890-universal8890.dtb
Anyone knows how could I make it flashable? Thanks.
Click to expand...
Click to collapse
This particular chipset (64-bit Exynos) uses the uncompressed Image and a separate dtb.img file made from combining all the dtb revisions of your device codename and region into a DTBH format.
You can flash them using my LazyFlasher project.
See: https://github.com/jcadduono/lazyflasher
You will want to use the kernel-flasher branch. The kernel-flasher-samsung branch isn't fully ready and adds additional patch files to remove TIMA/Knox. I've yet to find out everything that needs to be changed from stock state to allow a bootable custom kernel without disabling encryption, unfortunately.
You can simply git clone it, then place your Image and optionally dtb.img in the root folder of the repository, then type "make" to build a TWRP flashable zip. They will be dynamically replaced in the current boot image on the device when the zip is flashed. You can check out the README.md for more info.
If you want to generate your own dtb.img to include in the installer, you can use a script I made from my universal8890 kernel sources on GitHub:
https://github.com/jcadduono/android_kernel_samsung_universal8890/blob/stock-6.0/dtbgen.sh
(correct the toolchain location for your build in the script)
It also requires the scripts/dtbTool folder (from the same git linked above) to be present in your repository. It's not the same as the Qualcomm dtbTool, and the sources are included (and fairly clean!) if you're interested in learning the Exynos dtb.img (DTBH) format.
./dtbgen.sh hero2lte xx
Now, there's still quite a bit that needs to be done to make the device actually boot successfully and be stable with a custom kernel. While the kernel is perfectly stable, the Samsung customized Android OS will absolutely freak out. That's a bit beyond me, and the reason I haven't really worked on any custom kernels for it myself.
Have fun!

jcadduono said:
This particular chipset (64-bit Exynos) uses the uncompressed Image and a separate dtb.img file made from combining all the dtb revisions of your device codename and region into a DTBH format.
You can flash them using my LazyFlasher project.
See: https://github.com/jcadduono/lazyflasher
You will want to use the kernel-flasher branch. The kernel-flasher-samsung branch isn't fully ready and adds additional patch files to remove TIMA/Knox. I've yet to find out everything that needs to be changed from stock state to allow a bootable custom kernel without disabling encryption, unfortunately.
You can simply git clone it, then place your Image and optionally dtb.img in the root folder of the repository, then type "make" to build a TWRP flashable zip. They will be dynamically replaced in the current boot image on the device when the zip is flashed. You can check out the README.md for more info.
If you want to generate your own dtb.img to include in the installer, you can use a script I made from my universal8890 kernel sources on GitHub:
https://github.com/jcadduono/android_kernel_samsung_universal8890/blob/stock-6.0/dtbgen.sh
(correct the toolchain location for your build in the script)
It also requires the scripts/dtbTool folder (from the same git linked above) to be present in your repository. It's not the same as the Qualcomm dtbTool, and the sources are included (and fairly clean!) if you're interested in learning the Exynos dtb.img (DTBH) format.
./dtbgen.sh hero2lte xx
Now, there's still quite a bit that needs to be done to make the device actually boot successfully and be stable with a custom kernel. While the kernel is perfectly stable, the Samsung customized Android OS will absolutely freak out. That's a bit beyond me, and the reason I haven't really worked on any custom kernels for it myself.
Have fun!
Click to expand...
Click to collapse
Thank you very much!

@jcadduono couldn't make the kernel boot after packing it with lazyflasher. I built a completely stock kernel from the mentioned source, pasted the "Image" (not the Image.gz) file in lazyflasher root and then used make command. Tried including "exynos8890-smdk8890.dtb" file as well. Same story. Not sure if I need anything else in the package or I made user mistake. Do you have any ideas how could I debug what makes it stuck on that screen?
Thanks!
EDIT: Solved Problem.

keezay said:
@jcadduono couldn't make the kernel boot after packing it with lazyflasher. I built a completely stock kernel from the mentioned source, pasted the "Image" (not the Image.gz) file in lazyflasher root and then used make command. Tried including "exynos8890-smdk8890.dtb" file as well. Same story. Not sure if I need anything else in the package or I made user mistake. Do you have any ideas how could I debug what makes it stuck on that screen?
Thanks!
EDIT: Solved Problem.
Click to expand...
Click to collapse
Can you help me set up an environment to build a kernel, arm64, for s7? I'm on Ubuntu having a heel of a time..

Galaxy S7 Edge Kernel Flashing Issues
I am currently trying to flash a different kernel into a galaxy s7 edge (SM-G935S).
I have gone as far as building a kernel and extracting a Image file from it, but every time I try flashing a boot.img with a replaced kernel image file, it seems to never work.
A mkbootimg tool that I am currently using requires a dtb file, but I cannot find where to get it from.
I have tried using @jcadduono's git code, but the dtb file created from it doesn't seem to work as well.
Can anyone tell me what I should do to flash a kernel successfully?

kernel panic after flashing
Hi @ll,
with this guide I was able to compile my own kernel and also flashing it to my phone. Unfortunatelly I'm getting kernel panic after rebooting the phone. is there any possibility to get the reason for this? Or do you have any hint, what I may have done wrong?
Thanks for your help.
Kind regards
v0ti