Date: Thu, 7 Jun 2007 12:53:07 +0200 From: Bernd Walter <ticso@cicely12.cicely.de> To: =?iso-8859-1?Q?Bj=F6rn_K=F6nig?= <bkoenig@alpha-tierchen.de> Cc: arm@freebsd.org Subject: Re: 4-bit SD Card mode Message-ID: <20070607105306.GH16463@cicely12.cicely.de> In-Reply-To: <54244.2001:6f8:101e:0:20e:cff:fe6d:6adb.1181211368.squirrel@webmail.alpha-tierchen.de> References: <50503.2001:6f8:101e:0:20e:cff:fe6d:6adb.1181202550.squirrel@webmail.alpha-tierchen.de> <20070607005128.T43808@synthcom.com> <53054.2001:6f8:101e:0:20e:cff:fe6d:6adb.1181203617.squirrel@webmail.alpha-tierchen.de> <20070607023728.X43808@synthcom.com> <54244.2001:6f8:101e:0:20e:cff:fe6d:6adb.1181211368.squirrel@webmail.alpha-tierchen.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 07, 2007 at 12:16:08PM +0200, Björn König wrote: > Neil wrote: > > The controllers I've encountered all have a "1 > > bit/4 bit" mode setting, and as long as you tell the card to go in to 4 > > bit mode and set it in the hardware as well, the SD controller handles > > everything for you. > > You are right; I had an error in reasoning. It should handle it. > > > What is the CPU in question? > > There are issues with AT91RM9200, but now I think the problem is something > else than I assumed. What issues? It is running fine for me beside it could be faster if 4bit and multiblock transfers would have been implemented. There are several hardware bugs and design flaws in the MCI hardware, which make it difficult. I have a 4bit patch available, but it's not running stable on my hardware, however I don't think it has anything to do with line sharing, since handling that is puporse of the MCI hardware. Currently I have no clue why 4bit doesn't work stable. Note, there is not reason to change width regulary unless you reselect cards, which is only required for MMC. About the multiblock thing. Writing is not an extremly big issue, but the MCI hardware has reversed byteorder and requires a buffer to copy data, which needs to be big enough for requests. Multiblock reading is problematic, you either need to stop the MCI befor finishing the last block, or it will automatically start reading the next one. When DMA finishes after the last block the first bytes from the next one get stuck into the read registers, since there is no DMA configured for the unrequested block it's stuck. Now the next transfer just gets poisoned with the stuck data bytes. Atmels workaournd is to stop fast enough or reset the controller after each transfer. This hardware flaw at least expects a major change in the interrupt state machine. Reseting the controller each time is unlikely a good solution. Maybe we can just fetch the stuck data bytes befor starting a new transfer, but this is untested and not mentioned in Atmels offical workaound. It might be a better solution to setup a dummy DMA range after the last intended block and then just reconfigure the PDA for the next transfer. Unfortunately ENOTIME catched me during work on thoses issues. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070607105306.GH16463>