AnsweredAssumed Answered

i.MX6: Accessing boot/user partitions on eMMC

Question asked by Marc-Oliver Westerburg on Jan 23, 2015
Latest reply on Jul 5, 2016 by Ning Li

Hi all



We just noticed a weird effect on our i.MX6-based designs when accessing the eMMC boot/user partitions from Linux. We're using i.MX6 Solo, Dual and Quad SoCs on the boards with different types of Micron eMMCs (MTFC4GLVEA-0M WT conforming to (e)MMC standard v4.41 and MTFC4GACAAAM-1M WT conforming to (e)MMC v4.51) and use all of the three eMMC partitions for different purposes:

  • /dev/mmcblk0boot0 is used "raw" just for the boot-loader without any filesystem. Access from Linux is done only via "dd"-command to update the boot-loader and this partition is used to boot the whole system, which works fine.
  • /dev/mmcblk0boot1 is formatted directly with a FAT-filesystem to store various system configuration files to.
  • /dev/mmcblk0 is further partitioned (via standard "fdisk") and contains multiple filesystems.

As you may know, read/write-commands sent to the eMMC do not address directly any of these partitions, but instead the driver sends special "CMD6 (SWITCH) commands to set the PARTITION_ACCESS bits in the EXT_CSD register, byte [179]" [JEDEC Standard No. 84-A441 p.40) to switch the partition currently "visible" to read, write, and other commands. It seems, that this partition switching is not working reliably.


In command sequences that access both boot- and the user-partition in Linux kernels v3.0.35 and 3.10.17 (current releases from Freescale for the i.MX6SoCs) occasionally wrong partitions seem to get addressed, instead, or rather: occasionally CMD6-commands sometimes don't seem to get sent to the eMMC and therefore data is read/written from wrong partitions. This seems to be timing-related: Using the GLVEA-eMMC, which seems to have shorter partition switching times, we can see this problem only occasionally during read-accesses to different partitions, with the ACAAAM-eMMC on i.MX6Dual/Quad-systems we sometimes see this problem even during write-accesses (which then of course will corrupt data on the eMMC, as e.g. the boot-loader is not written to /dev/mmcblk0boot0 but instead to /dev/mmcblk0).


Adding extra delays in the mmc_switch()-function (in mmc_ops.c) improves the issue considerably, but doesn't fully solve it. Adding debugging messages to the mmc_switch()-function and to esdhc_writel_le() in sdhci-esdhc-imx.c and logging all CMD6-commands actually sent to the eMMC, shows that the Linux kernel for some reason sends wildly different numbers of switch-commands to the eMMC each time: for the same sequence of commands accessing all three boot- and user-partitions executed each time immediately after booting up the system sometimes shows just 7 or 8 CMD6 commands, sometimes more than 30 being sent by the driver, but this doesn't seem to correlate to the problem occurring or not. The sequence of CMD6-commands also seems to make sense in all cases.


We haven't noticed any other problems with the eMMC, so far, though. Except from the fact that occasionally CMD6-commands seem to get lost, everything seems to work perfectly stable.


Anybody else noticed similar problems or any clues, what might be going on?