SD cards: SPI vs. 1-bit vs. 4-bit mode

[john.o...@gmail.com]

Hi All,
I believe I have read in previous posts that the OMAP3530 on the
Beagleboard interacts with the SD card using the full 4-bit data
interface (i.e., the OMAP3530 negotiates up from SPI to 4-bit mode).
At what point does the OMAP3530 start using 4-bit mode? If U-Boot is
being pulled from the SD card, is X-Loader using the full 4-bit mode?
Similarly, if U-Boot is pulling the kernel from the SD card, is U-Boot
using the full 4-bit mode?

We're trying to debug an issue with a custom design based on the
Beagleboard that is able to boot just fine off of the SD card (U-Boot
loads, kernel loads, both from the SD card), but as soon as the kernel
tries to bring up the interface for mmc0 (and subsequently the
rootfs), we start getting errors of the form:

...
mmc0: new high speed SDHC card at address 8fe4
mmcblk0: mmc0:8fe4 SU08G 7.40 GiB
mmcblk0:<4>mmcblk0: retrying using single block read
mmcblk0: error -84 transferring data, sector 0, nr 8, card status
0x9000
<repeated multiple times>

until a final error indicates that it is unable to read the partition
table and can't mount the rootfs, resulting in a kernel panic.

So clearly the SD interface is working up to a certain point (i.e., U-
Boot and the kernel can load successfully), but the kernel is
unsuccessful bringing up the SD interface. My hunch is that all
accesses to the SD card prior to the kernel trying to bring up this
interface are being done using a simpler interface (SPI or 1-bit
mode), and that the errors only occur when we move to 4-bit mode (and
potentially some issue with the D1/D2/D3 data lines). So I wanted to
see if anyone can confirm whether or not the card is ever accessed in
4-bit mode prior to the kernel trying to bring up the SD interface.

Other relevant info:
-we're using U-Boot 2009.08
-kernel is custom, based on 2.6.29-omap1
-the 8 GB SD card we're using for these tests boots just fine in our
Beagleboard with the same U-Boot, same kernel, so it really does look
like a hw issue on our side

Thanks for the bandwidth,
John

[Søren Steen Christensen]

Just checked the code - Seems like both x-loader and U-boot uses 1-bit mode:

See cpu/omap3/mmc.c for x-loader (search for HCTL)
See drivers/mmc/omap3_mmc.c for u-boot (search for hctl)

Can you make your board do a ROM code boot directly from MMC? (ROM-code
reading MLO from MMC?)
IFAIR the ROM-code will try to switch to 4-bit-mode, which should give you
the error at this time in case your theory is right :-)

Another thing to try would be to try to lower the MMC clock in the Linux
Kernel and/or cool/heat the card to see if it changes anything...

Good luck - Happy debugging
Søren

---
SSC Solutions ApS - Denmark - www.ssc-solutions.dk

> --
>
> You received this message because you are subscribed to the Google
> Groups "Beagle Board" group.
> To post to this group, send email to beagl...@googlegroups.com.
> To unsubscribe from this group, send email to
> beagleboard...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/beagleboard?hl=en.
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.426 / Virus Database: 270.14.102/2556 - Release Date:
> 12/10/09 07:36:00

[Howard Harte]

An SD memory card driver intending to use SD1 or SD4 modes will not start in SPI mode.  This is because once a card is in SPI mode, there is no way to switch into SD modes, except via card power cycle.

In SD mode, the card enumeration is performed using the CMD line, not the DAT lines.  Once the card capabilities have been determined using the CMD line, the card can be switched into SD4 mode without ever having done an SD1-mode data transfer.

That being said, both host and card are in 1-bit mode after a reset.

-Howard
---
http://www.magicandroidapps.com

[john.o...@gmail.com]

> Just checked the code - Seems like both x-loader and U-boot uses 1-bit mode:
>
> See cpu/omap3/mmc.c for x-loader (search for HCTL)
> See drivers/mmc/omap3_mmc.c for u-boot (search for hctl)

Thanks much Soren. Indeed, I finally scoped out D0-D3 and confirmed
that only D0 is active during U-Boot loading, and kernel loading. D1-
D3 become active after the SD/MMC interface is registered and brought
up by the kernel, so it looks like there is a hardware issue. It
looks like the bit-timing for 1-bit mode is around 90 nS per bit, or
~11 MHz. I haven't been able to successfully capture the speed of the
bus when it goes to 4-bit mode since it is only there for a very brief
period before it bombs out (and I don't have an adequate trigger
yet...may just wiggle an i/o line right before the interface comes up
to trigger my scope). I'm not ruling out a speed issue either...could
be the 4-bit mode runs at a faster bit rate than 1-bit mode, which
causes the issues. More playing shortly...

>
> Can you make your board do a ROM code boot directly from MMC? (ROM-code
> reading MLO from MMC?)
> IFAIR the ROM-code will try to switch to 4-bit-mode, which should give you
> the error at this time in case your theory is right :-)

Good idea. Alternately, I was going to see if I could force the
kernel to stick with 1-bit mode instead of 4-bit mode, which would
hopefully yield a working system (albeit slower).

>
> Another thing to try would be to try to lower the MMC clock in the Linux
> Kernel and/or cool/heat the card to see if it changes anything...
>
> Good luck - Happy debugging

Again, much appreciated for the quick response and insight.

Regards,
John

[john.o...@gmail.com]

On Dec 11, 10:14 am, "john.orla...@gmail.com" <john.orla...@gmail.com>
wrote:

> > Just checked the code - Seems like both x-loader and U-boot uses 1-bit mode:
>
> > See cpu/omap3/mmc.c for x-loader (search for HCTL)
> > See drivers/mmc/omap3_mmc.c for u-boot (search for hctl)
>
> Thanks much Soren.  Indeed, I finally scoped out D0-D3 and confirmed
> that only D0 is active during U-Boot loading, and kernel loading.  D1-
> D3 become active after the SD/MMC interface is registered and brought
> up by the kernel, so it looks like there is a hardware issue.  It
> looks like the bit-timing for 1-bit mode is around 90 nS per bit, or
> ~11 MHz.  I haven't been able to successfully capture the speed of the
> bus when it goes to 4-bit mode since it is only there for a very brief
> period before it bombs out (and I don't have an adequate trigger
> yet...may just wiggle an i/o line right before the interface comes up
> to trigger my scope).  I'm not ruling out a speed issue either...could
> be the 4-bit mode runs at a faster bit rate than 1-bit mode, which
> causes the issues.  More playing shortly...

Ahh...success. Turns out switching from 4-bit mode to 1-bit mode
didn't help the issue. After a bit more digging, I was able to verify
that when the kernel brings up 4-bit mode on the SD card, it is in
fact running at a faster rate (if I believe the code, it looks like
~50 MHz) than when X-Loader and U-Boot run the SD interface. A quick
check of the clock line with a scope showed that it was in fact
running faster, so I modified the mmc_sd_init_card() function in the
kernel (drivers/mmc/core/sd.c) to force it to run at 12.5 MHz. In a
2.6.32 mainline kernel, the mod is in line 482, by replacing max_dtr
with the desired speed). A hack for sure, but the SD card came right
up, along with the root filesystem. Nothing like fixing hardware with
a bit of software ;-)

So it is a hardware issue that we'll have to look at further, but for
now, the system is up.

Thanks again for the help/comments,
John

[Søren Steen Christensen]

Hi John,

> Ahh...success. Turns out switching from 4-bit mode to 1-bit mode
> didn't help the issue. After a bit more digging, I was able to verify
> that when the kernel brings up 4-bit mode on the SD card, it is in
> fact running at a faster rate (if I believe the code, it looks like
> ~50 MHz) than when X-Loader and U-Boot run the SD interface.

48Mhz I would expect, since the SD/MMC IP-block is clocked from a 96MHz
source, which only can be divided by an integer factor :-)

> So it is a hardware issue that we'll have to look at further, but for
> now, the system is up.

Do you have series resistors in the MMC-lines? It isn't on the BeagleBoard,
but it's recommended by some of the other OMAP3-design-resources (I.e.
http://wiki.davincidsp.com/index.php/SD-MMC_Usage_Notes_on_OMAP35x).
Personally I'm not sure if it matter or not, but it might be worth trying in
case you have any over/under-shoots at the interface...

In case you haven't already tried it, another quick test would be to try
another brand of SD/MMC-card (to check if the problem seems mostly card or
board related)

Best regards - Good luck

[john.o...@gmail.com]

Hi Soren,

> > Ahh...success.  Turns out switching from 4-bit mode to 1-bit mode
> > didn't help the issue.  After a bit more digging, I was able to verify
> > that when the kernel brings up 4-bit mode on the SD card, it is in
> > fact running at a faster rate (if I believe the code, it looks like
> > ~50 MHz) than when X-Loader and U-Boot run the SD interface.  
>
> 48Mhz I would expect, since the SD/MMC IP-block is clocked from a 96MHz
> source, which only can be divided by an integer factor :-)

Makes sense...good call.

>
> > So it is a hardware issue that we'll have to look at further, but for
> > now, the system is up.
>
> Do you have series resistors in the MMC-lines? It isn't on the BeagleBoard,

> but it's recommended by some of the other OMAP3-design-resources (I.e.http://wiki.davincidsp.com/index.php/SD-MMC_Usage_Notes_on_OMAP35x).

> Personally I'm not sure if it matter or not, but it might be worth trying in
> case you have any over/under-shoots at the interface...

We do have a series resistor on the clock line, but not on the data
lines. It certainly is possible that we need them on the data lines
as well. We'll have to dig in a bit more to observe the over/under
shoot on the lines to see if it is an issue or not.

>
> In case you haven't already tried it, another quick test would be to try
> another brand of SD/MMC-card (to check if the problem seems mostly card or
> board related)

Indeed, another item to check, though I am guessing that it is board
related since we were able to use these cards without any issue on our
beagleboard.

Thanks again,
John