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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
