Hi all,

I've been trying to boot the 2.6.36 kernel with a filesystem on an SD card on my custom 9G20 board. The wiring is the same as the 9G20 EK, and the card works under U-boot.

If I boot Linux with a filesystem provided by initramfs, I cannot mount the card. Looking at dmesg, code from at91_mci.c is definitely executing, but it looks like the card is not responding. The errors I see in dmesg as pasted at the end of this post.

This thread suggests that MMC support on the 9G20 with at least some cards is broken in 2.6.36: http://www.spinics.net/lists/arm-kernel/msg89310.html

I've also seen a recent forum post from nferre suggesting that the 2.6.36 kernel is missing some MMC patches needed for the 9G45.

Does anyone have an SD card working on a 9G20 with a recent kernel? If not, any suggestions as to what to do next?

Thanks,
Brandon
--
Brandon Stafford
Rascal Micro
Somerville, MA

Dmesg errors
--------------------------
mmc0: clock 400000Hz busmode 1 powermode 2 cs 0 Vdd 21 width 0 timing 0
clkdiv = 165. mcck = 397879
MMC: Setting controller bus width to 1
rtc-at91sam9 at91_rtt.0: hctosys: unable to read the hardware clock
Freeing init memory: 1088K
mmc0: starting CMD52 arg 00000c00 flags 00000195
Sending command 52 as 00001874, arg = 00000C00, blocks = 0, length = 0 (MR = 00009BA5)
MCI irq: status = 0010C0E4, C07F0001, 00100000
MMC: Response timeout
Completed command
Status = 00100000/0010c0e5 [00000000 00000000 00000000 00000000]
Error detected and set to -110/0 (cmd = 52, retries = 0)
mmc0: req done (CMD52): -110: 00000000 00000000 00000000 00000000
mmc0: starting CMD52 arg 80000c08 flags 00000195
Sending command 52 as 00001874, arg = 80000C08, blocks = 0, length = 0 (MR = 00009BA5)
MCI irq: status = 0010C0E4, C07F0001, 00100000
MMC: Response timeout
Completed command
Status = 00100000/0010c0e5 [00000000 00000000 00000000 00000000]
Error detected and set to -110/0 (cmd = 52, retries = 0)
mmc0: req done (CMD52): -110: 00000000 00000000 00000000 00000000
mmc0: clock 400000Hz busmode 1 powermode 2 cs 1 Vdd 21 width 0 timing 0
clkdiv = 165. mcck = 397879
MMC: Setting controller bus width to 1
mmc0: starting CMD0 arg 00000000 flags 000000c0
Sending command 0 as 00000800, arg = 00000000, blocks = 0, length = 0 (MR = 00009BA5)
MCI irq: status = 0000C0E5, C07F0001, 00000001
Command ready
Completed command
Status = 00000001/0000c0e5 [00000000 00000000 00000000 00000000]
mmc0: req done (CMD0): 0: 00000000 00000000 00000000 00000000
mmc0: clock 400000Hz busmode 1 powermode 2 cs 0 Vdd 21 width 0 timing 0
clkdiv = 165. mcck = 397879
MMC: Setting controller bus width to 1
mmc0: starting CMD8 arg 000001aa flags 000002f5
Sending command 8 as 00001848, arg = 000001AA, blocks = 0, length = 0 (MR = 00009BA5)
MCI irq: status = 0010C0E4, C07F0001, 00100000
MMC: Response timeout
Completed command
Status = 00100000/0010c0e5 [00000000 00000000 00000000 00000000]
Error detected and set to -110/0 (cmd = 8, retries = 0)
mmc0: req done (CMD8): -110: 00000000 00000000 00000000 00000000
mmc0: starting CMD5 arg 00000000 flags 000002e1
Sending command 5 as 00001845, arg = 00000000, blocks = 0, length = 0 (MR = 00009BA5)
MCI irq: status = 0010C0E4, C07F0001, 00100000
MMC: Response timeout
Completed command
Status = 00100000/0010c0e5 [00000000 00000000 00000000 00000000]
Error detected and set to -110/0 (cmd = 5, retries = 3)
mmc0: req failed (CMD5): -110, retrying...
Sending command 5 as 00001845, arg = 00000000, blocks = 0, length = 0 (MR = 00009BA5)
MCI irq: status = 0010C0E4, C07F0001, 00100000
MMC: Response timeout
Completed command
Status = 00100000/0010c0e5 [00000000 00000000 00000000 00000000]
Error detected and set to -110/0 (cmd = 5, retries = 2)
mmc0: req failed (CMD5): -110, retrying...
Sending command 5 as 00001845, arg = 00000000, blocks = 0, length = 0 (MR = 00009BA5)
MCI irq: status = 0010C0E4, C07F0001, 00100000
MMC: Response timeout
Completed command
Status = 00100000/0010c0e5 [00000000 00000000 00000000 00000000]
Error detected and set to -110/0 (cmd = 5, retries = 1)
mmc0: req failed (CMD5): -110, retrying...
Sending command 5 as 00001845, arg = 00000000, blocks = 0, length = 0 (MR = 00009BA5)
MCI irq: status = 0010C0E4, C07F0001, 00100000
MMC: Response timeout
Completed command
Status = 00100000/0010c0e5 [00000000 00000000 00000000 00000000]
Error detected and set to -110/0 (cmd = 5, retries = 0)
mmc0: req done (CMD5): -110: 00000000 00000000 00000000 00000000
mmc0: starting CMD55 arg 00000000 flags 000000f5
Sending command 55 as 00001877, arg = 00000000, blocks = 0, length = 0 (MR = 00009BA5)
MCI irq: status = 0010C0E4, C07F0001, 00100000
MMC: Response timeout
Completed command
Status = 00100000/0010c0e5 [00000000 00000000 00000000 00000000]
Error detected and set to -110/0 (cmd = 55, retries = 0)
mmc0: req done (CMD55): -110: 00000000 00000000 00000000 00000000
mmc0: starting CMD55 arg 00000000 flags 000000f5
Sending command 55 as 00001877, arg = 00000000, blocks = 0, length = 0 (MR = 00009BA5)
MCI irq: status = 0010C0E5, C07F0001, 00100001
MMC: Response timeout
Completed command
Status = 00100001/0010c0e5 [00000000 00000000 00000000 00000000]
Error detected and set to -110/0 (cmd = 55, retries = 0)
mmc0: req done (CMD55): -110: 00000000 00000000 00000000 00000000
mmc0: starting CMD55 arg 00000000 flags 000000f5
Sending command 55 as 00001877, arg = 00000000, blocks = 0, length = 0 (MR = 00009BA5)
MCI irq: status = 0010C0E4, C07F0001, 00100000
MMC: Response timeout
Completed command
Status = 00100000/0010c0e5 [00000000 00000000 00000000 00000000]
Error detected and set to -110/0 (cmd = 55, retries = 0)
mmc0: req done (CMD55): -110: 00000000 00000000 00000000 00000000
mmc0: starting CMD55 arg 00000000 flags 000000f5
Sending command 55 as 00001877, arg = 00000000, blocks = 0, length = 0 (MR = 00009BA5)
MCI irq: status = 0010C0E4, C07F0001, 00100000
MMC: Response timeout
Completed command
Status = 00100000/0010c0e5 [00000000 00000000 00000000 00000000]
Error detected and set to -110/0 (cmd = 55, retries = 0)
mmc0: req done (CMD55): -110: 00000000 00000000 00000000 00000000
mmc0: starting CMD1 arg 00000000 flags 000000e1
Clearing timeout
Clearing: SR = 0000C0E4
Clearing: SR = 0000C0E4
Clearing: SR = 0000C0E4
Clearing: SR = 0000C0E4
Clearing: SR = 0000C0E4
Clearing: SR = 0000C0E4
Clearing: SR = 0000C0E4
Clearing: SR = 0000C0E4
Clearing: SR = 0000C0E4
Clearing: SR = 0000C0E4
Clearing: SR = 0000C0E4
Clearing: SR = 0000C0E4
Sending command 1 as 00001841, arg = 00000000, blocks = 0, length = 0 (MR = 00009BA5)
MCI irq: status = 0010C0E4, C07F0001, 00100000
MMC: Response timeout
Completed command
Status = 00100000/0010c0e5 [00000000 00000000 00000000 00000000]
Error detected and set to -110/0 (cmd = 1, retries = 0)
mmc0: req done (CMD1): -110: 00000000 00000000 00000000 00000000
mmc0: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0
MMC: Setting controller bus width to 1

Relevant parts of kernel config, if useful
----------------------------------------------------
CONFIG_MMC=y
CONFIG_MMC_DEBUG=y
# CONFIG_MMC_UNSAFE_RESUME is not set

#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_BOUNCE=y
CONFIG_SDIO_UART=m
# CONFIG_MMC_TEST is not set

#
# MMC/SD/SDIO Host Controller Drivers
#
# CONFIG_MMC_SDHCI is not set
CONFIG_MMC_AT91=y
# CONFIG_MMC_ATMELMCI is not set
# CONFIG_MMC_SPI is not set

I have not had a problem with the SD card interface, but we are using the 9260-EK ref design with only 1 SD card interface (MCDB). Did not have any issues with the 2.6.32 kernel other than being in 1 bit mode by default.

Brandon,

I had similar issues until I realized that I was missing the pull-ups on the SDIO lines. Make sure you have 47k pull-ups on DAT0,1,2,3 and CMD in your design. I have found that some memory cards have weak internal pull-ups in them, because these few cards worked for me, despite my missing SDIO bus pull-ups. But other cards that did not have built-in pull-ups did not work for me; I have since fixed my design and all cards work.

On another, semi-related note:

One bug that I discovered on the AT91SAM9G20-EK board regarding card detection: The two card slot connectors that were populated on the EK did not have the card detect pins in the connectors! So these signals are just flapping in the wind on my EK. I wonder how many people are wondering why card detect is not working on their EK?

Thanks for the suggestions, all.

@falingtrea: Just to confirm, you're using a 9G20 with the SD card design from the 9260 EK with Linux 2.6.32, right? Did you patch the kernel at all? If you have it available, I'd love to see your .config file, or just the MMC section.

@cole: I have at least this card working under U-boot, so I suspect the pull-ups and card detection are not the problem. I'll add those pull-ups for future revisions to be certain.

I'll also investigate card detection-- it seems like that's working, given all the spew in dmesg, but I'll check the code to be sure.

Are you using the 2.6.36 kernel with the patches you posted recently?

Brandon,

Yes, I am using the 2.6.36 patch that I posted with an AT91SAM9G20 design.

You will absolutely need the pull-ups if you don't already have them. Perhaps your card functions in u-boot because the SD clock rate is slower there? Measure that with a scope and see. Also, put a scope on the SD CLK, CMD, and DATn lines and make sure you have nice edges.

Take care,
-Chris

Ah, that could be it-- works with U-boot at low speed, but without pullups, or with only weak pullups in a card, it falls apart at high speed.

I'll do a little investigation.

Thanks.

You probably only need to pull-up CMD, this signal is open drain in MMC mode!

Reinhard

Hi all,

Thanks for the suggestions. I've added pull-ups to CMD and DAT0-3. The outcome is the same-- still works under U-boot, still fails under Linux with the same errors in dmesg.

I also soldered on some whiskers for scope probing. Here's a scope shot of CLK (yellow) and CMD (blue) lines under U-boot: http://rascalmicro.com/img/mmc-clk-and- ... u-boot.png

U-boot reports, "mci: setting clock 22016000 Hz, block size 512," so the 22 MHz measured clock frequency matches what we'd expect to see. It appears that the clock continues for eternity, regardless of whether any commands are being sent. The clock signal doesn't look great, but it appears to be working, and its much faster than what Linux attempts. I have not been able to capture data on the CMD line, but I suspect that is due to bungled scope triggering, as I can get accurate directory listings via fatls in U-boot.

Under Linux, the MMC clock stops, and both lines idle high.

Here are a few questions that might help me debug this:
1. How does the Linux MMC driver decide whether to use MCDA or MCDB?
2. Is there a way to interact with the MMC driver via the command line? This would mean I could test without rebooting every time.
3. How is the clock frequency set in the MMC driver? I tried adjusting mmc->f_min and mmc->f_max in at91_mci.c, but it appears they are ignored. According to dmesg, I am always at 400 kHz.

Thanks for any wisdom you can offer.

[quote="pingswept"]Thanks for the suggestions, all.

@falingtrea: Just to confirm, you're using a 9G20 with the SD card design from the 9260 EK with Linux 2.6.32, right? Did you patch the kernel at all? If you have it available, I'd love to see your .config file, or just the MMC section.
[/quote]

As I understand it, there is a git repository that you can view at git.multitech.net that has the source code.

I finally cracked this one.

I had two problems occurring at the same time:

1. I was using MCDB rather than MCDA. I mistakenly believed that the presence of a sensible signal on MCCK meant that I was using the right port; I didn't realize that MCCK was shared between the two ports (though in hindsight, that's obvious).

2. MCDA0 and MCDA1 were configured to be GPIO in the EK.

Both of these problems were fixed by small changes in arch/arm/mach-at91/board-sam9g20ek.c.

Thanks for all the help.