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:
Related
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".
after numerous requests here we go!!!
no it's not complete yet, just starting...
firstly i'll just link up all threads from where i took collected my info, and then i'll start wiriting my how-to
it'll take time as my school and entrance exams are main priority at the moment but i'll do it in bits and pieces and i'll manage to pull it off before you x10 dies off .. ha ha ha
==========================================================================================================
SIMPLE GUIDE TO COMPILE KERNEL FOR X10i/X10a
=====================================================================================================
COMPILE AOKP FOR ANY XPERIA PHONE
=====================================================================================================
REFERENCE TO COMPILE AOSP/AOKP/CM7/CM9 FOR X10i/X10a
==========================================================================================================
firstly credits : >
1. DoomLord -> whose tools and info thread are just awesome
2. Zdzihu -> the biggest ever dev for x10 and for doing impossible feats
3. Freexperia Team -> for supporting this device for 2 years
4. Spaarc -> for his guide and his vast knowledge (guys!! this dude is 1 yr younger than me!!)
5. Azuzu -> for his awesome windows based tools
6. Androxyde -> flashtool and awesome shell scripts
7. Colossus -> for being the best mod ever !!! (yes i mean it buddy) and for guiding me a lot
8. Sahibunlimited -> for being me buddy and a really good friend to everybody here
9. GregBradley -> for being having the most useful signature in xda (and having helped me out when i was a noob)
10. LzVebz -> Pestering me to write this
phew!!! hope that's all?? more left?? please pm me, i'lll add you
EDIT
11. pvyParts -> for showing how to work on apk files
12. iridaki -> for being helpful and encouraging and pepping me up for all the good work i did and mostly for being an elder sister
13. ~Pilot~ -> for keeping xda clean
14. TAL333 -> for standing by me and believing in me
So firstly the threads that I read and YOU SHOULD PLEASE GO THOUGH ONCE before reading my Howto
spaarc's porting guide
doom's guide 1
doom's guide 2
doom's guide 3
doom's all in one info thread
doom's kernel.sin and ftf creator
doom's kernel.sin unpacker
dsixda kitchen (for "cooking" roms)
using android kitchen for xperia devices
http://forum.xda-developers.com/showthread.php?p=12875
Ok so as they say "safety first"
Let me give you your CRASH HELMET
It is said that x10 is UNBRICKABLE, though that is true but not hard and fast rule. Jerpelea and Doomlord have bricked x10 devices before and it's not all that impossible. Still, if you keep care of following things, you'll never brick your phone
1. NEVER DISCONNECT USB CABLE while flashing/bootloader unlocking/pccompanion upgrade is going on
2. Be extremely careful while using the_laser or 9Lukas5's unlock procedure. It changes device partition and mapper modules so they are delicate ares and can brick your device if procedure is not followed
3. DO NOT PANIC, THINGS CAN BE SET RIGHT. BE CALM, BE PATIENT, ASK FOR HELP AT XDA
=======================================================================================================================
Ok so, there can be bad flashes or whatever..... what to do if device does not boot up??
1. If the problem is about RED flashing led, then just plug your phone into a charger and wait over night it's a low charge problem. Once charged, all will be ok
2. If you face boot loop and you just do not know what to do (i.e. you cannot go to recovery too) then do this
a.) either download PC companion and update/upgrade your phone
OR
b.) download latest flashtool and flash a 2.1 for 2.3.3 firmware (that you get in .ftf format) that will set you on track
ok so to tell a few things first....
please do not pm me.regarding this.
ask any questions here.
i or any other member would definitely help
and dont get impatient.... I'm busy...so it'll take time to complete the guide
Sent from my X10S using xda premium
Finally it's here!!! Thanks man, I've been waiting for this
LzVebz said:
Finally it's here!!! Thanks man, I've been waiting for this
Click to expand...
Click to collapse
I've not yet started....feeling too lazy...but dont worry...in a week or two it'll be complete
Sent from my X10S using xda premium
Alright pretty dumb question feel free to shoot me. If I take an system ui apk and framework apk from say arc and just change it with my existing system ui n framework will I be getting the same theme of Sony arc.
Sent from my X10S using XDA
stanzzzzz said:
Alright pretty dumb question feel free to shoot me. If I take an system ui apk and framework apk from say arc and just change it with my existing system ui n framework will I be getting the same theme of Sony arc.
Sent from my X10S using XDA
Click to expand...
Click to collapse
maybe yes with systemui
DEFINITELY NOT with framework.
the framework res is not just the ui.
it defined the whole Android system...
it just cannot be ported like that....lol
@everyone
i won't shoot if you ask dumb questions.
you can ask dumb questions if you wish to.
that's the way we learn
Sent from my X10S using xda premium
Really happy to see someone doing this, thanks CS, may I suggest adding dooms guide to create update/amend scripts? I am sure you'll get to it! Best if luck with your exams too.
Sent from my X10i using XDA
[email protected] said:
Really happy to see someone doing this, thanks CS, may I suggest adding dooms guide to create update/amend scripts? I am sure you'll get to it! Best if luck with your exams too.
Sent from my X10i using XDA
Click to expand...
Click to collapse
never heard of that guide
I'll search and see....
i learnt amend and edify on my own by looking through various zip files....ha ha ha.
btw the dsixda kitchen makes edify/amend scripts automatically
Sent from my X10S using xda premium
championswimmer said:
maybe yes with systemui
@everyone
i won't shoot if you ask dumb questions.
you can ask dumb questions if you wish to.
that's the way we learn
Sent from my X10S using xda premium
Click to expand...
Click to collapse
Excellent! In which case, can you answer this question?
http://forum.xda-developers.com/showthread.php?t=1574805
blueowl0708 said:
Excellent! In which case, can you answer this question?
http://forum.xda-developers.com/showthread.php?t=1574805
Click to expand...
Click to collapse
decompile settings.apk and go through the xml files you get and play around with them a little....
Sent from my X10S using xda premium
this one
Ok, so lets get to our stuff fast
Her we begin with some info about how a ROM works
when cooking/porting roms, you are concerned with only a few folders
download any randon ROM zip and unzip it and see what it contains
1. /system/app -> this folder contains all apk files of apps
2. /system/framework -> this folder contains lots of .jar files that defines how the base operating system will run and function
3. /system/lib -> lots of .so files that are like drivers (yep .dll files in windows), these specify how the software communicates with various hardware components
4. /system/etc -> very dangerous folder contains lots of important configurations
5. /system/etc/permissions -> these contain lots of xml files that are required to define how the .jar files in framwork folder will work
ok so i'll elaborate point 2 and 5 a little more taking example of the panorama beta app by SE. it requires the com.sonyericsson.android.seee.jar file in framework folder to work but if you just keep the jar file, it'll not work. you need to sort out its permissions too and for that you need to put com.sonyericsson.android.seee.xml file in permissions folder
Click to expand...
Click to collapse
also the etc folder contains two some files called
gps.conf (which defines which gps server the device will use)
hosts (this defines which websites will be blocked .... yes that is your adblocker file )
apns.xml (which defines your apn configuration)
screwing up these files can cause you internet/gps/data traffic problems. also intelligent editing of these fils can give you better gps/data too
Click to expand...
Click to collapse
hey champ!
First I'd like to thank you very much for this nice guide and for your kernel. With latter u saved my ass. Was on Doom's with FeraLab and phone reboots sometimes Now it's flying!!!
But I'm fan of good design. And please don't hit me, but I'd like to change the boot-logo of your kernel is there any way? Or do u have any nice guide to change logo?
Would be awesome!!!
Question
Hi champ,
Does THIS also work for X10?
LzVebz said:
Hi champ,
Does THIS also work for X10?
Click to expand...
Click to collapse
not precisely.
for the perfect repacking script, see www.github.com/championswimmer/kCernel-goro
inside build-bootimg folder
Sent from my X10S using xda premium
championswimmer said:
not precisely.
for the perfect repacking script, see www.github.com/championswimmer/kCernel-goro
inside build-bootimg folder
Sent from my X10S using xda premium
Click to expand...
Click to collapse
Thanks!
I've one question left I think
I'm currently on Windows 7 ultimate, and I have 1 TB left on drive D (which is empty) My question is.. Is there a way to Dual-boot Windows & ubuntu without wubi?
Thank u very much again
Compiling kernel
So letme tell you how a kernel for x10 can be compiled
1. install ubuntu (through wubi or in vmware will also do) but i prefer on a separate partition.
2. Install the following packages
git-core gnupg sun-java6-jdk flex bison gperf libsdl-dev libesd0-dev libwxgtk2.6-dev build-essential zip curl libncurses5-dev zlib1g-dev
here's how you go about doing it
Code:
sudo apt-get install git-core gnupg flex bison gperf libsdl-dev libesd0-dev libwxgtk2.6-dev build-essential zip curl libncurses5-dev zlib1g-dev
sun-java6-sdk is no more officially available through ubuntu repositories
so you will need a workaround.... so here are some helpful articles
http://www.gaggl.com/2011/10/installing-java6-jdk-on-ubuntu-11-10/
http://superuser.com/questions/353983/how-do-i-install-the-sun-java-sdk-in-ubuntu-11-10-oneric
http://softwareinabottle.wordpress.com/2011/11/17/install-sun-jdk-6-on-ubuntu-11-10/
In case you are on a 64-bit version of ubuntu, (btw i strongly recommend using a 32 bit version for android development as you'll face various problems with 64-bit at various stages) you'll need these packages too
ia32-libs lib32z1-dev lib32ncurses5-dev gcc-multilib g++-multilib
3. Next you'll need a cross-compiler.
a cross compiler is used to compile for a different architecture than from the one you are currently working on. in this case you are either on a i686 or amd64 pc while the kernel you are compiling is for an ARMv7 processor.
for ubuntu, getting the Linaro GCC cross compiler for arm is getting as easy as
Code:
sudo apt-get install gcc-arm-linux-gnueabi
4. Now you are pretty much set up to compile kernels. Next we need sources.
So let me link you up to the most common available ones
Sony Ericcsoon Official Kernel Sources for 3.0.1.G.0.75 (gingerbread firmware)
Sony Ericsson Official Kernel Sources for Eclair Firmware
FreeXperia Kernel For ICS
FreeXperia Kernel for GingerBread
DoomKernel (this is my forked repo)
*** i'll update this list later (there are dozens of kernels for x10, all have their sources, i guess for now, this is enough)
5. So the source you have downloaded will be either a tar or zip archive. Using archiver, extract it into a directory of your liking.
6. Open terminal and 'cd' into the kernel directory. The kernel directory is the one which contains the folders arch, block, crypto, firmware, drivers .....
for compiling kernel you need to be in the root of this direcrory.
7. So here are a few codes that will get your kernel compiled
To clean source directory : -
Code:
ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make clean
ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make distclean
To get default configuration
Code:
ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make semc_es209ra_defconfig
if you are compiling FXP kernel then instead of semc_es209ra_defconfig you need to write fxp_es209ra_defconfig , and likewise for DoomKernel you need to use doom_x10_defconfig
To configure the kernel
Code:
ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make menuconfig
inside general setup you can name your kernel
and inside power management setup you can setup which CPU governors will be present and which will be default
do not mess to much with the driver setups or with "kernel hacking" area....
do not touch things that you have no idea about
Finally... to compile the kernel
Code:
ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make
If all goes well, you'll get this message
Kernel: arch/arm/boot/Image is ready
Kernel: arch/arm/boot/zImage is ready
If you get stuck in between, nothing to fret about. Just post here what problem you faced, amd me or some other helpful soul will help you out
8. I know you are thinking "whew!! are we done??"... ha ha ha!! no buddy!! not yet... much more work to do.
Firstly from you kernel directory go to arch/arm/boot (using a file explorer, not a terminal) and inside you'll find a 2~3 MB sized file called zImage. Copy that file into a separate folder where you'll stach all your finished works.
9. Now we need to compile the wifi modules.
It is imperative to note here that wifi modules should be compiled immediately after kernel has been compiled. DO NOT run "make clean" or "make distclean" commands in the kernel folder before wifi modules have been compiled
Click to expand...
Click to collapse
For compiling wifi, you'll need the "vendor" folder (which is there in official sony kernel sources but not present in Doom's or FXP's repo). So if you need just the vendor folder, you'll HAVE TO download the official kernel sources too.
in terminal 'cd' to vendor/atheros/wlan/host/ folder
edit the localmake.linux.inc file using a text editor
Code:
sudo gedit localmake.linux.inc
edit the line ATH_CROSS_COMPILE_TYPE := arm-eabi- to ATH_CROSS_COMPILE_TYPE := arm-linux-gnueabi-
also in the line
# ATH_LINUXPATH := < kernel source path >
remove the # (uncomment it) and insert the appropriate kernel source path (the folder that contains arch, crypto, firmware, drivers etc folders.
now to compile wifi modules, run this code
Code:
ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- KERNEL_DIR=/path/to/kernel make
of course, in place of "/path/to/kernel" type the actual path to kernel on your pc
this will get your wifi module compiled
go to the folder
vendor/atheros/wlan/host/.output/QUALCOMM_ARM_NATIVEMMC_BSP_REV=3240-SDIO/image/
and you'll find a file ar6000.ko
transfer that file to the place where you kept your zImage safely earlier.
10. PHew!! done?? ha ha .. no dude.. still not...more work left
now to pack things up, you'll need a ramdisk.
so lets steal a ramdisk from a already working kernel (for stock kernel take stock ramdisk, for cm7/cm9 take respective ramdisk)
take any kernel and unpack it using instructions given here
the file ending with xyz.cpio.gz is the ramdisk. rename the file into "ramdisk" (without any extension) and put this file into the folder where you kept your zImage and wifi module.
Now transfer all these three files into a folder which is accessible from your Windows partition (oops... yeah... without windows you cannot finish this job)
Rest of the steps that follow are to be done on Windows (i have not tried on WINE)
rename zImage to "image"
now using this tool (courtesy DoomLord) pack your ramdisk and image into a flashable .ftf file
also make a copy of the file ar6000.ko and name it wifi.ko
both these ar6000.ko and wifi.ko files are supposed to be in the folder /system/lib/module of your mobile (please create appropriate flashable zip for the same)
===============================================================================================================
If you found this Guide helpful, please remember to press the thanks button ;P
================================================================================================================
LzVebz said:
Thanks!
I've one question left I think
I'm currently on Windows 7 ultimate, and I have 1 TB left on drive D (which is empty) My question is.. Is there a way to Dual-boot Windows & ubuntu without wubi?
Thank u very much again
Click to expand...
Click to collapse
send me a screenshot of you disk manager (start->computer management -> disk management)
then i'll tell you how you can set it up easily
Since going on a little adventure with this, and successfully changing my boot Splash screen, (The ASUS + Nvidia logo before the standard boot animation) I decided to post a guide on how I accomplished this myself.
Thanks: This would not have been possible without the wonderful work of rayman86 for his blobtools, whirleyes for his splash patcher, and gee one for putting up with my total noob questions while I stumbled through this :3
The usual Disclaimer applies here, I'm not responsible for bricks, and if you're trying this with Sbkv2 (Like I did) and mess up, quite frankly you are FOUBAR SOL OCSA!! Be.. Careful. May the force be with you.
This guide was run on a Windows 7 (x64) machine, I was going to use linux, but I couldn't get Blobtools source to compile into something working (since I'm functionally retarted), the commands are pretty much exactly the same though, if you can get blobtools working.
Required files:
1. The latest ASUS update firmware from their site for your region: (I used US .24 firmware) link
2. Rayman84's (Give him thanks!) Blobtools (don't need boottools for just a splash screen change) [Attached] Original thread: link
3. A hex editor, I used xvi32 (you just need to be able to read and compare blobs) link
4. Three Images that you want to patch the splash screen with, the sizes need to be exactly 300x100 (asus logo) 300x90 (below) and 300x30 (Nvidia logo)
Note: Due to the nature of how the image is stored (In the freaking bootloader I might add -_-) these sizes need to be Correct, the bootsplash patcher should help you with this.
5. whirleye's (Give him thanks!) Boot Splash Patcher windows app. (Complete with shiny GUI) link
6. 3 pinches of ground unicorn horn, eye of newt, and hog's blood (extremely important ! ) Link
7. ???
8. Profit
*Make yourself a mental note of the disorganized location of these files as you scatter them throughout your documents/desktop/downloads folders.*
The Process:
1. Unzip the asus update, inside it is another zip, which you unzip. (Okay ASUS, you likes your zips) Inside there is a blob file, don't be alarmed, it will not attempt to absorb you into it's blobbiness, it stands for a Binary Large OBject file.
2. Put blobunpack into the same directory as the blob. (for easy cmd command)
3. MOD4+R (Windows key+R) to open run box, type 'cmd' This doesn't stand for central machine decimator.
4. Navigate to the directory with your blob, it was getting pretty lonely without you anyway. Ex: cd C:/users/username/downloads/blob
5. type blobunpack blob, your blob will now split itself into a multitude of blobs each with its own suffix. You now have to say Blob sr. and blob jr. when addressing them, it's only proper.
5a. You will (should) get:
blob.header (Oddly, I didn't actually get this, but we don't need it so don't worry about it.)
blob.app (huge file, the actual update system.img) [Don't Need]
blob.ebt (bootloader) [Need this blob]
blob.lnx (boot.img) [Don't Need]
blob.sos (recovery) [Avoid like the plague, unless you like losing cwm :3]
Note: The file extentions are 'false', they're just a way of separating the blob into manageable sections, they're all just blobs topped with a fancy-schmancy file extension.
6. Now that the blob has lost some extra poundage, it's time to patch it, Backup the blob.ebt and open the blob.ebt with whirleye's patcher!
7. Use your keyboard (This be old school) to load the images into the blob.ebt, shortcuts are at bottom and the tool is easy to use.
8. Save as patched_bl.bin, this should enable save as blob. (I had to do this for whatever reason, just don't question the gods)
At this point, you *Should* have a ready to patch bootloader with your new fancy image! If you like having a device that doesn't double as a very fancy paperweight, you'll keep going and check with a Hex editor.
9. Open your blob with the hex editor, the first line should be MSM-Radio-Update, followed by some 0s, then it should say EBT at the beginning. This marks which partitions are contained in the blob and will be flashed. Make sure none of the other (.SOS.LNX..etc) are in the blob, as then it would overwrite you. (shouldn't be there if you unpacked properly, and the filesize should be around 1.4KB)
9a. Search for whirleye's watermark, this shows the patcher worked, says "splash patcher by whirleyes"
9b. 9b is a terrorist and was deported by the TSA, move on to 9c. (bad hex joke)
9c. Open the backed up Asus blob.ebt you unblobbed, and compare the two files a tad, they should be nearly identical in length and code, except for the patched image section. If everything checks out you should be ready to flash your shiny new boot splash!
10. Now take your blob.ebt and De-knight it, stripping it of it's file extension. It is now just a 'blob' again.
11. Connect your tf and put it somewhere on your internal or external SD using adb or mass storage or whichever (I used /Removable/MicroSD/blob9000/blob)
12. --
gee one said:
to flash using the staging partition- you need either terminal or adb access.
the commands are:
su
dd if=/your/blob/here of=/dev/block/mmcblk0p4 # the last chars are zero pee four
reboot
Use adb or file manager or magic to save your blob somewhere on your transformer.
As it reboots, you should see a blue progress bar to indicate that it is flashing. It will reboot again and hopefully you will see your new splash screen.
Click to expand...
Click to collapse
13. ???
14. Profit!
Attached files:
Blobunpack.exe (zipped)
The Blob.ebt (zipped) finished product I made. For the US .24 update ONLY RAHHHHHH!!!!(Portal gun, aperture logo, mizore-kun. LD)
The blob.ebt.asus (zipped) original unblobbed .ebt part From the US .24 update (For all dem 'muricans)
Chuck Morris.png (A picture of a trollface, yes.) [Zipped]
Any questions? Let me know if this works out for you, worked wonderfully for me!
Link to my Q&A thread, may help with a little understanding, also has pic of my patched screen: link
If I helped, hit yo' self some thanks button. :3
Looks like you're fully explained how to do it and where to get the tools (which can often be harder than finding the how to info) but I've got to ask. Isn't that tons of work just to change something that shows for like a minute once a month whenever you reboot your tablet? I guess I don't understand why to do this but am trying to.
Sent from my PG41200 using Xparent Purple Tapatalk 2
Well, it's more of a, BAHAHAHAHAHAH I DID IT IN YO FACE! Sort of thing, and a neat challenge if you want to mod your tab a bit more. I did it more for the challenge of doing it than anything else. I also hated having everything EXCEPT splash completely customized. Just a proof of concept, and like a 30-40 min thing, not terrible. Let me know if you give it a shot
This is the complete open source evolution- ask some questions, do some research, flash something cool, and then write the guide. All you need now is the t-shirt. Congrats! We need more people willing to explore and ask questions.
sent while running with scissors
It's been a while since I made the discoveries.
Back then, I even made an android app to change the splash easily, but I never upload it to public.
Bump this thread if anyone interested.
I think I still have the source code buried deep inside my pc.
That'd be neat, the current method works but may be a tad confusing for some. I'll test out if you'd like
Has anyone done this successfully?
Flawless!
Works perfectly for me on:
TF101-A1 (16GB) B70
Android 4.0.4
Megatron ROM 1.1.6 (ricardopvz)
I don't think those last two matter, since this is a bootloader, but I thought I'd include it just in case.
I cannot express my thanks enough. If I had any skill, I'd create a CWM flashable template for this mod to make the flashing process a little easier.
I could do that, but that would encourage laziness, and noone would learn the Process behind it all. Which is the real whole point of this experiment :]
Second thread in a week. Read on, young dev, for you are about to enter a world of Android goodness soon.
WHAT IS A KERNEL?
A kernel, as explained by viper001 in his thread, is the software layer between the ROM and the hardware. It contains the crucial init process of the boot sequence. So an Android phone with a faulty kernel may mean a very expensive paperweight. But fear not I have compiled several kernels for my phone (released a few of them too) and I have never ever bricked my phone (not even a bootloop, strange right?).
WHY THE NEW THREAD AND WHY YOU SHOULD COMPILE A KERNEL?
viper001's thread is pretty outdated (it was published in 2010, it's nearly 2013 now) and uses the FXP source (which is also pretty old). Therefore if you compile a kernel following that guide, you'll only be able to use it with FXP ROM (which is almost ancient by now). That is why I decided, after considering Rohin's suggestion, to write a new kernel building guide, for members who wish to step into the dev world by compiling a kernel. Keep in mind, neither the XDA-ians nor I am to be held responsible if you do brick your phone (even if you pee on it due to sheer excitement, though I am pretty sure you'll handle it....LIKE A BOSS).
THE ACTUAL GUIDE
Okay so you want to compile your kernel, huh? Well, you're gonna need some packages and toolchains and sources and blah blah. In short these are the requirements:
1. An Ubuntu build (Linux Mint will do too but I haven't tried using it) on a fast computer (preferably a quad core but a dual core 2.4GHz will do too, 2GB of RAM) or a virtual installation (Google installing ubuntu on vbox).
2. Some packages that you can get by typing this in the Terminal:
sudo apt-get install git unrar libncurses5-dev qt3-dev-tools
3. A kernel source
4. A toolchain
5. Flashtool in your Windows installation (you must have one)
KERNEL SOURCES AND TOOLCHAINS
nAa GB (L)
nAa ICS (L)
nAa JB (L)
Alfs GB (use master branch; test has problems) (L)
LINARO (L sources only)
LINUX GNU Compiler for ARM
INSTRUCTIONS
Make a folder where you'll be working for the time being. Name it conveniently. Unpack a source there and a toolchain (use the Linaro one, it makes the kernel slightly faster and each of the sources I mentioned is compatible with it). Rename the toolchain folder, and the source folder too, to something simpler. It's better if all this is done without root, because that may screw your Ubuntu installation beyond recovery. Even so I did it in root. You, however, should do it in any place other than root, and make sure you can easily navigate to the place through Terminal.
Now for the tough Terminal bit. Navigate to the source folder and type in this:
export ARCH=arm
export CROSS_COMPILE=/path/to/toolchain/folder/bin/arm-linux-gnueabihf-
This will tell Terminal to build the kernel for the ARM platform using the Linaro toolchain.
Then type in:
make xxxx_shakira_defconfig
Where xxxx is the part of the name before _shakira. Check the /arch/arm/configs directory for either semc_ (for Alfs kernels) or nAa_ (for nAa kernels). Or you can make your own defconfig if you're up to the challenge.
Then type in:
make menuconfig
This will display a GUI version of your defconfig. Edit anything you want to there or directly in the defconfig.
Then type in:
make -j#
Where # is the number of cores your CPU has + 1.
If all goes well, you should have your kernel image. Grab the Image file form /arch/arm/boot.
You do have Windows installed, right? Good, because you're gonna need it now. Download the bootloader unlocking tool (not Flashtool, the one posted by the_laser).
You have to copy your Image file and a ramdisk, check my other guide, to the sinTools folder of the bootloader unlock tool. A suitable ramdisk, not a GB one for an ICS kernel and vice versa. Then rename the Image file to image and double-click on example_build.cmd. You should get a result.zip. Exatract it and rename result.sin to kernel.sin. Copy it over to a folder and place a loader.sin from a working kernel there too. Open up Flashtool. Go to Advanced > Bundle creation. Navigate to the folder and select both files and move them over to the right-side (by clicking the > button). Give it a proper name and branding and click OK. FLASH! FLASH! You are done with your kernel. First ever, huh? Wish to know more.
If your build failed, type in
make mrproper
or
make clean
Coming soon, TIPS AND TRICKS and more.
P.S.
It is pretty obvious that I'm not a RD, or any D for that matter, this guide may have petty mistakes. Therefore I request any member to let me know if there are any mistakes should he/she find any.
Stay safe and pray that your PC doesn't explode while you're doing this.
If any of the Forum Mods are reading this, you may wonder why I posted this when there already was a guide. viper001's thread is a bit outdated although some users have compiled kernels following it. Therefore to help users who are quite new to this, I wrote this. I sincerely hope I do not get warned for posting a guide twice, just to help people compile newer kernels.
NEITHER THE XDA-IANS NOR I AM TO BE HELD RESPONSIBLE FOR ANY DAMAGE THAT THIS MAY CAUSE TO YOUR PHONE. YOU ARE SOLELY RESPONSIBLE FOR WHATEVER YOU DO TO YOUR PHONE.
But do ask for help if you need it.
EDIT: You can also use the zImage file (you have to rename it to image) as pilu1978 said in his post (check second page and thank him). If you use this, you can attach a larger ramdisk.
COMPILING WiFi MODULES
After you compile a kernel, you need to compile a set of WiFi modules for the kernel. Otherwise your WiFi won't turn on and when you check in Terminal Emulator, you'll get blah blah.ko magic version errors. So after every compile, you also need to compile your WiFi modules.
For nAa based kernels, all you gotta do is issue the ./build_wifi.sh command right after compiling your kernel. It'll result in 3 files in the source's parent folder: tiwlan_drv.ko, tiap_drv.ko and sdio.ko. You have to copy these files to the ramdisk's modules folder, replacing the ones already there.
For nAa .32 kernel, you don't have to do anything. Just grab the following modules:
net/compat-wireless/net/mac80211/mac80211.ko
net/compat-wireless/drivers/net/wireless/wl12xx/wl12xx_sdio.ko
net/compat-wireless/drivers/net/wireless/wl12xx/wl12xx.ko
Thanks to @btisserand and @pilu1978.
For alfs based kernels, I have no idea. You can ask alfsamsung like I did. I tried it using his method and failed. However I tried copying the vendor_ti_wlan and the build_wifi.sh files from nAa's source to alfs' source and it worked, just once. I couldn't test the modules myself but my tester said the kernel didn't even boot o_0. Therefore I find it safer to stick to the nAa kernel source. But even if you do try with alfs and somehow manage to succeed, do post how you managed to compile it.
EDIT: Thanks to Daveee10, you now have another source for the WiFi modules. Download this as a zipball and extract in Ubuntu. Then execute nAa's build_wifi.sh script in Terminal and you should have the modules. Oh and if you get any permission denied error just chmod it. It works for me.
Next post covers TIPS AND TRICKS.
TIPS AND TRICKS
So compiling a kernel, a bland, vanilla kernel is pretty mainstream. You want more tweaks. That's up to you to find out how you're gonna manage that. All I can do is help you with some things that'll make the kernel your very own, your precious.
Changing the name of the kernel...like completely
You want to change the name of the kernel like
xxxxx
[email protected]#1
[TIMESTAMP]
The xxxxx in the first line can be changed in the defconfig or in the menuconfig (easier). Go to General Setup. Then scroll down to the KERNEL_VERSION line (in menuconfig). Then change the name to anything you like (for example, X8-kernel).
The [email protected]#1 can also be changed. Go to /source-folder/scripts and open up the mk_compile.h file. Scroll down to line 66 and change the word within inverted commas to anything you like (for example, X8). Then in the next line, change the word within inverted commas to anything you like as well (for example, XDA).
After you flash your compiled kernel and go to Settings > About phone, you'll see
X8-kernel
[email protected]#1
[TIMESTAMP]
I'm not sure if you can change the TIMESTAMP.
Editing CPU freqs
Editing CPU frequencies via kernel is also pretty easy (thanks fotak-x for the suggestion).
Go to /arch/arm/mach-msm and open up acpuclock.c.
Scroll to line 202 (the line which says "7x27 with GSM capable modem PLL0 and PLL1 swapped" or something) and just below that you'll see the frequency table which also has the GPU frequencies (??)
The value after { 0, is the CPU frequency, the one you want to change.
You can delete any frequency that you don't use (19MHz and so on) but don't delete 600MHz or add any beyond 864MHz. No X8 will ever go beyond that without freezing up.
The values just before the last number are the voltage units (ranging from 1 to 7). You can experiment with that too but it's better not to.
If you do not know what you are doing, please do not attempt this.
Adding/Deleting I/O schedulers
First look at this commit from DooMLorD: https://github.com/DooMLoRD/Xperia-...mmit/0ae625f7561c559d4933284f489733bf5eb66e96
I'm pretty sure you understood what you gotta do. If you still didn't, read on.
What Sir DooMLorD did was change some lines in the Kconfig.iosched of /block directory to add the Simple I/O scheduler. Then he edited the Makefile to include the building of SIO. The most important thing he did was to make a new file and paste the code that is the script that tells SIO what to do, basically it's core ingredient. You have to perform similarly and change the defconfig to include the I/O scheduler.
Deleting is way simpler than that. You just have to write n after the line in the defconfig where the inclusion of the scheduler is mentioned.
50% FPS-uncap in ICS (and JB?) kernels
It's pretty obvious that I'm referring to the nAa-ICS kernel source. Navigate to the arch/arm/mach-msm directory and open up the board-delata.c file.
Go to line 1915 (the one that begins with panel_data->panel_info.lcd.vsync_enable). Change the value to FALSE. This disables HW vSync.
Then go to line 1999 (it also begins with panel_data->panel_info.lcd.vsync_enable). Change this value to FALSE as well.
Compile the kernel as you would normally. Flash to see a slight increase in performance, and a massive improvement in gaming.
Thanks to pilu1978
That's it for now. Will be updated soon.
CREDITS in no particular order
-viper001
-nobodyAtall
-alfsamsung
-djnilse
-Daveee10
-CyanogenMod team
-pilu1978
-RohinZaraki
-fotak-x
-DooMLorD
-paxChristos
-Google and the Android team
is it possible to compile it from stock kernel?
Thanks sgt may try compiling a kernel just for my ROMs
cool
@fotak-x
yes you can download the stock sources and compile it but it's a little complicated. and all kernels are basically improvements over the stock kernel, so in a way you are compiling a not-so-stock stock kernel.
Thread updated. More tips and tricks now.
Some additions
About the compiler (arm gcc). Today everyone prefer linaro. After a lot of testing, I can say: NO real performance differences between the different compilers (tried google/codesourcery/linaro with lot of versions between 4.4.x and 4.7.x series). Sometime the older is better. The linaro gcc contains optimized libgcc for each instruction set, but we are on the bottom of the list, without the armv7 extensions, extended float unit (thumb-2) and vector processing unit (NEON) the linaro gcc can't give real boost for our phone.
About the cpu frequencies: yes, possible to add/remove/modify these values, but without enough knowledge, better if you not do anything. You use an android phone, so you must know, your best friend: google. Use it. And try to understand how to generate the cpu freqs. Learn about the PLLs, their values, dividers, bus frequencies (axi, ahb, etc...) before start to play with frequencies. You can't set directly the gpu freq, in the msm7x27 SoC series the gpu freq depends on the axi clock (can't work in async mode). Modify the VCC levels, bus frequencies the easiest way to make the phone unstable.
About the wifi modules: you can use the wifi drivers from nAa sources if you want to compile modules to alfs kernel. Or you can find the tiwlan1271 driver sources in the cyanogenmod source tree too. If not working, or you can't compile, try another compiler, or other sources. If you successfully build the modules, you NOT must recompile it after a new kernel build. If you change the kernel versions (2.6.29.xx-xyz) you MUST recompile the modules (the wifi modules linked directly to the kernel version).
good addition mate. i never added any freq and that's why i don't know the exact amount it multiplies by at every step. or even if it works that way. and i never succeeded in compiling the WiFi modules for alfs. and yeah there is basically no improvements in terms of performance between Linaro and Codesourcery. Linaro just seems cool and that's why everyone wants to use it. simple as that. that being said, Linaro does indeed work good on ARMv7 devices as you said in your post.
Some additions (again)
Differences between make clean and make mrproper (if you need to clean the sources after a failed build). The make clean command delete the most generated files and builded objects, but keep the .config file (what contains the changes of actual defconfig) and keep enough informations to build external modules. The make mrproper command delete ALL generated files/objects, after this command you need to configure the kernel config again (make blabla_defconfig and make menuconfig for example). If you use alfsamsung sources, never use the mrproper command, because this source not contains defconfigs, only a predefined .config, the make mrproper delete it, and need to extract this file again.
About the Image and zImage: the difference between these files is only one, the Image contains the raw kernel code, the zImage starting with a decompressing code and the compressed image. When build the kernel.sin, you can use the zImage too, just rename to Image. The result is a smaller kernel, you can attach bigger ramdisk. The maximum size of the kernel (the complete kernel.sin) is around 8.300.000 byte. A typical kernel image is around 5,5MB (you can use ramdisks with maximum 2,5MB) the compressed image size is less than 3MB (you can use ramdisks around 5MB size)
As sgt. meow wrote: "Linaro just seems cool and that's why everyone wants to use it." This is the general problem in the development section, every "developer" want to make "cool" things, I think better if they concentrate to make "good" things, instead of making "cool" sh!ts...
Some tips:
If you make a kernel, never post it: based on LATEST xyz source. The latest is relative. Write a correct commit version, if you don't know what is it, need to learn before publish kernels.
To the members who have low bandwidth. Download sources as zipball, it needs less data transfer than a repository sync (when you sync a repo, you download a lot of deltas, additional files too), a typical kernel zipball is around 90MB. This method works with rom sources too (but more complicated, because you need to download and extract manually more than 200 files), for example the minicm7 sources with manual download as zipballs is only 600MB (without the prebuilts what is around additional 700MB).
If you want to be "cool" and use linaro, use the standalone linaro gcc (the arm-none-eabi version) instead of the linaro toolchain (arm-linux-gnueabi version) it will give less compiling errors.
true dat, brother.
and is minicm7 really about 1.3GB in size as zipballs? one more thing i heard (read, probably) that the zImage is the compressed version of the Image with a decompression code. so if we use that, won't booting time be a lil bit slower?
added all your suggestions bro. thanks a lot for helping out. you should apply for RC.
No, the compressed image not give significant slower boot time. All nAa kernels use compressed images, and boot faster than the alfs (the alfs8 use normal image, the alfs9 use compressed).
Yes, the minicm7 source only 614MB if you download as zipballs. For example: the settings app size is 3,5MB if you download as zip, but the git repo is around 90MB (this is an extreme example, with some part of code you can't decrease the download size).
Tips to use this method.
Make the repo init, but not start the sync. Check the default.xml in .repo/manifests, and you can see all needed repo.
You can make download links from this file in this form:
https://github.com/"name value"/zipball/"revision value"
Concrete example:
You see this line:
<project path="bootable/recovery" name="CyanogenMod/android_bootable_recovery" />
The link what you need: https://github.com/CyanogenMod/android_bootable_recovery/zipball/gingerbread
(the most line in default.xml not contains revision, if you not see it use gingerberad for minicm7, or ics for minicm9)
If the download finished, you must extract manually the downloaded file into the "project path". With this example: in your source folder you must make the bootable/recovery folder, and extract the downloaded zip into this folder (warning: the zip contains a folder named in this form - project name+commit number, you must extract the files into the "project path" folder WITHOUT this folder (you need the files INSIDE this folder))
gonna try that soon.
okay so the line has to be edited like this:
<project path="bootable/recovery name="CyanogenMod/android_bootable_recovery/zipball" />
i'm trying it on the MiniCM9 source.
oh yeah android source from googlesource can't be zipballed that way.
sgt. meow said:
gonna try that soon.
okay so the line has to be edited like this:
<project path="bootable/recovery name="CyanogenMod/android_bootable_recovery/zipball" />
i'm trying it on MiniCM9.
Click to expand...
Click to collapse
No.
The correct method for get direct links:
You can see in the default.xml: <project path="external/compcache" name="CyanogenMod/android_external_compcache" revision="master" />
The link what you need:
https://github.com/CyanogenMod/android_external_compcache/zipball/master
The text with puple color: need to write it manually
Text with green color: the repo what you need
Text with blue color: the branch name what you need. Usually you not see the revision in the default.xml, if not exist, use the default branch name (gingerbread or ics, depends on what source needed)
The downloaded file will be this: CyanogenMod-android_external_compcache-cm-7.0.0-0-g5fdea21.zip
Inside the zip package you can see a folder with same name, this folder NOT needed, go inside this folder, and extract the files into the folder what marked with orange colour.
You must do it with ALL project (over 200 files), but you need to download only 600MB, and not need to sync the repo (what is much bigger).
EDIT: You not need anything from google sources if you want CM7 (just the prebuilt binaries, but you can find it somewhere in the minicm nightlies threads, eagleeyetom uploaded it when the aosp servers was unavailable)
EDIT: what about platform/abi/cpp and some others?
sgt. meow said:
EDIT: what about platform/abi/cpp and some others?
Click to expand...
Click to collapse
Please explain it in longer form (I not understand what is the question)
i saw this line in the default.xml
<project path="abi/cpp" name="platform/abi/cpp/zipball" remote="aosp" revision="refs/tags/android-4.0.4_r2.1"/>
this is important. how do i zipball or tarball it?
sgt. meow said:
i saw this line in the default.xml
<project path="abi/cpp" name="platform/abi/cpp/zipball" remote="aosp" revision="refs/tags/android-4.0.4_r2.1"/>
this is important. how do i zipball or tarball it?
Click to expand...
Click to collapse
Okay, understand I checked only the cm7 sources, what not contains codes from aosp servers (only the prebuilt toolchains, but this is available on mediafire servers, eagleeyetom upload it when the prebuilts was unavailable ). So, at this moment no idea how to download code from google servers.
Try this: remove all minicm/cyanogenmod related lines from default.xml, leave only the lines that contains: remote="aosp", and sync the repo with only the aosp code. Or send your default.xml (just copy/paste the contents, and send it in a pm.
sorry for off-topic but @pilu you should be recognized developer
MyMinds_Kernel_Swap
===================
Based on AnyKernel, but pretty much rebuilt in every way so that it will actually work. So, many thanks to Koush for the idea.
The Idea and What It Does...
=======================
Some but not all of this script has been snippets here and there from ArchiKitchen and DSIXDA Kitchen.
This has allowed me to formulate a zip as such without the need to technically build from scratch saving me LOADS OF HOURS.
It currently uses my static compiled mkbootimg, unmkbootimg, and mkbootfs binaries to allow editing, and rebuilding of the boot.img.
Some serious modifications were made to get this to work successfully with MUCH DEBUGGING. If you change something and it breaks another function then that is on you!
# IT IS CURRENTLY STABLE!
1. It will pull your current boot.img using dd.
2. It will search for the Android! header in the boot.img and remove the unnecessary junk before it if needed to.
3. It will split the boot.img in to the kernel and ramdisk.
4. It will unpack the contents inside the ramdisk.
5. It will modify the default.prop file giving you insecure ADB. If you already have it then this will not affect you.
6. It will modify the init.rc file to give support for init.d. If you already have it then this will not affect you.
7. It will write to sysinit and install-recovery.sh for the completion of init.d support. If already done, then this will not affect you.
8. It will make the init.d folder under /system/etc on your device with required permissions.
9. It will place an init.d script to test to see if init.d is fully working. If it works, you will find a file called, HAS_INIT, located in the /dev directory of your device.
10. It will swap out the original kernel with a new prebuilt kernel upon rebuilding the new boot.img
11. It will repack you a new ramdisk using mkbootfs to be applied to your new boot.img upon rebuilding it.
12. It will remove your old modules and push your new modules that came with your new prebuilt kernel.
13. It will write your new boot.img to your boot partition using dd.
14. Hopefully, more to come!
MAKE SURE YOU CHANGE...
=======================
"$BOOT_PARTITION" ACCORDING TO YOUR DEVICE BEFORE USING THIS SCRIPT!!!!!!
How to use it...
==============
1. Place your prebuilt kernel in the prebuilt folder and insure it is named, zImage.
2. Place kernel modules in the modules folder.
3. Zip, and flash in TWRP recovery.
If you have any suggestions then let me know. My ears are open to them.
https://github.com/ModdingMyMind/MyMinds_Kernel_Swap
Sent from my C525c using Tapatalk