From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Roese Date: Fri, 17 Mar 2006 10:00:43 +0100 Subject: [U-Boot-Users] flash protection code in cfi_flash In-Reply-To: <4dd15d180603161159x323e7293h5111f8777f77dc97@mail.gmail.com> References: <4dd15d180603141115g748f2303h9846f5d8b0e9b59e@mail.gmail.com> <4419A710.5080000@orkun.us> <4dd15d180603161159x323e7293h5111f8777f77dc97@mail.gmail.com> Message-ID: <200603171000.44433.sr@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi David, On Thursday, 16. March 2006 20:59, David Ho wrote: > 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. After digging through some Intel manuals it seems that you are correct here. Good catch. > 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. You did quite well. Sometimes you just need some patience (and endurance). ;-) The best way to proceed (if nobody of the CFI experts objects) would be, if you could create a patch to fix this problem using the "Legacy lock/unlock" bit from the query table. Best regards, Stefan