The structure of the PIT is defined below:-
Code:
Based on PIT GT-I9300_mx_20120329.pit
Block Size = 0x200
Partition Name Image Name LEN LEN in BLK OS Partition Physical Partition
BOOTLOADER sboot.bin 0x000D8C00 0x06C6 0x50 0x50
TZSW tz.img 0x00027000 0x0138 0x51 0x51
PIT mx.pit 0x00002000 0x0010 0x46 0x46
MD5HDR md5.img 0x00100000 0x0800 0x47 0x47
BOTA0 - 0x00400000 0x2000 0p1 0x01
BOTA1 - 0x00400000 0x2000 0p2 0x02
EFS efs.img 0x01400000 0xA000 0p3 0x03
PARAM param.bin 0x00800000 0x4000 0x4 0x04
BOOT boot.img 0x00800000 0x4000 0p5 0x05
RECOVERY recovery.img 0x00800000 0x4000 0p6 0x06
RADIO modem.bin 0x02000000 0x10000 0p7 0x07
CACHE cache.img 0x40000000 0x200000 0p8 0x08
SYSTEM system.img 0x60000000 0x300000 0p9 0x09
HIDDEN hidden.img 0x23000000 0x118000 0p10 0x0A
OTA - 0x00800000 0x4000 0p11 0x0B
USERDATA userdata.img 0x00000000 0x0000 0p12 0x0C
The offsets in the flash are as follows:-
Code:
Flash Reserved Area 0
Partition Name Start Address
BL1 0x0000000000000000
BL2 0x0000000000002000
BL3 0x0000000000006000
uTZ 0x00000000000D6800
TZSW 0x00000000000D8C00
DDI 0x00000000000FFC00
Flash Reserved Area 1
<empty>
Flash User Area
Partition Name Start Address Mount Point
GUID Header 0x0000000000000000
GPT Header 0x0000000000000200
PIT 0x0000000000004400
MD5HDR 0x0000000000006400
BOTA0 0x0000000000400000
BOTA1 0x0000000000800000
EFS 0x0000000000C00000 /efs
PARAM 0x0000000002000000 /param
BOOT 0x0000000002800000 /boot
RECOVERY 0x0000000003000000 /recovery
RADIO 0x0000000003800000 /radio
CACHE 0x0000000005800000 /cache
SYSTEM 0x0000000045800000 /system
HIDDEN 0x00000000A5800000 /preload
OTA 0x00000000C8800000
USERDATA 0x00000000C9000000 /data (this is grown on the remaining flash space, depending on the model 16/32/64)
thanks
Chenglu said:
thanks
Click to expand...
Click to collapse
I only got my i9300 yesterday so this info is not complete and COULD contain errors, this thread will be updated as and when I find other info out.
As listed on this thread, the US version.
http://forum.xda-developers.com/showthread.php?t=1739426
The use of dd;
dd if=/sdcard/recovery.img of=/dev/block/mmcblk0p18
Click to expand...
Click to collapse
Where as the Asian variant of GS3 is on different block 0p6 instead.
Is it a normal practice to writing the recovery.img by using dd?
Or was it just used purely to escape from increasing the flash counter?!
I have a question
GT-I9300_mx_20120329.pit can used for 32GB(S3) ?
sorry my bad english
rulala said:
I have a question
GT-I9300_mx_20120329.pit can used for 32GB(S3) ?
sorry my bad english
Click to expand...
Click to collapse
You have 32Gb SGS3?
If so contact me via PM and we can read your current pit and check.
Which *.pit-file is correct for the 16GB Version?
GT-I9300_mx_20120220.pit
GT-I9300_mx_20120322.pit
GT-I9300_mx_20120329.pit
M0_20120220.pit
M0_20120220.pit
I dont want to flash with the wrong file
Thanks
Blindi1985 said:
I dont want to flash with the wrong file
Click to expand...
Click to collapse
Why do you feel you need to flash with a pit file?
A noob Question, Can we access OTA partion, the OTA file which is downloaded can be accessed before flashing it?
ZACQ8 said:
A noob Question, Can we access OTA partion, the OTA file which is downloaded can be accessed before flashing it?
Click to expand...
Click to collapse
The OTA files are stored in the cache partition, check it out with root explorer
I'm just being nooby, what does this thread do? will it later become a rom?
It would be useful and interesting to know what is inside and the function of the various partition images. For example, why is there a cache image? I would have assumed the default cache.img should have been empty.
In addition what is the "new" TZSW partition? I've never heard of this one before. Finally, is the GT-I9300 PARAM the same as for I9100?
E:V:A said:
what is the "new" TZSW partition? I've never heard of this one before.
Click to expand...
Click to collapse
ARM Trusted Zone
E:V:A said:
the GT-I9300 PARAM the same as for I9100?
Click to expand...
Click to collapse
Function is the same but format is different, i9300 file is a tar.
Partition Table for I9300 vs SGS&SGSII
mmcblk0p1 BOTA0 = sboot.bin = boot.bin
mmcblk0p2 BOTA1 = sboot. bin = Sbl.bin
mmcblk0p3 EFS = efs.img = efs.img
mmcblk0p4 PARAM = param.bin = param.lfs
mmcblk0p5 BOOT = boot.img = zImage
mmcblk0p6 RECOVERY = recovery.img = no
mmcblk0p7 RADIO (MODEM) = modem.bin = modem.bin
mmcblk0p8 CACHE = cache.lmg = cache.img
mmcblk0p9 SYSTEM = system.img = factoryfs.img
mmcblk0p10 HIDDEN = hidden.img = hidden.img
mmcblk0p11 OTA = data = data.img
mmcblk0p12 USERDATA = userdata.img = UMS.img
SGS3 32GB Internal memory
If guys u need any kind of help. Soooo most welcome
@odia
Thanks for the infomation about mmcblk0p4 (param.bin).
There are 26 jpg images in this partition - one is the boot logo.
I replace the boot logo (logo.jpg) and reflashed mmcblk0p4, but the original boot logo is showing.
Do you know if there is a backup of this partition somewhere?
Or, if the logo.jpg (boot logo) is in the SBL partition?
I know I flashed it correctly, as I copied it back and dumped it. It was as I created it.
BTW - I had no errors on boot because of my changes.
Edit: I did clear the cache
Thanks.
gcrutchr said:
@odia
Thanks for the infomation about mmcblk0p4 (param.bin).
There are 26 jpg images in this partition - one is the boot logo.
I replace the boot logo (logo.jpg) and reflashed mmcblk0p4, but the original boot logo is showing.
Do you know if there is a backup of this partition somewhere?
Or, if the logo.jpg (boot logo) is in the SBL partition?
I know I flashed it correctly, as I copied it back and dumped it. It was as I created it.
BTW - I had no errors on boot because of my changes.
Edit: I did clear the cache
Thanks.
Click to expand...
Click to collapse
Yes logo.jpg is also part of sboot (sboot has 8 JPEGs) so that must be taking over.
I have a 32gb S3 unlocked and rooted if you need any information.
Odia said:
Yes logo.jpg is also part of sboot (sboot has 8 JPEGs) so that must be taking over.
Click to expand...
Click to collapse
Thanks for the response!
Odia said:
Why do you feel you need to flash with a pit file?
Click to expand...
Click to collapse
Since SGS1, thru SGS2 (although not recommended by devs) I always flashed lowship firmwares (with data.img) and pit. Just to be sure that everything is overwritten... If I had data.img (userdata) I could do with SGS3 as well...
Related
Hello,
After a failed attempt to install VEGAn-TAB GingerEdition on my Malata Zpad, I followed an advice on a thread to reflash the tablet with nvflash.
I made a big mistake at that time and flashed a Gtablet configuration.
This stuck me in APX mode, without anything on screen (for the first flash operation, I get one line telling I was in this mode, but after that I never saw this line again).
I can put the tablet is in APX mode (lsusb gives: Bus 001 Device 110: ID 0955:7820 NVidia Corp.). I can read slowly some elements using nvflash and --rawdeviceread (552 sectors at a time only) from my Linux computer. If I try to read too many byte, I get "data receive failure NvError 0x120000". I also have to switch the tablet on and off one or two times between each read attempt. Patiently reading sectors and assembling them on the computer with commands like cat, dd, od -x and the like, I get the impression that most of the gtablet configuration has been written (including PT but not BCT, or it was overwritten later), but there were some errors (binary files differ after some hundreds of thousands bytes).
However, most of the commands I send with nvflash fail as never completing or sending only the bootloader and not the other files, or sending the bct and stopping ... I also tried to use --rawdevicewrite but was able to overwrite neither BCT nor PT partitions. In fact, after the rawdevicewrite attempt, now rawdeviceread returns lots of alternating series of ffffffff and 000000. It also seem that if I read at the sectors corresponding to partitions BCT and PT, I get the same patterns, but if I do a --getBCP I get "normal" bytes (first line of od -x shows: 0000000 b380 6840 476e 15b9 23f1 5b07 18d2 8a58 ...). I think the fffff and 0000 are really there and correspond to write errors, but cannot be sure.
I also tried using directly --download to put the BCT partition but got another error: "failed executing command 14 NvError 0x120002 / command failure: partition download failed (bad command)". If I try the same command on partition 4 (EBT, with the bootloader) the bytes are sent but the error becomes "failed executing command 25 NvError 0x120000 / command failure: sync failed".
I don't understand what happens and how I can flash a working configuration again.
I have made some very small progress.
I now can see the following line on the tablet when nvflash has sent the appropriate bootloader (the one I used before was corrupted):
Code:
Entering NvFlash recovery mode / Nv3p server
This bootloader however does not support the --getbct command, it replies:
Code:
Failed sending command 2 NvError 1179650command failure: getbct failed (bad data)
bootloader status: operation not implemented (code: 3) message: nverror:0x1 (0x1) flags: 0
So I have to switch to another bootloader (fastboot.bin, retrieved from an ac100 forum) to get the BCT.
I can use --download without errors, so I tried to download recovery.img from cwm 0.8 into partition 9 as a recovery boot, hoping to repartition my tablet from CWM. No error on download, but nothing happens if I try to reboot in recovery mode (I guess this boot image is used when powering up the tablet while Vol+ is pressed. Rereading the first 94MB of the flash memory, I searched for the header bytes of recovery.img but did not found them (the longest match I found were only 8 bytes long), so I think --download did not download anything.
So I am still stuck with an unusable tablet.
Could someone give me some advice ?
Another strange thing I get is when I try to reset the BCT after having sent the bootloder to the tablet in a previous command. I use:
Code:
sudo ../nvflash --bct Malata_a02_12Mhz_H5PS1G83EFR-S6C_333Mhz_1GB_2K8Nand_HY27UF084G2B-TP.bct --setbct --configfile android_fastboot_full.cfg --odmdata 0xbb0c0011 --create --go
Then I get messages about creating BCT, PT and EBT partitions, followed by a message about BCT being full and unable to add a new boot loader. I'm not sure anything has really been written on the tablet.
Does anyone know how to empty the BCT before attempting to relaunch the previous flash operation ?
It seems I am the only one in this thread and nobody wants to help me.
Current status is that I am still stuck. I can write at some places using nvflash --rawdevicewrite, but not everywhere. Even in the middle of the memory, I had write operations where the first 64kbytes of the write were replaced by ffff, then the following 64k bytes were written properly, and the rest was again replaced by ffff. Trying to write blocks smaller than 64k did not help, it is as if the target sector was corrupted (depite at the beginning it did not contain ffff, but a part of the initial flash).
Then I tried reformating the partitions. Some succeeded, some didn't.
Then I read in nvflash internal help (using nvflash --cmdhelp --format_all) the --format_all would reformat also the BCT an PT partitions, using the provided configfile. It was exactly what I needed! I tried it:
Code:
sudo ../nvflash --configfile android_fastboot_full.cfg --format_all --bl bootloader.bin --go
and it failed with the error messages
Code:
waiting for bootloader to initialize
bootloader downloaded successfully
Formatting all partitions please wait.. bootloader status: partition table is required for this command (code: 8) message: nverror:0x4 (0x4) flags: 0
FAILED!
formatting failed
format-all failed
NvError 0x0
It looks as if the --format_all which should create the partition table needs the partition table, and cannot only use the provided configuration file. This seems rather strange to me, so I may miss something obvious.
Please, help me.
unbricked!
I finally got the device unbricked.
Since I always got messages about full BCT, I finally decided to try to reset it with nvflash --rawdeviewrite. The BCT is at the very beginning of the memory (from block 0 included to block 1536 excluded). It starts with 16 bytes of magic numbers: b380 6840 476e 15b9 23f1 5b07 18d2 8a58, followed by 16 bytes set to 0, followed by the 4080 bytes you find in the various bct files lying around these threads. This pattern seems to be repeated several times, each 64k, so I thought it could hold several configuration (1536 blocks of 2048 bytes each can hold a bunch of such 64k sections).
So I forged a first 64k block from the magick numbers, the zeros, my Malata_a02_12Mhz_H5PS1G83EFR-S6C_333Mhz_1GB_2K8Nand_HY27UF084G2B-TP.bct file and filled the rest with ffff. I wrote this to the tablet and ... it did only write a long series of ffff. So I have finally completely overwritten my BCT with garbage
After that, almost all nvflash operations failed, even simply downloading the bootloader. Error messages were either bad data, or missing partition table, or BCT related.
I tried several bootloaders, fastboot.bin from an ac100 thread the bootloader from the dropbox link in Roebeet's thread here: http://forum.xda-developers.com/showpost.php?p=9603803&postcount=1, and the one from the Malata image in nvflash_t2_mp_wifi_1202.rar. This last one succeeded. Since I had already used this commands a very large number of times and it always failed before, I think this time it succeeded because I had erased the BCT with my bunch of ffff.
Here are the final command I set and its output:
Code:
sudo ../nvflash --bl bootloader.bin --bct Malata_a02_12Mhz_H5PS1G83EFR-S6C_333Mhz_1GB_2K8Nand_HY27UF084G2B-TP.bct --setbct --configfile an
droid_fastboot_full.cfg --odmdata 0xbb0c0011 --create --go
Nvflash started
rcm version 0X20001
System Information:
chip name: t20
chip id: 0x20 major: 1 minor: 3
chip sku: 0x8
chip uid: 0x17144040432025d7
macrovision: disabled
hdcp: enabled
sbk burned: false
dk burned: false
boot device: nand
operating mode: 3
device config strap: 0
device config fuse: 0
sdram config strap: 0
sending file: Malata_a02_12Mhz_H5PS1G83EFR-S6C_333Mhz_1GB_2K8Nand_HY27UF084G2B-TP.bct
- 4080/4080 bytes sent
Malata_a02_12Mhz_H5PS1G83EFR-S6C_333Mhz_1GB_2K8Nand_HY27UF084G2B-TP.bct sent successfully
odm data: 0xbb0c0011
downloading bootloader -- load address: 0x108000 entry point: 0x108000
sending file: bootloader.bin
| 928956/928956 bytes sent
bootloader.bin sent successfully
waiting for bootloader to initialize
bootloader downloaded successfully
setting device: 1 0
creating partition: BCT
creating partition: PT
creating partition: EBT
creating partition: NVC
creating partition: MBT
creating partition: BLO
creating partition: MSC
creating partition: KLO
creating partition: OGO
creating partition: SOS
creating partition: LNX
creating partition: APP
creating partition: CAC
Formatting partition 2 BCT please wait.. done!
Formatting partition 3 PT please wait.. done!
Formatting partition 4 EBT please wait.. done!
Formatting partition 5 NVC please wait.. done!
Formatting partition 6 MBT please wait.. done!
Formatting partition 7 BLO please wait.. done!
Formatting partition 8 MSC please wait.. done!
Formatting partition 9 KLO please wait.. done!
Formatting partition 10 OGO please wait.. done!
Formatting partition 11 SOS please wait.. done!
Formatting partition 12 LNX please wait.. done!
Formatting partition 13 APP please wait.. done!
Formatting partition 14 CAC please wait.. done!
done!
sending file: bootloader.bin
| 928956/928956 bytes sent
bootloader.bin sent successfully
sending file: bootloader.bin
| 928956/928956 bytes sent
bootloader.bin sent successfully
sending file: mbtdata.img
- 1024/1024 bytes sent
mbtdata.img sent successfully
sending file: boot.bmp
- 1843254/1843254 bytes sent
boot.bmp sent successfully
sending file: boot.bmp
- 1843254/1843254 bytes sent
boot.bmp sent successfully
sending file: logodata.img
| 418176/418176 bytes sent
logodata.img sent successfully
sending file: recovery.img
/ 3362816/3362816 bytes sent
recovery.img sent successfully
sending file: boot.img
| 2758656/2758656 bytes sent
boot.img sent successfully
sending file: system.img
- 152334336/152334336 bytes sent
system.img sent successfully
After that, the tablet rebooted automatically, with the Malata logo.
Last few problems were that it was in chinese and with the touch screen not responding. The touch screen problem was due to not understanding the slider at the bottom of the initialization screen was an unlocking slider and should be moved to activate the touch screen. Then I had to search a little to reset the tablet in english.
The last few days have been tiresome, and I would have appreciated getting some help here ...
There were probably a few who were following this thread (myself included), but couldn't help, because we have very little info on the BCT.
Plus you have a ztab, rather than a gtablet.
Congratulations on you success and persistence, and thanks for posting this info.
I do have one question: how'd you figure out what to use for the odmdata? That's another piece of the puzzle w little info....
Jim
Misty soul said:
I finally got the device unbricked.
Since I always got messages about full BCT, I finally decided to try to reset it with nvflash --rawdeviewrite. The BCT is at the very beginning of the memory (from block 0 included to block 1536 excluded). It starts with 16 bytes of magic numbers: b380 6840 476e 15b9 23f1 5b07 18d2 8a58, followed by 16 bytes set to 0, followed by the 4080 bytes you find in the various bct files lying around these threads. This pattern seems to be repeated several times, each 64k, so I thought it could hold several configuration (1536 blocks of 2048 bytes each can hold a bunch of such 64k sections).
So I forged a first 64k block from the magick numbers, the zeros, my Malata_a02_12Mhz_H5PS1G83EFR-S6C_333Mhz_1GB_2K8Nand_HY27UF084G2B-TP.bct file and filled the rest with ffff. I wrote this to the tablet and ... it did only write a long series of ffff. So I have finally completely overwritten my BCT with garbage
After that, almost all nvflash operations failed, even simply downloading the bootloader. Error messages were either bad data, or missing partition table, or BCT related.
I tried several bootloaders, fastboot.bin from an ac100 thread the bootloader from the dropbox link in Roebeet's thread here: http://forum.xda-developers.com/showpost.php?p=9603803&postcount=1, and the one from the Malata image in nvflash_t2_mp_wifi_1202.rar. This last one succeeded. Since I had already used this commands a very large number of times and it always failed before, I think this time it succeeded because I had erased the BCT with my bunch of ffff.
Here are the final command I set and its output:
Code:
sudo ../nvflash --bl bootloader.bin --bct Malata_a02_12Mhz_H5PS1G83EFR-S6C_333Mhz_1GB_2K8Nand_HY27UF084G2B-TP.bct --setbct --configfile an
droid_fastboot_full.cfg --odmdata 0xbb0c0011 --create --go
Nvflash started
rcm version 0X20001
System Information:
chip name: t20
chip id: 0x20 major: 1 minor: 3
chip sku: 0x8
chip uid: 0x17144040432025d7
macrovision: disabled
hdcp: enabled
sbk burned: false
dk burned: false
boot device: nand
operating mode: 3
device config strap: 0
device config fuse: 0
sdram config strap: 0
sending file: Malata_a02_12Mhz_H5PS1G83EFR-S6C_333Mhz_1GB_2K8Nand_HY27UF084G2B-TP.bct
- 4080/4080 bytes sent
Malata_a02_12Mhz_H5PS1G83EFR-S6C_333Mhz_1GB_2K8Nand_HY27UF084G2B-TP.bct sent successfully
odm data: 0xbb0c0011
downloading bootloader -- load address: 0x108000 entry point: 0x108000
sending file: bootloader.bin
| 928956/928956 bytes sent
bootloader.bin sent successfully
waiting for bootloader to initialize
bootloader downloaded successfully
setting device: 1 0
creating partition: BCT
creating partition: PT
creating partition: EBT
creating partition: NVC
creating partition: MBT
creating partition: BLO
creating partition: MSC
creating partition: KLO
creating partition: OGO
creating partition: SOS
creating partition: LNX
creating partition: APP
creating partition: CAC
Formatting partition 2 BCT please wait.. done!
Formatting partition 3 PT please wait.. done!
Formatting partition 4 EBT please wait.. done!
Formatting partition 5 NVC please wait.. done!
Formatting partition 6 MBT please wait.. done!
Formatting partition 7 BLO please wait.. done!
Formatting partition 8 MSC please wait.. done!
Formatting partition 9 KLO please wait.. done!
Formatting partition 10 OGO please wait.. done!
Formatting partition 11 SOS please wait.. done!
Formatting partition 12 LNX please wait.. done!
Formatting partition 13 APP please wait.. done!
Formatting partition 14 CAC please wait.. done!
done!
sending file: bootloader.bin
| 928956/928956 bytes sent
bootloader.bin sent successfully
sending file: bootloader.bin
| 928956/928956 bytes sent
bootloader.bin sent successfully
sending file: mbtdata.img
- 1024/1024 bytes sent
mbtdata.img sent successfully
sending file: boot.bmp
- 1843254/1843254 bytes sent
boot.bmp sent successfully
sending file: boot.bmp
- 1843254/1843254 bytes sent
boot.bmp sent successfully
sending file: logodata.img
| 418176/418176 bytes sent
logodata.img sent successfully
sending file: recovery.img
/ 3362816/3362816 bytes sent
recovery.img sent successfully
sending file: boot.img
| 2758656/2758656 bytes sent
boot.img sent successfully
sending file: system.img
- 152334336/152334336 bytes sent
system.img sent successfully
After that, the tablet rebooted automatically, with the Malata logo.
Last few problems were that it was in chinese and with the touch screen not responding. The touch screen problem was due to not understanding the slider at the bottom of the initialization screen was an unlocking slider and should be moved to activate the touch screen. Then I had to search a little to reset the tablet in english.
The last few days have been tiresome, and I would have appreciated getting some help here ...
Click to expand...
Click to collapse
Hi, how did you manage to restore "nvflash_t2_mp_wifi_1202.rar"...I restored my malata smb-a1011 with the nvflash tutorial posted here: http://forum.xda-developers.com/showthread.php?t=861950 but I'm having major problems and I can't use my hardware keys (i.e. Home, Back, Menu)
any help would be appreciated. Thank you!
jimcpl said:
I do have one question: how'd you figure out what to use for the odmdata?
Click to expand...
Click to collapse
I found a link to a Malata image named nvflash_t2_mp_wifi_1202.rar. the file itself can be found using a web search engine, it seems to be available at several places. In this file, the download.bat script reads:
Code:
"nvflash.exe" --bct Malata_a02_12Mhz_H5PS1G83EFR-S6C_333Mhz_1GB_2K8Nand_HY27UF084G2B-TP.bct --setbct --bl bootloader.bin --configfile android_fastboot_full.cfg --odmdata 0xbb0c0011 --create --go
I also read in this post about using 0xba0c0011 and somewhere else about 0xbc0c0011. However if now I search for this I find a reference to an Adam, not a Zpad.
jimcpl said:
I do have one question: how'd you figure out what to use for the odmdata? That's another piece of the puzzle w little info....
Jim
Click to expand...
Click to collapse
Hi Jim,
Following an idea from one of your posts on another thread, I looked at the binary structure of the BCT as it is retrieved using nvflash --read 2 02-BCT.img.
The partition is composed of 24 exact copies of the same 128 kibibytes block. In this block, bytes 4068, 4069, 4070 and 4071 (counting from 0) are 0x11, 0x00, 0x0c, 0xbb, which appear to be the omddata I set, in reversed order.
So it may be easy to recover the good omddata from any working tablet by dumping its BCT partition and looking at these bytes. It would probably be good to gather this information for all tablets in some reference thread.
I dont know about anyone else but the partition layout on the S3 LTE really bother's me it just wastes so much
has any work been done on seeing if resizing causes any problems
as im tempted to resize cache,system,hidden to pull back 1971mb of space wasted by samsung
then make a custom full odin package with the new partition sizes and flash
clearly i wouldnt be able to use standard samsung packages anymore and would have to make my own
which isnt a problem
All sizes are in true Megabyte/Gigabyte what is called Mib/Gib by people of late
to try and differentiate from the stupid ass rounding hd manufacturers started
TOMBSTONES = 256mb
CACHE = 1024mb
SYSTEM = 1536mb
HIDDEN = 560mb
Leaving 10.8GB for userdata
Im unsure what the tombstones dir is used for so i would be inclined to leave it
but cache can be dropped to 100mb if not using ota updates which i dont
system i could drop to 1024mb and be fine
i dont think hidden is used on the s3 lte
so i could pull back around 1971mb of wasted space
for userdatea with partitions like below
CACHE = 100mb
SYSTEM = 1024mb
HIDDEN = 1mb
Here's the current layout
Note it isnt even 16 fake GB
Model: MMC MAG4FB (sd/mmc)
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 4194kB 8389kB 4194kB BOTA0
2 8389kB 12.6MB 4194kB BOTA1
3 12.6MB 33.6MB 21.0MB ext4 EFS
4 33.6MB 37.7MB 4194kB m9kefs1
5 37.7MB 41.9MB 4194kB m9kefs2
6 41.9MB 46.1MB 4194kB m9kefs3
7 46.1MB 54.5MB 8389kB PARAM
8 54.5MB 62.9MB 8389kB BOOT
9 62.9MB 71.3MB 8389kB RECOVERY
10 71.3MB 164MB 92.3MB fat16 RADIO
11 164MB 432MB 268MB ext4 TOMBSTONES
12 432MB 1506MB 1074MB ext4 CACHE
13 1506MB 3116MB 1611MB ext4 SYSTEM
14 3116MB 3704MB 587MB ext4 HIDDEN
15 3704MB 3712MB 8389kB OTA
16 3712MB 15.8GB 12.0GB ext4 USERDATA
ShonkUK said:
I dont know about anyone else but the partition layout on the S3 LTE really bother's me it just wastes so much
has any work been done on seeing if resizing causes any problems
as im tempted to resize cache,system,hidden to pull back 1971mb of space wasted by samsung
then make a custom full odin package with the new partition sizes and flash
clearly i wouldnt be able to use standard samsung packages anymore and would have to make my own
which isnt a problem
All sizes are in true Megabyte/Gigabyte what is called Mib/Gib by people of late
to try and differentiate from the stupid ass rounding hd manufacturers started
TOMBSTONES = 256mb
CACHE = 1024mb
SYSTEM = 1536mb
HIDDEN = 560mb
Leaving 10.8GB for userdata
Im unsure what the tombstones dir is used for so i would be inclined to leave it
but cache can be dropped to 100mb if not using ota updates which i dont
system i could drop to 1024mb and be fine
i dont think hidden is used on the s3 lte
so i could pull back around 1971mb of wasted space
for userdatea with partitions like below
CACHE = 100mb
SYSTEM = 1024mb
HIDDEN = 1mb
Click to expand...
Click to collapse
You can do it with PIT Magic i did this before for S2 I'd like to do the same thing with s3 but i don't have the PIT file for the international version (My Phone )
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
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
This page is trying to find out which partition is for what ?
Code:
Model: MMC P1J95K (sd/mmc)
Disk /dev/block/mmcblk0: 15302656s
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 131072s 262143s 131072s fat16 modem
2 262144s 265215s 3072s tunning
3 265216s 267263s 2048s traceability
4 267264s 267265s 2s fsc
5 267266s 267281s 16s ssd
6 267282s 268305s 1024s sbl1
7 268306s 269329s 1024s sbl1bak
8 269330s 270353s 1024s rpm
9 270354s 271377s 1024s rpmbak
10 271378s 272401s 1024s tz
11 272402s 273425s 1024s tzbak
12 273426s 275473s 2048s pad
13 275474s 276497s 1024s hyp
14 276498s 277521s 1024s hypbak
15 277522s 280593s 3072s modemst1
16 280594s 283665s 3072s modemst2
17 283666s 285713s 2048s simlock
18 285714s 288785s 3072s efsdata
19 393216s 393279s 64s DDR
20 393280s 396351s 3072s fsg
21 396352s 396383s 32s sec
22 396384s 398431s 2048s aboot
23 398432s 400479s 2048s abootbak
24 400480s 466015s 65536s boot
25 466016s 531551s 65536s recovery
26 531552s 5898239s 5366688s ext2 system
27 5898240s 5963775s 65536s ext4 persist
28 5963776s 6004735s 40960s reserved
29 6004736s 6021119s 16384s splash
30 6021120s 6062079s 40960s ext4 tctpersist
31 6062080s 6082559s 20480s ext4 hdcp
32 6082560s 6082575s 16s fota
33 6082576s 6606863s 524288s ext4 cache
34 6606864s 6608911s 2048s misc
35 6608912s 6613007s 4096s persistent
36 6684672s 6686719s 2048s devinfo
37 6815744s 6816767s 1024s keystore
38 6816768s 6816831s 64s config
39 6816832s 6816959s 128s oem
40 6816960s 6823151s 6192s redbend
41 6823152s 6825199s 2048s ciqbp
42 6825200s 6827247s 2048s ciqap
43 6827248s 15302622s 8475375s ext4 userdata
25. recovery - partition to be used for recovery boots this is allinone image to let you boot when all door closed.
26. system - this is android which is booted once linux bootup and mounted at /system
33. cache - for temporary work usually lost after reboot but not always
43. userdata - this partition hold userdata, internal sd (/storage/sdcard0 or /sdcard), internal app installed mainly mounted at /data
10. tz
11. tzbak - Trusted Zone and back up are trusted zone providers to android
5. ssd - secure software download; "Secure Software Download" is a memory based file system (RAMFS) for secure storage, used to download and store "who knows what" on the eMMC. It is a referenced part in the Remote Storage RPC Client of the MSM kernel.
6. sbl1 - secondary bootloader
7. sbl1bak - secondary bootloader backup
8. rpm - resource and power manager @MotoJunkie01 /rpm is also known as primary bootloader, and flashing this partition should always be avoided if at all possible. /rpm, /sbl1, /tz, and /aboot are all considered bootloaders.
9. rpmbak - resource and power manager backup
24. boot - this partition holds kernel and initrd.gz
15. modemst1 - Modem1 (NV data)
16. modemst2 - Modem2 (NV data)
22. aboot - AP Bootloader {AP has some thing to do with APN configuration}
23. abootbak - AP Bootloader backup
20. fsg - Probably stands for File System (FS) "Golden". According to Samsung documentation, this partition is a "Golden Copy". This is partially confirmed by RE of the PARAM partition, which indicate that this partition should contain a copy of MODEMST1. As such it is a backup of the current EFS2 filesystem. The creation of a FSG is not supported on flash devices and the internal (QMI) DIAG request "EFS2_DIAG_MAKE_GOLDEN_COPY", can only be used to create a backup one time over the life of the device. [80-V1294-11] ref
rest of the partition you write
Good research. /rpm is also known as primary bootloader, and flashing this partition should always be avoided if at all possible. /rpm, /sbl1, /tz, and /aboot are all considered bootloaders (and/or bootloader dependent partitions). Tampering with any of these is the quickest way to hard brick a device beyond repairability. /fsg, in Motorola devices anyway, is considered a radio firmware partition and contains the fsg-id configuration for carrier dependent parameters. I included /fsg in my modem thread (my baseband installer flashes /modem, /fsg, and formats modemst1 & modemst2). The /simlock partition does exactly what it implies. When a network unlock code is entered into the device, the requisite changes are applied to /simlock in order to enable GSM network unlocking. In theory, if an unlocked device's /simlock partition is flashed to a locked device, the locked device also becomes network unlocked. This works on most brands which use a similar partition index for network locking/unlocking. I'll research the partitions you didn't reference and add some additional info.
The /splash partition is the boot logo.
The /splash partition is the boot logo.
If you remove or tamper it you will get beautiful tux icon
Recovery and boot are actually in the same format -- an "ANDROID!" archive containing a kernel, an initrd, and a kernel command line. The recovery is just another kernel and an initrd containing all the files you see in your recovery.
Cache is used for the system communicating with the recovery. The system places a command in a file there telling the recovery to perform a function like factory reset or apply a FOTA. The recovery reads that, does the command, and writes its state and logs back to cache. I don't know what else cache is used for, but FOTA temp files certainly don't download there (they're in /data/data/com.tcl.dmclient/files/last_dlpkgfile on this phone), and the Play Store doesn't download stuff to there when installing apps.
tz/tzbak are something for the ARM Trust Zone, which is a bit like TPM on PCs. It's a function built into the processor that can be used to store keys securely. These partitions contain an ELF file, so I suspect this is a binary that interfaces with or runs inside the Trust Zone, and not the data store for it.
I haven't seen any real info about ssd, but given "Secure Software Download" and that it's only 8 KB, I'm guessing it's used by the baseband for things like updates and SIM apps pushed through the cell network.
The boot sequence as I understand it is rpm -> sbl1 -> aboot -> boot (Linux kernel).
Rpm, sbl1 and tz are updated with each firmware update for this device that I've seen. It looks like the updater changes rpm, sbl1 and tz; and then rpmbak, sbl1bak and tzbak are updated after a successful boot. The updater seems to update both aboot and abootbak though. I determined this by looking at a backup taken after an update and reboot, and one taken after an update and no reboot.
Do you have a link where I can read more about fsg, modemst1/2, EFS2 and EFS2_DIAG_MAKE_GOLDEN_COPY?
Chupi383 said:
Recovery and boot are actually in the same format -- an "ANDROID!" archive containing a kernel, an initrd, and a kernel command line. The recovery is just another kernel and an initrd containing all the files you see in your recovery.
Cache is used for the system communicating with the recovery. The system places a command in a file there telling the recovery to perform a function like factory reset or apply a FOTA. The recovery reads that, does the command, and writes its state and logs back to cache. I don't know what else cache is used for, but FOTA temp files certainly don't download there (they're in /data/data/com.tcl.dmclient/files/last_dlpkgfile on this phone), and the Play Store doesn't download stuff to there when installing apps.
tz/tzbak are something for the ARM Trust Zone, which is a bit like TPM on PCs. It's a function built into the processor that can be used to store keys securely. These partitions contain an ELF file, so I suspect this is a binary that interfaces with or runs inside the Trust Zone, and not the data store for it.
I haven't seen any real info about ssd, but given "Secure Software Download" and that it's only 8 KB, I'm guessing it's used by the baseband for things like updates and SIM apps pushed through the cell network.
The boot sequence as I understand it is rpm -> sbl1 -> aboot -> boot (Linux kernel).
Rpm, sbl1 and tz are updated with each firmware update for this device that I've seen. It looks like the updater changes rpm, sbl1 and tz; and then rpmbak, sbl1bak and tzbak are updated after a successful boot. The updater seems to update both aboot and abootbak though. I determined this by looking at a backup taken after an update and reboot, and one taken after an update and no reboot.
Do you have a link where I can read more about fsg, modemst1/2, EFS2 and EFS2_DIAG_MAKE_GOLDEN_COPY?
Click to expand...
Click to collapse
I can confirm that modemst1 and modemst2 are nv data partitions. The /fsg partition (a configuration which has been used by Samsung and Motorola for many years) is a baseband firmware partition that contains carrier ID and carrier regional information.
---------- Post added at 03:35 AM ---------- Previous post was at 03:33 AM ----------
MotoJunkie01 said:
I can confirm that modemst1 and modemst2 are nv data partitions. The /fsg partition (a configuration which has been used by Samsung and Motorola for many years) is a baseband firmware partition that contains carrier ID and carrier regional information.
Click to expand...
Click to collapse
@Chupi383, Question: have you been able to successfully capture an OTA for this device? If so, where is the OTA stored once downloaded? Thanks for your help on this.
@MotoJunkie01 The downloaded OTA is stored as /data/data/com.tcl.dmclient/files/last_dlpkgfile.
You can also get the download URL for an XML file named "desc" from logcat. You can download desc by using a user agent string spoofer with the user agent "Red Bend Software vDirect Mobile(TM) RedBend-vdm-5.6.0.65". Then that will contain the download URL for the zip itself, which you can download with the same user agent. The fun thing about these zips is once you have the URL for one, you can guess the URLs for other to/from firmware version pairs.