Philippe De Muyter <p...@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.ga23...@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 <p...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
