SDSlotRetrofit < CryoElectronics

---++ SD Slot Retrofit

Bookmarks:

Connections

The SPI / MicroSD slot interface is defined as follows:

Pin	Name	Connection	Notes
1	N/C	N/C
2	`CS`	FPGA 3.3v	Chip select. This is also a hard-wired card detect pin. The socket shorts this to GND unless a card is inserted; the card has a pull-up to VCC.
3	`MOSI`	FPGA 3.3v bank
4	`VDD`	3.3 volts
5	`SCLK`	FPGA 3.3v	Serial clock.
6	`GND`	`GND`
7	`MISO`	FPGA 3.3v	SD to FPGA.
8	N/C

Mini Module Routing

Aug. 27, 2009: This works fine, and is being used for now. It's possible that routing considerations will require a change in pin assignment!

Aug. 28, 2009: Beware the CS pin. It's connected to the slot ground (somehow) as a card detect. Pete ohm'd this out and says it's the chassis (not the ground pin.)

Header Pin	FPGA Pin	Signal
`J2-43`	`Y12`	`MISO`
`J2-44`	`W13`	`MOSI`
`J2-55`	`D4`	`SCK`
`J2-56`	`C4`	`CS`
`J2-21` or `J2-22`	N/A	3.3V
`J2-23` or `J2-24`	N/A	GND

Kernel Gotchas

I see an awful lot of "mmc0: error -110 whilst initialising SD card" errors. From here:

On Fri, 2009-06-05 at 17:34 +0200, Joachim Foerster wrote:
we have a very strange problem with SD-card-over-SPI support using 2.6.29.4 on our custom PowerPC 405 (Virtex-4 FX FPGA) based board. To summarize the problem in one sentence: mmc_spi gets a timeout (error -110) after sending MMC command "CMD10" (CID, card identification?).

The problem seems to be these DMA transfers/methods (?), which are used by mmc_spi, if spi->master->dev.parent->dma_mask is non-NULL in mmc_spi_probe() . We detected the problem in form of kind of "data loss/corruption" in mmc_spi_readbytes() after spi_sync() is called. Data is received correctly by xilinx_spi (and thus by spi_sync())!
Background: The CMD10 is the first "bigger" (16 bytes) block transfer, where mmc_spi waits for the token 0xfe by calling mmc_spi_skip() in the end and later on receives these 16 bytes. But the token seems to be "lost/corrupted" and thus a timeout occurs.
For now our dirty workaround is, to remove DMA support by commenting out the "if (spi->master->dev.parent->dma_mask)" block in mmc_spi_probe().
Note, that in the old 2.6.26+arch/ppc this dma_mask is NULL - so DMA code is never activated in mmc_spi_probe()!
Conclusion: Either DMA code in mmc_spi has a bug OR dma_*() functions have a bug OR the device tree setup code should not assign a dma_mask to xilinx_spi devices?
Any hints? Where do we have to look in case there is something wrong in device tree setup?
Joachim

With these instructions, we get...

First Light

mmc_spi spi32765.0: xilinx_spi_setup, unsupported mode bits 4
mmc_spi spi32765.0: can't change chip-select polarity
mmc0: host does not support reading read-only switch. assuming write-enable.
mmc0: new SD card on SPI
mmcblk0: mmc0:0000 SD02G 1.83 GiB
 mmcblk0: p1

Huzzah!

The kernel boot arguments (to boot from such a device) are "console=ttyUL0 rootwait root=/dev/mmcblk0p1" (assuming the first partition on the MMC is ext2fs formatted and contains the root filesystem.) The "rootwait" option is required since the SPI interface is relatively slow: without it, the kernel will be unable to find the block device and panic. With "rootwait", it waits politely for the device to show up.

This topic: CryoElectronics > WebHome > SDSlotRetrofit Topic revision: r5 - 2009-08-31 - GraemeSmecher