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.
Related
Edit: See Wiki for information on why this can not be accomplished: "summary: 2gb have stuff. other 2gb make phone faster. phone have more faster ram. Phone go faster." (Thanks wrsg)
First, I feel this needs to be in the development section because it's most likely going to require some commands/.zip/custom ROM/whatever to actually be able to use that other 2gb of memory we don't see.
Correct me if I'm wrong but from my understanding, that other 2gb of memory has a backup of STOCK G2 Software (OS/Recovery/etc) and reserved space for updates. Basically meaning memory that's only touched by an OTA or ... gingerbread when that drops.
How would we go about "unlocking" that other half of internal memory? It could be used for apps or possibly even mountable storage (if possible...)
I'm sure this is already a work in progress and I have nothing to offer in the endeavor. Just opening the door for someone to walk through.
If a mod believes this to be in the wrong section, please feel free to move it.
Sent from my T-Mobile G2 using XDA App
philosophics said:
First, I feel this needs to be in the development section because it's most likely going to require some commands/.zip/custom ROM/whatever to actually be able to use that other 2gb of memory we don't see.
Correct me if I'm wrong but from my understanding, that other 2gb of memory has a backup of STOCK G2 Software (OS/Recovery/etc) and reserved space for updates. Basically meaning memory that's only touched by an OTA or ... gingerbread when that drops.
How would we go about "unlocking" that other half of internal memory? It could be used for apps or possibly even mountable storage (if possible...)
I'm sure this is already a work in progress and I have nothing to offer in the endeavor. Just opening the door for someone to walk through.
If a mod believes this to be in the wrong section, please feel free to move it.
Sent from my T-Mobile G2 using XDA App
Click to expand...
Click to collapse
what do you propose?
I believe this thread will be where brains come together. As stated above, I have nothing to offer in the endeavor. Just opening a door for someone to walk through.
When something comes up that works, I will post it in the OP and change the thread title...
Sent from my T-Mobile G2 using XDA App
I think we are getting ahead of ourselves...we need a base/stock rom with su/busybox installed badly! I know the soft bricks are already happening and no one has anything to revert to (that isn't insanely tedious). Besides, nandroid/titanium backup can't fix it every time. I hope someone is working on that first. I'm sure people are looking into accessing the total rom space but if its just partitioned that way... there may be no easy solution. Or at least one that isn't dangerous...
Isn't this supposedly HTC and T-mobile's job!?!
Aren't they supposed to acknowledge this problem already?!
Up until now I have seen NO official words from either HTC or T-mobile. what's up with that? are these guys playing the silence game?
HA!
I just posted same question in "dev question" sticky which has almost no dev questions in it. I believe their may be a barrier to entry to our other 1.9 gigs and that is the actual architecture that our g2 radios live, on the eemc.
Pls feel free to correct me if I am wrong here.
i feel as if the other 2 gigs are partitions that are used for data and cache; jus a thought
s0xpan said:
i feel as if the other 2 gigs are partitions that are used for data and cache; jus a thought
Click to expand...
Click to collapse
all told system, data, and cache 1 gig would be a huge amount. still leaving an unaccounted gig
thats not even taking into account the 512 of rom
haensgn said:
all told system, data, and cache 1 gig would be a huge amount. still leaving an unaccounted gig
thats not even taking into account the 512 of rom
Click to expand...
Click to collapse
true this is true
philosophics said:
Correct me if I'm wrong but from my understanding, that other 2gb of memory has a backup of STOCK G2 Software (OS/Recovery/etc) and reserved space for updates. Basically meaning memory that's only touched by an OTA or ... gingerbread when that drops.
Click to expand...
Click to collapse
I don't think that's been proved, has it, it's just speculation ? i.e. what that extra space is for ?
If anyone has links to proof then of course I'd be very interested, and apologise if I'm wrong.
The "missing" memory might even be unintentional and/or a bug, from what I've seen.
well sir speculation is a part of this whole "think tank" process
nothing needs proof. although if you have any documentation...
From what i saw going through the emmc in 4kbits of code at a time, done by the rooting team. it seems to be part of the architecture but i am waiting for wiser ppl whom have physically cracked this puppy open.
For anyone interested in specifics, you can do some reading here
I believe what you are referring to is the space beyond mmcblk0p28 (on the G2) which begins at block 264551 and ends at block 1048577
reukiodo said:
For anyone interested in specifics, you can do some reading here
Click to expand...
Click to collapse
and also at http://tjworld.net/wiki/Android/HTC/Vision/InstallingCustomOperatingSystem
Though, interestingly I get something a little different when I fdisk -l mmcblk0:
Code:
# busybox fdisk -l /dev/block/mmcblk0
busybox fdisk -l /dev/block/mmcblk0
Warning: deleting partitions after 60
Disk mmcblk0: 2256 MB, 2256535552 bytes
1 heads, 16 sectors/track, 275456 cylinders
Units = cylinders of 16 * 512 = 8192 bytes
Device Boot Start End Blocks Id System
mmcblk0p1 * 1 63 500 4d Unknown
Partition 1 does not end on cylinder boundary
mmcblk0p2 63 71 64 45 Unknown
Partition 2 does not end on cylinder boundary
mmcblk0p3 71 634 4500 46 Unknown
Partition 3 does not end on cylinder boundary
mmcblk0p4 634 1048577 8383544 5 Extended
Partition 4 does not end on cylinder boundary
mmcblk0p5 634 4384 30000 49 Unknown
mmcblk0p6 4384 5946 12500 50 Unknown
mmcblk0p7 5946 6202 2048 51 Unknown
mmcblk0p8 6202 6586 3072 52 Unknown
mmcblk0p9 6586 6842 2048 53 Unknown
mmcblk0p10 6842 6970 1024 54 Unknown
mmcblk0p11 6971 7098 1024 56 Unknown
mmcblk0p12 7099 8192 8751+ 55 Unknown
mmcblk0p13 8193 8577 3072 4a Unknown
mmcblk0p14 8577 8961 3072 4b Unknown
mmcblk0p15 8961 9089 1024 74 Unknown
mmcblk0p16 9089 10208 8957+ 75 Unknown
mmcblk0p17 10209 10240 256 76 Unknown
mmcblk0p18 10241 10369 1024 47 Unknown
mmcblk0p19 10369 10497 1024 34 Unknown
mmcblk0p20 10497 10657 1280 36 Unknown
mmcblk0p21 10657 11744 8701 71 Unknown
mmcblk0p22 11744 12256 4096 48 Unknown
mmcblk0p23 12257 12288 256 73 Unknown
mmcblk0p24 12289 12321 256 31 Unknown
mmcblk0p25 12321 65536 425726+ 83 Linux
mmcblk0p26 65537 235777 1361920+ 83 Linux
mmcblk0p27 235777 261991 209715+ 83 Linux
mmcblk0p28 261991 264551 20480 19 Unknown
mmcblk0p29 634 4384 30000 49 Unknown
mmcblk0p30 4384 5946 12500 50 Unknown
mmcblk0p31 5946 6202 2048 51 Unknown
mmcblk0p32 6202 6586 3072 52 Unknown
mmcblk0p33 6586 6842 2048 53 Unknown
mmcblk0p34 6842 6970 1024 54 Unknown
mmcblk0p35 6971 7098 1024 56 Unknown
mmcblk0p36 7099 8192 8751+ 55 Unknown
mmcblk0p37 8193 8577 3072 4a Unknown
mmcblk0p38 8577 8961 3072 4b Unknown
mmcblk0p39 8961 9089 1024 74 Unknown
mmcblk0p40 9089 10208 8957+ 75 Unknown
mmcblk0p41 10209 10240 256 76 Unknown
mmcblk0p42 10241 10369 1024 47 Unknown
mmcblk0p43 10369 10497 1024 34 Unknown
mmcblk0p44 10497 10657 1280 36 Unknown
mmcblk0p45 10657 11744 8701 71 Unknown
mmcblk0p46 11744 12256 4096 48 Unknown
mmcblk0p47 12257 12288 256 73 Unknown
mmcblk0p48 12289 12321 256 31 Unknown
mmcblk0p49 12321 65536 425726+ 83 Linux
mmcblk0p50 65537 235777 1361920+ 83 Linux
mmcblk0p51 235777 261991 209715+ 83 Linux
mmcblk0p52 261991 264551 20480 19 Unknown
mmcblk0p53 634 4384 30000 49 Unknown
mmcblk0p54 4384 5946 12500 50 Unknown
mmcblk0p55 5946 6202 2048 51 Unknown
mmcblk0p56 6202 6586 3072 52 Unknown
mmcblk0p57 6586 6842 2048 53 Unknown
mmcblk0p58 6842 6970 1024 54 Unknown
mmcblk0p59 6971 7098 1024 56 Unknown
mmcblk0p60 7099 8192 8751+ 55 Unknown
Partition table entries are not in disk order
It looks like my partition table repeats itself, but refers to the same sectors. Does anyone else see this oddity?
cheat sheet:
Code:
adb shell
su
busybox fdisk -l /dev/block/mmcblk0
$ export PATH=/data/local/bin:$PATH
$ su
#busybox fdisk -l /dev/block/mmcblk0
Warning: deleting partitions after 60
Disk /dev/block/mmcblk0: 2332 MB, 2332033024 bytes
1 heads, 16 sectors/track, 284672 cylinders
Units = cylinders of 16 * 512 = 8192 bytes
Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 * 1 63 500 4d Unknown
Partition 1 does not end on cylinder boundary
/dev/block/mmcblk0p2 63 71 64 45 Unknown
Partition 2 does not end on cylinder boundary
/dev/block/mmcblk0p3 71 634 4500 46 Unknown
Partition 3 does not end on cylinder boundary
/dev/block/mmcblk0p4 634 284672 2272311 5 Extended
Partition 4 does not end on cylinder boundary
/dev/block/mmcblk0p5 634 4384 30000 49 Unknown
/dev/block/mmcblk0p6 4384 5946 12500 50 Unknown
/dev/block/mmcblk0p7 5946 6202 2048 51 Unknown
/dev/block/mmcblk0p8 6202 6586 3072 52 Unknown
/dev/block/mmcblk0p9 6586 6842 2048 53 Unknown
/dev/block/mmcblk0p10 6842 6970 1024 54 Unknown
/dev/block/mmcblk0p11 6971 7098 1024 56 Unknown
/dev/block/mmcblk0p12 7099 8192 8751+ 55 Unknown
/dev/block/mmcblk0p13 8193 8577 3072 4a Unknown
/dev/block/mmcblk0p14 8577 8961 3072 4b Unknown
/dev/block/mmcblk0p15 8961 9089 1024 74 Unknown
/dev/block/mmcblk0p16 9089 10208 8957+ 75 Unknown
/dev/block/mmcblk0p17 10209 10240 256 76 Unknown
/dev/block/mmcblk0p18 10241 10369 1024 47 Unknown
/dev/block/mmcblk0p19 10369 10497 1024 34 Unknown
/dev/block/mmcblk0p20 10497 10657 1280 36 Unknown
/dev/block/mmcblk0p21 10657 11744 8701 71 Unknown
/dev/block/mmcblk0p22 11744 12256 4096 48 Unknown
/dev/block/mmcblk0p23 12257 12288 256 73 Unknown
/dev/block/mmcblk0p24 12289 12544 2047 26 Unknown
/dev/block/mmcblk0p25 12545 83968 571391+ 83 Linux
/dev/block/mmcblk0p26 83969 223616 1117183+ 83 Linux
/dev/block/mmcblk0p27 223617 262016 307199+ 83 Linux
/dev/block/mmcblk0p28 262017 264672 21247+ 19 Unknown
/dev/block/mmcblk0p29 264673 264704 256 23 Unknown
/dev/block/mmcblk0p30 634 4384 30000 49 Unknown
/dev/block/mmcblk0p31 4384 5946 12500 50 Unknown
/dev/block/mmcblk0p32 5946 6202 2048 51 Unknown
/dev/block/mmcblk0p33 6202 6586 3072 52 Unknown
/dev/block/mmcblk0p34 6586 6842 2048 53 Unknown
/dev/block/mmcblk0p35 6842 6970 1024 54 Unknown
/dev/block/mmcblk0p36 6971 7098 1024 56 Unknown
/dev/block/mmcblk0p37 7099 8192 8751+ 55 Unknown
/dev/block/mmcblk0p38 8193 8577 3072 4a Unknown
/dev/block/mmcblk0p39 8577 8961 3072 4b Unknown
/dev/block/mmcblk0p40 8961 9089 1024 74 Unknown
/dev/block/mmcblk0p41 9089 10208 8957+ 75 Unknown
/dev/block/mmcblk0p42 10209 10240 256 76 Unknown
/dev/block/mmcblk0p43 10241 10369 1024 47 Unknown
/dev/block/mmcblk0p44 10369 10497 1024 34 Unknown
/dev/block/mmcblk0p45 10497 10657 1280 36 Unknown
/dev/block/mmcblk0p46 10657 11744 8701 71 Unknown
/dev/block/mmcblk0p47 11744 12256 4096 48 Unknown
/dev/block/mmcblk0p48 12257 12288 256 73 Unknown
/dev/block/mmcblk0p49 12289 12544 2047 26 Unknown
/dev/block/mmcblk0p50 12545 83968 571391+ 83 Linux
/dev/block/mmcblk0p51 83969 223616 1117183+ 83 Linux
/dev/block/mmcblk0p52 223617 262016 307199+ 83 Linux
/dev/block/mmcblk0p53 262017 264672 21247+ 19 Unknown
/dev/block/mmcblk0p54 264673 264704 256 23 Unknown
/dev/block/mmcblk0p55 634 4384 30000 49 Unknown
/dev/block/mmcblk0p56 4384 5946 12500 50 Unknown
/dev/block/mmcblk0p57 5946 6202 2048 51 Unknown
/dev/block/mmcblk0p58 6202 6586 3072 52 Unknown
/dev/block/mmcblk0p59 6586 6842 2048 53 Unknown
/dev/block/mmcblk0p60 6842 6970 1024 54 Unknown
Partition table entries are not in disk order
Sent from my HTC Vision using XDA App
... very, very weird.
It reminds me of some of Samsung's boneheaded decisions on the filesystem in their Galaxy S series. Just some real head-scratchers -- like using a journaled FAT filesystem that blocks on write for some stupid reason.
If you really want to be sleuthy, read the #g2root logs from last night, particularly scotty2's diagnosis.
What's the difference between our memory and the vibrants. What makes it mountable on a computer. I know he have an sd card for pix and stuff.who on earth is gunna use 4 gigs on just apps. It would make sense to be able to use it for pix and downloads
I figure it is there for the huge cache. Is that cache disabled when the phone is rooted?
Anomaly said:
I figure it is there for the huge cache. Is that cache disabled when the phone is rooted?
Click to expand...
Click to collapse
... to what huge cache are you referring?
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.
It is usually partition.mbn or partition.bin, but none of these files are present. I know that there is a guide from Geno, but I need to know what files are important for the partitions.
Thanks
We have a mmc card with mbr record. Its just like hdd.
To get the partition layout, do in adb: "su" "fdisk /dev/block/mmcblk0" "p"
Sent from my U8800
Thank you very much.
But is there a way to "replace" the partition values of the u8800 with the u8800-51 values? Because I need to do this in order to use some u8800 files on u8800-51.. Any ideas of how to do it?? Maybe replacing some files?
Thanks again.
I belive the partition layout is same on both phones. What exactly do you want to use?
I added partition info, some may be incorrect though.
On normal U8800:
Code:
Disk /dev/block/mmcblk0: 3959 MB, 3959422976 bytes
1 heads, 16 sectors/track, 483328 cylinders
Units = cylinders of 16 * 512 = 8192 bytes
Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 1 30721 245760 b Win95 FAT32 CUST
Partition 1 does not end on cylinder boundary
/dev/block/mmcblk0p2 * 30721 30783 500 4d Unknown BL1 SBL1
Partition 2 does not end on cylinder boundary
/dev/block/mmcblk0p3 30783 31158 3000 46 Unknown BL2 TZ SBL2
Partition 3 does not end on cylinder boundary
/dev/block/mmcblk0p4 31158 483328 3617363+ 5 Extended EBR
Partition 4 does not end on cylinder boundary
/dev/block/mmcblk0p5 32769 34304 12288 59 Unknown LOGO?
/dev/block/mmcblk0p6 40961 57600 133120 4c Unknown ABOOT
/dev/block/mmcblk0p7 65537 65599 500 5a Unknown MISC - EMPTY
/dev/block/mmcblk0p8 73729 74112 3072 58 Unknown EMPTY
/dev/block/mmcblk0p9 81921 82795 7000 50 Unknown AUDIO?
/dev/block/mmcblk0p10 90113 90496 3072 4a Unknown MODEM_ST1
/dev/block/mmcblk0p11 98305 98688 3072 4b Unknown MODEM_ST2
/dev/block/mmcblk0p12 106497 134656 225280 83 Linux SYSTEM
/dev/block/mmcblk0p13 139265 216064 614400 83 Linux USERDATA
/dev/block/mmcblk0p14 221185 483328 2097152 69 Unknown INTERNAL_SD
Blefish said:
I belive the partition layout is same on both phones. What exactly do you want to use?
I added partition info, some may be incorrect though.
On normal U8800:
Code:
Disk /dev/block/mmcblk0: 3959 MB, 3959422976 bytes
1 heads, 16 sectors/track, 483328 cylinders
Units = cylinders of 16 * 512 = 8192 bytes
Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 1 30721 245760 b Win95 FAT32 CUST
Partition 1 does not end on cylinder boundary
/dev/block/mmcblk0p2 * 30721 30783 500 4d Unknown BL1 SBL1
Partition 2 does not end on cylinder boundary
/dev/block/mmcblk0p3 30783 31158 3000 46 Unknown BL2 TZ SBL2
Partition 3 does not end on cylinder boundary
/dev/block/mmcblk0p4 31158 483328 3617363+ 5 Extended EBR
Partition 4 does not end on cylinder boundary
/dev/block/mmcblk0p5 32769 34304 12288 59 Unknown LOGO?
/dev/block/mmcblk0p6 40961 57600 133120 4c Unknown ABOOT
/dev/block/mmcblk0p7 65537 65599 500 5a Unknown MISC - EMPTY
/dev/block/mmcblk0p8 73729 74112 3072 58 Unknown EMPTY
/dev/block/mmcblk0p9 81921 82795 7000 50 Unknown AUDIO?
/dev/block/mmcblk0p10 90113 90496 3072 4a Unknown MODEM_ST1
/dev/block/mmcblk0p11 98305 98688 3072 4b Unknown MODEM_ST2
/dev/block/mmcblk0p12 106497 134656 225280 83 Linux SYSTEM
/dev/block/mmcblk0p13 139265 216064 614400 83 Linux USERDATA
/dev/block/mmcblk0p14 221185 483328 2097152 69 Unknown INTERNAL_SD
Click to expand...
Click to collapse
Thank you very much. Here is the explanation:
I have a u8800-51 with android 2.2. This version of u8800 had the 1900mhz band for 3g, so for my country (in South America) I had 3g enabled.
Now I updated to gingerbread for u8800pro (because there is no update for u8800-51). It works great, but the only issue is 3g. Edge (2g) works great. This is because the u8800pro doesnt works with 1900mhz WCDMA bands (neither it's software)
I have read that in other android device, you can replace the "ril libs" (with the old ones from u8800-51 Froyo) in the system folder to enable bands (since my device u8800-51 has hardware capability). But for this, you have to also replace with the amss.mbn file associated with those lib files. Everything works when I just replace the lib files, but I still dont get 3g, only 2g. When I now replace the amss.mbn file (with radio values), it doesnt boots. I have read that this is because the partitions are different, so that is why I am asking you this.
Any ideas?
What would happen if you apply 2.2 amss.mbn on 2.3? If it doesn't work, try to replace the 2.3 libs with 2.2 ones and test again.
I'm only guessing this, so it may not work.
Sent from my U8800
Blefish said:
What would happen if you apply 2.2 amss.mbn on 2.3? If it doesn't work, try to replace the 2.3 libs with 2.2 ones and test again.
I'm only guessing this, so it may not work.
Sent from my U8800
Click to expand...
Click to collapse
Yeah, thats what I did, but it doesnt boots. I think that android is detecting that this file (amss.mbn) is not from this version/device. Thats why I am asking about the partitions. Maybe as I am replacing the amss.mbn file by another, the partition values are wrong somehow, and thats why it is not booting. Or maybe that is because of a md5 (checksum)? Any ideas of how to fix this?
pd: sorry for my bad english
It could be that modem is not booting up, yes. But I am not experienced in the modem part. I believe it's being loaded by the primary bootloader, but I am not sure. It would be easier if we'd know what part of the booting up crashes.
Are there differences in mmcblk0p10 and mmcblk0p11 in the 2.2 and 2.3?
Thank you very much for your help but I finally think the important file here is not the amss.mbn. Maybe it just cant be replaced by another. I think the thing is in the ril libs.. and also in the "rild" file in the bin folder. I am trying to get 3g to work now replacing those files.
here is the topic: http://forum.xda-developers.com/showthread.php?p=23407031#post23407031
Thanks again..
Hello!
TL/DR version: I updated a L5 (E612F - Vivo BR) with a V20 KDZ file and the internal storage, that was 8GB is seen by fdisk as ~3GB. There seems to be something wrong with the partition table. Is it possible to revert it back to the original value?
Detailed version:
My girlfriend bought a L5 (E612F - Vivo BR) and urged me to remove all the LG crap that came with the phone.
E612f is known for not being easily rootable and so on, so it was a struggle to put CM10.x in it. After many attempts and a few boot loops, I managed to use an E610 KDZ + E610 recovery and other images from this thread: http://forum.xda-developers.com/showthread.php?t=2186161
The problem is that fdisk reports that the internal SD has only ~3GB of size, but the device ghas 8GB internal SD. Because of that, she gets low space errors all the time:
Code:
1|[email protected]:/ # fdisk -l /dev/block/mmcblk0
Disk /dev/block/mmcblk0: 3909 MB, 3909091328 bytes
1 heads, 16 sectors/track, 477184 cylinders
Units = cylinders of 16 * 512 = 8192 bytes
Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 * 1 3 20 4d Unknown
Partition 1 does not end on cylinder boundary
/dev/block/mmcblk0p2 3 128 1003+ 45 Unknown
Partition 2 does not end on cylinder boundary
/dev/block/mmcblk0p3 129 256 1024 46 Unknown
Partition 3 does not end on cylinder boundary
/dev/block/mmcblk0p4 257 465152 3719168 5 Extended
Partition 4 does not end on cylinder boundary
/dev/block/mmcblk0p5 8193 8704 4096 47 Unknown
/dev/block/mmcblk0p6 8705 9216 4096 2c Unknown
/dev/block/mmcblk0p7 9217 9728 4096 58 Unknown
/dev/block/mmcblk0p8 9729 12800 24576 77 Unknown
/dev/block/mmcblk0p9 12801 13824 8192 48 Unknown
/dev/block/mmcblk0p10 13825 14336 4096 4a Unknown
/dev/block/mmcblk0p11 14337 14848 4096 4b Unknown
/dev/block/mmcblk0p12 14849 18432 28672 49 Unknown
/dev/block/mmcblk0p13 18433 22016 28672 6c Unknown
/dev/block/mmcblk0p14 22017 100096 624640 83 Linux
/dev/block/mmcblk0p15 100353 101376 8192 83 Linux
/dev/block/mmcblk0p16 101377 114176 102400 83 Linux
/dev/block/mmcblk0p17 114177 115200 8192 60 Unknown
/dev/block/mmcblk0p18 115201 116224 8192 83 Linux
/dev/block/mmcblk0p19 116225 117760 12288 6b Unknown
/dev/block/mmcblk0p20 117761 470656 2823168 83 Linux
/dev/block/mmcblk0p21 471041 471552 4096 ff Unknown
/dev/block/mmcblk0p22 471553 471680 1024 ff Unknown
/dev/block/mmcblk0p23 472065 474112 16384 83 Linux
Could the KDZ from another version (E610) be the culprit for this? Any idea how to deal with it? Thanks!
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