From owner-freebsd-arm@FreeBSD.ORG Thu Jun 7 10:53:19 2007 Return-Path: X-Original-To: arm@freebsd.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9851216A41F for ; Thu, 7 Jun 2007 10:53:19 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 430BC13C468 for ; Thu, 7 Jun 2007 10:53:18 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id l57ArGB1064910; Thu, 7 Jun 2007 12:53:16 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id l57Ar7b6083330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jun 2007 12:53:08 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id l57Ar7nX024770; Thu, 7 Jun 2007 12:53:07 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l57Ar7Sd024769; Thu, 7 Jun 2007 12:53:07 +0200 (CEST) (envelope-from ticso) Date: Thu, 7 Jun 2007 12:53:07 +0200 From: Bernd Walter To: =?iso-8859-1?Q?Bj=F6rn_K=F6nig?= Message-ID: <20070607105306.GH16463@cicely12.cicely.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> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <54244.2001:6f8:101e:0:20e:cff:fe6d:6adb.1181211368.squirrel@webmail.alpha-tierchen.de> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: arm@freebsd.org Subject: Re: 4-bit SD Card mode 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, 07 Jun 2007 10:53:19 -0000 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