[U-Boot-Users] CFI, saveenv Flash no Erased
Hi All, First, my thanks to the CFI developers -- great job!
With the erase and cp commands, the CFI flash driver seems just fine. However, when I execute saveenv (env is in flash), I observe "Flash not Erased".
I'm using AMDLV065D on a Nios-II board with the latest cfi_flash.c (rev 1.18). In routine flash_write_cfiword (cfi_flash.c, line 1146), flag == 0, indicating that the flash is not "(sufficiently) erased":
flag = ((cptr.cp[0] & cword.c) == cword.c);
Adding a delay of about 500 msec corrects the problem, and I was able to trace the bits changing (eventually) to 0xff with some hack code.
This is the first time I've worked with the CFI code, so I'm looking for some guidance from someone familiar with the code on how to track down the problem/potential solution & where I should focus my attention.
Thanks, --Scott
The timeout check is not correct in the current code. I had submitted a patch to Wolfgang on July 2nd, 2005. I do not know if/when he will apply it. The patch is available via:
http://sourceforge.net/mailarchive/message.php?msg_id=12234135
Try if it solves your issue...
Best regards, Tolunay
Scott McNutt wrote:
Hi All, First, my thanks to the CFI developers -- great job!
With the erase and cp commands, the CFI flash driver seems just fine. However, when I execute saveenv (env is in flash), I observe "Flash not Erased".
I'm using AMDLV065D on a Nios-II board with the latest cfi_flash.c (rev 1.18). In routine flash_write_cfiword (cfi_flash.c, line 1146), flag == 0, indicating that the flash is not "(sufficiently) erased":
flag = ((cptr.cp[0] & cword.c) == cword.c);Adding a delay of about 500 msec corrects the problem, and I was able to trace the bits changing (eventually) to 0xff with some hack code.
This is the first time I've worked with the CFI code, so I'm looking for some guidance from someone familiar with the code on how to track down the problem/potential solution & where I should focus my attention.
Thanks, --Scott
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
In message 42FD2928.2090605@orkun.us you wrote:
The timeout check is not correct in the current code. I had submitted a patch to Wolfgang on July 2nd, 2005. I do not know if/when he will apply it. The patch is available via:
I've been working hard to shrink my list of open patches. At the moment I'm preparing for the U-Boot 1.1.3 release. After this, we will have a change in the develpoment cycle, and I hope patches will flow in much more easily.
Best regards,
Wolfgang Denk
Hi Tolunay,
Tolunay Orkun wrote:
The timeout check is not correct in the current code.
As it turns out, this is a hardware issue, _not_ a software bug WRT to my earlier post. It's related to using the toggle bit with the Nios avalon bus (as described below). I hacked up some code to use DQ7 polling for erase/write status checking and everything works just fine.
The problem is bus-related: the Nios avalon bus always fetches 32-bits from a memory peripheral, period .. regardless of the physical device size. So, an 8-bit cpu read, results in 4 x 8-bit external bus cycles, but only the first 8-bit read is delivered to the cpu core.
As you may well guess, the toggle bit transitions like this: 0 -> 1 -> 0 -> 1 for each 8-bit CPU read. So, the CPU never sees the toggle bit change state -- it always gets the state from the first 8-bit access. (Yikes!)
Anyway, that's what is happening. I'm not sure if there are any other bus architectures that behave this way. But I'd like to hear what others have to say WRT a compile time option to use DQ7 polling vs. toggle bit. I'd be happy to work on such a patch.
Please don't tell me to fix the Nios-II external bus -- I have no control over it-- and I still have a headache from tracking this issue down ;-)
Best Regards, --Scott
participants (3)
-
Scott McNutt -
Tolunay Orkun -
Wolfgang Denk