buffer write error (status 0x90)

[Joakim Tjernlund]

>
> Jon,
> I'm also replacing the obsolete P30 part and ran into an interesting
> issue.  It turns out the new replacement part has a larger buffer size
> so if you mix and match the obsolete part with the newer part you will
> have issues because if the new part is in the lower nibble 0:15 the
> CFI will read out its buffer size and since that buffer size is larger
> than the obsolete P30 sitting in the higher nibble 16:31 then the its
> buffer will get over run and not work.  So what I'm saying is that
> even though the replacement part is almost the same as the old part do
> not mix and match as the buffer sizes will cause issues.  Although you
> can patch the kernel and hard code the buffer size to that of the
> legacy P30 or even better patch it to read the buffer sizes out of
> both ICs and use the smaller size.
>
> Regards,
> Shane
>
> On Mon, Aug 9, 2010 at 11:46 PM, Jon Ringle <jon at ringle.org> wrote:
> > On Mon, Aug 9, 2010 at 5:21 PM, Adam Yergovich <ayergo at jkmicro.com> wrote:
> >> Jon Ringle wrote:
> >>>
> >>> We are replacing the discontinued Intel StrataFlash P30 flash
> >>> JS28F256P30T95 with the Numonyx P30-65nm flash JS28F256P30TF on our
> >>> boards and have a few boards with sample chips. During some testing
> >>> one of the boards with the Numonyx flash chip is now reporting the
> >>> following buffer write error (status 0x90) on every boot:

Check your samples. We did this too some time ago and the
samples we got were old and had errors not present in production parts.

> >>
> >> I have tested swapping the lower density part and haven't had any problems
> >> with MTD or otherwise.  I suspect you've just got a bad part or something
> >> else happened.
> >
> > Maybe, but we have seen other incompatibilities that occurred on all
> > of our samples. We use Redboot as the bootloader and we found that a
> > Redboot image in ROM mode will hang when trying to unlock and erase a
> > sector. I resolved that problem by building a ROMRAM Redboot image.

Most likely due to a know bug in the chips. See
"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.

Easy to work around.

 Jocke