[U-Boot] [PATCHv2 CFI flash]: Workaround for Numonyx Axcell P33/P30 256-Mbit 65nm bug

[Joakim Tjernlund]

Philippe De Muyter <phdm at macqel.be> wrote on 2010/08/09 14:57:27:
>
> Hello Joakim,
>
> On Mon, Aug 09, 2010 at 10:32:25AM +0200, Joakim Tjernlund wrote:
> > >
> > > Dear Stefan,
> > >
> > > In message <20100623131040.GA23209 at frolo.macqel> Philippe De Muyter wrote:
> > > > Hello Wolfgang & list,
> > > >
> > > > This is a revised patch, with comments and indentation fixed, I hope.
> > > >
> > > > I have "ported" U-boot to a in house made board with Numonyx Axcell P33/P30
> > > > 256-Mbit 65nm flash chips.
> > > >
> > > > After some time :( searching for bugs in our board or soft, we have
> > > > discovered that those chips have a small but annoying bug, documented in
> > > > "Numonyx Axcell P33/P30 256-Mbit Specification Update"
> > > >
> > > > It states :
> > > > When customer uses [...] block unlock, the block lock status might be
> > > > altered inadvertently. Lock status might be set to either 01h or 03h
> > > > unexpectedly (00h as expected data), which leads to program/erase failure
> > > > on certain blocks.
> > > >
> > > > A working workaround is given, which I have applied and tested with success.
> > > >
> > > > Signed-off-by: Philippe De Muyter <phdm at macqel.be>
> > > >
> > > > ---
> > > >  drivers/mtd/cfi_flash.c |   27 ++++++++++++++++++++-------
> > > >  1 files changed, 20 insertions(+), 7 deletions(-)
> > >
> > > I didn't see comments from you?
> > >
> > > Best regards,
> > >
> > > Wolfgang Denk
> >
> > Doesn't the Linux kernel need the same fix? Would be great if
> > you(Philippe) could provide one. I too have such chips but I have
> > never seen this problem so I guess I have been lucky so far :)
> >
> >       Jocke
>
> I use linux on those boards, of course, so I also thought that I'd need
> to fix linux, but I didn't have to.  On the boards I had, the bug was
> easily repeatable with u-boot or the bdm-tools's bdm-based flash programmer
> I used.  The same blocks always gave the same error, while other blocks
> always worked perfectly.  From linux, I tested with eraseall from mtd-utils
> also on the bad blocks and I never had any problem, so linux probably
> already does the erase sequence the way numonyx testers do it.  The key
> point is that the CFI unlock command sequence must come just before the
> CFI erase command sequence, not long before.

hmm, the problem isn't erase(as I understand it). It is the unlock/lock sequence
that does. I suspect that the auto unlock procedure in cfi_cmd0001 could suffer
from this problem. Do you use auto unlock? There is nothing that
protects the timing for unlock, is there?

       Jocke