> 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(a)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(a)lists.sourceforge.net
From: Jerry Van Baren <vanbaren_gerald(a)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(a)denx.de>, andrew may <acmay(a)acmay.homeip.net>
From: Jerry Van Baren <vanbaren_gerald(a)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(a)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.
***********************************************************************
