On Thu, Aug 30, 2007 at 11:56:23AM -0700, David Brownell wrote: > > > > This is a crc error. > > > > > > You're sure? On my systems, error 2 == ENOENT, which is > > > only reported when an MMC or SD card fails CID fetch... > > > > No, it's MMC_ERR_BADCRC. I don't use the patches from -mm at the moment, > > I noticed that they report errno instead of MMC_ERR_*. > > You should use the current patchset. I think the rc3-mm1 git-mmc.patch > includes the fix for that merge botch I noted, and I *know* it also > includes a few notable fixes that earlier code didn't. (None that > would seem to relate to this issue though.)
Will do. > > > > The problem with the crc is reproducible. I watched this on the logic > > analyzer, it's the response from the card to a SPI_TOKEN_STOP_TRAN > > transfer. It occurs on the very last block on an SD card: > > ISTR seeing some comment in a document pointing out that there can > be some odd faults reported when reading that block. Maybe you've > found a case where the mmc_spi code needs updating. > > > > I tested this with six SD cards. They all behave like this except one > > 512MB Kingston card which works. A MMC card I tested works too. > > Maybe we have to use a single block transfer on the last sector? > > Could be. See what the current "Simplified SD" spec says ... I do > recall language about reading that sector, but it didn't seem to > matter for any of the cards I have for testing. So I probably didn't > pay enough attention to those words. Unfortunately I did not find anything about that in the spec. If no other idea comes up I will try what happens when I read the last block using a single block read next week. The easiest way would be to fix it in the mmc block driver. That should not be too much overhead for 'real' SD cards, or is it? > > > > > > There may be still problems in my (Hilscher netx)spi driver. > > > > The mmc over spi stuff is the first testbed for this fresh driver. > > > > > > Feeling brave, aren't you? :) > > > > Sure, we do quality software here ;) > > I can only applaud! :) > > None of the other protocol level SPI drivers seem to be quite as > demanding of the underlying controller drivers, so in that sense > it's a good testbed. On the other hand, the mmc-over-SPI code is > a bit young, and various integration and corner-case issues are > still to be expected. btw what is the reason why mmc_spi requires an unshared bus? Even the SD spec talks about connecting multiple cards to one spi bus. Is it because of the CS high phase during initialization? Sascha -- Pengutronix - Linux Solutions for Science and Industry Entwicklungszentrum Nord http://www.pengutronix.de ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
