For example, in Samsung Galaxy S I9000, the stock partition tables for s1_odin_20100512.pit should look like this:
| NAND disk */dev/block/stl1 - stl6 omitted | |||
| device name | mount point | size in MB | remarks |
| /dev/block/stl7 | n/a | 7.5 | known as KERNEL, for holding zImage |
| /dev/block/stl8 | n/a | 7.5 | known as RECOVERY, for storing a copy of zImage |
| /dev/block/stl9 | /system | 286.5 | known as FACTORYFS |
| /dev/block/stl10 | /dbdata | 134 | known as DBDATA |
| /dev/block/stl11 | /cache | 35 | known as CACHE |
| /dev/block/stl12 | n/a | 7.5 | known as MODEM, for storing modem.bin |
| MMC disk | |||
| device name | mount point | size in MB | remarks |
| /dev/block/mmcblk0p1 | /mnt/sdcard (/sdcard) | ~6200 (8G) / ~14200 (16G) | none |
| /dev/block/mmcblk0p2 | /data | ~2000 | none |
For other pit files like s1_odin_20100513 and s1_odin_20100803, the size of /system and /dbdata are different. So for a larger /system partition, a smaller /dbdata and/or /cache will be resulted and vice versa since the total size of the nand is fixed (~500MB)
When we flash a rom to our phone, the above information will be read by odin to decide where the files will be stored. For instance, the zImage will be written to /dev/block/stl7 (/dev/block/bml7) and /dev/block/stl8 (/dev/block/bml8), while the FACTORYFS.rfs will be stored on /dev/block/stl9 (or /dev/block/bml9) at a specific start block address, up to the size of the file and so forth.
As a result, if we wanna use our own customized partition layout, we have to deal with the pit file and the mmc via fdisk or parted, etc
read more:
Free more available disk space from NAND - PART II
freeNANDmod - get more space from NAND - PART III
freeNANDmod - get more space from NAND - PART IV
for more details, read:
Investigation Into PIT Files
The reality of PIT files
Sign up here with your email
ConversionConversion EmoticonEmoticon