Re: smb driver for Nvidia ION (intel ATOM) chipset
Jeremy Chadwick
> Oliver Lehmann wrote:
>
> > Hi,
> >
> > has anyone tried using the nfsmb(4) driver for the Nvidia ION chipset's
> > SMB controller?
> >
> > none3@pci0:0:3:5: class=0x0b4000 card=0x83f91043 chip=0x0aa310de rev=0xb1 hdr=0x00
> > vendor = 'Nvidia Corp'
> > device = 'NVIDIA nForce System Management Controller (nForce)'
> > class = processor
> >
> > I could try to just change one of the device IDs in pci/nfsmb.c to 0x0aa3
> > and see if it works but if someone has already tried this and says "won't
> > work" I can avoid maybe crashing my box ;)
>
> Adjusting the driver was kinda easy
>
> but now I'm stuck with no idea what "-c" argument I should use for mbmon..
>
> nfsmb0: <nForce2/3/4 MCP SMBus Controller> port 0x4900-0x493f,0x4d00-0x4d3f,0x4e00-0x4e3f irq 20 at device 3.2 on pci0
> smbus0: <System Management Bus> on nfsmb0
> nfsmb1: <nForce2/3/4 MCP SMBus Controller> on nfsmb0
> smbus1: <System Management Bus> on nfsmb1
> smb0: <SMBus generic I/O> on smbus0
> smb1: <SMBus generic I/O> on smbus1
> root@nudel nfsmb> mbmon -S -s0 -d
> SMBus[NVidia nForce2] found, but No HWM available on it!!
> InitMBInfo: Device not configured
> Exit 1
> root@nudel nfsmb> mbmon -S -s1 -d
> SMBus[NVidia nForce2] found, but No HWM available on it!!
> InitMBInfo: Device not configured
> Exit 1
> root@nudel nfsmb> mbmon -S -s1 -c8 1
> InitMBInfo: Device not configured
> Exit 1
> root@nudel nfsmb>
>
> ru@ provided an smbtest.c to find out where the slave devices are when he
> initially made the nfsmb driver but the file is gone from his freefall
> page...
> Maybe someone saved it somewhere?
>
> http://lists.freebsd.org/pipermail/freebsd-current/2005-December/059065.html
If you look inside /usr/ports/sysutils/mbmon/work/xmbmon205 once
the port is built (e.g. "make"), you'll find there are other utilities
for attempting to find the slave address, such as "testsmb"
Be aware that these devices can contain more than one address on the
bus. Be aware that "probing" is risky business as well -- I've seen
1) Are you certain your motherboard has a H/W monitoring IC on it?
Visual inspection of the board can help, but isn't always accurate (I've
found many boards where the silkscreening on the H/W IC does not match
what the behaviour of the chip is and therefore had to involve the
vendor to get details of chip behaviour). You'll need to look for
chips with logos from Winbond, LM, or AMD (non-north/southbridge).
2) If so, are your sure the H/W monitoring IC is tied to SMBus? If not,
LPC (classic ISA-style I/O ports) are all you'll have available. You'll
need to contact the board vendor to get this, as well as base registers
and offsets used for accessing data.
3) Finally, and most importantly, does mbmon support the exact model and
revision of H/W monitoring IC on your board? If not, you're wasting
your time. :-)
It's easy to get confused by the state of hardware monitoring on not
only FreeBSD but other OSes as well; they all make it sound like
monitoring things "just magically works with SMBus", and that isn't the
case. SMBus is just a communication architecture; the software using
SMBus still has to know what's on the other end and what offsets
correlate with what thermistors / fans / etc. and how to decode that
data (it's per-chip specific).
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
Jeremy Chadwick
> If you look inside /usr/ports/sysutils/mbmon/work/xmbmon205 once
> the port is built (e.g. "make"), you'll find there are other utilities
> for attempting to find the slave address, such as "testsmb"
>
> Be aware that these devices can contain more than one address on the
> bus. Be aware that "probing" is risky business as well -- I've seen
Oops, accidentally deleted the lines after this. :-) Should have read:
I've seen testsmb as well as my own utilities (which perform only reads
across SMBus) result in some hardware lock-ups and watchdogs firing.
It's best to be as safe/accurate as possible (the software should be
told explicitly what chip you have).
Jeremy Chadwick
> Re: smb driver for Nvidia ION (intel ATOM) chipset writes:
>
> >It's easy to get confused by the state of hardware monitoring on not
> >only FreeBSD but other OSes as well; they all make it sound like
> >monitoring things "just magically works with SMBus", and that isn't the
>
> I'v now went deeper into mbmon's source and found that stuff out
> sorta...
>
> Looks like I've to do some more research what really is on my board
> first.
>
> Using the ISA-IO access method mbmon thinks I've a LM78 and mbmon
> even works but I'm getting false numbers for probably just
> everything...
>
> root@nudel xmbmon205> mbmon
>
> Temp.= 185.0, 0.0, 0.0; Rot.= 835, 30681, 18750
> Vcore = 1.10, 1.81; Volt. = 3.39, 4.95, 8.21, -7.51, -3.24
> ^C
This is the exact sort of situation I was referring to -- at this point
your system may be unstable. The mbmon software has initiated a raw LPC
(ISA) I/O request on a port which obviously is not tied to an LM78 H/W
monitoring IC. Who knows what all of the writes and reads to those
offsets just did.
I would recommend you reboot and/or power cycle this box ASAP given the
nature of what transpired. One has to be very careful when operating
with /dev/io that the proper (LPC/ISA) ports are used. The same applies
to most bus architectures (SMBus, PCI, etc.), though in the case of PCI,
there's existing infrastructure to find out what's on the bus properly.
There isn't such with SMBus and LPC/ISA.
Now you see why I strongly discourage auto probing. :-)
> root@nudel xmbmon205> mbmon -d
> SMBus[NVidia nForce2] found, but No HWM available on it!!
> Using ISA-IO access method!!
> * Nat.Semi.Con. Chip LM78 found.
> root@nudel xmbmon205>
Yeah, this looks like a very bad assumption made by the software.
You're very likely going to have to end up mailing the board
manufacturer/vendor and asking them -- that is, assuming there's a H/W
monitoring IC on the board at all.
If you have access to Windows 2K/XP, you might try using some software
there called SpeedFan. If it works, you'll be able to at least figure
out what H/W monitoring IC is used, and if it's via SMBus or LPC/ISA.
What registers, slave address, etc. it uses are a different matter
altogether (I'm not sure the software discloses that).
Oliver Lehmann
> I'll go and find some information about what HWM chip is tied on that
> board...
regarding to
http://ubuntuforums.org/showthread.php?t=1199797&page=4
It got an ITE 87 sensor... This is what Linux detects:
Driver `it87':
* ISA bus, address 0x290
Chip `ITE IT8720F Super IO Sensors' (confidence: 9)
Driver `coretemp':
* Chip `Intel Core family thermal sensor' (confidence: 9)
So now I just need to find out why the it87 gets not choosen by mbmon...
maybe the 8720 is just not supported right now - I'll probably have to take
a look at Linux lm-sensors since it is working there...
"Int.Tec.Exp. Chip IT8705F/IT8712F or SIS950"
Oliver Lehmann
> It's easy to get confused by the state of hardware monitoring on not
> only FreeBSD but other OSes as well; they all make it sound like
> monitoring things "just magically works with SMBus", and that isn't the
This is what I was thinking so far - yeah exactly ;)
I'v now went deeper into mbmon's source and found that stuff out sorta...
Looks like I've to do some more research what really is on my board first.
Using the ISA-IO access method mbmon thinks I've a LM78 and mbmon even
works but I'm getting false numbers for probably just everything...
root@nudel xmbmon205> mbmon
Temp.= 185.0, 0.0, 0.0; Rot.= 835, 30681, 18750
Vcore = 1.10, 1.81; Volt. = 3.39, 4.95, 8.21, -7.51, -3.24
^C
root@nudel xmbmon205> mbmon -d
SMBus[NVidia nForce2] found, but No HWM available on it!!
Using ISA-IO access method!!
* Nat.Semi.Con. Chip LM78 found.
root@nudel xmbmon205>
When working with mbmon -S it comes to the conclusion that I have a lm75
(or maybe it thinks just that because it is the last of the supported HWM
entries in the HWM_module array) but when probing it in lm75_probe it
fails...
i = set_smb_Extemp(LM75_ADDR_START, LM75_ADDR_END,
&smb_wbtemp1, &smb_wbtemp2);
temp1_flag = i >> 1;
temp2_flag = i & 0x01;
if (temp1_flag && temp2_flag)
return 0;
it returns 0 there and this is what probe_HWMChip does not like (it expects
!= 0).
Jeremy Chadwick
> Re: smb driver for Nvidia ION (intel ATOM) chipset writes:
>
> >I'll go and find some information about what HWM chip is tied on
> >that board...
>
> regarding to
>
> http://ubuntuforums.org/showthread.php?t=1199797&page=4
>
> It got an ITE 87 sensor... This is what Linux detects:
>
> Driver `it87':
> * ISA bus, address 0x290
> Chip `ITE IT8720F Super IO Sensors' (confidence: 9)
I don't know if lmsensors on Linux supports SMBus or not, but it looks
like (based on the above) that you should be able to communicate with
the IT8720F chip using LPC/ISA on port 0x290.
I'm pretty sure the ITE chips have their specifications and engineering
datasheets publicly available.
My guess is that mbmon lacks support for this specific IC, or has buggy
support. For example, it may have "IT87 support", but maybe only for
IT8705F and not for IT8720F; this is why vague classifications and
lumping multiple devices under one hood is often a bad idea.
> Driver `coretemp':
> * Chip `Intel Core family thermal sensor' (confidence: 9)
CPU core temperatures for that CPU family come directly from the CPU
itself, and not usually through a H/W monitoring IC (though sometimes
they can be routed through PECI; gotta love acronyms!).
FreeBSD has the coretemp(4) driver for Intel CPUs and the amdtemp(4)
driver for AMD CPUs; this should suffice for monitoring your CPU cores.
Intel and AMD both started adding on-die thermal monitoring to their
CPUs somewhat recently (past 3-4 years).
> So now I just need to find out why the it87 gets not choosen by
> mbmon... maybe the 8720 is just not supported right now - I'll
> probably have to take a look at Linux lm-sensors since it is working
> there...
>
> "Int.Tec.Exp. Chip IT8705F/IT8712F or SIS950"
Good luck -- I've spent hours upon hours digging through lmsensors, and
the code is quite possibly the worst bunch of spaghetti I've ever seen.
I'd recommend going straight to the datasheets.
If you'd like, I can code up something that uses LPC/ISA to communicate
with this IC via port 0x290 based on the datasheet. It's pretty easy,
but will require that the program be run as root (to open /dev/io). I
won't integrate it into bsdhwmon because that software strictly uses
SMBus.
Oliver Lehmann
> I've attached the patch for sens_it87.c
Which was broken.... I attached the correct one.
--
Oliver Lehmann
http://www.pofo.de/
http://wishlist.ans-netz.de/
Oliver Lehmann
> If you'd like, I can code up something that uses LPC/ISA to communicate
> with this IC via port 0x290 based on the datasheet.
I now was able to "hack up" mbmon to communicate with my it8720 sensor.
I've attached the patch for sens_it87.c
I also added to Makefile to the DEFS = line "-DIT8720" of course. This
made mbmon working with ISA-IO mode working. I'm now getting the
following outputs:
Temp.= 32.0, 34.0, 22.0; Rot.= 4591, 1298, 0
Vcore = 1.10, 1.81; Volt. = 3.39, 4.95, 11.93, -11.93, -4.99
I can nearly verify all values with the BIOS and they are matching. I
XXed in the following output (same as above) all values out I was not
able to verify because the BIOS-HWM does not show their values:
Temp.= 32.0, XXX, XXX; Rot.= 4591, 1298, 0
Vcore = 1.10, XXXX; Volt. = 3.39, 4.95, 11.93, -11.93, XXXXX
For the remaining values I'm pretty sure they are correct.
I enabled the 16Bit RPM mode for the 8720. In this case no devisor is
needed for calculating the RPM. I was not able to get the 2nd FAN-RPM
right in the 8Bit mode. The 1st one was correct even in the 8Bit mode.
About the voltage multipliers... I'm not sure about the last one because
I'm not able to verify this (I could with a multimeter of course but this
would create other deviations).
I'm also not sure why the multipliers (for my board?) are different. I
wonder why they are hardcoded there anyway. I can imagine that they are
depending the board layout or am I mistaken? I mean the IT spec says only
that the input of the pins need to be in the range between 0 and VCC. So
I can choose whatever multiplier I like as long as the resulting voltage
keeps within this range. Keeping the measured voltage somewhere in the
middle of 0 and VCC with the multiplier for the expected value makes
sense but this is no "must be" I guess
Now - since ISA-IO is working I want to get smbus working too ;)
First I patched src/sys/pci/nfsmb.c to detect the known remaning nforce
SMB controllers including mine.
I then added the device-id of this controller to the pci_pm.h file of
mbmon to make it detect my controller.
But now it still fails to find the it87 sensor on the bus. I guess the
bus can have many "slaves" and mbmon just needs to test all to find out
which identifies itself as it87? (reading from Adress 0x58 should return
0x90 - at least in ISA mode)
root@nudel xmbmon205> ./mbmon -S -D -p it87
Probe Request: it87
>>> Testing Reg's at SMBus <<<
SMBus slave 0xA0(0x50) found...
SMBus slave 0xA2(0x51) found...
SMBus slave 0xA4(0x52) found...
SMBus slave 0xA6(0x53) found...
SMBus slave 0xA8(0x54) found...
SMBus slave 0xAA(0x55) found...
SMBus slave 0xAC(0x56) found...
SMBus slave 0xAE(0x57) found...
SMBus[NVidia nForce2] found, but No HWM available on it!!
InitMBInfo: Device not configured
Exit 1
root@nudel xmbmon205> ./mbmon -S -s1 -D -p it87
Probe Request: it87
>>> Testing Reg's at SMBus <<<
SMBus slave 0xA0(0x50) found...
SMBus slave 0xA2(0x51) found...
SMBus slave 0xE0(0x70) found...
SMBus[NVidia nForce2] found, but No HWM available on it!!
InitMBInfo: Device not configured
Exit 1
root@nudel xmbmon205>
But it looks like at least the smb detection code for it87 is not working
for mine...
Any ideas how to proceed here?
(I have basic C skills and know something about electronics (can build a
Z80 SBC for example ;))