[lm-sensors] Using lm_sensors for accessing SMSC EMC6W201
fhj-52 at sbcglobal.net
Thu Jun 15 05:33:13 CEST 2006
I am pretty sure that the +5VDC as well as the +12VDC lines are not monitored
on this chip and this mobo. Both of those values, as well as the 5VStby and
Vbat readings, from the output of the 8712F readings look reasonable. The
value for the 5VDC here is way off( but that might be the way I got the value
The reading registers(hex), names, nominal values and what each is:
20, 2.5VDC, 2.5 VDC nominal, for ??? on ...???...
21, V1.5P1, 1.5 VDC nominal, for CPU0
22, VCC, 3.3 VDC nominal, for chip, or line or VTR ...?...
23, +5V, 5.0 VDC nominal, for ...???...
24, 1.5VDC, 1.5 VDC nominal, for 1.5V on ...???...
25, V1.5P2, 1.5 VDC nominal, for CPU1
The DS info on Analog Voltages does not have much that makes a lot of sense(to
me) but ithink I figured out that what they were trying to say is that to get
the Voltage value:
take the read value, convert to decimal, multiply by the factor and add
0.5*factor to the result; one then has the closest truth to the actual value.
I saw no info about the accuracy/tolerance(yet) but if it is like the
temps(+/- 3*c), the above method will provide as good a result as an end user
The "factor" is the scaling factor obtained from a chart.
Each voltage I/O has it's own "3/4" scale/factor:
5VDC is 0.026
3.3VDC is 0.0172
1.5VDC is 0.008
2.5VDC is 0.013
But there is a range too(see chart) so multiplying by the factor is not going
to give the best value to report. It will be on the low end so adding
1/2*factor to the result of factor*decimal coversion of hex reading will give
a closer to truth value. There's a mathematical term for that which I am sure
to rem' just _after_ I press the send button. :)
Readings same as from yesterday _and_ just now(no change)
20 21 22 23 24 25 Registers
c8 b0 bb 64 c0 b3 hex values
200 176 187 100 192 179 decimal equiv's
Register 20 is the 2.5VDC reading output value which has no use unless GBT has
connected it to something that uses 2.5V. I don't know what that could be.
...whatever it is, it reads ~ 2.6 + 0.0065 => 2.606VDC
Register 21 is the 1.5VDC P1(CPU0 core volts) reading output value
176*0.008 = 1.408 => 1.412VDC
Register 25 is the 1.5VDC P2(CPU1 core volts) reading output value
179*0.008 = 1.432 => 1.436VDC
Those are very close to what they should be(1.35 - 1.40) _and_
considering that GBT OVERCLOCKS this mobo, those are probably dead-on. IIRC,
nVidia's nTune showed the voltage as > 1.4VDC as well as DDR at 402, HT @
Register 22 is the 3.3VDC VCC reading output value
187*0.0172 = 3.2164 => 3.225VDC
That's close ... close enuf to be a real value considering I have a little
problem with the PSU, or so it seems(12VDC runs low too). That is one of the
reasons we need to get lm_sensors working correctly for this chip. ...
Register 23 is the 5VDC reading output value
100*0.026 = 2.6 => ridiculous!
... that cannot be correct!!
Perhaps GBT does not use the 6W201 for 5V voltage either ... ???
Interestingly, the 8712F obtained value is 4.97VDC which is prbly correct.
Register 24 is the nominal 1.5V value but, really, we do not know what it is
so don't care.
What they (SMSC) say:
The chip updates the registers at least 4 times per second.
The device compares the inputs(voltages) against a known (internal) reference
source ... scales the inputs internally " such that the correct value refers
to 3/4 scale or 192 decimal."
" Voltages in the Registers are presented at 3/4 full scale for the nominal
voltage, meaning that at nominal voltage, each register will read c0h. "
...iDontHaveaFrigginClue what that *really* means; am pretty sure the editor
cut the sentences that would have made that make sense to non bit-byters. It
does not mean the value in the register is 75% of the full correct value.
There's a ADC Voltage Conversion chart on PDF page 145 of the DS(p133 of doc).
What I get here by using the method above agrees with what I know to be true
but it could be coincedence. I do not know of any way to test/verify it. The
BIOS HW readings do not show the CPU voltages. The 3.3VDC is always a little
bit low. If the method is wrong or there is a better way, I would surely like
Please do not think that I am going to hunt you down and hurt you for
correcting me. I would never do that.(
http://regmedia.co.uk/2001/09/12/joke_alert.gif ) :)
--- Philip Pokorny <ppokorny at penguincomputing.com> wrote:
> Ric Johnson wrote:
> >There is no URL as GBT sent the Datasheet to me. It is PDF. I can send it
> >do not have a web server at this time so cannot post it.
> It would *really* help if we could see the datasheet. How big is it?
> >The DS says the "default slave adddress is 0101110b" and GBT told me they
> >"followed SMSC recommendations" ...
> >There is a table showing
> > "SMBUS Address[7:1] " as 0101 110b which is suppose is the same as 101110
> >binary or 2E hex.
> Yes, that's the default address.
> >i2cdetect -l returns nothing. I am not sure why since lsmod has quite a
> >"i2c*" items in it while sensors is running.
> Perhaps that's a bug with i2cdetect... We can follow up on that problem
> >#> 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: XX XX XX XX XX 08 XX XX XX XX XX XX XX
> >10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
> >20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
> >30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
> >40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
> >50: XX XX UU UU XX XX UU UU XX XX XX XX XX XX XX XX
> >60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
> >70: XX XX XX XX XX XX XX XX
> No, that's probably just your memory DIMM's (at 52, 53, 56, 67) (do you
> have 4 DIMM's installed?) Not sure what might be at address 0x08...
> >I have run i2cdump 0 0x2e but the results are only "XX". Perhaps that is
> >wrong command parameter/address ...
> That's because there is no device at address 0x2e on bus 0. Note the XX
> in square 20 x e in the output above.
> >Since it *looks* like i2c-1 is where all the easter eggs are hidden, I did
> >dump and got all kinds of stuff:
> Perfect, the output from 'i2cdetect -l' would have listed what busses
> you have and we would have gotten around to asking you to 'i2cdetect 1'
> and so on, but you've figured that out for yourself. Excellent...
> >#> i2cdump 1 0x2e
> >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-1, address 0x2e, mode byte
> >Continue? [Y/n]
> > 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
> >00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> >10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> >20: c8 b0 bb 64 c0 b3 2d 17 31 1b 16 22 c4 0c 37 0e ???d??-?1??"??7?
> >30: 52 0e 40 0d 1a 07 80 80 80 00 00 00 00 00 5c b1 R?@??????.....\?
> >40: 05 00 00 00 00 00 00 00 3e 00 00 ff 00 ff 00 ff ?.......>.......
> >50: 00 ff 00 ff 00 ff 81 7f 81 7f 81 7f 81 7f 81 7f ......??????????
> >60: 81 7f ff ff ff ff ff ff ff ff ff ff 00 00 00 ff ??..............
> >70: 00 ff 00 ff 00 ff 00 ff 00 ff fc 3e 7e 00 00 00 ..........?>~...
> >80: e2 e2 e2 99 90 cc cc cc 00 00 80 80 80 00 00 00 ????????..???...
> >90: 23 23 23 23 23 23 64 64 64 64 64 64 44 44 44 94 ######ddddddDDD?
> >a0: 00 40 80 00 04 04 04 04 2c 2c 2c 00 0a 00 2d 2d .@?.????,,,.?.--
> >b0: 2d 2d 2d 2d 00 00 00 00 a0 00 05 25 12 ff ff 00 ----....?.?%?...
> >c0: 00 00 00 00 7f 7f 7f 7f 7f 7f c0 00 00 00 00 00 ....???????.....
> >d0: 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
> >e0: 00 00 c0 8a 68 00 20 00 1c 00 00 00 00 00 00 00 ..??h. .?.......
> >f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> >It's 22:24:24 CDT (UTC-0500) on Tue Jun 13, week 24 in 2006.
> >OF course, that might be an eeprom or something.
> No, that's probably your chip. Go ahead and try i2cdump on one of your
> eeproms 'i2cdump 0 0x52' and you'll see that the output is very different.
> >Any ideas?
> Yes, but without the data sheet it's just speculation...
> I would say that you appear to have 6 voltage sensors (0x20-25), and 6
> temperature sensors (as you said previously, 0x26-2b). I'm going to
> guess that you have five (5) 16-bit fan speed sensors (0x2c-35).
> The device ID signature registers are probably 0x3e (value 0x5c) and
> 0x3f (value 0xb1)
> The min/max limits for the voltages probably start at 0x4a through
> 0x55. Then the limits for the temperatures (0x56-0x61) and fan speeds
> I would guess that the rest of the registers are perhaps fan speed
> control or some other features on the chip. Hopefully they are
> described in the datasheet.
> If that's correct, then we just need to know what the scaling values are
> for the voltages and the fan speed equation. And your temperatures are:
> 2d = 45 degC
> 17 = 23 degC
> 31 = 49 degC
> 1b = 27 degC
> 16 = 22 degC
> 22 = 34 degC
> If that's right, the temperatures appear to be rather low. Do you have this
> machine in a cooled computer room?
" He has achieved success who has lived well, laughed often, and loved much; who has enjoyed the trust of pure women, the respect of intelligent men and the love of little children; who has filled his niche and accomplished his task; who has left the world better than he found it whether by an improved poppy, a perfect poem, or a rescued soul; who has never lacked appreciation of Earth's beauty or failed to express it; who has always looked for the best in others and given them the best he had; whose life was an inspiration; whose memory a benediction. "
- Bessie A. Stanley( Published in Lincoln Sentinel, Nov. 30, 1905 )
More information about the lm-sensors