From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tolunay Orkun Date: Thu, 16 Mar 2006 11:57:36 -0600 Subject: [U-Boot-Users] flash protection code in cfi_flash In-Reply-To: <4dd15d180603160917u6d699e3fx58efaf88937d904f@mail.gmail.com> References: <4dd15d180603141115g748f2303h9846f5d8b0e9b59e@mail.gmail.com> <20060314205857.E1235353A57@atlas.denx.de> <4dd15d180603150807x3ca2ab0bj7fec61d17d03cf6a@mail.gmail.com> <4418BBA1.7090102@orkun.us> <4dd15d180603160917u6d699e3fx58efaf88937d904f@mail.gmail.com> Message-ID: <4419A710.5080000@orkun.us> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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...