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

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

[Grant Erickson]

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

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

[Wolfgang Denk]

Dear Grant Erickson,

In message <C974475E.23E4D%gerickson@nuovations.com> you wrote:
> 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:

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

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

[Grant Erickson]

On 2/6/11 12:41 PM, Grant Erickson wrote:
> 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 [ELIDED]:

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

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

[Alexander Holler]

Am 06.02.2011 22:33, schrieb Grant Erickson:

>      // Preincrement random data.
>
>      ++env_new.flags; /* increase the serial */
>
> Unfortunately, preincrementing random data won't replicate the behavior of

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.

> 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.

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

Regards,

Alexander