From mboxrd@z Thu Jan  1 00:00:00 1970
From: Richard Retanubun <RichardRetanubun@RuggedCom.com>
Date: Fri, 17 Apr 2009 10:39:06 -0400
Subject: [U-Boot] recommended place to identify hardware using
 i2c-eeprom data.
In-Reply-To: <200904170622.11288.sr@denx.de>
References: <49E7AAA4.5010007@RuggedCom.com> <200904170622.11288.sr@denx.de>
Message-ID: <49E8948A.3040707@RuggedCom.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Stefan Roese wrote:
> I suggest you take a look at "gd->board_type" (enabled via 
> CONFIG_BOARD_TYPES). This could be what you are looking for.

Neat! Thanks for the tip. Unfortunately my "board_type" does not fit inside an unsigned long.

For others on the ML, an example of using i2c eeprom with gd->board_type can be found in
board/cm5200/cm5200.c:checkboard()


Timur: Thanks for responding, I think I found a workaround for this.

I find that if I pre-create the environment variable in the board header file

e.g. #define CONFIG_EXTRA_ENV_SETTINGS "partnum=uninitialized_partnumber\0"

Then, setenv("partnum", "12-34-5678") called from board_early_init_r ("12-34-5678" obtained from i2c-eeprom) works.

Looking at _do_setenv in common/cmd_nvedit.c I think there may be something I'm violating by having it create/append
a new environment variable that does not exist before. (I know not overflowing: Environment size: 862/8188 bytes)
Not sure what the cause is at the moment.

Thanks for your time,

- Richard Retanubun