AT91RM9200 - problem with SD/MMC

Hi. I have problem with transmission between ARM and MMC/SD on my board. I tested with 16MB SD from Panasonic and 256MB Kingston MMC. Here is my board

formatting link
I use kernel 2.6.19 with patches from maxim.org.za The connections are: MMC CPU

8 -> PB3 7 -> PA29 6 -> GND 5 -> PA27 4 -> +3v3 3 -> GND 2 -> PA28 1 -> PB5 9 -> PB4 I added pullup (10k) to pin 2 of MMC/SD. Since that - kernel recognize card size, type and so on

mmc0: host does not support reading read-only switch. Assuming write-enable. mmcblk0: mmc0:5a2b S016B 14560KiB mmcblk0:mmc0: starting CMD18 arg 00000000 flags 00000035

but when I'm trying to do "cat some.img > /dev/mmc" it hangs. I use one wire interface. The last message is "Jan 1 00:11:33 (none) user.debug kernel: Handling the transmit"

Here are some extra debugs from kernel (doing cat some.img.........): What should I do ? Add more pullups to the other pins ? Other suggestions ?

-- Best regards Pelos

formatting link

Jan 1 00:11:33 (none) user.debug kernel: mmc0: starting CMD18 arg 000fe000 flags 00000035 Jan 1 00:11:33 (none) user.debug kernel: Sending command 18 as 000D1052, arg = 000FE000, blocks = 8, length = 512 (MR = 02008301) Jan 1 00:11:33 (none) user.debug kernel: pre dma read Jan 1 00:11:33 (none) user.debug kernel: Using transfer index 0 Jan 1 00:11:33 (none) user.debug kernel: sg = c01ce940 Jan 1 00:11:33 (none) user.debug kernel: dma address = 200FD000, length =

4096 Jan 1 00:11:33 (none) user.debug kernel: Nothing left to transfer (index = 1) Jan 1 00:11:33 (none) user.debug kernel: pre dma read done Jan 1 00:11:33 (none) user.debug kernel: setting ier to 00000040 Jan 1 00:11:33 (none) user.debug kernel: MCI irq: status = 0000C0DF, C07F0040, 00000040 Jan 1 00:11:33 (none) user.debug kernel: Receive has ended Jan 1 00:11:33 (none) user.debug kernel: post dma read Jan 1 00:11:33 (none) user.debug kernel: finishing index 0 Jan 1 00:11:33 (none) user.debug kernel: Unmapping page 200FD000 Jan 1 00:11:33 (none) user.debug kernel: buffer = c00fd000, length = 4096 Jan 1 00:11:33 (none) user.debug kernel: post dma read done Jan 1 00:11:33 (none) user.debug kernel: MCI irq: status = 0000C0DF, C07F4000, 00004000 Jan 1 00:11:33 (none) user.debug kernel: RX buffer full Jan 1 00:11:33 (none) user.debug kernel: MCI irq: status = 0000C0D7, C07F0001, 00000001 Jan 1 00:11:33 (none) user.debug kernel: Command ready Jan 1 00:11:33 (none) user.debug kernel: Completed command Jan 1 00:11:33 (none) user.debug kernel: Status = 0000C0D7 [00000900 CAA8DBC0 641C8008 EDD32218] Jan 1 00:11:33 (none) user.debug kernel: Sending command 12 as 0002104C, arg = 00000000, blocks = 0, length = 0 (MR = 02008301) Jan 1 00:11:33 (none) user.debug kernel: setting ier to 00000001 Jan 1 00:11:33 (none) user.debug kernel: MCI irq: status = 0000C0FF, C07F0001, 00000001 Jan 1 00:11:33 (none) user.debug kernel: Command ready Jan 1 00:11:33 (none) user.debug kernel: Completed command Jan 1 00:11:33 (none) user.debug kernel: Status = 0000C0F7 [00000B00 00808080 01104001 00000100] Jan 1 00:11:33 (none) user.debug kernel: mmc0: req done (CMD18): 0/0/0: 00000900 caa8dbc0 641c8008 edd32218 Jan 1 00:11:33 (none) user.debug kernel: mmc0: starting CMD25 arg 00000000 flags 00000035 Jan 1 00:11:33 (none) user.debug kernel: Sending command 25 as 00091059, arg = 00000000, blocks = 8, length = 512 (MR = 02008301) Jan 1 00:11:33 (none) user.debug kernel: Transmitting 4096 bytes Jan 1 00:11:33 (none) user.debug kernel: setting ier to 00008000 Jan 1 00:11:33 (none) user.debug kernel: MCI irq: status = 0000C0CF, C07F8000, 00008000 Jan 1 00:11:33 (none) user.debug kernel: TX buffer empty Jan 1 00:11:33 (none) user.debug kernel: Handling the transmit
Reply to
Pelos
Loading thread data ...

I reduced f_max MMC clock to 375kHz in kernel and added pullup to DAT - pin (7) and writes still hangs, but reading is OK. Any other suggestions ? :)

--
Pelos
http://twarm.pelos.pl
Reply to
pelos

Well - I found solution :-)

formatting link

--
Pelos
http://twarm.pelos.pl
Reply to
Pelos

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.