[U-Boot-Users] CFI, saveenv Flash no Erased

[U-Boot-Users] CFI, saveenv Flash no Erased

[Scott McNutt]

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

[U-Boot-Users] CFI, saveenv Flash no Erased

[Tolunay Orkun]

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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] CFI, saveenv Flash no Erased

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The last thing one knows in constructing a work is what to put first.
- Blaise Pascal

[U-Boot-Users] CFI, saveenv Flash no Erased

[Scott McNutt]

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