I2C isn't exposed anywhere except on the board, although it's relatively straightforward to get to.  You can either solder directly to R900 and R901, or you can short them and pick them up on pins 5 and 6 of the unpopulated chumbilical connector.  We did that during development when hooking up a logic analyzer, and it was really useful.

I2C addresses are left-aligned, so the bottom bit should always be 0.  The FM radio is on 0x56, and I believe there are a few eeproms on 0xA2 (cryptoprocessor eeprom), 0xA8, 0xAA, 0xAC, and 0xAE (all four are DCID eeprom).  Everything else should be available.

I think acceld_i2c.c in the acceld source is the easiest thing to steal code from if you're looking for basic i2c examples.  You can pretty much lift I2C_Read_nbyte() and I2C_Write_nbyte() without needing to change anything.

No, I mean bridge the two pads on R900, and bridge the two pads on R901.  These are basically unpopulated to prevent people from accidentally connecting a chumby classic daughtercard connector (which is almost but not quite entirely like the chumby one daughtercard connector) and sending 12V down a 5V line (and hooking up I2S to an I2C bus).

But yes, if you bridge R900 and bridge R901, chumbilical connector pins 5 and 6 will become live.

From the diagram, it looks like pin 5 is I2C_SDA (which goes through R900), and pin 6 is I2C_SCL (which goes through R901).

There's also the accelerometer on 0x3A.

0x1d would need to be referred to as 0x3a on the chumby one, which as inio pointed out is where the accelerometer lives.  You're seeing the periodic poll being done by acceld.  The datasheet is available from Freescale.

I2C addressing is weird, because it's a 7-bit address, and you can treat it like an 8-bit field with the lower bit being the read/write bit.  The chumby kernel does this, meaning that for some datasheets (such as the Freescale ones), you have to left-shift the address of 0x1d to read 0x3a.  Many datasheets forego giving a hexadecimal address and instead just give a bit pattern.

We actually use the read/write bit when talking to the FM radio, because it requires this really weird I2C packet where you set the "read" bit while writing the address packet.  That special case is achieved I think by sending a packet with the I2C_M_RD flag set, but also with the write bit set on the address.

Anyway, that does look like a valid packet trace, and it will probably go away if you kill acceld.

no I couldn't get it to work.  I wasn't even trying to hook up BlinkMs that that point, but simply watching the i2c with a logic analyzer.  I couldn't seem to get my own messages to come out so I gave up and went the custom route with a Fez Domino.  Not as cool as if it would have been hacked into a Chumby but it still works.  Have you been able to send your own i2c messages?