From owner-freebsd-arm@FreeBSD.ORG Thu Jan 22 11:29:04 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 DABC4106566B for ; Thu, 22 Jan 2009 11:29:04 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id F037C8FC18 for ; Thu, 22 Jan 2009 11:29:03 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id n0MAusOZ044982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Jan 2009 11:56:54 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id n0MAupgE016778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2009 11:56:51 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id n0MAupaB051946; Thu, 22 Jan 2009 11:56:51 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id n0MAupu9051945; Thu, 22 Jan 2009 11:56:51 +0100 (CET) (envelope-from ticso) Date: Thu, 22 Jan 2009 11:56:50 +0100 From: Bernd Walter To: "M. Warner Losh" Message-ID: <20090122105650.GB50103@cicely7.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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090121.122842.-1582190967.imp@bsdimp.com> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.055, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de 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 Reply-To: ticso@cicely.de 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 11:29:05 -0000 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. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.