• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

[DEV][GUIDE][REF] Customize Internal Partition Layout for MTD Devices

Search This thread

CosmicDan

Senior Member
Jun 19, 2009
5,890
7,736
34
Sydney
Google Pixel 3 XL
Xiaomi Poco X3 Pro
See Post #2 for current known stock partition parameters for various devices. Your contributions for missing devices are welcome and appreciated. Cheers!

Introduction


This guide / reference aims to be a complete article on customizing, resizing and/or re-ordering the internal partition layout on most (any?) Android MTD-based device. I have seen many questions around the various forums on how to get more internal data so I thought I'd share my developments. Hopefully this will become a valuable resource for kernel builders/hackers.

The guide is especially valuable (and, in the case of my kernel builds, originally designed for) the Xperia 2011 line, but from what I know it could be applied to nearly any Android device where kernel source/flashing is possible.

I would like to gather stock partition information for various devices and place them into Post #2. If you can at least give me your Partition Info from ATAG (see "Gathering information" section), I can create a reference for all kernel developers. Thank you!

Requirements

  • Android SDK
  • Ability to build a kernel (this guide does not teach that)
  • Ability to flash a kernel (unlocked bootloader, etc)
  • Bootloader which exposes Partition info via ATAG on startup (see "Gathering information" section)
  • Device which uses MTD Partition Map (Don't know how to check this, I think most Android devices do anyway)


Warning

As far as I know, following this guide and using precise calculation that you double and triple check before flashing will not result in a hard brick - however I can not guarantee it. Some devices may have "obscure" partition maps or some "protected" sectors for one reason or another, and modifying these *may* result in either a hard-brick (unlikely) or a permanent inability to restore your device to 100% stock (very likely) for warranty and/or DRM purposes. You have been warned. I/we/anyone may not be held accountable for any of these events should they occur, for you are doing this at your own risk and with your own responsibility.


Gathering information


  1. The first thing you'll want to do for the sake of accuracy is to flash to a 100% stock firmware. In the case of Xperia 2011 devices, flash the latest stock FTF for your device.
  2. With the stock firmware now installed, the second thing you will need to do is to flash a custom kernel that is rooted and has busybox installed. In most cases, a CM7/9/10 kernel will do nicely.
  3. Power-off your device. Execute the following command from shell/console, and then press enter:
    Code:
    adb wait-for-device && adb shell dmesg
  4. After pressing enter, the console will wait at the prompt as intended. Now, power on your device and immediately plug in the USB cable. I assume the ADB drivers are already installed.
  5. Shortly (5-15 seconds) you should see a mass output from the kernel followed by a return to your shell prompt. If you don't, either your kernel or bootloader does not support it. Try a different kernel. If you still don't, then sorry but I think we can't do it for your device.
  6. Scroll right to the top of the dmesg output, you should see something similar to this:
    Code:
    <6>[    0.000000] Initializing cgroup subsys cpu                                                                                                           
    <5>[    0.000000] Linux version 2.6.32.9-KRsH ([email protected], Linaro 4.7) (gcc version Linaro 4.6.2 20111004) #8 PREEMPT Thu Oct 25 15:57:27 EST 2012   
    <4>[    0.000000] CPU: ARMv7 Processor [511f00f2] revision 2 (ARMv7), cr=10c53c7d                                                                          
    <4>[    0.000000] CPU: VIPT nonaliasing data cache, VIVT ASID tagged instruction cache                                                                     
    <4>[    0.000000] Machine: zeus                                                                                                                            
    <6>[    0.000000] Partition (from atag) system -- Offset:2e4 Size:9c4                                                                                      
    <6>[    0.000000] Partition (from atag) userdata -- Offset:ca8 Size:be0                                                                                    
    <6>[    0.000000] Partition (from atag) cache -- Offset:1cb4 Size:32c                                                                                      
    <6>[    0.000000] Partition (from atag) appslog -- Offset:1888 Size:42c                                                                                    
    <4>[    0.000000] Memory policy: ECC disabled, Data cache writeback
    ...see those "Partition (from atag)" lines? That's what we need! Copy this information down and move on to the next section.




Additional verification and hidden partitions (optional)


As far as I know, this is only possible with Xperia 2011 devices. If you know of a method for other devices, please let me know.


We can additionally verify the ATAG information and map extra "hidden" partitions such as boot (kernel) by examining the SIN files inside an FTF. I will assume that you know how to use Flashtool already as I won't go into much detail here.


First, we need to enable the development features of Flashtool. In the program folder, open "config.properties" and edit/add the line like so:
Code:
devfeatures=yes
Next, extract your stock FTF bundle with any ol' ZIP extractor, load Flashtool, and select "Tools" > "SIN Editor", and open a particular SIN file that you want to verify/unhide. In this example, we will open system.sin. The "Partition Info" field is what we want. Behold:
Code:
STOCK SIN:
system:   0400000001000080E4020000C4090000
                  --    --|------||------|
                   |    |     |       |
type? (elf/yaffs) _/    |     |       \____ byte-reversed size
                        |     |
            unknown ____/     \____________ byte-reversed offset
The second last 8-bytes are the offset and the last 8-bytes are the size. By "byte-reversed" I mean that you read each byte from end to beginning, but not swap the bytes themselves. Thus the size above, reading "C4090000" is actually "000009C4". And as you can see, this matches 100% to our ATAG of 9c4 for system size. Correct sir! Additionally, the offset of "E4020000" > reversed to "000002E4" also matches.


So now, we can open "kernel.sin" and do the same, because we also want to partition "boot" (why not?). In this device (Xperia Play/Xperia Neo L), kernel.sin gives us 03000000220000808002000064000000 which means that the size is 64 and the offset is 280.



Calculations


From the partition info via ATAG, we can now build "stock" mtdparts information to apply to our kernel. Using the example(s) above, we can now build this information:


Note the syntax of size@offset. Next, we must convert the hex values to decimal, then multiply by 128 (I do not know if 128 is the same multiplier for all devices, please double check and let me know). This will give us the exact sizes and offsets in kilobytes.


Alright, so that is a 100% stock partition map for this device - except we also have the boot (kernel) mapped now too. Here is a (crappy) visual representation of it:


Code:
 reserved  |  boot  |   /system   |     /data      |   appslog   | /cache  |
first 80MB | 12.5MB |   312.5MB   |     380MB      |   133.5MB   | 101.5MB |

Note: Not to scale :)
You may have noticed that the order we (and ATAG) lists the partitions in does not match the actual order of the partitions. It is quite important to retain the order of the partitions as specified in ATAG, because that's the order they will be mapped in. I.e. system will remain mtdblock0 and cache will remain mtdblock2. Any extra partitions should always go after these defaults.





Formatting for kernel


To specify the mtdparts parameter for the kernel to use is trivial. Doing this will over-ride the ATAG map (from bootloader) and everything in the system - including Recovery - will see your map from the kernel. Search your default config file in your kernel for the value "CONFIG_CMDLINE" and you should find a value like this :
Code:
CONFIG_CMDLINE="console=ttyMSM2,115200n8 androidboot.hardware=semc"
Using the information we have above about our partition map, we add a new parameter here with "mtdparts=msm_nand:". The syntax is as follows:
Code:
mtdparts=msm_nand:[size]@[offset](name){,[size]@[offset](name)}{...}
Remember that we converted our size and offsets to kilobytes (for better readibility) so we need to specify size unit of k. The new parameter, from our above examples, becomes this:
Code:
mtdparts=msm_nand:[email protected](system),[email protected](userdata),[email protected](cache),[email protected](boot)
Don't forget to retain the order! And so, our full line looks like this:
Code:
CONFIG_CMDLINE="console=ttyMSM2,115200n8 androidboot.hardware=semc mtdparts=msm_nand:[email protected](system),[email protected](userdata),[email protected](cache),[email protected](boot)"
NOTE: Depending on your kernel, you may also need to enable the following line in your config:
Code:
CONFIG_MTD_CMDLINE_PARTS=y
And we're all done. If you build your kernel now, you will be able to mount (or at least dd from) the appslog and boot partitions.




Resizing partitions


This is somewhat trivial, the most difficult part is probably over - but this step can be tedious, albeit not very complicated. Anybody with an above average IQ would have already figured this out - we simply change the size of one partition and adjust the offsets of it's following partitions to accommodate for the change. Here is one good example that I use for the MIUI ROM for the Xperia Play and Neo L, compared to the stock examples shown above:
Code:
mtdparts=msm_nand:[email protected](system),[email protected](userdata),[email protected](cache),[email protected](boot)
...and a visual representation of this new map:
Code:
 reserved  |  boot  |   /system   |               /data               |/cache|
first 80MB | 12.5MB |    280MB    |               639MB               |  8MB |

Note: Not to scale :)
Hopefully that's enough to make sense. Remember to verify your modified partitions. This can easily be done by adding the size+offset of a partition, giving the offset of the next partition. E.g. in this mod, userdata ends at 1036288 (654848+381440) which matches the offset for the next partition - cache.




Troubleshooting/Recovering from modified partitions


In some cases, your new kernel may not boot. A common issue is that the kernel logo will show, and the device will shortly reboot (kernel bootloop). This can be solved by formatting your partitions with fastboot after flashing the new kernel, usually system and userdata are all that is needed:

Code:
fastboot format system
fastboot format userdata
If you wish to return to a stock partition layout, sometimes flashing a non-modified kernel is not enough. You may get stuck on kernel logo even after formatting system and userdata. In this case, flashing a stock Firmware and setting your phone back to scratch should result in a 100% original device. But if your phone is still bricked, sorry but it's not my fault. You probably did something wrong.





#####



OK, that's the guide done for now. Any questions or suggestions on the guide, please let me know! Also, refer to post #2 for some stock partition map reference.
 
Last edited:

CosmicDan

Senior Member
Jun 19, 2009
5,890
7,736
34
Sydney
Google Pixel 3 XL
Xiaomi Poco X3 Pro
Finding Stock Partition Info For Your Device

Three methods:

  1. Most reliable - See the section "Gathering info" above to get it from ATAG
  2. Only shows size without offset - do "cat /proc/mtd" from adb shell. Can be used to test if you're on stock partitions or not, or to verify partition is big enough for update ZIP's (with sed/grep).
  3. Xperia 2011 Only - Examine SIN header as outlined above. This method is difficult to determine mtd block order but I'm 99% sure the order is same for all Xperia 2011 devices (system=mtd0, userdata=mtd1, cache=mtd2).


Stock Partition Parameters for Various Devices

Xperia 2011 Range:
Code:
[B]anzu (Arc) (LT15) (HDPI):[/B]
(03) kernel   - [email protected]   ([email protected])    (unmapped)
(04) system   - [email protected]  ([email protected])
(05) amss     - [email protected]    ([email protected])     (unmapped)
(06) amss_fs  - [email protected]    ([email protected])    (unmapped)
(08) adsp     - [email protected]   ([email protected])    (unmapped)
(09) userdata - [email protected]  ([email protected])
(10) vendor   - [email protected] ([email protected])
(0B) fota0    - [email protected]   ([email protected])    (unmapped)
(0C) fota1    - [email protected]   ([email protected])    (unmapped)
mtdparts=msm_nand:[email protected](system),[email protected](userdata),[email protected](cache),[email protected](appslog),[email protected](amss),[email protected](amss_fs),[email protected](adsp),[email protected](fota0),[email protected](fota1),[email protected](boot)

[B]ayame (Arc S) (LT18) (HDPI):[/B]
(03) kernel   - [email protected]   ([email protected])    (unmapped)
(04) system   - [email protected]  ([email protected])   
                     \ this is odd, there is 2048k unallocated between boot and system (SEMC made a mistake?)
(05) amss     - [email protected]    ([email protected])     (unmapped)
(06) amss_fs  - [email protected]    ([email protected])    (unmapped)
(08) adsp     - [email protected]   ([email protected])    (unmapped)
(09) userdata - [email protected] ([email protected])
(10) vendor   - none
(0B) fota0    - [email protected]   ([email protected])    (unmapped)
(0C) fota1    - [email protected]   ([email protected])    (unmapped)
mtdparts=msm_nand:[email protected](system),[email protected](userdata),[email protected](cache),[email protected](boot),[email protected](amss),[email protected](amss_fs),[email protected](adsp),[email protected](fota0),[email protected](fota1)

[B]haida (Neo V) (MT11) (HDPI):[/B]
[I]Same as ayame (Arc S) (LT18)[/I]

[B]hallon (Neo) (MT15) (HDPI):[/B]
[I]Same as anzu (Arc) (LT15)[/I]

[B]iyokan (Pro) (MK16) (HDPI):[/B]
[I]Same as ayame (Arc S) (LT18)[/I]

[B]mango (Mini Pro) (SK17) (MDPI):[/B]
??

[B]satsuma (Active) (ST17) (MDPI):[/B]
??

[B]smultron (Mini) (ST15) (MDPI):[/B]
??

[B]urushi (Ray) (ST18) (HDPI):[/B]
??

[B]phoenix (Neo L) (MT25) (HDPI):[/B]
[I]Same as anzu (Arc) (LT15)[/I]

[B]zeus/zeusc (Play) (R800) (HDPI):[/B]
[I]Same as anzu (Arc) (LT15)[/I]
R800a (and probably i/at, but not x) has unallocated vendor partition. Needs one-time flash of Vendor-enabled FTF (e.g. phoenix or anzu) to allocate it otherwise the vendor map will present I/O errors.
 
Last edited:

CosmicDan

Senior Member
Jun 19, 2009
5,890
7,736
34
Sydney
Google Pixel 3 XL
Xiaomi Poco X3 Pro
Very nice work mate! (Especially for using ATAGs...)
I just started the related thread:

"[DEV][REF] El Grande Partition Table Reference"
To collect detailed partition info from various devices...

Heh nice! Yours looks a bit more hardcore than mine, I've never used any of those tools :p

I started this guide so I can port kernels to various devices for Xperia 2011 range, and also to help other devs appeal the users who crave for more internal partition space. But so far, none of these people seem to have the patience to lend a hand with gathering data :(
 

[NUT]

Senior Member
Xperia Arc (anzu - LT15i_4.1.B.0.587_Generic Global World)
Code:
SIN               name     HEX [email protected] DEC (in k)       SIZE
amss.sin:         ???       E4 @   10       29184 @   2048   28Mb
amss_fs_anzu.sin: ???       68 @   F4       13312 @  31232   13Mb
adsp.sin:         ???       6C @  15C       13824 @  44544   13Mb
fota0.sin:        ???       5C @  1C8       11776 @  58368   11Mb
fota1.sin:        ???       5C @  224       11776 @  70144   11Mb
kernel.sin:       boot      64 @  280       12800 @  81920   12Mb
system.sin:       system   9C4 @  2E4      320000 @  94720  312Mb
userdata.sin:     userdata BE0 @  CA8      389120 @ 414720  380Mb
vendor.sin:       vendor   42C @ 1888      136704 @ 803840  133Mb

I've been talking to wedgess about the use of the cache partition... been poking around and he pointed me in your direction... so, here we go! :highfive:
 
Last edited:

CosmicDan

Senior Member
Jun 19, 2009
5,890
7,736
34
Sydney
Google Pixel 3 XL
Xiaomi Poco X3 Pro
Xperia Arc (anzu - LT15i_4.1.B.0.587_Generic Global World)
Code:
SIN               name     HEX [email protected] DEC (in k)       SIZE
amss.sin:         ???       E4 @   10       29184 @   2048   28Mb
amss_fs_anzu.sin: ???       68 @   F4       13312 @  31232   13Mb
adsp.sin:         ???       6C @  15C       13824 @  44544   13Mb
fota0.sin:        ???       5C @  1C8       11776 @  58368   11Mb
fota1.sin:        ???       5C @  224       11776 @  70144   11Mb
kernel.sin:       boot      64 @  280       12800 @  81920   12Mb
system.sin:       system   9C4 @  2E4      320000 @  94720  312Mb
userdata.sin:     userdata BE0 @  CA8      389120 @ 414720  380Mb
vendor.sin:       vendor   42C @ 1888      136704 @ 803840  133Mb

I've been talking to wedgess about the use of the cache partition... been poking around and he pointed me in your direction... so, here we go! :highfive:

Awesome, thanks for the partition info. I *hope* to get all Xperia 2011 device info so I can build Turbo Kernel for all. From what I can see, Arc partitions are identical to Play and Neo L. So maybe all Xperia 2011 devices are the same.

Since the cache partition is not an FTF file, it goes after vendor - so offset would be 940544 (kb). The size I am not sure and might vary per device. /proc/mtd (or /proc/partitions) should tell you.

Also, you can remove vendor partition - because all ROM's just mount it to the folder at /system/vendor so any vendor files you need can go into system partition, and then you can remap/reclaim vendor.
 
Last edited:

[NUT]

Senior Member
Awesome, thanks for the partition info. I *hope* to get all Xperia 2011 device info so I can build Turbo Kernel for all. From what I can see, Arc partitions are identical to Play and Neo L. So maybe all Xperia 2011 devices are the same.

Since the cache partition is not an FTF file, it goes after vendor - so offset would be 940544 (kb). The size I am not sure and might vary per device. /proc/mtd (or /proc/partitions) should tell you.

Also, you can remove vendor partition - because all ROM's just mount it to the folder at /system/vendor so any vendor files you need can go into system partition, and then you can remap/reclaim vendor.

Might be different for the Arc S (ayame) ... i'm looking into the official firmware release now to confirm... but as i used a FTF for my LT15i to gain size on my userdata a while back this is what i get from the dmesg ATAG lines...

Code:
                  system   9C4 @  2E4      320000 @  94720  312Mb
                  cache    32C @  FA4      103936 @ 512512  101Mb
                  userdata D20 @ 12D0      430080 @ 616448  420Mb

Seeing cache between system and userdata ... but no vendor partition anymore o_O

I also notice my endpoint at 918Mb of 1000MB (as sony states in their whitepaper: 1GB) that would be inside the phone ... lost space or do you know a reason perhaps?
 
Last edited:

CosmicDan

Senior Member
Jun 19, 2009
5,890
7,736
34
Sydney
Google Pixel 3 XL
Xiaomi Poco X3 Pro
Might be different for the Arc S (ayame) ... i'm looking into the official firmware release now to confirm... but as i used a FTF for my LT15i to gain size on my userdata a while back this is what i get from the dmesg ATAG lines...

Code:
                  system   9C4 @  2E4      320000 @  94720  312Mb
                  cache    32C @  FA4      103936 @ 512512  101Mb
                  userdata D20 @ 12D0      430080 @ 616448  420Mb

Seeing cache between system and userdata ... but no vendor partition anymore o_O

I also notice my endpoint at 918Mb of 1000MB (as sony states in their whitepaper: 1GB) that would be inside the phone ... lost space or do you know a reason perhaps?

1GB = 1024MB, not 1000MB :)

Well on stock zeus/phonex, as the OT shows, boot + system + data + appslog (vendor) + cache = 940MB. Along with the ~80MB of reserved data at the beginning for radio/baseband and such, that comes to 1020MB. I assume the last missing ~4MB of the full 1GB is reserved for remapping bad blocks (i.e. wear-leveling).


That FTF is completely weird, just like the 420MB space mod for some devices is actually dangerous (size of one partition overlaps the offset of another by about 20MB). If you visualize your map you just showed, there is some wasted space after /system map. Anyway, the cache partition on zeus board goes right at the end, after vendor. So yeah the maps are obviously different, however I think the 1020MB NAND size is possibly the same for all msm-7x30/Snapdragon S2 SoC devices (not just Sony).

Could you ensure you have flashed a 100% original/genuine FTF file and get full ATAG information again?
 

[NUT]

Senior Member
1GB = 1024MB, not 1000MB :)

well... thats open for debate in some way, GB != GiB. For me 1GB should be 1024Mb though ... :)

Well on stock zeus/phonex, as the OT shows, boot + system + data + appslog (vendor) + cache = 940MB. Along with the ~80MB of reserved data at the beginning for radio/baseband and such, that comes to 1020MB. I assume the last missing ~4MB of the full 1GB is reserved for remapping bad blocks (i.e. wear-leveling).

most likely yes... sounds fair atleast...

That FTF is completely weird, just like the 420MB space mod for some devices is actually dangerous (size of one partition overlaps the offset of another by about 20MB). If you visualize your map you just showed, there is some wasted space after /system map. Anyway, the cache partition on zeus board goes right at the end, after vendor. So yeah the maps are obviously different, however I think the 1020MB NAND size is possibly the same for all msm-7x30/Snapdragon S2 SoC devices (not just Sony).

i've been playing around with wedgess' kernel:

Code:
                  system    9C4 @  2E4      320000 @   94720  312Mb
                  userdata 1258 @  CA8      601088 @  414720  587Mb
                  cache      40 @ 1F00        8192 @ 1015808    8Mb

EOD: 1024000 1000Mb

Thats what i am using now, thanks to your guide ;)

attachment.php


Could you ensure you have flashed a 100% original/genuine FTF file and get full ATAG information again?

Will report back with the defaults from the stock rom later... going to bed now... 7:36am here now... haven't been sleeping yet :silly:
 

CosmicDan

Senior Member
Jun 19, 2009
5,890
7,736
34
Sydney
Google Pixel 3 XL
Xiaomi Poco X3 Pro
Yeah true, the whole kilobyte/kibibyte thing.... they still display KB/MB instead of KiB/MiB in most things even though they're in 1024 unit (shell listings, file explorer properties, etc.) but storage vendors do use true 1000 units, 32GB SDCard for example... but then the software doesn't so it's stupid and confusing :p So yeah, most people have not adopted it, thus it's better to assume that all KB/MB/etc measurements are done in powers of 1024 still.... because they're old school :)

I wonder, in pther Android ROM's is it corrrect? In MIUI/Turbo UI it shows 639MB in Storage (instead of MiB) so I assume even Android OS itself is also "wrong" haha. Titanium Backup is the *only* app I know of that shows sizes in power of 1000.... and that confuses a lot of people.
 

[NUT]

Senior Member
Yeah true, the whole kilobyte/kibibyte thing.... they still display KB/MB instead of KiB/MiB in most things even though they're in 1024 unit (shell listings, file explorer properties, etc.) but storage vendors do use true 1000 units, 32GB SDCard for example... but then the software doesn't so it's stupid and confusing :p So yeah, most people have not adopted it, thus it's better to assume that all KB/MB/etc measurements are done in powers of 1024 still.... because they're old school :)

I wonder, in pther Android ROM's is it corrrect? In MIUI/Turbo UI it shows 639MB in Storage (instead of MiB) so I assume even Android OS itself is also "wrong" haha. Titanium Backup is the *only* app I know of that shows sizes in power of 1000.... and that confuses a lot of people.

attachment.php


:D

Code:
SIN               name     HEX [email protected] DEC (in k)       SIZE
amss.sin:         ???       E4 @   10       29184 @   2048   28Mb
amss_fs_anzu.sin: ???       68 @   F4       13312 @  31232   13Mb
adsp.sin:         ???       6C @  15C       13824 @  44544   13Mb
fota0.sin:        ???       5C @  1C8       11776 @  58368   11Mb
fota1.sin:        ???       5C @  224       11776 @  70144   11Mb
kernel.sin:       boot      64 @  280       12800 @  81920   12Mb

LT15i: anzu
system.sin:       system   9C4 @  2E4      320000 @  94720  312Mb
userdata.sin:     userdata BE0 @  CA8      389120 @ 414720  380Mb
vendor.sin:       vendor   42C @ 1888      136704 @ 803840  133Mb
                  cache    330 @ 1CB4      104448 @ 940544  102Mb
EOD: 1044480 1020Mb

LT18i: ayame
system.sin:       system   C80 @  2F4      409600 @  96768  400Mb
                  cache    360 @ 1CB4      110080 @ 506368  107Mb
userdata.sin:     userdata D20 @ 12D0      430080 @ 616448  420Mb
EOD: 1046528 1022Mb

MK16i/a: iyokan
system.sin:       system   C80 @  2F4      409600 @  96768  400Mb
                  cache    360 @ 1CB4      110080 @ 506368  107Mb
userdata.sin:     userdata D20 @ 12D0      430080 @ 616448  420Mb
EOD: 1046528 1022Mb

your welcome :cowboy:
 

[NUT]

Senior Member
Great thanks. It seems the anzu has 2MB unused... is that your device? If so, do you know how to use dd? Can use dd to dump partition, if its mapped bad it will give I/O error.

Sent from Xperia Play (R800a) with Tapatalk

Yep, I have the anzu, and I know how to use dd... Will test that some time later ;) would it be possible to dump all of the nand flash?

Sent from my LT15i using xda app-developers app
 

CosmicDan

Senior Member
Jun 19, 2009
5,890
7,736
34
Sydney
Google Pixel 3 XL
Xiaomi Poco X3 Pro
Yep, I have the anzu, and I know how to use dd... Will test that some time later ;) would it be possible to dump all of the nand flash?

Sent from my LT15i using xda app-developers app

Sure, should be. Say you wanted to dump entire flash to one image, just add another partition to mtdparts parameter with offset 0 and size of 1020MB (in anzu case). Then you can dd from that new mtdblock device to sdcard. But I think you may get lots of I/o errors on the first 80MB, I am really not sure. Just make sure you don't try to write to it LOL.

Also I think our devices need bs=4096 (4KB) because that is the sector size of our nand chip.

EDIT: Maybe there is some unused space at the end of that first 80MB, I am not sure. Because baseband and adsp firmware is less than 80MB.

Sent from Xperia Play (R800a) with Tapatalk
 

[NUT]

Senior Member
Sure, should be. Say you wanted to dump entire flash to one image, just add another partition to mtdparts parameter with offset 0 and size of 1020MB (in anzu case). Then you can dd from that new mtdblock device to sdcard. But I think you may get lots of I/o errors on the first 80MB, I am really not sure. Just make sure you don't try to write to it LOL.

Also I think our devices need bs=4096 (4KB) because that is the sector size of our nand chip.

EDIT: Maybe there is some unused space at the end of that first 80MB, I am not sure. Because baseband and adsp firmware is less than 80MB.

Sent from Xperia Play (R800a) with Tapatalk

From what i know from using dd: it does a byte4byte copy, in any sector size you like but in any case it will read what the disk says there is, as long as there is a disk... so the o/i errors should only occur on those parts that are either damaged or non existent...

I'll do a partition as last option in the config_cmdline grabbing the theoretical maximum of 1024Mb and see if it will fly. :cowboy:

As the NAND flash chip has no logic that makes it a disk like entity other then direct access through MTD software logic (hence yaffs2 as filesystem of choice) i strongly doubt it will use the last 2/4Mb in the end as wear leveling buffer... :confused:
 

[NUT]

Senior Member
I'll do a partition as last option in the config_cmdline grabbing the theoretical maximum of 1024Mb and see if it will fly. :cowboy:

Well... it doesn't ... it craps out on the first sector it seems, but even if i skip the first sector it still doesn't want to go, probably because the partition size was wrong in the first place, but it's strange anyway.

Building a new testkernel with [email protected] which is one less in size, if 0 counts as the first, the last probably didn't exist :p

EDIT: nope, that one didn't fly either... dunno why, dd isn't very elaborate on it's errors :p
 
Last edited:

CosmicDan

Senior Member
Jun 19, 2009
5,890
7,736
34
Sydney
Google Pixel 3 XL
Xiaomi Poco X3 Pro
Well... it doesn't ... it craps out on the first sector it seems, but even if i skip the first sector it still doesn't want to go, probably because the partition size was wrong in the first place, but it's strange anyway.

Building a new testkernel with [email protected] which is one less in size, if 0 counts as the first, the last probably didn't exist :p

EDIT: nope, that one didn't fly either... dunno why, dd isn't very elaborate on it's errors :p

I think that beginning part is "read-protected" in userspace, I'm not sure. I will def. like to try this but my linux machine is awaiting repairs, I want to see if I can write to the amss (SBL) partition. Probably not though :p
 

[NUT]

Senior Member
I think that beginning part is "read-protected" in userspace, I'm not sure. I will def. like to try this but my linux machine is awaiting repairs, I want to see if I can write to the amss (SBL) partition. Probably not though :p

I would agree with you, except if I skip the first 92 Mb of the NAND with dd it still doesn't read... maybe the 'read-protection' foils that plan as well... I don't know ...
 

Top Liked Posts

  • There are no posts matching your filters.
  • 23
    See Post #2 for current known stock partition parameters for various devices. Your contributions for missing devices are welcome and appreciated. Cheers!

    Introduction


    This guide / reference aims to be a complete article on customizing, resizing and/or re-ordering the internal partition layout on most (any?) Android MTD-based device. I have seen many questions around the various forums on how to get more internal data so I thought I'd share my developments. Hopefully this will become a valuable resource for kernel builders/hackers.

    The guide is especially valuable (and, in the case of my kernel builds, originally designed for) the Xperia 2011 line, but from what I know it could be applied to nearly any Android device where kernel source/flashing is possible.

    I would like to gather stock partition information for various devices and place them into Post #2. If you can at least give me your Partition Info from ATAG (see "Gathering information" section), I can create a reference for all kernel developers. Thank you!

    Requirements

    • Android SDK
    • Ability to build a kernel (this guide does not teach that)
    • Ability to flash a kernel (unlocked bootloader, etc)
    • Bootloader which exposes Partition info via ATAG on startup (see "Gathering information" section)
    • Device which uses MTD Partition Map (Don't know how to check this, I think most Android devices do anyway)


    Warning

    As far as I know, following this guide and using precise calculation that you double and triple check before flashing will not result in a hard brick - however I can not guarantee it. Some devices may have "obscure" partition maps or some "protected" sectors for one reason or another, and modifying these *may* result in either a hard-brick (unlikely) or a permanent inability to restore your device to 100% stock (very likely) for warranty and/or DRM purposes. You have been warned. I/we/anyone may not be held accountable for any of these events should they occur, for you are doing this at your own risk and with your own responsibility.


    Gathering information


    1. The first thing you'll want to do for the sake of accuracy is to flash to a 100% stock firmware. In the case of Xperia 2011 devices, flash the latest stock FTF for your device.
    2. With the stock firmware now installed, the second thing you will need to do is to flash a custom kernel that is rooted and has busybox installed. In most cases, a CM7/9/10 kernel will do nicely.
    3. Power-off your device. Execute the following command from shell/console, and then press enter:
      Code:
      adb wait-for-device && adb shell dmesg
    4. After pressing enter, the console will wait at the prompt as intended. Now, power on your device and immediately plug in the USB cable. I assume the ADB drivers are already installed.
    5. Shortly (5-15 seconds) you should see a mass output from the kernel followed by a return to your shell prompt. If you don't, either your kernel or bootloader does not support it. Try a different kernel. If you still don't, then sorry but I think we can't do it for your device.
    6. Scroll right to the top of the dmesg output, you should see something similar to this:
      Code:
      <6>[    0.000000] Initializing cgroup subsys cpu                                                                                                           
      <5>[    0.000000] Linux version 2.6.32.9-KRsH ([email protected], Linaro 4.7) (gcc version Linaro 4.6.2 20111004) #8 PREEMPT Thu Oct 25 15:57:27 EST 2012   
      <4>[    0.000000] CPU: ARMv7 Processor [511f00f2] revision 2 (ARMv7), cr=10c53c7d                                                                          
      <4>[    0.000000] CPU: VIPT nonaliasing data cache, VIVT ASID tagged instruction cache                                                                     
      <4>[    0.000000] Machine: zeus                                                                                                                            
      <6>[    0.000000] Partition (from atag) system -- Offset:2e4 Size:9c4                                                                                      
      <6>[    0.000000] Partition (from atag) userdata -- Offset:ca8 Size:be0                                                                                    
      <6>[    0.000000] Partition (from atag) cache -- Offset:1cb4 Size:32c                                                                                      
      <6>[    0.000000] Partition (from atag) appslog -- Offset:1888 Size:42c                                                                                    
      <4>[    0.000000] Memory policy: ECC disabled, Data cache writeback
      ...see those "Partition (from atag)" lines? That's what we need! Copy this information down and move on to the next section.




    Additional verification and hidden partitions (optional)


    As far as I know, this is only possible with Xperia 2011 devices. If you know of a method for other devices, please let me know.


    We can additionally verify the ATAG information and map extra "hidden" partitions such as boot (kernel) by examining the SIN files inside an FTF. I will assume that you know how to use Flashtool already as I won't go into much detail here.


    First, we need to enable the development features of Flashtool. In the program folder, open "config.properties" and edit/add the line like so:
    Code:
    devfeatures=yes
    Next, extract your stock FTF bundle with any ol' ZIP extractor, load Flashtool, and select "Tools" > "SIN Editor", and open a particular SIN file that you want to verify/unhide. In this example, we will open system.sin. The "Partition Info" field is what we want. Behold:
    Code:
    STOCK SIN:
    system:   0400000001000080E4020000C4090000
                      --    --|------||------|
                       |    |     |       |
    type? (elf/yaffs) _/    |     |       \____ byte-reversed size
                            |     |
                unknown ____/     \____________ byte-reversed offset
    The second last 8-bytes are the offset and the last 8-bytes are the size. By "byte-reversed" I mean that you read each byte from end to beginning, but not swap the bytes themselves. Thus the size above, reading "C4090000" is actually "000009C4". And as you can see, this matches 100% to our ATAG of 9c4 for system size. Correct sir! Additionally, the offset of "E4020000" > reversed to "000002E4" also matches.


    So now, we can open "kernel.sin" and do the same, because we also want to partition "boot" (why not?). In this device (Xperia Play/Xperia Neo L), kernel.sin gives us 03000000220000808002000064000000 which means that the size is 64 and the offset is 280.



    Calculations


    From the partition info via ATAG, we can now build "stock" mtdparts information to apply to our kernel. Using the example(s) above, we can now build this information:


    Note the syntax of size@offset. Next, we must convert the hex values to decimal, then multiply by 128 (I do not know if 128 is the same multiplier for all devices, please double check and let me know). This will give us the exact sizes and offsets in kilobytes.


    Alright, so that is a 100% stock partition map for this device - except we also have the boot (kernel) mapped now too. Here is a (crappy) visual representation of it:


    Code:
     reserved  |  boot  |   /system   |     /data      |   appslog   | /cache  |
    first 80MB | 12.5MB |   312.5MB   |     380MB      |   133.5MB   | 101.5MB |
    
    Note: Not to scale :)
    You may have noticed that the order we (and ATAG) lists the partitions in does not match the actual order of the partitions. It is quite important to retain the order of the partitions as specified in ATAG, because that's the order they will be mapped in. I.e. system will remain mtdblock0 and cache will remain mtdblock2. Any extra partitions should always go after these defaults.





    Formatting for kernel


    To specify the mtdparts parameter for the kernel to use is trivial. Doing this will over-ride the ATAG map (from bootloader) and everything in the system - including Recovery - will see your map from the kernel. Search your default config file in your kernel for the value "CONFIG_CMDLINE" and you should find a value like this :
    Code:
    CONFIG_CMDLINE="console=ttyMSM2,115200n8 androidboot.hardware=semc"
    Using the information we have above about our partition map, we add a new parameter here with "mtdparts=msm_nand:". The syntax is as follows:
    Code:
    mtdparts=msm_nand:[size]@[offset](name){,[size]@[offset](name)}{...}
    Remember that we converted our size and offsets to kilobytes (for better readibility) so we need to specify size unit of k. The new parameter, from our above examples, becomes this:
    Code:
    mtdparts=msm_nand:[email protected](system),[email protected](userdata),[email protected](cache),[email protected](boot)
    Don't forget to retain the order! And so, our full line looks like this:
    Code:
    CONFIG_CMDLINE="console=ttyMSM2,115200n8 androidboot.hardware=semc mtdparts=msm_nand:[email protected](system),[email protected](userdata),[email protected](cache),[email protected](boot)"
    NOTE: Depending on your kernel, you may also need to enable the following line in your config:
    Code:
    CONFIG_MTD_CMDLINE_PARTS=y
    And we're all done. If you build your kernel now, you will be able to mount (or at least dd from) the appslog and boot partitions.




    Resizing partitions


    This is somewhat trivial, the most difficult part is probably over - but this step can be tedious, albeit not very complicated. Anybody with an above average IQ would have already figured this out - we simply change the size of one partition and adjust the offsets of it's following partitions to accommodate for the change. Here is one good example that I use for the MIUI ROM for the Xperia Play and Neo L, compared to the stock examples shown above:
    Code:
    mtdparts=msm_nand:[email protected](system),[email protected](userdata),[email protected](cache),[email protected](boot)
    ...and a visual representation of this new map:
    Code:
     reserved  |  boot  |   /system   |               /data               |/cache|
    first 80MB | 12.5MB |    280MB    |               639MB               |  8MB |
    
    Note: Not to scale :)
    Hopefully that's enough to make sense. Remember to verify your modified partitions. This can easily be done by adding the size+offset of a partition, giving the offset of the next partition. E.g. in this mod, userdata ends at 1036288 (654848+381440) which matches the offset for the next partition - cache.




    Troubleshooting/Recovering from modified partitions


    In some cases, your new kernel may not boot. A common issue is that the kernel logo will show, and the device will shortly reboot (kernel bootloop). This can be solved by formatting your partitions with fastboot after flashing the new kernel, usually system and userdata are all that is needed:

    Code:
    fastboot format system
    fastboot format userdata
    If you wish to return to a stock partition layout, sometimes flashing a non-modified kernel is not enough. You may get stuck on kernel logo even after formatting system and userdata. In this case, flashing a stock Firmware and setting your phone back to scratch should result in a 100% original device. But if your phone is still bricked, sorry but it's not my fault. You probably did something wrong.





    #####



    OK, that's the guide done for now. Any questions or suggestions on the guide, please let me know! Also, refer to post #2 for some stock partition map reference.
    8
    Finding Stock Partition Info For Your Device

    Three methods:

    1. Most reliable - See the section "Gathering info" above to get it from ATAG
    2. Only shows size without offset - do "cat /proc/mtd" from adb shell. Can be used to test if you're on stock partitions or not, or to verify partition is big enough for update ZIP's (with sed/grep).
    3. Xperia 2011 Only - Examine SIN header as outlined above. This method is difficult to determine mtd block order but I'm 99% sure the order is same for all Xperia 2011 devices (system=mtd0, userdata=mtd1, cache=mtd2).


    Stock Partition Parameters for Various Devices

    Xperia 2011 Range:
    Code:
    [B]anzu (Arc) (LT15) (HDPI):[/B]
    (03) kernel   - [email protected]   ([email protected])    (unmapped)
    (04) system   - [email protected]  ([email protected])
    (05) amss     - [email protected]    ([email protected])     (unmapped)
    (06) amss_fs  - [email protected]    ([email protected])    (unmapped)
    (08) adsp     - [email protected]   ([email protected])    (unmapped)
    (09) userdata - [email protected]  ([email protected])
    (10) vendor   - [email protected] ([email protected])
    (0B) fota0    - [email protected]   ([email protected])    (unmapped)
    (0C) fota1    - [email protected]   ([email protected])    (unmapped)
    mtdparts=msm_nand:[email protected](system),[email protected](userdata),[email protected](cache),[email protected](appslog),[email protected](amss),[email protected](amss_fs),[email protected](adsp),[email protected](fota0),[email protected](fota1),[email protected](boot)
    
    [B]ayame (Arc S) (LT18) (HDPI):[/B]
    (03) kernel   - [email protected]   ([email protected])    (unmapped)
    (04) system   - [email protected]  ([email protected])   
                         \ this is odd, there is 2048k unallocated between boot and system (SEMC made a mistake?)
    (05) amss     - [email protected]    ([email protected])     (unmapped)
    (06) amss_fs  - [email protected]    ([email protected])    (unmapped)
    (08) adsp     - [email protected]   ([email protected])    (unmapped)
    (09) userdata - [email protected] ([email protected])
    (10) vendor   - none
    (0B) fota0    - [email protected]   ([email protected])    (unmapped)
    (0C) fota1    - [email protected]   ([email protected])    (unmapped)
    mtdparts=msm_nand:[email protected](system),[email protected](userdata),[email protected](cache),[email protected](boot),[email protected](amss),[email protected](amss_fs),[email protected](adsp),[email protected](fota0),[email protected](fota1)
    
    [B]haida (Neo V) (MT11) (HDPI):[/B]
    [I]Same as ayame (Arc S) (LT18)[/I]
    
    [B]hallon (Neo) (MT15) (HDPI):[/B]
    [I]Same as anzu (Arc) (LT15)[/I]
    
    [B]iyokan (Pro) (MK16) (HDPI):[/B]
    [I]Same as ayame (Arc S) (LT18)[/I]
    
    [B]mango (Mini Pro) (SK17) (MDPI):[/B]
    ??
    
    [B]satsuma (Active) (ST17) (MDPI):[/B]
    ??
    
    [B]smultron (Mini) (ST15) (MDPI):[/B]
    ??
    
    [B]urushi (Ray) (ST18) (HDPI):[/B]
    ??
    
    [B]phoenix (Neo L) (MT25) (HDPI):[/B]
    [I]Same as anzu (Arc) (LT15)[/I]
    
    [B]zeus/zeusc (Play) (R800) (HDPI):[/B]
    [I]Same as anzu (Arc) (LT15)[/I]
    R800a (and probably i/at, but not x) has unallocated vendor partition. Needs one-time flash of Vendor-enabled FTF (e.g. phoenix or anzu) to allocate it otherwise the vendor map will present I/O errors.
    4
    Xperia mini pro SK17i

    hi

    partition info for Xperia mini pro SK17i

    ATAG:

    Code:
    [SIZE="2"]
    <6>Initializing cgroup subsys cpu
    <5>Linux version 2.6.32.9-LuPuS-CM9 ([email protected]_dd93) (gcc version 4.6.2 20111004 (prerelease) (Linaro GCC 4.6-2011.10) ) #32 PREEMPT Wed Jan 2 18:56:37 IST 2013
    <4>CPU: ARMv7 Processor [511f00f2] revision 2 (ARMv7), cr=10c53c7f
    <4>CPU: VIPT nonaliasing data cache, VIVT ASID tagged instruction cache
    <4>Machine: mogami
    <6>Partition (from atag) system -- Offset:2f4 Size:c80
    <6>Partition (from atag) appslog -- Offset:f74 Size:30
    <6>Partition (from atag) cache -- Offset:fa4 Size:32c
    <6>Partition (from atag) userdata -- Offset:12d0 Size:d20
    <4>Memory policy: ECC disabled, Data cache writeback
    [/SIZE]

    from .sin files:
    apps_log.sin, cache.sin and loader.sin are showing the value of "00" in flashtool

    Code:
    [SIZE="2"]
                                              size    offset
    adsp.sin          | 0000006C | 0000015C | 13824 | 44544
    amss.sin          | 000000E4 | 00000010 | 29184 | 2048
    amss_fs_mango.sin | 00000068 | 000000F4 | 13312 | 31232
    fota0.sin         | 0000005C | 000001C8 | 11776 | 58368
    fota1.sin         | 0000005C | 00000224 | 11776 | 70144
    kernel.sin        | 00000064 | 00000280 | 12800 | 81920
    system.sin        | 00000C80 | 000002F4 | 409600 | 96768
    userdata.sin      | 00000D20 | 000012D0 | 430080 | 616448
    [/SIZE]

    in order:

    Code:
    [SIZE="2"]
    01. bootloader        0-2 MiB (2 MiB)
    02. amss.sin          2-30,5 MiB (28,5 MiB)
    03. amss_fs_mango.sin 30,5-43,5 MiB (13 MiB)
    04. adsp.sin          43,5-57 MiB (13,5 MiB)
    05. fota0.sin         57-68,5 MiB (11,5 MiB)
    06. fota1.sin         68,5-80 MiB (11,5 MiB)
    07. kernel.sin        80-92,5 MiB (12,5 MiB)
    08. empty space?      92,5-94,5 MiB (2 MiB)
    09. system.sin        94,5-494,5 MiB (400 MiB)
    10. apps_log.sin      494,5-500,5 MiB (6 MiB)
    11. cache.sin         500,5-602 MiB (101,5 MiB)
    12. userdata.sin      602-1022 MiB (420 MiB)
    13. empty space?      1022-1024 MiB (2 MiB)
    
    total 1 GiB
    [/SIZE]
    3
    Reserved again (just in case)
    3
    Very nice work mate! (Especially for using ATAGs...)
    I just started the related thread:

    "[DEV][REF] El Grande Partition Table Reference"
    To collect detailed partition info from various devices...

    Heh nice! Yours looks a bit more hardcore than mine, I've never used any of those tools :p

    I started this guide so I can port kernels to various devices for Xperia 2011 range, and also to help other devs appeal the users who crave for more internal partition space. But so far, none of these people seem to have the patience to lend a hand with gathering data :(