Andy, Henry, Ulf, and the rest, I've posted the patch that I'm using for my SD/MMC support. It is a new driver based on some of the code from the original Atmel driver that uses the MMC framework. I've tested it on a at91sam9g45 (ES and production chips) and on an ek board and our own board.
I hope this can help you guys out and I hope this can get mainlined for others to enjoy. If the patch is not in your email, here is a link to it in the archives: http://lists.denx.de/pipermail/u-boot/2010-April/070816.html --Rob On Fri, Apr 23, 2010 at 6:18 PM, Andy Fleming <aflem...@gmail.com> wrote: > On Fri, Apr 23, 2010 at 6:21 PM, Albin Tonnerre > <albin.tonne...@free-electrons.com> wrote: >> On Fri, 23 Apr 2010 16:58 -0500, Andy Fleming wrote : >>> On Thu, Apr 22, 2010 at 7:51 PM, Rob Emanuele <r...@emanuele.us> wrote: >>> > Hi Henry & U-Boot Community, >>> > >>> > I've been experiencing the same errors and frustration you have. >>> > >>> > So I've been looking at this code and these patch sets for a day or >>> > two now. I've done that in conjunction with reading the SD card spec: >>> > http://www.sdcard.org/developers/tech/sdcard/pls/ >>> > >>> > I've come to the conclusion that this code as it stands will not work >>> > with any card that conforms to the SD Physical Layer Simplified >>> > Specification Version 2.0. This includes all SDHC cards and some >>> > non-HC cards that conform to version 2.0. I have a few 1GB cards that >>> > work just fine with the atmel_mci.c code on a 'G45 as it was in rev >>> > 95c44ec485b46ffb43dbdaa299f1491a500fdadf . >>> > >>> > If your SD card is newer, you'll see in the for loop in "sd_init_card" >>> > in atmel_mci.c time out. In the 2.0 spec, you need to perform a CMD8 >>> > (SEND_IF_COND) first to see if your card is a 2.0 card. In CMD8 you >>> > tell the card the voltages you support and if you support HC cards. >>> > Once you send it the right data there, then ACMD41 will not have its >>> > BUSY bit set. That's all well and good, but additionally the CSD >>> > register is in a new format and that needs updating before any of this >>> > will work. >>> >>> >>> The best solution is to use the MMC framework, which *does* do all of >>> these things that you suggest. It should be fairly straightforward to >>> port the atmel_mci driver to this framework. If you see something >>> lacking, feel free to mention it, or modify the framework. :) >> >> I did port the atmel_mci driver to the MMC framework and posted the results >> on >> this mailing list a few months back. However, some people apparently >> experienced >> issues I have never been able to reproduce, and got few review. >> I recently adapted the AT91 SD/MMC support patch and the atmel_mci port to >> use >> the new C structures access, I'll repost it in a couple days in case anyone's >> interested. >> > > > Yeah, I see that now. I'm catching up from being in various other > project quagmires. Sadly, > I can't apply your patch if people are running into problems with it, > but I'd far prefer it. > > I also don't have such a board, though. If someone could apply > Albin's patches, and try to identify why it's not working, I'd be very > appreciative. :) > > Andy > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
