[U-Boot-Users] [PATCH] Update OMAP242x for git head (plus sign).
listmember at orkun.us
Thu Sep 29 22:28:16 CEST 2005
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
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
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
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.
> Comments welcome.
Thank for asking. :)
More information about the U-Boot