U-Boot 2010.12 Cannot Successfully Save Variables with Redundant NAND Environment

I recently updated my TI AM37x EVM from U-Boot 2010.09 to 2010.12 and noticed that, in doing so, saveenv / env save no longer seems to work. The following example demonstrates:

=> version

U-Boot 2010.12 (Feb 04 2011 - 16:12:51)
=> env print foo
## Error: "foo" not defined
=> env set foo bar
=> env save
Saving Environment to NAND...
Erasing redundant NAND...
Erasing at 0x3a0000 -- 100% complete.
Writing to redundant NAND... done
=> env print foo
foo=bar
=> reset
resetting ...

...

Hit any key to stop autoboot: 0
=> env print foo
## Error: "foo" not defined

However, I can successfully read and write NAND, for example, updating u-boot.

Anyone else noticed this on OMAP-based boards? With NAND? With NOR?

Running a few more experiments, I find that I can entirely whack the environment, set a variable once thereafter, but never again:

=> printenv resetenv
resetenv=nand erase 0x340000 0x1000 && nand erase 0x3a0000 0x1000 => run resetenv

NAND erase: device 0 offset 0x340000, size 0x1000 Erasing at 0x340000 -- 100% complete.
OK

NAND erase: device 0 offset 0x3a0000, size 0x1000 Erasing at 0x3a0000 -- 100% complete.
OK
=> reset
resetting ...

...
*** Warning - bad CRC, using default environment
...
Hit any key to stop autoboot: 0

=> saveenv
Saving Environment to NAND...
Erasing redundant NAND...
Erasing at 0x3a0000 -- 100% complete.
Writing to redundant NAND... done
=> setenv foo bar
=> printenv foo
foo=bar
=> saveenv
Saving Environment to NAND...
Erasing NAND...
Erasing at 0x340000 -- 100% complete.
Writing to NAND... done
=> printenv foo
foo=bar
=> reset
resetting ...

...
Hit any key to stop autoboot: 0
=> printenv foo
foo=bar
=> env delete foo
Not implemented yet
=> setenv foo
=> printenv foo
## Error: "foo" not defined
=> saveenv
Saving Environment to NAND...
Erasing redundant NAND...
Erasing at 0x3a0000 -- 100% complete.
Writing to redundant NAND... done
=> printenv foo
## Error: "foo" not defined
=> reset
resetting ...

...
Hit any key to stop autoboot: 0
=> printenv foo
foo=bar

Principal
Nuovations

998 Alpine Terrace Suite 3
Sunnyvale, CA 94086-2469
US

T +1-408-749-0495
F +1-205-449-0495
M +1-408-489-5710

gerickson at nuovations.com
http://www.nuovations.com/


Best,

Grant

Dear Grant Erickson,

See git commit
920a5dd 2011-02-02 16:14:08 -0600 NAND: Fix saving of redundand environment

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
Heavier than air flying machines are impossible.
                    -- Lord Kelvin, President, Royal Society, c. 1895

I subsequently found the following patch and commit:

    http://www.mail-archive.com/u-boot at lists.denx.de/msg46834.html

http://git.denx.de/?p=u-boot.git;a=commitdiff;h=920a5dd2325438a82b6ac8102c5a
5e0c43276fd;hp=42d44f631c4e8e5359775bdc098f2fffde4e5c05

However, it's not clear how this patch can reasonably work outside of random chance:

    // Allocate a new environment on the stack. The environment structure is
    // whatever random data is already on the stack.

    env_t    env_new;

    ...
    
    // At this point, the data field will be initialized; however, crc and
    // flags are still random data.

    res = (char *)&env_new.data;
    len = hexport_r(&env_htab, '\0', &res, ENV_SIZE);

    // The crc field is now set.

    env_new.crc   = crc32(0, env_new.data, ENV_SIZE);

    // Preincrement random data.

    ++env_new.flags; /* increase the serial */

Unfortunately, preincrementing random data won't replicate the behavior of 2010.09, where the flags field was referenced through a global env_ptr such that flag manipulation was handled (more) coherently as the environment was read and written.

Best,

Grant

Am 06.02.2011 22:33, schrieb Grant Erickson:

Wheter using preincrement or postinecrement isn't of interest here, using preincrement is just a good habit which will avoid temporaries when incrementing complex types in c++. Using always postincrement is a bad habit. Just let us call that increment. ;)

But for the random it looks like you are true and I haven't had examined the code correctly. I had the believe (and examine the newly saved nand here showed that too), that env_new.flags contains the old serial. Must have been luck that I've had always the old serial there.

Anyway, increasing the serial there is the right way, it's just that flags should already contain the old serial.

Sorry, I don't know how that worked before. I never have come in touch with that before.

Regards,

Alexander