[U-Boot-Users] CFI driver

[York Sun <yorksun@freescale.com>]

Yuli,

Thanks for reply.

I am using a single chip. The problem doesn't appear EVERY programming.
It happens after programming about 13KB.

I did this test. In function "flash_status_check ( )", within the while
loop, I insert codes to read DQ7-DQ0. I got DQ6 toggling and DQ5=1. That
means "exceeded timing limit". Without a reset the program will hang in
this loop. By polling the DQ7 instead of DQ6, it went smoothly.

York

On Wed, 2004-10-20 at 15:19, Yuli Barcohen wrote:
> >>>>> York Sun writes:
> 
>     York> I am debugging flash driver for MPC8555CDS board. The driver
>     York> is drivers/cfi_flash.c. I have two boards. One is rev 1.0,
>     York> with AM29LV641D.  The other is rev 1.1, with AM29LV641M.
> 
>     York> The problem is polling DQ6 after programming. The current
>     York> driver in U-boot 1.1.2 works well for AM29LV641M. As for
>     York> AM29LV641D, the programming hangs after writing about 13KB. I
>     York> track it down to "flash_is_busy()" function. When the problem
>     York> occurs, the DQ6 keeps toggling. If I change the algorithm to
>     York> polling DQ7, no problem occurs.
> 
> I'm working now with a board (Adder87x) having exactly the same flash
> (AM29LV641DL) and the driver works perfectly. I suspect that the problem
> is not in the chip but in specific configuration.
> 
>     York> Shawn has a similar problem
>     York> http://lists.infradead.org/pipermail/linux-mtd/2004-March/009402.html.
> 
> Your board uses several chips in parallel to get wider bus. The same was
> on Shawn's board. In older versions of Linux CFI driver I found a bug in
> the polling algorithm when more than one chip is used. I just replaced
> the driver with a newer version and now it works OK. It sounds like
> similar (same?) bug in the U-Boot's CFI driver.
> 
>     York> Maybe we should use DQ7 rather than DQ6.
> 
> IMHO, no. Polling DQ6 is the standard for AMD-compatible flashes.
> 
> ...