i.MX6: Accessing boot/user partitions on eMMC

[MOW]

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?

Regards,

Marc

[gusarambula]

Unfortunately the i.MX6 Processors supports eMMC 4.4/4.41. Would you please confirm if these issues are present on the eMMX 4.51 chip? As if this is the case it could be related to the slight differences on the eMMC standard.

[MOW]

At least for the Linux v3.0.35 kernel the issue occuring during write-accesses seems to be caused by accesses to the SYSFS "boot_config" DEVATTR, which Freescale has added to the MMC driver.

If we constantly just write to /dev/mmcblk0boot0, /dev/mmcblk0boot1, and /dev/mmcblk0 in sequence and afterwards verify the contents of each partition, everything seems to work fine.

If we write to /sys/devices/platform/sdhci-esdhc-imx.3/mmc_host/mmc0/mmc0:0001/boot_config in between, even if we add "sync"-calls -- as initialization and update scripts we use in-house and provide to our customers must do to ensure that the system will boot from the proper partition -- the problem occurs.

[MOW · Accepted solution]

Problem solved:

In contrast to my original post the problem does not seem to exist with kernel v3.10.17. The issue could be resolved to a bug in the function setup_boot_partitions() (in drivers/mmc/core/mmc.c), which in the v3.0.35-kernel also modified the currently active eMMC-partition used by the OS without synchronizing this switch with the automatic switching mechanism in the MMC-stack when accessing different eMMC-partitions via their respective block-devices.

Kernel v3.10.17 of this function seems explicitly ensure that eMMC-partition currently used by the OS is not modified. Porting this code back to v3.0.35 seems to solve the issue. We can't reproduce the problem anymore with either eMMC 4.41 or eMMC 4.51 chips.

[Chiranjeevi]

Hi, 

I'm working on Imx8qm 5.15.5 kernel version. my question is will this version/board supports for CMD6(SWITCH) in order to switch between user area and general purpose partitions?

if yes, what is the command to see this effect with mmc utils.

or Pls suggest me if any alternate way to do it.

Many thanks in advance.

[ningli]

Hi Marc-Oliver，

     i have the same problem。I see your fixed method, and download kernel files from kernle.org. But i don't find the function setup_boot_partitins(). can you show me the code of kernel v3.10.17 mmc.c . My email is ramon20082001@163.com.

                   thanks!

[MOW]

For read-accesses we can occasionally reproduce the problem on both eMMC 4.41 and eMMC 4.51 chips, for write-accesses we have seen the issue only with eMMC 4.51 chips, so far.

Seems to be some kind of timing issue: if I add debugging messages to esdhc_writel_le() in sdhci-esdhci-imx.c to log all commands sent to the eMMC (not just CMD6, as in my original messages), the problem seems to disappear.