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

[Neil Bryan <nbryan@embebidos.com>]

Hello group,

I have a problem to solve which effects U-boot environment variable 
storage.  Before I submit changes to core U-boot code, I want to
find out from the group 'what is acceptable code to modify?'.

I am afraid that this description is quite long, but I do not know
how to describe it in very few words.

TARGET DESCRIPTION:
Based on the AT91RM9200 MCU from Atmel with 8kbytes of I2C EEPROM.
For my initial investigation I am using the AT91RM9200DK port of 
U-boot.

PROBLEM:
The board has a limited EEPROM storage area and it has been decided that
U-boot environment variables are to be stored in EEPROM.  

U-boot uses quite a large amount of environment variable space,
in fact the default size for the AM91RM9200DK CFG_ENV_SIZE is 0x2000
(8kbytes). So all my EEPROM disappears to U-boot leaving non for Linux.

I can reduce this by changing ./include/configs/at91rm9200dk.h 
CFG_ENV_SIZE to 0x800 (2kbytes).  U-boot builds, runs and all is well.

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.

SOLUTION:
To divide the EEPROM into a psuedo-file structure.  We have data 
structures of varying lengths and types to pack more data into the 
EEPROM.  We need to support a variety of OSes on the board and will 
have several OS-specific data structures.

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.

AFFECT ON U-BOOT:
When U-boot reads the environment variables, it needs to check in two
places in EEPROM:

1) The standard U-boot storage of NUL terminated strings, e.g.
bootdelay, bootargs, bootcmd, etc.

2) Our board specific data structure(s) which most likely will be 
baudrate, ethaddr, ethxaddr, ipaddr, serverip.

COMMENTS:

 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. 

 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.

So, people with lots of U-boot experience, I need your advice.
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?

Thanks for your time on this.

Regards,

Neil.