From: Grant Erickson <gerickson@nuovations.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] U-Boot 2010.12 Cannot Successfully Save Variables with Redundant NAND Environment
Date: Sun, 06 Feb 2011 13:33:48 -0800 [thread overview]
Message-ID: <C97453BC.23E58%gerickson@nuovations.com> (raw)
In-Reply-To: <C974475E.23E4D%gerickson@nuovations.com>
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
next prev parent reply other threads:[~2011-02-06 21:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-06 20:41 [U-Boot] U-Boot 2010.12 Cannot Successfully Save Variables with Redundant NAND Environment Grant Erickson
2011-02-06 21:19 ` Wolfgang Denk
2011-02-06 21:33 ` Grant Erickson [this message]
2011-02-07 10:28 ` Alexander Holler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=C97453BC.23E58%gerickson@nuovations.com \
--to=gerickson@nuovations.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.