CFI driver

I am debugging flash driver for MPC8555CDS board. The driver is drivers/cfi_flash.c. I have two boards. One is rev 1.0, with AM29LV641D. The other is rev 1.1, with AM29LV641M.

The problem is polling DQ6 after programming. The current driver in U-boot 1.1.2 works well for AM29LV641M. As for AM29LV641D, the programming hangs after writing about 13KB. I track it down to "flash_is_busy()" function. When the problem occurs, the DQ6 keeps toggling. If I change the algorithm to polling DQ7, no problem occurs.

Shawn has a similar problem
http://lists.infradead.org/pipermail/linux-mtd/2004-March/009402.html.
Maybe we should use DQ7 rather than DQ6.

Another issue is the CFI driver might not work for all CFI compatible flash. For example, Micro MT28F640J3. Micro uses status register instead of DQ# polling. Somehow, we still need board specific driver.

Best regards,
 
York Sun, Ph.D
Metrowerks
Freescale Semiconductor Inc.
Phone: (512) 996-5252
Email: yorksun at freescale.com
 
This email, and any associated attachments have been classified as:
[x] Freescale Semiconductor General Business
[ ] Freescale Semiconductor Internal Use Only
[ ] Freescale Semiconductor Confidential Proprietary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20041020/27a976b5/attachment.htm 

...

York> Another issue is the CFI driver might not work for all CFI York> compatible flash. For example, Micro MT28F640J3. Micro uses York> status register instead of DQ# polling. Somehow, we still need York> board specific driver.

So what's the problem? The CFI driver supports both methods, polling for AMD-compatible chips and reading status register for Intel-compatible ones. It works well on original Intel 28F640J3. Maybe Micro is not recognised correctly as Intel-compatible? If it's the case, it's just a bug which is easily fixed. You don't need board specific driver for these flashes.

BTW, please, don't send HTML to the list.

========================================================================
 Yuli Barcohen       | Phone +972-9-765-1788 |  Software Project Leader
 yuli at arabellasw.com | Fax   +972-9-765-7494 | Arabella Software, Israel
========================================================================

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.

...

========================================================================
 Yuli Barcohen       | Phone +972-9-765-1788 |  Software Project Leader
 yuli at arabellasw.com | Fax   +972-9-765-7494 | Arabella Software, Israel
========================================================================

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

Yuli,

I add the following test code and modified flash_status_check. I have no error for erasing. But I got "Time out" for programming after 13KB. This algorithm complies AMD standard, doesn't it?

Regards,

York

#define AMD_STATUS_TIMEOUT 0x20

static int flash_time_out (flash_info_t * info, flash_sect_t sect)

{
        int retval;
                                                                                                                 
        switch (info->vendor) {
        case CFI_CMDSET_AMD_STANDARD:
        case CFI_CMDSET_AMD_EXTENDED:
                retval = flash_isset (info, sect, 0,
AMD_STATUS_TIMEOUT);
                break;
        default:
                retval = 0;
        }
        debug ("flash_time_out: %d\n", retval);
        return retval;
}
static int flash_status_check (flash_info_t * info, flash_sect_t sector,
                               ulong tout, char *prompt)
{
        ulong start,now;
                                                                                                                 
        /* Wait for command completion */
        start = get_timer (0);
        while (flash_is_busy (info, sector)) {
                if (flash_time_out(info,sector)) {
                        if (flash_is_busy (info, sector)) {
                                flash_write_cmd (info, sector, 0,
info->cmd_reset);
                                printf("Time out\n");
                        }
                }
                if ((now=get_timer (start)) > info->erase_blk_tout *
CFG_HZ) {
                        printf ("Flash %s timeout at address %lx data
%lx\n",
                                prompt, info->start[sector],
                                flash_read_long (info, sector, 0));
                        flash_write_cmd (info, sector, 0,
info->cmd_reset);
                        return ERR_TIMOUT;
                }
        }
        return ERR_OK;
}

Best regards,
 
York Sun, Ph.D
Metrowerks
Freescale Semiconductor Inc.
Phone: (512) 996-5252
Email: yorksun at freescale.com
 
This email, and any associated attachments have been classified as:
[x] Freescale Semiconductor General Business
[ ] Freescale Semiconductor Internal Use Only
[ ] Freescale Semiconductor Confidential Proprietary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20041020/31efa762/attachment.htm 

Yuli,

I have confirm the problem on more boards.

Yes.

I tried 4 more boards.
I confirm the problem on one board with the same two flash chips (AM29LV641DH). I also found two boards with mixed chips (one AM29LV641MH and AM29LV641DH). One of those board has problem on erasing, no problem on programming. The other board is fine.

The problem did show up on the board with two AM29LV641MH.

I have revised the driver to support port width from 8-bit to 64-bit, chip width from 8-bit to 32-bit. Also, I modified the driver to poll DQ6 at the same address where the date is being written to. And I add the polling DQ7, which is not enabled by default. With these modification, all my boards passed testing.

By the way, here is the feedback from AMD, "It is a good practice to use the exact address where data is being written to when using the "DQ6" method, even though in theory you don't have to."

If you want to confirm, I can generate a patch. Wolfgang?

Regards,

York

Yes?

Best regards,

Wolfgang Denk

See us @ Embedded/Electronica Munich, Nov 09 - 12, Hall A.6 Booth 513
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Too many people are ready to carry the stool when the piano needs  to
be moved.