Re: [U-Boot-Users] I2C address above 0x7f
In message 0212041401260G.06014@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
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@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
In message 0212041616150I.06014@pcj86.jena.mazet.de you wrote:
Hurray, it seems to work. Thank you for all the support. I've borrowed the LWMON configuration, thank you Wolfgang.
:-) You're welcome.
A quick guidance how to write to the lowest and the highest address of my FRAM would be really great.
Read: => eeprom read 100000 0 <size_of_fram_in_bytex_in_hex> => md 100000
Write: => eeprom write 100000 0 <size_of_fram_in_bytex_in_hex>
Best regards,
Wolfgang Denk
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@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@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@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@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. ***********************************************************************
participants (3)
-
Jerry Van Baren -
Stephan Linz -
Wolfgang Denk