11/9/23, 6:18 PM eMMC Partition Management · Linux Kernel Internals

eMMC partition management

Partitions Overview
In the eMMC standard, the internal Flash Memory is divided into 4 types of areas, which can
support up to 8 hardware partitions, as shown in the following figure:

Overview
Under normal circumstances, the capacity of Boot Area Partitions and RPMB Partition is usually
4MB, and some chip manufacturers will also provide configuration opportunities. General
Purpose Partitions (GPP) are not supported by default at the factory, that is, these partitions do
not exist. The user needs to actively enable it and configure the capacity of the GPP to be used.
The number of GPPs can be 1 - 4, and each GPP The capacity size can be different. The
capacity of the User Data Area (UDA) is the total capacity minus the capacity occupied by other
partitions. More details of each partition will be described in subsequent sections.

https://linux-codingbelief-com.translate.goog/zh/storage/flash_memory/emmc/emmc_partitions.html?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en&_… 1/10
11/9/23, 6:18 PM eMMC Partition Management · Linux Kernel Internals

Partition addressing
The storage space of each hardware partition of eMMC is independently addressed, that is, the
access address is 0 - partition size. Which hardware partition is actually accessed by the specific
data read and write operations is determined by Bit[2:0]: PARTITION_ACCESS in the
PARTITION_CONFIG Field of the Extended CSD register of eMMC. The user can switch access
to the hardware partition by configuring PARTITION_ACCESS. In other words, before accessing
a specific partition, the user needs to send a command to configure PARTITION_ACCESS, and
then send the relevant data access request. For more details on data reading and writing,
please refer to the eMMC bus protocol chapter.
Each hardware partition of eMMC has its own functional characteristics, and the multi-partition
design provides convenience for different application scenarios.

Boot Area Partitions

Boot Area contains two Boot Area Partitions, which are mainly used to store Bootloader and
support SOC to boot the system from eMMC.

Capacity
The sizes of the two Boot Area Partitions are exactly the same and are determined by the
BOOT_SIZE_MULT Field of the Extended CSD register. The size calculation formula is as
follows:

Size = 128Kbytes x BOOT_SIZE_MULT

Generally, the size of Boot Area Partition is 4 MB, that is, BOOT_SIZE_MULT is 32. Some chip
manufacturers will provide the function of rewriting BOOT_SIZE_MULT to change the capacity of
Boot Area Partition. The maximum value of BOOT_SIZE_MULT can be 255, that is, the
maximum capacity of the Boot Area Partition can be 255 x 128 KB = 32640 KB = 31.875 MB.

Start from Boot Area

Boot State is defined in eMMC. After Power-up, HW reset or SW reset, if certain conditions are
met, eMMC will enter this State. The conditions for entering Boot State are as follows:
Original Boot Operation
If the CMD signal remains low for no less than 74 clock cycles, Original Boot Operation will be
triggered and the Boot State will be entered.

https://linux-codingbelief-com.translate.goog/zh/storage/flash_memory/emmc/emmc_partitions.html?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en&_… 2/10
11/9/23, 6:18 PM eMMC Partition Management · Linux Kernel Internals

Alternative Boot Operation

After 74 clock cycles, when the CMD signal is pulled low for the first time or before the Host
sends CMD1, when the Host sends COM0 with the parameter 0xFFFFFFFA, the Alternative
Boot Operation will be triggered and the Boot State will be entered.

In Boot State, if BOOT_ACK is configured, eMMC will first send a "010" ACK packet, and then
eMMC will send Boot Data of up to 128Kbytes x BOOT_SIZE_MULT to the Host. During the
transmission process, the Host can interrupt the eMMC data transmission by pulling up the CMD
signal (in Original Boot) or sending a Reset command (in Alternative Boot) to complete the Boot
Data transmission.
Boot Data can be read from Boot Area Partition 1, Boot Area Partition 2 or User Data Area
according to the setting of Bit[5:3]:BOOT_PARTITION_ENABLE of the PARTITION_CONFIG
Field of the Extended CSD register.
Boot Data stored in the Boot Area is more secure than in the User Data Area, which can
reduce the situation where accidental modifications cause the system to fail to start and the
system cannot be updated.

(For more details about Boot State, please refer to the Boot Mode chapter of eMMC Working
Mode )

write protect
By setting the BOOT_WP Field of the Extended CSD register, the write protection function can
be configured independently for the two Boot Area Partitions to prevent data from being
accidentally rewritten or erased.
Two boot area write protection modes are defined in eMMC:
1. Power-on write protection, after enabling it, if the eMMC is powered off, the write protection
function will be invalid and needs to be configured after each power on.
2. Permanent write protection, when enabled, will not become invalid even if the power is
turned off. It will become invalid only if it is actively shut down.

RPMB Partition
RPMB (Replay Protected Memory Block) Partition is a partition in eMMC with security features.
When eMMC writes data to RPMB, it will verify the legality of the data. Only the specified Host
can write. At the same time, when reading data, it also provides a signature mechanism to
https://linux-codingbelief-com.translate.goog/zh/storage/flash_memory/emmc/emmc_partitions.html?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en&_… 3/10
11/9/23, 6:18 PM eMMC Partition Management · Linux Kernel Internals

ensure that the data read by the Host is RPMB internal data. It is not data forged by the attacker.

In practical applications, RPMB is usually used to store some data that needs to be prevented
from illegal tampering, such as public keys and serial numbers related to fingerprint payment on
mobile phones. RPMB can authenticate writing operations, but reading does not require
authentication. Anyone can perform reading operations, so the data stored in RPMB is usually
encrypted before being stored.

Capacity
The size of the two RPMB Partitions is determined by the BOOT_SIZE_MULT Field of the
Extended CSD register. The size calculation formula is as follows:
Size = 128Kbytes x BOOT_SIZE_MULT
Generally, the size of Boot Area Partition is 4 MB, that is, RPMB_SIZE_MULT is 32. Some chip
manufacturers will provide the function of rewriting RPMB_SIZE_MULT to change the capacity of
RPMB Partition. The maximum value of RPMB_SIZE_MULT can be 128, that is, the maximum
capacity of the Boot Area Partition can be 128 x 128 KB = 16384 KB = 16 MB.

Replay Protect principle

When products using eMMC are produced on the production line, a unique 256-bit Secure Key
will be produced for each product and programmed into the OTP area of ​eMMC (an area that
can only be programmed once). At the same time, the Host is in the secure area ( For example:
TEE) will also retain the Secure Key.
Inside the eMMC, there is also a RPMB Write Counter. Every time RPMB performs a legal write
operation, the Write Counter will automatically increase by one.

Through the application of Secure Key and Write Counter, RMPB can realize Replay Protect of
data reading and writing.

RPMB data reading

The process of reading RPMB data is as follows:

1. The Host initiates a request to read the RPMB to the eMMC, and at the same time
generates a 16 bytes random number and sends it to the eMMC.
2. eMMC reads the requested data from RPMB and uses the Secure Key to calculate the
signature after concatenating the read data and the received random number using the
HMAC SHA-256 algorithm. Then, eMMC sends the read data, the received random number,
and the calculated signature to the Host.
3. After the Host receives the data, random number and signature of RPMB, it first compares
whether the random number is consistent with what it sent. If it is consistent, it then uses
https://linux-codingbelief-com.translate.goog/zh/storage/flash_memory/emmc/emmc_partitions.html?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en&_… 4/10
11/9/23, 6:18 PM eMMC Partition Management · Linux Kernel Internals

the same Secure Key to combine the data and random number through the HMAC SHA-256
algorithm to sign. If the signature is consistent with the signature sent by eMMC, then it can
be determined that the data is the correct data read from the RPMB and not data forged by
the attacker.

Through the above reading process, it can be ensured that the Host correctly reads the RPMB
data.

RPMB data writing

The process of writing RPMB data is as follows:

1. The Host reads the Write Counter of RPMB according to the above data reading process.
2. The Host splices the data to be written and the Write Counter together and calculates the
signature, and then sends the data, Write Counter and signature to the eMMC.
3. After eMMC receives the data, it first compares whether the Write Counter is the same as
the current value. If it is the same, it then signs the combination of the data and the Write
Counter, and then compares it with the signature sent by the Host. If the signatures are the
same, the authentication is passed. Data is written to RPMB.
Through the above writing process, it can be ensured that RPMB will not be illegally tampered
with.
For more details about RPMB, please refer to the eMMC RPMB chapter.

General Purpose Partitions

eMMC provides General Purpose Partitions (GPP), which are mainly used to store system and
application data. In many products using eMMC, GPP is not enabled because it is functionally
similar to UDA, and using UDA directly on the product can meet the needs.

Capacity
eMMC can support up to 4 GPPs, and the size of each GPP can be configured
individually. Users can set the capacity size of GPPx (x=1~4) by setting the following three fields
of the Extended CSD register:

GP_SIZE_MULT_x_2
GP_SIZE_MULT_x_1
GP_SIZE_MULT_x_0

https://linux-codingbelief-com.translate.goog/zh/storage/flash_memory/emmc/emmc_partitions.html?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en&_… 5/10
11/9/23, 6:18 PM eMMC Partition Management · Linux Kernel Internals

The capacity calculation formula of GPPx is as follows:

Size = (GP_SIZE_MULT_x_2 * 2^16 + GP_SIZE_MULT_x_1 * 2^8 + GP_SIZE_MULT_x_0 *

2^0) * (Write protect group size)
Write protect group size = 512KB * HC_ERASE_GRP_SIZE * HC_WP_GRP_SIZE

In eMMC, erasure and write protection are performed in blocks. HC_WP_GRP_SIZE in

the above expression is the block size of the write protection operation, and
HC_ERASE_GRP_SIZE is the block size of the erase operation.
The GPP configuration of the eMMC chip can usually only be performed once (OTP),
which is usually performed on the production line during the mass production stage of
the product.

Partition properties
In the eMMC standard, two types of attributes are defined for GPP, Enhanced attribute and
Extended attribute. Each GPP can set one of the two types of attributes, but cannot set multiple
attributes at the same time.

Enhanced attribute
Default, Enhanced attribute is not set.
Enhanced storage media, set GPP to Enhanced storage media.
In the eMMC standard, the impact on eMMC after setting the Enhanced attribute is not actually
defined. The specific role of Enhanced attribute is defined by the chip manufacturer.
In actual products, after setting Enhanced storage media, the storage medium of the partition is
usually changed from MLC to SLC to improve the read and write performance, lifespan, and
stability of the partition. Since the capacity of MLC is twice that of SLC under one storage unit,
when the total number of storage units is constant, if the partition originally used for MLC is
changed to SLC, the capacity of eMMC will be reduced. That is to say, at this time The actual
total capacity of eMMC will be smaller than the nominal total capacity. (For details of MLC and
SLC, please refer to the Flash Memory chapter)
Extended attribute
Default, the Extended attribute is not set.
System code, set GPP to the System code attribute. This attribute is mainly used to store
operating system classes and partitions that are rarely erased and updated.
Non-Persistent, set GPP to the Non-Persistent attribute. This attribute is mainly used for
partitions that store temporary data, such as the partition where the tmp directory is located,
the swap partition, etc.

https://linux-codingbelief-com.translate.goog/zh/storage/flash_memory/emmc/emmc_partitions.html?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en&_… 6/10
11/9/23, 6:18 PM eMMC Partition Management · Linux Kernel Internals

In the eMMC standard, the impact on eMMC after setting the Extended attribute is also not
defined. The specific role of the Extended attribute is defined by the chip manufacturer. The
Extended attribute is mainly related to the application scenarios of partitions. Manufacturers can
perform different optimizations for partitions that do not have application scenarios.

User Data Area

User Data Area (UDA) is usually the largest partition in eMMC and the most important storage
area in actual products.

Capacity
The capacity of UDA does not need to be set. After configuring other partition sizes and
deducting the capacity lost by setting the Enhanced attribute, the remaining capacity is the
capacity of UDA.

software partition
In order to manage data more reasonably and meet different application requirements, UDA will
perform software repartitioning in actual products. Currently, the mainstream software
partitioning technologies include MBR (Master Boot Record) and GPT (GUID Partition
Table). The basic principles of these two partitioning technologies are similar, as shown in the
following figure:

https://linux-codingbelief-com.translate.goog/zh/storage/flash_memory/emmc/emmc_partitions.html?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en&_… 7/10
11/9/23, 6:18 PM eMMC Partition Management · Linux Kernel Internals

Software partitioning technology generally divides storage media into multiple areas, namely SW
Partitions, and then maintains these SW Partitions through a Partition Table. In the Partition
Table, each entry stores attribute information such as the starting address and size of a SW
Partition. After the software system is started, it will scan the Partition Table to obtain the
information of each SW Partitions on the storage medium, and then load each Partitions into the
system based on this information for data access.
MBR and GPT will not be introduced in detail here. For more details, please refer to the
introduction of MBR and GPT on Wikipedia .

Area properties
In the eMMC standard, it is supported to set the Enhanced attribute for a specific size area in the
UDA. Like the Enhanced attribute in GPP, the eMMC standard does not define the impact on
eMMC after setting the Enhanced attribute in this region. The specific role of Enhanced attribute
is defined by the chip manufacturer.
Enhanced attribute
Default, Enhanced attribute is not set.
Enhanced storage media, set this area to Enhanced storage media.
In actual products, after the UDA area is set to Enhanced storage media, the storage medium in
this area is usually changed from MLC to SLC. Usually, a certain SW Partition in the product can
be set as Enhanced storage media to obtain better performance and robustness.

https://linux-codingbelief-com.translate.goog/zh/storage/flash_memory/emmc/emmc_partitions.html?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en&_… 8/10
11/9/23, 6:18 PM eMMC Partition Management · Linux Kernel Internals

eMMC partition application example

In an Android mobile phone system, each partition is presented as follows:
mmcblk0 is the eMMC block device;
mmcblk0boot0 and mmcblk0boot1 correspond to two Boot Area Partitions;
mmcblk0rpmb is RPMB Partition,
mmcblk0px is the SW Partitions divided by UDA;
If GPP exists, the names are mmcblk0gp1, mmcblk0gp2, mmcblk0gp3, mmcblk0gp4;

root@xxx:/ # ls /dev/block/mmcblk0*
/dev/block/mmcblk0
/dev/block/mmcblk0boot0
/dev/block/mmcblk0boot1
/dev/block/mmcblk0rpmb
/dev/block/mmcblk0p1
/dev/block/mmcblk0p2
/dev/block/mmcblk0p3
/dev/block/mmcblk0p4
/dev/block/mmcblk0p5
/dev/block/mmcblk0p6
/dev/block/mmcblk0p7
/dev/block/mmcblk0p8
/dev/block/mmcblk0p9
/dev/block/mmcblk0p10
/dev/block/mmcblk0p11
/dev/block/mmcblk0p12
/dev/block/mmcblk0p13
/dev/block/mmcblk0p14
/dev/block/mmcblk0p15
/dev/block/mmcblk0p16
/dev/block/mmcblk0p17
/dev/block/mmcblk0p18
/dev/block/mmcblk0p19
/dev/block/mmcblk0p20
/dev/block/mmcblk0p21
/dev/block/mmcblk0p22
/dev/block/mmcblk0p23
/dev/block/mmcblk0p24
/dev/block/mmcblk0p25
/dev/block/mmcblk0p26
/dev/block/mmcblk0p27
/dev/block/mmcblk0p28
/dev/block/mmcblk0p29
/dev/block/mmcblk0p30
/dev/block/mmcblk0p31
/dev/block/mmcblk0p32

Each partition will be named according to its actual function.

https://linux-codingbelief-com.translate.goog/zh/storage/flash_memory/emmc/emmc_partitions.html?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en&_… 9/10
11/9/23, 6:18 PM eMMC Partition Management · Linux Kernel Internals

root@xxx:/ # ls -l /dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/
lrwxrwxrwx root root 2015-01-03 04:03 boot -> /dev/block/mmcblk0p22
lrwxrwxrwx root root 2015-01-03 04:03 cache -> /dev/block/mmcblk0p30
lrwxrwxrwx root root 2015-01-03 04:03 custom -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 2015-01-03 04:03 devinfo -> /dev/block/mmcblk0p28
lrwxrwxrwx root root 2015-01-03 04:03 expdb -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 2015-01-03 04:03 flashinfo -> /dev/block/mmcblk0p32
lrwxrwxrwx root root 2015-01-03 04:03 frp -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2015-01-03 04:03 keystore -> /dev/block/mmcblk0p27
lrwxrwxrwx root root 2015-01-03 04:03 lk -> /dev/block/mmcblk0p20
lrwxrwxrwx root root 2015-01-03 04:03 lk2 -> /dev/block/mmcblk0p21
lrwxrwxrwx root root 2015-01-03 04:03 logo -> /dev/block/mmcblk0p23
lrwxrwxrwx root root 2015-01-03 04:03 md1arm7 -> /dev/block/mmcblk0p17
lrwxrwxrwx root root 2015-01-03 04:03 md1dsp -> /dev/block/mmcblk0p16
lrwxrwxrwx root root 2015-01-03 04:03 md1img -> /dev/block/mmcblk0p15
lrwxrwxrwx root root 2015-01-03 04:03 md3img -> /dev/block/mmcblk0p18
lrwxrwxrwx root root 2015-01-03 04:03 metadata -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 2015-01-03 04:03 nvdata -> /dev/block/mmcblk0p7
lrwxrwxrwx root root 2015-01-03 04:03 nvram -> /dev/block/mmcblk0p19
lrwxrwxrwx root root 2015-01-03 04:03 oemkeystore -> /dev/block/mmcblk0p12
lrwxrwxrwx root root 2015-01-03 04:03 para -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 2015-01-03 04:03 ppl -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 2015-01-03 04:03 proinfo -> /dev/block/mmcblk0p13
lrwxrwxrwx root root 2015-01-03 04:03 protect1 -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 2015-01-03 04:03 protect2 -> /dev/block/mmcblk0p10
lrwxrwxrwx root root 2015-01-03 04:03 recovery -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 2015-01-03 04:03 rstinfo -> /dev/block/mmcblk0p14
lrwxrwxrwx root root 2015-01-03 04:03 seccfg -> /dev/block/mmcblk0p11
lrwxrwxrwx root root 2015-01-03 04:03 secro -> /dev/block/mmcblk0p26
lrwxrwxrwx root root 2015-01-03 04:03 system -> /dev/block/mmcblk0p29
lrwxrwxrwx root root 2015-01-03 04:03 tee1 -> /dev/block/mmcblk0p24
lrwxrwxrwx root root 2015-01-03 04:03 tee2 -> /dev/block/mmcblk0p25
lrwxrwxrwx root root 2015-01-03 04:03 userdata -> /dev/block/mmcblk0p31

https://linux-codingbelief-com.translate.goog/zh/storage/flash_memory/emmc/emmc_partitions.html?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en&… 10/10