[U-Boot-Users] flash protection code in cfi_flash

[David Ho]

Hi all,

Maybe if there is someone from Intel on this list they would have
clear up this confusion much earlier.  Better yet, if someone from
Intel can correct me here.

Some explanation is in order.

While Intel flashes K3/C3 use the that command sequence as block
unlock,  the same command sequence (0x60 0xD0) is used to "clear all
blocks bits" on the J3.  This is restrictly speaking not an intel
flash bug.  The datasheet had not mentioned there is a change to the
lock/unlock command in the datasheet revision history so it appears to
have been there in the J3 datasheet from the start.  Just that there
is an inconsistency in the behaviour of the command sequence.  They
refer to it as Legacy lock/unlock in the Primary Vendor Specifc
Exended Query Table.  So information can be extracted from CFI
attributes.

All indication suggests that Intel is not at fault.

With the evidence gathered thus far, it is simply small detail
overlooked by the implementor of the original code, which is perfectly
acceptable.  Just that I would have hoped this thread elicited
discussion that led to this discovery.

I wonder how I can better present myself to make others more co-operative.

David



On 3/16/06, Tolunay Orkun <listmember at orkun.us> wrote:
> David Ho wrote:
> > Okay,
> >
> > I really didn't mean to rip out someone's code, I know it was there
> > for a reason.  In any case, I like to understand which Intel flash is
> > behaving badly.  The spec does not say unprotect unlocks all blocks.
> >
> First, I am not the author of this part of code. I can tell you the
> Intel StrataFlash 28F128J3 parts on my Cogent CSB272 board needs this
> code. Original author must have hit the same issue. This is a chip bug
> and probably documented on some Intel Errata and it may be applying to
> certain Revs of the chip. I do not have a list.
> >
> >>> If no one has any objection, I will remove the part of the code that
> >>> relock each sector, for submission.
> >>>
> >> First, That behavior is required because some Intel flash parts
> >> incorrectly unlock all sectors (not just current sector) so after
> >> unlocking the current sector we must redo the locking of all others that
> >> were supposed to remain locked. Again, the comment in that code reflects
> >> and explains this.
> >>
> >
> > I am sorry, my interpretation of your comment led me to think you are
> > suggesting all Intel flashes behave this way.  Really my original post
> >
> What is not clear about the word "some" in my description of the issue?
> I am obviously not claiming all Intel parts are this. Your
> interpretation is incorrect.
>
> > came from a confusion of the comment.  A better comment may include
> > what you just said above.
> >
> > Do you know which parts behave this way?  Has Intel confirmed this?
> >
> I do not need Intel's confirmation. It is a reality for me. Again, it is
> most likely documented in some Intel Errata (which might not be widely
> publicly circulated).
>
> > Certainly not all flashes need to have this workaround, perhaps it is
> > sensible to option it out?  Anyway, I have no problem with this code
> > being there.  Since I have not seen the same behaviour you saw, and
> > google did not turn up and evidence to support this, I was just
> > curious if this has been solved since the code was first submitted.
> >
> I certainly do not have the capability to test each new rev of every
> Intel flash. Without a complete list you can only take the safe path...
>
>
>