cfi_flash.c patches
Woodruff
PATCH 1/1 cfi_flash.c patches
Tolunay,
Several Intel chips do provide hardware level protection locks which get cleared at reset.
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.
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.
Your point is one _hardware_ features behavior should be valued over another's. Having them both via flags is probably the way to go.
Regards,
Richard W.
Quoted 8 lines
-----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.cpatches
Quoted 4 lines
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
Quoted 3 lines
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
Quoted 3 lines
(to prevent accidental writes - forgetting to enable protection).
You should enable
CFG_FLASH_PROTECTIONin your board config file. If
you
Quoted 2 lines
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
Quoted 1 line
"protect off" will not issue unlock commands as you may have
witnessed.
Quoted 29 lines
CFG_FLASH_PROTECTIONwill 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,
TolunayQuoted 7 lines · Sangmoon Kim
Hi,
The two patches attached are fordrivers/cfi_flash.c.cfi_flash-protect.patch adds
CFG_FLASH_PROTECT_CLEARbecause for some flash memories(such as 28F320C3) all banks are protected after reset.Quoted 7 lines
cfi_flash-buffer.patch makes
write_buffnot to callflash_write_cfibufferifbuffer_sizeis1. Because for flash memories withbuffer_size1, buffer write is not supported.Regards,
Sangmoon Kim
Quoted 5 lines
-------------------------------------------------------
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
Quoted 1 line
Security * Process Improvement & Measurement *
Quoted 4 lines
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
PATCH 1/1 cfi_flash.c patches
Richard,
Quoted 6 lines · Richard
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.
Quoted 6 lines
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.
Quoted 5 lines
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.
Quoted 4 lines
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".
Quoted 103 lines
Regards,
Richard W.Quoted 8 lines
-----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.cpatchesQuoted 6 lines
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
Quoted 5 lines
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
Quoted 5 lines
(to prevent accidental writes - forgetting to enable protection).
You should enable
CFG_FLASH_PROTECTIONin your board config file. Ifyou
Quoted 4 lines
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
Quoted 3 lines
"protect off" will not issue unlock commands as you may have
witnessed.
Quoted 30 lines
CFG_FLASH_PROTECTIONwill 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,
TolunayQuoted 7 lines · Sangmoon Kim
Hi,
The two patches attached are fordrivers/cfi_flash.c.cfi_flash-protect.patch adds
CFG_FLASH_PROTECT_CLEARbecause for some flash memories(such as 28F320C3) all banks are protected after reset.Quoted 9 lines
cfi_flash-buffer.patch makes
write_buffnot to callflash_write_cfibufferifbuffer_sizeis1. Because for flash memories withbuffer_size1, buffer write is not supported.Regards,
Sangmoon KimQuoted 7 lines
-------------------------------------------------------
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
Quoted 3 lines
Security * Process Improvement & Measurement *
Quoted 6 lines
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Quoted 3 lines · Tolunay Orkun <listmember <at> orkun.us> writes:
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.
I believe that Intel's strataflash does this, but their boot block units do not.
Signature · 2 lines
Marcus Hall marcushall at lucent.com