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.
York Sun writes:
...
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.
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.
...
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.
...
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; }
On Wed, 2004-10-20 at 15:40, York Sun wrote:
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.
...
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
participants (2)
-
York Sun -
Yuli Barcohen