MCF5485EVB and MMC over SPI

cancel
Showing results for 
Search instead for 
Did you mean: 

MCF5485EVB and MMC over SPI

3,602 Views
schiller
Contributor III

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 !

Labels (1)
0 Kudos
13 Replies

744 Views
schiller
Contributor III

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?

0 Kudos

744 Views
shindy2m
Contributor I

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
0 Kudos

744 Views
schiller
Contributor III

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

0 Kudos

744 Views
shindy2m
Contributor I

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.

 

 

0 Kudos

744 Views
schiller
Contributor III

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 ?

 

0 Kudos

744 Views
shindy2m
Contributor I

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.

 

 

0 Kudos

744 Views
schiller
Contributor III

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 ?

0 Kudos

744 Views
Dave_SC
Contributor I

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

 

0 Kudos

744 Views
pmatil
Contributor I

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.

0 Kudos

744 Views
pmatil
Contributor I

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?

0 Kudos

744 Views
Dave_SC
Contributor I

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?

0 Kudos

744 Views
schiller
Contributor III

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

0 Kudos

744 Views
schiller
Contributor III

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

Thanks for your help.

0 Kudos