[lm-sensors] i2c-i801 on AppleTV (1st gen)

[lm-sensors] i2c-i801 on AppleTV (1st gen)

[Dag Wieers]

Hi,

For the OpenELEC project I am looking into enabling the i2c-i801 interface 
for getting more system information (voltage, temperature, fan).

The AppleTV (1st Gen) has a N10/ICH 7 Family SMBus Controller (8086:27da) 
device that is supported by i2c-i801, but I haven't been able to get 
anything to work apart from loading the driver.

   00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev 02)
           Subsystem: Intel Corporation Device 7270
           Flags: medium devsel, IRQ 19
           I/O ports at efa0 [size2]
           Kernel driver in use: i801_smbus
           Kernel modules: i2c-i801

(Lacking perl, I haven't been able to get sensors-detect working yet. We 
will have to add perl to the OpenELEC buildsystem for this)

I tried loading all sensors from kernel 3.7.5, to no avail.

Is there something I can do to test whether the i2c SMBus is at all 
functional ?

PS If needed, I can provide remote access to an AppleTV device.

Kind regards,
-- 
-- dag wieers, dag@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] i2c-i801 on AppleTV (1st gen)

[Jean Delvare]

On Tue, 5 Feb 2013 10:08:49 +0100 (CET), Dag Wieers wrote:
> For the OpenELEC project I am looking into enabling the i2c-i801 interface 
> for getting more system information (voltage, temperature, fan).
> 
> The AppleTV (1st Gen) has a N10/ICH 7 Family SMBus Controller (8086:27da) 
> device that is supported by i2c-i801, but I haven't been able to get 
> anything to work apart from loading the driver.
> 
>    00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev 02)
>            Subsystem: Intel Corporation Device 7270
>            Flags: medium devsel, IRQ 19
>            I/O ports at efa0 [size2]
>            Kernel driver in use: i801_smbus
>            Kernel modules: i2c-i801

This looks good.

> (Lacking perl, I haven't been able to get sensors-detect working yet. We 
> will have to add perl to the OpenELEC buildsystem for this)
> 
> I tried loading all sensors from kernel 3.7.5, to no avail.

This is pretty risky, I wouldn't do that.

> Is there something I can do to test whether the i2c SMBus is at all 
> functional ?

Install i2c-tools [1] and try i2cdetect.

[1] http://www.lm-sensors.org/wiki/I2CTools

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] i2c-i801 on AppleTV (1st gen)

[Dag Wieers]

On Tue, 5 Feb 2013, Jean Delvare wrote:

> On Tue, 5 Feb 2013 10:08:49 +0100 (CET), Dag Wieers wrote:
>
>> Is there something I can do to test whether the i2c SMBus is at all
>> functional ?
>
> Install i2c-tools [1] and try i2cdetect.
>
> [1] http://www.lm-sensors.org/wiki/I2CTools

Ok, I included i2ctools as part of the OpenELEC build and this is now what 
I get:

root ~ # ./i2cdetect -l
i2c-0   smbus           SMBus I801 adapter at efa0              SMBus adapter
i2c-1   i2c             Afatech AF9015 reference design         I2C adapter
i2c-2   i2c             NVIDIA i2c adapter 1 at 1:00.0          I2C adapter
i2c-3   i2c             NVIDIA i2c adapter 2 at 1:00.0          I2C adapter

root ~ # ./i2cdetect -F 0
Functionalities implemented by /dev/i2c-0:
I2C                              no
SMBus Quick Command              yes
SMBus Send Byte                  yes
SMBus Receive Byte               yes
SMBus Write Byte                 yes
SMBus Read Byte                  yes
SMBus Write Word                 yes
SMBus Read Word                  yes
SMBus Process Call               no
SMBus Block Write                yes
SMBus Block Read                 yes
SMBus Block Process Call         no
SMBus PEC                        yes
I2C Block Write                  yes
I2C Block Read                   yes

What's next ?

-- 
-- dag wieers, dag@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] i2c-i801 on AppleTV (1st gen)

[Jean Delvare]

On Tue, 5 Feb 2013 11:33:49 +0100 (CET), Dag Wieers wrote:
> Ok, I included i2ctools as part of the OpenELEC build and this is now what 
> I get:
> 
> root ~ # ./i2cdetect -l
> i2c-0   smbus           SMBus I801 adapter at efa0              SMBus adapter
> i2c-1   i2c             Afatech AF9015 reference design         I2C adapter
> i2c-2   i2c             NVIDIA i2c adapter 1 at 1:00.0          I2C adapter
> i2c-3   i2c             NVIDIA i2c adapter 2 at 1:00.0          I2C adapter
> 
> root ~ # ./i2cdetect -F 0
> Functionalities implemented by /dev/i2c-0:
> I2C                              no
> SMBus Quick Command              yes
> SMBus Send Byte                  yes
> SMBus Receive Byte               yes
> SMBus Write Byte                 yes
> SMBus Read Byte                  yes
> SMBus Write Word                 yes
> SMBus Read Word                  yes
> SMBus Process Call               no
> SMBus Block Write                yes
> SMBus Block Read                 yes
> SMBus Block Process Call         no
> SMBus PEC                        yes
> I2C Block Write                  yes
> I2C Block Read                   yes
> 
> What's next ?

# ./i2cdetect 0 

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] i2c-i801 on AppleTV (1st gen)

[Dag Wieers]

On Tue, 5 Feb 2013, Jean Delvare wrote:

> On Tue, 5 Feb 2013 11:33:49 +0100 (CET), Dag Wieers wrote:
>
>> Ok, I included i2ctools as part of the OpenELEC build and this is now what
>> I get:
>>
>> root ~ # ./i2cdetect -l
>> i2c-0   smbus           SMBus I801 adapter at efa0              SMBus adapter
>> i2c-1   i2c             Afatech AF9015 reference design         I2C adapter
>> i2c-2   i2c             NVIDIA i2c adapter 1 at 1:00.0          I2C adapter
>> i2c-3   i2c             NVIDIA i2c adapter 2 at 1:00.0          I2C adapter
>>
>> root ~ # ./i2cdetect -F 0
>> Functionalities implemented by /dev/i2c-0:
>> I2C                              no
>> SMBus Quick Command              yes
>> SMBus Send Byte                  yes
>> SMBus Receive Byte               yes
>> SMBus Write Byte                 yes
>> SMBus Read Byte                  yes
>> SMBus Write Word                 yes
>> SMBus Read Word                  yes
>> SMBus Process Call               no
>> SMBus Block Write                yes
>> SMBus Block Read                 yes
>> SMBus Block Process Call         no
>> SMBus PEC                        yes
>> I2C Block Write                  yes
>> I2C Block Read                   yes
>>
>> What's next ?
>
> # ./i2cdetect 0

root ~ # ./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] Y
      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- 69 -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Anything I can read to understand the output ?

-- 
-- dag wieers, dag@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] i2c-i801 on AppleTV (1st gen)

[Jean Delvare]

On Tue, 5 Feb 2013 11:40:50 +0100 (CET), Dag Wieers wrote:
> On Tue, 5 Feb 2013, Jean Delvare wrote:
> > # ./i2cdetect 0
> 
> root ~ # ./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] Y
>       0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00:          -- -- -- -- -- -- -- -- -- -- -- -- --
> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60: -- -- -- -- -- -- -- -- -- 69 -- -- -- -- -- --
> 70: -- -- -- -- -- -- -- --
> 
> Anything I can read to understand the output ?

Not really. It takes some experience to interpret the results, although
the above is so simple that it should be easy.

A single chip replied to the probes, at 7-bit I2C slave address 0x69.
On computers, this address is most typically used by a clock chip. It
is advised to leave that kind of chip alone unless you know exactly
what brand and model it is and how it is connected to the other components
on the board.

To put it short: if you were looking for a hardware monitoring chip,
it's not there. Or maybe it is there but behind a multiplexer -
something which can't be detected.

Do you have any reason to believe that there is an SMBus-based hardware
monitoring chip on this system?

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] i2c-i801 on AppleTV (1st gen)

[Dag Wieers]

On Tue, 5 Feb 2013, Jean Delvare wrote:

> Do you have any reason to believe that there is an SMBus-based hardware
> monitoring chip on this system?

No I haven't. In fact I would be surprised if there was one (given how 
Apple stripped the device), but I wanted to make sure that we're using all 
the capabilities of the system (and I wasn't sure if anyone went through 
the trouble already for this device).

Since the device has no power button and little ACPI functionality, it 
would have been helpful to measure temperature and voltage so we could 
determine whether changes to xbmc or the kernel improve the situation or 
makes it worse.

From the other i2c devices, the only one that returns any info is:

root ~ # ./i2cdetect -l
i2c-0   smbus           SMBus I801 adapter at efa0              SMBus adapter
i2c-1   i2c             Afatech AF9015 reference design         I2C adapter
i2c-2   i2c             NVIDIA i2c adapter 1 at 1:00.0          I2C adapter
i2c-3   i2c             NVIDIA i2c adapter 2 at 1:00.0          I2C adapter


Not sure what this output provides us with:

root ~ # ./i2cdetect 2
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-2.
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: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- 37 -- -- 3a -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Thanks for your insights,
-- 
-- dag wieers, dag@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] i2c-i801 on AppleTV (1st gen)

[Jean Delvare]

On Tue, 5 Feb 2013 12:10:05 +0100 (CET), Dag Wieers wrote:
> root ~ # ./i2cdetect -l
> i2c-0   smbus           SMBus I801 adapter at efa0              SMBus adapter
> i2c-1   i2c             Afatech AF9015 reference design         I2C adapter
> i2c-2   i2c             NVIDIA i2c adapter 1 at 1:00.0          I2C adapter
> i2c-3   i2c             NVIDIA i2c adapter 2 at 1:00.0          I2C adapter
> 
> 
> Not sure what this output provides us with:
> 
> root ~ # ./i2cdetect 2
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> I will probe file /dev/i2c-2.
> 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: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 30: -- -- -- -- -- -- -- 37 -- -- 3a -- -- -- -- --
> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 70: -- -- -- -- -- -- -- --

At 0x50 is the EDID EEPROM inside the monitor connected to the graphics
card (over the video cable.) No idea about 0x37 and 0x3a, but these
have to be chips related to the graphics card, like a video encoder if
the card has video-out.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] i2c-i801 on AppleTV (1st gen)

[Dag Wieers]

On Tue, 5 Feb 2013, Jean Delvare wrote:

> On Tue, 5 Feb 2013 11:40:50 +0100 (CET), Dag Wieers wrote:
>> On Tue, 5 Feb 2013, Jean Delvare wrote:
>>> # ./i2cdetect 0
>>
>> root ~ # ./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] Y
>>       0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
>> 00:          -- -- -- -- -- -- -- -- -- -- -- -- --
>> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 60: -- -- -- -- -- -- -- -- -- 69 -- -- -- -- -- --
>> 70: -- -- -- -- -- -- -- --
>>
>> Anything I can read to understand the output ?
>
> Not really. It takes some experience to interpret the results, although
> the above is so simple that it should be easy.
>
> A single chip replied to the probes, at 7-bit I2C slave address 0x69.
> On computers, this address is most typically used by a clock chip. It
> is advised to leave that kind of chip alone unless you know exactly
> what brand and model it is and how it is connected to the other components
> on the board.
>
> To put it short: if you were looking for a hardware monitoring chip,
> it's not there. Or maybe it is there but behind a multiplexer -
> something which can't be detected.

Hi Jean,

I noticed on my second AppleTV device that it has a second address that 
replied:

root ~ # 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: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- 69 -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

The differences between both devices is that this one has the original 
wireless device (b43) instead of the crystalhd mini-pci, and it doesn't 
have the DVB USB stick inserted.

What could 48 be ?

Thanks in advance,
-- 
-- dag wieers, dag@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] i2c-i801 on AppleTV (1st gen)

[Jean Delvare]

Hello Dag,

On Wed, 6 Feb 2013 00:26:06 +0100 (CET), Dag Wieers wrote:
> I noticed on my second AppleTV device that it has a second address that 
> replied:
> 
> root ~ # 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: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- --
> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60: -- -- -- -- -- -- -- -- -- 69 -- -- -- -- -- --
> 70: -- -- -- -- -- -- -- --
> 
> The differences between both devices is that this one has the original 
> wireless device (b43) instead of the crystalhd mini-pci, and it doesn't 
> have the DVB USB stick inserted.
> 
> What could 48 be ?

This address was commonly used for simple temperature sensors (e.g.
LM75) but these are no longer so frequent. This could be virtually
anything. If you are willing to take the risk, you can provide a byte
dump of the chip with:
# i2cdump 0 0x48 b
at which point I can tell you if this is a device I recognize (a.k.a.
human version of sensors-detect.)

-- 
Jean Delvare
http://khali.linux-fr.org/wishlist.html

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] i2c-i801 on AppleTV (1st gen)

[Dag Wieers]

On Wed, 6 Feb 2013, Jean Delvare wrote:

> On Wed, 6 Feb 2013 00:26:06 +0100 (CET), Dag Wieers wrote:
>
>> I noticed on my second AppleTV device that it has a second address that
>> replied:
>>
>> root ~ # 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: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- --
>> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 60: -- -- -- -- -- -- -- -- -- 69 -- -- -- -- -- --
>> 70: -- -- -- -- -- -- -- --
>>
>> The differences between both devices is that this one has the original
>> wireless device (b43) instead of the crystalhd mini-pci, and it doesn't
>> have the DVB USB stick inserted.
>>
>> What could 48 be ?
>
> This address was commonly used for simple temperature sensors (e.g.
> LM75) but these are no longer so frequent. This could be virtually
> anything. If you are willing to take the risk, you can provide a byte
> dump of the chip with:
> # i2cdump 0 0x48 b
> at which point I can tell you if this is a device I recognize (a.k.a.
> human version of sensors-detect.)

What risk am I taking wrt. probability and damage ? :)

And what could be the reason for the difference in behaviour of both 
devices ? Could it be BIOS, firmware, ACPI, kernel, or is this pure 
hardware-related ?

PS I now added dmidecode to the OpenELEC build system in order to find 
other differences between both devices.

-- 
-- dag wieers, dag@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] i2c-i801 on AppleTV (1st gen)

[Jean Delvare]

On Wed, 6 Feb 2013 09:11:05 +0100 (CET), Dag Wieers wrote:
> On Wed, 6 Feb 2013, Jean Delvare wrote:
> 
> > On Wed, 6 Feb 2013 00:26:06 +0100 (CET), Dag Wieers wrote:
> >
> >> I noticed on my second AppleTV device that it has a second address that
> >> replied:
> >>
> >> root ~ # 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: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> >> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> >> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> >> 40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- --
> >> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> >> 60: -- -- -- -- -- -- -- -- -- 69 -- -- -- -- -- --
> >> 70: -- -- -- -- -- -- -- --
> >>
> >> The differences between both devices is that this one has the original
> >> wireless device (b43) instead of the crystalhd mini-pci, and it doesn't
> >> have the DVB USB stick inserted.
> >>
> >> What could 48 be ?
> >
> > This address was commonly used for simple temperature sensors (e.g.
> > LM75) but these are no longer so frequent. This could be virtually
> > anything. If you are willing to take the risk, you can provide a byte
> > dump of the chip with:
> > # i2cdump 0 0x48 b
> > at which point I can tell you if this is a device I recognize (a.k.a.
> > human version of sensors-detect.)
> 
> What risk am I taking wrt. probability and damage ? :)

There is no standard on which I2C/SMBus transactions a slave must
support not how it interprets them. "Read byte" transactions send a
register offset to the slave and the slave is expected to reply with
the 8-bit register value. 95% of the I2C/SMBus slaves understand that
and will to what you expect, however a few of them will not. Amongst
the one which won't, are a few which will treat the register offset as
an actual write. And do whatever they are supposed to do when you write
to them. We have has (thankfully rare) reports of dead hardware as a
result of poking at unknown I2C slaves.

The risk is relatively low, but it exists. If you want to make it as
low as possible, you can start with:

# i2cget 0 0x48

This will read the presumed internal pointer value from the chip. Write
down the value for future use. I'll call in $v below. Then try a single
register read:

# i2cget 0 0x48 $v

If it returns $v again, and $v is neither 0x00 nor 0xff, you better
leave the chip alone, and cold boot the machine (just in case.) In
other cases, the chip seem to behave normally and you can go with:

# i2cdump 0 0x48 b

> And what could be the reason for the difference in behaviour of both 
> devices ? Could it be BIOS, firmware, ACPI, kernel, or is this pure 
> hardware-related ?

It can be a lot of things. It can be that one machine has an extra chip
and the other doesn't. Or the chip can be present on both, but hidden
behind a multiplexer, and that multiplexer has a different default
setting on the machines. Or both machines have a compatible chip but
not exactly the same one, and one replies to SMBus quick commands (used
by i2cdetect) and the other one does not. And there are certainly more
possible reasons I can't think of right now.

> PS I now added dmidecode to the OpenELEC build system in order to find 
> other differences between both devices.

Good idea.

-- 
Jean Delvare
http://khali.linux-fr.org/wishlist.html

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] i2c-i801 on AppleTV (1st gen)

[Dag Wieers]

On Wed, 6 Feb 2013, Jean Delvare wrote:

> The risk is relatively low, but it exists. If you want to make it as
> low as possible, you can start with:
>
> # i2cget 0 0x48
>
> This will read the presumed internal pointer value from the chip. Write
> down the value for future use. I'll call in $v below. Then try a single
> register read:
>
> # i2cget 0 0x48 $v
>
> If it returns $v again, and $v is neither 0x00 nor 0xff, you better
> leave the chip alone, and cold boot the machine (just in case.) In
> other cases, the chip seem to behave normally and you can go with:
>
> # i2cdump 0 0x48 b

So here we go:

root ~ # i2cget 0 0x48
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will read from device file /dev/i2c-0, chip address 0x48, current data
address, using read byte.
Continue? [Y/n]
0x3f

root ~ # i2cget 0 0x48 0x3f
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will read from device file /dev/i2c-0, chip address 0x48, data address
0x3f, using read byte data.
Continue? [Y/n]
Error: Read failed

root ~ # i2cget 0 0x48 b
Error: Data address invalid!
Usage: i2cget [-f] [-y] I2CBUS CHIP-ADDRESS [DATA-ADDRESS [MODE]]
   I2CBUS is an integer or an I2C bus name
   ADDRESS is an integer (0x03 - 0x77)
   MODE is one of:
     b (read byte data, default)
     w (read word data)
     c (write byte/read byte)
     Append p for SMBus PEC


>> PS I now added dmidecode to the OpenELEC build system in order to find
>> other differences between both devices.
>
> Good idea.

No important differences. The systems also runs the same kernel/ramdisk, 
so I guess some nvram or bios setting is different, or it's the hardware. 
Weird.

----
[dag@lisse ~]$ diff -u <(ssh root@xbmc01 dmidecode) <(ssh root@xbmc02 dmidecode)
--- /dev/fd/63  2013-02-06 13:10:19.476163195 +0100
+++ /dev/fd/62  2013-02-06 13:10:19.477163195 +0100
@@ -180,7 +180,7 @@
         Manufacturer: Apple Inc.
         Product Name: AppleTV1,1
         Version: 1.0
-       Serial Number: YM91505WXVG
+       Serial Number: YM809009YST
         UUID: 9CFE245E-D0C8-BD45-A79F-54EA5FBD3D97
         Wake-up Type: Power Switch
         SKU Number: System SKU #
@@ -207,7 +207,7 @@
         Type: Space-saving
         Lock: Not Present
         Version: Mac-F4228DC8
-       Serial Number: YM91505WXVG
+       Serial Number: YM809009YST
         Asset Tag: Asset Tag#
         Boot-up State: Safe
         Power Supply State: Safe
----


-- 
-- dag wieers, dag@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] i2c-i801 on AppleTV (1st gen)

[Jean Delvare]

On Wed, 6 Feb 2013 13:12:54 +0100 (CET), Dag Wieers wrote:
> On Wed, 6 Feb 2013, Jean Delvare wrote:
> 
> > The risk is relatively low, but it exists. If you want to make it as
> > low as possible, you can start with:
> >
> > # i2cget 0 0x48
> >
> > This will read the presumed internal pointer value from the chip. Write
> > down the value for future use. I'll call in $v below. Then try a single
> > register read:
> >
> > # i2cget 0 0x48 $v
> >
> > If it returns $v again, and $v is neither 0x00 nor 0xff, you better
> > leave the chip alone, and cold boot the machine (just in case.) In
> > other cases, the chip seem to behave normally and you can go with:
> >
> > # i2cdump 0 0x48 b
> 
> So here we go:
> 
> root ~ # i2cget 0 0x48
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> I will read from device file /dev/i2c-0, chip address 0x48, current data
> address, using read byte.
> Continue? [Y/n]
> 0x3f
> 
> root ~ # i2cget 0 0x48 0x3f
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> I will read from device file /dev/i2c-0, chip address 0x48, data address
> 0x3f, using read byte data.
> Continue? [Y/n]
> Error: Read failed

Not good. This can mean one of two things: either the chip has no
register 0x3f and it nacks non-existent register read attempts, or it
doesn't support SMBus read byte transactions at all. In the latter
case, I strongly suggest that you leave the chip alone. As for the
former case, there are a few thermal sensor chips which behave like,
don't have a register at 0x3f and can use slave address 0x48: DS1621
and similar, DS75, LM73.

Please try "i2cget 0 0x48" multiple times and see if it always returns
the same value.

> root ~ # i2cget 0 0x48 b
> Error: Data address invalid!
> Usage: i2cget [-f] [-y] I2CBUS CHIP-ADDRESS [DATA-ADDRESS [MODE]]
>    I2CBUS is an integer or an I2C bus name
>    ADDRESS is an integer (0x03 - 0x77)
>    MODE is one of:
>      b (read byte data, default)
>      w (read word data)
>      c (write byte/read byte)
>      Append p for SMBus PEC

The right command here was i2cdump, not i2cget. But given the results
of the previous command, it's probably a good thing that you got it
wrong. Don't do it (yet.)

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] i2c-i801 on AppleTV (1st gen)

[Dag Wieers]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 814 bytes --]

On Wed, 6 Feb 2013, Jean Delvare wrote:

> Not good. This can mean one of two things: either the chip has no
> register 0x3f and it nacks non-existent register read attempts, or it
> doesn't support SMBus read byte transactions at all. In the latter
> case, I strongly suggest that you leave the chip alone. As for the
> former case, there are a few thermal sensor chips which behave like,
> don't have a register at 0x3f and can use slave address 0x48: DS1621
> and similar, DS75, LM73.

It now consistently returns 0x3d, could this be a thermal value, like 61°C ?

The GPU reports 46°C (coming from nvidia-smi).

-- 
-- dag wieers, dag@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] i2c-i801 on AppleTV (1st gen)

[Jean Delvare]

On Wed, 6 Feb 2013 15:00:58 +0100 (CET), Dag Wieers wrote:
> On Wed, 6 Feb 2013, Jean Delvare wrote:
> 
> > Not good. This can mean one of two things: either the chip has no
> > register 0x3f and it nacks non-existent register read attempts, or it
> > doesn't support SMBus read byte transactions at all. In the latter
> > case, I strongly suggest that you leave the chip alone. As for the
> > former case, there are a few thermal sensor chips which behave like,
> > don't have a register at 0x3f and can use slave address 0x48: DS1621
> > and similar, DS75, LM73.
> 
> It now consistently returns 0x3d, could this be a thermal value, like 61°C ?

Could be, but for now all I see is that 0x3d == 0x3f - 0x02, i.e. only
one bit changed. You will need to take more samples before you can draw
a conclusion. Also compare when CU is idle and when it's busy.

> The GPU reports 46°C (coming from nvidia-smi).

-- 
Jean Delvare
http://khali.linux-fr.org/wishlist.html

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] i2c-i801 on AppleTV (1st gen)

[Dag Wieers]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2128 bytes --]

On Wed, 6 Feb 2013, Jean Delvare wrote:

> On Wed, 6 Feb 2013 15:00:58 +0100 (CET), Dag Wieers wrote:
>> On Wed, 6 Feb 2013, Jean Delvare wrote:
>>
>>> Not good. This can mean one of two things: either the chip has no
>>> register 0x3f and it nacks non-existent register read attempts, or it
>>> doesn't support SMBus read byte transactions at all. In the latter
>>> case, I strongly suggest that you leave the chip alone. As for the
>>> former case, there are a few thermal sensor chips which behave like,
>>> don't have a register at 0x3f and can use slave address 0x48: DS1621
>>> and similar, DS75, LM73.
>>
>> It now consistently returns 0x3d, could this be a thermal value, like 61°C ?
>
> Could be, but for now all I see is that 0x3d == 0x3f - 0x02, i.e. only
> one bit changed. You will need to take more samples before you can draw
> a conclusion. Also compare when CU is idle and when it's busy.

So I have been reading out different values over time, but when 
repeatedly asked it provides the same value:

----
root ~ # i2cget 0 0x48
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will read from device file /dev/i2c-0, chip address 0x48, current data
address, using read byte.
Continue? [Y/n]
0x3d

root ~ # gputemp
46 C
----

----
root ~ # i2cget 0 0x48
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will read from device file /dev/i2c-0, chip address 0x48, current data
address, using read byte.
Continue? [Y/n]
0x43

root ~ # gputemp
52 C
----

----
root ~ # i2cget 0 0x48
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will read from device file /dev/i2c-0, chip address 0x48, current data
address, using read byte.
Continue? [Y/n]
0x4b

root ~ # gputemp
58 C
----

It pretty much looks like a thermal sensor, much in sync with the GPU 
temperature. How would I continue ?

-- 
-- dag wieers, dag@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] i2c-i801 on AppleTV (1st gen)

[Jean Delvare]

On Thu, 7 Feb 2013 00:27:09 +0100 (CET), Dag Wieers wrote:
> > Could be, but for now all I see is that 0x3d = 0x3f - 0x02, i.e. only
> > one bit changed. You will need to take more samples before you can draw
> > a conclusion. Also compare when CU is idle and when it's busy.
> 
> So I have been reading out different values over time, but when 
> repeatedly asked it provides the same value:
> 
> ----
> root ~ # i2cget 0 0x48
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> I will read from device file /dev/i2c-0, chip address 0x48, current data
> address, using read byte.
> Continue? [Y/n]
> 0x3d
> 
> root ~ # gputemp
> 46 C
> ----
> 
> ----
> root ~ # i2cget 0 0x48
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> I will read from device file /dev/i2c-0, chip address 0x48, current data
> address, using read byte.
> Continue? [Y/n]
> 0x43
> 
> root ~ # gputemp
> 52 C
> ----
> 
> ----
> root ~ # i2cget 0 0x48
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> I will read from device file /dev/i2c-0, chip address 0x48, current data
> address, using read byte.
> Continue? [Y/n]
> 0x4b
> 
> root ~ # gputemp
> 58 C
> ----
> 
> It pretty much looks like a thermal sensor, much in sync with the GPU 
> temperature. How would I continue ?

I would suggest the following:
# i2cdump -r 0x3d-0x4b 0 0x48 b

This should be pretty safe, as even if the chip doesn't use 8-bit
register addressing, at least we know that values in the 0x3d-0x4b
range are fine for your system.

If this is a DS75 or DS1621 chip you should see some register values.
If this is an LM73 you won't.

Then try again:
# i2cget 0 0x48
If you don't get a value in the range you expect, play it safe and
power down the machine immediately, then cold boot it.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] i2c-i801 on AppleTV (1st gen)

[Dag Wieers]

On Thu, 7 Feb 2013, Jean Delvare wrote:

> I would suggest the following:
> # i2cdump -r 0x3d-0x4b 0 0x48 b
>
> This should be pretty safe, as even if the chip doesn't use 8-bit
> register addressing, at least we know that values in the 0x3d-0x4b
> range are fine for your system.
>
> If this is a DS75 or DS1621 chip you should see some register values.
> If this is an LM73 you won't.
>
> Then try again:
> # i2cget 0 0x48
> If you don't get a value in the range you expect, play it safe and
> power down the machine immediately, then cold boot it.

I am trusting you blindly here ;-)

It all looks good to me (system is mostly idle):

----
root ~ # i2cdump -r 0x3d-0x4b 0 0x48 b
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0, address 0x48, mode byte
Probe range limited to 0x3d-0x4b.
Continue? [Y/n]
      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
30:                                        XX XX XX                 XXX
40: XX XX XX XX XX XX XX XX XX XX XX XX                XXXXXXXXXXXX

root ~ # i2cget 0 0x48
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will read from device file /dev/i2c-0, chip address 0x48, current data
address, using read byte.
Continue? [Y/n]
0x4b

root ~ # gputemp
47 C
----

I tried loading lm73 and lm75. Don't seem to do anything. I will compile 
ds1621 in the next build.

Thanks for your persistence ;-)
-- 
-- dag wieers, dag@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] i2c-i801 on AppleTV (1st gen)

[Jean Delvare]

On Thu, 7 Feb 2013 10:54:07 +0100 (CET), Dag Wieers wrote:
> It all looks good to me (system is mostly idle):
> 
> ----
> root ~ # i2cdump -r 0x3d-0x4b 0 0x48 b
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> I will probe file /dev/i2c-0, address 0x48, mode byte
> Probe range limited to 0x3d-0x4b.
> Continue? [Y/n]
>       0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
> 30:                                        XX XX XX                 XXX
> 40: XX XX XX XX XX XX XX XX XX XX XX XX                XXXXXXXXXXXX
> 
> root ~ # i2cget 0 0x48
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> I will read from device file /dev/i2c-0, chip address 0x48, current data
> address, using read byte.
> Continue? [Y/n]
> 0x4b
> 
> root ~ # gputemp
> 47 C
> ----

So no register in range 0x37-0x4b.

> I tried loading lm73 and lm75. Don't seem to do anything. I will compile 
> ds1621 in the next build.

The dump above rules out the DS75 and DS1621. Could be an LM73, but
then the lm73 driver would have found it. What did you try before
coming to the conclusion that it "don't seem to do anything"?

Next thing you can try is:

# i2cdump -r 0-0x3f 0 0x48 b

And then as usual:

# i2cget 0 0x48

> Thanks for your persistence ;-)

You're welcome.

-- 
Jean Delvare
http://khali.linux-fr.org/wishlist.html

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] i2c-i801 on AppleTV (1st gen)

[Jean Delvare]

On Thu, 7 Feb 2013 12:03:10 +0100, Jean Delvare wrote:
> The dump above rules out the DS75 and DS1621. Could be an LM73, but
> then the lm73 driver would have found it. What did you try before
> coming to the conclusion that it "don't seem to do anything"?
> 
> Next thing you can try is:
> 
> # i2cdump -r 0-0x3f 0 0x48 b
> 
> And then as usual:
> 
> # i2cget 0 0x48

Did you try? Did it return anything useful?

There is some risk so I would understand if you don't want to try, but
if you do try, I'm definitely curious to know the outcome.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] i2c-i801 on AppleTV (1st gen)

[Dag Wieers]

On Mon, 11 Feb 2013, Jean Delvare wrote:

> On Thu, 7 Feb 2013 12:03:10 +0100, Jean Delvare wrote:
>> The dump above rules out the DS75 and DS1621. Could be an LM73, but
>> then the lm73 driver would have found it. What did you try before
>> coming to the conclusion that it "don't seem to do anything"?
>>
>> Next thing you can try is:
>>
>> # i2cdump -r 0-0x3f 0 0x48 b
>>
>> And then as usual:
>>
>> # i2cget 0 0x48
>
> Did you try? Did it return anything useful?

I'll let you decide :-)

----
root ~ # i2cdump -r 0-0x3f 0 0x48 b
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0, address 0x48, mode byte
Probe range limited to 0x00-0x3f.
Continue? [Y/n] y
      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX

root ~ # i2cget 0 0x48
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will read from device file /dev/i2c-0, chip address 0x48, current data
address, using read byte.
Continue? [Y/n] y
Error: Read failed
----


What's weird is that now it behaves the same as the other device. Address 
0x48 no longer responds. Not sure if this behaviour relates to other 
changes on the system or if it was because of the above commands.

----
root ~ # 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: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- 69 -- -- -- -- -- --
70: -- -- -- -- -- -- -- -- 
----

Did I break it ? :)


-- 
-- dag wieers,    dag@wieers.com,    http://dag.wieers.com/
-- dagit linux solutions, info@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] i2c-i801 on AppleTV (1st gen)

[Jean Delvare]

On Sun, 17 Feb 2013 15:42:49 +0100 (CET), Dag Wieers wrote:
> On Mon, 11 Feb 2013, Jean Delvare wrote:
> 
> > On Thu, 7 Feb 2013 12:03:10 +0100, Jean Delvare wrote:
> >> The dump above rules out the DS75 and DS1621. Could be an LM73, but
> >> then the lm73 driver would have found it. What did you try before
> >> coming to the conclusion that it "don't seem to do anything"?
> >>
> >> Next thing you can try is:
> >>
> >> # i2cdump -r 0-0x3f 0 0x48 b
> >>
> >> And then as usual:
> >>
> >> # i2cget 0 0x48
> >
> > Did you try? Did it return anything useful?
> 
> I'll let you decide :-)
> 
> ----
> root ~ # i2cdump -r 0-0x3f 0 0x48 b
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> I will probe file /dev/i2c-0, address 0x48, mode byte
> Probe range limited to 0x00-0x3f.
> Continue? [Y/n] y
>       0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
> 00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> 10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> 20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
> 30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX

Nothing useful...

> 
> root ~ # i2cget 0 0x48
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> I will read from device file /dev/i2c-0, chip address 0x48, current data
> address, using read byte.
> Continue? [Y/n] y
> Error: Read failed
> ----

Doh :(

> 
> What's weird is that now it behaves the same as the other device. Address 
> 0x48 no longer responds. Not sure if this behaviour relates to other 
> changes on the system or if it was because of the above commands.

I'd suspect the i2c commands, but it's impossible to be sure,
especially as you did not run a "i2cget 0 0x48" right before the
i2cdump, so maybe it was already no longer replying.

> ----
> root ~ # 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: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60: -- -- -- -- -- -- -- -- -- 69 -- -- -- -- -- --
> 70: -- -- -- -- -- -- -- -- 
> ----
> 
> Did I break it ? :)

Could be. This could explain why the other system was looking
different, if something similar had already been attempted on it.
Please try powering the machine down, unplug the power cord, and cold
boot the machine at least 1 minute later. Hopefully the chip at 0x48
will be back.

If not, please let us know if you notice anything no longer working
properly on the machine. So that it can at least be documented.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] i2c-i801 on AppleTV (1st gen)

[Dag Wieers]

On Sun, 17 Feb 2013, Jean Delvare wrote:

>> Did I break it ? :)
>
> Could be. This could explain why the other system was looking
> different, if something similar had already been attempted on it.
> Please try powering the machine down, unplug the power cord, and cold
> boot the machine at least 1 minute later. Hopefully the chip at 0x48
> will be back.
>
> If not, please let us know if you notice anything no longer working
> properly on the machine. So that it can at least be documented.

The chip at 0x48 did not come back, but everything still seems to work 
fine on (both) systems. I might buy a third system, and will investigate 
again...

Thanks for your assistance !
-- 
-- dag wieers, dag@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors