No subject

[<bogus@does.not.exist.com>]

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