MCF5485EVB and MMC over SPI

[schiller]

Hi,

I'm trying to use a SDCard with my MCF5485EVB board and the Linux 2.6.25 BSP from Freescale.

I plugged in a custom SDCard connector on the J26 connector of the LOGIC motherboard.

On the software side, I enabled these options in the Linux kernel :

CONFIG_SPI=y
CONFIG_SPI_MASTER=y
CONFIG_SPI_DSPI=y

CONFIG_MMC=y
CONFIG_MMC_DEBUG=y
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_BOUNCE=y
CONFIG_MMC_SPI=y

The compilation was successful. The SPI driver is loaded and ready to work.

I also compiled and successfully ran the spidevtest.c SPI test program following the "Help/software/device_drivers/DSPI_M547X_8X.htm" file.

When I plug the SDcard, nothing happens (the hardware connector has been tested). I tried to debug the SPI and MMC layers and I think that the SDCard is not correctly (or not at all) probed.

Does anyboby here had the same problem using a MMC/SDCard over SPI?

Is there a solution to get those cards working over SPI on a 5485?

I'm really waiting for your help !

[schiller]

I'm still trying to get the MMC over SPI driver working on my 5485 board. I found something strange when this driver is registered in the spi bus driver tree (call to spi_register_master). If I understand well, calling this function causes the probe driver function to be called. With the MMC over SPI driver, the probe function is never called by the kernel when the driver is initialized.

Is there somebody here who used this driver and encountered the same problem?

[shindy2m]

Hi Schiller,

you have to create and register a device in linux\arch\m68k\coldfire\m547x_8x-devices.

In attached file, the device uses a driver defined in modalias member (.modalias = "mmc_spi").

For more information see "linux\Documentation\driver-model" in your kernel source.

Jiri Sindelar

http://www.etech.cz/en/

m547x_8x_devices.c

Message Edited by t.dowe on 2009-09-10 04:59 PM

[schiller]

Hi Jiri,

That is exactly what I found yesterday by searching how the "spidev" driver was able to load its probe function.

I did what you're saying and I'm now able to probe and use my SDCard as a mass storage device.

Do you use SDCard with the 5485 ? If yes, could you please give me the transfer rate (read/write) you have ? I find write access are very slow.

Thanks for your help

[shindy2m]

I use SD Card with 5475.

I did'n measure the transfer rate exactly, but I found write access is very slow too. When I measured communication on SPI lines, I found out that problem is in very slow SPI driver (only 10 - 20% SPI bus utilisation).

I'm going to optimize the SPI driver in a future, because it doesn't use interrupts and DMA properly.

[schiller]

---

I'm going to optimize the SPI driver in a future, because it doesn't use interrupts and DMA properly.

---

 

I've also noticed some strange configuration in the SPI driver (dspi_mcf.c). For example, the DSPI_FIFO_SIZE define set to 16. In the MCF5485 reference manual, it is written that the receive FIFO size is 4 entries depth (chapter 28-1). By leaving the DSPI_FIFO_SIZE to 16, I noticed that I missed data in th Rx FIFO. Setting the DSPI_FIFO_SIZE to 4 solved this problem. Did you have this problem ?

I did not check how the interrupts are managed. Do you have some advice or direction to optimise the SPI driver ?

One other question : did you check if this slow write access is not due to the "MMC over SPI" layer or even the MMC block layer ?

[shindy2m]

Yes, I had to set DSPI_FIFO_SIZE to 4 too.

1) These functions are called when sending data:

       transfer() --> pump_messages()-->pump_transfers()-->write()

2) write() prepares only DSPI_FIFO_SIZE*4 bytes for DMA transfer and starts DMA

3) dspi_interrupt() --> read() ; write()

Maybe, it will be better to prepare complete buffer for sending and then use these interrupts (or DMA requests).

— Tx FIFO is not full (TFFF)
— Rx FIFO is not empty (RFDF)

For more information see MCF5475 (5485) datasheet.

That is all I know. I'm only a beginner in Linux, interrupts and DMA.

[schiller]

Hi,

I'm still working on the MMC over SPI code to understand why the write access are so slow. 

I played with the SPI clock frequency. After severals tires, I noticed that switching the clock around 2Mhz allow me to have faster write access. With a 25Mhz clock, I got a 50kB/s write access. With a 2Mhz clock, I got a 75 kB/s rate.

Any idea about this curious results ?

[Dave_SC]

Hi Folks,  I am trying to get an SD card up on MMC+SPI on a MCF 5475/5485 unit.  I have performed the kernel configuration as noted in your first email and added the additional platform device stuff and got a few log messages on boot.  However, no /dev/mmc device can be found after boot.  What am I doing wrong?  

What are the steps to access a SD card filesystem?

Here is a snippet of my logs:

...dmesg output...

DSPI: Coldfire master initialized

mice: PS/2 mouse device common for all mice

i2c /dev entries driver

i2c-algo-mcf.o: I2C ColdFire algorithm module is loaded.

mmc_spi spi1.0: ASSUMING SPI bus stays unshared!

mmc_spi spi1.0: ASSUMING 3.2-3.4 V slot power

mmc0: clock 0Hz busmode 0 powermode 0 cs 0 Vdd 0 width 0 timing 0

mmc_spi spi1.0: SD/MMC host mmc0, no DMA, no WP, no poweroff

mmc0: clock 0Hz busmode 2 powermode 1 cs 1 Vdd 21 width 0 timing 0

mmc_spi spi1.0: mmc_spi: power up (21)

mmc0: clock 400000Hz busmode 2 powermode 2 cs 1 Vdd 21 width 0 timing 0

mmc_spi spi1.0: mmc_spi: power on (21)

Bad message or transfer state handler.  IRQ status = c2020000

mmc_spi spi1.0: mmc_spi:  clock to 400000 Hz, 0

mmc0: starting CMD0 arg 00000000 flags 000000c0

mmc_spi spi1.0:   mmc_spi: CMD0, resp R1

mmc0: req done (CMD0): -110: 00000000 00000000 00000000 00000000

mmc0: starting CMD8 arg 000001aa flags 000002f5

mmc_spi spi1.0:   mmc_spi: CMD8, resp R3/R4/R7

mmc0: req done (CMD8): -110: 00000000 00000000 00000000 00000000

mmc0: starting CMD5 arg 00000000 flags 000002e1

mmc_spi spi1.0:   mmc_spi: CMD5, resp R3/R4/R7

TCP cubic registered

mmc0: req failed (CMD5): -110, retrying...

mmc_spi spi1.0:   mmc_spi: CMD5, resp R3/R4/R7

mmc0: req failed (CMD5): -110, retrying...

mmc_spi spi1.0:   mmc_spi: CMD5, resp R3/R4/R7

NET: Registered protocol family 1

NET: Registered protocol family 17

NET: Registered protocol family 15

mmc0: req failed (CMD5): -110, retrying...

mmc_spi spi1.0:   mmc_spi: CMD5, resp R3/R4/R7

mmc0: req done (CMD5): -110: 00000000 00000000 00000000 00000000

mmc0: starting CMD55 arg 00000000 flags 000000f5

mmc_spi spi1.0:   mmc_spi: CMD55, resp R1

mmc0: req done (CMD55): -110: 00000000 00000000 00000000 00000000

mmc0: starting CMD55 arg 00000000 flags 000000f5

mmc_spi spi1.0:   mmc_spi: CMD55, resp R1

RPC: Registered udp transport module.

RPC: Registered tcp transport module.

mmc0: req done (CMD55): -110: 00000000 00000000 00000000 00000000

mmc0: starting CMD55 arg 00000000 flags 000000f5

mmc_spi spi1.0:   mmc_spi: CMD55, resp R1

mmc0: req done (CMD55): -110: 00000000 00000000 00000000 00000000

mmc0: starting CMD55 arg 00000000 flags 000000f5

mmc_spi spi1.0:   mmc_spi: CMD55, resp R1

mmc0: req done (CMD55): -110: 00000000 00000000 00000000 00000000

mmc0: starting CMD1 arg 00000000 flags 000000e1

mmc_spi spi1.0:   mmc_spi: CMD1, resp R1

drivers/rtc/hctosys.c: unable to open rtc device (rtc0)

VFS: Mounted root (jffs2 filesystem) readonly.

mmc0: req done (CMD1): -110: 00000000 00000000 00000000 00000000

mmc0: clock 0Hz busmode 2 powermode 0 cs 1 Vdd 0 width 0 timing 0

[pmatil]

I have the same problem and messages on boot. I use a custom board with 5485 CPU. The devices.c has the board configuration lines from Jiri Sindelar's example above. I'm using the CPU's chip select 2 (DSPICS2). I also have an RTC chip at CS0 and that won't initialize either (I have a board config lines for it also). If you have SD over MMC working, please share the connection details and devices.c.

P.S. with a custom operating system the RTC is working fine so for it there's no connection problem.

I use the Freescale BSP 20111026 which compiles fine and I boot only the kernel image vmlinux.bin from memory using a custom bootloader. Root filesystem is mounted from NFS.

[pmatil]

I'm answering to myself, in case anyone struggles with the same problem. I've finally got the SD card reading and writing to work. I'm using the Freescale BSP 20111026 and it seems that the dspi driver has a number of bugs. First, the DSPI_PAR register is not correctly initialized for 547x/8x CPUs. Chip selects 2, 3 and 5 are not activated but are configured as GPIO. This mistake is in dspi_mcf.c which assumes that the DSPI_PAR register is 8-bits wide. For 547x/8x it's 16-bits. This fix only applies if you're using other chip selects than CS0.

In function coldfire_spi_probe() there's lines for setting *drv_data->par = platform_info->par_val. Change it to:

#elif defined(CONFIG_M547X_8X)

*drv_data->par = platform_info->par_val16;

#else

*drv_data->par = platform_info->par_val;

#endif

Platform info struct is from devices.c and from there it can be set as .par_val16 = 0x1FFF. Also, struct driver_data {} needs a line u16 par_val; I've made a conditional definition to set par_val as u16 if CPU is 547x/8x and else u8.

The second bug is the FIFO depth mentioned above. Setting that to 4 is correct. I have also not been able to get write speeds higher than ~20 kB/s. Read speed is however, about 1,5 MB/s. The card tested was a sandisk 2 GB class 2 card. Did anyone manage to optimize the write speed?

[Dave_SC]

An update to my question... I was able to get the SD flash talking on MMC+SPI... My board has some different chip selects that the stock eval.  When I supplied the correct chip select it was able to identify the SD and read and write to it.

The next problem is that I can only write at about 25Kb/S.  

Has anyone been able to achieve faster write speeds?

[schiller]

Hi Dave,

We are also using a MMC over SPI on a MCF5475. With our custom board, we can't get more than 70kB/s. After a lot of tests, it seems that the quality of the SDCard (brand, speed...) can act on the write speed.

I've also figured out that reducing the SPI clock speed increased the write speed on the SDCard.

I can't remember the clock speed. On the SDCard side, writing speed has changed from 35/40kB/s to 70kB/s. I think this point is closely depending to our custom hardware.

Please give us more information If you achieve to increase your wrinting speed.

-- Guillaume

[schiller]

Ok... Im' gonna try to see what I can do. I'll tell you if I have relevant results.

Thanks for your help.