We can't come through a thread about a firmware or Odin without reading questions by members about what is a pit file and which pit file to use, and all of us did read countless posts that prefers a pit file to another pit file, some say '512.pit do increase performance and is the best to use', others say 'no it's 803.pit that is best'.
I do remember a thread that was made by a member who wanted to flash his device for the first time, and that member had a trouble with how to use Odin and what pit file to use, I did answer that he could use 512.pit or 803.pit and it does not matter which pit file to use, another member did write that using 803.pit is bad and if anyone that is using 803.pit file is only asking for trouble! And of course that was only a claim that was not backed up by facts, 512.pit will not make the device a Superman nor 803.pit will bring Friday the 13th any closer.
I don't blame our members for asking these questions, and they should ask if they search and do not find a real answer, because not much real information have been passed on to them, and that gives place for claims, assumptions and opinions to be passed on as facts, like 're-calibrating the battery of your phone will kill it' or 'you can't flash the modem file only, you need to flash a whole firmware' and so on..
I think that it's time to look into pit files, and see there functions and what they can be used for.
As a Galaxy S user then you are familiar with pit files or short for Partition Information Table files that are 512.pit, 803.pit and 513.pit, these terms of pit files are short for:
The files are all of s1-type to be used with Odin, and if you look at the numbers that is bold, then you will quickly find out that they are dates as in YYYY/MM/DD, these are the dates where these files have been created or released:
Any pit file of the three files above will re-partition the ROM of your device when used into these sectors:
(ROM: Read-Only Memory, ROM is similar to a harddisk on a PC where the information is kept permanently unless changed by the user.)
The interesting partitions are /system and /dbadat, as you can see above, these are the only areas where the space trading is present, and you have the right here to ask if there is any trading while the space allocated for /dbdata is the only one that is changing, well, follow me to see the whole picture.
I did a dump of the system partition on all of the three pit files to find out where the missing 10MB with 803.pit and 20MB with 513.pit of /dbdata are hiding.
Let's look at /system dump while using 512.pit:
A /system dump while using 803.pit:
And a /system dump while using 513.pit:
As seen above, using 803.pit or 513.pit files will only reduce the size of /dbdata while the usable space of /system is kept at 276.3MB.
Anyone now might ask the followings:
Why do you call it usable space and actual size?
Could the usable /system space on 803.pit and 513.pit files be dynamic, means they can expand beyond the usable space if more space on /system is needed?
The answer is no... The usable space is fixed and is not dynamic, hereby the 10MB or 20MB beyond the usable 276.3MB are not usable for /system at all, I tried to copy a file that is 40MB in size while my device was using 513.pit file and had 31.1MB of free space, means that if /system is expandable beyond 276.3MB then the size of /system will be 285.2MB, this is beyond 276.3MB and less than 297.5MB, the copy process did fail because there was no more space available.
We have now reached to the moment of truth:
* Changing a pit file is only a ROM space trade operation between /system and /dbdata, no more or less than that.
* If a user does use 512.pit, 803.pit or 513.pit file then even if the space trading between /system and /dbdata is present but in reality the only change is reducing or increasing /dbdata while not benefiting from space increase of /system as the usable space is kept at 276.3MB no matter what pit file is used.
* Any pit file will not change the performance of the device for better or worse, while /dbdata is not used for more than keeping settings and browsing cache and /system usable space is kept at 276.3MB while being a read-only partition on all pit files.
* Unless we know why the 10MB in 803.pit and the 20MB in 513.pit are traded from /dbdata to /system while not used, then it's hard to tell what is the meaning of releasing these 2 pit files, unless they contain partition fixes that we don't know about.
I do remember a thread that was made by a member who wanted to flash his device for the first time, and that member had a trouble with how to use Odin and what pit file to use, I did answer that he could use 512.pit or 803.pit and it does not matter which pit file to use, another member did write that using 803.pit is bad and if anyone that is using 803.pit file is only asking for trouble! And of course that was only a claim that was not backed up by facts, 512.pit will not make the device a Superman nor 803.pit will bring Friday the 13th any closer.
I don't blame our members for asking these questions, and they should ask if they search and do not find a real answer, because not much real information have been passed on to them, and that gives place for claims, assumptions and opinions to be passed on as facts, like 're-calibrating the battery of your phone will kill it' or 'you can't flash the modem file only, you need to flash a whole firmware' and so on..
I think that it's time to look into pit files, and see there functions and what they can be used for.
As a Galaxy S user then you are familiar with pit files or short for Partition Information Table files that are 512.pit, 803.pit and 513.pit, these terms of pit files are short for:
The files are all of s1-type to be used with Odin, and if you look at the numbers that is bold, then you will quickly find out that they are dates as in YYYY/MM/DD, these are the dates where these files have been created or released:
2010-05-12 (12th of May 2010)
2010-05-13 (13th of May 2010)
2010-08-03 (3rd of August 2010)
Any pit file of the three files above will re-partition the ROM of your device when used into these sectors:
(ROM: Read-Only Memory, ROM is similar to a harddisk on a PC where the information is kept permanently unless changed by the user.)
START
PBL (256KB: Primary Boot Loader: boot.bin)
PIT (*256KB: .pit )
EFS (5.9MB: efs.rfs )
SBL (1.25MB: Secondary Boot Loader: Sbl.bin)
SBL2 (1.25MB: Backup Secondary Boot Loader: Sbl.bin)
PARAM (*640KB: param.lfs)
KERNEL (7.5MB: Primary Kernel: zImage)
RECOVERY (7.5MB: Backup Kernel: zImage)
FACTORYFS (276.3MB: factoryfs.rfs)
DBDATAFS (126.7MB, 117.2MB, 107.2MB (depends on pit file): dbdata.rfs)
CACHE (30.1MB: cache.rfs)
MODEM (12MB: modem.bin)
END
*=Assumed
The interesting partitions are /system and /dbadat, as you can see above, these are the only areas where the space trading is present, and you have the right here to ask if there is any trading while the space allocated for /dbdata is the only one that is changing, well, follow me to see the whole picture.
I did a dump of the system partition on all of the three pit files to find out where the missing 10MB with 803.pit and 20MB with 513.pit of /dbdata are hiding.
Let's look at /system dump while using 512.pit:
Usable /system space: 276.3MB
Actual /system size: 278MB
/dbdata size: 126.7MB
A /system dump while using 803.pit:
Usable /system space: 276.3MB
Actual /system size: 287.5MB
/dbdata size: 117.2MB
And a /system dump while using 513.pit:
Usable /system space: 276.3MB
Actual /system size: 297.5MB
/dbdata size: 107.2MB
As seen above, using 803.pit or 513.pit files will only reduce the size of /dbdata while the usable space of /system is kept at 276.3MB.
Anyone now might ask the followings:
Why do you call it usable space and actual size?
Could the usable /system space on 803.pit and 513.pit files be dynamic, means they can expand beyond the usable space if more space on /system is needed?
The answer is no... The usable space is fixed and is not dynamic, hereby the 10MB or 20MB beyond the usable 276.3MB are not usable for /system at all, I tried to copy a file that is 40MB in size while my device was using 513.pit file and had 31.1MB of free space, means that if /system is expandable beyond 276.3MB then the size of /system will be 285.2MB, this is beyond 276.3MB and less than 297.5MB, the copy process did fail because there was no more space available.
We have now reached to the moment of truth:
* Changing a pit file is only a ROM space trade operation between /system and /dbdata, no more or less than that.
* If a user does use 512.pit, 803.pit or 513.pit file then even if the space trading between /system and /dbdata is present but in reality the only change is reducing or increasing /dbdata while not benefiting from space increase of /system as the usable space is kept at 276.3MB no matter what pit file is used.
* Any pit file will not change the performance of the device for better or worse, while /dbdata is not used for more than keeping settings and browsing cache and /system usable space is kept at 276.3MB while being a read-only partition on all pit files.
* Unless we know why the 10MB in 803.pit and the 20MB in 513.pit are traded from /dbdata to /system while not used, then it's hard to tell what is the meaning of releasing these 2 pit files, unless they contain partition fixes that we don't know about.
For developers and advanced users only:
It all began here: Investigation Into PIT Files*
*Note: Not all informations provided in that thread are correct, but definitely a good read, credit goes to RyanZA, sztupy , Richthofen and all the members that have contributed constructively in that thread.
Last edited: