From owner-freebsd-arm@FreeBSD.ORG Thu Jan 22 16:07:08 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 47D2D1065670; Thu, 22 Jan 2009 16:07:08 +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 EB66A8FC18; Thu, 22 Jan 2009 16:07:07 +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 n0MG52fB048050; Thu, 22 Jan 2009 09:05:02 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 22 Jan 2009 09:05:40 -0700 (MST) Message-Id: <20090122.090540.-839781195.imp@bsdimp.com> To: mav@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <49787314.3070004@FreeBSD.org> References: <20090121.122842.-1582190967.imp@bsdimp.com> <20090122105650.GB50103@cicely7.cicely.de> <49787314.3070004@FreeBSD.org> 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: freebsd-arm@FreeBSD.org, ticso@cicely.de 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:07:08 -0000 In message: <49787314.3070004@FreeBSD.org> Alexander Motin writes: : 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. The standard host adapter spec has this. The Atmel part doesn't. Warner