[U-Boot-Users] U-boot code etiquette
wd at denx.de
Mon Jan 24 11:12:17 CET 2005
in message <1106558355.3698.47.camel at 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.
> 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
> 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.
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Why don't you have a Linux partition installed so you can be working
in a programmer-friendly environment instead of a keep-gates'-bank-
account-happy one? :-) -- Tom Christiansen
More information about the U-Boot