[GUIDE] [INFO] The reality of PIT files

Search This thread

[Ramad]

Senior Member
Sep 18, 2010
1,162
1,683
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:
s1_odin_20100512.pit
s1_odin_20100513.pit
s1_odin_20100803.pit


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:
igx2dw.jpg


Usable /system space: 276.3MB
Actual /system size: 278MB
/dbdata size: 126.7MB


A /system dump while using 803.pit:
qxwdxk.jpg


Usable /system space: 276.3MB
Actual /system size: 287.5MB
/dbdata size: 117.2MB


And a /system dump while using 513.pit:
2iar4up.jpg


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.


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:

Auzy

Senior Member
Nov 18, 2010
286
21
We need more people like you here.. Not only have you pasted useful information, but you have also backed up the important parts of what you said with evidence (and shown how you tested it, so testing can be repeated).

Bravo.. This oughta put an end to some of the bs being said here..
 

Mothatt

Senior Member
Aug 20, 2010
268
64
Thanks heaps man. I was starting to get sick of explaining this over and over again. :)

Sent from my GT-I9000 using XDA Premium App
 
  • Like
Reactions: senzomon

[Ramad]

Senior Member
Sep 18, 2010
1,162
1,683
Thanks to all of you, the idea is to provide information as easy as possible for the receiver to understand and I hope that our members will find some answers in these few lines and find this post useful. :)
 

jebise101

Senior Member
Jan 22, 2010
931
121
so then then 512 is the best then since it gives you the most dbadata, since system will not let your write over the 276.3MB limit why give it the extra 10-20MB?
 

[Ramad]

Senior Member
Sep 18, 2010
1,162
1,683
so then then 512 is the best then since it gives you the most dbadata, since system will not let your write over the 276.3MB limit why give it the extra 10-20MB?

It's not about which pit file is the best as much as showing what pit files do... We don't have all the informations of why there is several pit files and why the trading between dbdata and system. Please keep it at that and use any pit file you like.
 

Auzy

Senior Member
Nov 18, 2010
286
21
Thanks to all of you, the idea is to provide information as easy as possible for the receiver to understand and I hope that our members will find some answers in these few lines and find this post useful. :)

Not only that I feel.. The main thing here, is that we are seeing a few "professionals" here who are running around telling everyone who disagrees with them that they are "idiots", except when queried about ANY evidence, or the means they used to find the results, they REFUSE to provide it, and they even will tell others they are wrong when OTHERS post evidence (despite the fact they didn't post any).

And it's RUINING XDA. AT least 2 people I spoke with left XDA because they were getting sick of all the people who are filling XDA with Anti-Truths.

So good job, you are my hero..
 
Last edited:

franksames

Senior Member
Jan 5, 2010
52
13
Xiamen
Thanks Ramad,

you do a lot of good work here for us!!!!

there was a explanation of this last year:
http://xdaforums.com/showthread.php?t=816449
But not so easy and straight forward as you did.
The problem here in XDA is that this kind of information get not sticky and pass away. The search function is not so helpful to find this kind of information if it was posted some time ago.

Anyway I really thank you for your work
 

seresseran

Member
Apr 14, 2009
26
3
Thanks Ramad. Very useful information for all of us. Many questions are gone from my mind, but

" Then How the guys at samfirmware decide about the pit file when they release a firmware ?"

As you know, the firmware table at samfirmware points us different pit files for different firmwares. WHY? According to what?
 
Last edited:

pawitp

Inactive Recognized Developer
Oct 30, 2010
3,928
21,276
Bangkok
The reason that you don't see increased space in /system is because the usable size of that partition is recorded in the ROM. If you apply a lagfix to the partition with 513.pit, you will see that the usable space is increased because a new partition is created.

The reason for the increased space in 513.pit, the /system in certain Asian roms (such as DXJPA) needs to be larger to contain the large amount of CSC.
 

Hanafubuki

Member
Jun 25, 2010
18
1
Thank you so much. I was looking for information on those pit files and especially what the differences are between them. This should be a sticky!
 

g00ndu

Retired Recognized Developer
Apr 22, 2008
2,782
273
The reason that you don't see increased space in /system is because the usable size of that partition is recorded in the ROM. If you apply a lagfix to the partition with 513.pit, you will see that the usable space is increased because a new partition is created.

The reason for the increased space in 513.pit, the /system in certain Asian roms (such as DXJPA) needs to be larger to contain the large amount of CSC.

I believe hardcore had preciously mentioned about the increase in the usable space after lagfix is applied.

[Ramad], were you on ext4, or rfs? Maybe try the experiment on both file system?

Anyway, excellent information.

Sent from my GT-I9000
 

seresseran

Member
Apr 14, 2009
26
3
The reason that you don't see increased space in /system is because the usable size of that partition is recorded in the ROM. If you apply a lagfix to the partition with 513.pit, you will see that the usable space is increased because a new partition is created.

The reason for the increased space in 513.pit, the /system in certain Asian roms (such as DXJPA) needs to be larger to contain the large amount of CSC.


But as you see the usable space does not change. So even if some roms need more space for system, According to Ramad's file copy test, this 10 MB or 20 MB is not usable for the system, it is not dynamically extensible.

if it can't use that space, how can we say that some roms need to be larger to contain the large amount of CSC.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 218
    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:
    s1_odin_20100512.pit
    s1_odin_20100513.pit
    s1_odin_20100803.pit


    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:
    igx2dw.jpg


    Usable /system space: 276.3MB
    Actual /system size: 278MB
    /dbdata size: 126.7MB


    A /system dump while using 803.pit:
    qxwdxk.jpg


    Usable /system space: 276.3MB
    Actual /system size: 287.5MB
    /dbdata size: 117.2MB


    And a /system dump while using 513.pit:
    2iar4up.jpg


    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.


    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.
    4
    Just want to note that my I9000 come with ZSJPE, and update to ZSJPG via kies, never repartition, should come with a 512.pit, according to the size of dbdata, but samfirmware list as 803.pit. Thanks for the info and now I know what is the real pit come with my i9000
    3
    We need more people like you here.. Not only have you pasted useful information, but you have also backed up the important parts of what you said with evidence (and shown how you tested it, so testing can be repeated).

    Bravo.. This oughta put an end to some of the bs being said here..
    2
    The reason that you don't see increased space in /system is because the usable size of that partition is recorded in the ROM. If you apply a lagfix to the partition with 513.pit, you will see that the usable space is increased because a new partition is created.

    The reason for the increased space in 513.pit, the /system in certain Asian roms (such as DXJPA) needs to be larger to contain the large amount of CSC.
    2
    @maciekwar, unfnknblvbl, dawabz94, phalanger, ytt3r, x86-Dark, Darkyy, ph33lix

    Thank you all guys...I hope that I did not forget anyone :)

    according to this, in my phone I have 4th pit file... because /system and /dbdata have different sizes then sizes set by three pits we all know?

    Your device is using 512.pit, system partition can vary in size, I get the same usable system space as you with some firmwares(275.8MB), I had the one with 276.3MB installed so I went with it, had no desire to flash three more times. :) dbdata size on your device is 127MB, this is 512.pit. :)

    Very useful post, would you mind possibly posting this information in the other SGS subforums?

    You may very well post these informations in any sub-forum where the devices are using the same pit files as Galaxy S. These informations belongs to all XDA members, you may modify it also if that is needed for it to fit other pit files used on other devices.