The invalidation of the old environment instance did not work for flashes supporting hardware locking. Now we unlock/lock around this update also.

Signed-off-by: Detlev Zundel dzu@denx.de --- tools/env/fw_env.c | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-)

Please note that this solution which does not do any checking of the return codes is inline with the locking/unlocking in other parts of the code.

For a sensible return code checking we would need to know if locking is supported and wanted. As I currently do not see that the MTD layer exposes the first information I fail to see an automatic way of doing this.

Using a command line option to request locking/unlocking looks like agood way to handle this. Locking/unlocking would the need to be explicitely requested by the user. When the user does not do this on chips needing it, a read-only error message would result.

What do other people think about this?

diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c index 04f3bf0..8ff7052 100644 --- a/tools/env/fw_env.c +++ b/tools/env/fw_env.c @@ -1,5 +1,5 @@ /* - * (C) Copyright 2000-2008 + * (C) Copyright 2000-2010 * Wolfgang Denk, DENX Software Engineering, wd@denx.de. * * (C) Copyright 2008 @@ -899,7 +899,10 @@ static int flash_write_buf (int dev, int fd, void *buf, size_t count, static int flash_flag_obsolete (int dev, int fd, off_t offset) { int rc; + struct erase_info_user erase;

+ erase.start = DEVOFFSET (dev); + erase.length = DEVESIZE (dev); /* This relies on the fact, that obsolete_flag == 0 */ rc = lseek (fd, offset, SEEK_SET); if (rc < 0) { @@ -907,7 +910,9 @@ static int flash_flag_obsolete (int dev, int fd, off_t offset) DEVNAME (dev)); return rc; } + ioctl (fd, MEMUNLOCK, &erase); rc = write (fd, &obsolete_flag, sizeof (obsolete_flag)); + ioctl (fd, MEMLOCK, &erase); if (rc < 0) perror ("Could not set obsolete flag");