@BrateloSlava @bataya @xpirt @awidawad @old.splatterhand (and anyone else who can assist - thanks in advance)
Ok people, something doesn't feel right to me so I need confirmation... When you split the boot.img and then unpack the ramdisk, how many blocks should there be? I am getting 1851 when unpacking the ramdisk in to the ramdisk folder. See picture below to view what I am talking about.
I just feel like something is missing or isn't being unpacked properly.
Sent from my K2_CL using Tapatalk
Now I don't remember exactly but from what I see in picture seems all files are there.. You can use also unpackbootimg to unpack it, if you have linux.
xpirt
xpirt said:
Now I don't remember exactly but from what I see in picture seems all files are there.. You can use also unpackbootimg to unpack it, if you have linux.
xpirt
Click to expand...
Click to collapse
Don't have my pc with me so having to do this on my device. Just needed to confirm because I have changed ro.secure=1 to 0. When I repack the ramdisk and then the new ramdisk with the zimage to create the new modded boot.img I get a bootloop. Must be an error on my part then lol.
Sent from my K2_CL using Tapatalk
@simonsimons34 @BrateloSlava @bataya @xpirt @awidawad @old.splatterhand
(and anyone else who can assist)
Hmmm, ok...
Code:
unpackbootimg -i /system/Folder/boot.img -o /system/Folder/
I get the zImage and boot.img-ramdisk.gz.
I then do the following:
Code:
mkdir /system/Folder/ramdisk
cp /system/Folder/boot.img-ramdisk.gz /system/Folder/ramdisk
At this point I have created a folder named ramdisk and have copied the boot.img-ramdisk.gz over in to the ramdisk folder.
Next I do as followed:
Code:
cd /system/Folder/ramdisk
gunzip -cd ../boot.img-ramdisk.gz | cpio -i
I delete the ramdisk.gz file in the ramdisk folder because it is not needed there anymore after the extraction. I edit the default.prop file. Then I do as followed:
Code:
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
Ok, so now I have a new ramdisk that has been modded and repacked. I then run mkbootimg to join together the newramdisk.cpio.gz and zImage to form the modded boot.img. As followed:
Code:
mkbootimg --kernel /system/Folder/boot.img-zImage --ramdisk /system/Folder/newramdisk.cpio.gz --base 0x80400000 --pagesize 2048 --ramdiskaddr 0x81808000 --cmdline 'console=ttyHSL0,115200,n8 user_debug=31' -o /system/Folder/bootmod_4_1_2.img
Now I have the new boot.img running at a size of 5.93 MB.
I place the boot image in a zip with the android-info.txt and place it on the external sdcard. Boot in to bootloader, follow instructions, reboot. Then stuck on splash screen with red text.
Apparently I am doing something wrong with either unpacking or packing the boot.img.
And I am becoming pretty annoyed with it lol.
Sent from my K2_CL using Tapatalk
I should add, that I open up the original boot.img with a hex editor and remove everything before ANDROID! then save so when I run unpackbootimg it reads the android magic value properly.
Sent from my K2_CL using Tapatalk
Inside the ramdisk folder...
Sent from my K2_CL using Tapatalk
And a picture showing the original ramdisk, new ramdisk, original boot, and new boot....
Sent from my K2_CL using Tapatalk
Nobody huh? Lol
Sent from my K2_CL using Tapatalk
Well, manage to repack the boot.img while holding up to 16 mb then wrote the img to the device. Making progress I guess, as it now will boot, stick on splash screen, then reboot in to TWRP recovery lol. Will keep at it until I resolve this one way or the other
Sent from my K2_CL using Tapatalk
Modding.MyMind said:
Nobody huh? Lol
Sent from my K2_CL using Tapatalk
Click to expand...
Click to collapse
Sorry, but i never worked on boot.img/kernels. So in this case i'm not the right one to help.
old.splatterhand said:
Sorry, but i never worked on boot.img/kernels. So in this case i'm not the right one to help.
Click to expand...
Click to collapse
No worries, just tagging people on here who I know are a little more experience then others. For those I did not tag (take no offense - you were under the radar).
Anyways, I went ahead and just unpacked then repacked everything without making any edits and still the same results. Not sure what is going on now. Has something to do with repackaging the boot.img I'm sure but can't seem to pin point the problem.
Sent from my K2_CL using Tapatalk
Modding.MyMind said:
No worries, just tagging people on here who I know are a little more experience then others. For those I did not tag (take no offense - you were under the radar).
Anyways, I went ahead and just unpacked then repacked everything without making any edits and still the same results. Not sure what is going on now. Has something to do with repackaging the boot.img I'm sure but can't seem to pin point the problem.
Sent from my K2_CL using Tapatalk
Click to expand...
Click to collapse
Removed. Saw you packed it fine.. The problem is not when you pack the kernel and ramdisk but I think when you pack the ramdisk, try without unpacking it.
xpirt
For unpack kernel and pack ramdisk I'm use cygwin and View attachment tools_for_cygwin.7z.
From cygwin console:
Kernel built from parts I perform under Ubuntu:
Code:
~/boot_tools/mkbootimg --kernel ~/Kernel_output/zImage --ramdisk ~/Kernel_output/ramdisk.gz --base 0x80400000 --pagesize 2048 --ramdiskaddr 0x81808000 --cmdline ~/Kernel_output/cmdline.txt -o boot-new.img
In the example, I have post the commands for compiling a new kernel 4.1.2
I think he is using the phone, with computer it's more simple.
xpirt
@xpirt @BrateloSlava
I am using my phone. And with mkbootimg I am using just as BrateloSlava demonstrated. However, you are using a text file which holds your cmdline... Maybe I should try that lol.
Sent from my K2_CL using Tapatalk
I also noticed in @BrateloSlava picture when he goes to unpack the ramdisk in to the ramdisk folder it counts up to 1944 blocks while for me I am only getting 1851. Assuming this is the case, then that is where my problem is. I am missing stuff lol.
Sent from my K2_CL using Tapatalk
old.splatterhand said:
Sorry, but i never worked on boot.img/kernels. So in this case i'm not the right one to help.
Click to expand...
Click to collapse
+1, but I think that problem is phone. You should try do it on pc.
bataya said:
+1, but I think that problem is phone. You should try do it on pc.
Click to expand...
Click to collapse
Will be doing that today and comparing results from both the pc and phone version with a hex editor to determine what the problem is. Something isn't adding up because I've edited boot images before. This is just the first time I've done it on a phone lol.
Sent from my K2_CL using Tapatalk
Update: been reviewing the open source code from dsixda kitchen in regards to the boot.img. Rebuilding the sources for arm devices. Seems the current build I have from another source is lacking stuff which isn't building the boot.img properly after careful analysis between the modboot.img on my device and the modboot.img on my PC.
After the rebuilt is successful then my problem will be resolved and I will change the title to (solved).
Sent from my K2_CL using Tapatalk
Thread title updated. Compiled source code was successful. Managed to unpack, edit, repack, and use dd to write the boot.img straight to the partition then reboot. All of this on my device without a PC. Everything went well.
Pat on the back lol.
Sent from my K2_CL using Tapatalk
Related
heres where im at now. im trying to edit the init.rc
i have extracted the boot.img using unpack-bootimg.pl and have got the follwing
empty folder called ramdisk
boot.img-ramdisk.cpio.gz
boot.img-ramdisk.gz
boot.img-kernell.gz
i am now stuck extracting the ramdisk to edit init.rc
i also get error gunzip is not a recognied command
any help??
add.thebad said:
i am trying to edit the init.rc but have problems extracting boot.img-ramdisk.gz
i have made a rom dump
then extracted boot.img
got boot.img-ramdisk.gz so extracted that
and now i have a file called boot.img-ramdisk nothing else
so how can i edit ramdisk?
thanks in advance. any help welcome
Click to expand...
Click to collapse
add.thebad,
Been a while since I've done this, lol, but these are the instructions I followed:
http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack%2C_Edit%2C_and_Re-Pack_Boot_Images
There's links to the Perl scripts in that page too.
Hope this helps.
Cheers!
thanks but the link to the scripts is broke. dont suppose you know where to get another
add.thebad said:
thanks but the link to the scripts is broke. dont suppose you know where to get another
Click to expand...
Click to collapse
Adam (that's right, right? ),
I found an XDA version of the "How To" link I posted above: http://forum.xda-developers.com/showthread.php?t=443994 and the files are at the bottom of the first post and they are still available.
By the way, I used these instructions (along with lots of help from Amon_RA himself) for unpacking and repacking Amon_RA's custom recovery .img file (I built a version that doesn't require the use of a trackball for the Eris).
I think after you unpack the ramdisk, you'll just replace / update your init.rc file and then repack everything before doing the mkbootfs on your ramdisk directory (followed by your particular mkbootimg command).
Good luck!
Cheers!
thanks for you help i have the scripts now and i can get it to extract however i get the error "gunzip is not recognised" and the files it does extract are emply
add.thebad said:
thanks for you help i have the scripts now and i can get it to extract however i get the error "gunzip is not recognised" and the files it does extract are emply
Click to expand...
Click to collapse
Are you on a Linux system?
The gzip / gunzip utilities should be on your system and/or referenced in you PATH environment variable.
Do a find / -name 'gzip' 2> /dev/null or find / -name gunzip 2> /dev/null or whereis gunzip or which gunzip (one of these should reveal the utility's location).
The unpack-bootimg.pl does use the gunzip command to extract the files, so you will need this utility.
Cheers!
after a bit of reading i think the way i have got my boot.img is wrong could this be why the folder is empty?
add.thebad said:
after a bit of reading i think the way i have got my boot.img is wrong could this be why the folder is empty?
Click to expand...
Click to collapse
Not sure... Like I said, I started with a known, good recovery.img file... I never have (yet) played with a boot.img file...
scary alien said:
Not sure... Like I said, I started with a known, good recovery.img file... I never have (yet) played with a boot.img file...
Click to expand...
Click to collapse
i managed to extract a boot.img from an official system image and tried that and got the same result. could i have anything to do with gunzip not being recognised
add.thebad said:
i managed to extract a boot.img from an official system image and tried that and got the same result. could i have anything to do with gunzip not being recognised
Click to expand...
Click to collapse
lol...I think we cross-posted a little bit ago...see above ^^^ for my post about your gunzip utility.
scary alien said:
lol...I think we cross-posted a little bit ago...see above ^^^ for my post about your gunzip utility.
Click to expand...
Click to collapse
haha so we did.
no im on windows and cant get gunzip to work. think i have gzip working tho
any ideas?
add.thebad said:
haha so we did.
no im on windows and cant get gunzip to work. think i have gzip working tho
any ideas?
Click to expand...
Click to collapse
Yeah, you'll have to grab some Windows versions of the Unix commands.
I can't remember where I got mine, but a quick search yielded this as a possible starting place:
http://www.cyberciti.biz/faq/unix-command-line-utilities-for-windows/
There's a couple of links to sets of tools. After you download and install these, make sure you point / change your Windows PATH to point to the utilities or just do all of your work in the same directory.
You really just need the utilities that are referenced in the Perl script... Not sure I'd bother with the whole Cygwin thing (your call, of course).
Cheers!
scary alien said:
Yeah, you'll have to grab some Windows versions of the Unix commands.
I can't remember where I got mine, but a quick search yielded this as a possible starting place:
http://www.cyberciti.biz/faq/unix-command-line-utilities-for-windows/
There's a couple of links to sets of tools. After you download and install these, make sure you point / change your Windows PATH to point to the utilities or just do all of your work in the same directory.
You really just need the utilities that are referenced in the Perl script... Not sure I'd bother with the whole Cygwin thing (your call, of course).
Cheers!
Click to expand...
Click to collapse
Ok will try that. I allready have cygwin to try get the commands i will try ur link tho. Think im getting a bit outa my depth but ive learnt so much so far i dont want to give up so thanks for your help
heres where im at now. im trying to edit the init.rc
i have extracted the boot.img using unpack-bootimg.pl and have got the follwing
empty folder called ramdisk
boot.img-ramdisk.cpio.gz
boot.img-ramdisk.gz
boot.img-kernell.gz
i am now stuck extracting the ramdisk to edit init.rc
i also get error gunzip is not a recognied command
any help??
add.thebad said:
heres where im at now. im trying to edit the init.rc
i have extracted the boot.img using unpack-bootimg.pl and have got the follwing
empty folder called ramdisk
boot.img-ramdisk.cpio.gz
boot.img-ramdisk.gz
boot.img-kernell.gz
i am now stuck extracting the ramdisk to edit init.rc
i also get error gunzip is not a recognied command
any help??
Click to expand...
Click to collapse
Well, I spent some time tonight trying to do this under Windows myself, but I used the split_bootimg.pl Perl script instead to create the *.img-kernel and *.img-ramdisk.gz files (with mixed success). lol, I had a hard time re-finding some good Unix commands that would run under Windows (I've got some good ones on my work PC, but that doesn't help me now).
Here's the relevant section in the original HOWTO link I sent you:
% ./split_bootimg.pl boot.img
Page size: 2048 (0x00000800)
Kernel size: 1388548 (0x00153004)
Ramdisk size: 141518 (0x000228ce)
Second size: 0 (0x00000000)
Board name:
Command line: no_console_suspend=1
Writing boot.img-kernel ... complete.
Writing boot.img-ramdisk.gz ... complete.
Now, extracting the ramdisk under Windows is a little trickier and I couldn't get the whole way there because I couldn't find the cpio command for Windows (you might have it already if you are using Cygwin). Anyway, the documentation explains that you would create a temporary "ramdisk" directory, change to it, use the gzip utility to uncompress and feed the output to the cpio command to actually extract the files and directories:
Extract the ramdisk.
% mkdir ramdisk
% cd ramdisk
% gzip -dc ../boot.img-ramdisk.gz | cpio -i
% cd ..
That should work for you (if you have appropriate utilities) and should give you the various files that comprise the ramdisk for you to modify (i.e., the init.rc).
After modifying them, you would use the mkbootfs utility (not sure if this is actually available in Windows) to re-pack the ramdisk and then use the mkbootimg command to re-pack your boot image.
It might be easier to get a Linux distro installed that you can launch from Windows just to do this.
Good luck!
scary alien said:
It might be easier to get a Linux distro installed that you can launch from Windows just to do this.
Good luck!
Click to expand...
Click to collapse
ahaa managed to get everything extracted and edit the init.rc so thank you for all your help
one the linux side of things i have ubuntu dual boot and use it from time to time im just not familiar with the commands on it so prefer windows. might try it more oftern since it can be a pain finding all the tools for windows
ne way all i need to do now is repackage it which is proving to be a bit of a problem atm.
a sleep less night and ill c how i get on lol
cheers for the help
add.thebad said:
ahaa managed to get everything extracted and edit the init.rc so thank you for all your help
one the linux side of things i have ubuntu dual boot and use it from time to time im just not familiar with the commands on it so prefer windows. might try it more oftern since it can be a pain finding all the tools for windows
ne way all i need to do now is repackage it which is proving to be a bit of a problem atm.
a sleep less night and ill c how i get on lol
cheers for the help
Click to expand...
Click to collapse
Adam,
Glad you are making progress .
Here's the last few bits that I used to re-pack my ramdisk and to rebuild the bootable recovery .img file (i.e., ramdisk + kernel):
# pack-up the ramdisk directory's files to build the new ramdisk .zip
#
mkbootfs ./ramdisk | gzip > ramdisk-new.gz
# now, repack the kernel and ramdisk to make the new recovery image
#
mkbootimg --cmdline 'no_console_suspend=1 console=null' --kernel recovery-RA-eris-v1.6.2.img-kernel --ramdisk ramdisk-new.gz --base 0x11200000 -o new-recovery.img
This is very similar to the instructions in the HOWTO thread.
Also, note the --base parameter in the mkbootimg line, this is unique/specific to each phone/bootable image since it appears to be the boot/load address, so you'll have to know or find-out what this particular value is for your situation.
Good luck and let me know how it goes.
Cheers to you, too!
scary alien said:
Adam,
Glad you are making progress .
Here's the last few bits that I used to re-pack my ramdisk and to rebuild the bootable recovery .img file (i.e., ramdisk + kernel):
# pack-up the ramdisk directory's files to build the new ramdisk .zip
#
mkbootfs ./ramdisk | gzip > ramdisk-new.gz
# now, repack the kernel and ramdisk to make the new recovery image
#
mkbootimg --cmdline 'no_console_suspend=1 console=null' --kernel recovery-RA-eris-v1.6.2.img-kernel --ramdisk ramdisk-new.gz --base 0x11200000 -o new-recovery.img
This is very similar to the instructions in the HOWTO thread.
Also, note the --base parameter in the mkbootimg line, this is unique/specific to each phone/bootable image since it appears to be the boot/load address, so you'll have to know or find-out what this particular value is for your situation.
Good luck and let me know how it goes.
Cheers to you, too!
Click to expand...
Click to collapse
ok gave up in windows cannot find a command or perl script for mkbootfs so now in ubuntu giving it a try
i can do that first bit fine. does it need to be re cpio?
on the next commannd i type
Code:
mkbootimg --cmdline 'no_console_suspend=1 console=null' --boot.img-kernel.gz --boot.img-ramdisk.gz ----base 0x10000000 -o new-boot.img
and get this
Code:
[email protected]:~/Desktop$ mkbootimg --cmdline 'no_console_suspend=1 console=null' --boot.img-kernel.gz --boot.img-ramdisk.gz ----base 0x10000000 -o new-boot.img
usage: mkbootimg
--kernel <filename>
--ramdisk <filename>
[ --second <2ndbootloader-filename> ]
[ --cmdline <kernel-commandline> ]
[ --board <boardname> ]
[ --base <address> ]
-o|--output <filename>
but nothing is outputted on my desktop
add.thebad said:
ok gave up in windows cannot find a command or perl script for mkbootfs so now in ubuntu giving it a try
Click to expand...
Click to collapse
I believe that the mkbootfs utility is available / created as a result of building / compiling the Android open source.
Like I mentioned before, its been a while since I did all this myself, but I had to download and do the base "make" for the Android open source since I was actually changing and recompiling the custom recovery.
So, you'll need to check-out / download the desired AOSP branch / version from the proper location (which eludes me at the moment). Then, I believe doing the base / generic "make" for the AOSP will create or reveal the mkbootfs utility.
One of the threads in the following forum should have a better, starter explanation for doing the above that I could post here:
http://forum.xda-developers.com/forumdisplay.php?f=613
I'd dig into this more with you tonight, but I gotta do my taxes and then go into work for a few hours tonight (ugh on both counts, lol!).
Good luck!
Hi,
I've been trying to get my own kernel with few modifications running on my ASUS Transformer. I've followed few guides around with no luck. What I did:
Tried two source trees:
1) Official from ASUS
2) Roach2010s tree from github (https://github.com/Roach2010/android_kernel_TF101.git)
Used .config from my current kernel which is running fine (Prime kernel) without any changes.
Compiled kernel.
So far looks good, with few modifications to config I got new modules that works so crosscompiler is not misscompiling. Now the part where I'm doing something wrong and can't figure out what.
I started with Prime Kernel from http://forum.xda-developers.com/showthread.php?t=1251044
* Unziped the archive
* blobunpack blob
* created blob.LNX in several ways described bellow
* blobpack blob.HEADER blob LNX blob.LNX
* dd if=blob of=/dev/block/mmcblk0p4
* reboot
How I created blob.LNX
A) Use extracted blob.LNX and use abootimg to replace kernel
* abootimg -u blob.LNX -k zImage
B) Extracted all parts and recreated image using abootimg
* abootimg -x blob.LNX
* abootimg --create blob.LNX -f bootimg.cfg -k zImage -r initrd.img
C) Extracted all parts and recreated image using bootunpack and mkbootimg
* bootunpack blob.LNX
* mkbootimg --kernel zImage --ramdisk ramdisk.gz -o blob.LNX
In addition I tried few modifications:
* enlarging bootsize in bootimg.cfg to make sure everything fits
* passing cmdline my current kernel booted up with as default in .config, as cmdline in bootimg.cfg and both
All my efforts ended up on ASUS boot up screen, no matter what I try. So my question is, am I missing something? Did I skipped some important part? Have I done something wrong? Any ideas appreciated.
If nobody has any idea, can somebody please create kernel with enabled kexec for my ASUS Transformer? That was the ultimate goal of trying to get my own kernel, but if I can't get working just recompiled one...
-miska- said:
Hi,
I've been trying to get my own kernel with few modifications running on my ASUS Transformer. I've followed few guides around with no luck. What I did:
Tried two source trees:
1) Official from ASUS
2) Roach2010s tree from github (https://github.com/Roach2010/android_kernel_TF101.git)
Used .config from my current kernel which is running fine (Prime kernel) without any changes.
Compiled kernel.
So far looks good, with few modifications to config I got new modules that works so crosscompiler is not misscompiling. Now the part where I'm doing something wrong and can't figure out what.
I started with Prime Kernel from http://forum.xda-developers.com/showthread.php?t=1251044
* Unziped the archive
* blobunpack blob
* created blob.LNX in several ways described bellow
* blobpack blob.HEADER blob LNX blob.LNX
* dd if=blob of=/dev/block/mmcblk0p4
* reboot
How I created blob.LNX
A) Use extracted blob.LNX and use abootimg to replace kernel
* abootimg -u blob.LNX -k zImage
B) Extracted all parts and recreated image using abootimg
* abootimg -x blob.LNX
* abootimg --create blob.LNX -f bootimg.cfg -k zImage -r initrd.img
C) Extracted all parts and recreated image using bootunpack and mkbootimg
* bootunpack blob.LNX
* mkbootimg --kernel zImage --ramdisk ramdisk.gz -o blob.LNX
In addition I tried few modifications:
* enlarging bootsize in bootimg.cfg to make sure everything fits
* passing cmdline my current kernel booted up with as default in .config, as cmdline in bootimg.cfg and both
All my efforts ended up on ASUS boot up screen, no matter what I try. So my question is, am I missing something? Did I skipped some important part? Have I done something wrong? Any ideas appreciated.
If nobody has any idea, can somebody please create kernel with enabled kexec for my ASUS Transformer? That was the ultimate goal of trying to get my own kernel, but if I can't get working just recompiled one...
Click to expand...
Click to collapse
Here is what I've done. If you have successfully built a kernel with the resulting zImage, then you are part way there, I believe there is a kernel config option to enable kexec support but I haven't tried that. Next, you can take some other kernel's .zip file (CWM flashable) and unzip it. You may need to download a zip utility. You'll have 2 folders and a kernel blob. If you bootunpack this kernel blob, you'll end up with the kernel blob and a some *.LNX file. This *.LNX file is the same as a boot.img file. You can use dsixda's Android kitchen to split this into the initrd and the kernel (zImage) parts. Replace the zImage with your own and move any modules you may have also built if necessary into the initrd part, join them back together into a boot.img in the kitchen.
copy this boot.img back to where you unzipped the kernel.zip, delete the original *.LNX file, rename the boot.img to the same name as the previous *.LNX file and then bootpack it together and flash it through CWM. Zip the 2 folders and the kernel blob you just made back together with whatever name you want. You can edit the text in the updater script before you zip it all up, but whether you do or not it should boot.
Yes, there is kexec config option, but I haven't suceeded even without changing anything so enabling it doesn't make kernel boot :-D I tried Android Kitche to split boot image and I ended up with the same files (compared the content to check) as with abootimg -x. Tried recreating update.zip and sign it using Android Kitchen, just to be sure, that something in android is not in the way to the actualization from running system. Still no luck :-(
-miska- said:
Yes, there is kexec config option, but I haven't suceeded even without changing anything so enabling it doesn't make kernel boot d:-D I tried Android Kitche to split boot image and I ended up with the same files (compared the content to check) as with abootimg -x. Tried recreating update.zip and sign it using Android Kitchen, just to be sure, that something in android is not in the way to the actualization from running system. Still no luck :-(
Click to expand...
Click to collapse
I didn't even sign mine as I have signature verification turned off in CWM recovery. Didn't change the text either as I was mostly experimenting and learning. I know kexec works under linux, but I think it requires separate package(s) and configuration to do so. I got a bit confused with blobpack, blobunpack info, but figured out that with just the kernel you don't seem to need the mentioned header file, just the .LNX which is the same as boot.img which is the combined kernel zImage and initramfs. If the kernel blob is still there and you use the same name for the output file then it doesn't matter because it will get overwritten anyway. Worked for me at least using source of kernel I've booted before and my running .config.
sidneyk said:
I didn't even sign mine as I have signature verification turned off in CWM recovery. Didn't change the text either as I was mostly experimenting and learning. I know kexec works under linux, but I think it requires separate package(s) and configuration to do so. I got a bit confused with blobpack, blobunpack info, but figured out that with just the kernel you don't seem to need the mentioned header file, just the .LNX which is the same as boot.img which is the combined kernel zImage and initramfs. If the kernel blob is still there and you use the same name for the output file then it doesn't matter because it will get overwritten anyway. Worked for me at least using source of kernel I've booted before and my running .config.
Click to expand...
Click to collapse
hmmm, zip file I had as an example was using blobed boot image going through mmcblk0p4. Do you have some link to .zip file that does it differently?
kexec is a way how to boot something else from linux directly without need to fiddle with bootloader. To use it, two parts are needed - kernel that supports it (that's what I can't get) and tool to actually use it/call it. Tool is not a problem, got that one hopefully ready, but without the kernel...
-miska- said:
hmmm, zip file I had as an example was using blobed boot image going through mmcblk0p4. Do you have some link to .zip file that does it differently?
kexec is a way how to boot something else from linux directly without need to fiddle with bootloader. To use it, two parts are needed - kernel that supports it (that's what I can't get) and tool to actually use it/call it. Tool is not a problem, got that one hopefully ready, but without the kernel...
Click to expand...
Click to collapse
Have you tried Koush's "anykernel.zip" code (probably requires a few mods)? It appears to be trying to replace the blob based updater-scripts that are all over the place.
I've used it successfully, but it has mostly been on other devices, and it is very easy to use. I think some of the templates are too generic and maybe confusing, and without figuring out how edify scripting actually works, it is mysterious, but I'd look at this code, git it and try to use it:
I'll try to provide a working example since I just added a few modules to one of the kernels 2.6.36-4 that're out there for the tf101, but I need to be sure it's working first. I think there's perhaps one difference at least between what Koush shows for the xoom and the tf101 so am working on it.
https://github.com/koush/AnyKernel
Good luck -
-miska- said:
hmmm, zip file I had as an example was using blobed boot image going through mmcblk0p4. Do you have some link to .zip file that does it differently?
kexec is a way how to boot something else from linux directly without need to fiddle with bootloader. To use it, two parts are needed - kernel that supports it (that's what I can't get) and tool to actually use it/call it. Tool is not a problem, got that one hopefully ready, but without the kernel...
Click to expand...
Click to collapse
I was using clemsyn-blades_kernel_ver22a zip file. I don't know if it was doing it different or not, haven't checked that far into it.
sidneyk said:
I was using clemsyn-blades_kernel_ver22a zip file. I don't know if it was doing it different or not, haven't checked that far into it.
Click to expand...
Click to collapse
hmmm, checked that one, uses blobed image and 'dd if=/tmp/blob of=/dev/block/mmcblk0p4' as well. Maybe I'll try different crosscompiler anyway, that's the one thing I haven't altered yet :-/
hachamacha said:
Have you tried Koush's "anykernel.zip" code (probably requires a few mods)? It appears to be trying to replace the blob based updater-scripts that are all over the place.
I've used it successfully, but it has mostly been on other devices, and it is very easy to use. I think some of the templates are too generic and maybe confusing, and without figuring out how edify scripting actually works, it is mysterious, but I'd look at this code, git it and try to use it:
I'll try to provide a working example since I just added a few modules to one of the kernels 2.6.36-4 that're out there for the tf101, but I need to be sure it's working first. I think there's perhaps one difference at least between what Koush shows for the xoom and the tf101 so am working on it.
Click to expand...
Click to collapse
Haven't tried that one, looks interesting... This one doesn't use blobed update and wites image directly somewhere. Just would require to check that that somewhere is the right place :-D Thanks, will take a look at that and what other edify commands are availble in updater, sounds like interesting alternative approach...
-miska- said:
Haven't tried that one, looks interesting... This one doesn't use blobed update and wites image directly somewhere. Just would require to check that that somewhere is the right place :-D Thanks, will take a look at that and what other edify commands are availble in updater, sounds like interesting alternative approach...
Click to expand...
Click to collapse
I'm modifying the script I've seen passed around (not quite Koush's git repo version) passed around to see if I can get it to work on the tf101. The 'write it somewhere' edify command is the question mark, but I think it is going on it's (the device's) internal partition table and vectored to 'boot', which is either a terrific generic idea, or terrible depending upon what edify does. I can't really find a heck of a lot explaining anything about the individual edify commands. I'm just getting rid of the 'showstoppers' where partition names like mmc0p* are used that are clearly wrong for the tf101. I made the mistake of trying one that I only later realized thought that partition 1 was data, when it is actually partition 7. Good thing I can make nvflash backups on my 'old' transformer.
I'll post back later today with any results I get. I'm not concerned about whether my kernel worked since it is completely experimental , just that it got written there, so I might use a working version with a different kernel name (in Makefile) just so I can get 'proof of concept' .
On a slightly different note but having to do with what you're doing, I tried the blob route this week, and for some reason, blobunpack/pack right from Rayman's git repo do not unpack the blobs correctly for say 'clemsyms' or 'Prime's' blobs, which has me wondering about some change that maybe took place. In any case, it forces me down this other path anyway.
If they are working OK for you, could you tell me a couple things?
1) Your linux distro and architecture (x86/x86_64)
2) did you build them from Rayman's repo? Did you get binaries from somewhere, if so where?
3) parameters? I don't think mine take any but the blob name.
4) Output suffixes. I only get .LNX from any of the above blobs which is useless.
EDIT: I was recalling that 'edify' in CWM came into being somewhere (maybe) past the only version that works with the tf101 (we're on ~v3.x and edify ~v4/5+). If that's the case, then we're all stuck with blobs because that one write command is edifi(ed) most likely. I'll stare at the git CWM source today too to figure out if it used the edify stuff in this version. I think Solarnz had it in his git hub.
hachamacha said:
I'm modifying the script I've seen passed around (not quite Koush's git repo version) passed around to see if I can get it to work on the tf101. The 'write it somewhere' edify command is the question mark, but I think it is going on it's (the device's) internal partition table and vectored to 'boot', which is either a terrific generic idea, or terrible depending upon what edify does. I can't really find a heck of a lot explaining anything about the individual edify commands. I'm just getting rid of the 'showstoppers' where partition names like mmc0p* are used that are clearly wrong for the tf101. I made the mistake of trying one that I only later realized thought that partition 1 was data, when it is actually partition 7. Good thing I can make nvflash backups on my 'old' transformer.
I'll post back later today with any results I get. I'm not concerned about whether my kernel worked since it is completely experimental , just that it got written there, so I might use a working version with a different kernel name (in Makefile) just so I can get 'proof of concept' .
On a slightly different note but having to do with what you're doing, I tried the blob route this week, and for some reason, blobunpack/pack right from Rayman's git repo do not unpack the blobs correctly for say 'clemsyms' or 'Prime's' blobs, which has me wondering about some change that maybe took place. In any case, it forces me down this other path anyway.
If they are working OK for you, could you tell me a couple things?
1) Your linux distro and architecture (x86/x86_64)
2) did you build them from Rayman's repo? Did you get binaries from somewhere, if so where?
3) parameters? I don't think mine take any but the blob name.
4) Output suffixes. I only get .LNX from any of the above blobs which is useless.
EDIT: I was recalling that 'edify' in CWM came into being somewhere (maybe) past the only version that works with the tf101 (we're on ~v3.x and edify ~v4/5+). If that's the case, then we're all stuck with blobs because that one write command is edifi(ed) most likely. I'll stare at the git CWM source today too to figure out if it used the edify stuff in this version. I think Solarnz had it in his git hub.
Click to expand...
Click to collapse
Blobs are used on the tf101 because they are the ONLY way of flashing boot/recovery, there is no block device mapping of them on our device
lilstevie said:
Blobs are used on the tf101 because they are the ONLY way of flashing boot/recovery, there is no block device mapping of them on our device
Click to expand...
Click to collapse
OK: Thanks lilstevie,
That takes care of that. Time for me to make peace with blobs.
After steve's reply, I just went to using blobs. I've got my own kernel running fine on the tf101 using that method.
For the best reference I've seen on using blobs and boottools , try this post:
http://forum.xda-developers.com/showthread.php?t=1193737
---
Just got back from work, will ply with it some more, but I'll start with answering the questions...
hachamacha said:
1) Your linux distro and architecture (x86/x86_64)
Click to expand...
Click to collapse
Gentoo x86-64
hachamacha said:
2) did you build them from Rayman's repo? Did you get binaries from somewhere, if so where?
Click to expand...
Click to collapse
Compiled from git repo. I always tried to find the most upstream repo for each tool and then compiled it by myself.
hachamacha said:
3) parameters? I don't think mine take any but the blob name.
4) Output suffixes. I only get .LNX from any of the above blobs which is useless.
Click to expand...
Click to collapse
These two comes together:
'blobunpack blob' - takes a blob as input and ouptuts blob.HEADER and blob.LNX
'bootunpack blob.LNX' - takes blob.LNX as input and outputs blob.LNX-kernel.gz, blob.LNX-ramdisk.cpio.gz and blob.LNX-config
'abootimg -x blob.LNX' - takes blob.LNX as input and outputs zImage, initrd.img and bootimg.cfg
Resulting files from bootunpack and abootimg are almost same, only difference is the configuration file
To repack:
'abootimg --create newblob/blob.LNX -f bootimg.cfg -k zImage -r initrd.img'
or
'mkbootimg --kernel zImage --ramdisk blob.LNX-ramdisk.cpio.gz -o newblob/blob.LNX'
and then
'blobpack blob.HEADER newblob/blob LNX newblob/blob.LNX'
Unless I change kernel, everything works just fine :-D
-miska- said:
Just got back from work, will ply with it some more, but I'll start with answering the questions...
Gentoo x86-64
Compiled from git repo. I always tried to find the most upstream repo for each tool and then compiled it by myself.
These two comes together:
'blobunpack blob' - takes a blob as input and ouptuts blob.HEADER and blob.LNX
'bootunpack blob.LNX' - takes blob.LNX as input and outputs blob.LNX-kernel.gz, blob.LNX-ramdisk.cpio.gz and blob.LNX-config
'abootimg -x blob.LNX' - takes blob.LNX as input and outputs zImage, initrd.img and bootimg.cfg
Resulting files from bootunpack and abootimg are almost same, only difference is the configuration file
To repack:
'abootimg --create newblob/blob.LNX -f bootimg.cfg -k zImage -r initrd.img'
or
'mkbootimg --kernel zImage --ramdisk blob.LNX-ramdisk.cpio.gz -o newblob/blob.LNX'
and then
'blobpack blob.HEADER newblob/blob LNX newblob/blob.LNX'
Unless I change kernel, everything works just fine :-D
Click to expand...
Click to collapse
Pretty similar, although the kernel zImage itself is always a mystery unless you've not changed anything, but even then, getting it built with the right toolchain, etc isn't guaranteed. So lets assume that just works for now since it'll become obvious as it goes along.
I guess I have not heard of 'abootimg' as a tool for this, so I've been using the more manual way of dissecting the initrd as follows:
Code:
gunzip -dc ../blob.LNX-ramdisk.cpio.gz | cpio -i
If you need to change something , for example, in default.prop like ro.secure=0, then you'd do it there.
Then repack into a new ramdisk:
Code:
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
Finally I just had a somewhat heavily modified zImage from my build, so did this to make the blob (I'd copied zImage to blob.LNK-zImage.gz below):
Code:
./mkbootimg --kernel blob.LNX-zImage.gz --ramdisk newramdisk.cpio.gz -o boot.img
./blobpack blob.HEADER newblob LNX boot.img
zip -r imagename.zip blob MET* system // whatever the syntax was.
NOTE: I did this on a native 64 bit ubuntu LTS 10.04 box.
Unless I typo'd up there, that 'should' work. If it does boot, then first thing, take a look at settings, and kernel info so you can verify that you're running the kernel you desired (hopefully you renamed it in Makefile the first 4-5 lines).
Solved
Ok, got it working!!! Problem was bad crosscompiler :-( Modules I crosscompiled worked fine, so I ruled crosscompiler out :-/ Looks like I was too quick in judgement :-( Now I have kernel recompiled with original settings and evne the modified one and it still works and boot. Now I'm going to play with new features I got! Thanks a lot for all help!!!
Just for the record, crosscompiler I was originally using was codesourcery 2011.03 and to make it work I switched to official crosscompiler from NDK. Rest of the commands was Ok, I was just suspecting wrong step as I was quite familiar with kernel building and quite unfamiliar with the blob stuff :-(
Congrats!
For some reason I avoid the codesourcery stuff and stick with either the prebuilt toolchains or else just build my own from gnu source.
Anyway, glad you figured it out.
I have been following a few different instructions for the tools and was concentrated on just learning to rebuild a kernel on my own setup - Ubuntu 11.10. I only installed Ubuntu since it was the distro mostly referenced in the tutorials. I've also tried a couple different tool chains, some work, some don't.
I then find an existing *.zip CWM flashable kernel to work with, usually trying to use one I've successfully ran before, and unzip it. This gives 2 folders and a blob file. Whenever I run bootunpack on the blob I only get a resultant blob.LNX file and, so far never any blob.HEADER file. I understood that the blob.LNX was the same as boot.img from reading through and use dsixda's kitchen to split up the .LNX file I've renamed to boot.img. I then replace the zImage with the one I've just built and repack to boot.img in the kitchen. Then I move that boot.img back to unzipped kernel directory and rename to blob.LNX and run bootpack with blob as output and just ignore the .HEADER part. I then rezip the 2 folders (after replacing any modules in there) and blob into a new zip file and reflash in CWM. If it was based on a kernel I've booted before then it usually works without any problems. I can replace text in the updater-script, if I want and am just reusing the initramfs from the original zip. I have signature verification turned off in CWM, so that doesn't choke it. I need to read more about building initramfs before I do it. So far, this works for me, but I haven't really done any modification to the source, other than rebuilding it with my running config.
sidneyk said:
I have been following a few different instructions for the tools and was concentrated on just learning to rebuild a kernel on my own setup - Ubuntu 11.10. I only installed Ubuntu since it was the distro mostly referenced in the tutorials. I've also tried a couple different tool chains, some work, some don't.
I then find an existing *.zip CWM flashable kernel to work with, usually trying to use one I've successfully ran before, and unzip it. This gives 2 folders and a blob file. Whenever I run bootunpack on the blob I only get a resultant blob.LNX file and, so far never any blob.HEADER file. I understood that the blob.LNX was the same as boot.img from reading through and use dsixda's kitchen to split up the .LNX file I've renamed to boot.img. I then replace the zImage with the one I've just built and repack to boot.img in the kitchen. Then I move that boot.img back to unzipped kernel directory and rename to blob.LNX and run bootpack with blob as output and just ignore the .HEADER part. I then rezip the 2 folders (after replacing any modules in there) and blob into a new zip file and reflash in CWM. If it was based on a kernel I've booted before then it usually works without any problems. I can replace text in the updater-script, if I want and am just reusing the initramfs from the original zip. I have signature verification turned off in CWM, so that doesn't choke it. I need to read more about building initramfs before I do it. So far, this works for me, but I haven't really done any modification to the source, other than rebuilding it with my running config.
Click to expand...
Click to collapse
The architecture really seems to make a big difference in some configurations.
I have one native linux box with 64 bit 10.04 LTS on it, and it always behaves as well as possible, so I did this blob/boot/tools work on it, and it went as it should (creating HEADER and LNX) files, etc.
Then in addition I use several linux distros in VMs, one of them being more like yours, an 11.10 distro with just the androidSDK and all the build tools, prebuilt chains, etc. That will do exactly as you said. I actually built those blobtools/boottools from Koush's git, and they don't work correctly in that one environment. What is different to make that happen? I'm just guessing that something important like the native x86_64 gcc world is different enough to foul things up. It really doesn't matter. Once I got the tools working on the native box, I just transferred them to the other boxes including 11.10 and they work fine.
If you're using 64 bit and would like them I can probably stick them into a .tar.bz2 or whatever and stick up a link to them, or maybe if you can find working binaries to download, you might get those working. Once the blobunpack is returning only the .LNX file, you've pretty well had it as far as progress.
Good luck
hachamacha said:
The architecture really seems to make a big difference in some configurations.
I have one native linux box with 64 bit 10.04 LTS on it, and it always behaves as well as possible, so I did this blob/boot/tools work on it, and it went as it should (creating HEADER and LNX) files, etc.
Then in addition I use several linux distros in VMs, one of them being more like yours, an 11.10 distro with just the androidSDK and all the build tools, prebuilt chains, etc. That will do exactly as you said. I actually built those blobtools/boottools from Koush's git, and they don't work correctly in that one environment. What is different to make that happen? I'm just guessing that something important like the native x86_64 gcc world is different enough to foul things up. It really doesn't matter. Once I got the tools working on the native box, I just transferred them to the other boxes including 11.10 and they work fine.
If you're using 64 bit and would like them I can probably stick them into a .tar.bz2 or whatever and stick up a link to them, or maybe if you can find working binaries to download, you might get those working. Once the blobunpack is returning only the .LNX file, you've pretty well had it as far as progress.
Good luck
Click to expand...
Click to collapse
If by 'native' you mean a hard disk install as opposed to a VM install, then that's where I'm at. I have Ubuntu 11.10 x86_64 installed to a separate partition. I have the recommended stuff installed including the ia32 libs, but I never see a blob.HEADER file with either kernel.zips or ROM zips. I can unpack and repack kernels without the HEADER though and they boot just fine.
But, yes, if you don't mind posting a link with your files I'll give them a try sometime. Thanks.
Ok here are the facts. I have configure the environment for building android from source in Ubuntu 12.04. I've downloaded the kernel source code and platform source code for my phone. I've followed the instructions and managed to compile zImage. Now this is where the problems begin. I've read on the forums and all over the net A LOT about this. I know that I need correct initramfs to make ramdisk.gz or something like this, and together with zImage, I can then build boot.img, which can be flashed on my phone. First thing every where I can read that I should pull (with dd command) original boot.img from my phone to get initramfs from there, and then correct those initramfs, to make kernel insecure. Problem is, I can't do this cause my phone is not rooted and there is no way to root it.
So my question here is is there any way to build (compile) an insecure kernel? Cause the reason I want such kernel is to root my phone after that.
Please help me!
EDIT: I also have original firmware in .tar file, which includes next images: cache.img.md5, hidden.img.md5, kernel.bin.md5, modem.bin.md5, system.img.md5. Can I use this in anyway to get the files I need?
qzem said:
Ok here are the facts. I have configure the environment for building android from source in Ubuntu 12.04. I've downloaded the kernel source code and platform source code for my phone. I've followed the instructions and managed to compile zImage. Now this is where the problems begin. I've read on the forums and all over the net A LOT about this. I know that I need correct initramfs to make ramdisk.gz or something like this, and together with zImage, I can then build boot.img, which can be flashed on my phone. First thing every where I can read that I should pull (with dd command) original boot.img from my phone to get initramfs from there, and then correct those initramfs, to make kernel insecure. Problem is, I can't do this cause my phone is not rooted and there is no way to root it.
So my question here is is there any way to build (compile) an insecure kernel? Cause the reason I want such kernel is to root my phone after that.
Please help me!
EDIT: I also have original firmware in .tar file, which includes next images: cache.img.md5, hidden.img.md5, kernel.bin.md5, modem.bin.md5, system.img.md5. Can I use this in anyway to get the files I need?
Click to expand...
Click to collapse
The tar has no boot.img that's weird. Have you tried renaming the kernel.img to boot and extracting to see if it's in their? That's what I do with the system.img I just rename it to data and take it to the dsixda kitchen tool and let it extract. Works fine for that I have not messed with kernels to much but I don't see how an unsecured kernel will help you get root? Or how you can push it without root?
Sent from my ADR6425LVW using XDA
sknight13602 said:
The tar has no boot.img that's weird. Have you tried renaming the kernel.img to boot and extracting to see if it's in their? That's what I do with the system.img I just rename it to data and take it to the dsixda kitchen tool and let it extract. Works fine for that I have not messed with kernels to much but I don't see how an unsecured kernel will help you get root? Or how you can push it without root?
Sent from my ADR6425LVW using XDA
Click to expand...
Click to collapse
That was the first thing I've tried,and it doesn't work. I think it is becaus it is in bin format and not img. As far as I've learnt here the phone with insecure kernel can be rooted with tools like superoneclick.
Sent from my GT-I9070 using XDA
Is it possible to convert .bin.md5 to img? Do I have to decrypt it first?
Ok first issue is solved now here is new problem.
For SGS2 the command for making a boot.img looks like this:
Code:
mkbootimg-sg2x --kernel zImage --ramdisk ramdisk.gz --cmdline "androidboot.hardware=qcom msm_watchdog.appsbark=0 msm_watchdog.enable=1 loglevel=4" -o boot.img --base 0x40400000 --pagesize 2048
How does it look for our phone, or how can I find out what needs to be written for cmdline, base and page size?
qzem said:
Ok first issue is solved now here is new problem.
For SGS2 the command for making a boot.img looks like this:
Code:
mkbootimg-sg2x --kernel zImage --ramdisk ramdisk.gz --cmdline "androidboot.hardware=qcom msm_watchdog.appsbark=0 msm_watchdog.enable=1 loglevel=4" -o boot.img --base 0x40400000 --pagesize 2048
How does it look for our phone, or how can I find out what needs to be written for cmdline, base and page size?
Click to expand...
Click to collapse
Well I have an HTC Evo 4g and a HTC Rezound and a HTC Thunderbolt and all three are3 different. What do you have? google make boot.img for... Their is almost always info out their just can be hard to find sometimes.
I have Samsung Galaxy S I9070 Advance.
Sent from my GT-I9070 using XDA
qzem said:
I have Samsung Galaxy S I9070 Advance.
Sent from my GT-I9070 using XDA
Click to expand...
Click to collapse
I have only worked with HTC devices I really couldn't tell ya what you use to compile it for that device. I'm guessing your phone has little to no dev support. But if usually the android dev page has stuff on it where you pull the source from.
Sent from my ADR6425LVW using XDA
HTC releases it source code and has a how to for it but I'm not sure for Samsung.
Sent from my ADR6425LVW using XDA
---------- Post added at 12:37 AM ---------- Previous post was at 12:32 AM ----------
I went to the samsung page and their open source page says that if your device was relased before 1 may 2010 that the owners manual will provide the website you need to get source code from. I would start there.
---------- Post added at 01:20 AM ---------- Previous post was at 12:37 AM ----------
qzem said:
Ok first issue is solved now here is new problem.
For SGS2 the command for making a boot.img looks like this:
Code:
mkbootimg-sg2x --kernel zImage --ramdisk ramdisk.gz --cmdline "androidboot.hardware=qcom msm_watchdog.appsbark=0 msm_watchdog.enable=1 loglevel=4" -o boot.img --base 0x40400000 --pagesize 2048
How does it look for our phone, or how can I find out what needs to be written for cmdline, base and page size?
Click to expand...
Click to collapse
mkbootimg-sgs --kernel zImage -ramdisk.gz
androidboot.hardware=qcom "this describes the processor in this case a snapdragon similar to the Evo."
msm_watchdog.appsbark=0 "this is for a hardware fuction android uses in case of problems with proccessing info i.e. the phone gets stuck and freezes the watchdog will restart the phone to keep it from ruining any of the hardware. I have no idea what the levels are"
msm_watchdog.enable=1 "this is the same as above but... 0 to disable watchdog and 1 enables it I'm not sure about much else with this command"
oglevel=4" "I think this is related to logging but not sure"
{-o boot.img --base 0x40400000 --pagesize 2048 } this part is striclty to be different for each device.
base 0x40400000 is the hex decimal size of the zImage "this is your base address. here is a link to find yours for your phone"
http://lyncd.com/2011/03/android-kernel-mkbootimg-base/
pagesize 2048 "refers to the size of the kernel"
% mkbootimg --cmdline 'no_console_suspend=1 console=null' --kernel boot.img-kernel --ramdisk ramdisk-new.gz -o boot-new.img "this is a generic command to compile and probably wont work unless you place your base address and page size in the command I really hope this help you out.
this link might prove helpful for you.
http://rootzwiki.com/topic/8824-howto-compile-your-own-kernel-v-01/
I also recomened that even though you dont have recovery you can always adb pull your system place su in you bin and xbin place the su app in system app and push the system and see if you get root but i doubt as their are files in the kernel to edit to obtain full root. worth a shot though. I would be alot more help if your had a recovery cus I could make you a root rom and kernel but you would have no way to flash it.
Thank you very much! I will use your information in near future, when I will try to make a custom rom for my device. I've managed to root it finally !
qzem said:
Thank you very much! I will use your information in near future, when I will try to make a custom rom for my device. I've managed to root it finally !
Click to expand...
Click to collapse
Glad to hear man. small steps lol that how I learned and I still am.
Sent from my ADR6425LVW using XDA
sknight13602 said:
Glad to hear man. small steps lol that how I learned and I still am.
Sent from my ADR6425LVW using XDA
Click to expand...
Click to collapse
Thats right. Step by step,like in preschool, lol
Sent from my GT-I9070 using XDA
Okay, so I have created and modified my own kernel name BionicSheep and have done couple releases (check my signature for link). My main question is how do I create a flashable zip with a boot.img I have asked a few people and they told me to use the kernel kitchen or google, but this is the only problem I haven't been able to solve after googling daily for the past 4 days. I figured I would ask here.
The reason I would like a boot.img is because I know in order to modify the kernelsplash with my own logo, I need to be able to unpack the bootimage to get the ramdisk and modify an rle file. The problem is I have no idea how to first make this bootimage. I understand to make the bootimage you need a the zImage (kernel binary) and the ramdisk. I have the zImage but I don't know how to make/get a ramdisk.
Currently I have been using this described method of packing my kernel into a flashable zip. I am pretty sure it just packs my modules and zImage into koush's AnyKernel. Thanks for any help, I need it.
Also try my kernel out and leave feedback if you are so inclined! It really is appreciated
In linux:
http://forum.xda-developers.com/showthread.php?t=1477845
In windows:
http://technopyrate.blogspot.pt/2013/04/how-to-edit-android-bootimg-in-windows.html
zamcum said:
In linux:
http://forum.xda-developers.com/showthread.php?t=1477845
In windows:
http://technopyrate.blogspot.pt/2013/04/how-to-edit-android-bootimg-in-windows.html
Click to expand...
Click to collapse
This is helpful for unpacking modifying and repacking, but I dont have a boot.img to unpack. Like I said, all I have is a zImage, i have no clue how to get a ramdisk. Can I just use one from another kernel or will that cause conflicts? Thanks for the help
aeppacher said:
This is helpful for unpacking modifying and repacking, but I dont have a boot.img to unpack. Like I said, all I have is a zImage, i have no clue how to get a ramdisk. Can I just use one from another kernel or will that cause conflicts? Thanks for the help
Click to expand...
Click to collapse
You can have it, in a stock rom:
Download a stock rom for your phone, open .tar.md5 file with winrar, extract boot.img and unpack it.
Inside you have, ramdisdk and zimage, with another name (boot.img-kernel)
rename your zimage, to boot.img-kernel, edit ramdisk if you want
repalce original boot.img-kernel with yours
and repack
Rename boot-new.img to boot.img
Enjoy
EDIT: To make a flashable Odin file, in Linux:
tar -H ustar -c boot.img > YOURKERNEL.tar
md5sum -t YOURKERNEL.tar >> YOURKERNEL.tar
mv YOURKERNEL.tar YOURKERNEL.tar.md5
That's not necessary. You can make it so that your zImage replaces the zImage inside the boot.img and the initlogo.rle at the same time.
CNexus said:
That's not necessary. You can make it so that your zImage replaces the zImage inside the boot.img and the initlogo.rle at the same time.
Click to expand...
Click to collapse
Which step is not necessary? My biggest problem here was I didn't know i could take any old boot.img to make mine
zamcum said:
You can have it, in a stock rom:
Download a stock rom for your phone, open .tar.md5 file with winrar, extract boot.img and unpack it.
Inside you have, ramdisdk and zimage, with another name (boot.img-kernel)
rename your zimage, to boot.img-kernel, edit ramdisk if you want
repalce original boot.img-kernel with yours
and repack
Rename boot-new.img to boot.img
Enjoy
EDIT: To make a flashable Odin file, in Linux:
tar -H ustar -c boot.img > YOURKERNEL.tar
md5sum -t YOURKERNEL.tar >> YOURKERNEL.tar
mv YOURKERNEL.tar YOURKERNEL.tar.md5
Click to expand...
Click to collapse
hahaha so I think that worked, I have a bootimage with my kernel!! hurrah, now how do I turn it into a flashable zip? Last question I promise
aeppacher said:
hahaha so I think that worked, I have a bootimage with my kernel!! hurrah, now how do I turn it into a flashable zip? Last question I promise
Click to expand...
Click to collapse
the easiest way, is to download a custom kernel for your phone, open the zip with winrar and replace the bott.img by your boot.img
It is important that the exact custom kernel of your phone, so that, there are no incompatibilities in the installation script
zamcum said:
the easiest way, is to download a custom kernel for your phone, open the zip with winrar and replace the bott.img by your boot.img
It is important that the exact custom kernel of your phone, so that, there are no incompatibilities in the installation script
Click to expand...
Click to collapse
Hmmm, I tried this and it didn't boot. :/ then I booted to recovery restarted, and then it booted with my boot splash (yay) went to apps updating and then just got stuck at starting apps. I couldn't get it to fully boot :/
Any ideas whats up
EDIT: I can't thank you since I only get 8 per day, sorry I do appreciate it though
aeppacher said:
Hmmm, I tried this and it didn't boot. :/ then I booted to recovery restarted, and then it booted with my boot splash (yay) went to apps updating and then just got stuck at starting apps. I couldn't get it to fully boot :/
Any ideas whats up
EDIT: I can't thank you since I only get 8 per day, sorry I do appreciate it though
Click to expand...
Click to collapse
If your kernel does not boot, is because it has a problem. It is normal to happen in the first kernel.
The process I use, is what is above. Sorry, II can not help more.
Do not worry about the gratefulness. The important thing is to help
I have a question along the same lines as this thread and I've read all over the place and can't find anything. How do you open a boot.img file to be able to replace the zimage
---------- Post added at 09:21 AM ---------- Previous post was at 08:45 AM ----------
I have a question along the same lines as this thread and I've read all over the place and can't find anything. How do you open a boot.img file to be able to replace the zimage
EDIT: i fixed this
Problem solved, figured I would post a solution:
here are the tools: https://dl.dropboxusercontent.com/u/106865720/bootimg_tools.zip
extract them into any old folder. You also need to have perl installed (just google it)
1. You need to take your built boot.img (from a rom running your kernel successfully) and drag it into the folder.
2. Open up terminal and navigate to the directory with the tools and boot.img
3. First you need to split the boot image into its 2 parts (the ramdisk and the kernel zImage)
Code:
perl split_bootimg.pl boot.img
The "boot.img" part is just the name of your boot.img (I am assuming yours is called boot.img but you can change it as needed)
4. Okay what should have happened is the boot.img should have split into a 'boot.img-ramdisk.gz' and a 'boot.img-kernel' file. The first is a specially compressed ramdisk and the second is the zImage for the kernel
5. Now you need to unpack the ramdisk so that you can modify it. BE CAREFUL AND MODIFY ONLY IF NEEDED Use this code:
Code:
perl unpack_ramdisk boot.img-ramdisk.gz ramdisk
the "boot-img-ramdisk.gz" is the name of the ramdisk, you can change this as needed but it should be named that by default
6.Okay so what should have happened is a folder ramdisk was created (this is the unpacked ramdisk which you need).
7.Okay go back to your directory and delete your boot.img, boot.img-kernel and boot.img-ramdisk.gz files (you no longer need them)
8. Now you need to repack the ramdisk folder you modified so you can rebuild the boot.img use the following:
Code:
perl repack_ramdisk ramdisk boot.img-ramdisk.cpio.gz
9. This will take the 'ramdisk' folder and pack it and name it 'boot.img-ramdisk.cpio.gz'
11. Find your built zImage for your compiled kernel and copy it into this folder with the tools. Rename it as "boot.img-kernel"
10. Sweet now you need to pack the new ramdisk file and your kernel you just stuck in into a new boot.img (this part took me forever to figure out)
11. Here is the code to rebuild
Code:
mkbootimg --kernel boot.img-kernel --ramdisk boot.img-ramdisk.cpio.gz --cmdline 'console=null androidboot.hardware=qcom user_debug=31 zcache' --base 0x80200000 --pagesize 2048 --ramdiskaddr 0x81500000 -o boot.img
12. This should create a file named boot.img in the directory that will have your kernel and modified ramdisk (whoo)
Any further help can be directed to this thread or PMing me!
aeppacher said:
11. Here is the code to rebuild
Code:
mkbootimg --kernel boot.img-kernel --ramdisk boot.img-ramdisk.cpio.gz --cmdline 'console=null androidboot.hardware=qcom user_debug=31 zcache' --base 0x80200000 --pagesize 2048 --ramdiskaddr 0x81500000 -o boot.img
Any further help can be directed to this thread or PMing me!
Click to expand...
Click to collapse
While executing above code I am getting : -bash: mkbootimg: command not found. Whether the mkbootimg file is exist there,
could you please help
mukulsoni said:
While executing above code I am getting : -bash: mkbootimg: command not found. Whether the mkbootimg file is exist there,
could you please help
Click to expand...
Click to collapse
Are you doing this is the same directory as the mkbootimg file? Otherwise you have to path it
aeppacher said:
Are you doing this is the same directory as the mkbootimg file? Otherwise you have to path it
Click to expand...
Click to collapse
Yes I am doing in same path. Its unpacking correctly, but showing error while packing the boot
Hmmm perhaps a bad download?
aeppacher said:
Hmmm perhaps a bad download?
Click to expand...
Click to collapse
but unpacking is fine, My downloaded zip file is in 66.4 Kb size. any way could you please try to compile the attached HP.zip into boot.img in your system. TIA
Edit: sorry downloaded file size is 290kb. please send me the final compiled boot.img file. Thanks so much
mukulsoni said:
but unpacking is fine, My downloaded zip file is in 66.4 Kb size. any way could you please try to compile the attached HP.zip into boot.img in your system. TIA
Edit: sorry downloaded file size is 290kb. please send me the final compiled boot.img file. Thanks so much
Click to expand...
Click to collapse
What version of linux are you running? Ubuntu? what version number, and is it 32-bit or 64-bit
EDIT: try install 32bit packages "sudo apt-get install ia32-libs"
aeppacher said:
What version of linux are you running? Ubuntu? what version number, and is it 32-bit or 64-bit
EDIT: try install 32bit packages "sudo apt-get install ia32-libs"
Click to expand...
Click to collapse
I am running these scripts on window7 using Cygwin64. I guess these script should run on window 7 64 bit too.... please guide
mukulsoni said:
I am running these scripts on window7 using Cygwin64. I guess these script should run on window 7 64 bit too.... please guide
Click to expand...
Click to collapse
I have no clue how to fix that. Mkbootimg is for 32 bit instruction so you need the appropriate libraries. No clue how to do that in windows
First the disclaimer:
I am not responsible for what you do to your phone. Following these directions could cause you to brick, locust plague, or end of times. You assume ALL responsibility for what you do with this information.
Now, on to the fun stuff. I take *NO* credit for this information at all. I am a student of people far more knowledgeable about these things. However, I've managed to take what I've learned and apply it in really fun ways. For example, I have a script that takes an OTA and builds a new full ODIN image from it...with all partitions fully signed except system. Many people have asked me to "repackage it" with various requests. This tutorial is going to show how to do that.
Requirements:
o) You will need to install Cygwin. A default installation should suffice for this exercise.
o) You will need one of the ODIN TAR Full Rooted Restore images. They are gzipped to make them smaller.
Process:
o) You need to unpack the files stored inside the gzip. 7 Zip is a handy program for doing that. We need the individual partition files extracted to a work directory that can be accessed from a Cygwin command prompt. I create a C:\Android\S4_GPE directory for my own image creation tasks.
o) Once the individual files are unpacked, we need to repack them. Open a Cygwin command prompt and navigate to the directory you extracted the files to. In my case, that would be cd c:/Android/S4_GPE
Follow the directions below to repack the files as needed. I give a few examples here to show you the basics of how it's done. Basically you run each command in your Cygwin command prompt. Or you can add them to an SH script and run it that way. Whatever you feel most comfortable with.
The output of these commands is an ODIN flashable file that will install what you choose.
BOOT
filename=boot
tar -H ustar -c boot.img > $filename.tar
md5sum -t $filename.tar >> $filename.tar
mv $filename.tar $filename.tar.md5
RECOVERY
filename=recovery
tar -H ustar -c recovery.img > $filename.tar
md5sum -t $filename.tar >> $filename.tar
mv $filename.tar $filename.tar.md5
MODEM
filename=modem
tar -H ustar -c NON-HLOS.bin modem.bin > $filename.tar
md5sum -t $filename.tar >> $filename.tar
mv $filename.tar $filename.tar.md5
FULL ODIN IMAGE
filename=I9505GUEUB_FULL_ROOTED
tar -H ustar -c boot.img recovery.img NON-HLOS.bin modem.bin system.img.ext4 > $filename.tar
md5sum -t $filename.tar >> $filename.tar
mv $filename.tar $filename.tar.md5
gzip $filename.tar.md5
Those are some of the common ones. What if I wanted a "semi-full rooted image"? For instance, without the modems? You just modify this line:
tar -H ustar -c boot.img recovery.img NON-HLOS.bin modem.bin system.img.ext4 > $filename.tar
so that it becomes:
tar -H ustar -c boot.img recovery.img system.img.ext4 > $filename.tar
Of if you don't want recovery, either, and just want boot and system:
tar -H ustar -c boot.img system.img.ext4 > $filename.tar
And the rest stays the same. I really hope this helps people. I will update this post to clarify anything that's confusing and will try to help people in this thread to create whatever they need. Again, you take responsibility for anything you create using these instructions and flash to your phone.
whats the command to create a system dump to an odin compatible system.img file? been a while. i forget
This is how I do it in my script:
adb shell "su -c 'cd /sdcard; dd if=/dev/block/platform/msm_sdcc.1/by-name/system of=/sdcard/system.img.ext4'"
adb pull /sdcard/system.img.ext4
adb shell rm /sdcard/system.img.ext4
SamuriHL said:
This is how I do it in my script:
adb shell "su -c 'cd /sdcard; dd if=/dev/block/platform/msm_sdcc.1/by-name/system of=/sdcard/system.img.ext4'"
adb pull /sdcard/system.img.ext4
adb shell rm /sdcard/system.img.ext4
Click to expand...
Click to collapse
I'm a relative noob and just learning as much as I can and this is alot of great info. I am able to pull system dump and pull recovery.img from my but when I create an odin flashable recovery image (for back-up purposes) it fails auth. Is there a way to pull a signed recovery image from system? Thanks.
No. When you dd extract a partition it adds padding to it which messes with the signature. I create a signed recovery img file by patching the boot img with the recovery-from-boot.p in the OTA update. That's a lot more involved than what's in this tutorial, however.
SamuriHL said:
No. When you dd extract a partition it adds padding to it which messes with the signature. I create a signed recovery img file by patching the boot img with the recovery-from-boot.p in the OTA update. That's a lot more involved than what's in this tutorial, however.
Click to expand...
Click to collapse
Got it, thank you. I found the thread on hexediting the partition file. I will see if that works.
muniz_ri said:
Got it, thank you. I found the thread on hexediting the partition file. I will see if that works.
Click to expand...
Click to collapse
My initial results weren't very conclusive on that. I tried it with the NON-HLOS.bin file just to see if I could make it consistent with the one I create by patching, and the results were not good. There's no way to know exactly how long to make the cut. It seems like all you do is remove the trailing 00's when hexediting, but, I can tell you that's not enough to make it match. I've got more research to do on this as it would be extremely useful to be able to edit the dd extracted files to make them match the signed files. So far, that doesn't seem possible.
SamuriHL said:
My initial results weren't very conclusive on that. I tried it with the NON-HLOS.bin file just to see if I could make it consistent with the one I create by patching, and the results were not good. There's no way to know exactly how long to make the cut. It seems like all you do is remove the trailing 00's when hexediting, but, I can tell you that's not enough to make it match. I've got more research to do on this as it would be extremely useful to be able to edit the dd extracted files to make them match the signed files. So far, that doesn't seem possible.
Click to expand...
Click to collapse
That's too bad, I was also hoping removing the trailing zeros would work. Can you point me to a tutorial, etc where i can learn how to patch using the OTA files? thanks again.
muniz_ri said:
That's too bad, I was also hoping removing the trailing zeros would work. Can you point me to a tutorial, etc where i can learn how to patch using the OTA files? thanks again.
Click to expand...
Click to collapse
It's not quite as simple as that. There isn't a tutorial on it. I learned what I know from Matt Groff. It started with a thread here:
http://forum.xda-developers.com/showthread.php?t=1702233
But that thread isn't going to teach nearly enough to learn how to do this. It involves parsing the update scripts from the OTA to find the command they use to patch the actual partition and then converting that to a command to patch the file. So if you look at this command from install-recovery.sh:
applypatch EMMC:/dev/block/platform/msm_sdcc.1/by-name/boot:8036608:1ad324cf48a6e19fd402603477cd0ed8472ed863 EMMC:/dev/block/platform/msm_sdcc.1/by-name/recovery f4579fa7099942ec2f214cff81014b8e8b1a550f 8632576 1ad324cf48a6e19fd402603477cd0ed8472ed863:/system/recovery-from-boot.p
What that's doing is taking 8036608 bytes from the boot partition, ensuring it has a sha1 hash of 1ad324cf48a6e19fd402603477cd0ed8472ed863, patching it with the contents of the recovery-from-boot.p file, and then writing it to the recovery partition.
Each time an OTA comes out for our phones, I create signed recovery, modem, and non-hlos files using this process. Then I use the process outlined in this tutorial to create the ODIN tar md5 files that I post.
SamuriHL said:
It's not quite as simple as that. There isn't a tutorial on it. I learned what I know from Matt Groff. It started with a thread here:
http://forum.xda-developers.com/showthread.php?t=1702233
But that thread isn't going to teach nearly enough to learn how to do this. It involves parsing the update scripts from the OTA to find the command they use to patch the actual partition and then converting that to a command to patch the file. So if you look at this command from install-recovery.sh:
applypatch EMMC:/dev/block/platform/msm_sdcc.1/by-name/boot:8036608:1ad324cf48a6e19fd402603477cd0ed8472ed863 EMMC:/dev/block/platform/msm_sdcc.1/by-name/recovery f4579fa7099942ec2f214cff81014b8e8b1a550f 8632576 1ad324cf48a6e19fd402603477cd0ed8472ed863:/system/recovery-from-boot.p
What that's doing is taking 8036608 bytes from the boot partition, ensuring it has a sha1 hash of 1ad324cf48a6e19fd402603477cd0ed8472ed863, patching it with the contents of the recovery-from-boot.p file, and then writing it to the recovery partition.
Each time an OTA comes out for our phones, I create signed recovery, modem, and non-hlos files using this process. Then I use the process outlined in this tutorial to create the ODIN tar md5 files that I post.
Click to expand...
Click to collapse
Success! Thanks so much, just created my first signed odin image!
Theres two more ways the get signed images. One is using dd if=of with the right bs and count. For example, I extracted the stock signed PIT file for the S4 using
Code:
su
dd if=/dev/block/mmcblk0 of=/sdcard/sch1545.pit bs=8 count=580 skip=2176
you can see the thread and md5 comparisonhere The other method is hexediting but it was easier on 4.2.2 but still very doable on 4.3. You have to know what signatures look like though. Hexediting can also be useful for manually extracting the zimage and ramdisk from a boot.img
Sent from my SCH-I545 using XDA Premium 4 mobile app
Surge1223 said:
Theres two more ways the get signed images. One is using dd if=of with the right bs and count. For example, I extracted the stock signed PIT file for the S4 using
Code:
su
dd if=/dev/block/mmcblk0 of=/sdcard/sch1545.pit bs=8 count=580 skip=2176
you can see the thread and md5 comparisonhere The other method is hexediting but it was easier on 4.2.2 but still very doable on 4.3. You have to know what signatures look like though. Hexediting can also be useful for manually extracting the zimage and ramdisk from a boot.img
Sent from my SCH-I545 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
I'm also going to play around more with hexediting, if it will work it seems much more straightforward. Thanks again for all of the good info!
SamuriHL said:
My initial results weren't very conclusive on that. I tried it with the NON-HLOS.bin file just to see if I could make it consistent with the one I create by patching, and the results were not good. There's no way to know exactly how long to make the cut. It seems like all you do is remove the trailing 00's when hexediting, but, I can tell you that's not enough to make it match. I've got more research to do on this as it would be extremely useful to be able to edit the dd extracted files to make them match the signed files. So far, that doesn't seem possible.
Click to expand...
Click to collapse
Sam, id be glad to try hexediting the NON-HLOS.bin file and then send you the md5.
Sent from my SCH-I545 using XDA Premium 4 mobile app
Surge1223 said:
Sam, id be glad to try hexediting the NON-HLOS.bin file and then send you the md5.
Sent from my SCH-I545 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
I'll pm one to you tomorrow. I definitely am curious if you're able to md5 hash it correctly.
Pm sent. Good luck.
Sent from my SM-P600 using Tapatalk 4
SamuriHL said:
Pm sent. Good luck.
Sent from my SM-P600 using Tapatalk 4
Click to expand...
Click to collapse
How do you limit the number of bytes extracted for the mdm.bin to match the updater script's parameters? Thank you.
muniz_ri said:
How do you limit the number of bytes extracted for the mdm.bin to match the updater script's parameters? Thank you.
Click to expand...
Click to collapse
I didn't. The first signed modem bin I made was done by looking at the size in the updater script and using cygwin to copy that many bytes to a new file. From then on I just patched the previous version's modem bin and NON-HLOS bin files.
Sent from my SM-P600 using Tapatalk 4
SamuriHL said:
I didn't. The first signed modem bin I made was done by looking at the size in the updater script and using cygwin to copy that many bytes to a new file. From then on I just patched the previous version's modem bin and NON-HLOS bin files.
Sent from my SM-P600 using Tapatalk 4
Click to expand...
Click to collapse
First time quickly hexediting it I got
md5: 9616e85b765e0365e8ccd57550a715b8
Surge1223 said:
First time quickly hexediting it I got
md5: 9616e85b765e0365e8ccd57550a715b8
Click to expand...
Click to collapse
Which doesn't match the digital signature. This is what I was afraid of and what I was running into.
Sent from my SM-P600 using Tapatalk 4
SamuriHL said:
Which doesn't match the digital signature. This is what I was afraid of and what I was running into.
Sent from my SM-P600 using Tapatalk 4
Click to expand...
Click to collapse
what are you comparing the sig to?
Sent from my SCH-I545 using XDA Premium 4 mobile app