[U-Boot] Boot based on I2C EEPROM value

[U-Boot] Boot based on I2C EEPROM value

[Canchivaram, Srivatsan]

Hello,

 

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?

 

Thank you,

Srivatsan

 

[U-Boot] Boot based on I2C EEPROM value

[Detlev Zundel]

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

-- 
An elephant is a mouse with an operating system.
                                        -- Donald Knuth
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] Boot based on I2C EEPROM value

[Detlev Zundel]

Hi again,

> 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 ;)
 
In the meantime I found the "eeprom" command, which should allow you to
transfer the data into memory.  Still I believe the proposed
additions/removals to the "i2c" subsystem to be worthwhile.

Cheers
  Detlev

-- 
Microsoft gives you windows, Linux gives you the whole house.
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] Boot based on I2C EEPROM value

[Canchivaram, Srivatsan]

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 at denx.de] 
Sent: Thursday, February 18, 2010 7:53 AM
To: Canchivaram, Srivatsan
Cc: u-boot at 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

-- 
An elephant is a mouse with an operating system.
                                        -- Donald Knuth
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] Boot based on I2C EEPROM value

[Wolfgang Denk]

Dear "Canchivaram, Srivatsan",

In message <E3B2C7C726B07C4FA70FFAED2C8A2E6ABFF08D@owa.usmonolithics.com> you wrote:
> 
> 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. 

Argh...

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

This is a bug still present in current code. evalexp() in
"common/cmd_itest.c" does not pay atention to any ".b" or ".w"
modifiers.

This needs to be fixed. Patches are welcome!

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
panic: can't find /