[U-Boot-Users] I2C address above 0x7f

[Stephan Linz]

Hurray, it seems to work. Thank you for all the support. I've borrowed the 
LWMON configuration, thank you Wolfgang.

But now I've another problem (sorry :-). Is there a more extensive syntax 
description of all the I2C commands than the quick help messages. I don't 
understand the meanings of "dotted address numbers" [.0, .1, .2] and "numbers 
of objects" [# of objects]. What is happen if I leave out this fields or in 
which case I have to use it ?

A quick guidance how to write to the lowest and the highest address of my 
FRAM would be really great.


Thanks for all,
Stephan Linz

Am Mittwoch,  4. Dezember 2002 14:22 schrieb Wolfgang Denk:
> In message <0212041401260G.06014 at pcj86.jena.mazet.de> you wrote:
> > > > Hm, what's the meaning of CFG_I2C_SLAVE ? I've expected it's the
> > > > highes valid slave address, isn't it ?
> > >
> > > No, what makes you think so? It's the value that gets programmed into
> > > the MPC8xx I2C controller's I2ADD register. See the Users Manual  for
> > > details.
> > >
> > > The subject suggests you ntended to ask something different?
> >
> > Oops, I've forgot to ask. Now, at my TQ there is a so named FRAM I2C
> > brick connected to I2CSDA (PB27) and I2CSCL (PB26). The FRAM has two
> > different addresses both above 0x7F, 0xAE for write access and 0xAF for
> > read access.
>
> No. The FRAM has just one address: 0x57. The first octet sent on  the
> I2C  bus  contains  the 7 address bits plus a read/write bit. The I2C
> interface as used in U-Boot does NOT consider the  read/write  bit  a
> part of the address - we use the plain 7 bit device address.
>
> > The FRAM is similar to E2PROM bricks like AT24C64.
>
> Yes, I know. You can find a configuration featuring a  FM24CL64  FRAM
> in the LWMON config file ("include/configs/lwmon.h").
>
> > My question: Is there an read/write abstraction layer inside of the I2C
> > stuff of PPCBoot ? I don't know if I should use the bit shifted address
> > 0x57
>
> You mean something like i2c_read() and i2c_write()? Of  course  there
> is.  And  there  is  also extensive command line support for I2C. Use
> "help".
>
> > instead of 0xAE for calling imd -- I think 0x57. However, upt to now I've
> > tried both addresses without success.
>
> You probably got the address length wrong. See the LWMON board for  a
> working example.
>
> > Ah, just now I see there is a nice tool to scan I2C devices (iprobe). Can
> > anybody give me an generic command line dump with iprobe in action? I've
> > ran iprobe but without any success. The only thing I see is:
> >
> > => iprobe
> > Valid chip addresses:
>
> Be careful. "iprobe" with the HW I2C code may  take  _very_  long  to
> complete.  If  you  don't need very fast bulk data transfers (100 kHz
> clock or more) you will find it  probably  much  simpler  to  use  SW
> (bitbanging) I2C instead.
>
> Here is what I get on a LWMON board:
>
> 	U-Boot 0.1.1 (Dec  4 2002 - 14:19:27)
>
> 	CPU:   PPC823EZTnnB2 at 66 MHz: 16 kB I-Cache 8 kB D-Cache
> 	Board: Litronic Monitor IV
> 	       Watchdog enabled
> 	I2C:   ready
> 	DRAM:  64 MB
> 	POST spr PASSED
> 	FLASH: 16 MB
> 	KEYBD: Version 1.2
> 	Net:   SCC ETHERNET
> 	POST cache PASSED
> 	POST i2c PASSED
> 	POST cpu PASSED
> 	POST ethernet PASSED
> 	POST spi PASSED
> 	POST usb PASSED
> 	PCMCIA:   No Card found
> 	Hit any key to stop autoboot:  0
> 	=> iprobe
> 	Valid chip addresses: 2E 51 52 53 55 56
> 	=>
>
> > I think iprobe has not found any valid chip. Is it so ?
>
> Seems so.
>
> Best regards,
>
> Wolfgang Denk

-- 

======================================================================
Stephan Linz
Software Engineer

MAZeT GmbH                   Email:   mailto:linz at mazet.de
Branche office Jena          Phone:   +49-3641-2809-55
Göschwitzer Straße 32        Fax  :   +49-3641-2809-12
D-07745 JENA
Germany

Visit our web-pages: http://www.MAZeT.de
======================================================================