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@lists.sourceforge.net [mailto:u-boot-users- admin@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 *
U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users