Embedded MultiMediaCard, usually referred to as eMMC or e.MMC, is a solid-state storage standard derived from the MMC standard. Formerly maintained by the MMC Association (MMCA), it is now the responsibility of JEDEC. The standard may have extensions, such as the e.MMC Security Extension.
In a short summary, an eMMC device is a raw NAND chip with an integrated controller that abstracts concepts such as wear levelling and ECC. For more information about flash technologies, check our additional resources:
The eMMC is an evolving standard. As of January 2019, JEDEC published the document JESD84-B51A: Embedded MultiMediaCard (e.MMC), Electrical Standard (5.1A), a.k.a eMMC 5.1A.
This article goes through:
You need a module with eMMC. A summary table of eMMC-based modules is provided below:
|Family||Modules||eMMC Capacity (GB)||Technology|
|Apalis||TK1 2GB||16||8-bit MLC|
|Apalis||iMX6Q 2GB IT
iMX6D 1GB IT
T30 1GB IT
|Apalis||T30 2GB||8||8-bit MLC|
|Colibri||iMX8QX 2GB IT
|Colibri||iMX7D 1GB||4||8-bit MLC|
iMX6S 256MB IT
iMX6DL 512MB IT
T30 1GB IT
The eMMC standard provides an interface in which the device is seen and treated as a block device by Linux. As an implication, any file system used in HDDs and SSDs can be employed on eMMC devices. On the other hand, eMMC is widely different from those and its peculiarities must be taken into consideration when choosing and configuring the file system.
As of the embedded Linux BSP 2.7b4, Toradex switched from using ext3 to ext4 by default, therefore ext4 is the current file system adopted in our BSP.
The eMMC device has a boot area, which is seen as a different block device than the regular user area. It is a vendor specific area that uses an underlying storage technology more reliable than the user area, for instance SLC or pSLC instead of MLC.
The default partitioning scheme of an eMMC-based Toradex module is as follows:
eMMC boot area:
eMMC user area:
Note: Following information is from a Colibri iMX6S 256MB IT V1.1A with embedded Linux BSP 2.8b5.
You can use the command
fdisk to see the partitioning scheme:
root@colibri-imx6:~# fdisk -lDisk /dev/mmcblk0: 3850 MB, 3850371072 bytes4 heads, 16 sectors/track, 117504 cylindersUnits = cylinders of 64 * 512 = 32768 bytesDevice Boot Start End Blocks Id System/dev/mmcblk0p1 129 640 16384 c Win95 FAT32 (LBA)/dev/mmcblk0p2 641 117504 3739648 83 LinuxDisk /dev/mmcblk0boot1: 16 MB, 16777216 bytes4 heads, 16 sectors/track, 512 cylindersUnits = cylinders of 64 * 512 = 32768 bytesDisk /dev/mmcblk0boot1 doesn't contain a valid partition tableDisk /dev/mmcblk0boot0: 16 MB, 16777216 bytes4 heads, 16 sectors/track, 512 cylindersUnits = cylinders of 64 * 512 = 32768 bytesDisk /dev/mmcblk0boot0 doesn't contain a valid partition table
From the above output, notice that boot area does not have a partition table. In addition, the user area size is
3850371072 bytes, being
16777216 bytes for the kernel and device tree partition and
3829399552 bytes for the root file system. Alternatively, one could get the block devices and partition sizes using the command
root@colibri-imx6:~# lsblk -b /dev/mmcblk0NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTmmcblk0 179:0 0 3850371072 0 disk├─mmcblk0p1 179:1 0 16777216 0 part /media/mmcblk0p1└─mmcblk0p2 179:2 0 3829399552 0 part /root@colibri-imx6:~# lsblk -b /dev/mmcblk0boot0NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTmmcblk0boot0 179:8 0 16777216 1 diskroot@colibri-imx6:~# lsblk -b /dev/mmcblk0boot1NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTmmcblk0boot1 179:16 0 16777216 1 disk
Using the command
df, you'll notice that the size reported by the file systems is slightly smaller than the user area partitions:
root@colibri-imx6:~# dfFilesystem 1K-blocks Used Available Use% Mounted on/dev/root 3615352 488560 2923428 14% /devtmpfs 58644 4 58640 0% /devtmpfs 124692 0 124692 0% /dev/shmtmpfs 124692 396 124296 0% /runtmpfs 124692 0 124692 0% /sys/fs/cgrouptmpfs 124692 4 124688 0% /tmptmpfs 124692 0 124692 0% /var/volatile/dev/mmcblk0p1 16116 5179 10937 32% /media/mmcblk0p1tmpfs 24936 0 24936 0% /run/user/0
From the command above the total size of the kernel and device tree partition is
16502784 bytes and the root file system is
3702120448 bytes. This reports the actual usable space for each partition and happens due to file system overhead - things such as the inode table and file system journal.
There is a specific article for this topic:
Even though discouraged, it is possible to copy the eMMC contents for backup or replication purposes. There is a specific article for this topic:
The Linux kernel provides a tool chest for configuring MMC devices from user space named mmc-utils. A downstream version from Chromium OS is integrated out-of-the-box in the Toradex BSPs.
If you want to use the upstream version, it can be easily built using OpenEmbedded. Both variants (upstream and downstream) can be built and installed concurrently in the same image, due to update-alternatives support.
Mmc-utils makes it possible to query information from the device as well as configure features. Some examples are health status, enhanced user area, write reliability, sanitize, cache and write protection. Use the command help to list all available features:
Flash manufacturers may provide their own eMMC tools. For instance Micron releases the emmcparm tool periodically. It can be obtained from the Micron website, though you must register and request access to it. Once you have it deployed to the module, set the execute flag of the binary and run it without parameters to display the help:
Note: For a better understanding of emmcparm, browse Micron's website for the technical note TN-FC-25 - Understanding Linux Driver Support for e.MMC
The following sections go through some of the available commands of mmc-utils and emmcparm.
Health status can be generic - as defined in the eMMC standard - or vendor specific. It is related to the concepts of raw NAND flash technology, such as SLC vs. MLC, eraseblock count, spare eraseblocks and erase cycles.
In a short summary, from the health perspective, the eMMC can be seen as an array of physical blocks - so-called eraseblocks - that have an average lifetime. The lifetime is measured by the amount of erase operations to a single block - the eraseblock count - and for MLC NAND technology it varies from 3000 to 10000 cycles depending on the trace width in nanometers.
A raw lifetime estimation could be stated as
size of block *
number of blocks *
number of erase operations before eraseblock wears out. For instance, theoretically an eMMC with 1024 blocks - each having 4MiB and 3000 erases per block - can store up to
12000GiB or 12TiB. Notice that this is an inaccurate estimation due to the various caching mechanisms of Linux as well as the practical aspects of NAND operation, which for instance contribute to write amplification.
Note: You may find more information about flash memory in the extra material pointed to in this article's introduction.
Since e.MMC 5.0, device health status became part of the standard. It provides life time estimation for SLC and MLC areas as well as pre EOL status:
Warning: Depending on the computer on module and its version, the eMMC standard may be prior to 5.0 and thus not have the generic life time estimation available.
First, check the eMMC standard version:
Then you can get the health status from the Extended CSD register (ECSD), which can be parsed by the command
mmc extcsd read <device>, for instance:
Vendor-specific health status may be available in eMMC devices. The best way to understand what is available is to go through the vendor documentation, since they may provide instructions or utilities for retrieving the information from the device.
Note: Even eMMCs compliant to standards prior to eMMC 5.0 may have vendor specific health status information.
Micron is an eMMC manufacturer that provides specific information about the health status of some of its parts. Below is a list of Toradex modules equipped with Micron eMMCs that both comply to the eMMC 5.0 standard and have additional vendor-specific health information:
|Computer on Module||Version|
|Apalis iMX6Q 2GB IT||V1.1C|
|Apalis iMX6Q 1GB||V1.1B|
|Apalis iMX6D 1GB IT||V1.1B|
|Apalis iMX6D 512MB||V1.1B|
|Apalis T30 1GB||V1.1B|
|Apalis T30 1GB IT||V1.1B|
|Colibri iMX7D 1GB||V1.1A|
|Colibri iMX6S 256MB||V1.1A|
|Colibri iMX6S 256 MB IT||V1.1A|
|Colibri iMX6D 512MB||V1.1A|
|Colibri iMX6D 512MB IT||V1.1A|
Note: For a better understanding of this section, browse Micron's website for the technical note TN-FC-32 - e.MMC Device Health Report
There are two possibilities for retrieving the vendor-specific data:
Below we illustrate the output of some emmcparm commands related to flash health.
Enhanced User Area, also referred to as enhanced storage is a mode defined in the eMMC 4.4 (MMCA 4.4) standard onwards in which the user area of the eMMC can be configured, which is meant to make that area more reliable and present better performance. How manufacturers do implement the Enhanced User Area is not defined in the standard, though. If the device supports this configuration, then the boot and RPMB area partitions must be configured as enhanced storage by default.
Note: As of the beginning of 2019, almost all eMMCs in production support Enhanced User Area, thus they have boot and RPMB partitions with this configuration enabled by default.
Pseudo SLC, also known as pSLC, is a configuration of the MLC NAND flash memory that uses half of the cells capacity - that is, instead of 2 bits per cell, uses 1 bit per cell - to improve the reliability, performance and endurance of the eMMC. In practice, the pSLC mode is in-between SLC and MLC.
A few remarks about enhanced mode are presented below:
Attention: Some of the commands from this section are one-time only operations. That means they cannot be reverted. Think carefully before executing any of them.
U-Boot has mmc commands, including the capability of hardware partitioning. This is what we need to configure the eMMC (or part of it) as enhanced storage. This section goes through how to do it:
Note: Following information is from a Colibri iMX6S 256MB IT V1.0B with embedded Linux BSP 2.8b5.
First of all, get the information about the size of the user area partition:
In the example above it is round to 3.7GiB and has write reliability switched on. The
mmc hwpartition command can be used to get partition information as well as set enhanced storage. We can see the current configuration:
Let's try to switch the whole partition to Enhanced User Area mode. We'll pass an option
check that does not execute the operation right away, it only tests it and outputs the outcome as if we had actually done it. The size needs to be specified in 512 byte blocks and the area must be HC WP group size aligned:
It fails, informing the maximum size allowed in "HC WP group size", that is 472 * 4MiB = 1888MiB. Thus we need this value in 512 KiB blocks, which is 1888 * 1024 * 1024 / 512 = 3866624. Once you are sure about the value to use as well as the offset, use the
complete option. We'll do it for the whole user are in the example below:
Note: The following command also configures write reliability as on, which is usually desired. Read the Reliable Write section before proceeding.
Once you power-cycle, the changes take effect:
Note: Following information is from a Colibri T30 IT V1.1A.
The Enhanced User Area is expected to be faster, if we assume that it is implemented as a pSLC area.
Check eMMC capacity before configuration:
Then configure the eMMC as enhanced storage:
Check eMMC capacity after configuration:
It is exactly 50%, an indicator that it is in pSLC mode. Now we can compare the results of bonnie++ and dd to check write performance:
Write reliability is a configuration that affects what happens to data during an unexpected power-cut. When it is enabled, write operations are atomic at the eMMC level and after an unexpected power-cut data is either old or new, but never undefined. To check if it's on by default you can use the U-Boot
mmc info command:
From the command above, notice on the line
User Capacity: 3.7 GiB WRREL that the WRREL means write reliability is on. If you want to change such configuration, refer to the section Configure eMMC Enhanced User Area.
Note: For a better understanding of reliable write on Micron eMMC devices, browse Micron's website for the technical note TN-FC-27 - e.MMC Power Loss Data Integrity
Notice that Micron eMMCs have reliable write and partition protection features, which they claim to have the same level of protection.
Note: Following information is from a Colibri iMX6S 256MB IT V1.1A with embedded Linux BSP 2.8b5.
For Micron eMMCs, TN-FC-27 has a plot of sequential write performance against chunk size, comparing the results for enabled and disabled partition protection. As expected, when protection is enabled the performance is worse. The chunk size range in which it is worst is between 32KB and 256KB. In addition, the same document states in its conclusion that "a sequential write with partition protection enabled has much better performance than a sequential reliable write".
Write reliability enabled (default):
Write reliability disabled: