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

Wolfgang Denk
2008-09-16T09:04:50Z

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