[U-Boot-Users] MMC Card Problems with U-Boot 1.1.6
Hello.
I’m using U-Boot 1.1.6, and I’m having problems with the MMC support. My board is a custom board based on the PXA270 CPU, with 128MB of SDRAM and 64MB of internal flash. Using the loadb command, I can successfully copy my filesystem to the SDRAM. Then, I use the cp.b command to transfer it to flash. Everything works properly and the filesystem transfers without any problem.
Next, I tried using the fatload command to copy the same exact filesystem from the MMC card to SDRAM. U-Boot claims that the entire file was copied correctly as indicated by the filesize environment variable. However, once I move the filesystem to flash, it ends up corrupted in the flash. I can only conclude that the fatload command has incorrectly copied the filesystem from the MMC card to SDRAM.
Has anybody had trouble using MMC cards and the fat commands with a PXA270 CPU? I don’t receive any error messages, so I’m not really sure where to look.
Thanks in advance for any guidance.
Steve
What kind of MMC cards are you using? We're in the same boat and haven't been able to initialize Patriot 512MB cards. I've rewritten/added to the code for SD 2.0 (added 'sdinit' and an sd interface) and am seeing portions of the data dropped when I read blocks from a 512MB SanDisk SD 2.0 card. We're clocking at 10 MHz, running a 312 MHz PXA-270 (with turbo mode), and both cards work fine under our 2.6.18 kernel.
You can define DEBUG and MMC_DEBUG and rebuild u-boot to look at the command outputs. Our MMC_STAT register reads 0x2140 on successful commands and 0x2142 on timeouts.
Has anyone been able to copy file systems correctly with MMC or SD on the PXA-270? I'm not convinced this ever worked.
sgobien wrote:
I’m using U-Boot 1.1.6, and I’m having problems with the MMC support. My board is a custom board based on the PXA270 CPU, with 128MB of SDRAM and 64MB of internal flash. Using the loadb command, I can successfully copy my filesystem to the SDRAM. Then, I use the cp.b command to transfer it to flash. Everything works properly and the filesystem transfers without any problem.
Next, I tried using the fatload command to copy the same exact filesystem from the MMC card to SDRAM. U-Boot claims that the entire file was copied correctly as indicated by the filesize environment variable. However, once I move the filesystem to flash, it ends up corrupted in the flash. I can only conclude that the fatload command has incorrectly copied the filesystem from the MMC card to SDRAM.
Has anybody had trouble using MMC cards and the fat commands with a PXA270 CPU? I don’t receive any error messages, so I’m not really sure where to look.
Thanks in advance for any guidance.
Steve
On 2/13/07, Pete MacKay linux@architechnical.net wrote:
What kind of MMC cards are you using? We're in the same boat and haven't been able to initialize Patriot 512MB cards. I've rewritten/added to the code for SD 2.0 (added 'sdinit' and an sd interface) and am seeing portions of the data dropped when I read blocks from a 512MB SanDisk SD 2.0 card. We're clocking at 10 MHz, running a 312 MHz PXA-270 (with turbo mode), and both cards work fine under our 2.6.18 kernel.
I think I know where I'd start looking ;-)
/* FIXME fill in the correct size (is set to 32MByte) */ mmc_dev.blksz = 512; mmc_dev.lba = 0x10000;
Btw, why do you need an sdinit command? It should be possible to tell the difference between SD and MMC cards automatically. In fact, I know it's possible because the Linux driver does it, and the at32ap7000 mmc driver I haven't submitted yet does it.
Haavard
Thanks for the pointers! I replaced that with the values read from the CSD, which was a task in itself as the 270 seemed to add a 0x3F and drop the CRC/0x01 byte in the response (which is reversed byte-order).
You're right that the cards can be told apart with the proper init sequence (the right way for submission), but I added 'sd' commands and interface in the interest of time and preserving the original MMC code line. Fortunately adding commands to u-boot is easy! :) CMD1 isn't supported in SD 2.0 (it times out), which does added negotiation (CMD8/ACMD41). Linux very recently added SDHC (high capacity) support and last I heard they were debating whether the sequence should check for MMC first (CMD1) or SD (CMD8).
Alas, the kernel code is layered and complex, but is a good place to start. I've been looking through it for 270 caveats (there are several) and now my brain hurts...
Haavard Skinnemoen-2 wrote:
I think I know where I'd start looking ;-)
/* FIXME fill in the correct size (is set to 32MByte) */ mmc_dev.blksz = 512; mmc_dev.lba = 0x10000;Btw, why do you need an sdinit command? It should be possible to tell the difference between SD and MMC cards automatically. In fact, I know it's possible because the Linux driver does it, and the at32ap7000 mmc driver I haven't submitted yet does it.
Haavard
participants (3)
-
Haavard Skinnemoen -
Pete MacKay -
sgobien