I2C read from onboard devices

GoogleGroups
1

Hello,

I saw that onboard EEPROM is connected at 0xA0 (0x50) slave address but ioctl() on this address failed.
Anyone can point me to read this i2c device ?

The same problem with HDMI framer, I cannot read from it’s slave address 0xE0 (0x70)

Thanks

2

Hi,

You can use i2cset ,i2cget and i2cdetect function to write ,read and detect the EEPROM

Regards
Punith

3

I have been trying to use these functions to determine the status of the HDMI but always receive device is busy.

I am trying to get at the interrupt from the HDMI that seems to be defined in the reference manual. I2C does not seem to work under Angstrom or Ubuntu. Any ideas as to where to start looking?

Thanks,
Dan Metcalf

4

That device is being utilized by drm drivers.. However you can use
the "parse-edid" tool to read the edid value directly..

root@beaglebone:~# uname -a
Linux beaglebone 3.8.13-bone33 #1 SMP Sat Dec 21 17:11:36 UTC 2013
armv7l GNU/Linux

root@beaglebone:~# parse-edid /sys/class/drm/card0/card0-HDMI-A-1/edid
parse-edid: parse-edid version 2.0.0
parse-edid: EDID checksum passed.

# EDID version 1 revision 3
Section "Monitor"
# Block type: 2:0 3:ff
# Block type: 2:0 3:fc
Identifier "DELL 1707FP"
VendorName "DEL"
ModelName "DELL 1707FP"
# Block type: 2:0 3:ff
# Block type: 2:0 3:fc
# Block type: 2:0 3:fd
HorizSync 30-81
VertRefresh 56-76
# Max dot clock (video bandwidth) 140 MHz
# DPMS capabilities: Active off:yes Suspend:yes Standby:yes

Mode "1280x1024" # vfreq 60.020Hz, hfreq 63.981kHz
DotClock 108.000000
HTimings 1280 1328 1440 1688
VTimings 1024 1025 1028 1066
Flags "+HSync" "+VSync"
EndMode
# Block type: 2:0 3:ff
# Block type: 2:0 3:fc
# Block type: 2:0 3:fd
EndSection

Regards,

5

Or you can access the registered device thru: /sys/bus/i2c/devices/

root@beaglebone:~# hexdump -e '8/1 "%c"' /sys/bus/i2c/devices/0-0050/eeprom

A335BNLT0A5A1513BBBK3949

(prints other random junk..)

Regards,

6

The question is why can’t be accessed regularly from user space by reading /dev/i2c-0 bus?
The I2C buses and devices can’t be owned exclusively even by kernel due to I2C architecture, so as far as the bus is free, anyone should read/write to any address.

I have worked on many industrial boards considerably bigger than BBB (WindRiver kernel) and all devices with I2C for maintenance (RapidIO, DSP, MAC/PHY, etc) are accessible.

Why on BeagleBone the addresses of HDMI framer, PMIC and onboard EE are intentionally blocked by driver ?
Or why the DRM driver is written that way?

Regards,

7

Well the hdmi/edid is the easly one.. As the beaglebone dose not have
direct access to that bus, take look at page 10:

https://github.com/CircuitCo/BeagleBone-Black/blob/master/BBB_SCH.pdf

Thus we need to query the TDA19988 device thru drm for the edid...

As far as PMIC/EE are registered by the dts in i2c0:

tps: tps@24 {
reg = <0x24>; };

baseboard_eeprom: baseboard_eeprom@50 {
compatible = "at,24c256";
reg = <0x50>; };

Thus if that blocks access thru /dev/i2c-0, i guess it blocks it...

Regards,

8

The PMIC registers can be read using i2cget but writing to registers requires editing the password register http://www.ti.com/lit/ds/symlink/tps65217c.pdf Page 40. NOTE: All registers on the PMIC are set to default if the device moves from active to sleep or off state.

The eePROM can be read from using i2cget but is hardware write protected.

9

btw the "UU" from i2cdetect in 0x24/0x50 give you a hint that the
normal i2cXYZ can't access them as they are currently busy (with the
kernel)..

root@beaglebone:~# i2cdetect -y -r 0
     0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- 34 -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: 70 -- -- -- -- -- -- --

(no idea where 0x34/0x70 are coming from at the moment..)

Regards,

10

I think 0x34 is the HDMI framer.

11

According to the SRM 0x70 should be the HDMI Framer Processor Interface. see page 73.

12

Your right Daniel, thanks for correcting me.

13

No worries. I have only been starring at it for the last week or so trying to figure out how to get at the interrupt and status information. I am working to determine when a display has been connected or disconnected to now when to start and stop a product presentation and get supported resolution so I can resize the presentation to fit the new display.

v/r,
Dan Metcalf