From owner-freebsd-arm@FreeBSD.ORG Thu Jan 22 13:22:35 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 02EDB1065678 for ; Thu, 22 Jan 2009 13:22:35 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 3C8408FC12 for ; Thu, 22 Jan 2009 13:22:33 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [77.52.120.233] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 232281305; Thu, 22 Jan 2009 15:22:30 +0200 Message-ID: <49787314.3070004@FreeBSD.org> Date: Thu, 22 Jan 2009 15:22:28 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: ticso@cicely.de References: <20090121.100533.-1955669401.imp@bsdimp.com> <20090121.101459.2022307528.imp@bsdimp.com> <49776734.8030805@FreeBSD.org> <20090121.122842.-1582190967.imp@bsdimp.com> <20090122105650.GB50103@cicely7.cicely.de> In-Reply-To: <20090122105650.GB50103@cicely7.cicely.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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 13:22:35 -0000 Bernd Walter wrote: > On Wed, Jan 21, 2009 at 12:28:42PM -0700, M. Warner Losh wrote: >> In message: <49776734.8030805@FreeBSD.org> >> Alexander Motin writes: >> : >> : This part looks quire strange for plain FIFO explanation. Several >> : consequential commands give different results: >> : >> : CMD: 37 ARG 10000 len 0 >> : RES: 0 >> : CMD: d ARG 0 len 64 >> : >> : ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 28 >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... >> : RES: 2 >> : CMD: 37 ARG 10000 len 0 >> : RES: 0 >> : CMD: d ARG 0 len 64 >> : >> : ff ff ff ff ff ff ff ff ff ff ff ff 00 00 00 00 >> : 00 00 00 28 00 00 00 00 00 00 00 00 00 00 00 00 >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... >> : RES: 2 >> : CMD: 37 ARG 10000 len 0 >> : RES: 0 >> : CMD: d ARG 0 len 64 >> : >> : ff ff ff ff 00 00 00 00 00 00 00 28 00 00 00 00 >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... >> : RES: 2 >> : CMD: 37 ARG 10000 len 0 >> : RES: 0 >> : CMD: d ARG 0 len 64 >> : >> : ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 28 >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... >> : RES: 2 >> : >> : While working on sdhci driver for on ENE chip I have found that for >> : short transfers (less then 1K) DMA engine returns set of zeroes instead >> : of data. I haven't found better solution and just handling short >> : transfers by PIO. Same problem exists for PIO also, but there it was >> : masked by adding short delay before reading from port. >> >> I'll have to take a look at the code in more detail to make sure that >> we're doing the right thing. I noticed all the ff's, but didn't >> notice until now what they were shifted the same way that the data >> blocks were later. In this case, you'll see there's three of them. >> >> I believe that this is the first use of a CMD that generates data that >> isn't a full block of data... > > Havn't read everything, so maybe I writing nonsense in respect to > this problem. > The multiblock read trouble is a problem in the MMC design. > The first read always works fine, but you need to stop the transfer > and an exact time, otherwise it starts reading the next block. > The first bytes of the next block then stucks in the DMA fifo and > the next read then starts with the stuck uint32. > If you see broken reads like this then I would assume the previous > command was problematic. > The official workaround to get multiblock reading is to reset the MMC > and clean the fifo after each multiblock command, but I would assume > it is enough to just read the data register a few time before setting > up the DMA for the new request. Haven't look deep at that arm controller operation, but standard SD host has special counter register which terminates DMA transfer after specified amount of blocks. sdhci driver even uses it's Auth-CMD12 feature, where controller even sends STOP command to the card by itself. -- Alexander Motin