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 ?

From Jerry Van Baren vanbaren_gerald@si.com on Wed, 23 Jan 2002:

Note that I added a ".1" (default) or ".2" modifier to the chip internal address (offset). This allows you to use one byte addresses or two byte addresses in the same system and without the _X mess.

----------

Examples:

Dumping 256 bytes from the SPD on a DIMM:

=> imd 57 0 100 0000: 12 00 00 00 00 00 00 00 00 00 00 11 00 00 00 22 ..............." 0010: 00 00 00 05 00 00 00 06 00 00 00 07 00 00 00 08 ................ 0020: 00 00 00 09 00 00 00 00 00 00 00 01 00 00 00 02 ................ 0030: 00 00 00 03 00 00 00 04 00 00 00 05 00 00 00 06 ................ 0040: 00 00 00 07 00 00 00 08 00 00 00 09 00 00 00 00 ................ 0050: 00 00 00 01 00 00 00 02 00 00 00 03 00 00 00 04 ................ 0060: 00 00 00 05 00 00 00 06 00 00 00 07 00 00 00 08 ................ 0070: 00 00 00 09 00 00 00 00 ff ff ff ff 00 00 00 01 ................ 0080: 00 00 00 02 00 00 00 03 00 00 00 04 00 00 00 05 ................ 0090: 00 00 00 06 00 00 00 07 00 00 00 08 00 00 00 09 ................ 00a0: 00 00 00 00 00 00 00 01 00 00 00 02 00 00 00 03 ................ 00b0: 00 00 00 04 00 00 00 05 00 00 00 06 00 00 00 07 ................ 00c0: 00 00 00 08 00 00 00 09 00 00 00 00 00 00 00 01 ................ 00d0: 00 00 00 02 00 00 00 03 00 00 00 04 00 00 00 05 ................ 00e0: 00 00 00 06 00 00 00 07 00 00 00 08 00 00 00 09 ................ 00f0: 00 00 00 00 00 00 00 01 00 00 00 02 00 00 00 03 ................

Changing a few bytes...

=> imm 80 Usage: imm - i2c memory modify (auto-incrementing)

=> imm 50 80 00000080: ff ? 12 00000081: ff ? 34 00000082: ff ? 56 00000083: ff ? 78 00000084: ff ? .

Dumping byte data:

imd.b e 81 e imd.b f 81 e imd.b 11 81 5

Old emails that might help...

To: ppcboot-users@lists.sourceforge.net From: Jerry Van Baren vanbaren_gerald@si.com Date: Wed, 23 Jan 2002 07:07:50 -0500

Good morning everybody,

This message is being sent in two parts to (hopefully) squeeze it under the 40K limit of the list server. I sent it yesterday in one part: the moderator (Wolfgang?) has not released the oversize message. Wolfgang is out of town and I'm impatient :-/.

----------------------------------------------------------------

Attached are some I2C patches that I've been working on. This set of patches does two things:

1) Rationalize the i2c interface for the 8260, 8xx, and 4xx CPUs: all of them get the same interface, eliminating the horrible #ifdef cancer that was growing.

2) Create a generic soft_i2c.c in the /common directory that is configured by changing #defines in the board configuration file. This replaces the soft_i2c.c in the cpu/8xx and cpu/8260 subdirectories.

3) Creates a new set of commands that imitate the regular memory peek/poke commands: imd for I2C memory display, imm for I2C mem mod, imw, etc. IMHO this alone is worth the price of admission. The syntax of the commands is: imd {i2c_chip} {addr}{.1, .2} {len} imw {i2c_chip} {addr}{.1, .2} {data} [{count}] icrc32 {i2c_chip} {addr}{.1, .2} {count} imm {i2c_chip} {addr}{.1, .2} inm {i2c_chip} {addr}{.1, .2} iloop {i2c_chip} {addr}{.1, .2} [{length}] [{delay}] Note that I added a ".1" (default) or ".2" modifier to the chip internal address (offset). This allows you to use one byte addresses or two byte addresses in the same system and without the _X mess.

4) New I2C commands: iprobe {addr} - goes through all chip addresses, prints all chips that respond isdram {i2c_chip} - Dumps the SDRAM SPD memory in human readable form

5) Improved the hardware 8260 I2C driver, especially with respect to timeouts. The hardware 8xx I2C driver could probably benefit from this as well, but I don't have a 8xx system to test on.

6) The imd & friends really obsolete cmd_eeprom.c, but I patched it over for backwards compatibility. I thought about putting a pester printf in it for the I2C branch ("This command is obsolete, please use imd/imm/imw, etc.\n") but didn't. Discussion and advice on how to handle command obsolescence would be welcome.

--------

This should be a clean patch against the latest PPCBoot, although I did not test that.

What I need help with is: 1) Testing the 8xx code (should be OK, but it is untested) 2) Testing the 4xx code (a little shakier, I'm less familiar with the 4xx) 3) Figure out what to do with the ICU862 with its Xicor X40430 I2C EEPROM: I downloaded the X40430 spec sheet but had problems reconciling the spec sheet to the code and ended up not doing anything with the memory lock/unlock code. This is currently BROKEN.

Notes: ------ Attachment: ppcboot/common/soft_i2c.c.gz - new file.

Part 2 attachment: patch.gz - patches against latest PPCBoot.

* The "soft_i2c.c" routines under the 8xx and 8260 cpu subdirectories are made obsolete by the new one in common. The new one is generic, configured by #defines in the board configuration.

gvb

To: Wolfgang Denk wd@denx.de, andrew may acmay@acmay.homeip.net From: Jerry Van Baren vanbaren_gerald@si.com Date: Wed, 30 Jan 2002 07:38:11 -0500

Attached are my latest i2c patches. I added in some of Andrews suggestions, primarily the [.bwl] attribute on the imm and inm commands. I also removed the gratuitous calls to i2c_init() in some of the i2c read (transfer) routines. Hopefully start up routines call i2c_init() properly before trying to read i2c -- if they don't, I would consider that to be a bug and should be fixed.

I did _not_ include Andrew's patch reading the environment variable to determine the I2C speed.

In the tarball, I included common/soft_i2c.c which is new and a clean copy of common/cmd_i2c.c which is totally different from the original (current PPCBoot version), making the patch file for it pretty tough to read :-).

gvb

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