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

[Wolfgang Denk]

In message <433C4E60.7010700 at orkun.us> you wrote:
> 
> Actually, I think I had replied to that and there were a couple more 
> from others as far as I can remember.

Sorry, must be my volatile memory then. I have to admit  that  I  did
not re-scan the archive.

> > 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?

If flash_unlock is undefined or not starting with 'n' hen flash shall
be unlocked, to make it behave identically like flash  on  any  other
systems. Exception is the area occupied by U-boot and the envrionment
sector(s)  which  shall  be  protected by default unless unpreotected
(but then they shall be protected again after a reset) - exactly what
you see with other flash types.

> 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.

Yes. From my point of view this means fixing these boards :-)

> 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:

I want to make sure that the default behaviour is the  same  for  all
users.

> 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.

That would be even more confusing for most users.

Sorry, I can perfectly understand your intentions from  a  developers
point  of  view.  But  guess  how many users there are for each of us
developers? They outnumber us many, many times. And even if there was
perfect documentation for each of the ports - guess  how  many  users
would  not  read  it?  Providing  the  same  look and feel across all
implementations is an important issue for me. And I see it as a  part
of my task as a maintainer to keep the design simple and predictable.

KISS.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
People seldom know what they want until you give them what  they  ask
for.