Dear Wolfgang,
Wolfgang Denk wrote:
The problem with the previous discussion was that there was no agree- ment wether the board should come up with the flash generally un- locked (which is probably what most users expect and what is assumed in the existing documentation), or if it should be left untouched (which is what some board maintainers want). Detlev ZUndel tried to start a poll of opinions, which - to the best of my knowledge - resulted in no replies at all.
Actually, I think I had replied to that and there were a couple more from others as far as I can remember.
I can see only one way to keep everybody satisfied:
I am glad we are now looking at formulating a (better) solution now.
The unlocking feature gets implemented (as part of the common CFI flash driver), with the default that flash automatically gets un- locked when the board comes up (this gives most users the expected standard behaviour).
A new environment variable "flash_unlock" can be defined which, when set to a value that starts with a 'n' (like "setenv flash_unlock no") will turn off the automatic unlock (so board maintainers or users who need to optimize boot times can turn this off, eventually as a default by pre-setting this variable in thier board config file).
Currently, some Intel flash parts can maintain the lock/unlock state for their sectors. Is flash driver going to unlock these sectors if flash_unlock is undefined or leave at "current" state?
Unlocking all sectors on these parts would change the current behavior of the boards unless either the environment variable is defined or board config file is also updated.
I prefer undefined "flash_unlock" environment variable to mean use whatever default action in board config file or if none is defined in board config file assume flash_unlock=no. In short this means:
1) All boards with no locking support would not be effected anyway. 2) All boards with flash that maintain lock state from last change would work unmodified as well with existing environment settings and board config file. 3) All new flash parts that have all sectors coming up in locked state are used on relatively newer board designs and the board designers would need to add CONFIG_FLASH_UNLOCK (or something like that) to their board config file.
Also, Instead of all black or white, why don't we have unlock regions for partial unlocking sections of flash like like jffs2 partitions? E.g.
setenv flash_unlock no setenv flash_unlock yes setenv flash_unlock 1:12-39,2:0xfff00000-0xfffbffff,3:all
The last one above would give partial regions to unlock. If comma is not OK we can use another seperator character. Basically, it would list a number of sector range specifications as used by other flash related commands use.
Similarly if we adopt partial unlocks we can also have partial locks as well via flash_lock environment variable.
It shall be a requirement (1) that the existing commands "lock" and "unlock" work as expected and (2) that the "flinfo" command shows the current lock state correctly, i. e. if the flash comes up locked it *must* be displayed as read-only.
100% agreed.
Comments welcome.
Thank for asking. :)
Best regards, Tolunay