From: Mike Frysinger <vapier@gentoo.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] incremental environment updating
Date: Mon, 13 Apr 2009 06:34:48 -0400 [thread overview]
Message-ID: <200904130634.49617.vapier@gentoo.org> (raw)
In-Reply-To: <20090413101524.27E4083420E8@gemini.denx.de>
On Monday 13 April 2009 06:15:24 Wolfgang Denk wrote:
> In message Mike wrote:
> > currently the env code will erase the entire env storage before writing
> > back out the current env, even if the env storage has enough empty space
> > to store the current env. for example, if CONFIG_ENV_SIZE is declared as
> > 0x2000 but the current env only takes up ~0x300 bytes, the whole 0x2000
> > is erased and then the ~0x300 gets written out. seems like we can get a
> > pretty good return for fairly low effort if we appended env updates
> > rather than erasing/writing every time ? it'd certainly be faster.
> > while systems with a dedicated sector this isnt so bad, but for people
> > who have to embed the env in the middle of a large sector, this would be
> > much faster most of the time.
> >
> > has there been previous discussion along these lines that i havent seen ?
>
> This hasn't been discussed before. Interesting idea. However, I fail
> to see how this could be implemented without changing the environment
> format?
that depends on how you want the compatibility to go. being able to read old
environments by newer u-boots is reasonable, but i dont think having old u-
boots read newer environments makes realistic sense ?
in terms of actual changes, i had a couple of ideas ... the current env format
is: <crc><env><NUL>[undefined]. so if we logically extend the format where
[undefined] is <crc><env><NUL>[...], then all existing env storage would be
automatically imported. considering most env storage out there uses a bit
value of "0" to mean programmed and "1' to mean unprogrammed, it should be
pretty easy to quickly detect where the appended envs stop.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090413/3a87fa60/attachment.pgp
next prev parent reply other threads:[~2009-04-13 10:34 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-13 10:09 [U-Boot] incremental environment updating Mike Frysinger
2009-04-13 10:15 ` Wolfgang Denk
2009-04-13 10:34 ` Mike Frysinger [this message]
2009-04-13 12:12 ` Jerry Van Baren
2009-04-13 12:26 ` Wolfgang Denk
2009-04-13 12:53 ` Jerry Van Baren
2009-04-13 13:06 ` Wolfgang Denk
2009-04-13 13:57 ` Jerry Van Baren
2009-04-13 12:34 ` Mike Frysinger
2009-04-13 13:04 ` Wolfgang Denk
2009-04-13 13:11 ` Jerry Van Baren
2009-04-13 13:30 ` Mike Frysinger
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=200904130634.49617.vapier@gentoo.org \
--to=vapier@gentoo.org \
--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.