Among these, the most frustrating thing, in my opinion, is the way how Samsung/Android treat the modem. Why should we waste the invaluable 12.5MB for storing the modem.bin in the NAND drive as a temporary storage? So I tried to move it elsewhere but found that the location of the modem.bin is hard coded in the boot loader. More, the loading of the modem file is performed by the bml utils which reads the modem.bin from the nand drive and put it into the memory during the init process. Unfortunately, I was unable to change this due to I am not an expert in C and they are not open sources (althought I discovered some related source files at a later stage).
freeNANDmod
Finally, I found a way to remove the modem completely from the nand drive and freed the extra 12.5MB when I tried to free some more nand disk space for my own use. This finding, together with the mod for the nand drive partitons (let's call it freeNANDmod :D), allows us to get more free nand disk space available for faster reads/writes. And what it does actually is to make more room in the nand storage for larger partitions, by moving the traditional partitions in the nand disk to and from the mmc disk.
Although it looks like easy enough to move the partitions around, there are some more works needed to reflect these changes to the system. The obvious thing is to handle the new partition layout so that the system will get the right partition when needed. It is not a difficult task for me, and since I modified my system to run on loop devices, I already have my own mount and umount processes/scripts to override the system's. However, for most of the rom modders, they will need to find a way to tell the system where and which the partitions are, since afaik, they dont' have to care about this before.
Other areas which required attentions include, but not limiting to, making sure the rom and subsequent files can be written to the correct partitions during rom reflashing while maintaining your new layouts, as well as handling these info in the recovery process or otherwise neither the stock recovery nor cwm recovery will work properly especially if you made changes to the /cache.
You may ask at this point, "So what did you do to the layout and how can we benefit from your mod?"
Let's take a look at my current partitions snapshot:
| device name | mount point | size in MB | location |
| /dev/block/stl10 | /dbdata | 444 | NAND |
| /dev/block/mmcblk0p1 | /mnt/sdcard | 13757 | MMC (unchanged) |
| /dev/block/mmcblk0p2 | /data | 1408 | MMC |
| /dev/block/mmcblk0p3 | /system | 370 | MMC |
| /dev/block/mmcblk0p4 | /cache | 105 | MMC |
As you can see in the table above, I have one single partition with 444MB available on /dbdata. It is 4x compared with the stock version (134MB with s1_odin_20100512.pit). You can also find the /system and /cache partition are moved to the mmc disk, for the reasons that:
- the /system holds read only files usually (that's why it is mounted as read-only by default), therefore the writing speed to /system can be ignored
- for those files reside on /system that require faster read, you can always put them in the new /dbdata instead
- the /cache now is a dummy partition which require limited reads/writes, and can be completely removed in case you want to handle it yourself during the boot process
PS I am not following S2's. I have made these changes for about 2 months and I only realized the /system in S2 is located at mmc also about 2 weeks ago
* wearing and tearing is not taken into account and will not be discussed
read more:
Free more available disk space from NAND - PART I
Free more available disk space from NAND - PART II
freeNANDmod - get more space from NAND - PART IV
