I am attempting to apply a new system.img file to an Android tablet and it always results in a soft brick/bootloop.
The tablet being used is a TerraPad 1004, running android 5.1.1 (MTK8735). I have been given special access to the image files by the manufacturer, who have provided everything I need to update the tablet using SP Flash Tool (5.164 on Windows 10). If I flash the files as they were provided it all works fine and the tablet boots up perfectly. If I unpack/mount/repack the system.img and then try flashing it I get stuck either on the boot screen or get the dead android image (only get this I make the system.img file too big when repacking it). Please note, despite unpacking/mounting/repacking I made no changes to the system image, so in theory it should be the same as the originally provided system.img file.
I am doing the unpack/mount/repack on Ubuntu 16.04 (64 bit - have tried 32 bit and 12.04) VM (using Virtual Box).
The commands I am using are:
Unpack: simg2img system.img system.raw
Mount: sudo mount -t ext4 -o loop system.raw system/
Repack: make_ext4fs -s -l 1617722231 -S file_contexts -a system newsystem.img /home/ubuntu/mhh/Terra1004/system
The file size specified for make_ext4fs has been arrived at via trial and error as all the means I have seen of calculating (e.g blocks x block size) result in a file that is significantly bigger then the original system.img file (resulting in dead android when flashed to tablet). The current size specified results in an image file that has the same number of blocks as the original file but is 24 bytes bigger than the original (this img results in getting stuck on the very first boot splash screen).
I have tried flashing the image via fastboot (fastboot flash system system.img) and get "FAILED (remote: failed to get download permission for partition 'system')".
I am working with the manufacturer to resolve this issue but I am getting very little back from them.
I am getting quite desperate to resolve this as my business relies on my ability to amend the system.img (and other files) to bespoke the tablet to my own product.
I am really at the limit of my understanding on what I am talking about when it comes to modding tablets - I do it as a necessity rather than a hobby, so please excuse any incorrectly used terminology.
All help/suggestions welcome. Please let me know if you need any further information.
Thanks in advance.
KGMARSCH said:
I am attempting to apply a new system.img file to an Android tablet and it always results in a soft brick/bootloop.
The tablet being used is a TerraPad 1004, running android 5.1.1 (MTK8735). I have been given special access to the image files by the manufacturer, who have provided everything I need to update the tablet using SP Flash Tool (5.164 on Windows 10). If I flash the files as they were provided it all works fine and the tablet boots up perfectly. If I unpack/mount/repack the system.img and then try flashing it I get stuck either on the boot screen or get the dead android image (only get this I make the system.img file too big when repacking it). Please note, despite unpacking/mounting/repacking I made no changes to the system image, so in theory it should be the same as the originally provided system.img file.
I am doing the unpack/mount/repack on Ubuntu 16.04 (64 bit - have tried 32 bit and 12.04) VM (using Virtual Box).
The commands I am using are:
Unpack: simg2img system.img system.raw
Mount: sudo mount -t ext4 -o loop system.raw system/
Repack: make_ext4fs -s -l 1617722231 -S file_contexts -a system newsystem.img /home/ubuntu/mhh/Terra1004/system
The file size specified for make_ext4fs has been arrived at via trial and error as all the means I have seen of calculating (e.g blocks x block size) result in a file that is significantly bigger then the original system.img file (resulting in dead android when flashed to tablet). The current size specified results in an image file that has the same number of blocks as the original file but is 24 bytes bigger than the original (this img results in getting stuck on the very first boot splash screen).
I have tried flashing the image via fastboot (fastboot flash system system.img) and get "FAILED (remote: failed to get download permission for partition 'system')".
I am working with the manufacturer to resolve this issue but I am getting very little back from them.
I am getting quite desperate to resolve this as my business relies on my ability to amend the system.img (and other files) to bespoke the tablet to my own product.
I am really at the limit of my understanding on what I am talking about when it comes to modding tablets - I do it as a necessity rather than a hobby, so please excuse any incorrectly used terminology.
All help/suggestions welcome. Please let me know if you need any further information.
Thanks in advance.
Click to expand...
Click to collapse
Try flashing system.img without modifying it
Sent from my GT-S7580 using Tapatalk
DodoGTA said:
Try flashing system.img without modifying it
Sent from my GT-S7580 using Tapatalk
Click to expand...
Click to collapse
I've done that. The system.img file as provided by the manufacturer works fine. It fails as soon as I unpack/repack it, even without making any modifications to it.
KGMARSCH said:
I've done that. The system.img file as provided by the manufacturer works fine. It fails as soon as I unpack/repack it, even without making any modifications to it.
Click to expand...
Click to collapse
What's the size of unmodified system.img (in bytes)?
Sent from my GT-S7580 using Tapatalk
DodoGTA said:
What's the size of unmodified system.img (in bytes)?
Sent from my GT-S7580 using Tapatalk
Click to expand...
Click to collapse
Using Ubuntu stat command on system.img (the original untouched image), it reports:
Size: 929,933,912
Blocks: 1,816,288
IO Block: 4,096
Inode: 1,863,406
Doing the same on the repacked newsystem.img I get:
Size: 929,933,936
Blocks: 1,816,288
IO Block: 4,096
Inode: 1,983,804
This is the closest I can get the size of newsystem.img to be to system.img (24 bytes difference).
The permissions on both are the same (0770).
DodoGTA said:
Try flashing system.img without modifying it
Sent from my GT-S7580 using Tapatalk
Click to expand...
Click to collapse
Just realised that I may have misunderstood your comment. I have previously tried flashing the original system.img using the SP Flash Tool and that works fine. However, in case you meant flashing it via fastboot, I have just tried this and I get the same "failed to get download permission for partition 'system'" error, even with the original system.img.
KGMARSCH said:
Using Ubuntu stat command on system.img (the original untouched image), it reports:
Size: 929,933,912
Blocks: 1,816,288
IO Block: 4,096
Inode: 1,863,406
Doing the same on the repacked newsystem.img I get:
Size: 929,933,936
Blocks: 1,816,288
IO Block: 4,096
Inode: 1,983,804
This is the closest I can get the size of newsystem.img to be to system.img (24 bytes difference).
The permissions on both are the same (0770).
Click to expand...
Click to collapse
Can you run this command on a tablet you talked about in this thread (with a terminal emulator app):
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
and post the output of it?
Sent from my GT-S7580 using Tapatalk
DodoGTA said:
Can you run this command on a tablet you talked about in this thread (with a terminal emulator app):
and post the output of it?
Sent from my GT-S7580 using Tapatalk
Click to expand...
Click to collapse
Here is the output from cat partitions, cat partinfo and cat emmc:
[email protected]_PAD_1004:/proc $ cat partitions
cat partitions
major minor #blocks name
254 0 483328 zram0
7 0 1254 loop0
179 0 15267840 mmcblk0
179 1 3072 mmcblk0p1
179 2 5120 mmcblk0p2
179 3 10240 mmcblk0p3
179 4 10240 mmcblk0p4
179 5 512 mmcblk0p5
179 6 512 mmcblk0p6
179 7 16384 mmcblk0p7
179 8 16384 mmcblk0p8
179 9 8192 mmcblk0p9
179 10 10240 mmcblk0p10
179 11 512 mmcblk0p11
179 12 2048 mmcblk0p12
179 13 6144 mmcblk0p13
179 14 8192 mmcblk0p14
179 15 5120 mmcblk0p15
179 16 5120 mmcblk0p16
179 17 1024 mmcblk0p17
179 18 32768 mmcblk0p18
179 19 37888 mmcblk0p19
179 20 1572864 mmcblk0p20
179 21 409600 mmcblk0p21
179 22 13088256 mmcblk0p22
179 23 16384 mmcblk0p23
179 96 4096 mmcblk0rpmb
179 64 4096 mmcblk0boot1
179 32 4096 mmcblk0boot0
[email protected]_PAD_1004:/proc $ cat partinfo
cat partinfo
Name Start Size
pgpt 0x0000000000000000 0x0000000000080000
proinfo 0x0000000000080000 0x0000000000300000
nvram 0x0000000000380000 0x0000000000500000
protect1 0x0000000000880000 0x0000000000a00000
protect2 0x0000000001280000 0x0000000000a00000
lk 0x0000000001c80000 0x0000000000080000
para 0x0000000001d00000 0x0000000000080000
boot 0x0000000001d80000 0x0000000001000000
recovery 0x0000000002d80000 0x0000000001000000
logo 0x0000000003d80000 0x0000000000800000
expdb 0x0000000004580000 0x0000000000a00000
seccfg 0x0000000004f80000 0x0000000000080000
oemkeystore 0x0000000005000000 0x0000000000200000
secro 0x0000000005200000 0x0000000000600000
keystore 0x0000000005800000 0x0000000000800000
tee1 0x0000000006000000 0x0000000000500000
tee2 0x0000000006500000 0x0000000000500000
frp 0x0000000006a00000 0x0000000000100000
nvdata 0x0000000006b00000 0x0000000002000000
metadata 0x0000000008b00000 0x0000000002500000
system 0x000000000b000000 0x0000000060000000
cache 0x000000006b000000 0x0000000019000000
userdata 0x0000000084000000 0x000000031ed80000
flashinfo 0x00000003a2d80000 0x0000000001000000
sgpt 0x00000003a3d80000 0x0000000000080000
[email protected]_PAD_1004:/proc $ cat emmc
cat emmc
partno: start_sect nr_sects partition_name
emmc_p1: 00000400 00001800 "proinfo"
emmc_p2: 00001c00 00002800 "nvram"
emmc_p3: 00004400 00005000 "protect1"
emmc_p4: 00009400 00005000 "protect2"
emmc_p5: 0000e400 00000400 "lk"
emmc_p6: 0000e800 00000400 "para"
emmc_p7: 0000ec00 00008000 "boot"
emmc_p8: 00016c00 00008000 "recovery"
emmc_p9: 0001ec00 00004000 "logo"
emmc_p10: 00022c00 00005000 "expdb"
emmc_p11: 00027c00 00000400 "seccfg"
emmc_p12: 00028000 00001000 "oemkeystore"
emmc_p13: 00029000 00003000 "secro"
emmc_p14: 0002c000 00004000 "keystore"
emmc_p15: 00030000 00002800 "tee1"
emmc_p16: 00032800 00002800 "tee2"
emmc_p17: 00035000 00000800 "frp"
emmc_p18: 00035800 00010000 "nvdata"
emmc_p19: 00045800 00012800 "metadata"
emmc_p20: 00058000 00300000 "system"
emmc_p21: 00358000 000c8000 "cache"
emmc_p22: 00420000 018f6c00 "userdata"
emmc_p23: 01d16c00 00008000 "flashinfo"
[email protected]_PAD_1004:/proc $
DodoGTA said:
Can you run this command on a tablet you talked about in this thread (with a terminal emulator app):
and post the output of it?
Sent from my GT-S7580 using Tapatalk
Click to expand...
Click to collapse
I've got ahead of you I think. I have amended the file size in the make_ext4fs command to make it the same as the partition (1572864 x 1024 = 1610612736). I have flashed the resultant image and it now boots up.
I would swear that I tried this, but then again I have tried so many things over the last couple of weeks
You are my hero and have saved me sooooooo much stress - I honestly thought I'd have to shut down business until this was resolved.
KGMARSCH said:
I've got ahead of you I think. I have amended the file size in the make_ext4fs command to make it the same as the partition (1572864 x 1024 = 1610612736). I have flashed the resultant image and it now boots up.
I would swear that I tried this, but then again I have tried so many things over the last couple of weeks
You are my hero and have saved me sooooooo much stress - I honestly thought I'd have to shut down business until this was resolved.
Click to expand...
Click to collapse
I meant to say this solution
Sent from my GT-S7580 using Tapatalk
DodoGTA said:
I meant to say this solution
Sent from my GT-S7580 using Tapatalk
Click to expand...
Click to collapse
I don't really know what the forum etiquette is but thanks very much for your help. I was rapidly running out of stock of the previous tablet model from the manufacturer and was starting to worry that I wouldn't have a replacement ready in time - now I can get on with making the required amends.
Sometimes you just need someone from the outside to have a look!
Many thanks, Kevin
KGMARSCH said:
I am attempting to apply a new system.img file to an Android tablet and it always results in a soft brick/bootloop.
The tablet being used is a TerraPad 1004, running android 5.1.1 (MTK8735). I have been given special access to the image files by the manufacturer, who have provided everything I need to update the tablet using SP Flash Tool (5.164 on Windows 10). If I flash the files as they were provided it all works fine and the tablet boots up perfectly. If I unpack/mount/repack the system.img and then try flashing it I get stuck either on the boot screen or get the dead android image (only get this I make the system.img file too big when repacking it). Please note, despite unpacking/mounting/repacking I made no changes to the system image, so in theory it should be the same as the originally provided system.img file.
I am doing the unpack/mount/repack on Ubuntu 16.04 (64 bit - have tried 32 bit and 12.04) VM (using Virtual Box).
The commands I am using are:
Unpack: simg2img system.img system.raw
Mount: sudo mount -t ext4 -o loop system.raw system/
Repack: make_ext4fs -s -l 1617722231 -S file_contexts -a system newsystem.img /home/ubuntu/mhh/Terra1004/system
The file size specified for make_ext4fs has been arrived at via trial and error as all the means I have seen of calculating (e.g blocks x block size) result in a file that is significantly bigger then the original system.img file (resulting in dead android when flashed to tablet). The current size specified results in an image file that has the same number of blocks as the original file but is 24 bytes bigger than the original (this img results in getting stuck on the very first boot splash screen).
I have tried flashing the image via fastboot (fastboot flash system system.img) and get "FAILED (remote: failed to get download permission for partition 'system')".
I am working with the manufacturer to resolve this issue but I am getting very little back from them.
I am getting quite desperate to resolve this as my business relies on my ability to amend the system.img (and other files) to bespoke the tablet to my own product.
I am really at the limit of my understanding on what I am talking about when it comes to modding tablets - I do it as a necessity rather than a hobby, so please excuse any incorrectly used terminology.
All help/suggestions welcome. Please let me know if you need any further information.
Thanks in advance.
Click to expand...
Click to collapse
Why not try it like this
This is how I do it
use simg2img
simg2img system.img system_mod.img
mount it
mount -t ext4 -o loop system_mod.img /data/mountpoint
Make your modifications and unmount it
use img2simg
img2simg system_mod.img system.img
I don't think you can mount an img for what your trying to do you can use dd though its like flashing it
dd if=/system.img of=/mountpoint
Sent from my SM-J320P using Tapatalk
rick.wardenburg said:
Why not try it like this
This is how I do it
use simg2img
simg2img system.img system_mod.img
mount it
mount -t ext4 -o loop system_mod.img /data/mountpoint
Make your modifications and unmount it
use img2simg
img2simg system_mod.img system.img
I don't think you can mount an img for what your trying to do you can use dd though its like flashing it
dd if=/system.img of=/mountpoint
Sent from my SM-J320P using Tapatalk
Click to expand...
Click to collapse
Thanks for replying. I've now solved this (with help from DodoGTA). Turns out I had to be very specific (to the byte) with the file size in the make_ext4fs command. Previous tablets I've updated weren't as stringent with the files size (I think they were always defaulted to 500M) but this one is. I took the file size from the system partition size on the tablet (x 1024 to get it into bytes) and it worked (although I could have sworn I'd already tried this). I've now made amends to the system.img and they are taking affect. Thanks anyway.
Same issue as OP
Hey guys I could really use some help. I have MTK device with manufacturer permission to modify firmware. I unpack and repack system.img with no changes, and phone stuck on boot. I can cat partitions, but not partinfo or emmc. Any suggestions would be great as I'm super frustrated and running out of ideas.
scott.fallick said:
Hey guys I could really use some help. I have MTK device with manufacturer permission to modify firmware. I unpack and repack system.img with no changes, and phone stuck on boot. I can cat partitions, but not partinfo or emmc. Any suggestions would be great as I'm super frustrated and running out of ideas.
Click to expand...
Click to collapse
Hi Scott,
If your problem is the same as the one I had then it will be to do with the size you are specifying when repacking the system image.
I was able to work out the size that I required from "cat partitions" (take the size shown for the system partition and multiply it by 1024 to get the value you should use).
The problem you may have is being able to identify which is the system partition. Without being able to see either the partinfo or emmc you may not be able to do this easily, in which case I would recommend a process of elimination. Start with the largest number shown on in the "cat partitions" list and work your why down until you get a value that works. Not the quickest way to do it but the best I can offer you. If you can post the output from "cat partitions" I may be able to make an educated guess which is the system.
Sorry I can't be of more help.
KGMARSCH said:
Hi Scott,
If your problem is the same as the one I had then it will be to do with the size you are specifying when repacking the system image.
I was able to work out the size that I required from "cat partitions" (take the size shown for the system partition and multiply it by 1024 to get the value you should use).
The problem you may have is being able to identify which is the system partition. Without being able to see either the partinfo or emmc you may not be able to do this easily, in which case I would recommend a process of elimination. Start with the largest number shown on in the "cat partitions" list and work your why down until you get a value that works. Not the quickest way to do it but the best I can offer you. If you can post the output from "cat partitions" I may be able to make an educated guess which is the system.
Sorry I can't be of more help.
Click to expand...
Click to collapse
So I believe I'm using the correct size, I was able to determine the name for system using an apk. However, this may sound weird, but it seems my system.img is on a ZRAM partition.
scott.fallick said:
So I believe I'm using the correct size, I was able to determine the name for system using an apk. However, this may sound weird, but it seems my system.img is on a ZRAM partition.
Click to expand...
Click to collapse
I think I am at the limit of my knowledge here. I know enough to be able to make changes to one specific model of tablet. Anything outside of the process that I use for modifying that tablet and I'm not much help I'm afraid. Sorry.
I hope someone else is able to help you.
Kevin
KGMARSCH said:
Hi Scott,
If your problem is the same as the one I had then it will be to do with the size you are specifying when repacking the system image. I was able to work out the size that I required from "cat partitions" (take the size shown for the system partition and multiply it by 1024 to get the value you should use).
.
Click to expand...
Click to collapse
I have the same issue. Seem to have to almost hit super lucky with my make_ext4fs command on nougat based system.img files, where I seem to have gotten one mbuild working but then nothing!. I am in bootloop hell!! However your solution seems like the answer for me. Forgive me for being a little slow on the uptake here, can you explain how you CAT on the device to get the partition sizes and can you take us through the method a little more step by step? I just lost you on that small point.
Just the bit about getting the partition size you then multiply by 1024 to get the final value you use in the make_ext4fs command?
Cheers
OK, so I answered my own question here: https://forum.xda-developers.com/showthread.php?t=2450045
I'm a Windows dude so LINUX commands are not my forte!!
davek17 said:
OK, so I answered my own question here: https://forum.xda-developers.com/showthread.php?t=2450045
I'm a Windows dude so LINUX commands are not my forte!!
Click to expand...
Click to collapse
Well still not resolved actually. For some reason make_ext4fs is now building 44.9MB system.img files that are empty when upacked. Maybe my LINUX VM has gotten corrupted.
Also I think this could be to do with dm-verity too. Despite not seeing any errors when I build the system.img again it boots, runs normally but anything to do with Google apps fail. E.G. Google play stops running, chrome just doesn't want to load. Rest of device seems to work OK though!! Anyone shed any light on that
Related
I'm working on my first ROM that is based on the "stock" Samsung firmware. I am used to messing around with AOSP and CM ROMs where there's a nice flashable ZIP with a boot.img in it. Working from the "stock" Samsung image has been less clean.
My device is a Samsung SGH-T869 (the T-Mobile version of the Galaxy Tab 7.0 Plus).
I began with the file T869TMBLG7_T869UVLG7_T869UVLG7_HOME.tar.md5, which is the newest firmware available for this device.
I am able to extract the image using 7-zip, which gives me the error "There is no correct record at the end of archive", but otherwise appears to extract perfectly.
Extracted files include:
-boot.bin
-cache.img
-factoryfs.img
-hidden.img
-modem.bin
-param.lfs
-recovery.img
-Sbl.bin
-zImage
These files are enough to give Android Kitchen something to start with, but AK is complaining about the lack of a boot.img, plus I want to do some ramdisk tweaking. I have been researching this for hours, and I get the impression that what I need is in there, just in a proprietary format. I have installed KernelKitchen, which I guess I can use to build boot.img from zImage and a ramdisk, I'm just not sure where to go from here.
I also tried dumping ADB (dd if=/dev/block/mmcblk0pX of=/sdcard/boot.img, tried all partitions one by one).
I also looked at a backup made via CWM 6 of the 'stock' untouched ROM running on my tab. My backup contains:
-boot.img
-cache.ext4.dup
-data.ext4.dup
-nandroid.md5
-recovery.img
-system.ext4.dup
So far, no success. The various imgs I have pulled are all treated as invalid by Android Kitchen and also split_bootimg.pl by William Enck. When running that nice Perl script I get the error "Android Magic not found".
My general first goal is a cleaned up stock ROM which has been deodexed, zipaligned, with insecure boot enabled, and of course, root.I would like to also do a sweet custom boot image and boot animation, but I believe its best to start with a solid foundation before jumping into the other stuff. Any suggestions, XDA gang? Somewhere in that mix did I get the actual boot.img but Samsung uses a weird header? Or something else?
Rename file.tar.md5 to file.tar and unzip
Find an updater-script of custom based stock rom and you get "name' of kernel partition
Sent from my X10i using xda app-developers app
xSkArx said:
Rename file.tar.md5 to file.tar and unzip
Find an updater-script of custom based stock rom and you get "name' of kernel partition
Sent from my X10i using xda app-developers app
Click to expand...
Click to collapse
Your first instruction (to "rename and unzip") makes no difference at all.
The second suggestion seems like it may be useful.
From the CM9 flash script I found that /dev/block/mmcblk0p5 is the boot partition.
I am not sure what's wrong with the boot.img I am pulling.
Here's my command session:
Code:
adb shell
su
dd if=dev/block/mmcblk0p5 of=/mnt/sdcard/boot.img
exit
adb pull /mnt/sdcard/boot.img
I attached the resulting file. I looked at it a bit in a hex editor but I'm not sure what I'm lookin for...
DivinityCycle said:
Your first instruction (to "rename and unzip") makes no difference at all.
The second suggestion seems like it may be useful.
From the CM9 flash script I found that /dev/block/mmcblk0p5 is the boot partition.
I am not sure what's wrong with the boot.img I am pulling.
Here's my command session:
Code:
adb shell
su
dd if=dev/block/mmcblk0p5 of=/mnt/sdcard/boot.img
exit
adb pull /mnt/sdcard/boot.img
I attached the resulting file. I looked at it a bit in a hex editor but I'm not sure what I'm lookin for...
Click to expand...
Click to collapse
It seems that you managed to extract a kernel image (zImage). What you are looking for is an image starting with the signature "ANDROID!".
What do you see if you enter the following command?
Code:
$ cat /proc/mtd
It should read something similar to:
Code:
dev: size erasesize name
mtd0: xxxxxxxx xxxxxxxx "system"
...
DivinityCycle said:
Your first instruction (to "rename and unzip") makes no difference at all.
The second suggestion seems like it may be useful.
From the CM9 flash script I found that /dev/block/mmcblk0p5 is the boot partition.
I am not sure what's wrong with the boot.img I am pulling.
Here's my command session:
Code:
adb shell
su
dd if=dev/block/mmcblk0p5 of=/mnt/sdcard/boot.img
exit
adb pull /mnt/sdcard/boot.img
I attached the resulting file. I looked at it a bit in a hex editor but I'm not sure what I'm lookin for...
Click to expand...
Click to collapse
My first instruction is to get boot.bin without error when unzip it.
With the boot.img that you attached try this http://forum.xda-developers.com/showthread.php?t=1849666
Sent from my X10i using xda app-developers app
You are probably going to have to trim some extra data off the front of your boot.img so that the tool finds the needed Hex address. If you haven't already I'd pull the applicable scripts out of dsixda's kitchen and see how he handles it.
k02a said:
It seems that you managed to extract a kernel image (zImage). What you are looking for is an image starting with the signature "ANDROID!".
What do you see if you enter the following command?
Code:
$ cat /proc/mtd
It should read something similar to:
Code:
dev: size erasesize name
mtd0: xxxxxxxx xxxxxxxx "system"
...
Click to expand...
Click to collapse
I'm pretty sure you're after the partitions. However, there's no /proc/mtd on the SGH-T869 running stock.
Code:
[email protected]:/proc # cat partitions
cat partitions
major minor #blocks name
179 0 15388672 mmcblk0
179 1 20480 mmcblk0p1
179 2 1280 mmcblk0p2
179 3 1280 mmcblk0p3
179 4 8192 mmcblk0p4
179 5 8192 mmcblk0p5
179 6 8192 mmcblk0p6
179 7 204800 mmcblk0p7
259 0 16384 mmcblk0p8
259 1 786432 mmcblk0p9
259 2 13791232 mmcblk0p10
259 3 524288 mmcblk0p11
259 4 8192 mmcblk0p12
179 8 30318592 mmcblk1
179 9 30317568 mmcblk1p1
When looking at /proc/mounts, I see that partitions 1, 4, 7, 9, and 10 are all mounted. I'm also relatively certain that mmcblk1 is the microSD card slot, based on its size (I've got a 32GB card installed at the moment).
So, ruling those out, we're left with:
Code:
major minor #blocks name
179 2 1280 mmcblk0p2
179 3 1280 mmcblk0p3
179 5 8192 mmcblk0p5
179 6 8192 mmcblk0p6
259 0 16384 mmcblk0p8
259 3 524288 mmcblk0p11
259 4 8192 mmcblk0p12
I have already extracted the first 8 partitions and tried running each through Android Kitchen's boot.img unpack tool without success. The script fails to locate the ANDROID header within any of the files. I'm guessing Samsung uses some sort of custom header, because if it works perfectly fine, why not mess with it?
I've searched through a few of the files with XVI32 for "ANDROID" but didn't get any hits.
As posted earlier, other ROMs flash boot.img to mmcblk0p5 so I'm pretty sure that's the right space.
Any hints on an application I can use to analyze the dump and locate the offsets where the header and ramdisk are inside it?
Update. In my research I have come across this article:
http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images
It wasn't directly helpful but it did give me a key idea: "Find the Magic Number for a GZ archive and you'll find the ramdisk inside the raw image"
As per http://www.garykessler.net/library/file_sigs.html, the "Magic Number" for a GZ archive is 1F 8B 08. The first article only mentions "look for a bunch of zeros and then 1F 8B." That never occurs in my dumped file, and the number 1F 8B occurs 65 times. However, "1F 8B 08" only occurs once in the entire file, indicating the spot where the header and kernel end and the ramdisk begins.
I deleted everything before 1F 8B 08 and saved the result as ramdisk.gz.
Then, I threw the resulting file onto one of my Linux boxes and used the following commands to extract:
Code:
mkdir ramdisk
cd ramdisk
gunzip < ../ramdisk.gz | cpio -i --make-directories
ls
(results of ls command here:)
data init.goldfish.rc lpm.rc ueventd.goldfish.rc
default.prop init.rc proc ueventd.rc
dev init.smdk4210.rc sbin ueventd.smdk4210.rc
fota.rc init.smdk4210.usb.rc sys vendor
init lib system
I did this stuff in a command terminal connected over Putty, and I got a ton of crazy output during extraction, mostly the line "cpio: Malformed number" over and over.
My next planned task is to take 3 boot.img dumps from my tablet and them compare MD5s on all 3 dumps, to ensure I got a "good" copy.
I imagine this is largely unnecessary, but I've learned from working on other embedded devices that you can't be too careful about raw reads / writes.
I'm pretty sure now that I have extracted the ramdisk I am OK. The factory firmware has zImage as a discrete file, so I'm pretty sure I can use either Android Kitchen or Kernel Kitchen to repack the stuff into a "normal" boot.img.
I'll post my results here, since there may be like one other person interested in doing ROMs for the T869
Just a little update, the md5sums on ALL of my various dumps matched.
By that I mean CWM's backup and all the various dumps I did via ADB (using the dd command) all match.
md5sum for this firmware's boot.img appears to be 1e4367954524901c7dfff14b02023163
Interesting and a great research!
I look forward to see more of your progressive work.
Sent from my Xperia Arc via Tapatalk 2
---------- Post added 11th October 2012 at 12:00 AM ---------- Previous post was 10th October 2012 at 11:39 PM ----------
DivinityCycle said:
As per http://www.garykessler.net/library/file_sigs.html, the "Magic Number" for a GZ archive is 1F 8B 08. The first article only mentions "look for a bunch of zeros and then 1F 8B." That never occurs in my dumped file, and the number 1F 8B occurs 65 times. However, "1F 8B 08" only occurs once in the entire file, indicating the spot where the header and kernel end and the ramdisk begins.
I deleted everything before 1F 8B 08 and saved the result as ramdisk.gz.
Then, I threw the resulting file onto one of my Linux boxes and used the following commands to extract:
Click to expand...
Click to collapse
According to RFC1952, the gzip header only contains two bytes (ID1, ID2), while the third byte (CM) normally seems to be set to 0x08 (deflate) - so you did the right thing to include the third byte.
http://tools.ietf.org/html/rfc1952
Sent from my Xperia Arc via Tapatalk 2
k02a said:
Interesting and a great research!
I look forward to see more of your progressive work.
Sent from my Xperia Arc via Tapatalk 2
Hell yeah, I'm surprised at how much I've achieved, since today has been pretty busy at work. I use Putty, WinSCP, and SplashTop to access my home machines from the office, and I've got an ADB command line connection to my tab on my workstation here, so I've been able to get a lot done.
My current task is reverse-engineering dsixda's scripts that do the task of taking apart the boot.img. I should have looked at them before, they're well-written and self-documented. It's looking like I'll have to figure out the weird offsets Samsung is using (already half done) and then I can tweak the scripts so they'll probably be able to unpack / repack the image.
If I'm building a stock ROM do the offsets and header have to all be the same on my modified boot.img? I would assume so, but I'm new to this
I only want to modify the ramdisk a bit, no kernel tweaks.
Click to expand...
Click to collapse
After much searching, it looks Samsung's boot.imgs sometimes simply have no header at all, so like the first chunk is the kernel, and the second is the ramdisk. I'm gonna test out unpacking ramdisk, making the changes I need, repacking it, and then combining the two chunks back together for flashing.
Will post results
DivinityCycle said:
After much searching, it looks Samsung's boot.imgs sometimes simply have no header at all, so like the first chunk is the kernel, and the second is the ramdisk. I'm gonna test out unpacking ramdisk, making the changes I need, repacking it, and then combining the two chunks back together for flashing.
Will post results
Click to expand...
Click to collapse
I took a new look at your boot.img today.
Besides the gzip header at address 0000:4634 (which you found), I also noticed that there are 256 (0x100) bytes at 007f:fc00.
Any clue about this?
DivinityCycle said:
I'm working on my first ROM that is based on the "stock" Samsung firmware. I am used to messing around with AOSP and CM ROMs where there's a nice flashable ZIP with a boot.img in it. Working from the "stock" Samsung image has been less clean.
My device is a Samsung SGH-T869 (the T-Mobile version of the Galaxy Tab 7.0 Plus).
I began with the file T869TMBLG7_T869UVLG7_T869UVLG7_HOME.tar.md5, which is the newest firmware available for this device.
I am able to extract the image using 7-zip, which gives me the error "There is no correct record at the end of archive", but otherwise appears to extract perfectly.
Extracted files include:
-boot.bin
-cache.img
-factoryfs.img
-hidden.img
-modem.bin
-param.lfs
-recovery.img
-Sbl.bin
-zImage
These files are enough to give Android Kitchen something to start with, but AK is complaining about the lack of a boot.img, plus I want to do some ramdisk tweaking. I have been researching this for hours, and I get the impression that what I need is in there, just in a proprietary format. I have installed KernelKitchen, which I guess I can use to build boot.img from zImage and a ramdisk, I'm just not sure where to go from here.
I also tried dumping ADB (dd if=/dev/block/mmcblk0pX of=/sdcard/boot.img, tried all partitions one by one).
I also looked at a backup made via CWM 6 of the 'stock' untouched ROM running on my tab. My backup contains:
-boot.img
-cache.ext4.dup
-data.ext4.dup
-nandroid.md5
-recovery.img
-system.ext4.dup
So far, no success. The various imgs I have pulled are all treated as invalid by Android Kitchen and also split_bootimg.pl by William Enck. When running that nice Perl script I get the error "Android Magic not found".
My general first goal is a cleaned up stock ROM which has been deodexed, zipaligned, with insecure boot enabled, and of course, root.I would like to also do a sweet custom boot image and boot animation, but I believe its best to start with a solid foundation before jumping into the other stuff. Any suggestions, XDA gang? Somewhere in that mix did I get the actual boot.img but Samsung uses a weird header? Or something else?
Click to expand...
Click to collapse
Feel free to use my updater-script in the scorched kernel thread. The updater works for ics boot images. just remove the parts about copying lib files and setting permissions ... and remove the lib files from the zip. they are specific to the kernel. a stock kernel will break if those lib files are copied to /system/lib/modules.
Oh, and you can get the boot image easily in CWM by doing a backup of the stock rom and grabbing it from the clockworkmod folder on the sdcard.
merwin said:
Feel free to use my updater-script in the scorched kernel thread. The updater works for ics boot images. just remove the parts about copying lib files and setting permissions ... and remove the lib files from the zip. they are specific to the kernel. a stock kernel will break if those lib files are copied to /system/lib/modules.
Oh, and you can get the boot image easily in CWM by doing a backup of the stock rom and grabbing it from the clockworkmod folder on the sdcard.
Click to expand...
Click to collapse
As posted earlier in this thread, I pulled a boot.img from a CWM backup, but that was back before I knew how to do anything useful with it yet.
The md5sum of the CWM-generated backup boot.img matches the dumps I did over ADB using the dd command, so they're different ways to get the same end result. I have a pretty good understanding of the syntax used in the CWM flashable ZIPs. My rough plan was to first build a "restore to stock boot.img" flashable zip (so I can fix it if I make my tab unbootable ), then experiment with building my own boot.img and flashing it using the same methods. The only thing that'll be different about the "flash modded boot.img" and "flash stock boot.img" is the actual boot.img file included in the zip. Didn't get a chance to do it while off work last night, but should be able to knock it out today.
k02a said:
I took a new look at your boot.img today.
Besides the gzip header at address 0000:4634 (which you found), I also noticed that there are 256 (0x100) bytes at 007f:fc00.
Any clue about this?
Click to expand...
Click to collapse
Your guess is probably better than mine, honestly. I would think that second address is actually within the 'ramdisk' part of things, so that seems pretty odd. I'm a relative noob when it comes to hex stuff, as that's a couple levels down from where I usually operate with computers
If I unpack, modify, and repack the ramdisk, any suggestions on the 'best' way to reattach the header/kernel to it?
k02a said:
I took a new look at your boot.img today.
Besides the gzip header at address 0000:4634 (which you found), I also noticed that there are 256 (0x100) bytes at 007f:fc00.
Any clue about this?
Click to expand...
Click to collapse
Following up on this earlier point, it looks like there are a few more regions within the 8 MB file than I initially saw.
I use XVI32, so the addresses I found are formatting as such.
it seems like the following is the layout of the file contents:
Part 1 - $000000 to $004633 = 17.5 KB header?
Part 2 - $004634 to $4768A6 = 4.44 MB ramdisk (?)
Part 3 - $4768A7 to $7FFBFF = 3.53 MB of zero padding
Part 4 - $7FFC00 to $7FFCFF = 241 bytes footer
Part 5 - $7FFD00 to $7FFFFF = 768 bytes of zero padding
My initial attempt to unpack / repack the image of course made the device unbootable. My "restore" flashable zip worked as expected, so I'm now able to mess around with this stuff with relative ease.
I'm still getting a bunch of weird crap in my terminal when extracting the ramdisk. The command I am running is gunzip -c ../ramdisk.gz | cpio -i run within the directory where I want the files to extract. Both under Cygwin in Windows and under Ubuntu Server, I get tons of "cpio: Malformed number" followed by garbage. Under Ubuntu Server, despite this weird output, the files actually DO appear to extract and I get 1.65 MB of unpacked files, all in the expected format and directory structure.
Under Cygwin it didn't extract at all.
I'll continue to mess around but for your hacky fun, I have attached the parts all split up and then packed into a single ZIP.
Post if you have any ideas. I'm gonna try and repack the ramdisk and then re-assemble the whole thing. The repacked ramdisk will be smaller, but I'll just fill in the empty spot with zero padding so that the footer still ends up at the same address. We'll see if that works
Quite interesting result so far...
I wonder if there are some documentation on the data structure of the footer information floating around in public, and secondly if the offset is static.
Speaking of padding zeros. Maybe the number of trailing zeroes depends on the payload size and the page size (evenly divided by given page size), which is the case for e. g. boot.img?
Sent from my Xperia Arc via Tapatalk 2
k02a said:
Quite interesting result so far...
I wonder if there are some documentation on the data structure of the footer information floating around in public, and secondly if the offset is static.
Speaking of padding zeros. Maybe the number of trailing zeroes depends on the payload size and the page size (evenly divided by given page size), which is the case for e. g. boot.img?
Sent from my Xperia Arc via Tapatalk 2
Click to expand...
Click to collapse
It will take some experimentation to see how picky the boot loader is. I have been sidetracked today by actual work (imagine that!) and also I have been working on exhaustively cataloging and documenting the contents of the stock ROM, particularly /system/app. Cutting the Samsung bloat has been challenging only in that there's so much stuff to remove
I just had a brainstorm: I'm going to examine the boot.img from the CM9 and CM10 ROMs for the T869. After all, both of them are accepted by the bootloader, so those two and the "stock" boot.img must share some common properties, which one would think would be the "key" stuff to make the boot.img work.
The boot.imgs from CM9 and CM10 both lack any useful "handles" to try and understand their contents.
I'm uncertain how else to proceed.
I have tried creating a modified ramdisk archive, then padding out the rest of the space with zeros so that the various pieces of boot.img fall at the same location, but no success.
I'm beginning to think everything about the Samsung boot.img is weird. I was able to locate the boot logo, but its located in the ramdisk at /sbin/fota.png.
I've been knocking away on this for like a week now, and I'm beginning to think maybe it ain't worth it. All this so I can get insecure boot and maybe a modified boot image? Freakin Samsung
I have a NOOK tablet 16GB that is somehow locked from modifying partitions
I have tried
the repart image , which has worked many times for me in the past
the AdamOutler Ubuntu Disk
formatting / wiping options in various versions of CWM and TWRP
fastboot erases
fastboot formats
dd'ing /zero to various partitions
parted
sgdisk
a zillion scripts
something at a low level is preventing modifications to the partitions
Im wasting far too much time on this , but I hate being beat (-:
I have a backup of rom and factory , and dd images of stock parttions so I am 100% comfortable with something that
will COMPLETELY ZAP the device
if I boot a known good CM10 image from SD card, it fails to boot , I was assuming if I could get a running android from the card, I'd have access to lots of tools... , but it just fails to tun CM10
any help appreciated.
Thanks
To completely zap the device, erase the partition table. That will leave you one, giant, unallocated space.
From there, you need to recreate all partitions from scratch.
You will not be able to boot without a bootable CWM SD, so have that handy.
sagirfahmid3 said:
To completely zap the device, erase the partition table. That will leave you one, giant, unallocated space.
From there, you need to recreate all partitions from scratch.
You will not be able to boot without a bootable CWM SD, so have that handy.
Click to expand...
Click to collapse
Thanks for responding, Yes, I have tried multiple ways to to zap the table and it doesnt stick.
sgdisk -Z, sgdisk -z parted,
no matter what I do the partitions remain untouched.
I reboot and it still boots into an old stock OS that has a FC shortly after startup, and the internal recovery (factory) , which I can not overwrite, gives the please restart and try again message.
hmm,
I WAS able to get a CM7 SD card image to boot and run
appears to work "normally" , but Internal storage shows as "not available" in settings
mikeataol said:
hmm,
I WAS able to get a CM7 SD card image to boot and run
appears to work "normally" , but Internal storage shows as "not available" in settings
Click to expand...
Click to collapse
You're supposed to do:
# gdisk
# o
# w
# q
That will for sure give you an empty partition table. You probably forgot to write the changes before exiting.
sagirfahmid3 said:
You're supposed to do:
# gdisk
# o
# w
# q
That will for sure give you an empty partition table. You probably forgot to write the changes before exiting.
Click to expand...
Click to collapse
Hi, no, I didnt forget to "write" after the "o"
/tmp # ./gdisk /dev/block/mmcblk0
./gdisk /dev/block/mmcblk0
GPT fdisk (gdisk) version 0.8.4
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.
Warning! Main and backup partition tables differ! Use the 'c' and 'e' options
on the recovery & transformation menu to examine the two tables.
Warning! One or more CRCs don't match. You should repair the disk!
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: damaged
****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************
Command (? for help): o
o
This option deletes all partitions and creates a new protective MBR.
Proceed? (Y/N): y
y
Command (? for help): w
w
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!
Do you want to proceed? (Y/N): y
y
OK; writing new GUID partition table (GPT) to /dev/block/mmcblk0.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot.
The operation has completed successfully.
/tmp # q
/tmp #
after reboot
Command (? for help): p
p
Disk /dev/block/mmcblk0: 31105024 sectors, 14.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): CE21388C-B927-4A5C-91CE-DBD1DE4AB3BC
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 30535678
Partitions will be aligned on 256-sector boundaries
Total free space is 1285 sectors (642.5 KiB)
Number Start (sector) End (sector) Size Code Name
1 256 511 128.0 KiB 8300 xloader
2 512 1023 256.0 KiB 8300 bootloader
3 1024 31743 15.0 MiB 8300 recovery
4 32768 65535 16.0 MiB 8300 boot
5 65536 163839 48.0 MiB 8300 rom
6 163840 262143 48.0 MiB 8300 bootdata
7 262144 1019903 370.0 MiB 8300 factory
8 1019904 2273279 612.0 MiB 8300 system
9 2273280 3145727 426.0 MiB 8300 cache
10 3145728 5242879 1024.0 MiB 8300 media
11 5242880 30535639 12.1 GiB 8300 userdata
Humm...wow, that's pretty crazy. Try writing zeroes to your emmc and then retrying.
# dd if=/dev/zero of=/dev/block/mmcblk0
This is a port of stock the Nexus7 (Grouper) 4.1.2 ROM with the Nabi 2 OTA 2.4.6 as the base. Everything seems to be working but as the title says it is a beta and so not fully tested....FLASH AT YOUR OWN RISK!!!!
Couple of things to be aware of: You have to update some of the apps before they work (Chrome for instance) and when adjusting the brightness it is possible to turn the screen all the way black, don't panic, just slide it back to the right...oh, and if you try to skip turning on the wifi it still tries to connect but it will eventually time out. If anyone actually uses the Nabi camera I have found that the Nexus 7 Camera app from the play store will work, other ones might also but I tested that one. There are no HDMI settings right now because the Nexus didn't have that port but the HDMI does work.
Screenshot:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Instructions:
1. Make a full TWRP backup to external sdcard!!! AND make sure your backup works!!!
2. Download the zip and place it on your external sdcard.
3. Wipe everything except external sdcard.
4. Install the zip.
5. Wipe cache and davlik again for good measure.
6. Reboot and do a little happy dance!!! (First boot takes a while so don't freak after 30 secs, lol)
Download: Nabixus_beta0.1.zip , Mirror1, or Mirror2
MD5: b334707cf14b2ad4e552d6a7a3b48fcd
Let me know what you think, I know there's room for improvement....and I'll fix this post up some at some point, give me a break it's my first time!!
reserved
reserved 2
First! LOL. Glad you got it going. If you need any help or any stock files from my newly acquired Nexus 7, let me know. I can make a complete nandroid if needed.
Additional screenshots!
Can't spend too much time fooling around with it before the kids get up, but looks good for now! Thanks for the awesome work!
Just to report, all is well with the port. Just getting a bit of screen flicker but that is due to the low brightness level. It has gone away since I have raised it up all the way. All apps updating fine via Playstore and OTG USB working great as well. Side loading a lot of what I call my "Power Rooting Apps". This reminds me of the nexus 7 I just got LOL. Great job!
Dude! YOU ROCK....
Now when my son upgrades, I'll be able to use the nabi for kodi (xbmc) on the tv.
Sent from my Nexus 7 using Tapatalk
Awesome, can't wait till I have a moment free to give this a try!
Sent from my Nexus 10 using Tapatalk
@n3wt GREAT job, just wanted to know if I build CyanogenMod for Nexus 7 2012; could you port CyanogenMod over to Nabi?
katinatez said:
@n3wt GREAT job, just wanted to know if I build CyanogenMod for Nexus 7 2012; could you port CyanogenMod over to Nabi?
Click to expand...
Click to collapse
I've been trying to port CM the past few days and keep getting stuck at a never ending boot animation. So yeah, if you guys could give it a shot that would be great, lol.
katinatez said:
if I build CyanogenMod for Nexus 7 2012; could you port CyanogenMod over to Nabi?
Click to expand...
Click to collapse
maybe. aicjofs suggested that the kernel might be too different though. I have a cm with tablet ui for the Nexus that I was looking at but I'm toying with the idea of trying to get a working kernel compiled. ... That way we could just build a rom for the nabi.
It took a lot of hours to get to this point though so whatever comes next will be after a bit of rest.
I'm really happy that you guys are liking this one, feel free to take it and mod it and what not.
SMcC2 said:
I've been trying to port CM the past few days and keep getting stuck at a never ending boot animation. So yeah, if you guys could give it a shot that would be great, lol.
Click to expand...
Click to collapse
Do you have adb working?
ROFL
Anyone else get the email
"Hello from Google: Get the most out of your Nexus 7" ?
n3wt said:
Do you have adb working?
Click to expand...
Click to collapse
I had it working at one point, but don't remember how I had gotten there.
I've been using these links as resources:
How to Build CyanogenMod for Grouper
How to Port CyanogenMod to new Devices
Kernel Building for CyanogenMod
The instructions for building on Grouper say to pull the proprietary blobs from a device with CyanogenMod already installed. I don't have that option.
Note:
Your device should already be running a build of CyanogenMod for the branch you wish to build for the extract-files.sh script to function properly. Nexus users: While it maybe be tempting to run the script on stock Android, and in fact it may succeed, realize that some of the blobs CyanogenMod uses are modified or otherwise different from stock blobs (e.g. Adreno graphics libraries). Save yourself some trouble and install a copy of CyanogenMod on your device before extracting blobs.
Click to expand...
Click to collapse
The instructions for porting to new devices says
Create extract-files.sh and setup-makefiles.sh scripts to pull those blob files from the device using adb and put them in the right /vendor/ directory. There are plenty of examples available for other devices.
Create an .mk Makefile to copy those files to the $OUT folder during the build process and put them in the right place. Again, use other devices as a guide for what this Makefile should look like. An example filename might be BoardConfigVendor.mk
Make sure that the Makefile you just created is included from your main BoardConfig.mk via a command such as -include vendor/[vendor]/[codename]/BoardConfigVendor.mk. Again, existing devices can illustrate how this is done.
Click to expand...
Click to collapse
I don't think I'm getting everything when I do that and that's where my problem is...
maybe. aicjofs suggested that the kernel might be too different though.
Click to expand...
Click to collapse
The Nabi kernel should be based on AOSP, so that is the best ROM's to work with for best compatibility. AOKP, and CM being there own breed might need some kernel mods. For example on current Qualcomm devices CM is using CAF code and AOSP is using google kernel code. Just an example
Anyone else get the email
Click to expand...
Click to collapse
Could be this in build.prop.
ro.build.fingerprint=google/nakasi/grouper:4.1.2/JZO54K/485486:user/release-keys
or a special bit of code in email program.
Create extract-files.sh and setup-makefiles.sh scripts to pull those blob files from the device using adb and put them in the right /vendor/ directory. There are plenty of examples available for other devices.
Click to expand...
Click to collapse
Yeah you have to do it all manually(make proprietary-files.txt). I did it once but it was all manual, and I could have missed something, it took hours. I also remember having a failure pulling the firmware files in the /vendor directory. You can look at what I did in attached
@n3wt You should write up some of your secret sauce, would help those guys mimic what you did on other ROM's
aicjofs said:
Yeah you have to do it all manually(make proprietary-files.txt). I did it once but it was all manual, and I could have missed something, it took hours. I also remember having a failure pulling the firmware files in the /vendor directory. You can look at what I did in attached
Click to expand...
Click to collapse
I was afraid it might have to be done manually.
SMcC2 said:
I've been trying to port CM the past few days and keep getting stuck at a never ending boot animation. So yeah, if you guys could give it a shot that would be great, lol.
Click to expand...
Click to collapse
Same here LOL. I have been trying to port CleanRom 4.0.0 JB 4.3 from my Nexus 7 but am stuck at the 4 rotating orbs. I have the boot image decompiled and the complete System files from my Nexus 7 if anyone would like to give it a try.
aicjofs said:
@n3wt You should write up some of your secret sauce, would help those guys mimic what you did on other ROM's
Click to expand...
Click to collapse
Yes please, I have dissected the rom to see the differences and have gotten as far as I have so far. It is very time consuming for sure. I have 4.1.2 Modded to the bone at the moment.
In case anyone wants the info:Off my Nexus 7 Running CleanRom 4.0.0 4.3 JB.
Code:
(dev/block/platform/sdhci-tegra.3/by-name)
[email protected]:/ $ cat /proc/partitions
cat /proc/partitions
major minor #blocks name
7 0 2111 loop0
7 1 11466 loop1
7 2 9387 loop2
7 3 4190 loop3
7 4 28098 loop4
7 5 61362 loop5
7 6 8348 loop6
7 7 53046 loop7
179 0 31178752 mmcblk0
179 1 12288 mmcblk0p1
179 2 8192 mmcblk0p2
179 3 665600 mmcblk0p3
179 4 453632 mmcblk0p4
179 5 512 mmcblk0p5
179 6 10240 mmcblk0p6
179 7 5120 mmcblk0p7
179 8 512 mmcblk0p8
179 9 30014464 mmcblk0p9
179 32 2048 mmcblk0boot1
179 16 2048 mmcblk0boot0
254 0 2110 dm-0
254 1 11466 dm-1
254 2 9387 dm-2
254 3 4189 dm-3
254 4 28098 dm-4
254 5 61362 dm-5
254 6 8347 dm-6
254 7 53046 dm-7
7 8 2111 loop8
254 8 2110 dm-8
=============================================
[email protected]:/ $ ls -al /dev/block/platform/sdhci-tegra.3/by-name
ls -al /dev/block/platform/sdhci-tegra.3/by-name
lrwxrwxrwx root root 2014-10-04 12:29 APP -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 2014-10-04 12:29 CAC -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 2014-10-04 12:29 LNX -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 2014-10-04 12:29 MDA -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 2014-10-04 12:29 MSC -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2014-10-04 12:29 PER -> /dev/block/mmcblk0p7
lrwxrwxrwx root root 2014-10-04 12:29 SOS -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 2014-10-04 12:29 UDA -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 2014-10-04 12:29 USP -> /dev/block/mmcblk0p6
[COLOR=Red]=============================================[/COLOR]
[COLOR=DarkRed][B]( fstab.grouper )[/B][/COLOR]
[COLOR=Red]==================================[/COLOR]
# Android fstab file.
#<src> <mnt_point> <type> <mnt_flags> <fs_mgr_flags>
# The filesystem that contains the filesystem checker binary (typically /system) cannot
# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 noatime,nodiratime,nodev,noauto_da_alloc wait
/dev/block/platform/sdhci-tegra.3/by-name/CAC /cache ext4 noatime,nodiratime,nosuid,nodev,data=writeback,noauto_da_alloc,nomblk_io_submit,errors=panic wait
/dev/block/platform/sdhci-tegra.3/by-name/UDA /data ext4 noatime,nodiratime,nosuid,nodev,data=writeback,noauto_da_alloc,nomblk_io_submit,errors=panic wait,encryptable=/dev/block/platform/sdhci-tegra.3/by-name/MDA
/dev/block/platform/sdhci-tegra.3/by-name/MSC /misc emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/LNX /boot emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/SOS /recovery emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/USP /staging emmc defaults defaults
/devices/platform/tegra-ehci /storage/usbdisk vfat defaults voldmanaged=usbdisk:auto
[COLOR=Red]---------------------------------------------[/COLOR]
[B][COLOR=DarkRed]( fstab.grouper~ )[/COLOR][/B]
[COLOR=Red]-------------------------------------[/COLOR]
# Android fstab file.
#<src> <mnt_point> <type> <mnt_flags> <fs_mgr_flags>
# The filesystem that contains the filesystem checker binary (typically /system) cannot
# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro wait
/dev/block/platform/sdhci-tegra.3/by-name/CAC /cache ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic wait
/dev/block/platform/sdhci-tegra.3/by-name/UDA /data ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic wait,encryptable=/dev/block/platform/sdhci-tegra.3/by-name/MDA
/dev/block/platform/sdhci-tegra.3/by-name/MSC /misc emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/LNX /boot emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/SOS /recovery emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/USP /staging emmc defaults defaults
/devices/platform/tegra-ehci /storage/usbdisk vfat defaults voldmanaged=usbdisk:auto
SMcC2 said:
I was afraid it might have to be done manually.
Click to expand...
Click to collapse
Well look over the zip I posted maybe it can save some time.
DarkAngel said:
Same here LOL. I have been trying to port CleanRom 4.0.0 JB 4.3
Click to expand...
Click to collapse
Above 4.2 you will need SElinux support in kernel, so I don't 4.3 is going to work.
aicjofs said:
Well look over the zip I posted maybe it can save some time.
Above 4.2 you will need SElinux support in kernel, so I don't 4.3 is going to work.
Click to expand...
Click to collapse
I know but I had to try.
You think I could just ls the vendor file and copy it in to a text file with the right format?
Here is an example from my HTC...
[email protected]:/ $ cd system
[email protected]:/system $ cd vendor
[email protected]:/system/vendor $ ls */*
etc/audio_effects.conf
firmware/acdb.mbn
firmware/apps.mbn
firmware/bcm4335_prepatch.hcd
firmware/dsp1.mbn
firmware/dsp2.mbn
firmware/dsp3.mbn
firmware/efs1.mbn
firmware/efs2.mbn
firmware/efs3.mbn
firmware/htc61.mbn
firmware/htc62.mbn
firmware/htc63.mbn
firmware/htc64.mbn
firmware/htc65.mbn
firmware/htccdma.mbn
firmware/htcnvbak.mbn
firmware/htcrcust.mbn
firmware/htcrfnv.mbn
firmware/htcsmem.mbn
firmware/htcssmem.mbn
keymaster.b00
keymaster.b01
keymaster.b02
keymaster.b03
keymaster.mdt
firmware/mdm_acdb.img
firmware/q6.b00
firmware/q6.b01
firmware/q6.b03
firmware/q6.b04
firmware/q6.b05
firmware/q6.b06
firmware/q6.mdt
firmware/rpm.mbn
firmware/sbl1.mbn
firmware/sbl1_82.mbn
firmware/sbl1_92.mbn
firmware/sbl1_96.mbn
firmware/sbl2.mbn
eglsubAndroid.so
libEGL_adreno.so
libGLESv1_CM_adreno.so
libGLESv2S3D_adreno.so
libGLESv2_adreno.so
libq3dtools_adreno.so
power.msm8960.so
lib/libC2D2.so
lib/libQSEEComAPI.so
lib/libRSDriver_adreno.so
lib/libWVStreamControlAPI_L1.so
lib/libadreno_utils.so
lib/libbt-vendor.so
lib/libc2d30-a3xx.so
lib/libc2d30.so
lib/libgsl.so
lib/libllvm-a3xx.so
lib/libqc-opt.so
lib/librs_adreno.so
lib/librs_adreno_sha1.so
lib/libsc-a3xx.so
lib/libwvm.so
detection
recognition
[email protected]:/system/vendor $
I attempted to install Jasmine rom, after it failed twice I tried to recover and failed at that. Then after trying to resinstall twrp i got it into a bootloop and no recovery and no download and no recovery.
I need the following .img for the LG G3 vs985 to try to use the method in the link below:
NEED THESE FILES:
1- sbl1.img
2- aboot.img
3- rpm.img
4- tz.img
http://forum.xda-developers.com/showthread.php?t=2582142
Here are the files from 10b:
http://downloads.codefi.re/autoprime/LG/LG_G3/VS985/stock_partitions/10B
Be careful (those are things that mere mortals like I wouldn't mess with )
THANK YOU!!
markfm said:
Here are the files from 10b:
http://downloads.codefi.re/autoprime/LG/LG_G3/VS985/stock_partitions/10B
Be careful (those are things that mere mortals like I wouldn't mess with )
Click to expand...
Click to collapse
Thank you very much. now i just need to figure out why It wont show me the locations of all those files when i enter the terminal in linux... I'm getting something like this:
Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: not present
************************************************** *****************************************
Found invalid GPT and MBR valid; Converting MBR to GPT format in memory.
************************************************** *****************************************
Disk /dev/sda: 625142448 sectors, 298.1 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 4746570D-B91E-4A91-917C-D94BCEBD34F3
Partitions table holds up to 128 entries
First usable sector in 34, last usable sector is 625142414
Partitions will be aligned on 2048-sector boundaries
Total free space is 310512237 sectors (148.1 GiB)
Number Start (sector) End (sector) Size Code Name
1 2048 52430847 25.0 GiB 0700 Microsoft Basic data
2 52430848 314632191 125.0 GiB 0700 Microsoft Basic data
Only this was copied from another post. I am using linux.
Any suggestions?
No idea. What you posted doesn't make sense to me. Hopefully someone else will pop in.
I copied from another post but I am getting roughly the same response when I rum the gdisk Dev command in Linux terminal. It does recognize the device as lg. But it doesn't appear to find the device while running the command to see the list of img files.
Also having trouble coding the file extension to push the img files with dd command.
good morning,
I've got 3 galaxy S4 (I-9505) and for some purpose (and testing) I want to clone one into another one (just to test strange different behaviours between two of them, apparently with same android version etc).
I dumped the full internal eeprom, as a 16GB file, with dd throw adb, and now I'm trying to restore this image in another phone.
the destination phone has CWM recovery installed and booted, the image is visible from external sd, but I've tried with netcat as well...
what happens is that after writing to /dev/block/mmcblk0, after average 30MB I receive an input/output error, and adb crashed. on the phone the recovery appears active, but not fully working... if I choose any menu it waits forever. phone is not detected ltil I restart it in recovery again.
I tried moving ahead with "dd seek & skip" to start a bit further and the same happens.
it works only if I start from the efs partition.
this is my layout:
Number Start End Size File system Name Flags
1 8192s 33735s 25544s apnhlos
2 33736s 139263s 105528s mdm
3 139264s 139519s 256s sbl1
4 139520s 140031s 512s sbl2
5 140032s 141055s 1024s sbl3
6 141056s 145151s 4096s aboot
7 145152s 146175s 1024s rpm
8 146176s 147199s 1024s tz
9 147200s 180991s 33792s pad
10 180992s 208895s 27904s ext4 efs
11 208896s 215039s 6144s modemst1
12 215040s 221183s 6144s modemst2
13 221184s 222743s 1560s m9kefs1
14 222744s 224303s 1560s m9kefs2
15 224304s 225863s 1560s m9kefs3
16 225864s 5878343s 5652480s ext4 system
17 5878344s 5894727s 16384s persist
18 5894728s 10134087s 4239360s ext4 cache
19 10134088s 10146375s 12288s param
20 10146376s 10166855s 20480s boot
21 10166856s 10187335s 20480s recovery
22 10187336s 10207815s 20480s fota
23 10207816s 10220103s 12288s backup
24 10220104s 10226247s 6144s fsg
25 10226248s 10226263s 16s ssd
26 10226264s 10244695s 18432s ext4 persdata
27 10244696s 11268695s 1024000s ext4 hidden
28 11268696s 11309655s 40960s carrier
29 11309656s 30765655s 19456000s ext4 userdata
so if I start writing from sector 180992 it goes up to the end and the phone boots.
what could be the cause of not being able to write from the beginning?
david
I suppose it's the bootloader protecting from writing operation in sensible area. but I thought it was not acting while raw writing the block device.
guess it fails when trying to write in the same area where odin refuses non-signed .bin files.
I've two jtag boxes... so the only way to flash the whole mmcblk0 image is through jtag interface (luckily confortable on the S4)?
guess so as well. but as you said I thought it didn't act like that raw writing.
I've got 2 jtag box as well, and will give a try with them. yes S4 is nice with that, with large confortable pads.
david