mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Yann Sionneau <ysionneau@kalray.eu>
To: barebox@lists.infradead.org
Subject: Re: arasan-sdhci eMMC Problem 'command timeout'
Date: Thu, 6 Oct 2022 15:28:59 +0200	[thread overview]
Message-ID: <49e58ddb-dfe1-b387-9721-05596f9f0cbd@kalray.eu> (raw)
In-Reply-To: <AM9P192MB08709ED9E86625C99913EA2FAB5C9@AM9P192MB0870.EURP192.PROD.OUTLOOK.COM>

Hello Michael,

The driver is polling for completion of the commands (8 for the first 
error, 55 for the second).

While doing this polling, an error was raised by the SDHCI controller.

The nature of the error is reported in the register SDHCI_INT_ERROR (reg 
offset 0x32)

Only the LSB (bit 0) is set.

This bit means "Command Timeout Error".

I copy paste the SDHC simplified specification version 4.20:

"

This bit is set only if no response is returned within 64 SD clock 
cycles from
the end bit of the command. If the Host Controller detects a CMD line
conflict, in which case Command CRC Error shall also be set as shown in
Table 2-26, this bit shall be set without waiting for 64 SD clock cycles
because the command will be aborted by the Host Controller.

"

So it seems either the eMMC stops answering, or it's too slow.

Or ... the controller thinks it's too slow and the "timeout" could be a 
false positive.

To check for false positive :

* check the tmclk frequency, it's a clock which is an input of the sdhc 
controller in the Soc: see your SoC documentation for that on how the 
sdhc controller is integrated.

* check the Timeout Control Register content (register 0x2E). Try to 
force a higher value (for instance max value is 0xe)

* Check that CAPABILITIES1_R (register 0x40) fields TOUT_CLK_UNIT (bit 
7) and TOUT_CLK_FREQ (bits [5:0]) that are reported by the controller 
corresponds correctly to the real value of the tmclk clock that is 
feeded to the controller by the SoC.

You can try to hook-up a logic analyser to your eMMC bus to have a look 
at what's happening. Try to lower the max frequency of the bus before 
doing so, so that the logic analyzer extra capacitance does not mess too 
much with the bus signaling.

Another lead to investigate is to have a look at which QUIRKS are 
enabled by the Linux driver to make the controller work in your case: 
https://github.com/torvalds/linux/blob/master/drivers/mmc/host/sdhci-of-arasan.c

Maybe Linux enables some quirks that could be needed to also "enable" in 
the Barebox driver?

Regards,

Yann

On 10/6/22 15:03, michael.graichen@hotmail.com wrote:
> Hey,
>
> I have connected an eMMC to sdhci0 and a uSD Card to sdhci1 of a Zynq.
> while the uSD Card seams to work fine i'm getting the error
>
> arasan-sdhci e0100000.mmc@e0100000.of: registered as mmc0
> arasan-sdhci e0100000.mmc@e0100000.of: SDHCI_INT_ERROR: 0x00000001
> arasan-sdhci e0100000.mmc@e0100000.of: error while transfering data for command 8
> arasan-sdhci e0100000.mmc@e0100000.of: state = 0x01ff0001 , interrupt = 0x00018000
> arasan-sdhci e0100000.mmc@e0100000.of: SDHCI_INT_ERROR: 0x00000001
> arasan-sdhci e0100000.mmc@e0100000.of: error while transfering data for command 55
> arasan-sdhci e0100000.mmc@e0100000.of: state = 0x01ff0001 , interrupt = 0x00018000
>
> from the eMMC.
>
> arasan-sdhci e0101000.mmc@e0101000.of: registered as mmc1
> mmc1: detected SD card version 2.0
> mmc1: registered mmc1
>
> both eMMC and SDCard work fine in Linux. So I think the Problem is some confuguration difference between Linux and barebox.
> The MMC is from type MTFC8G but Linux detects it as
>
> [    2.012122] mmc0: new high speed MMC card at address 0001
> [    2.021129] mmcblk0: mmc0:0001 Q2J55L 7.09 GiB
> [    2.026355] Btrfs loaded, crc32c=crc32c-generic, zoned=no, fsverity=no
> [    2.027458] mmcblk0boot0: mmc0:0001 Q2J55L 16.0 MiB
> [    2.031509] mmcblk0boot1: mmc0:0001 Q2J55L 16.0 MiB
> [    2.039829] mmcblk0rpmb: mmc0:0001 Q2J55L 4.00 MiB, chardev (245:0)
>
> Unfortunattly I'm not very familliar with SDHCI, so I would apreciate any help.
>
> Best Regards
> Michael
>
>
>
>
>
>
>
>
>
>







  parent reply	other threads:[~2022-10-06 13:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-06 13:03 michael.graichen
2022-10-06 13:13 ` Ahmad Fatoum
2022-10-07 14:13   ` AW: " michael.graichen
2022-10-07 14:21     ` Ahmad Fatoum
2022-10-06 13:28 ` Yann Sionneau [this message]
2023-01-03 22:06   ` Ahmad Fatoum
2023-01-04  9:27     ` Yann Sionneau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49e58ddb-dfe1-b387-9721-05596f9f0cbd@kalray.eu \
    --to=ysionneau@kalray.eu \
    --cc=barebox@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox