[U-Boot-Users] U-boot code etiquette

[Wolfgang Denk]

Dear Neil,

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.

> 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

-- 
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