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