This is a development thread whose main purpose is to catalog and document
the various partition tables used by our manufacturers in our loved Androids.
Thread Difficulty: Medium (some risk of bricking)
Quote:
When people get a bad flash and soft-brick their devices, one of the first
things that need to be done, is finding out on what partition that flash went
bad. This information can be extremely valuable since it could very well make
the difference between loosing or keeping all your data.
In addition, it will help clarify much of the partitioning confusion that has
arisen because of the many different partitioning schemes used in different
devices and by different hardware manufacturers.
Thus you can help by providing your complete partition tables in this thread
in one post. In order for this information to be useful, you will have to
provide and specify the following:
Code:
General Device Name: Samsung Galaxy S2
Manufacturer Product Name: GT-I9100
Processor: Exynos 4210
AOS version: Android GB 2.3.4
Radio FW version: XXKI1
System FW version: XXKE4
Service Provider/ Branding: T-mobile
Country: Germany
<< output of parted >>
<< output of fdisk >>
<< output of gdisk >>
<< Any additional info you'd like to share. See text.>>
Additional information that could be useful, include:
Code:
a) The alternative commands shown in post#2 below.
b) Other hardware info that can often be found in the PDA database.
c) A link to a text paste site with the output from:
1. dmesg (directly after reboot)
2.
How To Post Here
To make your post compact and stylish, post using the "Go Advanced"
and put your command output in "CODE" tags and choose: "Sizes" ==> 2.
If you know how to, also replace all tabs (\t) with spaces. If your output
is excessively large, please use paste site (pastebin, pastie etc.) instead
of multiple posts.
Also, please search the thread for previous devices before posting
your own results, unless they differ significantly.
================================================== This is a development thread. Do not ask for help with this or that, this is not a support thread! Make sure that any question you might have, is directly related to the benefit of this thread and on-topic. If not your post will be removed. ==================================================
The goal here is to obtain as detailed information about your device
partitions as possible. The most important information are (with example):
Code:
- Partition Number 2
- Partition Name mmcblk0p2
- Partition Type EXT4
- Partition MBR ID 83
- Partition GPT ID 8300 /
- Partition Label SBL1
- Partition Description Secondary Bootloader 1
- Start block (hex/dec) 0x1000
- End block (hex/dec) 0x1fff
- Partiton Size (hex/dec) 0x1000
- Partition Content Qualcomm SBL1 bootloader image (sbl1.img)
As a good example of a fairly complete partition table is that of the Verizon Samsung Galaxy S3 (SCH-I535), as shown in post#3, although it is
still missing some relevant data, it was completed using the commands
shown in post#2.
Thanks in advance for wanting to help to make this thread an awesome
and great partition table reference.
Although the way to obtain your complete partition table layout varies from
device to device, there are some standard tools and methods to do this. The
most important thing to know, especially if you're used to the old-school
Windows/Linux Master Boot Record (MBR) type file systems, is that most modern
Android smartphones now make heavy use of the GUID Partition Table (GPT)
structure (formatting). Thus you will need some slightly different tools, to
obtain the proper information from your device. Different tools give different
information, as we shall see.
NOTE:You have to be rooted to use these tools!
Example-1: (Partition Tables for the Samsung Galaxy S2 GT-I9100)
Here we get our partition table using three different tools:
fdisk
parted
gdisk (aka gptfdisk)
And the results will differ quite dramatically.
1. Using fdisk:
Code:
/ # fdisk -l /dev/block/mmcblk0
Disk /dev/block/mmcblk0: 15.7 GB, 15756951552 bytes
1 heads, 16 sectors/track, 1923456 cylinders
Units = cylinders of 16 * 512 = 8192 bytes
Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 1 1923456 15387647+ ee EFI GPT
Partition 1 does not end on cylinder boundary
2. Using parted:
Code:
/ # parted /dev/block/mmcblk0
GNU Parted 1.8.8.1.179-aef3
Using /dev/block/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
p
Model: MMC VYL00M (sd/mmc)
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 4194kB 25.2MB 21.0MB ext4 EFS
2 25.2MB 26.5MB 1311kB SBL1
3 27.3MB 28.6MB 1311kB SBL2
4 29.4MB 37.7MB 8389kB PARAM
5 37.7MB 46.1MB 8389kB KERNEL
6 46.1MB 54.5MB 8389kB RECOVERY
7 54.5MB 159MB 105MB ext4 CACHE
8 159MB 176MB 16.8MB MODEM
9 176MB 713MB 537MB ext4 FACTORYFS
10 713MB 2861MB 2147MB ext4 DATAFS
11 2861MB 15.2GB 12.4GB fat32 UMS
12 15.2GB 15.8GB 537MB ext4 HIDDEN
3. Using gdisk:
Code:
/ # gdisk -l /dev/block/mmcblk0
GPT fdisk (gdisk) version 0.8.4
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/block/mmcblk0: 30775296 sectors, 14.7 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 52444E41-494F-2044-4D4D-43204449534B
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 30775262
Partitions will be aligned on 2048-sector boundaries
Total free space is 17341 sectors (8.5 MiB)
Number Start (sector) End (sector) Size Code Name
1 8192 49151 20.0 MiB 0700 EFS
2 49152 51711 1.2 MiB 0700 SBL1
3 53248 55807 1.2 MiB 0700 SBL2
4 57344 73727 8.0 MiB 0700 PARAM
5 73728 90111 8.0 MiB 0700 KERNEL
6 90112 106495 8.0 MiB 0700 RECOVERY
7 106496 311295 100.0 MiB 0700 CACHE
8 311296 344063 16.0 MiB 0700 MODEM
9 344064 1392639 512.0 MiB 0700 FACTORYFS
10 1392640 5586943 2.0 GiB 0700 DATAFS
11 5586944 29720575 11.5 GiB 0700 UMS
12 29720576 30769151 512.0 MiB 0700 HIDDEN
I have collected the above three tools into one ZIP package
that you can download HERE. << WIP TBA >>
Download the ZIP containing partedHERE.
(Do not use/push/install anything else than "parted", as they may
already be present on your system, or in Busybox.)
The gptfdisk binary is rather large (~1.5 MB) as it is statically compiled.
It would be nice if someone could create an NDK based dynamic binary.
Download the binary HERE. (SourceForge, Info)
Quote:
! WARNING !
Be careful with parted, make sure you tell it to "Ignore" any errors it might
find. Also you have to type "quit" to get it to exit from interactive mode.
Similarly, you'll probably also get various scary warnings when using gdisk.
Same thing here. Make sure to ignore, never attempt to repair, unless you know
exactly what you're doing!
You may get other warnings as well, but should always be ignored. This is due
to the fact that many devices are using some kind of hybrid proprietary MBR/GPT partitioning with accompanying tables. This is especially true for
Qualcomm based devices from Samsung and HTC.
Collecting Alternative Information
There are several system commands and files that you can use, that contain
partitioning information. The most common ones are:
[You will probably need to modify these to suit your particular storage device.]
Another useful place for info is in the Kernel and debug messages output.
However, these commands need to be performed as soon as possible after a
reboot, since the message log is a ring-buffer of only 4K. (Meaning it will soon
overwrite itself.)
The Following 8 Users Say Thank You to E:V:A For This Useful Post: [ Click to Expand ]
8zabi (23rd February 2013), Const60 (7th November 2012), daxxone (31st October 2012), FreeDee (7th December 2012), LQi (2nd May 2013), lutadore (31st October 2012), smw6180 (19th February 2013), trogdan (3rd November 2012)
So to be a good example, let me start to post the complete partition table
for the US Verizon, Samsung Galaxy S3 (SCH-I535). It was probably obtained
from a screenshot of one of Samsung's internal documents, not available for
public scrutiny. I then had to add additional information from other peoples
devices to complete the details. Still, it is likely there will be some
variations due to hardware and updated firmware etc. But it does serve as a
great and informative example of a top-of-the-line Android partition table.
So to follow my own instructions:
Code:
General Device Name: Samsung Galaxy S3
Manufacturer Product Name: SCH-I535
Processor: Qualcomm Snapdragon 4S+ (MSM8960)
AOS version: Android GB 4.0.4
Radio FW version: <na>
System FW version: <na>
Service Provider/ Branding: Verizon
Country: USA
Here I give a general description to the various partitions. Most of them have
been determined, but some still remain somewhat mysterious. But there are
Terabytes written about various partition schemes and file systems etc, but
some good sources for our purpose are found on Wikipedia and Microsoft.
But the most important thing to understand, is that most of the technical
ingredients (as show in the previous post) is hardware dependent. Thus the
Android partition schemes depend on the processor / modem combination and
their firmware, and thus also the kernel, to some extent.
General Android Partition Description (Qualcomm MSM8960)
The function and content of many of the partitions are not very well
described, nor easily found in one place. Here are some further details,
that apply primarily to Qualcomm Snapdragon S4/+ based Android devices.
However, Windows Phones using these these SoC's should have a very similar
partition structures, but with different names.
For details about: RPM (PBL), SBL1, SBL2, SBL3, TZ and ABOOT (APPSBL), please
see this and this thread, where they are extensively discussed and described.
GPT: See section on PIT and GPT "partitions" below.
BACKUP: This partition should contain a copy of MODEMST2. Whether it does or
not, is described in the PARAM partition.
BOOT: This is the partition that enables the phone to boot, as the name
suggests. It includes the kernel and the ramdisk. Without this partition, the
device will simply not be able to boot. Wiping this partition from recovery
should only be done if absolutely required and once done, the device must NOT
be rebooted before installing a new one, which can be done by installing a ROM
that includes a /boot partition.
CACHE: Contain the firmware update package which is downloaded from server,
and the recovery log file. Other uses include storage for frequently accessed
data and application components. Wiping the cache doesnt effect your personal
data but simply gets rid of the existing data there, which gets automatically
rebuilt as you continue using the device.
DATA / USERDATA: This partition contains the user's data this is where your
contacts, messages, settings and apps that you have installed go. Wiping this
partition essentially performs a factory reset on your device, restoring it to
the way it was when you first booted it, or the way it was after the last
official or custom ROM installation. When you perform a wipe data/factory
reset from recovery, it is this partition that you are wiping.
EFS: The Android EFS partition stores all your phones important, but
accessible, hardware data, such as WiFi/BlueTooth MAC's, IMEI (or ESN for a
CDMA based device) and some others.
FOTA: Is the Firmware Over The Air partition. After the update package has
been downloaded from the server it is saved into the CACHE partition. After
that the userspace application that does the download writes a special cookie
into the FOTA partition. This cookie tells the bootloaders to take the
necessary steps to boot into recovery mode
FSG: Probably stands for File System (FS) "Golden". According to Samsung
documentation, this partition is a "Golden Copy". This is partially confirmed
by RE of the PARAM partition, which indicate that this partition should
contain a copy of MODEMST1.
GROW: << unknown >>
MISC: This partition contains miscellaneous system settings in form of on/off
switches. These settings may include CID (Carrier or Region ID), USB
configuration and certain hardware settings etc. This is an important
partition and if it is corrupt or missing, several of the devices features
will will not function normally. Not all devices have this partition.
PARAM: This is the Parameter partition which contains a number of parameters,
variables and settings of the hardware. Apparently it has an 88 byte header
structure that tell us if the MODEMST1 and MODEMST2 have been backed up to the FSG and BACKUP partitions, respectively. Furthermore it contain all the debug
settings (DLOW/DMID/DHIG etc), the "triangle" status of whether or not you have
flashed custom ROMs and the flash count (0x3FFE00). Current boot mode in use,
and much more. The info about this partition could easily occupy a book by
itself.
PERSIST: << unknown >> The use of this partition is unknown and apparently
only exists on Qualcomm based devices.
PIT: See below.
RECOVERY: Holds the recovery boot image. When updating the system we boot
into recovery mode by using the boot image stored in this partition. It lets
you boot the device into a recovery console for performing advanced recovery
and maintenance operations on it.
SSD: "Secure Software Download" is a memory based file system (RAMFS) for
secure storage, used to download and store "who knows what" on the eMMC. It is
a referenced part in the Remote Storage RPC Client of the MSM kernel.
SYSTEM: This partition basically contains the entire operating system, other
than the kernel and the ramdisk. This includes the Android user interface as
well as all the system applications that come pre-installed on the device.
Wiping this partition will remove Android from the device without rendering it
unbootable, and you will still be able to put the phone into recovery or
bootloader mode to install a new ROM.
When inspecting the partitioning of the eMMC's used by Qualcomm Snapdragon based
hardware, we see that they tend to use different partition types, for their
different partitions depending on their function. For example, for the MSM8960
SoC/PoP, we often find the following partition ID's, when inspected by
mounting the device with on linux PC. This seem to remain fairly consistent across
all their Snapdragon class/based devices.
Code:
ID Type Label oldLabels Filename(s) Description
-----------------------------------------------------------------------
05 EXT -- -- -- Extended partition
0C FAT32X MODEM FAT non-hlos.bin
45 SBL3 sbl3.mbn
46 TZ OEMSBL tz.mbn, osbl.mbn
47 RPM rpm.mbn
48 BOOT boot.img
4A MODEM_ST1 --
4B MODEM_ST2 --
4C ABOOT emmc_appsboot.mbn
4D Boot SBL1 CFG_DATA sbl1.mbn, dbl.mbn
51 SBL2 sbl2.mbn
58 FSG --
5D ??HTC
60 RECOVERY recovery.img
64 ?BOOT1 --
65 "misc" misc.img
83 EXT4 [1] // // Native Linux
-----------------------------------------------------------------------
[1] This is a standard linux partition of any EXT2/3/4 type, thus there
are many different labels used here.
Some additional partition IDs found from their CodeAurora sources in
[kernel/msm][arch/arm/mach-msm/rmt_storage_client.c]:
Thus we can conclude that most of the standard (but outdated) MBR definitions
of partition type ID's are no longer valid, but used as an identifier for
various sub-system software.
From another document [80-VP120-1 Rev.K] the Secure Boot 3.0 based devices use MBR partition types as shown below:
However, this document is from 2010 and may not be up-to-date with what you have.
Check your kernel sources!
That is, 0x200 bytes for the protective MBR, 0x200 bytes for the GPT header,
and 128 x 128 bytes GPT partition headers = 0x4400 bytes for the full GPT block.
The PIT file contains partition names (BOOT), the names of the files that go
in them (boot.img), the size of each partition, the partition ID (7), and any flags (RO).
The GPT contains the physical layout for the partitions in memory and reads all the info from the PIT to fill in the blanks.
I find it useful to understand, that from the low-level point of view, an eMMC and SSD are essentially
the same. An SSD is basically a huge eMMC, but where the NAND chips are used in parallel, similar to
a Raid-0 configuration, but with an added DRAM cache buffer and a SATA interface operating at 5V.
So, apart from the more advanced microcontroller, the wear-leveling etc. works in the same way.
"Bad block management (BBM) is a critical component of NAND flash drivers to
improve the reliability and endurance of the flash. NAND is shipped from the
factory with 'mostly good' cells, meaning there are some cells that are
non-functional even when the flash is new. Blocks can also go bad over time,
causing loss of data stored in the flash memory or even a bricked device."
"Flash life is limited to the number of erase cycles for which your part is
rated. By distributing write/erase cycles evenly throughout the flash, a
properly executed wear-leveling algorithm can more than double the life of
your product. FlashFX Pro uses both static and dynamic wear-leveling to
achieve 133% longer life than MSFlash, the flash manager found in Windows CE
and WindowsMobile. The charts below show a test comparison between a FlashFX
Pro disk and one using MSFlash. Flash disks read and write data in a grid of
erase blocks. Once a block reaches its maximum rated erase count, the flash is
at risk of lost or corrupted data, becoming a "broken" device. For this test,
we recorded the erase counts by block and applied a heat map ranging from
white (lowest use) to green (medium use), to black (highest use). As the
heatmap shows, the MSFlash disk contains many blocks that are well over their
rated lifespan, while other blocks are barely used. The FlashFX Pro disk shows
what happens when proper wear-leveling algorithms are employed. All blocks are
evenly worn and within a tight range of erase counts, making your handheld
last more than twice as long, and protecting the reputation for durability
you've worked hard for."
"Flash parts are commonly divided into partitions, which allows multiple
operations to occur simultaneously (erasing one partition while reading from
another). Partitions are further divided into blocks (commonly 64KB or 128KB
in size). The only Write operation permitted on a flash memory device is to
change a bit from a one to a zero. If the reverse operation is needed, then
the block must be erased (to reset all bits to the one state). NOR flash
memory can typically be programmed a byte at a time, whereas NAND flash memory
must be programmed in multi-byte bursts (typically, 512 bytes)"
Basic Wear Leveling
MLC devices typically support fewer than 10,000 program/erase (PE) cycles. So
if you erased and reprogrammed a block every minute, you would exceed the 10K
cycling limit in just 7 days!
Code:
60 × 24 × 7 = 10,080 (cycles/block)
So rather than cycling (re-programming) the same block, wear-leveling moves
data around to other blocks so that blocks are more evenly cycled.
Example: An 8GB eMMC MLC-based device
This device has 4096 independent blocks. So if we took the previous example
and distributed the cycles over all 4,096 blocks, each block would have been
programmed fewer than three times. (10,000/4096 = 2.44 [cycles/block/per
week]) (versus the 10,800 cycles when you cycle the same block)
So if we cycle some block once every minute, we have:
However, this is far from what can be expected. For example, the guaranteed
cycle count may apply only to block zero (as is the case with TSOP NAND
devices). And accrding to WikiPedia, "MLC NAND flash used to be rated at about
5–10K cycles (Samsung K9G8G08U0M) but is now typically 1–3K cycles"
According to THIS very informative page, "34nm MLC NAND is good for 5,000
write cycles, while 25nm MLC NAND lasts for only 3,000 write cycles."
Then there is the possibility of "read disturb", The method used to read NAND
flash memory can cause nearby cells to change over time if the surrounding
cells of the block are not rewritten. This is generally on the order of ~100K
reads without a rewrite of those cells. The error does not appear when reading
the original cell, but shows up when finally reading one of the surrounding
cells.
Then there is Write Amplification (WA): [for SSD but also applicable to us]
"An undesirable phenomenon associated with flash memory and solid-state drives
(SSDs) where the actual amount of physical information written is a multiple
of the logical amount intended to be written. Because flash memory must be
erased before it can be rewritten, the process to perform these operations
results in moving (or rewriting) user data and metadata more than once. This
multiplying effect increases the number of writes required over the life of
the SSD which shortens the time it can reliably operate. The increased writes
also consume bandwidth to the flash memory which mainly reduces random write
performance to the SSD."
Write amplification is typically measured by the ratio of writes coming from
the host system and the writes going to the flash memory. A lower write
amplification is more desirable, as it corresponds to a reduced number of P/E
cycles on the flash memory and thereby to an increased NAND life,
Then there is Over-provisioning (OP), which is the difference between the
physical capacity of the flash memory and the logical capacity presented through
the operating system as available for the user. During the garbage collection,
wear-leveling, and bad block mapping operations on the SSD, the additional space
from over-provisioning helps lower the write amplification when the controller
writes to the flash memory.
Vocabulary:
MLC = Multi Level Cell: NAND stores four states per memory cell and enables two bits programmed/read per memory cell
SLC = Single Level Cell: NAND stores two states per memory cell and enables one bit programmed/read per memory cellenables cell
What does all this mean?
Well, it means a lot! Here are just a few things:
We have to use host-based disk encryption to ensure we don't leave private data on eMMC/SSD.
(Re-formatting and erasure just doesn't work, as ensured by internal wear-leveling, unless
secure erase is enabled permanently. But this is not yet supported in older JEDEC!)
We should always choose the largest available memory device to maximize life.
We should have the source code and eMMC specifications to verify device specifications
and the proper handling and quick resolution of future bugs.
Most of the following is based on the information given by "Its Reh" in this post.
Code:
General Device Name: HTC One X LTE (US) [aka "HOXL"]
Manufacturer Product Name: HTC One X LTE
Processor: Qualcomm Snapdragon 4S+ (MSM8960)
AOS version: ICS 4.0.4 ?
Radio FW version: <na>
System FW version: <na>
Radio Service: CDMA/LTE ?
Network / Carrier: AT&T, Verizon, + others
Country: US
Similar Device: unknown, possibly HTC One S (US)
But much information have been collected from many other sources, as well. Why all this difficulty?
Because of the many OEM custom modifications of the filesystems used in the
HTC devices, many of the standard partition commands fails to provide complete
and correct information. Thus a combination of the various command output in
addition to other external info, can help us construct a more complete picture
of the (US) HOXL partition table.
It is very important to know that the US HTC One X LTE (HOXL) is very
different from the Chinese HTC One X and the One XL, in the common idiotic
spirit of HTC using the same name for completely different hardware. (There
are probably even more devices in other countries.)
Since the US HOXL is using an older version of the bootloader build-tool we
get the most reliable partition information from the fdisk command. We can
draw this conclusion, based on three observations. (1) Because fdisk complain
that the first 4 (primary) partitions "doesn't end on a cylinder boundary", is
a typical indication of using sparse disk images for partitions p1-4, and the
fact that (2) this partition scheme is still suffering from the HTC
partitioning-loop bug. Which mean you can ignore all partitions >36. Finally
(3), they seem to use it to format a native GPT based (?) eMMC device, using
an MBR-like structure and related tools. This causes gdisk to fail recognizing
the MBR style FS-types and erroneously marks them as a "Linux filesystem"
(8300).
We can also use some of the fastboot commands to show the nature of the eMMC
primary partitions. The command format from (windows) CMD prompt is:
fastboot oem <command>
Code:
Command Description
-----------------------------------
list_partition_emmc --> List the primary eMMC partitions (index, type, start, num)
check_emmc_mid --> Check eMMC Manufacterer ID
get_wp_info_emmc --> Show eMMC write protection group size (in blocks?)
get_sector_info_emmc --> Show available eMMC Sectors (free or start?)
Partition tables are not only reserved to PCs and Smartphones,
here's a great example of a modern TV set, that runs on an ARM
processor and a Samsung modified Linux based OS, called VDLinux.
Most of these devices also run applications that can be downloaded,
and hacked...
Not too long ago, we talked about how Sony was continuing its AOSP efforts on … more
XDA Developers was founded by developers, for developers. It is now a valuable resource for people who want to make the most of their mobile devices, from customizing the look and feel to adding new functionality. Are you a developer?
Introducing XDA:DevCon A Conference For Developers By Developers
>
[DEV][REF] El Grande Partition Table Reference
Print
Email
[DEV][REF] El Grande Partition Table Reference
View Profile
View Forum Posts
Linear Mode
