From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Frysinger Date: Mon, 13 Apr 2009 06:34:48 -0400 Subject: [U-Boot] incremental environment updating In-Reply-To: <20090413101524.27E4083420E8@gemini.denx.de> References: <200904130609.08060.vapier@gentoo.org> <20090413101524.27E4083420E8@gemini.denx.de> Message-ID: <200904130634.49617.vapier@gentoo.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.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: [undefined]. so if we logically extend the format where [undefined] is [...], 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