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