[U-Boot] erase and saveenv stop working after using fw_setenv

[Wolfgang Denk <wd@denx.de>]

Dear Petri Lehtinen,

In message <48CF6452.40603@inoi.fi> you wrote:
> 
> I'm using U-Boot 1.3.4 and Linux 2.6.26.5 on MPC8323E-RDB. After using
> fw_printenv in Linux, erase and saveenv stop working in U-Boot. In
--^^^^^^^^^^^--

I think this must be a typo. fw_printenv should have no effect. I
guess you mean fw_setenv (as in the Subject) ?

> Linux, fw_* still work.

Obviously the flash locking is the important thing here. Probably your
flashes weren't locked before, but are locked after running fw_setenv.

> When using erase, this is the result:
> 
> => protect off fe040000 fe05ffff
> Un-Protected 1 sectors
> => erase fe040000 fe05ffff
> 
> Flash erase error at address fe040000
> Block Erase Error.
> Block locked.
^^^^^^^^^^^^^^^

That's a pretty clear error message here.

> Errors are similar when using saveenv:
> 
> => saveenv
> Saving Environment to Flash...
> Un-Protected 1 sectors
> Erasing Flash...
> Flash erase error at address fe040000
> Block Erase Error.
> Block locked.
^^^^^^^^^^^^^^^

Again, a clear error message.

> However, I have no clue on how CFI works, so my ability to debug it
> further stops here. A possible reason I can think of is that the ioctl
> calls in fw_setenv are somehow messing up the Flash status.

The problem is that  the  MPC8323ERDB  board  has  flash  chips  that
support  hardware  flash  protection  (locking), but the board config
file does  not  select  the  CFG_FLASH_PROTECTION  option.  Therefore
U-Boot  will  not  make  any  attempts  to  lock  or unlock any flash
sectors.


I think two things should be done:

a) Kim, I think it would make sense to  add  CFG_FLASH_PROTECTION  to
   all  board  configurations  that use lockable flash chips. I would
   even consider this a bug fix and pull it into the upcoming 2008-10
   release, if you want.

b) Guennadi, I think it would be  nice,  user-friendly  behaviour  if
   fw_setenv  did  not unconditional locking, but would instead leave
   the flash in the same state it found it. Do you think it would  be
   possible  to  test  the state first, and then perform the unlock /
   lock operations only when the flash sectors  were  already  locked
   when fw_setenv was called?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Brain: an apparatus with which we think we think.    - Ambrose Bierce