Dear Neil,
in message 1106558355.3698.47.camel@daroca you wrote:
The board has a limited EEPROM storage area and it has been decided that U-boot environment variables are to be stored in EEPROM.
Don't do that. Using an EEPROM for the environment has several serious disadvantages (slow boot speed, risk of losing the environment). I strongly recommend to use flash, porobably even redundand flash sectors.
U-boot uses quite a large amount of environment variable space,
This depends on what you do with it. If you want, you can do with just 128 bytes or so. But then a lot of the power of U-Boot results from clever use of the environment, so you have to decide if you really want to castrate U-Boot.
in fact the default size for the AM91RM9200DK CFG_ENV_SIZE is 0x2000
The default isto use flash, too, where this is not a problem at all.
(8kbytes). So all my EEPROM disappears to U-boot leaving non for Linux.
Who says that Linux and U-Boot cannot share the same storage?
BUT, cetain variables such as the board IP address need to be common to both Linux and U-boot. So if the board IP address is changed by the OS or by Linux, the change needs to be visible to the other.
Right. So share the environment.
SOLUTION: To divide the EEPROM into a psuedo-file structure. We have data
What a overkill.
structures of varying lengths and types to pack more data into the
KISS: we already have that. We have name=value tuples, encoded in plain text with variable length. What else do you need?
EEPROM. We need to support a variety of OSes on the board and will have several OS-specific data structures.
Please provide an example that cannot be encoded in the way mentioned above.
One data structure would be reserved for U-boot, length 2kBytes,
However, common values such as IP address will be stored in this psuedo-file structure.
Doesn't make sense. Don't duplicate the same data if you can avoid it.
When U-boot reads the environment variables, it needs to check in two places in EEPROM:
Such a modifcation is avoidable.
o I don't want to make board-specific changes in common code areas. I can see my proposal affecting cmd_nvedit.c. This code does not have pre-processing for multiple board-types and so architecturaly it feels wrong.
I don't see what sort of board specific preprocessing might be needed. Maube you can elucidate.
o I need to hook into functions getenv() and setenv(). I will read a table of constant strings and compare with the environment variable which is being sought and then parse it appropriately.
Don't do that. Don't duplicate function, don't duplicate code, don't duplicate data. Use one set of data.
I don't want to spend lots of time making theses suggested changes to have it rejected for inclusion into the mainline code. Will it be accepted or is it just too far outside of the way U-boot evolves? Is there a better solution?
If you have the choice, then provide access functions to the U-Boot environment for your other components that need to access (read and write) configuration data. For Linux this is trivial - see the code in tools/env as example. If you really *must* use a different storage format, then use this for everything and provide a complete new access method for U-Boot.
Best regards,
Wolfgang Denk