From owner-freebsd-arm@FreeBSD.ORG Wed Jun 6 06:45:56 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 A222916A4C6 for ; Wed, 6 Jun 2007 06:45:56 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id BE61513C45B for ; Wed, 6 Jun 2007 06:45:53 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 7779735690; Wed, 6 Jun 2007 09:45:52 +0300 (EEST) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61373-04; Wed, 6 Jun 2007 09:45:49 +0300 (EEST) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id 923163568C; Wed, 6 Jun 2007 09:45:49 +0300 (EEST) Message-ID: <4666581D.9050009@bulinfo.net> Date: Wed, 06 Jun 2007 09:45:49 +0300 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.0 (X11/20070601) MIME-Version: 1.0 To: ticso@cicely.de References: <53067.2001:6f8:101e:0:20e:cff:fe6d:6adb.1181056352.squirrel@webmail.alpha-tierchen.de> <20070605154250.GN16463@cicely12.cicely.de> <20070605.100615.-1384053623.imp@bsdimp.com> <20070605165908.GP16463@cicely12.cicely.de> In-Reply-To: <20070605165908.GP16463@cicely12.cicely.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net Cc: ticso@cicely12.cicely.de, arm@freebsd.org Subject: Re: timeout while detecting 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: Wed, 06 Jun 2007 06:45:56 -0000 Bernd Walter wrote: > On Tue, Jun 05, 2007 at 10:06:15AM -0600, M. Warner Losh wrote: > >> In message: <20070605154250.GN16463@cicely12.cicely.de> >> Bernd Walter writes: >> : On Tue, Jun 05, 2007 at 05:12:32PM +0200, Björn König wrote: >> : > Hello, >> : > >> : > yet another problem. I can't access the SD card. I googled a bit and >> : > noticed that I'm not the only one with this problem, but I haven't found a >> : > solution yet. Here are some details: >> : > >> : > Everything seems to work fine until sending the app command in >> : > mmc_wait_for_app_cmd. The driver gets an interrupt with a "response >> : > time-out error" set in status register. That's it. >> >> I think this is what I fixed by increasing the timeout... >> >> : > I tried to find the problem and executed an Atmel MCI demo programm in >> : > kernel shortly after mmc_scan. It does basically the same and detects the >> : > card in the SD card bay properly. There is one obvious difference: the >> : > demo doesn't use an interrupt service routine. >> : > >> : > I hope someone has a hint for me, once again. ;-) >> : >> : All drivers expect the bootcode to setup the io-lines. >> : I also saw the effect that when booting via bootspi (MCI init added) >> : then the first boot may not find the card. >> : Booting via boot2 always succeed. >> : You may want to check about what redboot does about MCI init. >> >> The theory I read somewhere in linux land was that the boot loader was >> responsible for setting up the various I/O lines. I coded full speed >> ahead with this assumption. If it isn't actually true, then we can >> reevaluate. It isn't that hard to add a board init function. But >> then we need to add a board id to boot2 and have the kernel use it. I >> believe that redboot already passes one in... >> > > I personally like the current situation is best. > I can have the same image for variuous boards, whichout having to > define a new board name everytime. > Just a few points in respect to hardcoded clock rates may be a problem. > E.g. MCK can be higher than 60MHz if you accept to reduce the CPU clock, > which may or may not be faster depending on the io usage. > Not to speak about overclocking, which, if I got the RM9200 datasheet > right, allows higher clock rates by just overclocking the PLL. > I use MCK 80MHz and cpu clock 240MHz without any problems.