[PATCH 0/2] mci: fix read timeouts following SD card writes

[PATCH 0/2] mci: fix read timeouts following SD card writes

[Sascha Hauer]

On a KSZ9477-EVB (SAMA5D3), saveenv fails on the first attempt after
the SD card has been freshly flashed, and larger raw writes to the
card fail as well:

  ERROR: atmel_mci f0000000.mmc@f0000000.of: command/data timeout
  ERROR: atmel_mci f0000000.mmc@f0000000.of: command/data timeout

The card is still programming a previous write when the next read
command arrives, and does not answer it. barebox already waits for
the card to become ready before writes, but reads can still hit it
while it is busy.

The first patch makes the atmel_mci timeout message say which command
failed and how, which is what pointed to the cause. The second patch
waits for the card to become ready after each block write.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
Sascha Hauer (2):
      mci: atmel_mci: improve timeout error message
      mci: wait for card to leave programming state after block writes

 drivers/mci/atmel_mci_common.c |  4 +++-
 drivers/mci/mci-core.c         | 11 ++++++++++-
 2 files changed, 13 insertions(+), 2 deletions(-)
---
base-commit: 6b2dee07d7189bcec749539574ff99580880e238
change-id: 20261019-atmel-mci-fixes-994fa7c17ffe

Best regards,
-- 
Sascha Hauer <s.hauer@pengutronix.de>

[PATCH 1/2] mci: atmel_mci: improve timeout error message

[Sascha Hauer]

On a command timeout, the driver only prints "command/data timeout",
which says neither which command failed nor whether the card did not
respond at all (RTOE) or the data phase timed out (DTOE).

Print the command index, the kind of timeout and the raw status
register instead, e.g.:

  ERROR: atmel_mci f0000000.mmc@f0000000.of: CMD18: response timeout (SR=0x04100005)

This made it possible to see that it was a read command that the card
did not answer while it was still programming a previous write.

Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 drivers/mci/atmel_mci_common.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mci/atmel_mci_common.c b/drivers/mci/atmel_mci_common.c
index 170c021eba..3a081b8b63 100644
--- a/drivers/mci/atmel_mci_common.c
+++ b/drivers/mci/atmel_mci_common.c
@@ -243,7 +243,9 @@ static int atmci_read_response(struct atmel_mci *host, unsigned int stat)
 	resp = (u32 *)cmd->response;
 
 	if (stat & (ATMCI_RTOE | ATMCI_DTOE)) {
-		dev_err(host->hw_dev, "command/data timeout\n");
+		dev_err(host->hw_dev, "CMD%u: %s timeout (SR=0x%08x)\n",
+			cmd->cmdidx, stat & ATMCI_RTOE ? "response" : "data",
+			stat);
 		return -ETIMEDOUT;
 	} else if ((stat & ATMCI_RCRCE) && (cmd->resp_type & MMC_RSP_CRC)) {
 		dev_err(host->hw_dev, "cmd crc error\n");

-- 
2.47.3

[PATCH 2/2] mci: wait for card to leave programming state after block writes

[Sascha Hauer]

Commit d8c3bab30542 ("mci: only write blocks when card out of programming
mode") polls the card status before a block write, so that CMD24/25 is
not sent while the card is still programming the previous write. Reads
are not covered: a read following a write can still find the card in
prg state. CMD17/18 are illegal there and the card does not answer
them, so the host sees a response timeout.

On a KSZ9477-EVB (SAMA5D3) with a freshly flashed SD card, the first
saveenv fails with:

  ERROR: atmel_mci f0000000.mmc@f0000000.of: command/data timeout
  ERROR: atmel_mci f0000000.mmc@f0000000.of: command/data timeout

With more verbose error reporting, the failing commands turn out to be
a multi-block read and the stop command sent after it:

  CMD18: response timeout (SR=0x04100005)
  CMD12: response timeout (SR=0x04100005)

The same happens without any filesystem involved when writing larger
amounts of data to the raw device:

  memcpy -s /dev/ram0 -d /dev/mmc0.root-A 0 0 2M

Also poll the card status after each block write, like U-Boot does, so
that any command following a write finds the card back in transfer
state.

Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 drivers/mci/mci-core.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/mci/mci-core.c b/drivers/mci/mci-core.c
index 874ee40cb3..1954de8053 100644
--- a/drivers/mci/mci-core.c
+++ b/drivers/mci/mci-core.c
@@ -266,7 +266,7 @@ static int mci_block_write(struct mci *mci, const void *src, int blocknum,
 {
 	struct mci_cmd cmd = {};
 	unsigned mmccmd;
-	int ret;
+	int ret, err;
 
 	/*
 	 * Quoting eMMC Spec v5.1 (JEDEC Standard No. 84-B51):
@@ -304,6 +304,15 @@ static int mci_block_write(struct mci *mci, const void *src, int blocknum,
 		mci_send_cmd(mci, &cmd);
         }
 
+	/*
+	 * The card stays in prg state for a while after the write. Polling
+	 * before the next write is not enough: a read sent in prg state is
+	 * an illegal command, which the card does not answer at all.
+	 */
+	err = mci_poll_until_ready(mci, 1000 /* ms */);
+	if (!ret && err != -ENOSYS)
+		ret = err;
+
 	return ret;
 }
 

-- 
2.47.3

Re: [PATCH 0/2] mci: fix read timeouts following SD card writes

[Sascha Hauer]

On Mon, 19 Oct 2026 11:52:42 +0200, Sascha Hauer wrote:
> On a KSZ9477-EVB (SAMA5D3), saveenv fails on the first attempt after
> the SD card has been freshly flashed, and larger raw writes to the
> card fail as well:
> 
>   ERROR: atmel_mci f0000000.mmc@f0000000.of: command/data timeout
>   ERROR: atmel_mci f0000000.mmc@f0000000.of: command/data timeout
> 
> [...]

Applied, thanks!

[1/2] mci: atmel_mci: improve timeout error message
      https://git.pengutronix.de/cgit/barebox/commit/?id=bf7b978c8c3a (link may not be stable)
[2/2] mci: wait for card to leave programming state after block writes
      https://git.pengutronix.de/cgit/barebox/commit/?id=d43bedfe62b7 (link may not be stable)

Best regards,
-- 
Sascha Hauer <s.hauer@pengutronix.de>