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