[U-Boot-Users] [PATCH] cfi_flash.c patches

Tolunay Orkun listmember at orkun.us
Fri Aug 19 22:16:52 CEST 2005


Richard,

Woodruff, Richard wrote:

>Tolunay,
>
>Several Intel chips do provide hardware level protection locks which get
>cleared at reset.
>  
>
I do not know of any Intel flash that would unlock sectors on "Reset". 
Can you be specific? Even so it is not relevant to the problem of this 
specific flash which does 100% opposite (intentionally and for a very 
good reason)

I do know early Intel flash would unlock all flashs sectors as you 
unlock one so all previous locks would have to be redone. U-Boot has 
code to fix this. I think you are confusing with this type of Intel flash.

>It is useful to use this hardware feature at boot to help protect flash
>sectors from upper level code during normal operation.  The u-boot
>software lock is nice, but doesn't extend beyond u-boot code while the
>hardware lock does.
>  
>
Yes, I support use of hardware sector/block locks on chips that supports 
hardware locking for the same reason. I was not suggesting use of 
software protection for the user. In fact, I am suggesting the opposite 
as he probably has not enabled hardware protection code using 
CFG_FLASH_PROTECTION.

>The difference in behavior between chips is the issue here.  Perhaps it
>is better to add another compile time flag which allows the hardware
>features to be used on such chips.
>  
>
Unlocking sectors that should really remain locked until you explicitly 
unlocked is an invitation for problems and against the model of use 
these flash is promoting. If your flash relocks these sectors all you 
have to do is to explicitly unlock them using "protect off" before doing 
a "cp" etc. For protect off to work, you will need to define 
CFG_FLASH_PROTECTION so flash_real_protect() would be called by "protect 
off" command. The difference between this and the solution proposed is 
that the proposed solution is taking all sectors unlocked even if 
perhaps you will not modify/erase etc the flash sectors. You should do 
these on demand in the spirit of the flash design.

>Your point is one _hardware_ features behavior should be valued over
>another's.  Having them both via flags is probably the way to go.
>  
>
We do not have to pick one way or another. U-Boot already supports these 
new flash and it is supported in a way compatible with the design.

What is being done is unlocking all sectors irrespective of they should 
or should not remain unlocked. Why don't you unlock only the sectors 
that you are intentionally updating using "protect off".

>Regards,
>Richard W.
>
>  
>
>>-----Original Message-----
>>From: u-boot-users-admin at lists.sourceforge.net [mailto:u-boot-users-
>>admin at lists.sourceforge.net] On Behalf Of Tolunay Orkun
>>Sent: Friday, August 19, 2005 1:37 PM
>>To: Sangmoon Kim
>>Cc: u-boot; Wolfgang Denk
>>Subject: Re: [U-Boot-Users] [PATCH] cfi_flash.c patches
>>
>>Dear Sangmoon,
>>
>>I've examined your patch for clearing the protection of flash sectors
>>automatically during flash init. As a matter of fact a similar patch
>>    
>>
>was
>  
>
>>also proposed by someone else and I had commented on it as well.
>>
>>I think this is wrong approach. These sectors are protected for a
>>    
>>
>reason
>  
>
>>(to prevent accidental writes - forgetting to enable protection).
>>
>>You should enable CFG_FLASH_PROTECTION in your board config file. If
>>    
>>
>you
>  
>
>>don't do this U-Boot will do software protection of sectors (which is
>>really for those flash chips with no hardware protection capability)
>>    
>>
>and
>  
>
>>"protect off" will not issue unlock commands as you may have
>>    
>>
>witnessed.
>  
>
>>CFG_FLASH_PROTECTION will enable the "protect  off" command to disable
>>protection properly on these sectors as it should.
>>
>>IMHO, No patch is needed here! Perhaps we need to add a couple of
>>comment lines in README (DULG?) for documentation purposes. Wolfgang,
>>can you comment here.
>>
>>Best regards,
>>Tolunay
>>
>>Sangmoon Kim wrote:
>>    
>>
>>>Hi,
>>>The two patches attached are for drivers/cfi_flash.c.
>>>
>>>cfi_flash-protect.patch adds CFG_FLASH_PROTECT_CLEAR
>>>because for some flash memories(such as 28F320C3)
>>>all banks are protected after reset.
>>>
>>>cfi_flash-buffer.patch makes write_buff not to call
>>>flash_write_cfibuffer if buffer_size is1.
>>>Because for flash memories with buffer_size 1,
>>>buffer write is not supported.
>>>
>>>Regards,
>>>Sangmoon Kim
>>>      
>>>
>>
>>-------------------------------------------------------
>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle
>>Practices
>>Agile & Plan-Driven Development * Managing Projects & Teams * Testing
>>    
>>
>& QA
>  
>
>>Security * Process Improvement & Measurement *
>>    
>>
>http://www.sqe.com/bsce5sf
>  
>
>>_______________________________________________
>>U-Boot-Users mailing list
>>U-Boot-Users at lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/u-boot-users
>>    
>>






More information about the U-Boot mailing list