[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