I am in the process of flashing a custom rom. My phone is an original unlocked Consumer Cellular which had 2.2.1 installed and later on got an OTA update to 2.2.2.
I rooted the Bravo, made a system dump, installed 2nd-init and created a nandroid backup. As a final check I wanted to look at the partition table and that's when things got interesting. I tried parted but parted terminated with an error message about a partition "beyond" the device's last sector.
Looked around a bit and found out that fdisk is preinstalled in /system/xbin. So I used fdisk and this is what I found:
fdisk's info about the device:
Code:
Disk /dev/block/mmcblk1: 1958 MB, 1958739968 bytes
16 heads, 16 sectors/track, 14944 cylinders
Units = cylinders of 256 * 512 = 131072 bytes
That sounds about right, it is a 2 GByte flash rom. The problem is partition p4 (the "extended" partition) and partition p25 (aka "userdata"). Partition p4 is listed in the partition table as:
Code:
Device Boot Start End Blocks Id System
/dev/block/mmcblk1p4 13 122496 15677952 5 Extended
Well, "start" and "end" are cylinders, so the "end" being 122496 is waaaay beyond 14944! Partition p25 also seems to be messed up the same way:
Code:
Device Boot Start End Blocks Id System
/dev/block/mmcblk1p25 4633 122496 15086592 83 Linux
However, a "cat /proc/partitions" shows this:
Code:
cat /proc/partitions
major minor #blocks name alias
179 32 1912832 mmcblk1
179 33 128 mmcblk1p1
179 34 512 mmcblk1p2
179 35 512 mmcblk1p3
179 36 1 mmcblk1p4
179 37 512 mmcblk1p5
179 38 512 mmcblk1p6
179 39 4096 mmcblk1p7 pds
179 40 512 mmcblk1p8
179 41 512 mmcblk1p9
179 42 1024 mmcblk1p10
179 43 2048 mmcblk1p11
179 44 512 mmcblk1p12
179 45 512 mmcblk1p13
179 46 4096 mmcblk1p14
179 47 8192 mmcblk1p15 boot
179 48 8192 mmcblk1p16 recovery
179 49 14336 mmcblk1p17 cdrom
179 50 512 mmcblk1p18 misc
179 51 512 mmcblk1p19 cid
179 52 4096 mmcblk1p20 kpanic
179 53 334848 mmcblk1p21 system
179 54 512 mmcblk1p22 prek
179 55 512 mmcblk1p23 pkbackup
179 56 204800 mmcblk1p24 cache
179 57 1319936 mmcblk1p25 userdata
179 0 1931264 mmcblk0
179 1 1930240 mmcblk0p1
So besides the partition data which I seem to not understand the size of userdata seems to be 1319936 blocks which is ~1.3 GByte.
This leads to my 2 questions:
Is there a problem here or do I simply misunderstand fdisk's partition list (parted says that is something wrong though!)?
Do I have to try to "fix" this before installing a custom rom (planning on trying cm-10.2-20131030-NIGHTLY-mb520.zip)?
Thanks,
Markus
Ok ... I'm answering my own question here, just in case someone else is interested in the solution:
General Information:
Historically (pc compatible) partitions used to be aligned on cylinder boundaries. Nowadays partitions are usually aligned on a sector number which is a multiple of 2048. For standard 512 sectors this evaluates to a 1 MByte boundary - which is also compatible with drives with a larger sector size (4096 bytes for drives > 2 TByte).
Logical volumes within the extended partition do not use the first head of the first cylinder (or the first 2048 sectors) because the area holds the volume's EBR - which is only a 512 byte record, similar to a MBR.
Implementation in the Motorola Bravo:
The Linux kernel reports 16 heads per cylinder and 16 tracks per head, resulting in 128 kByte per cylinder.
Partitions are aligned to this "virtual" disk geometry.
Digging through the list of EBRs (using dd and hexdump) I found that the partitioning utility used by Motorola creates volumes in the extended partition in a different (but still compatible) way: instead of wasting the first "track" (for the volume's EBR) in each volume, it consolidates all the EBRs in the disk space wasted by the partition entry for the extended partition itself (which usually is 1 cylinder or 2048 sectors).
Motorola actually allocated 512 kByte (1024 sectors) for the extended partition itself, giving the system the theoretical limit of 1024 volumes.
The question still unanswered though is: why does the extended partition (and the last volume in that partition) extend way beyond the end of mmcblk1?
Findings:
I searched around and I discovered that the tool Motorola used to create the partition table was most likely something like nand-part (part of the sunxi tools, please look it up on Wikipedia, I am not allowed yet to post links outside this forum).
This tool creates the EBRs for logical volumes in the same way as they appear in the Bravo's partitions. And most important, this tools also allows to create partitions which extend beyond the end of the device!
Ok ... on with the story: whenever a file system utility like mkfs wants to format a partition, it asks the kernel for information about that partition. The kernel is smart enough to correct partition definitions which extend beyond the end of device in order to avoid a failure or crash of the file system formatting utility. This "correction" is not permanent (partition table stays as it is) but done on the fly.
Conclusions:
nand-part's lack of parameter checking together with the kernel's smartness about partitions exceeding the device made it possible for Motorola to create one common partition layout for devices with different flash capacities: the setup used in the Bravo would be sufficient for flash up to 8 GByte without even changing the partition tables. The last partition (userdata) would simply benefit from a higher flash capacity.
Having answered that question, I still wanted to know what happenes when I try to correct that error (I know, I just asked for trouble). So I went ahead and as a first step I corrected the size in userdata's (mmcblk1p25) EBR to the correct value (using dd and a hex editor). After the correction everything looked fine. The definition of mmcblk1p25 now matched the actual size. I rebooted the phone and ... boom! The bootloader obviously was extremely unhappy and I was forced to do my first "sbf" - which I managed to do and meanwhile my Bravo is happily running CM10.2.
Dear Moderator:
If this post is of any use for the "Dev" section, please move it over there. I do not have the permission (yet) to post in the dev section.
Happy hacking,
Markus
Related
The DZ is advertised by HTC as having 1.5 GB internal storage, but the G2 is advertised as having 4 GB. As proved via teardown pictures (see http://forum.xda-developers.com/showthread.php?t=832686 ), the two phones have exactly the same 4 GB storage chip (NAND), but both also report a lot less memory available to the user (2.1 GB seems to be there if you examine the partitioning).
This has led people to try and investigate where the "missing" memory has gone, e.g. what is using it up, can we get access to it, etc.
This "mystery" seems now to have been solved, and has been posted up in the Wiki at http://forum.xda-developers.com/wiki/index.php?title=HTC_Vision#The_Missing_2GB
A summary of this was kindly posted up by dhkr123 in the G2 forums at http://forum.xda-developers.com/showpost.php?p=9174115&postcount=22 , specifically :
There are 2.1 GB of internal storage addressable by the kernel. This piece of space is divided up into several partitions, for the radio, the SPL, the SYSTEM, the USERDATA, the CACHE, and several other things. All of these partitions are accounted for within the 2.1 GB.
What has been found is that a 1-time write deal to the eMMC is responsible for converting most of the internal storage from MLC (multi-level cell, specifically, 2 bits per cell) into SLC (single-level cell, 1 bit per cell) for the purpose of improving performance and durability.
Specifically, the entire eMMC is 4 GB, and 2.1 GB are accessible, that means that ~200 MB remains MLC, the remaining 3.8 GB is converted into SLC, offering 1.9 GB. 1.9GB + 200MB = 2.1 GB.
Mystery solved, nothing you can do about it.
But understand that it is faster and more reliable like this.
Click to expand...
Click to collapse
So apparently the hardware has been setup so that there is 2.1 GB available for storage for performance and reliability reasons, and it is unlikely this can be changed.
Just found some further explanation and diagrams on this at http://tjworld.net/wiki/Android/HTC/EMMC/UnderstandingUserCapacity
Nice post
Thanks for sharing.
Even with the "hidden" partition, huh... I have installed more apps than never and I still have near-1GB free
And I think the internal mem for process and running system is a great idea since the phone runs smoother than butter
Maybe that's why nobody's talking 'bout apps2sd, which is a common topic @ other phone's fora
How do you have near 1gb free?
CacheMate for me reports 1,078MB (1.07 GB) total data, 338MB used, 760 whatever free, not 2.1GB. Is this with a ROMed DZ, stripped of major components in the system and whatnot? (ie, Sense)
GlitchZero said:
CacheMate for me reports 1,078MB (1.07 GB) total data, 338MB used, 760 whatever free, not 2.1GB.
Click to expand...
Click to collapse
That doesn't sound right at all. But I don't know anything about CacheMate.
It's a root app, clears out the dalvik (I believe) and app caches that have built up, but it shows Total Memory, Memory Used, and Free Memory, and those are my readings, and they are consistent to .01 of a megabyte with what it says in SD & Phone Storage in my Settings.
But there's 2.1 GB total user storage on the phone, so it doesn't sound like it's reporting it correctly ?
Here's the partitioning on a DZ, taken from http://tjworld.net/wiki/Android/HTC/Vision/EmmcPartitioning (duplicate rows deleted, see the link for more details) :
# fdisk -ul /dev/block/mmcblk0
Warning: deleting partitions after 60
Disk /dev/block/mmcblk0: 2332 MB, 2332033024 bytes
1 heads, 16 sectors/track, 284672 cylinders, total 4554752 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 * 1 1000 500 4d Unknown
Partition 1 does not end on cylinder boundary
/dev/block/mmcblk0p2 1001 1128 64 45 Unknown
Partition 2 does not end on cylinder boundary
/dev/block/mmcblk0p3 1129 10128 4500 46 Unknown
Partition 3 does not end on cylinder boundary
/dev/block/mmcblk0p4 10129 4554750 2272311 5 Extended
Partition 4 does not end on cylinder boundary
/dev/block/mmcblk0p5 10130 70129 30000 49 Unknown
/dev/block/mmcblk0p6 70131 95130 12500 50 Unknown
/dev/block/mmcblk0p7 95132 99227 2048 51 Unknown
/dev/block/mmcblk0p8 99229 105372 3072 52 Unknown
/dev/block/mmcblk0p9 105374 109469 2048 53 Unknown
/dev/block/mmcblk0p10 109471 111518 1024 54 Unknown
/dev/block/mmcblk0p11 111520 113567 1024 56 Unknown
/dev/block/mmcblk0p12 113569 131071 8751+ 55 Unknown
/dev/block/mmcblk0p13 131073 137216 3072 4a Unknown
/dev/block/mmcblk0p14 137218 143361 3072 4b Unknown
/dev/block/mmcblk0p15 143363 145410 1024 74 Unknown
/dev/block/mmcblk0p16 145412 163326 8957+ 75 Unknown
/dev/block/mmcblk0p17 163328 163839 256 76 Unknown
/dev/block/mmcblk0p18 163841 165888 1024 47 Unknown
/dev/block/mmcblk0p19 165890 167937 1024 34 Unknown
/dev/block/mmcblk0p20 167939 170498 1280 36 Unknown
/dev/block/mmcblk0p21 170500 187901 8701 71 Unknown
/dev/block/mmcblk0p22 187903 196094 4096 48 Unknown
/dev/block/mmcblk0p23 196096 196607 256 73 Unknown
/dev/block/mmcblk0p24 196609 200702 2047 26 Unknown
/dev/block/mmcblk0p25 200704 1343486 571391+ 83 Linux
/dev/block/mmcblk0p26 1343488 3577854 1117183+ 83 Linux
/dev/block/mmcblk0p27 3577856 4192254 307199+ 83 Linux
/dev/block/mmcblk0p28 4192256 4234750 21247+ 19 Unknown
/dev/block/mmcblk0p29 4234752 4235263 256 23 Unknown
If you add up the sizes of partitions 4, 25, 26 and 27 (i.e. the big ones) then there is 2.1 GB in total. I wonder if CacheMate is only looking at partition 4 (1.1 GB) and not the rest ? I could be way off though.
Not really big news for anyone who's installed SDE and poked around a bit, but I thought I'd post this anyway.
Taken from a 16GB Archos 101. Your results may differ.
Code:
Disk /dev/mmcblk0: 536 MB, 536870912 bytes
4 heads, 16 sectors/track, 16384 cylinders
Units = cylinders of 64 * 512 = 32768 bytes
Device Boot Start End Blocks Id System
/dev/mmcblk0p1 5 1605 51200+ 83 Linux
/dev/mmcblk0p2 1605 5511 125023 83 Linux
/dev/mmcblk0p3 5512 6489 31296 83 Linux
/dev/mmcblk0p4 6490 16384 316640 83 Linux
Disk /dev/mmcblk1: 15.3 GB, 15388901376 bytes
4 heads, 16 sectors/track, 469632 cylinders
Units = cylinders of 64 * 512 = 32768 bytes
Device Boot Start End Blocks Id System
/dev/mmcblk1p1 1 469632 15028216 c Win95 FAT32 (LBA)
Being MMC rather than MTD devices, it ought to be possible to repartition to shuffle some space around, perhaps gaining as much as 50MB extra space for /data.
Additionally, for custom firmwares maybe even repartitioning mmcblk1 may be possible, to create an alternate partition to mount /data/ to.
Of course, for fear of ruining my 101 I have only used fdisk for read-only operations.
don't forget mmcblk2..
it's the external sdcard
Of course I was examining the internal flash storage of the device.
Having my 101 for just under 3 weeks I'm not quite brave enough to repartition mmcblk0, as it would be very difficult to recover an operational system if this were to not go as well as expected. :>
I'm hoping that someone with a little more insight or perhaps a little braver than I could chime in on the possibility.
why won't you repartition (shrink p1 and append other partitions) blk1? (8 / 16 GB storage)
don't touch blk0 when you don't have to
chulri said:
why won't you repartition (shrink p1 and append other partitions) blk1? (8 / 16 GB storage)
don't touch blk0 when you don't have to
Click to expand...
Click to collapse
This was of course my suggestion for alternate firmwares that can take advantage of this.
Moved to general as not android development
In case this info is of use to someone...
Trying to understand what goes where,
Here is the partition table of a U8800:
#######################################
Disk /dev/sdb: 3959 MB, 3959422976 bytes
1 heads, 62 sectors/track, 124729 cylinders, total 7733248 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sdb1 1 491520 245760 b W95 FAT32
/dev/sdb2 * 491521 492520 500 4d QNX4.x
/dev/sdb3 492521 498520 3000 46 Unknown
/dev/sdb4 498521 7733247 3617363+ 5 Extended
/dev/sdb5 524288 548863 12288 59 Unknown
/dev/sdb6 655360 921599 133120 4c Unknown
/dev/sdb7 1048576 1049575 500 5a Unknown
/dev/sdb8 1179648 1185791 3072 58 Unknown
/dev/sdb9 1310720 1324719 7000 50 OnTrack DM
/dev/sdb10 1441792 1447935 3072 4a Unknown
/dev/sdb11 1572864 1579007 3072 4b Unknown
/dev/sdb12 1703936 2154495 225280 83 Linux
/dev/sdb13 2228224 3457023 614400 83 Linux
/dev/sdb14 3538944 7733247 2097152 69 Unknown
#############################################
sdb1: This is the FAT32 partition that gets mounted when we boot into pink screen;
It holds, among other files, EMMCBOOT.MBN, which, if not present and as far as I've experimented, will get the phone straight into a blue screen and initiate a flash procedure if a 'dload' folder with a ROM is found in the sdcard. The contens of this partition are changed when a ROM is flashed.
sdb2: Is flagged as bootable, and holds an (so far) unknown filesystem (if any; could hold a raw binary image, for instance);
sdb3: Holds an unknown filesystem, if any. This partition is changed whenever you flash a ROM. dumping this partition back, from any 2.3BETA, to a 2.3 (B522) running phone, will get the USB pink screen mode working again, allowing acces to sdb1.
sdb5: holds an unknown filesystem if any; dumping this one back gets us the original "IDEOS" logo and, probably, whatever is needed to make previous CWM backups work again.
sdb6: ext3 filesystem with a directory called "recovery".
sdb7: Unknown filessytem, if any.
sdb8: Unknown filesystem, if any.
sdb9: Unknown filesystem, if any.
sdb10: Unknown filesystem, if any.
sdb11: Unknown filesystem, if any.
sdb12: ext3 filesystem; gets mounted at "/system".
sdb13: ext3 filesystem; gets mounted at "/data".
sdb14: vfat filesystem; represents the internal sdcard.
I'm trying to find out what needs to be restored in order to perform a clean, reliable downgrade. sdb5 is a must, but not the only one. I've flashed 2.2 and dumped it back right after. The result is an almost downgraded U8800. I say almost because charging the battery while the phone is off shows a different image (the one that comes with 2.3) and I can't power up the phone unless I take the cable out; this means there are still remnants of 2.3 somewhere...
UPDATE: Not being able to power up the phone was to due to the CWM recovery; restoring original recovery.img solved that one.
I managed to get the system folder. Via http://forum.xda-developers.com/showthread.php?t=1578099
CWM
Instructions and discussion available here
Click to expand...
Click to collapse
CWM Flashable Recovery
Both have been tested by me
Stock Recovery
CWM 6.0.3.6 by Unjustified Dev
Click to expand...
Click to collapse
DOWNLOAD:
System.img (/dev/block/mmcblk0p22)
Boot.img (/dev/block/mmcblk0p20)
Recovery.img (/dev/block/mmcblk0p21)
Modem.img - T599UVAMB5 (/dev/block/mmcblk0p12)
modem.bin (/dev/block/mmcblk0p16)
param.lfs (/dev/block/mmcblk0p19)
Preload.img (/dev/block/mmcblk0p24)
efs.img (/dev/block/mmcblk0p11)
Click to expand...
Click to collapse
Hmmm... can you explain me what is that? Thx
Feyerabend said:
Hmmm... can you explain me what is that? Thx
Click to expand...
Click to collapse
It is for development purposes. It is basically the stock firmware minus the kernel and recovery.
goldfingerfif said:
I uploaded the system tar its almost 1GB I cannot pull the Kernel though.
I managed to get the system folder. Via http://forum.xda-developers.com/showthread.php?t=1578099
If someone can assist with getting the kernel without root I would be forever grateful. If it is unpossible then please let me know as well as I cannot find a root method that works.
Click to expand...
Click to collapse
So, what you basicly need is someone with linux who can make a system.img from this, and add supersu and su binary?
And then someone who makes a factoryreset and flash it in odin I guess..
That person might then be able to extract recovery.img and boot.img. Am I right?
tys0n said:
So, what you basicly need is someone with linux who can make a system.img from this, and add supersu and su binary?
And then someone who makes a factoryreset and flash it in odin I guess..
That person might then be able to extract recovery.img and boot.img. Am I right?
Click to expand...
Click to collapse
You don’t NEED linux, you can use Cygwin with windows, but yes someone can then make system.img or system.tar.md5 with supersu and su.
From there if a root shell is obtained recovery and boot partitions should be able to be extracted from the phone.
Then insecure kernel and custom recovery can be installed.
I’ve done something like this with the T989 but this phone is for someone at my work and so bricking is an issue unlike if it was a personal phone as well there is less motivation to do it if it isn’t mine.
goldfingerfif said:
You don’t NEED linux, you can use Cygwin with windows, but yes someone can then make system.img or system.tar.md5 with supersu and su.
From there if a root shell is obtained recovery and boot partitions should be able to be extracted from the phone.
Then insecure kernel and custom recovery can be installed.
I’ve done something like this with the T989 but this phone is for someone at my work and so bricking is an issue unlike if it was a personal phone as well there is less motivation to do it if it isn’t mine.
Click to expand...
Click to collapse
Somethimg like this I guess? http://forum.xda-developers.com/showthread.php?t=1081239&highlight=odin
tys0n said:
Somethimg like this I guess? http://forum.xda-developers.com/showthread.php?t=1081239&highlight=odin
Click to expand...
Click to collapse
Yes just like that minus the need to unpack it because it is just a tarball so 7zip or whatever should open it fine. I am at work but I believe my home computer has either a linux vm installed or Cygwin with dsixda’s kitchen.
I should be able to manually or through dsixda’s kitchen add supersu and su convert to a odin img and flash.
If it successfully roots so I can at least get a rooted shell so I can dd if=/dev/block/….. of=/sdcard/…img to get a recovery.img and boot.img then carefully cook up a TWRP or CWM recovery to flash then make a “custom” or modified stock rom to flash with insecured kernel.
Anything new on how this is going?
thecasual01 said:
Anything new on how this is going?
Click to expand...
Click to collapse
I added SuperSU.apk and su binary.
Scared to flash it without a known good working factory image. Need to read up on a couple things a little more like triple check I can flash just the system partition without boot, etc.
goldfingerfif said:
I added SuperSU.apk and su binary.
Scared to flash it without a known good working factory image. Need to read up on a couple things a little more like triple check I can flash just the system partition without boot, etc.
Click to expand...
Click to collapse
Excuse me if this may come across as stupid or ignorant, but to my understanding the SGH-T599 seems to be an alternative version of the S3 Mini , I think the main difference is the screen size? That being said, can you not use the current existing kernel, boot.img of the S3 mini? I'm basing this off the fact that I had soft-bricked my phone by attempting to flash CWM Recovery but it didn't work, and I couldn't get myself the stock recovery.img file so in an attempt to revive my phone, I substituted that with the S3 mini's and it worked. Although at first every time i turned on and off the phone it displayed noise (TV Static) but it no longer does so.
I would offer being a test monkey, but this is my only phone and I do not have any other phones that I could use in the scenario it does get bricked.
goldfingerfif said:
I added SuperSU.apk and su binary.
Scared to flash it without a known good working factory image. Need to read up on a couple things a little more like triple check I can flash just the system partition without boot, etc.
Click to expand...
Click to collapse
I think it will be fine to flash system.img only as long as you don't use any pit and repartition. Factory reset first to prevent bootloops.
tamil.soljahz said:
Excuse me if this may come across as stupid or ignorant, but to my understanding the SGH-T599 seems to be an alternative version of the S3 Mini , I think the main difference is the screen size? That being said, can you not use the current existing kernel, boot.img of the S3 mini? I'm basing this off the fact that I had soft-bricked my phone by attempting to flash CWM Recovery but it didn't work, and I couldn't get myself the stock recovery.img file so in an attempt to revive my phone, I substituted that with the S3 mini's and it worked. Although at first every time i turned on and off the phone it displayed noise (TV Static) but it no longer does so.
I would offer being a test monkey, but this is my only phone and I do not have any other phones that I could use in the scenario it does get bricked.
Click to expand...
Click to collapse
Are you saying you used a boot.img from s3 mini?
tamil.soljahz said:
Excuse me if this may come across as stupid or ignorant, but to my understanding the SGH-T599 seems to be an alternative version of the S3 Mini , I think the main difference is the screen size? That being said, can you not use the current existing kernel, boot.img of the S3 mini? I'm basing this off the fact that I had soft-bricked my phone by attempting to flash CWM Recovery but it didn't work, and I couldn't get myself the stock recovery.img file so in an attempt to revive my phone, I substituted that with the S3 mini's and it worked. Although at first every time i turned on and off the phone it displayed noise (TV Static) but it no longer does so.
I would offer being a test monkey, but this is my only phone and I do not have any other phones that I could use in the scenario it does get bricked.
Click to expand...
Click to collapse
What exactly did you use to get it up and running, just the recovery.img, system.img, or boot.img (kernel) you flashed or some combo?
Looks like processor, screen and possibly bluetooth are different
T-599 vs i8190
goldfingerfif said:
What exactly did you use to get it up and running, just the recovery.img, system.img, or boot.img (kernel) you flashed or some combo?
Looks like processor, screen and possibly bluetooth are different
T-599 vs i8190
Click to expand...
Click to collapse
I just flashed the recovery.img, and (incorrectly) came to the assumption that the boot.img and system.img would work on the phone as well. In fact, I realize I can't access recovery. I was asking whether that the S3 mini's boot.img would work on the T599V as well.
Also, according to this link: http://www.sammobile.com/2012/11/24/review-samsung-galaxy-s-iii-mini-gt-i8190-2/
it says the S3 mini uses the U8420 chipset as well, which is why I thought the phones were similar.
tamil.soljahz said:
I just flashed the recovery.img, and (incorrectly) came to the assumption that the boot.img and system.img would work on the phone as well. In fact, I realize I can't access recovery. I was asking whether that the S3 mini's boot.img would work on the T599V as well.
Also, according to this link: http://www.sammobile.com/2012/11/24/review-samsung-galaxy-s-iii-mini-gt-i8190-2/
it says the S3 mini uses the U8420 chipset as well, which is why I thought the phones were similar.
Click to expand...
Click to collapse
The site you linked doesn't mention the SGH-T599 just the GT-8190 and the GT-i9300, did you send the right link?
According to http://www.gsmchoice.com/en/catalogue/samsung/galaxyexhibit/ it's built on same board. ST-Ericsson U8420.
It' same for i8190, some sites say U8500 others say U8420.
The Cydia Impactor root method works on the T599, I just did it to mine. Stays rooted on reboot.
marksalot said:
The Cydia Impactor root method works on the T599, I just did it to mine. Stays rooted on reboot.
Click to expand...
Click to collapse
Cool
So, first guy who "dd" will be hero of the day
If partition layout is the same as i8190 it should look like this.
Code:
GT-I8190 PARTITION LAYOUT
Official Name * Fs * Mount point * Known as * Contents
/efs * ext4 * /dev/block/mmcblk0p11 * Efs folder *Device IMEI,mac address etc
/modemfs * ext4 * /dev/block/mmcblk0p12 * Radio *
/SdCcard * vfat * /dev/block/mmcblk1 /dev/block/mmcblk1p1 * Internal sd * Your stuff
/boot * emmc * /dev/block/mmcblk0p20 * kernel/zimage * Drivers etc
/recovery * emmc * /dev/block/mmcblk0p21 * Recovery partion * ??????
/system * ext4 * /dev/block/mmcblk0p22 * System folder * The operation system
/cache * ext4 * /dev/block/mmcblk0p23 * Cache partition * Update.zips csc,samsung and carriers customizations
/preload * ext4 * /dev/block/mmcblk0p24 * Hidden partition * Media files,apks etc from Samsung/carriers
/.lfs * j4fs * /dev/block/mmcblk0p19 * param.lfs ## * splash screen,charging animation download mode pngs, etc
/data * ext4 * /dev/block/mmcblk0p25 length=-16384 * data folder * Your download apps, current device and use, settings
/temp * ? * /dev/block/mmcblk0p5 * nedded to load *
* * * psccd and CSPSA *
* * * when reset is *
* * * triggered *
* * * *
* * * *
* *
* * * *
I guess boot, recovery, and param is most wanted
Here is the content of /proc/partitions
Code:
major minor #blocks name
7 0 5229 loop0
179 0 3866624 mmcblk0
179 1 128 mmcblk0p1
179 2 384 mmcblk0p2
179 3 1024 mmcblk0p3
179 4 1024 mmcblk0p4
179 5 512 mmcblk0p5
179 6 512 mmcblk0p6
179 7 512 mmcblk0p7
179 8 512 mmcblk0p8
179 9 1024 mmcblk0p9
179 10 1024 mmcblk0p10
179 11 16384 mmcblk0p11
179 12 16384 mmcblk0p12
179 13 16384 mmcblk0p13
179 14 51200 mmcblk0p14
179 15 64 mmcblk0p15
179 16 14336 mmcblk0p16
179 17 2048 mmcblk0p17
179 18 2048 mmcblk0p18
179 19 16384 mmcblk0p19
179 20 16384 mmcblk0p20
179 21 16384 mmcblk0p21
179 22 1228800 mmcblk0p22
179 23 737280 mmcblk0p23
179 24 102400 mmcblk0p24
179 25 1535983 mmcblk0p25
179 64 2048 mmcblk0boot1
179 32 2048 mmcblk0boot0
179 96 15637504 mmcblk1
179 97 15633408 mmcblk1p1
254 0 5229 dm-0
Here is the output of busybox df -h
I have a 16GB SD Card, apparently Maverick (GPS map app I installed) creates it's own partition.
Code:
busybox df -h
Filesystem Size Used Available Use% Mounted on
tmpfs 402.1M 112.0K 401.9M 0% /dev
tmpfs 402.1M 0 402.1M 0% /mnt/asec
tmpfs 402.1M 0 402.1M 0% /mnt/obb
tmpfs 402.1M 0 402.1M 0% /dev/shm
/dev/block/mmcblk0p22
1.2G 965.4M 215.7M 82% /system
/dev/block/mmcblk0p12
15.7M 4.3M 11.4M 28% /modemfs
/dev/block/mmcblk0p23
708.7M 12.0M 696.7M 2% /cache
/dev/block/mmcblk0p11
15.7M 4.5M 11.2M 29% /efs
/dev/block/mmcblk0p24
98.4M 11.6M 86.8M 12% /preload
/dev/block/mmcblk0p25
1.4G 1.3G 173.7M 88% /data
df: /mnt/.lfs: Function not implemented
/dev/fuse 1.3G 1.3G 73.7M 95% /storage/sdcard0
/dev/block/dm-0 5.0M 2.9M 2.1M 57% /mnt/asec/com.codesector.maverick.full-1
/dev/block/vold/179:97
14.9G 10.1G 4.8G 68% /storage/extSdCard
cat /proc/partitions gives me in I8190.
Code:
major minor #blocks name
7 0 16664 loop0
7 1 2111 loop1
7 2 5229 loop2
7 3 2111 loop3
7 4 2111 loop4
7 5 2111 loop5
7 6 2111 loop6
7 7 17703 loop7
179 0 7634944 mmcblk0
179 1 128 mmcblk0p1
179 2 384 mmcblk0p2
179 3 1024 mmcblk0p3
179 4 1024 mmcblk0p4
179 5 512 mmcblk0p5
179 6 512 mmcblk0p6
179 7 512 mmcblk0p7
179 8 512 mmcblk0p8
179 9 1024 mmcblk0p9
179 10 1024 mmcblk0p10
179 11 16384 mmcblk0p11
179 12 16384 mmcblk0p12
179 13 16384 mmcblk0p13
179 14 51200 mmcblk0p14
179 15 64 mmcblk0p15
179 16 14336 mmcblk0p16
179 17 2048 mmcblk0p17
179 18 2048 mmcblk0p18
179 19 16384 mmcblk0p19
179 20 16384 mmcblk0p20
179 21 16384 mmcblk0p21
179 22 1228800 mmcblk0p22
179 23 860160 mmcblk0p23
179 24 327680 mmcblk0p24
179 25 4945920 mmcblk0p25
179 64 2048 mmcblk0boot1
179 32 2048 mmcblk0boot0
179 96 15558144 mmcblk1
179 97 13473792 mmcblk1p1
179 98 2075648 mmcblk1p2
254 0 16663 dm-0
254 1 2110 dm-1
254 2 5229 dm-2
254 3 2110 dm-3
254 4 2110 dm-4
254 5 2110 dm-5
254 6 2110 dm-6
254 7 17703 dm-7
7 8 2111 loop8
254 8 2110 dm-8
7 9 26019 loop9
254 9 26019 dm-9
Looks like it matches pretty well
So, I used the Online Nandroid app, it detects the T599 as "codinatmo" and doesn't have a patch available.
Manually chose the "Samsung Galaxy S III mini GT-l8190" patch and installed.
Was able to back up boot.img and recovery.img, both 16MB.
Can someone explain me how the TPT does the booting? According to the nvidia manual there should be a BCT image somewhere on the device, either in SPI or in eMMC but I can not find it. According to this post: https://forum.xda-developers.com/showthread.php?t=2318140 there should be 16 partitions, but it looks like I only have 10:
Code:
[email protected]:/ # cat /proc/partitions
major minor #blocks name
179 0 15387648 mmcblk0
179 1 6144 mmcblk0p1
179 2 8192 mmcblk0p2
179 3 786432 mmcblk0p3
179 4 921600 mmcblk0p4
179 5 2048 mmcblk0p5
179 6 524288 mmcblk0p6
179 7 20480 mmcblk0p7
259 0 143360 mmcblk0p8
259 1 20480 mmcblk0p9
259 2 12939264 mmcblk0p10
[email protected]:/ # ls -al /dev/block/platform/sdhci-tegra.3/by-name/
lrwxrwxrwx root root 2018-08-16 09:07 AP -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 2018-08-16 09:07 CC -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 2018-08-16 09:07 LX -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 2018-08-16 09:07 MC -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2018-08-16 09:07 PA -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 2018-08-16 09:07 SC -> /dev/block/mmcblk0p7
lrwxrwxrwx root root 2018-08-16 09:07 SS -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 2018-08-16 09:07 UA -> /dev/block/mmcblk0p10
lrwxrwxrwx root root 2018-08-16 09:07 UP -> /dev/block/mmcblk0p8
As p1 is the recovery image and p2 is the kernel, I do not see any more partitions where the BCT image could be.
nvflash does not work on my device, as the APX mode is locked.
What I find a little bit worrying, is that fdisk says I have no partition table:
Code:
[email protected]:/ # fdisk -l mmcblk0
Disk mmcblk0: 15.7 GB, 15756951552 bytes
4 heads, 16 sectors/track, 480864 cylinders
Units = cylinders of 64 * 512 = 32768 bytes
Disk mmcblk0 doesn't contain a valid partition table
Should this command fail?
But there must be the configuration somewhere, right?
I have a TPT 1839-22G
I imaged now the whole eMMC using dd and found out that in difference to the posted partition table, the partitions BCT, PT, EBT and GP1 are missing. the Partitions SOS starts 0x100000 bytes earlier as given in the other thread.
Between 0x0 and 0x00d00000 I can find some non zero bytes but nothing which caught my attention.
Using gdisk I could restore the partition table:
Code:
GPT fdisk (gdisk) version 1.0.3
Unsupported GPT version in backup header; read 0x00000000, should be
0x00010000
Partition table scan:
MBR: not present
BSD: not present
APM: not present
GPT: not present
Creating new GPT entries.
Command (? for help): p
Disk mmcblk0.img: 30775296 sectors, 14.7 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): D3A36F54-6FB0-48C2-B599-DFD0D4E294BF
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 30775262
Partitions will be aligned on 2048-sector boundaries
Total free space is 30775229 sectors (14.7 GiB)
Number Start (sector) End (sector) Size Code Name
Command (? for help): r
Recovery/transformation command (? for help): b
Recovery/transformation command (? for help): p
Disk mmcblk0.img: 30775296 sectors, 14.7 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): D3A36F54-6FB0-48C2-B599-DFD0D4E294BF
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 30775262
Partitions will be aligned on 2048-sector boundaries
Total free space is 30775229 sectors (14.7 GiB)
Number Start (sector) End (sector) Size Code Name
Recovery/transformation command (? for help): c
Warning! This will probably do weird things if you've converted an MBR to
GPT form and haven't yet saved the GPT! Proceed? (Y/N): y
Caution! After loading partitions, the CRC doesn't check out!
Recovery/transformation command (? for help): p
Disk mmcblk0.img: 30775296 sectors, 14.7 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): D3A36F54-6FB0-48C2-B599-DFD0D4E294BF
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 30775262
Partitions will be aligned on 2048-sector boundaries
Total free space is 30653 sectors (15.0 MiB)
Number Start (sector) End (sector) Size Code Name
1 26624 38911 6.0 MiB 0700 体S
2 38912 55295 8.0 MiB 0700 乌X
3 55296 1628159 768.0 MiB 0700 偁P
4 1628160 3471359 900.0 MiB 0700 䅃C
5 3471360 3475455 2.0 MiB 0700 卍C
6 3475456 4524031 512.0 MiB 0700 䥐A
7 4524032 4564991 20.0 MiB 0700 䕓C
8 4564992 4851711 140.0 MiB 0700 单P
9 4851712 4892671 20.0 MiB 0700 䑐A
10 4892672 30771199 12.3 GiB 0700 䑕A
Which also shows, that there are no partitions before 0xd00000.
But where is the BCT stored then?