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
Related
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 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
I was running Chucktr's CM11 12.16 rom. Went to turn on phone, and got a black screen after the white HTC boot up screen. When I did get it to boot to the bootloader, the recovery did not work either. I got TWRP 2.8.0.1 installed, and can see from there, that there is problems mounting.
E: Primary block device /dev/block/mmcblk0p35 for mount point '/data' is not present!
E: Unable to recreate and-sec folder.
Updating partition details...
e: Unable to mount '/cache'
E: Unable to mount '/data'
E: Unable to mount '/system'
and so on.
Update 2/22/15: Results of parted
parted /dev/block/mmcblk0
GNU Parted 1.8.8.1.179-aef3
Using /dev/block/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
p
p
Error: Invalid partition table on /dev/block/mmcblk0 -- wrong signature 0.
Ignore/Cancel? i
i
i
Model: MMC KYL00M (sd/mmc)
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 512B 132kB 131kB primary boot
2 132kB 394kB 262kB primary
3 394kB 33.5MB 33.1MB primary
4 33.5MB 15.8GB 15.7GB extended
5 33.5MB 33.6MB 16.4kB logical
6 33.6MB 33.8MB 262kB logical
7 33.8MB 54.8MB 20.9MB logical
8 54.8MB 55.0MB 262kB logical
9 55.0MB 56.1MB 1049kB logical
10 56.1MB 56.3MB 262kB logical
11 56.3MB 58.4MB 2097kB logical
12 58.4MB 59.5MB 1049kB logical
13 59.5MB 59.5MB 32.8kB logical
14 59.5MB 65.8MB 6291kB logical
15 65.8MB 66.8MB 1049kB logical
16 66.8MB 67.1MB 262kB logical
17 67.1MB 109MB 41.9MB logical
18 109MB 151MB 41.9MB logical fat16
19 151MB 159MB 8388kB logical
20 159MB 168MB 8387kB logical
21 168MB 201MB 33.6MB logical fat16
22 201MB 218MB 16.8MB logical
23 218MB 235MB 16.8MB logical
24 235MB 252MB 16.8MB logical
Any ideas on where to start with fixing this?
amgold said:
I was running Chucktr's CM11 12.16 rom. Went to turn on phone, and got a black screen after the white HTC boot up screen. When I did get it to boot to the bootloader, the recovery did not work either. I got TWRP 2.8.0.1 installed, and can see from there, that there is problems mounting.
E: Primary block device /dev/block/mmcblk0p35 for mount point '/data' is not present!
E: Unable to recreate and-sec folder.
Updating partition details...
e: Unable to mount '/cache'
E: Unable to mount '/data'
E: Unable to mount '/system'
and so on.
Update 2/22/15: Results of parted
parted /dev/block/mmcblk0
GNU Parted 1.8.8.1.179-aef3
Using /dev/block/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
p
p
Error: Invalid partition table on /dev/block/mmcblk0 -- wrong signature 0.
Ignore/Cancel? i
i
i
Model: MMC KYL00M (sd/mmc)
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 512B 132kB 131kB primary boot
2 132kB 394kB 262kB primary
3 394kB 33.5MB 33.1MB primary
4 33.5MB 15.8GB 15.7GB extended
5 33.5MB 33.6MB 16.4kB logical
6 33.6MB 33.8MB 262kB logical
7 33.8MB 54.8MB 20.9MB logical
8 54.8MB 55.0MB 262kB logical
9 55.0MB 56.1MB 1049kB logical
10 56.1MB 56.3MB 262kB logical
11 56.3MB 58.4MB 2097kB logical
12 58.4MB 59.5MB 1049kB logical
13 59.5MB 59.5MB 32.8kB logical
14 59.5MB 65.8MB 6291kB logical
15 65.8MB 66.8MB 1049kB logical
16 66.8MB 67.1MB 262kB logical
17 67.1MB 109MB 41.9MB logical
18 109MB 151MB 41.9MB logical fat16
19 151MB 159MB 8388kB logical
20 159MB 168MB 8387kB logical
21 168MB 201MB 33.6MB logical fat16
22 201MB 218MB 16.8MB logical
23 218MB 235MB 16.8MB logical
24 235MB 252MB 16.8MB logical
Any ideas on where to start with fixing this?
Click to expand...
Click to collapse
Are you S-OFF? If you are, grab an RUU (a real RUU that is the EXE file that runs from Windows, not a flashable ZIP) and run it, reflash back to complete stock, and see if you can recovery that way, it is your best chance (sometimes this needs to be done twice)... If you are S-ON, well, you are probably screwed.
The real underlying issue here is WHY did the partition table get corrupted,the life of the flash memory in this device is less than expected by most people... a lot of Rez's die because of failure of the internal flash memory, I have seen several of them myself.
acejavelin said:
Are you S-OFF? If you are, grab an RUU (a real RUU that is the EXE file that runs from Windows, not a flashable ZIP) and run it, reflash back to complete stock, and see if you can recovery that way, it is your best chance (sometimes this needs to be done twice)... If you are S-ON, well, you are probably screwed.
The real underlying issue here is WHY did the partition table get corrupted,the life of the flash memory in this device is less than expected by most people... a lot of Rez's die because of failure of the internal flash memory, I have seen several of them myself.
Click to expand...
Click to collapse
Thanks for your reply. Unfortunately I am S-ON. I've looked unsuccessfully for a way to S-OFF without running software but have not found anything. Starting to feel like I now own a paperweight.
amgold said:
Thanks for your reply. Unfortunately I am S-ON. I've looked unsuccessfully for a way to S-OFF without running software but have not found anything. Starting to feel like I now own a paperweight.
Click to expand...
Click to collapse
Your chances of recovery at this point are very slim then... S-off is not possible on a non-bootable device, you can try multiple recoveries (CWM, TWRP, Amon Ra) and multiple format/wipes and flashing different ZIP packages, once in a while it recovers itself, but without access to the partition table via S-Off the chances are extremely low.
As I said before, the flash RAM in this device seems to be reaching its life span limits for lots of people... Nothing you did, it's just reaching its limits of writes and starting to fail.
acejavelin said:
Your chances of recovery at this point are very slim then... S-off is not possible on a non-bootable device, you can try multiple recoveries (CWM, TWRP, Amon Ra) and multiple format/wipes and flashing different ZIP packages, once in a while it recovers itself, but without access to the partition table via S-Off the chances are extremely low.
As I said before, the flash RAM in this device seems to be reaching its life span limits for lots of people... Nothing you did, it's just reaching its limits of writes and starting to fail.
Click to expand...
Click to collapse
This has to do with normal phone operation, right? Not how many times you've flashed ROMs? Curious because I rarely flash ROMs so wondering if that would mean my phone might have a longer life. I would be fine with it for another couple years.
feralicious said:
This has to do with normal phone operation, right? Not how many times you've flashed ROMs? Curious because I rarely flash ROMs so wondering if that would mean my phone might have a longer life. I would be fine with it for another couple years.
Click to expand...
Click to collapse
Emmc (your phones flash RAM) has a finite number of writes, when it reaches that point there is nothing you can do. It has nothing to do with flashing ROMs, it happens to completely stock devices as well... Like any other product, there are good ones and bad ones, some last longer than others, just the way it is. You didn't cause it to happen, normal use did, it was just it's time.
Is there any way to re-partition ROM eMMC ? since /cache has 500 MB ,it can be re - partitioned to merge into /data partition . so any body here know how to re-partition ROM ? is it possible ?
Parted dump:
Code:
31 106824kB 117268kB 10445kB boot
32 117268kB 127795kB 10527kB recovery
33 127795kB 603980kB 476185kB ext4 cache
34 603980kB 1543504kB 939524kB ext4 system
35 1543504kB 1551892kB 8389kB kpan
36 1551892kB 3958768kB 2406875kB ext4 userdata
Since the "important" partitions are towards the end, something can well be done (as long as you have full OS installation media in zip or nandroid format, plus some tools which may not even be needed on this phone)... If you can wait a week I'll try to write a guide
After some testing, it appears to be impossible, like there is some S-ON on the partition table area...
full partition table needed please..
Ryccardo said:
Parted dump:
Code:
31 106824kB 117268kB 10445kB boot
32 117268kB 127795kB 10527kB recovery
33 127795kB 603980kB 476185kB ext4 cache
34 603980kB 1543504kB 939524kB ext4 system
35 1543504kB 1551892kB 8389kB kpan
36 1551892kB 3958768kB 2406875kB ext4 userdata
Since the "important" partitions are towards the end, something can well be done (as long as you have full OS installation media in zip or nandroid format, plus some tools which may not even be needed on this phone)... If you can wait a week I'll try to write a guide
Click to expand...
Click to collapse
Hey bro, could you please provide me a full partition table in that same format?
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.