From mboxrd@z Thu Jan  1 00:00:00 1970
From: Tolunay Orkun <listmember@orkun.us>
Date: Wed, 14 Mar 2007 23:48:36 -0500
Subject: [U-Boot-Users] CFI flash driver problem
In-Reply-To: <1628E43D99629C46988BE46087A3FBB9900C73@ep-01.EmbeddedPlanet.local>
References: <1628E43D99629C46988BE46087A3FBB9900C73@ep-01.EmbeddedPlanet.local>
Message-ID: <45F8D024.1020206@orkun.us>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Jeff Mann wrote:

>> flash_write_cmd() function when calling it with "flash_write_cmd 
>> (info, sect, 0, AMD_CMD_ERASE_SECTOR);" at around line 490 in
>>     
> flash_erase().
>   
>>   
>>     
>
> UPDATE:
>
> I am proving this update in case someone searches the list archives to
> solve a similar problem. 
>
> The problem was the result of both NOR Flash and Cellular RAM driving
> the EBC_READY signal (also called CRAM_WT, and WAIT in the CRAM
> documents). Because of this configuration, after doing an operation on
> the Flash that requires a delay, such as erase or write, the Flash held
> EBC_READY low for a long time while erading or writing. So the processor
> never saw the CRAM release CRAM_WT when its data was ready. The
> processor never could retrieve the next instruction and intrepreted this
> as an "illegal instruction."
>
> The problem had nothing to do with bus transievers or accessing timing. 
>
> In "human time" the erase cycle completed before I made the next step in
> code. 
>
> -Jeffrey Mann
Jeff,

Thank you for the update. Did you make changes to your board design to 
solve this problem?

One solution would be to disconnect nor flash from EBC_READY and 
configure that CS for appropriate number of wait cycles. Another would 
be to disable bus timeout if possible.

Tolunay