[U-Boot-Users] [PATCH] Update OMAP242x for git head (plus sign).

[Tolunay Orkun]

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