From owner-freebsd-arm@FreeBSD.ORG Thu Jan 22 16:12:43 2009 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B2C01065692; Thu, 22 Jan 2009 16:12:43 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id D28E78FC1A; Thu, 22 Jan 2009 16:12:42 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n0MGBP2V048208; Thu, 22 Jan 2009 09:11:25 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 22 Jan 2009 09:12:04 -0700 (MST) Message-Id: <20090122.091204.831807729.imp@bsdimp.com> To: ticso@cicely.de, ticso@cicely7.cicely.de From: "M. Warner Losh" In-Reply-To: <20090122151340.GE50103@cicely7.cicely.de> References: <20090122142015.GC50103@cicely7.cicely.de> <49788702.9010808@FreeBSD.org> <20090122151340.GE50103@cicely7.cicely.de> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mav@FreeBSD.org, freebsd-arm@FreeBSD.org Subject: Re: Mount root from SD card? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 16:12:43 -0000 In message: <20090122151340.GE50103@cicely7.cicely.de> Bernd Walter writes: : On Thu, Jan 22, 2009 at 04:47:30PM +0200, Alexander Motin wrote: : > Bernd Walter wrote: : > >Yes - and this is broken in the Atmel design. : > >This is not the only nasty bug that Atmel has left int he chip. : > >You need to issue the STOP command at the absolut right timing, which : > >is more or less impossible. : > >The design puts every 32bit word in a receive register, which has a small : > >fifo. : > >You can setup a DMA enginge to pull the words from the register into RAM. : > >Now what happens is that if you issue the STOP too late it starts reading : > >the next block and then stops - the card can stop at every location, so : > >there is no problem about this, but now you have the first words in the : > >receive fifo. : > >The DMA doesn't work anymore, because it was setup with a limited number : > >of words to pull, so the additional words are kept in the register. : > >Once you start reading the next block and setup the DMA it pulls the : > >stuck words first. : > >It that case it looks as if the timing is one word too late therefor : > >you get 4 additonal bytes after each transaction. : > >It shouldn't be a problem to read the receive register without data in : > >it, so 4 or 5 dummy reads befor DMA setup should be enough. : > >IIRC the fifo can only hold up to 3 words. : > : > Looks realistic. Just needed somebody with hardware to investigate it. : : I unfortunately don't have the time right now. : : > But even if current problem seems to be alike, the reasons are probably : > different. At this time, mmc/mmcsd layers are strictly instructed to not : > issue multi block operations to the at91 controller. There is something : > different pollutes the buffer. : : That's the point why I was not sure if it applies here. : Is there anything else issued which needs a STOP? : I'm really a bit out of SD card command handling... : : > But may be cleaning that FIFO before starting transfer could become : > universal solution. : : Probably - especially because multiblock operations are a massive : speed factor, but it would still be good to know why it happens here. : : With multiblock writing we don't have this problem, because we have : to supply the data and there is no reson to supply more than we need to : send. : The reason why we don't allow multiblock writes with this controller is : just because we need a temporary buffer to reorder the bytes, which is : fixed allocated to one block - the MCI in the RM9200 uses the wrong : byte order - sigh... : Would be good to use a larger buffer some day to speed up writing. : Especially with writing multiblock would be a major enhancement. Yes. We could have a larger buffer, but we still need the reset the fifo after each transfer hack. I tried to implement it long ago, but it failed to work reliably... : As another point: : Is it possible to support SHDC with mci some day, or is there a special : hardware requirement for SDHC? It should be, in theory, possible. sdio is a different matter due to timing issues, but SDHC should be possible... Warner