FORUMS

[TOOL] Android Image Kitchen - Unpack/Repack Kernel Ramdisk [Win/Android/Linux/Mac]

14,049 posts
Thanks Meter: 31,363
 
By osm0sis, Recognized Developer / Recognized Contributor on 30th December 2012, 03:55 PM
Post Reply Email Thread
5th January 2013, 06:54 PM |#11  
osm0sis's Avatar
OP Recognized Developer / Recognized Contributor
Flag Halifax
Thanks Meter: 31,363
 
Donate to Me
More
Quote:
Originally Posted by Goatshocker

Hm, doesnt seem to work for me. I unpacked boot.img, repacked it (didnt change anything) and then flashed it with fastboot - resulted in a bootloop.
The boot.img before unpack/repack boots fine.

Interesting. Worked for both dancer_69 and myself. Device info and image in PM please.
6th January 2013, 04:06 AM |#12  
ZeRo2o9's Avatar
Senior Member
Flag Central Cali
Thanks Meter: 310
 
More
Yes i confirm it worked for me on htc vivid jellybean

Sent from my HTC Vivid 4G
The Following User Says Thank You to ZeRo2o9 For This Useful Post: [ View ] Gift ZeRo2o9 Ad-Free
6th January 2013, 01:24 PM |#13  
Quote:
Originally Posted by osm0sis

Interesting. Worked for both dancer_69 and myself. Device info and image in PM please.

Hi Folks....

The boot loop maybe because ueventd /watchdogd in the sbin directory haven't been created, they are (normally) symlinked back to ../init, obviously windows doesn't support symlinks. a work around when using windows would be to copy-rename the /init to sbin/ueventd and sbin/watchdogd.

This is just "finger in the air" guessing but just something I've noticed
6th January 2013, 02:13 PM |#14  
osm0sis's Avatar
OP Recognized Developer / Recognized Contributor
Flag Halifax
Thanks Meter: 31,363
 
Donate to Me
More
Quote:
Originally Posted by trevd

Hi Folks....

The boot loop maybe because ueventd /watchdogd in the sbin directory haven't been created, they are (normally) symlinked back to ../init, obviously windows doesn't support symlinks. a work around when using windows would be to copy-rename the /init to sbin/ueventd and sbin/watchdogd.

This is just "finger in the air" guessing but just something I've noticed

No that doesn't seem to be the issue here, though I think that's what the issue was when I was using the gnuwin32 cpio. I was also worried about permissions being set correctly but I haven't seen any issues with that yet either. I just made sure of both by unpacking and repacking the maguro CWM recovery image then flashing it to my device, and both symlinks and permissions are restored correctly in the filesystem. What's going on with Goatshocker's One S is a bit more bizarre.

Oddly enough, even just recombining the original zImage and ramdisk from split_img doesn't work for him, meaning it's either unpackbootimg, or more likely mkbootimg at fault. All the commandline variables match for the original and built images (cmdline, pagesize, base), and I've tried the Cygwin executable and the native one you posted, so it's leading me to believe there is something different about how images must be packaged for the HTC One S. Another One S user that can confirm would be good though.

Edit: One S testing was done with Fusion v4 and CM stock from the latest Dark Jelly -
http://forum.xda-developers.com/show....php?t=1837630
http://forum.xda-developers.com/show....php?t=1848100
The Following User Says Thank You to osm0sis For This Useful Post: [ View ]
6th January 2013, 04:14 PM |#15  
I do know some htc boot images they have an additional 256 byte header which you have to strip off in linux you do that with dd, like so
Code:
dd if=htcsen.img of=htcstrip.img bs=256 skip=1
I've just done this with an HTC Sensation stock boot image and it unpacked alright after that..... not sure about repacking though

You can check if an additional header is present by opening the boot image in an hex editor, A standard boot image starts with the android magic, which is the byte sequence
Code:
41 4E 44 52 4F 49 44 21
This spells ANDROID! in ascii text. If it doesn't you can normally strip the additional header without any problems.

Looking at the various boot images in my htc sensation backups it seems my CM boot images don't have the special header..
HTC do have some specialness going on with the S-ON/OFF business etc but I'd just be speculating If I said anymore as my knowledge of the htc boot sequence is limited.
The Following 2 Users Say Thank You to trevd For This Useful Post: [ View ] Gift trevd Ad-Free
8th January 2013, 01:37 AM |#16  
osm0sis's Avatar
OP Recognized Developer / Recognized Contributor
Flag Halifax
Thanks Meter: 31,363
 
Donate to Me
More
Getting reports that HTC One X and One X+ are also not working, so it must be some kind of newer HTC thing. When I get a bit of free time I'll compare the custom kernels and recoveries for those devices and/or fire some PMs off to the kernel devs to see if there's anything special I should know and if there's a way I can fix it.
The Following User Says Thank You to osm0sis For This Useful Post: [ View ]
8th January 2013, 03:12 AM |#17  
Goatshocker's Avatar
Senior Member
Thanks Meter: 421
 
More
Well, "good" to hear its not just me who were having issues then
The Following User Says Thank You to Goatshocker For This Useful Post: [ View ] Gift Goatshocker Ad-Free
23rd January 2013, 04:07 AM |#18  
osm0sis's Avatar
OP Recognized Developer / Recognized Contributor
Flag Halifax
Thanks Meter: 31,363
 
Donate to Me
More
Was looking into this again today and found a nice build.sh on the One S Fusion Kernel github..

The mkbootimg command does have an extra parameter:

mkbootimg --kernel zImage --ramdisk ramdisk.cpio.gz --base 80400000 --ramdiskaddr 81800000 --cmdline console=ttyHSL0,115200,n8 -o boot.img

Not yet sure if that ramdiskaddr is the magic difference or not. That ramdiskaddr parameter doesn't even exist in any win32 compile I've seen of mkbootimg. I just downloaded a few images (the Dark Jelly ones we tested before) to hexedit and compare. I'll post again shortly on that.
The Following 2 Users Say Thank You to osm0sis For This Useful Post: [ View ]
23rd January 2013, 04:59 AM |#19  
osm0sis's Avatar
OP Recognized Developer / Recognized Contributor
Flag Halifax
Thanks Meter: 31,363
 
Donate to Me
More
Took a look with HxD and "ANDROID!" is present in all of them, so it's not the HTC header problem.

Since repacking the original ramdisk still wouldn't boot for the HTC One S in my tests with Goatshocker (which is crazy because it should all be exactly the same), I did just that with Fusion v3.2 and then ran a diff on the original and repack. Doing the same for a GN kernel produces zero differences, ie. the files are identical, but interestingly enough for the One S images there is a single difference, and it's in the header.

fv32-boot.xxd versus repack-boot.xxd:
Code:
0000000: 414e 4452 4f49 4421 0879 5100 0080 4080  [email protected]
0000010: b4a2 0200 0000 8081 0000 0000 0000 3081  ..............0.
0000020: 0001 4080 0008 0000 0000 0000 0000 0000  [email protected]
0000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000040: 636f 6e73 6f6c 653d 7474 7948 534c 302c  console=ttyHSL0,
0000050: 3131 3532 3030 2c6e 3800 0000 0000 0000  115200,n8.......
----
0000000: 414e 4452 4f49 4421 0879 5100 0080 4080  [email protected]
0000010: b4a2 0200 0000 4081 0000 0000 0000 3081  ......@.......0.
0000020: 0001 4080 0008 0000 0000 0000 0000 0000  [email protected]
0000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000040: 636f 6e73 6f6c 653d 7474 7948 534c 302c  console=ttyHSL0,
0000050: 3131 3532 3030 2c6e 3800 0000 0000 0000  115200,n8.......
Same change with the TWRP recovery images for the One S (ville) and One X (evita). So somehow I believe that's our problem with certain HTC devices... No idea why such a thing would occur. I looked into S-ON a bit and it seems that's controlled from the radio, and would prevent the image from being written, so it shouldn't have to do with that either. Perhaps it has to do with that extra ramdiskaddr parameter somehow affecting the header.

I could write an extra batch file that flips that byte as a workaround, but I'd prefer to actually figure out why it happens and fix that..
The Following User Says Thank You to osm0sis For This Useful Post: [ View ]
23rd January 2013, 09:20 PM |#20  
osm0sis's Avatar
OP Recognized Developer / Recognized Contributor
Flag Halifax
Thanks Meter: 31,363
 
Donate to Me
More
OP updated with the workaround zip, instructions in the 2nd post. Tested and working fully, many thanks to Goatshocker for the assistance.

Any ideas or leads on why this single byte difference would occur are welcome, but in the meantime the workaround should make this "universal" again.
The Following 3 Users Say Thank You to osm0sis For This Useful Post: [ View ]
28th January 2013, 07:44 AM |#21  
Senior Member
Thanks Meter: 25
 
More
First thank you for your nice work!

And it is possible to add support to samsung devices ( I have a Captivate i897 myself)? Tried some CM base Captivate kernels and it dosen't work.
Samsung devices are using particular kernel image layout perhaps, as well as various compress methods like bzip, lzo, etc as far as I know.

Semaphore thread for your reference. http://forum.xda-developers.com/show....php?t=1816087

P.S. Tool works without problem with Galaxy Nexus kernels~
The Following User Says Thank You to Fishmanzero For This Useful Post: [ View ] Gift Fishmanzero Ad-Free
Post Reply Subscribe to Thread

Tags
kernel, ramdisk, recovery, repack, unpack

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes