11

There is much talk of Android partitions that can be found with Google. Sometimes I can find references to GPT in documentation for mobile processors or on XDA Developers (where I have learned that certain devices do use GPT as their scheme). Aside from that, there is not much discussion about what Android devices use for storing partition information. There are exceptions: I know some devices use the MTD subsystem's command line-based method, like some of HTC's earlier devices, and I know that Qualcomm devices seem to use a GUID Partition Table.

If a device's partitions are represented by device nodes starting with mtd or mtdblock, then Linux receives the partition information from the boot arguments. If the partitions are represented by device nodes beginning with mmcblk, then the partition scheme is ambiguous. It could be using a GUID Partition Table, but the problem is that the table would have to start at the first sector which is also where all first-stage bootloaders reside in my experience.

Just as partition information on devices whose partitions' nodes begin with mtd can be found in /proc/mtd, on devices where the device nodes begin with mmcblk, the same information can (usually) be found at /proc/emmc. Why eMMC, a type of storage device, is treated like an alternative to MTD, which is an interface for accessing flash storage, I don't know. But this page on GitHub seems to imply that the partition information for devices with /proc/emmc is not gathered a table like GPT.

That same page seems to also be saying that kernels booted by U-Boot expose partitions in a different manner than MTD or GPT. Here is the passage:

Since MTK devices use the uboot mechanism, partitions including boot and recovery, are not revealed as separate partitions, but rather accessed sequencially by size and start parameters.

That sentence is rendered meaningless to me by the bit about sequential access. Perhaps someone can explain it better.

So how common is the GPT on Android devices? I've not seen any reference to partitioning on the Android developer website. If bootloaders are actually stored after the partition table, then does that mean the chips are GPT-aware?

Improve this question
4
  • As far as I know, most Android devices use GPT. You can check it easily by fdisk -l /dev/block/mmcblk0. BTW, this thread can be helpful: El Grande Partition Table Reference
    – Gokul NC
    May 30, 2016 at 10:16
  • @GokulNC I've seen that thread. It's one of the ones that I was talking about. Devices that use the MTD subsystem, which would seem to be a decent number of early Android smartphones, though, do not use a partition table. In those cases, there might be an MBR stored at the first sector/block of internal memory if the boot ROM of the SoC is designed with that in mind (the first-stage bootloader in OMAP-based devices starts 512 bytes in, for instance).
    – Melab
    Jun 2, 2016 at 17:29
  • do partition tables have to be on the first sector? maybe a SoC can boot from the last sector too, like reverse sector reading?
    – jiggunjer
    Feb 1, 2017 at 4:15
  • Also regarding MTD vs eMMC: the MTD is for raw NAND type storage, so uses different drivers than managed NAND like eMMC.
    – jiggunjer
    Feb 1, 2017 at 4:23

1 Answer 1

Reset to default
5

If I'm not wrong, GPT is pretty common. It's pretty advanced format than MBR. On my KitKat, they have 36 partitions. GPT has features like a backup partition table and naming/flag, and supports larger disks than MBR. (Android 6.0 introduces the ability to adopt external storage media which uses GPT as default partition format.)

A device may or may be aware of GPT. Typically with MBR, the first 512 bytes are used for the partition table. When we use GPT, it doesn't store any data on 1st sector. Instead, it gets marked as a protective MBR, so that if the device looking for MBR complaints, there is no partition.

If you are interested in the in-depth document:

Improve this answer
0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .