timeout while detecting SD card

[Krassimir Slavchev]

Bernd Walter wrote:
> On Tue, Jun 05, 2007 at 10:06:15AM -0600, M. Warner Losh wrote:
>   
>> In message: <20070605154250.GN16463 at cicely12.cicely.de>
>>             Bernd Walter <ticso at cicely12.cicely.de> 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.