Hi Detlev,

Thanks for the response. I was able to use the 'eeprom' command to read from the I2C device and copy to memory. With the itest.b command, the comparison always resulted in false even when the condition itself was true i.e.

mw.b 0x200000 1 if itest.b *0x200000 -eq 1 This would result as false.

Through debug of the itest code, I found out the reason to be endianness. My target is the PowerPC. Therefore, the itest.b's read of address *200000 always returned Byte 3 instead of Byte 0.

I am able to workaround this issue by forcing the itest function to read the correct byte. Do you know if there is any patch available for Big Endian in any of the recent versions? Or is this something that needs to be added to the source code? I am using version 1.3.3.

Thanks, Srivatsan

-----Original Message----- From: Detlev Zundel [mailto:dzu@denx.de] Sent: Thursday, February 18, 2010 7:53 AM To: Canchivaram, Srivatsan Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Boot based on I2C EEPROM value

Hi Srivatsan,

The modem I am working on contains two software images in flash

memory:

1. Default image
2. Backup image

Typically, the Default image will get loaded. If the application software determines that the Default image is causing issues, it will set a value of 1 in an address in the I2C EEPROM and reboot the board.

So, U-boot will need to read this EEPROM value and determine whether

it

should boot the Default or Backup image i.e.

if EEPROM data == 0

        bootm $default_addr

else

        bootm $backup_addr

How can I read and parse the EEPROM data from U-boot?

U-boot has the facility to read the I2C device from the command line

as

in (EEPROM dev num = 50, address = 2, count = 1):

=> i2c md 50 2 1

0002: 01 .

How do I parse this from within a U-boot command that can be run at boot-up?

Ah, this is interesting. I was about to tell you to use the "standard" i2c commands to transfer data from the chip into memory and then use the hush shell and the standard "itest *addr = 1" facility. Unfortunately, the "i2c" subsystem does not implement such functionality. So currently I would advise to implement such "read" and "write" operations to transfer to/from memory.

With this addition, you could even propose a patch to remove crc32 subcommand from i2c as this can then be done in two steps. So maybe you can even get away with this addition without adding anything to the binary size of U-Boot ;)

Then itest would work like this:

=> md.b 0x200000 1 00200000: 00 . => if itest *0x200000 -eq 0 ; then echo zero;else echo not zero; fi zero => mw.b 0x200000 1 1 => md.b 0x200000 1 00200000: 01 . => if itest *0x200000 -eq 0 ; then echo zero;else echo not zero; fi not zero =>

Cheers Detlev