- Nov 30, 2010
- 80
- 22
- 0
I've been trying this on the optimus T, but nobody reads that forum, and this could benifit S users as well, so what I've been trying is described here:
Custom partition layouts, ZERO brick risk! - xda-developers
What it states is that if you rebuild the kernel with partition sizes specified in the kernel command line, it will mount the partitions the way the command line specified instead of the default. First (I would assume) you would have to rebuild recovery to accept those partition sizes so that you can format them as those sizes so they will be usable. So, using kmsg logs, I found my partition table, which for the optimus T is:
<5>[ 1.583211] Creating 10 MTD partitions on "msm_nand":
<5>[ 1.583236] 0x000002600000-0x000002a40000 : "boot"
<5>[ 1.584648] 0x000002a40000-0x00000e840000 : "system"
<5>[ 1.585803] 0x00000e840000-0x00000ed40000 : "recovery"
<5>[ 1.587140] 0x00000ed40000-0x00000f000000 : "lgdrm"
<5>[ 1.588073] 0x00000f000000-0x00000f100000 : "splash"
<5>[ 1.589000] 0x00000f100000-0x00000f280000 : "FOTABIN"
<5>[ 1.589951] 0x00000f280000-0x00000f840000 : "FOTA"
<5>[ 1.590888] 0x00000f840000-0x00000f880000 : "misc"
<5>[ 1.591853] 0x00000f880000-0x000013880000 : "cache"
<5>[ 1.592828] 0x000013880000-0x000020000000 : "userdata"
So using my handy dandy calculator I created my mtdparts option for the command line, which after changing cache from 65mb to 10mb was:
mtdparts=msm_nand:4352k@0x000002600000(boot),194560k@0x000002a40000(system),5120k@0x00000e840000(recovery),2816k@0x00000ed40000(lgdrm),1024k@0x00000f000000(splash),1536k@0x00000f100000(FOTABIN),5888k@0x00000f280000(FOTA),256k@0x00000f840000(misc),10240k@0x00000f880000(cache),204288k@0x000010280000(userdata)
I rebuilt both my recovery.img & my boot.img with the command line specifying mtdparts, flashed the recovery & had my boot.img ready to flash, problem being, when I booted into recovery, it froze up, likely due to the fact that cache is mounted in recovery by default, and the size had been changed on it. So my question is does that sound like why recovery froze to anyone else? And if so, does building a "temp recovery" that doesn't mount any partitions other than root just to allow formatting the partitions to whatever the determined size is sound plausible?
Custom partition layouts, ZERO brick risk! - xda-developers
What it states is that if you rebuild the kernel with partition sizes specified in the kernel command line, it will mount the partitions the way the command line specified instead of the default. First (I would assume) you would have to rebuild recovery to accept those partition sizes so that you can format them as those sizes so they will be usable. So, using kmsg logs, I found my partition table, which for the optimus T is:
<5>[ 1.583211] Creating 10 MTD partitions on "msm_nand":
<5>[ 1.583236] 0x000002600000-0x000002a40000 : "boot"
<5>[ 1.584648] 0x000002a40000-0x00000e840000 : "system"
<5>[ 1.585803] 0x00000e840000-0x00000ed40000 : "recovery"
<5>[ 1.587140] 0x00000ed40000-0x00000f000000 : "lgdrm"
<5>[ 1.588073] 0x00000f000000-0x00000f100000 : "splash"
<5>[ 1.589000] 0x00000f100000-0x00000f280000 : "FOTABIN"
<5>[ 1.589951] 0x00000f280000-0x00000f840000 : "FOTA"
<5>[ 1.590888] 0x00000f840000-0x00000f880000 : "misc"
<5>[ 1.591853] 0x00000f880000-0x000013880000 : "cache"
<5>[ 1.592828] 0x000013880000-0x000020000000 : "userdata"
So using my handy dandy calculator I created my mtdparts option for the command line, which after changing cache from 65mb to 10mb was:
mtdparts=msm_nand:4352k@0x000002600000(boot),194560k@0x000002a40000(system),5120k@0x00000e840000(recovery),2816k@0x00000ed40000(lgdrm),1024k@0x00000f000000(splash),1536k@0x00000f100000(FOTABIN),5888k@0x00000f280000(FOTA),256k@0x00000f840000(misc),10240k@0x00000f880000(cache),204288k@0x000010280000(userdata)
I rebuilt both my recovery.img & my boot.img with the command line specifying mtdparts, flashed the recovery & had my boot.img ready to flash, problem being, when I booted into recovery, it froze up, likely due to the fact that cache is mounted in recovery by default, and the size had been changed on it. So my question is does that sound like why recovery froze to anyone else? And if so, does building a "temp recovery" that doesn't mount any partitions other than root just to allow formatting the partitions to whatever the determined size is sound plausible?