[UTIL] unmkbootimg - Android Software Development

I've put together a tool undoing what mkbootimg does. There are other tools splitting a boot image into the
kernel and root file system, but I didn't find any extracting the command line and base addresses, so I wrote this one.
It handles plain boot images as well as boot images embedded in larger filer, e.g. update-images.
Code:
$ unmkbootimg boot.img
Kernel size 2419636
Kernel address 0x20008000
Ramdisk size 152656
Ramdisk address 0x21000000
Secondary size 0
Secondary address 0x20f00000
Kernel tags address 0x20000100
Flash page size 2048
Board name is ""
Command line "no_console_suspend=1"
This image is built using standard mkbootimg
Extracting kernel to file zImage ...
Extracting root filesystem to file initramfs.cpio.gz ...
All done.
---------------
To recompile this image, use:
mkbootimg --kernel zImage --ramdisk initramfs.cpio.gz --base 0x20000000 --cmdline 'no_console_suspend=1' -o new_boot.img
---------------
$ ls -l
totalt 5044
-rw-r--r-- 1 kuisma kuisma 2576384 9 sep 09.44 boot.img
-rw-r--r-- 1 kuisma kuisma 152656 9 sep 09.44 initramfs.cpio.gz
-rw-r--r-- 1 kuisma kuisma 2419636 9 sep 09.44 zImage
Version 1.2 - Support for embedded boot images
Version 1.1 - Support for non-standard mkbootimg images.
Version 1.0 - Initial release.
Including a gziped binary for GNU/Linux in this post (32 bit, linked static). Download, unzip, make sure it is executable.
If running on a 64bit machine, make sure you've got the ia32-libs installed to be able to run 32bit binaries.

Great Tool........ i Always use it..........Thanks For Share

I've updated unmkbootimg. Now it detects and warns if the boot.img is built using a non-standard mkbootimg, and tells you how to patch it.
$ unmkbootimg samsung-boot.img
Kernel size 4905092
Kernel address 0x40408000
Ramdisk size 893395
Ramdisk address 0x41800000
Secondary size 0
Secondary address 0x41300000
Kernel tags address 0x40400100
Flash page size 2048
Board name is ""
Command line "androidboot.hardware=qcom msm_watchdog.appsbark=0 msm_watchdog.enable=1 loglevel=4"
*** WARNING ****
This image is built using NON-standard mkbootimg!
OFF_RAMDISK_ADDR is 0x01400000
Please modify mkbootimg.c using the above values to build your image.
****************
Extracting kernel to file zImage ...
Extracting root filesystem to file initramfs.cpio.gz ...
All done.
---------------
To recompile this image, use:
mkbootimg --kernel zImage --ramdisk initramfs.cpio.gz --base 0x40400000 --cmdline 'androidboot.hardware=qcom msm_watchdog.appsbark=0 msm_watchdog.enable=1 loglevel=4' -o new_boot.img
---------------
Click to expand...
Click to collapse

Thank you for your tool my friend
Though I have one question regarding this:
--cmdline 'no_console_suspend=1'
Click to expand...
Click to collapse
When I attempt to compile kernel from source, Sony said in the read me file that memory layout and other stuff are passed to kernel via cmdline. I do that just like it's written in the cmdline I quoted?! because I want to use the latest kernel source with an existing zRam but i'm unable to make the newly compiled kernel to boot because I am unable to pass arguments via cmdline on boot :crying:

DeepUnknown said:
Thank you for your tool my friend
Though I have one question regarding this:
When I attempt to compile kernel from source, Sony said in the read me file that memory layout and other stuff are passed to kernel via cmdline. I do that just like it's written in the cmdline I quoted?! because I want to use the latest kernel source with an existing zRam but i'm unable to make the newly compiled kernel to boot because I am unable to pass arguments via cmdline on boot :crying:
Click to expand...
Click to collapse
As far as I know, Sony passes all important parameters via kernel ATAGs, not command line.

kuisma said:
As far as I know, Sony passes all important parameters via kernel ATAGs, not command line.
Click to expand...
Click to collapse
I'm sorry I wasn't clear in the previous comment, here is what Sony mentioned:
In the official SW the following command line arguments are given
to the kernel:
cachepolicy=writealloc
noinitrd
init=init
board_id=1
logo.nologo
root=/dev/ram0
rw
rootwait
console=ttyAMA2,115200n8
androidboot.console=ttyAMA2
androidboot.hardware=st-ericsson
<memory layout>
mpcore_wdt.mpcore_margin=359
Click to expand...
Click to collapse
I'm sorry I went out of subject but I was using tools like yours to get zRam from other boot.img file.

Very nice tool, thanks for sharing.

unmkbootimg as of version 1.2 now supports embedded boot images, e.g. a boot image embedded deep in an update.img file.
$ unmkbootimg update.img
unmkbootimg version 1.2 - Mikael Q Kuisma <[email protected]>
File update.img not a plain boot image, seeking for embedded image ... found!
Kernel size 8073252
Kernel address 0x60408000
Ramdisk size 6380372
Ramdisk address 0x62000000
Secondary size 0
Secondary address 0x60f00000
Kernel tags address 0x60088000
Flash page size 16384
Board name is ""
Command line ""
*** WARNING ****
This image is built using NON-standard mkbootimg!
OFF_KERNEL_ADDR is 0x00380100
OFF_RAMDISK_ADDR is 0x01F78100
OFF_SECOND_ADDR is 0x00E78100
Please modify mkbootimg.c using the above values to build your image.
****************
Extracting kernel to file zImage ...
Extracting root filesystem to file initramfs.cpio.gz ...
All done.
---------------
To recompile this image, use:
mkbootimg --kernel zImage --ramdisk initramfs.cpio.gz --base 0x60087f00 --pagesize 16384 -o new_boot.img
---------------
$ ls
initramfs.cpio.gz update.img zImage
$
Click to expand...
Click to collapse

kuisma said:
unmkbootimg as of version 1.2 now supports embedded boot images, e.g. a boot image embedded deep in an update.img file.
Click to expand...
Click to collapse
Thanks for the update, very cool feature.

Can not extract zImage?
Could you check why I Can not extract zImage from this Kernel:
http://forum.xda-developers.com/showpost.php?p=37909023&postcount=56

mafamafa said:
Could you check why I Can not extract zImage from this Kernel:
http://forum.xda-developers.com/showpost.php?p=37909023&postcount=56
Click to expand...
Click to collapse
It's because it's not an Android boot image, but a Rockchip specific kernel image file.

Hi, could you please post the source here or upload in github or similar and provide the link. That will be much better.
Sent from my Amazon Kindle Fire HD using xda app-developers app

jeevas.v said:
Hi, could you please post the source here or upload in github or similar and provide the link. That will be much better.
Click to expand...
Click to collapse
Why? It's a trivial hack, and if you're a programmer, you'll put one together in minutes anyway.
So, no.

That is very bad and unethical. It is not a question of I or somebody can do it. Even it violates many things by saying no. What a pathetic situation.
Sent from my Amazon Kindle Fire HD using xda app-developers app

jeevas.v said:
That is very bad and unethical. It is not a question of I or somebody can do it. Even it violates many things by saying no. What a pathetic situation.
Click to expand...
Click to collapse
Say what? I'm providing the community a useful software for free - and you blame me for being unethical? :laugh:

I'm saying that you are using Foss as you like and hesitating to publish even a trivial change that you made. How can the community trust your binaries unless they don't have the source. What kind of mindset is that? Have you ever read GPL?
What do you think you are doing? Social service the Microsoft way? What a joke!
Sent from my Amazon Kindle Fire HD using xda app-developers app

jeevas.v said:
I'm saying that you are using Foss as you like and hesitating to publish even a trivial change that you made. How can the community trust your binaries unless they don't have the source. What kind of mindset is that? Have you ever read GPL?
What do you think you are doing? Social service the Microsoft way? What a joke!
Click to expand...
Click to collapse
GPL? My code is written from scratch, and is not a subject of GPL whatsoever.
You, my friend, are making a fool of your self. Please, don't let me hinder you.

I am trying to spread the awareness against the closed source behaviour and I hope I achieved that in whatever miniscule way.
I don't care about your binary or code but thought of asking you to know if you are intentionally not giving the source by giving just the 32bit binaries. Anyway so now everyone knows...
Sent from my Amazon Kindle Fire HD using xda app-developers app

how to build Rockchip specific kernel image file?
kuisma said:
It's because it's not an Android boot image, but a Rockchip specific kernel image file.
Click to expand...
Click to collapse
Can you tell how to build Rockchip specific kernel image file - or where to loog for that information?

mafamafa said:
Can you tell how to build Rockchip specific kernel image file - or where to look for that information?
Click to expand...
Click to collapse
I have no idea whatsoever how Rocketchip manages its boot images.

Related

[REF] Unpacking and repacking stock rom .img files

As most of you are aware, the stock rom tarball is comprised of several .img files which don't seem to be of any file system format and it is difficult at first to see what is inside these files without flashing via Odin.
Well, thanks to fguy, this thread http://forum.xda-developers.com/showthread.php?t=1054836 provided me the necessary inspiration to investigate just exactly what are these img made of.
Hopefully, this will allow easy removal of all the Samsung junk, deodexing, rooting etc etc without going through adb.
As it turns out, they are simply sparse ext4 images, and the AOSP source tree already contains the necessary utilities to both unpack and repack these img files via "ext4_utils" in system/extras (https://android.googlesource.com/platform/system/extras/)
For your convenience, I have provided a repackage of the source code for ext4_utils with a simple Makefile, for keen developers to make the necessary tools for unpacking and repacking the stock img files. Making these tools requires a linux development environment, which is beyond the scope of this topic.
To make the tools, simple extract the attached source code and type "make".
To unpack the .img file:
Code:
./simg2img factoryfs.img output.img
To view the contents of .img file:
Code:
mkdir tempdir; mount -o loop output.img tempdir
To repack .img file:
Code:
./mkuserimg.sh -s /some/directory/with/files ./factoryfs_custom.img ext4 ./temp 512M
As I do not have Odin at the moment, I am not able to test the repacked files can be reflashed successfully. I will test this shortly.
UPDATE
I have just tested repacking the stock factoryfs.img. It so happens that the original ext4_utils does not properly preserve permissions on the new ext4 image. I have made a slight modification to the source and reuploaded the zip.
You can now successfully unpack, remove and change the stock apps, root and modify the stock image using instructions above!!
I hope this will help people create their own custom roms.
UPDATE 27th MAY FOR GALAXY S4 TESTING (i9500 i9505)
A few people have messaged me asking why these tools do not work for the new Galaxy S4. Unfortunately I do not have a Galaxy S4 so I can not test any of these utilities. HOWEVER, it seems there has been quite a bit of updates by Google in the ext4_utils package. I have updated the sources according to 4.2.2 which is the latest version of the tools. I must stress that I DO NOT HAVE A GALAXY S4 TO TEST so don't be expecting miracles. In any case I have uploaded the new code now. As it was before, I have provided a MAKEFILE and you simply type "make" in order to build the tools. They are contained in ext4_utils_new.zip.
Thanks for your support guys. And I do apologize for replying late to my inbox...
Update 9th November 2014
Thanks to qwerty_7564 for providing the fixes for cygwin compilation.
Ext4 utils new still missing link arguments to compile. Investigating. I will update the sources to that of the 4.3 branch later.
Update 3rd December 2014
I have updated the tools to 4.3 branch. Note that no attempts has been made to make this compatible with cygwin as I have no cygwin to test.
As I have mentioned earlier, I do not have a newer samsung device to test any of these files, use at your own discretion. The new files are in ext4_utils_r4.3.tar.gz and is based on the jb release 2.0.0 branch.
you mean, with these tools anyone with fair knowledge of linux can create custom ROMs ? what all we can do with this trick to an image/stock ROM ? pls explain
keen to know what change it could bring to the present scenario of tweaks...
Yes and you can even provide root privileges to stock rom without having to pass through insecure firmware
As you said anyone with a little knowledge of Linux could do that
It's only unpacking and repackaging new rom
Sent from my GT-I9100 using Tapatalk
very good jazzor
what is so special samsung img file?
There is nothing special about the img file. It is just that I have not seen anyone write a guide to modify these img files yet. They are simple compressed ext4 images as explained in the first post. AOSP already recognises this format and have made available utilities for you to modify and create your own img files which can be flashed via Odin
hope someone can make this tool....i know little linux knowledge....
Hi, I have given make a mistake, it can be?
Thanks.
[email protected]:~/discoduro/BASURILLA/GSII/Varios/ext4_utils$ make
gcc -I. -DANDROID -c make_ext4fs.c
gcc -I. -DANDROID -c make_ext4fs_main.c
gcc -I. -DANDROID -c ext4_utils.c
gcc -I. -DANDROID -c allocate.c
gcc -I. -DANDROID -c backed_block.c
gcc -I. -DANDROID -c output_file.c
output_file.c:25:18: fatal error: zlib.h: No existe el fichero o el directorio
compilation terminated.
make: *** [output_file.o] Error 1
Click to expand...
Click to collapse
BoRoU said:
Hi, I have given make a mistake, it can be?
Thanks.
Click to expand...
Click to collapse
hi BoRoU, try this:
$ apt-get install zlib1g-dev
Perfect. Gracies.
i get a warning when i try the option make
[email protected]:/home/galaxy/ext4_utils# make
gcc -I. -DANDROID -c make_ext4fs.c
gcc -I. -DANDROID -c make_ext4fs_main.c
gcc -I. -DANDROID -c ext4_utils.c
gcc -I. -DANDROID -c allocate.c
gcc -I. -DANDROID -c backed_block.c
gcc -I. -DANDROID -c output_file.c
gcc -I. -DANDROID -c contents.c
contents.c: In function ‘make_directory’:
contents.c:118:3: warning: format ‘%llu’ expects type ‘long long unsigned int’, but argument 4 has type ‘u32’
how can i fix this?
GalaxyS! said:
i get a warning when i try the option make
[email protected]:/home/galaxy/ext4_utils# make
gcc -I. -DANDROID -c make_ext4fs.c
gcc -I. -DANDROID -c make_ext4fs_main.c
gcc -I. -DANDROID -c ext4_utils.c
gcc -I. -DANDROID -c allocate.c
gcc -I. -DANDROID -c backed_block.c
gcc -I. -DANDROID -c output_file.c
gcc -I. -DANDROID -c contents.c
contents.c: In function ‘make_directory’:
contents.c:118:3: warning: format ‘%llu’ expects type ‘long long unsigned int’, but argument 4 has type ‘u32’
how can i fix this?
Click to expand...
Click to collapse
Code:
error("failed to allocate %llu extents", (unsigned long long)len);
sgstwo said:
Code:
error("failed to allocate %llu extents", (unsigned long long)len);
Click to expand...
Click to collapse
They are just warnings. There's no need to fix anything. It will still compile.
jazzor said:
They are just warnings. There's no need to fix anything. It will still compile.
Click to expand...
Click to collapse
Yes, it will still compile. Since you ignore warnings, I take it you're not a programmer.
And if you look closely, it's also a bug. Nothing serious, but still a bug.
sgstwo said:
Yes, it will still compile. Since you ignore warnings, I take it you're not a programmer.
And if you look closely, it's also a bug. Nothing serious, but still a bug.
Click to expand...
Click to collapse
No, there really is nothing to fix.
Code:
data = inode_allocate_data_extents(inode, len, len);
if (data == NULL) {
error("failed to allocate %llu extents", len);
return EXT4_ALLOCATE_FAILED;
}
Worst case scenario: the error message displays a weird number.
EDIT: Not saying you don't get this (obviously you do - haha), but fixing this for someone asking what the warning means is a bit overkill.
RyanZA said:
Worst case scenario: the error message displays a weird number.
Click to expand...
Click to collapse
And that's the bug. Yes, not a very serious bug, but a bug nonetheless. The compiler can help you find bugs. Ignore compiler warnings at your own risk.
Any Chance to something like this for Windows?
You can make the tools for windows, but it will still be useless since you also need an ext4 driver and a loop mounter. And then theres the issue of maintaining file permissions on said ext4 driver. Unfortunately, windows is not a very friendly environment for such tasks.
Can someone make a simple guide? I have never use linux before
Thanks
Mackzen said:
Can someone make a simple guide? I have never use linux before
Thanks
Click to expand...
Click to collapse
This is the development section. It's not an easy process. Take a read, and google the bits you don't know. The info in the first post is all you need Get a virtualbox set up with ubuntu in it or something
pulser_g2 said:
This is the development section. It's not an easy process. Take a read, and google the bits you don't know. The info in the first post is all you need Get a virtualbox set up with ubuntu in it or something
Click to expand...
Click to collapse
Thanks for the answer
I have write this and place factoryfs.img inside ext4_utils. What I'm doing wrong?
PHP:
[email protected]:~$ cd ~/Desktop/ext4_utils/
[email protected]:~/Desktop/ext4_utils$ ./simg2img factoryfs.img output.img
bash: ./simg2img: No such file or directory

[Call for Help] Kernel Parameters - ro.secure

Ccurrently trying to get the SkyGO app working on the HD2.
One of the devs has suggested that for the app to work properly we need a Kernel with "ro.secure=1" set in it.
Currently I am bouncing between Typhoon 3.7.6 (which uses tytung's r14 kernel) and NexusHD2-ICS-4.0.3 (tytungs ICSr1 Kernel I believe)
Can anyone tell me how to find out if the kernel has this parameter set. If not how easy would it be for me to add it and recompile the kernel (pointers to kernel de/recompilation threads appreciated!
I'm not to worried about doing it myself if I have to.
TIA
mods - if this is in the wrong forum I apologise in advance, could you move it for me if it is
bobjbain said:
Ccurrently trying to get the SkyGO app working on the HD2.
One of the devs has suggested that for the app to work properly we need a Kernel with "ro.secure=1" set in it.
Currently I am bouncing between Typhoon 3.7.6 (which uses tytung's r14 kernel) and NexusHD2-ICS-4.0.3 (tytungs ICSr1 Kernel I believe)
Can anyone tell me how to find out if the kernel has this parameter set. If not how easy would it be for me to add it and recompile the kernel (pointers to kernel de/recompilation threads appreciated!
I'm not to worried about doing it myself if I have to.
TIA
mods - if this is in the wrong forum I apologise in advance, could you move it for me if it is
Click to expand...
Click to collapse
This is a question. [Q&A]
yz.hd said:
This is a question. [Q&A]
Click to expand...
Click to collapse
Thanks for the useful and insightful response
FYI - I realised that it might be after I submitted it! Which is why I caveated the post at the end.
this parameter is in the initrd.gz in the kernel in the boot folder of the ROM.
You should extract it and inside there is a file called default.prop
extract
mkdir initdir
cd initdir
zcat ../initrd.gz | cpio -i -d
compress
cd initdir
find . | cpio -o -H newc | gzip -9 > ../initrd.gz
Each line in the file default.prop is an attribute assignment. There we need to
Note the two properties: ro.secure, and ro.debuggable. . If ro.secure = 0 is allowed us to run the adb root command.
Usually we put the core ROOT refers to the ro.secure = 0. ROOT permission to refer to the general said on the phone
A license management program (Superuser.apk) procedures for the root user can grant permission.
bobjbain said:
Ccurrently trying to get the SkyGO app working on the HD2.
One of the devs has suggested that for the app to work properly we need a Kernel with "ro.secure=1" set in it.
Currently I am bouncing between Typhoon 3.7.6 (which uses tytung's r14 kernel) and NexusHD2-ICS-4.0.3 (tytungs ICSr1 Kernel I believe)
Can anyone tell me how to find out if the kernel has this parameter set. If not how easy would it be for me to add it and recompile the kernel (pointers to kernel de/recompilation threads appreciated!
I'm not to worried about doing it myself if I have to.
TIA
mods - if this is in the wrong forum I apologise in advance, could you move it for me if it is
Click to expand...
Click to collapse
look here this great kernel should have ro.secure set to 1
Bologna said:
look here this great kernel should have ro.secure set to 1
Click to expand...
Click to collapse
it doesn't, it's based on Tytung's Kernel, Tytung's doesn't so I'm not suprised that dorimnax's "greatest ever" (sic) doesn't teither
big thanks to magnus48, have decompressed the kernel, changed ro.secure to 1, recompressed, copied to /boot
Phone booted (which suprised me) and my SkyGo App now works.
Yay
magnus48 said:
The easy way is use root explorer and edit /default.prop on your device but is not free.
ro. means read only you can't change it's value after rom is loaded
Click to expand...
Click to collapse
So, I can either change the value in my kernel OR I can edit default.prop and reboot??
Won't the values in default.prop get overwritten on boot??
bobjbain said:
it doesn't, it's based on Tytung's Kernel, Tytung's doesn't so I'm not suprised that dorimnax's "greatest ever" (sic) doesn't teither
Click to expand...
Click to collapse
First question : Why of this sarcastic reply?
Second question : Can you please share your skygo working app, telling us what's the kernel you're using to have it working?
Thanks in advance
bobjbain said:
So, I can either change the value in my kernel OR I can edit default.prop and reboot??
Won't the values in default.prop get overwritten on boot??
Click to expand...
Click to collapse
forget this way. It did not work when rebooting the kernel overwrites the deafult.prop file.
The change should be done inside initrd.gz
magnus48 said:
forget this way. It did not work when rebooting the kernel overwrites the deafult.prop file.
The shange should be done inside initrd.gz
Click to expand...
Click to collapse
You should be able to pull it, make changes and push it back to phone via adb. Useful if you don't want to reflash
Sent from my HD2 using XDA
jwchips said:
You should be able to pull it, make changes and push it back to phone via adb. Useful if you don't want to reflash
Sent from my HD2 using XDA
Click to expand...
Click to collapse
default.prop is in the initrd.gz, this is extracted when the phone boots, so any changes you make to default.prop WILL be overwritten when the phone boots.
You have to make the changes inside the initrd.gz file.
Bologna said:
First question : Why of this sarcastic reply?
Click to expand...
Click to collapse
I don't quite hold dorimanx in quite the high esteem that others do, his work is good but it can be rushed as shown by his 5.x series of Kernels.
Bologna said:
Second question : Can you please share your skygo working app, telling us what's the kernel you're using to have it working?
Thanks in advance
Click to expand...
Click to collapse
Here although this is an app for UK Sky only and won't work for non-UK subscribers.
bobjbain said:
default.prop is in the initrd.gz, this is extracted when the phone boots, so any changes you make to default.prop WILL be overwritten when the phone boots.
You have to make the changes inside the initrd.gz file.
Click to expand...
Click to collapse
Any chance you could post the modified kernel? I am running R14 on GB3.2a so it would drop right in
CR5N said:
Any chance you could post the modified kernel? I am running R14 on GB3.2a so it would drop right in
Click to expand...
Click to collapse
yertiz.
Take a backup of your current initrd.gz first though to be on the safe side.
bobjbain said:
yertiz.
Take a backup of your current initrd.gz first though to be on the safe side.
Click to expand...
Click to collapse
Thankyou. This works on Tytung GB3.2a. F1 channel now working on this old HD2
What about SD builds?
magnus48 said:
forget this way. It did not work when rebooting the kernel overwrites the deafult.prop file.
The change should be done inside initrd.gz
Click to expand...
Click to collapse
I can access and edit default.prop on my SD build after the phone has booted. This seems to give me access to Sky News at least. But I still can't get premium channels. Do you think I still need to edit initrd.gz as well or is that now redundant?
johnkst said:
I can access and edit default.prop on my SD build after the phone has booted. This seems to give me access to Sky News at least. But I still can't get premium channels. Do you think I still need to edit initrd.gz as well or is that now redundant?
Click to expand...
Click to collapse
No, you will need to edit your initrd.gz
Before I did I could access Sky News only, afterwards the Sky world was my Oyster!!
bobjbain said:
No, you will need to edit your initrd.gz
Before I did I could access Sky News only, afterwards the Sky world was my Oyster!!
Click to expand...
Click to collapse
Thanks Bob. Is there anything else I should edit while I'm at it?
Currently after booting, my default.prop contains the following attributes:
ro.secure=0 (need to change this to 1)
ro.allow.mock.location=1
ro.debuggable=1
persist.service.adb.enable=1
I'm particularly suspicious of the last one!
Also... what should I use to edit default.prop within initrd.gz? I tried unzipping it with 7zip, editing the initrd file with a hex editor and re-zipping but it created a significantly smaller file...
johnkst said:
Thanks Bob. Is there anything else I should edit while I'm at it?
Currently after booting, my default.prop contains the following attributes:
ro.secure=0 (need to change this to 1)
ro.allow.mock.location=1
ro.debuggable=1
persist.service.adb.enable=1
I'm particularly suspicious of the last one!
Also... what should I use to edit default.prop within initrd.gz? I tried unzipping it with 7zip, editing the initrd file with a hex editor and re-zipping but it created a significantly smaller file...
Click to expand...
Click to collapse
I only ever changed ro.secure, don't have the phone any more so can't check the other values.
To edit the default.prop you need to uncompress the initrd.gz then recompress it using the following linux commands
Code:
extract
mkdir initdir
cd initdir
zcat ../initrd.gz | cpio -i -d
compress
cd initdir
find . | cpio -o -H newc | gzip -9 > ../initrd.gz
As I run windows I downloaded and installed cygwin and used that to uncompress and recompress the kernel.
I edited the default.prop in windows but you can use vi within cygwin if you want.
If you're uncomfortable doing this then attach your kernel to a post and I can do it for you.

[dev] fastboot kernel + patches

As we are able to fastboot, it make sense to have choice
As it is done now. Normal booting using 2ndinit
PC booting, not using 2ndinit (as the proper files can be inside the boot.img)
The drawback of 2. are obvious. if battery die, etc... but then 1. can be used. so i think 2. will have spread usage.
The pros of 2. are obvious too (no 2nd init, kernel can be modifed e.g. swap etc...) and not so obvious .... But it can be tested / used without compromising the phone usage (e.g. a plain reboot will go to 1.).
Having that in mind, fjfalcon your boot.img are working. (mine doesn't, mioze7ae`s too, there is some old post in some thread about that, but let's stick to this one).
So could you be so kind to share how to build usable (e.g. working) boot.img ?
Then using mio`s knowledge of preparing fastboot openrecovery it will be easy to implement inits, which don't rely on 2ndinit.
And then the real work can begin . Patching the kernel
I have found good starting point of patches:
http://omappedia.org/wiki/Patches_being_done_on_2.6.29_Android_kernel_not_yet_submitted_upstream
had checked some of them (there are not in our moto-compiled kernel), and most of them seems promising...
Of-course this will be just the beginning.
We can try to "patch" discovered goodies (via modules) to the moto-kernel
we can try to use newer version of the kernel (using 2./
etc...
i used motoroi devtree from opensource and kernel.tar.gz from 2.1.
Also i just patched some files... and that should be all.
I think when i get free time i will post our kernel to git.
But, idea about move 2ndinit away is back...
Much better idea will be usyng 2ndinit both times, with if/else statements.
Also, i'am almost done to building uart for kernel testing. I hope it will work.
I pushed mine kernel to https://github.com/CyanogenModXT720/android_kernel with xt720 branch. When it will be finished it will appear.
I need to run, good luck.
I also using command to build: make -j8 -f kernel/kernel.mk BLD_CONF=mine3
10x,
when i build modules, i had issue... they just did not load to the kernel... it turns out that my toolchain was not the right one... using another fixed the modules loading....
about 2ndinit we can brainstorm it later (i have mind floating around about the location of init_prep_keypad.sh)
i am curious about uart, where should we hook the wires :?)
i am curious more because of that commit comment
commit 9638a7f382b7ac1629cfa431bd32790362e3af70
Author: Muhammed Siju <[email protected]>
Date: Thu Jun 17 11:02:09 2010 +0530
IKSTR-401.Disable TV out accessory detection.
TV out code is currently enabled in kernel.So some 3.5mm accessory is getting detected as TV cable.However the TV out service APK was removed from the build.
This causes issues like accessory removal not getting detected and TTY cable failures.This is workaround to treat high impedence cables as headset without mic instead
Click to expand...
Click to collapse
i am not sure how to interpret the bolded one (and i am afraid to hope )
http://xt720.ru/foto mine uart.
Sent from my Milestone XT720 using xda premium
stock recovery adb ?
i just take a look at
cg35.img (e.g. boot image, when boot normaly) and
cg47.img (e.g. boot image, when booted in stock recovery)
equals: kernel
differs: kernel cmdline, and the ramdisk.
in the normal boot.img there is no cmdline, in the recovery one there is
Code:
console=ttyS2,115200n8 rw [email protected] init=/init ip=off motobldlabel=none mtdparts=omap2-nand.0:128k(mbmloader),640k(mbm),640k(mbmbackup),384k(bploader),384k(cdt),1536k(pds),384k(lbl),384k(lbl_backup),384k(cid),1536k(sp),384k(devtree),640k(logo),384k(misc),3584k(boot),3840k(bpsw),4608k(recovery),8960k(cdrom),384k(unused0),204416k(system),384k(unused1),106m(cache),177280k(userdata),1536k(cust),384k(unused2),2m(kpanic),512k(rsv)
kernel cmdline is curious to me, and will need more investigate, mostly because it is present in the normal boot too. (have to compare to the recovery one). I suppose, that the bootloader passes it to the normal boot ...
about initial ramdisk there is something interesting in it
mainly the adbd
service is defined in init.rc
Code:
service adbd /sbin/adbd recovery
on property:persist.service.adb.enable=1
start adbd
on property:persist.service.adb.enable=0
stop adbd
but disabled in default.prop
Code:
persist.service.adb.enable=0
as we are able to fastboot, it will be very interesting to see what can be done within the recovery shell (just have to modify default.prop using unpackbootimg and mkbootimg )
Personally i plan to do it near future (e.g. have time, did not test long term stability etc....)
recovery.img afaik also signed.
peshovec said:
i just take a look at
cg35.img (e.g. boot image, when boot normaly) and
cg47.img (e.g. boot image, when booted in stock recovery)
equals: kernel
differs: kernel cmdline, and the ramdisk.
in the normal boot.img there is no cmdline, in the recovery one there is
Code:
console=ttyS2,115200n8 rw [email protected] init=/init ip=off motobldlabel=none mtdparts=omap2-nand.0:128k(mbmloader),640k(mbm),640k(mbmbackup),384k(bploader),384k(cdt),1536k(pds),384k(lbl),384k(lbl_backup),384k(cid),1536k(sp),384k(devtree),640k(logo),384k(misc),3584k(boot),3840k(bpsw),4608k(recovery),8960k(cdrom),384k(unused0),204416k(system),384k(unused1),106m(cache),177280k(userdata),1536k(cust),384k(unused2),2m(kpanic),512k(rsv)
kernel cmdline is curious to me, and will need more investigate, mostly because it is present in the normal boot too. (have to compare to the recovery one). I suppose, that the bootloader passes it to the normal boot ...
Click to expand...
Click to collapse
Normal boot ignores cmdline and uses atags struct from cdt.bin table (CG31) instead. Recovery boot ignores atags struct and uses cmdline from recovery.img. This is why:
xt720mod.sbf uses normal Milestone XT720 boot.img (UK) but has Motoroi partition structure and recovery--the cmdline inside boot.img is ignored--partition locations come from CDT. If the normal boot used cmdline, xt720mod.sbf could never work using the Milestone XT720 kernel--we'd have to use the Motoroi kernel.
Normal boot has boot.img read-only and missing bpsw etc, but booting into stock recovery has all of the missing ones and they are read/write (because recovery.img uses the cmdline instead of atags)
Tangentially, there's also the devtree (CG61). For some reason the vulnerable Motoroi recovery.img used in xt720mod.sbf doesn't work with Milestone XT720 devtree {=stuck at (M)} *but* Milestone XT720 boot.img does work with Motoroi devtree ... sensorfix.ko tries to correct for some of the Milestone/Motoroi devtree differences (most of the devtree data is actually identical--just some subtle differences), but I haven't gotten to all of them yet (sensorfix.ko at the moment just corrects the accelerator axis mapping--I suspect there's something weird going on with the light sensor, too but I haven't figured that out yet).
fjfalcon said:
recovery.img afaik also signed.
Click to expand...
Click to collapse
I think he's talking about making a fastboot recovery. That's also what I did here: http://forum.xda-developers.com/archive/index.php/t-1477752.html and http://forum.xda-developers.com/showthread.php?p=23965193#post23965193. I thought about putting in a different recovery at first--but the more I thought about it, I couldn't find any reason to justify using a recovery different from openrecovery--just about anything you'd want to do in a custom recovery requires a sdcard to be present and openrecovery is already field-tested on XT720. I can't remember if fastbooted recovery uses the atags or cmdline... I don't think I ever figured out if the difference is in the bootloader or in the kernels.
Edit: when I created the fastboot-openrecovery.img I used the kernel from normal boot.img and used a custom ramdisk that was derived from recovery.img. And I didn't add any command line:
Code:
rm ramdisk.cpio.gz
cd ramdisk/
find . | cpio -o -H newc | gzip > ../ramdisk.cpio.gz
cd ..
rm openrecovery-fastboot.img
mkbootimg \
--kernel stock-boot.img-zImage \
--ramdisk ramdisk.cpio.gz \
--cmdline '' \
--base 10000000 \
--pagesize 00000800 \
-o openrecovery-fastboot.img
I can't remember if I tried using the recovery.img kernel or if I just decided not to risk that the recovery.img kernel wasn't flexible enough--I wanted the same fastboot recovery to work on both stock.sbf's and xt720mod.sbf... i.e. I explicitly wanted to use the atags data in cdt.bin that will always match the installed sbf rather than a static command line... and the mtdhack.ko I've made for XT720 is carefully crafted to work on both Milestone XT720 and Motoroi sbfs by relying on atags... so... I doubt I ever pursued using the recovery kernel.
Normal boot ignores cmdline and uses atags struct from cdt.bin table (CG31) instead. Recovery boot ignores atags struct and uses cmdline from recovery.img.
Click to expand...
Click to collapse
10x
will have to play using simultaneously fastboot and pressing the buttons, which screamed "stock recovery" just to check if we can benefit from cmdline somehow..
however i tried to automate the boot.img repack.
https://github.com/CyanogenModXT720/fastboot-repack
the default generated image (boot-custom.img) should work as test proofing
(will use the init*rc from my testing build, and will avoid 2ndint), the kernel is still stock (yet).
When i will find enough time to test, will start playing with different kernel (mainly the above mentioned patches )
p.s. yes i know fastbooting is annoying, but if there are charger near where, it will be perfectly usable for a long time...
One thing I've wanted to try is creating a basically stock kernel+compcache/ramz. Nadlabak says it's very helpful on A853 (he has a motorola development grade A853 that has high-security mode disabled so he can flash anything). The idea is you could fastboot to have a ram boost without using a swap partition (ramz does swap into a compressed region of ram).
Nadlabak says it's very helpful on A853 (he has a motorola development grade A853 that has high-security mode disabled so he can flash anything)
Click to expand...
Click to collapse
interesting, i have read something like that somewhere, but it was stated this is just rumor....
the approach with starting with stock kernel, then just enable some useful options (like swap), then start observing patches fits my vision too
peshovec said:
i tried to automate the boot.img repack.
https://github.com/CyanogenModXT720/fastboot-repack
Click to expand...
Click to collapse
I was just reading through the repository and saw the comment about replacing /init with one that handles parameters properly for insmod. You can also replace /init just before 2nd-init for the hijacked boot (2nd-init kills* /init and it gets restarted fresh). nadlabak's been doing this to add udev support on a853. I think fjfalcon's done that, too iirc.
*not really kill, it causes the original /init to exec /init
it can be done in the squisher...
# Rootfs stuff
mkdir -p $REPACK/ota/system/etc/rootfs/sbin
cp $OUT/root/sbin/adbd $REPACK/ota/system/etc/rootfs/sbin/adbd
cp $OUT/root/init $REPACK/ota/system/etc/rootfs/init
Click to expand...
Click to collapse
(nadlabak "Replaces" init and adbd)
then have to set permission in sh_hijack ...
probably will do that sometime in the future (if we had for example usb otg, probably we should have benefit of udev, but right now, it is just the feeling to be on the edge/latest and greatest ......e.g. not so high priority )
ok, run some tests
successful boot is achieved after
Code:
export CROSS_COMPILE=.......cyano/nadlabak/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi-
will try to attach the .config (swap enabled and the zImage
(attached in kernel_plus_config.tar )
of course i had some troubles mainly because the stock modules, are build with gcc 4.4.0 . Before seeing that, i was using different prebuilt toolchains ... and the kernel was tainted, paniced etc.....
using the above right now....
Code:
<6>[ 0.000000] Initializing cgroup subsys cpu
<5>[ 0.000000] Linux version 2.6.29-omap1 ([email protected]) (gcc version 4.4.0 (GCC) ) #2 PREEMPT Tue Apr 24 10:17:21 EEST 2012
/system/xbin/dd if=/dev/zero of=/sdcard/swap.img bs=1M count=50
mkswap /sdcard/swap.img
swapon /sdcard/swap.img
~ # free
total used free shared buffers
Mem: 230256 219232 11024 0 212
-/+ buffers: 219020 11236
Swap: 51192 1700 49492
So Mio, you can now try the swapz/
i will play with other options (moto has at least hdmi and camera driver, which are not present in later version of the omap 2.6.29 ... so i will try to merge
the gsm radio is very easy to break ...
i discovered, that if some module did not load 100% clean, the phone will lock/reboot ....
Then i start playing around that. Did not load any modules, and when load the modules about radio i discovered the title (e.g. still no radio, but phone lock/reboot again....)
So till now, my best combination (which i plan to test for a long (few days atleast) period) is:
plain stock + swap + 250, 500, 600, 800 Mhz (the default were always strange to me 250, 500, 550, 720 )
Also till now, i was not able to compile zram module
p.s. btw, i hope everybody knows, that actually there is no need for a separate swap partition,for somebody to use the swap, right ?
linkdriver
the following commit is very interesting to me ...
Code:
commit 1b533b8c037ae496a329e8e6c5e793232310b559
Author: Wei-Yu-Neng Loic <[email protected]>
Date: Tue Jun 9 17:48:14 2009 +0200
Add netmux_linkdriver and compile the netmux drivers in modules and not static
I wonder if before this commit, the radio was working?
Also this commit adds some harcoded configs ...
Code:
drivers/misc/netmux_linkdriver/usb/ModKconfig
....
+title = netmux_linkdriver
+obj_tree =
+depends =
+kconfig = Kconfig
+config = .config
+autoconf_header = modkconfig/autoconf.h
+config_header = modkconfig/config.h
.....
the autoconf.h and config.h are basically the kernel config ...
I suspect, that if we change the kernel config, in such way, that the modules will not be able to load, then we have to modify the modkonfig headers too...
I have created a kernel that has ramz and the ramzswap module for testing/experimentation.
Built from compcache-0.6.2 with the notify patches applied
Kernel source: ramz branch @ https://github.com/CyanogenModXT720/android_kernel
Rough notes on how to make your own bootz.img:
Compile using 4.4.0 toolchain from the android NDK version 5c. Something like:
Code:
export ARCH=arm
export CROSS_COMPILE=path/to/android-ndk-r5c/toolchains/arm-eabi-4.4.0/prebuilt/linux-x86/bin/arm-eabi-
export KERNEL_DIR=path/to/android_kernel
cd $KERNEL_DIR
make str_ramz_defconfig
make
Create bootz.img something like this:
Code:
mkbootimg \
--kernel path/to/android_kernel/arch/arm/boot/zImage \
--ramdisk path/to/uk-boot.img-ramdisk.gz \
--cmdline "" \
--base 10000000 \
--pagesize 00000800 \
-o bootz.img
Build the ramzswap.ko something like this:
Code:
cd compcache-0.6.2
# edit compat.h as described in "HIGHLY RECOMMENDED" section of README to enable use of the notify patch
make -C $KERNEL_DIR SUBDIRS=`pwd` modules
The kernel config I used is modified from str_defconfig, added as str_ramz_config (basically add swap, lzo_compress/lzo_decompress, /proc/config.gz) Link to config: https://github.com/CyanogenModXT720/android_kernel/blob/ramz/arch/arm/configs/str_ramz_defconfig
I haven't figured out how to cross-compile the rzscontrol yet so the CM compcache script doesn't work. OG Droid builds it as part of CM, so we can probably snag theirs.
Example of manual use (after fastboot boot bootz.img):
Code:
# Create 20MB zram
insmod ramzswap num_devices=1 disksize_kb=20480
# Enable swap on the new ramzswap0 device
swapon /dev/block/ramzswap0
# Set swappiness
echo 100 > /proc/sys/vm/swappiness
Be sure to check if your sdcard has a swap partition, you may want to disable the script that turns on swap there--it's usually in /system/etc/init.d/ with the name "swap" in the filename. I'm not sure how android sets priorities on different swap devices, the usual linux command isn't supported.
I have no idea what size of ramz people use. sholes (OG Droid) has compcache support in their CM7, so I'll probably look there next.
I've only tested this on a custom-tweaked version of peshovec's Apr 4 CM7 build running on xt720mod.sbf--I don't expect problems, but ymmv and you should be very aware of what the various /system/etc/init.d scripts (and possibly /system/etc/rootfs/*.rc) are up to.
The config can also be obtained from /proc/config.gz -- I propose we "insist" that custom kernels use that feature and then shell scripts can easily test existence of /proc/config.gz to detect custom kernels. On the other hand, that file consumes 16k...
Mioze7Ae said:
[*]Built from compcache-0.6.2 with the notify patches applied
Click to expand...
Click to collapse
hehe, that explain my troubles with compiling
i had used https://github.com/a853/a853_compcache
now tried the same setup with the old plain 0.6.2 and it compiles ...
Sweet. On peshovec's CM7 with a 40mb ramzswap, I'm able to keep XDA, HackerNews, Diode and Gh4a all running and switch between any of them instantly (also note I was already very happy with memory use on peshovec's CM7 without ramzswap). Probably not big news for people who've been using a swap partition, but compcache/ramzswap is swap without a swap partition--so no sdcard chewing. My perspective is: phone is perfectly usable without ramz if a reboot happens, but if I keep it charged I get some extra boost. For now, this is what I'm using as /system/etc/init.d/02ramz:
Code:
#!/system/xbin/busybox sh
# Don't do anything unless custom boot.img
[ -f /proc/config.gz ] || exit
# Create 40MB zram
/system/xbin/insmod /system/lib/modules/ramzswap.ko num_devices=1 disksize_kb=40960
/system/xbin/swapon /dev/block/ramzswap0
echo 100 > /proc/sys/vm/swappiness
hopefully in some days i will gather enough information, about how much exactly memory we are missing...
preliminary results are:
about 25 swap (pure one) needed,
-
about 5 which can be recovered with pkill at 4am (hello cron)
equal to about 20 MB more ram needed for full pleasure
This number can be used for calculating the percentage of ramz (which obviously is a trade between more RAM and faster RAM )
Doh! The device is automatically created as /dev/block/ramzswap0 on android not /dev/ramzswap0. I've updated my posts above appropriately.

Request for framework-res.apk and SystemUI.apk

Hello
Can someone help me and share the framework-res.apk and SystemUI.apk from JOP40D Stock odexed ? Or at least tell me where I can download it.
Thank You.
marser said:
Hello
Can someone help me and share the framework-res.apk and SystemUI.apk from JOP40D Stock odexed ? Or at least tell me where I can download it.
Thank You.
Click to expand...
Click to collapse
You can find these things in the system.img provided by the JOP40D factory image for occam. I've added them to an archive and attached to this post.
Thank you. Just to increase my knowledge... How I can extract the *.img ?? I was looking over the net looking for it, but i couldn't do finally.
marser said:
Thank you. Just to increase my knowledge... How I can extract the *.img ?? I was looking over the net looking for it, but i couldn't do finally.
Click to expand...
Click to collapse
Try 7-zip. I believe it can. Also a super light weight program.
Sent from my GT-I9000 using xda premium
marser said:
Thank you. Just to increase my knowledge... How I can extract the *.img ?? I was looking over the net looking for it, but i couldn't do finally.
Click to expand...
Click to collapse
I can provide the steps to do this in Linux as that is what I'm familiar with.
The system.img file is a sparse ext4 image that needs to be unpacked before it can be mounted. This is done with a binary compiled from AOSP source. Here are the steps for that:
Code:
git clone https://android.googlesource.com/platform/system/core
cd core
git checkout android-4.2.1_r1
cd libsparse
gcc -o simg2img -Iinclude -lz simg2img.c sparse_crc32.c backed_block.c output_file.c sparse.c sparse_err.c sparse_read.c
Once the simg2img binary is compiled you can make use of it on a sparse image:
Code:
simg2img system.img system.unpacked.img
The resulting unpacked.img will be much larger than the sparse image but can now be mounted and it's contents traversed.
Code:
mount -t ext4 -o loop system.unpacked.img /mnt/unpacked_system
want framework and system ui
I want nexus 4's stock rom JB 4.2 frame work and system ui...

[Tutorial] Kernel building instructions for Xperia SP

kernel sources for Xperia SP (C5302, C5303, C5306, M35h) {FW: 12.0.A.1.257} are available...
link to download sources:
http://dl-developer.sonymobile.com/code/copylefts/12.0.A.1.257.tar.bz2
i will keep pushing stock kernel sources to my git tree at the following branch:
https://github.com/DooMLoRD/android_kernel_sony_msm8960t/tree/sony_sources
following are the build instructions for developers who plan to work on this device....
toolchain recommended: Google GCC 4.7
Building kernel (zImage):
for Xperia SP:
import defconfig
Code:
ARCH=arm CROSS_COMPILE=~/arm-linux-androideabi-4.7/bin/arm-linux-androideabi- make viskan_huashan_defconfig
build zImage
Code:
ARCH=arm CROSS_COMPILE=~/arm-linux-androideabi-4.7/bin/arm-linux-androideabi- make -j8
incase u get errors like:
Code:
error : /scripts/gcc-wrapper.py
just correct the permissions of that file
Code:
chmod 755 ./scripts/gcc-wrapper.py
here is patch for compatibility with GCC 4.7 compilation
regards,
DooMLoRD
Instructions for building kernel.elf
first get the kernel built... once kernel is built u will get zImage and copy that zImage to the folder containing the build tools...
i have posted the build tools i use here:
https://github.com/DooMLoRD/build_tools/tree/master/msm8960t_viskan
Sony using the ELF format (similar to the 2012 devices)...
build kernel.elf
u can directly use the files posted at my git repo for build tools
or
use the following command:
Code:
python mkelf.py -o kernel.elf [email protected] [email protected],ramdisk [email protected],rpm [email protected],cmdline
the correct RPM.bin & bootcmd are posted at my git tree for build tools...
regards,
DooMLoRD
@DooMLoRD
I have to answer a lot of questions when compiling like board selection etc (have been clicking y and and enter for about 30 minutes now) is this normal?
View attachment 2411564
Hi Doomlord.
Being a fresh Xperia User, never heard about u on HTC forums. But glad to know you are helping a lot of people around here. I was wondering whether you could help me in understanding a bit about xperia phones before i dive into kernel kanging n stuff.
What i know from HTC devices
Partitions are like this:
Boot (separate partition on NAND)
Recovery (separate partition on NAND)
System like above
Data, same
Cache, same
etc
There, we used to flash boot.img to boot. boot.img contained kernel zImage+ramdisk
For recovery, we have recovery.img which contained zImage+recoveryramdisk
Then system and data etc as every other phone.
Here in Xperia, i cant understand where the recovery is. Is it inside kernel.elf?
Is it placed on a dedicated partition?
I want to know what i am messing with, before continuing.
What i plan to do is.
Build a clean TWRP from source (for myself, usage and learning.)
Build a stock based kernel from source. Add few govs/scheds and maybe Doubletap2wake etc. (but thats a little way ahead.)
Can you help me with this?
neXus PRIME said:
Hi Doomlord.
Being a fresh Xperia User, never heard about u on HTC forums. But glad to know you are helping a lot of people around here. I was wondering whether you could help me in understanding a bit about xperia phones before i dive into kernel kanging n stuff.
What i know from HTC devices
Partitions are like this:
Boot (separate partition on NAND)
Recovery (separate partition on NAND)
System like above
Data, same
Cache, same
etc
There, we used to flash boot.img to boot. boot.img contained kernel zImage+ramdisk
For recovery, we have recovery.img which contained zImage+recoveryramdisk
Then system and data etc as every other phone.
Here in Xperia, i cant understand where the recovery is. Is it inside kernel.elf?
Is it placed on a dedicated partition?
I want to know what i am messing with, before continuing.
What i plan to do is.
Build a clean TWRP from source (for myself, usage and learning.)
Build a stock based kernel from source. Add few govs/scheds and maybe Doubletap2wake etc. (but thats a little way ahead.)
Can you help me with this?
Click to expand...
Click to collapse
The recovery is inside the kernel but that's all I know
Sent from my C5303 using xda app-developers app
Yep. I found all I needed to know.... Fotakernel partition, elf ramdisk kernel and other stuff.
Sent from my C5303 using Tapatalk
No NAND is used
EMMC is there in all new xperia devices
Sent from my C6902 using xda app-developers app
DooMLoRD said:
No NAND is used
EMMC is there in all new xperia devices
Sent from my C6902 using xda app-developers app
Click to expand...
Click to collapse
ok thanks...
one more thing, if i build a custom kernel (lets say, stock-based), without any major changes..... can i flash that kernel file without unlocking bootloader???
as i understand, only kernel ftf files can be flashed via flashtool in locked bootlaoder.... correct me if im wrong.
neXus PRIME said:
ok thanks...
one more thing, if i build a custom kernel (lets say, stock-based), without any major changes..... can i flash that kernel file without unlocking bootloader???
as i understand, only kernel ftf files can be flashed via flashtool in locked bootlaoder.... correct me if im wrong.
Click to expand...
Click to collapse
No u can't
Sent from my C5302 using Tapatalk
Siddhesh said:
No u can't
Sent from my C5302 using Tapatalk
Click to expand...
Click to collapse
I compiled my kernel with a different splash screen and it flashed but I got a flashing black screen and it doesn't boot (i have UBL)
hi @DooMLoRD,
when i am making the elf of the zImage i am getting this error
[email protected]:~/android/huashan files/build tools/jk_output$ sudo bash '/home/jk-cha0s/android/huashan files/build tools/jk_output/build_it.sh'
[sudo] password for jk-cha0s:
Traceback (most recent call last):
File "mkelf.py", line 182, in <module>
main(sys.argv[1:])
File "mkelf.py", line 159, in main
size = os.path.getsize(seg.file)
File "/usr/lib/python2.7/genericpath.py", line 49, in getsize
return os.stat(filename).st_size
OSError: [Errno 2] No such file or directory: 'ramdisk.cpio.gz'
where to get the ramdisk.cpio.gz ?
edit:its inside a working kernel extract from there
neXus PRIME said:
Yep. I found all I needed to know.... Fotakernel partition, elf ramdisk kernel and other stuff.
Sent from my C5303 using Tapatalk
Click to expand...
Click to collapse
hey hi,
i need to know how to integrate recovery into a kernel i made. please help me to do it. :silly:
About Xperia SP(m35t)
Hello DooMLoRD
I want to ask you about how to build a kernel of m35t. I had tried to use the build_tools-master to unzip the kernel of m35t, and then repacked it without any modification. I flash the new kernel.elf but the phone doesn't work, how should I do ?
I want let the m35t run on Android 4.3 cause Sony hasn't update it, hope you can help me. Thanks a lot!
NewBay_STanLey said:
Hello DooMLoRD
I want to ask you about how to build a kernel of m35t. I had tried to use the build_tools-master to unzip the kernel of m35t, and then repacked it without any modification. I flash the new kernel.elf but the phone doesn't work, how should I do ?
I want let the m35t run on Android 4.3 cause Sony hasn't update it, hope you can help me. Thanks a lot!
Click to expand...
Click to collapse
Hi,
For android 4.3 the command to pack has changed from
Code:
python mkelf.py -o kernel.elf [email protected] [email protected],ramdisk [email protected],rpm [email protected],cmdline
To
Code:
python mkelf.py -o kernel.elf [email protected] [email protected],ramdisk [email protected],rpm [email protected],cmdline
pec0ra said:
Hi,
For android 4.3 the command to pack has changed from
Code:
python mkelf.py -o kernel.elf [email protected] [email protected],ramdisk [email protected],rpm [email protected],cmdline
To
Code:
python mkelf.py -o kernel.elf [email protected] [email protected],ramdisk [email protected],rpm [email protected],cmdline
Click to expand...
Click to collapse
Thanks, Pec0ra.
Yes, I know the command is changed, I repacked original kernel with build_it_JB-4.1.sh, the system is 12.0.C.2.58, everything is original, but the phone doesn't work.
I guess there is a little difference between c5303 and m35t, that I need to make a little modification to this tool.
I found the difference between m35t and other SPs
Finally, I found a difference between m35t and other SPs. The build_tools-master shouldn't be wrong, there is only one explanation is the RPM.bin not working for m35t. So,the rebuilt kernel can't boot up the m35t. @DooMLoRD, could you give me the right RPM.bin for m35t? Thanks a lot!
NewBay_STanLey said:
Finally, I found a difference between m35t and other SPs. The build_tools-master shouldn't be wrong, there is only one explanation is the RPM.bin not working for m35t. So,the rebuilt kernel can't boot up the m35t. @DooMLoRD, could you give me the right RPM.bin for m35t? Thanks a lot!
Click to expand...
Click to collapse
I think you can simply unpack it from stock kernel with the build tools. You will just have to find out which one of the extracted file it is since it might have another name.
Good news!
Good news! I found the way to extract rpm.bin witch use the flashtool. I use the version 207 C5303's zimage and ramdisk.cpio.gz and m35t's rpm.bin to repack the kernel. When I flash the kernel and version 207's rom in my m35t, it works! But only press the power button can let the back light gets on and off, the screen still can't display anything, and it can't play any sound, but it still take a big step!

Resources