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

Jerry Van Baren vanbaren_gerald at si.com
Wed Dec 4 16:56:38 CET 2002


In The Beginning, there were only single byte I2C addresses.  Then people 
started making chips with more than 256 data locations and two hack 
solutions came up.  The first hack solution was to spill the data address 
into the chip address.  The second hack address was to add another byte to 
the internal address field, allowing 64K bytes.  In addition, some people 
made I2C devices with only one register and decided that saving a byte in 
the transfer operation was more important than staying compatible with 
Historical Devices.

The .0, .1, .2 address modifiers deal with the internal address length 
(i.e. the offset inside the chip).  Some I2C devices have only one register 
and thus have no internal address -- use 0.0 for the address field for 
these chips.  The "in the beginning" chips have one byte internal address 
-- this is the default or you can make it obvious by using 12.1 for offset 
12.  Some chips have one byte internal address but have some address bits 
spill over into the chip address, making it (to my logical mind) "look 
like" multiple 256byte chips -- this is just a variant of the x.1 
address.  Other chips have two byte internal addresses -- use 12.2 for 
offset 0012.

x.0
<chip-addr><data>

x.1
<chip-addr><x><data>

x.2
<chip-addr><x-high><x-low><data>  (I think "x" is big endian)

You MUST know what device you are talking to because there is no way of 
knowing the address length a priori.  Using the wrong form is really bad 
because you won't be addressing what you think you are addressing.

gvb


At 04:16 PM 12/4/2002 +0100, Stephan Linz wrote:

>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
>======================================================================
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Microsoft Visual Studio.NET
>comprehensive development tool, built to increase your
>productivity. Try a free online hosted session at:
>http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en
>_______________________________________________
>U-Boot-Users mailing list
>U-Boot-Users at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/u-boot-users



**********************************************************************
This e-mail and any files transmitted with it are confidential and may
be legally privileged or otherwise exempt from disclosure under
applicable law. This e-mail and its files are intended solely for
the individual or entity to whom they are addressed and their content
is the property of Smiths Aerospace.  If you are not the intended
recipient, please do not read, copy, use or disclose this communication.
If you have received this e-mail in error please notify the e-mail 
administrator at postmaster at si.com and then delete this e-mail, its
files and any copies.

This footnote also confirms that this e-mail message has been scanned
for the presence of known computer viruses.
***********************************************************************





More information about the U-Boot mailing list