Custom partition layouts, ZERO brick risk!

lbcoder · Jun 17, 2010

This is about the coolest thing you can imagine.
DEATHSPL is OBSOLETE.
We can repartition these things -- to ANY layout we like -- withOUT changing or modifying the SPL!

This is even compatible with a STOCK SPL! I.e. 0.95.0000.

This is something I discovered while looking at the MTD drivers.

The mtd drivers accept partition table specified on the KERNEL COMMAND LINE! And this SUPERSEDES the automatic table discovery method.

This is the command line argument for STOCK partition layout:

Code:

mtdparts=msm_nand:256k@0x24c0000(misc),5120k@0x26c0000(recovery),2560k@0x2bc0000(boot),69120k@0x2e40000(system),69120k@0x71c0000(cache),76544k@0xb540000(userdata)

You can boot a kernel with a modified partition table using one of two methods;
the "-c" parameter to fastboot allows you to add kernel parameters. This is good for booting RECOVERY images and applying custom layouts.

The second method is to build the custom layout into your boot.img or recovery.img.
This can be done using the "--cmdline" parameter to mkbootimg.

Notes: The smallest possible partition is 128k.
The partition sizes must be MULTIPLES of 128k and must start on an offset that is a multiple of 128k. The memory size is 256MB precisely.

Note: DO NOT modify ANYTHING before the START of the boot partition, i.e. offset 0x2bc0000. If you do, it won't boot!

***** EDIT:
We now have a BETA implementation of this concept: http://xdaforums.com/showpost.php?p=6916491&postcount=39

Thanks go to Firerat, who did the actual implementation work in converting CM 5.0.8 to this process.
Also thanks to skraw at CM forums who asked a silly question that started the gears a crankin and ended up getting this as an answer.
** just goes to show that there is no such thing as a stupid question.

xaueious · Jun 17, 2010

Sweet stuff!

Now we can finally reduce the size of that useless cache partition. And ROM devs can actually fit anything they want without a headache.

This should be leaps and bounds more useful on the phones with more ROMs space like the 32A Magic, where the cache is absurdly large.

zim2dive · Jun 17, 2010

xaueious said:
Sweet stuff!

Now we can finally reduce the size of that useless cache partition. And ROM devs can actually fit anything they want without a headache.

This should be leaps and bounds more useful on the phones with more ROMs space like the 32A Magic, where the cache is absurdly large.

I'll ask a silly question, and full intent not to derail the thread.. why have partitions at all? (do they accomplish some level of protection that simple unix privs do not if /system, /data, /cache, etc were all on the same partition?) Hopefully not a super stupid question (I understand their use on my home linux box, but fail to see what value they add here)

maxisma · Jun 17, 2010

I already pointed this out months ago.. but no one ever tried to make a use out of it.

defconoi · Jun 17, 2010

sweeeeeet! good ****, someone make sure cyanogen knows about this.

mattv888 · Jun 17, 2010

mhmm... this is awesome! But for all those who already have Death SPL, could this increase the amount of space even further?

Macrophage001 · Jun 18, 2010

mattv888 said:
mhmm... this is awesome! But for all those who already have Death SPL, could this increase the amount of space even further?

Yeah Im curious about that too

goldenarmZ · Jun 18, 2010

mattv888 said:
mhmm... this is awesome! But for all those who already have Death SPL, could this increase the amount of space even further?

Yes, in theory.. I'm not sure how usable it would be, but purely theoretically you should be able to drop cache and userdata to 128k, mount them both on the sdcard instead and flash a 200mb+ system image.

With a bit of modification to the way we flash images at the moment, there's no reason devs can't include a custom partition layout to fit the requirements of every release.

This is an awesome find by both lbcoder and maxisma, who seem to have discovered it independently.. I totally missed maxisma's annoucement though

Whoever found it first, this rules.

Macrophage001 · Jun 18, 2010

This would be really awesome to see can't wait

lbcoder · Jun 18, 2010

Macrophage001 said:
This would be really awesome to see can't wait

Wait for what?
This is something that everyone can do for themselves!
All you need is a calculator (to calculate memory offsets and sizes), the first post of this thread, and this:
http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images

unpack your boot.img, mkbootimg it back with the specified kernel command line, shove it into your update.zip (or fastboot it into the phone), and you're done-ish.

Take the most recent CM for example:

1) extract boot.img, unpack it, repack it with the kernel command line specified (modified to your specifications), put it back in the update.zip, resign, and put it on your sdcard.

2) Phone in fastboot mode, fastboot -c "same kernel command line as boot.img is packed with" boot recovery.img, flash your update.zip, done.

And then every time the phone boots up, it'll have the customized partition table since it is built into the boot.img.

haozheng91 · Jun 18, 2010

with this custom partition layouts, do we also need to do something to the recovery to make nandroid/bart recognize the new layout?

ezterry · Jun 18, 2010

haozheng91 said:
with this custom partition layouts, do we also need to do something to the recovery to make nandroid/bart recognize the new layout?

Same steps as the rom, just ensure you *never* flash *any* spl or radio for any reason from a re-partitioned recovery with a cache partition that does not match the spl's actual cache start location. Or you will be in the market for a jtag adapter to fix your brick.

Making this user friendly will need some configuration work.

lbcoder · Jun 18, 2010

ezterry said:
Same steps as the rom, just ensure you *never* flash *any* spl or radio for any reason from a re-partitioned recovery with a cache partition that does not match the spl's actual cache start location. Or you will be in the market for a jtag adapter to fix your brick.

Making this user friendly will need some configuration work.

There's security built in to that process....
the cache partition has to get a special header applied in order for the update to be taken, and if the spl or radio partition was mapped differently, this header will be badly broken. I believe that there are also checksums on the spl and radio images that should be checked by the SPL prior to actually installing them. Part of the reason for this is to ensure that the image was actually written correctly to the cache partition.

r3s-rt · Jun 18, 2010

Another good find.

maxisma said:
I already pointed this out months ago.. but no one ever tried to make a use out of it.

Don't see why. Hopefully people will be able to understand how to do this, get rid of the deathspl along with all the spam topics that come from the resulting bricks.

ezterry · Jun 18, 2010

lbcoder said:
There's security built in to that process....
the cache partition has to get a special header applied in order for the update to be taken, and if the spl or radio partition was mapped differently, this header will be badly broken. I believe that there are also checksums on the spl and radio images that should be checked by the SPL prior to actually installing them. Part of the reason for this is to ensure that the image was actually written correctly to the cache partition.

I can test it but I've seen invalid radio images trap a phone in flash radio.. I highly recommend just not tempting fate with this one and just installing 1.33.2003 or 1.33.2005 before starting custom partitions.. then you can deal with radio/alt recovery flashes from there.

Leave the recovery for android system install/uppdate/backup operations.

asb123 · Jun 20, 2010

any success?

lbcoder · Jun 21, 2010

ezterry said:
I can test it but I've seen invalid radio images trap a phone in flash radio.. I highly recommend just not tempting fate with this one and just installing 1.33.2003 or 1.33.2005 before starting custom partitions.. then you can deal with radio/alt recovery flashes from there.

Leave the recovery for android system install/uppdate/backup operations.

Possibly with an invalid radio, but DEFINITELY NOT with an offset-cache partition. It simply can't possibly do anything without the right header.

And I don't see any benefit at all for installing a 1.x SPL. The ability to flash radio or SPL direct depends on fastboot, and if you have fastboot, you can break the update-x cycle simply by wiping the misc partition.

And for that matter, the 0.95.0000 SPL withOUT fastboot still could flash an nbh file in any circumstance where any of the engineering/pseudoengineering SPLs could enter fastboot.

Tempting fate is to flash a radio or spl to begin with. If you want to feel really safe, you can always build a recovery that lacks the ability to flash the radio or spl. This would, of course, force you to go back to the SPL's partition table (i.e. another recovery) to flash either of those.

Or how about this: query the kernel command line -- if the partition table is set on the kernel command line, don't allow flashing of radio or spl.

zim2dive · Jun 21, 2010

lbcoder said:
This is the command line argument for STOCK partition layout:

Code:

mtdparts=msm_nand:256k@0x24c0000(misc),5120k@0x26c0000(recovery),2560k@0x2bc0000(boot),69120k@0x2e40000(system),69120k@0x71c0000(cache),76544k@0xb540000(userdata)

Notes: The smallest possible partition is 128k.
The partition sizes must be MULTIPLES of 128k and must start on an offset that is a multiple of 128k. The memory size is 256MB precisely.

Note: DO NOT modify ANYTHING before the START of the boot partition, i.e. offset 0x2bc0000. If you do, it won't boot!

I'm working my way thru the math.. I set up an OpenOffice spreadsheet (alas its fairly inept at working with hex #'s, so I have to do all the match in decimal and convert it to hex (couldn't find a way to make it add in hex, and it can't seem to convert big hex numbers back to dec.. even tho it can convert that same dec # into hex... grr...) anyway... this is the table I came up with (using D and H to denote Decimal and Hex versions of the same #s)

Code:

Block   k       M       bytes(D)   bytes(H)  StartD     EndD       StartH  EndH
                                                                
misc    256     0.25    262144     40000     38535168   38797312   24C0000 2500000
recover 5120    5       5242880    500000    40632320   45875200   26C0000 2BC0000
boot    2560    2.5     2621440    280000    45875200   48496640   2BC0000 2E40000
system  69120   67.5    70778880   4380000   48496640   119275520  2E40000 71C0000
cache   69120   67.5    70778880   4380000   119275520  190054400  71C0000 B540000
userdat 76544   74.75   78381056   4AC0000   190054400  268435456  B540000 10000000
                                                                
size    229900288   219.25

The only "gap" I saw was after misc.. ie. there was space between the end of misc and the beginning of recovery (1792k by my calculations).. is that correct, or did I fudge my math up? Any idea what is in that gap?

Also by taking the final addr and subtracting the start addr, it looks like 219.25M (out of the 256M you mention) are being used? (actually that does not take the "gap" memory into account). Any idea what is using the other 256-219.25=36.75M?

Note: not trying to poke any holes here.. I'm trying to get a good understanding of this, so I can give it a try.

EDIT: added M column to table

ezterry · Jun 21, 2010

Yes.. there are some internal partitions after misc.

If you have 1.33.2005 or 1.33.2003 spls ask it the partition layout yourself: fastboot oem listpartition

lbcoder · Jun 21, 2010

zim2dive said:
I'm working my way thru the math.. I set up an OpenOffice spreadsheet (alas its fairly inept at working with hex #'s, so I have to do all the match in decimal and convert it to hex (couldn't find a way to make it add in hex, and it can't seem to convert big hex numbers back to dec.. even tho it can convert that same dec # into hex... grr...) anyway... this is the table I came up with (using D and H to denote Decimal and Hex versions of the same #s)

Code:

Block k M bytes(D) bytes(H) StartD EndD StartH EndH misc 256 0.25 262144 40000 38535168 38797312 24C0000 2500000 recover 5120 5 5242880 500000 40632320 45875200 26C0000 2BC0000 boot 2560 2.5 2621440 280000 45875200 48496640 2BC0000 2E40000 system 69120 67.5 70778880 4380000 48496640 119275520 2E40000 71C0000 cache 69120 67.5 70778880 4380000 119275520 190054400 71C0000 B540000 userdat 76544 74.75 78381056 4AC0000 190054400 268435456 B540000 10000000 size 229900288 219.25

The only "gap" I saw was after misc.. ie. there was space between the end of misc and the beginning of recovery (1792k by my calculations).. is that correct, or did I fudge my math up? Any idea what is in that gap?

Also by taking the final addr and subtracting the start addr, it looks like 219.25M (out of the 256M you mention) are being used? (actually that does not take the "gap" memory into account). Any idea what is using the other 256-219.25=36.75M?

Note: not trying to poke any holes here.. I'm trying to get a good understanding of this, so I can give it a try.

EDIT: added M column to table

You don't need to do any subtraction. The start address is itself the size of the "gap" before it. I.e. look at startD column: 38535168 -- that would be ~38.5 MB or (divide by 1024x1024) 36.75 MiB, the same as the number you got through your subtraction.

That gap is for the radio and SPL, and some proprietary data, like IMEI, radio lock, security, etc.

Of course, you could just ASK someone who has a deathSPL for the numbers....

Not about the gap between misc and recovery: I believe that the splash images go there.

In any case, you don't need to worry about any of those....
The only partitions you need to map are the ones that *are* mapped.
misc, recovery, and boot should be left alone. As should the STARTING address of system.

You should start by adjusting the SIZE of system,
Adjust the OFFSET of cache by the SAME AMOUNT as you adjusted the SIZE of system.
Adjust the SIZE of cache by whatever you feel is appropriate,
Adjust the OFFSET of userdata to (OFFSET+SIZE) of cache.
And according to the mtd documentation, you should be able to set the SIZE of userdata to "-" in order for it to fill all of the remaining space. Either that, or hardcode it to 0x10000000-OFFSET.

Custom partition layouts, ZERO brick risk!

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Member

Retired Recognized Developer

Senior Member

r3s-rt

Guest

Retired Recognized Developer

Senior Member

Senior Member

Senior Member

Retired Recognized Developer

Senior Member

Similar threads

Top Liked Posts