Sunxi-mmc 1c11000.mmc: error

Banana Pi SBCs design BPI-M2 Ultra / BPI-M2 Berry(A40i)
1

Hi,

I own a BPI M2 Ultra board running debina buster on Armbian on SD card, but while trying to boot form eMMC i always receive the folowing errors that stops the board

sunxi-mmc 1c11000.mmc: data error, sending stop command sunxi-mmc 1c11000.mmc: send stop command failed

I already disabled the mmc2 (1c11000) on dtb file, and now the board boots and works perfect from SD, but of course, i don’t wan to losse eMMC flash memory

Is it hardware failure? is there any way to fix it? i saw on olimex forum, that the manufacturer answered a similar question telling the customer that the problem was a capacitor that they soldered for eMMC 5.0 performance. “The capacitor that was over U10’s pads was needed at some point, it was soldered on purpose as a hardware fix that improved boot reliability when using 5.0 eMMC. It adds delay to EMMC_CLK that improved. It is 15pF in 0603 package (we used 50V one but the voltage shouldn’t matter as long as it is 15pF in 0603). This fix doesn’t work for newest 5.1 eMMC memories, however. If you need more details please contact me over [email protected]”

Nevertheles the board boots form eMMC original BPI image (legacy kernel), so, i’m not sure about the hardware problem.

Any help will be appreciated.

Regards,

Mauricio F.

2

Isn’t a hardware problem but i face the same problem with a SINA33 board using the mainline kernel. Without the capacitor the eMMC give errors but, with the capacitor works!! I added a capacitor 10pF between the CPU EMMC_CLK output and the resistor that is in series with the eMMC CLKM pin. That worked only for the 5.0 eMMC. I give the same try with eMMC version 4.41 and didn’t worked. With the provided firmware the eMMC works without any change, the problem only was presented on the mainline kernel. I haven’t find any solution or the reason why this happening.

3

hello, did you use the debian image from google drive, seem I have same issue for boot from emmc, but my boot screen always stuck on waiting the mmblk0(sd card) device to mount, but I was plug out, I don’t know if same way can change the bootboader…

4

@sinovoip seem we have some issue with debian buster image, do you have idea for this kinds of issue?

5

I haven’t find any solution to that problem yet. The problem is present mostly on the Micron eMMC chips. It has to do with the clock phase .output .sample inside the sunxi-mmc.c driver on the sunxi_mmc_clk_delays structure.

6

Late reply, but in case someone lands here with the same error on a BPI-M2 Ultra:

sunxi-mmc 1c11000.mmc: data error, sending stop command
sunxi-mmc 1c11000.mmc: send stop command failed

On my M2U (mainline kernels 6.6 and 6.16, LibreELEC; eMMC Samsung 8WPD3R, eMMC 5.0) this was fixed purely in software by limiting the eMMC clock. The mainline device tree has no max-frequency on the eMMC node, so it runs 8-bit DDR52 at 50 MHz. With max-frequency = <40000000> (the driver sets 37.5 MHz), and 8-bit DDR still on:

  • 50 MHz: fails within 0.5 s, reproducibly
  • 37.5 MHz: 0 errors in a 33 min read/write/verify soak, and the OS now boots and runs from eMMC
  • 25 MHz: also passes
  • Read ~61 MB/s, write ~25 MB/s

This fits the clock-timing suspicion earlier in the thread. Lowering the clock gives the signal more timing margin, much like the capacitor on EMMC_CLK, but without touching the board.

To apply it to a dtb:

fdtput -t u sun8i-r40-bananapi-m2-ultra.dtb /soc/mmc@1c11000 max-frequency 40000000

or as an overlay (what I use, so it survives OS updates that replace the dtb):

/dts-v1/;
/plugin/;
/ {
	compatible = "allwinner,sun8i-r40";
	fragment@0 {
		target-path = "/soc/mmc@1c11000";
		__overlay__ { max-frequency = <40000000>; };
	};
};

Afterwards, cat /sys/kernel/debug/mmcN/ios should show actual clock: 37500000 Hz with timing spec: 8 (mmc DDR52). Other eMMC chips may need a lower value (25 MHz).

Separate issue, in case you use LibreELEC 12.2.x on this board: its U-Boot 2025.07 hangs after “Trying to boot from MMC1”. The cause and a fix are in thread 29908 on forum.libreelec.tv.