[U-Boot] recommended place to identify hardware using i2c-eeprom data.

[U-Boot] recommended place to identify hardware using i2c-eeprom data.

[Richard Retanubun]

Hi,

I am working on an MP8360E powerpc platform using uboot 2009.03.

our boards contain an i2c eeprom that identify the type of board it is.

sing this information I would like to have a universal u-boot binary that can read the eeprom
and use the data to influence how the rest of the boot proceeds. (e.g setup mac addresses, initialize GPIOs, call setenv to initialize other params).

I've tried extracting the information at board_early_init_r (because I need to initialize MAC address later using this information also)
and store the information using setenv("partnum" "extracted_board_id");

However, the resulting printenv after boot only contains "pa" with no data, so obviously I am doing something wrong (calling setenv too early?)

Is there a recommended way/examples of doing this?

I've thought about using the global data, but don't know if there is a struct member that is arch-independent.
Thanks for everyone's time.

- Richard Retanubun

[U-Boot] recommended place to identify hardware using i2c-eeprom data.

[Timur Tabi]

On Thu, Apr 16, 2009 at 5:01 PM, Richard Retanubun
<RichardRetanubun@ruggedcom.com> wrote:

> I've tried extracting the information at board_early_init_r (because I need to initialize MAC address later using this information also)
> and store the information using setenv("partnum" "extracted_board_id");
>
> However, the resulting printenv after boot only contains "pa" with no data, so obviously I am doing something wrong (calling setenv too early?)

Can you post some of your code?  Maybe there's a bug.

> Is there a recommended way/examples of doing this?

Depends on the kind of initialization you're trying to do.

-- 
Timur Tabi
Linux kernel developer at Freescale

[U-Boot] recommended place to identify hardware using i2c-eeprom data.

[Stefan Roese]

On Friday 17 April 2009, Richard Retanubun wrote:
> I've tried extracting the information at board_early_init_r (because I need
> to initialize MAC address later using this information also) and store the
> information using setenv("partnum" "extracted_board_id");
>
> However, the resulting printenv after boot only contains "pa" with no data,
> so obviously I am doing something wrong (calling setenv too early?)
>
> Is there a recommended way/examples of doing this?
>
> I've thought about using the global data, but don't know if there is a
> struct member that is arch-independent. Thanks for everyone's time.

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

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] recommended place to identify hardware using i2c-eeprom data.

[Richard Retanubun]

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