PICO 2.0 I2c commands via Nvidia 9800 gtx on Ubuntu 10.10

Gavin,

I have always used the i2c-tools on the BeagleBoard running Angstrom Linux. The bus3-i2c usage for the HDMI i2c is probably unique to the BeagleBoard architecture.

The i2c-tools for Linux exist for Ubuntu and other Linux distributions running on PC hardware. However, the motherboard (system) use of the buses varies from platform to platform. The i2c buses are usually used for configuration of the motherboard, such as setting the core voltages for the processor, etc. This means that it is dangerous to use the i2c commands without clear knowledge of the assignment and uses of the various i2c buses on the specific system.

See http://www.lm-sensors.org/wiki/I2CTools for more about the i2c-tools package.

Perhaps someone with experience using i2c-tools on PC architecture will add their insights.

Best regards,

Pascal

Gavin,

One more bit of information that may be helpful. The i2c channel running over the HDMI connector is there to allow the host to query the display device to determine its resolution capabilities. The Pico Kit utilizes the channel for this purpose, but after that query has been handled, that i2c channel is released to communicate with the DLPC100 DMD controller.

This means that PCs with HDMI outputs should have the i2c bus on that port - to use for this purpose. But, which i2c bus is it? Also, since that bus is most likely on the video graphics chip, is it accessible via i2c-tools? I don't know - but would be very interested to learn from someone who does.

Best regards,

Pascal

Hi Pascal, thanks for the reply.   I don't currently have a beagleboard, but do have an ardunio, but until a breakout board arrives in the post for the microscopic flat cable which will allow me experiment with the i2c signals, I thought I'd have a shot at communications via the i2c port on the graphics card.

I have a dual boot PC with Win 7 and Ubuntu 10.10 and noticed in the doco for Ubuntu that it has full support for i2c-tools which I installed.

Also, if you read this ftp://download.nvidia.com/XFree86/Linux-x86/256.35/README/i2c.html   it detauils the I2c commands available via the Nvidia linux drivers which I installed.

The other reason I wish to be able to use the Graphic card for the I2C, is software which I have written to send the 'colorspace multiplexed' images to the projector is all written in processing , (processing.org) , which has been an absoultely excellent framework for developing a utility for doing realtime graphics for the pico 2.0 . The software I've written will (theoretically when I manage to get the Pico in the correct mode) allow me to render any 1440 fps animation I choose, in realtime, and allow me to create custom patterns, animations etc, and if i can get the i2c commands working, then I can create a GUI in the program to change all the modes using on screen buttons etc.

So, anyway, I installed the i2c-tools package, and ran the i2cdetect -l command and I get 3 lines (can't rememeber the exact syntax, as am at work now on differnent PC), but basically the 3 lines returned each mention the Nvidia i2c port, but theres nothing to really tell me what those refer to.

I'm struggling to find any examples on the web of people using i2c tools to send commands to the Pico 2.0 so any step by step guide would be great.

many thanks from the bleeding edge of technological discovery

Gav

Gavin,

Well, I hope you don't have to bleed too much.

If you can get on top of the Nvidia Linux driver i2c commands, that will be really good to have. If you can talk to that port, you should be able to send and receive commands from the Pico. I'm very interested in what you learn. Keep me posted.

Best regards,

Pascal

Hi Pascal, I spent 20 mins last night messing with the i2c-tools commands .

What was interesting is that the output from the sensors-detect command did not mention the Maxim MAX6650/MAX6651 chip when the pico was turned off, but when I turned the PJ on (plugged into the 2nd DVI port on the gfx card) , that chip was detected.  Does that belong to the Pico2? 

Here is the full output from the sensors-detect command. Can you confirn any of the i2c chips being detected belong to the Pico?

cheers

Gav

root@gav-EX58-UD4P:~# sensors-detect
# sensors-detect revision 5818 (2010-01-18 17:22:07 +0100)
# System: Gigabyte Technology Co., Ltd. EX58-UD4P

This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.

Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no): no

Some Super I/O chips contain embedded sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no): no

Some systems (mainly servers) implement IPMI, a set of common interfaces
through which system health data may be retrieved, amongst other things.
We first try to get the information from SMBIOS. If we don't find it
there, we have to read from arbitrary I/O ports to probe for such
interfaces. This is normally safe. Do you want to scan for IPMI
interfaces? (YES/no): no

Some hardware monitoring chips are accessible through the ISA I/O ports.
We have to write to arbitrary I/O ports to probe them. This is usually
safe though. Yes, you do have ISA I/O ports even if you do not have any
ISA slots! Do you want to scan the ISA I/O ports? (YES/no): no

Lastly, we can probe the I2C/SMBus adapters for connected hardware
monitoring devices. This is the most risky part, and while it works
reasonably well on most systems, it has been reported to cause trouble
on some systems.
Do you want to probe the I2C/SMBus adapters now? (YES/no):
Using driver `i2c-i801' for device 0000:00:1f.3: Intel ICH10
Module i2c-i801 loaded successfully.

Next adapter: NVIDIA i2c adapter  (i2c-0)
Do you want to scan it? (YES/no/selectively):
Client found at address 0x50
Probing for `Analog Devices ADM1033'...                     No
Probing for `Analog Devices ADM1034'...                     No
Probing for `SPD EEPROM'...                                 No
Probing for `EDID EEPROM'...                                Yes
    (confidence 8, not a hardware monitoring chip)

Next adapter: NVIDIA i2c adapter  (i2c-1)
Do you want to scan it? (YES/no/selectively):
Client found at address 0x1a
Probing for `Analog Devices ADM1021'...                     No
Probing for `Analog Devices ADM1021A/ADM1023'...            No
Probing for `Maxim MAX1617'...                              No
Probing for `Maxim MAX1617A'...                             No
Probing for `Maxim MAX1668'...                              No
Probing for `Maxim MAX1805'...                              No
Probing for `Maxim MAX1989'...                              No
Probing for `Maxim MAX6655/MAX6656'...                      No
Probing for `TI THMC10'...                                  No
Probing for `National Semiconductor LM84'...                No
Probing for `Genesys Logic GL523SM'...                      No
Probing for `Onsemi MC1066'...                              No
Probing for `Maxim MAX1618'...                              No
Probing for `Maxim MAX1619'...                              No
Probing for `National Semiconductor LM82/LM83'...           No
Probing for `Maxim MAX6654/MAX6690'...                      No
Probing for `Maxim MAX6680/MAX6681'...                      No
Probing for `Texas Instruments AMC6821'...                  No
Client found at address 0x1b
Probing for `Maxim MAX6650/MAX6651'...                      Success!
    (confidence 2, driver `max6650')
Client found at address 0x50
Probing for `Analog Devices ADM1033'...                     No
Probing for `Analog Devices ADM1034'...                     No
Probing for `SPD EEPROM'...                                 No
Probing for `EDID EEPROM'...                                Yes
    (confidence 8, not a hardware monitoring chip)
Client found at address 0x51
Probing for `Analog Devices ADM1033'...                     No
Probing for `Analog Devices ADM1034'...                     No
Probing for `SPD EEPROM'...                                 No
Client found at address 0x52
Probing for `Analog Devices ADM1033'...                     No
Probing for `Analog Devices ADM1034'...                     No
Probing for `SPD EEPROM'...                                 No
Client found at address 0x53
Probing for `Analog Devices ADM1033'...                     No
Probing for `Analog Devices ADM1034'...                     No
Probing for `SPD EEPROM'...                                 No

Next adapter: NVIDIA i2c adapter  (i2c-2)
Do you want to scan it? (YES/no/selectively):

Next adapter: SMBus I801 adapter at 0500 (i2c-3)
Do you want to scan it? (YES/no/selectively):
Client found at address 0x4e
Probing for `National Semiconductor LM75'...                No
Probing for `Dallas Semiconductor DS75'...                  No
Probing for `Dallas Semiconductor DS1621/DS1631'...         No
Probing for `Analog Devices ADM1021'...                     No
Probing for `Analog Devices ADM1021A/ADM1023'...            No
Probing for `Maxim MAX1617'...                              No
Probing for `Maxim MAX1617A'...                             No
Probing for `Maxim MAX1668'...                              No
Probing for `Maxim MAX1805'...                              No
Probing for `Maxim MAX1989'...                              No
Probing for `Maxim MAX6655/MAX6656'...                      No
Probing for `TI THMC10'...                                  No
Probing for `National Semiconductor LM84'...                No
Probing for `Genesys Logic GL523SM'...                      No
Probing for `Onsemi MC1066'...                              No
Probing for `Maxim MAX1618'...                              No
Probing for `Maxim MAX1619'...                              No
Probing for `National Semiconductor LM82/LM83'...           No
Probing for `Maxim MAX6654/MAX6690'...                      No
Probing for `Maxim MAX6659'...                              No
Probing for `Maxim MAX6647'...                              No
Probing for `Maxim MAX6680/MAX6681'...                      No
Probing for `Texas Instruments TMP411'...                   No
Probing for `Texas Instruments TMP421'...                   No
Probing for `Texas Instruments TMP422'...                   No
Probing for `Texas Instruments AMC6821'...                  No
Probing for `National Semiconductor LM64'...                No
Probing for `National Semiconductor LM73'...                No
Probing for `Maxim MAX6633/MAX6634/MAX6635'...              No
Probing for `Fintek F75121R/F75122R/RG (VID+GPIO)'...       No
Probing for `Fintek F75111R/RG/N (GPIO)'...                 No
Probing for `ITE IT8201R/IT8203R/IT8206R/IT8266R'...        Yes
    (confidence 6, not a hardware monitoring chip)
Client found at address 0x50
Probing for `Analog Devices ADM1033'...                     No
Probing for `Analog Devices ADM1034'...                     No
Probing for `SPD EEPROM'...                                 No
Probing for `EDID EEPROM'...                                No
Client found at address 0x52
Probing for `Analog Devices ADM1033'...                     No
Probing for `Analog Devices ADM1034'...                     No
Probing for `SPD EEPROM'...                                 No

Now follows a summary of the probes I have just done.
Just press ENTER to continue:

Driver `max6650':
  * Bus `NVIDIA i2c adapter '
    Busdriver `nvidia', I2C address 0x1b
    Chip `Maxim MAX6650/MAX6651' (confidence: 2)

To load everything that is needed, add this to /etc/modules:
#----cut here----
# Chip drivers
max6650
#----cut here----
If you have some drivers built into your kernel, the list above will
contain too many modules. Skip the appropriate ones!

Do you want to add these lines automatically to /etc/modules? (yes/NO)yes
Successful!

Monitoring programs won't work until the needed modules are
loaded. You may want to run '/etc/init.d/module-init-tools start'
to load them.

Unloading i2c-i801... OK

root@gav-EX58-UD4P:~# /etc/init.d/module-init-tools start
Rather than invoking init scripts through /etc/init.d, use the service(8)
utility, e.g. service module-init-tools start

Since the script you are attempting to invoke has been converted to an
Upstart job, you may also use the start(8) utility, e.g. start module-init-tools
module-init-tools stop/waiting
root@gav-EX58-UD4P:~# i2cdetect -l
i2c-0    i2c           NVIDIA i2c adapter                  I2C adapter
i2c-1    i2c           NVIDIA i2c adapter                  I2C adapter
i2c-2    i2c           NVIDIA i2c adapter                  I2C adapter

actaully I just googled Chip `Maxim MAX6650/MAX6651'   and it seems to be a fan controller. As the Pico has no fan, maybe when i turn on the pico, this turns the Fan on , on the 9800 gtx card.

Gavin,

This probe can only locate i2c controllers which are on the system bus. I don't think that it can detect external i2c controllers, such as the one in the Pico Kit. However, it can see if there is an EDID eprom, and it did find one - probably the one on the Pico kit.

I will have to do some checking to see if the MAX6650 is associated with the Pico. I may not be able to get an answer to you today - but I'll try.

Best regards,

Pascal

Gavin,

The MAX6650 is not on the Pico Kit. Since you say it comes and goes when the Pico Kit is plugged in or not, I guess that the MAX6650 controller on the Nvidia graphics card is noticing the 5V on the HDMI connector when the Pico is plugged in, and is waking up to read the EDID. If you can control this bus, then you could communicate with the Pico over the HDMI i2c bus.

You mention that there are TI i2c chips which are in the list that are probed for. Yes, there are TI parts which have i2c controllers which could show up in a system. However, the i2c controllers in the Pico kit v2 (MSP430 and DLPC100 both have i2c buses) will not show up in your probes, because they are not on the PC system bus (as controllers).

If you learn how to use the HDMI i2c bus from the Nvidia graphics using Linux, I'm sure others (including myself) would be interested. Please post a report to the forum on how you do it.

Best regards,

Pascal

Hi Pascal, I understand that the Pico controllers will not show up on the system but, but according to the following update from Nvidia,  they seem to be intimating that this set of drivers will expose any devices connected to the dvi ports on a Nvidia graphics card to the system bus,  at least thats what I asume this means. I'll carry on messing about and keep you posted.

Appendix F. i2c Bus Support

The NVIDIA Linux kernel module now includes i2c (also called I-squared-c, Inter-IC Communications, or IIC) functionality that allows the NVIDIA Linux kernel module to export i2c ports found on board NVIDIA cards to the Linux kernel. This allows i2c devices on-board the NVIDIA graphics card, as well as devices connected to the VGA and/or DVI ports, to be accessed from kernel modules or userspace programs in a manner consistent with other i2c ports exported by the Linux kernel through the i2c framework.

You must have i2c support compiled into the kernel, or as a module, and X must be running. The i2c framework is available for both 2.4 and 2.6 series kernels. Linux kernel documentation covers the kernel and userspace /dev APIs, which you must use to access NVIDIA i2c ports.

NVIDIA has noted that in some distibutions, i2c support is enabled. However, the Linux kernel module i2c-core.o (2.4) or i2c-core.ko (2.6), which provides the export infrastructure, was not shipped. In this case, you will need to build the i2c support module. For directions on how to build and install your kernel's i2c support, refer to your distribution's documentation for configuring, building, and installing the kernel and associated modules.

For further information regarding the Linux kernel i2c framework, refer to the documentation for your kernel, located at .../Documentation/i2c/ within the kernel source tree.

The following functionality is currently supported:

  I2C_FUNC_I2C
  I2C_FUNC_SMBUS_QUICK
  I2C_FUNC_SMBUS_BYTE
  I2C_FUNC_SMBUS_BYTE_DATA
  I2C_FUNC_SMBUS_WORD_DATA

Hi Pascal,

I made a bit more progress.  I upgraded to Ubuntu 11.104 and installed the lm-sensors package and i2ctools.

See below, there are 4 busses detected.

root@SkyNet:/home/gavin# i2cdetect -l
i2c-0    i2c           NVIDIA i2c adapter                  I2C adapter
i2c-1    i2c           NVIDIA i2c adapter                  I2C adapter
i2c-2    i2c           NVIDIA i2c adapter                  I2C adapter
i2c-3    smbus         SMBus I801 adapter at 0500          SMBus adapter

I then did an i2c detect of bus 0, and found that it had 10 devices on it,

root@SkyNet:/home/gavin# i2cdetect 0
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0.
I will probe address range 0x03-0x77.
Continue? [Y/n]
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- 1a 1b -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 52 53 54 55 56 57 -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --                        
root@SkyNet:/home/gavin#

apparently, devices starting around  50 are usually eproms, so I dumped that address with the i2cdump command, and it seems this is the Pico projector. (see bold)

root@SkyNet:/home/gavin# i2cdump 0 0x50
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0, address 0x50, mode byte
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 ff ff ff ff ff ff 00 65 e9 01 00 00 00 00 00    ........e??.....
10: 00 13 01 03 80 70 40 78 0a ee 95 a3 54 4c 99 26    .????p@x????TL?&
20: 0f 50 54 20 00 00 01 01 01 01 01 01 01 01 01 01    ?PT ..??????????
30: 01 01 01 01 01 01 c4 09 80 90 20 e0 1d 10 08 60    ?????????? ????`
40: 22 00 c4 8e 21 00 00 18 00 00 00 10 00 00 26 30    ".??!..?...?..&0
50: 18 88 36 00 c4 8e 21 00 00 18 00 00 00 10 00 3b    ??6.??!..?...?.;
60: 3d 0f 50 0e 0a 0a 0a 0a 0a 0a 0a 0a 00 00 00 fc    =?P?????????...?
70: 00 59 4f 49 20 50 69 63 6f 0a 0a 0a 0a 0a 00 91    .YOI Pico?????.?
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
root@SkyNet:/home/gavin#

So the question now, is how do i format my I2c commands ?  Is the address of the Chip 0x50 on bus 0 ?

cheers

Gav

Gavin,

I can see that the address 0x50 is returning a string with "YOI Pico" in it. This may be an address used by the Pico. However, the TI Pico controller (DLPC100) address is 0x1b.

Have you looked at the DLP Pico Kit v2 Programmer's Guide (http://www.ti.com/litv/pdf/dlpu002a)?

The commands look like this:

bus3-i2c 0x1b wb4 0x04 0x00000000 # Select Pico Kit v2 HDMI input

Where everything after the # is a comment.

I posted quite a long example of code a week or two ago on this forum, which you can examine.

Try something like:

bus3-i2c 0x1b wb4 0x04 0x00000001 # Select Pico Kit v2 internal test patterns

If it works, you should see a checkerboard pattern on the screen. You can return to the HDMI input by using the earlier command.

Best regards,

Pascal

Hi Pascal, you must be getting sick of all these questions! I admire your patience!

I'm a bit confused, as the DLP® Pico Chipset v2 Programmer’s Guide (page 8) for the Pico says the address of the pico 2.0 is  0x36  but you say its 0x1b

e.g  An example of a register write to device address x36, sub-address x04 with data x00000000 would be as follows: S 36 04 00 00 00 00 P

The other problem is that the syntax you describe e.g  bus3-i2c 0x1b wb4 0x04 0x00000001 

you send 4 bytes at a time using the wb4 clause, however, for those people using I2ctools in linux, I don't think thats possible, and using the i2cset command, you can only write a byte or a word at a time.  So presumably the command

bus3-i2c 0x1b wb4 0x04 0x00000001  would translate to

i2cset i2c 0x1b 0x04 0x01  i.e use the i2cset command on bus named i2c memory address 0x1b, sub address 0x04, value 0x01

I have been able to write to an unused sub address using 2 bytes at a time  as described above, but when doing the i2cdump of all the address listed in each bus, I could not see a memory map  memory values corrosponded to the default values listed in the user guide. So maybe I'm on a road to nowhere. Seems odd though. So close.

Gavin,

The difference between 0x36 and 0x1B is a 1 bit shift (multiply or divide by 2). 0x36 = 0011 0110b      0x1b = 0001 1011b

The i2c-tools use the right shifted value for the address, 0x1b.

As for the wb4 (write 4 bytes), I'm not sure why that doesn't work under any Linux. The data value is simply 32 bits. I would think that the tools would handle the data types the same on any architecture, PC or BB. I don't have a way to test this right  now. Perhaps someone in the community can give us the benefit of their experience with this.

Best regards,

Pascal

From the sensorss-detect script which sets up the list of devices available on each bus, i notice there are a number of TI devices, and it woudl be possible to add new TI devices to it.

An extract of some of the known TI devices is as follows, so would it be possible to add an entry for the PICO 2.0?

cheers

Gav

}, {
		name => "Texas Instruments TMP421",
		driver => "tmp421",
		i2c_addrs => [0x1c..0x1f, 0x2a, 0x4c..0x4f],
		i2c_detect => sub { tmp42x_detect(@_, 0); },
	}, {
		name => "Texas Instruments TMP422",
		driver => "tmp421",
		i2c_addrs => [0x4c..0x4f],
		i2c_detect => sub { tmp42x_detect(@_, 1); },
	}, {
		name => "Texas Instruments TMP423",
		driver => "tmp421",
		i2c_addrs => [0x4c, 0x4d],
		i2c_detect => sub { tmp42x_detect(@_, 2); },
	}, {
	

Gav,

Thank you for pointing out the list of sensors known to sensors-detect. We will consider this. I will look into lm-sensors and learn more.

Best regards,

Pascal