Boot failures related to errors occuring on eMMC access

We’ve seen a few recent occurrences where our product stopped booting properly. The product uses Colibri iMX6S 256MB IT V1.1A modules on a custom carrier board, running a customized BSP 3.0.4 image. The examples we’ve seen seem to show evidence of corrupted eMMC partitions . It’s unclear how the partitions were corrupted. The module still has a working uboot but the Linux boot will fail as it access other MMC partitions. The kernel boot log shows an error is occurring on mmc access. Comparing the failed modules boot logging with a working (same configuration part), it appears this error is occurring when the VFS file system was accessed. This is the failed units log, note the extended delay time.

[ 2.878024] EXT4-fs (mmcblk0p2): mounting ext3 file system using the ext4 subsystem
[ 2.886503] EXT4-fs (mmcblk0p2): INFO: recovery required on readonly filesystem
[ 2.893882] EXT4-fs (mmcblk0p2): write access will be enabled during recovery
[ 2.926598] EXT4-fs (mmcblk0p2): recovery complete
[ 8.355241] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x400e00

I have been able to restore the product to proper operation by using the uboot tftp loading sequence to restore the eMMC contents. The post ‘eMMC corruption? - #26 by patdex’ seems to be a similar issue. That post mentioned trying BSP 5.1, which I have not tried. Is there any update on if an issue exists?

The following snippet is part of the boot message from the module after reloading it seems to show the above failure seems to be when accessing the VFS.

[ 2.883295] EXT4-fs (mmcblk0p2): mounting ext3 file system using the ext4 subsystem
[ 2.896100] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[ 2.904353] VFS: Mounted root (ext3 filesystem) readonly on device 179:2.
[ 2.915026] devtmpfs: mounted

This is a snippet from a product that has not seen the issue, also showing it occurred about the time the VFS is accessed. Note the usb traffic differences are likely because we have optional equipment that can be plugged into usb ports, and this device has two USB modules installed.
[ 2.857415] EXT4-fs (mmcblk0p2): mounting ext3 file system using the ext4 subsystem
[ 2.865181] usb 1-1.4: new full-speed USB device number 4 using ci_hdrc
[ 2.872662] EXT4-fs (mmcblk0p2): INFO: recovery required on readonly filesystem
[ 2.880061] EXT4-fs (mmcblk0p2): write access will be enabled during recovery
[ 3.018294] hid-generic 0003:C251:2601.0001: hiddev96,hidraw0: USB HID v1.00 Device [Infinisource Card Interface] on usb-ci_hdrc.0-1.4/input0
[ 3.032307] sdhci-esdhc-imx 2190000.usdhc: Got CD GPIO
[ 3.318971] EXT4-fs (mmcblk0p2): recovery complete
[ 3.325047] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[ 3.333229] VFS: Mounted root (ext3 filesystem) readonly on device 179:2.

Hi @dwooldridge , thanks for reaching out. I’ve just remembered this issue happening but with SD cards, not the eMMC but it was solved by disabling the ADMA in favour of SDMA.

I’m not absolute sure of the command for your case but by then it was solved with:

setenv defargs $defargs sdhci.debug_quirks=0x65144040

The default shdci.debug_quirks was 0x65144000 but by changing the 0x40, you disable ADMA in favour of SDMA. This helped with the error -110 in the past.

Sorry but can you try this? (I don’t have the module in front of me so I’m not sure about the default defargs and if there is another debug_quirks for the eMMC, but this should help).

Kindly let us know how it goes.

Kind regards,
Alvaro.