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