SMBus driver and Windows XP - recommended reading?

NTDEV
1

Hi!

My customer came with a quite unusual request - Linux / Windows XP
driver for a custom peripheral attached to the ICH8 chipset’s SMBus. The
device is essentially an I2C accessed device, nothing special. While
Linux part is pretty much straightforward and well-defined, Windows is
much more confusing.

Basically I expect Windows to provide some abstraction of the SMBus, yet
I don’t know which of the docs I’ve found apply to WinXP. What are the
interfaces available to talk to SMBus on Windows XP?

As far as I understand, at the OS <-> Hardware level, firmware exposes
SMBus via ACPI EmbeddedController or SMBus CMI interface. Is this always
the case?

Any hints/pointers welcome!

Best Regards,
Przemyslaw

2

In general, Windows expects the BIOS to be the one that talks to the SMBus.

Assuming you have control of the BIOS, you can create methods in the BIOS to talk to whatever you want. You can then have the BIOS surface a device via ACPI, and have your driver invoke those methods.

Peter
OSR

3

Thanks!

Correct me if I’m wrong, but it means essentially that we’d need to:
* implement all the necessary control methods in DSDT
* at the driver level use generic ACPI API to evaluate the control method (IOCTL_ACPI_EVAL_METHOD IRP, I suppose).

This seems possible, yet quite complicated (I’d need to convince the customer to customize DSDT). Is that the only way?

BR,
Przemyslaw

4

> This seems possible, yet quite complicated (I’d need to convince the customer to customize DSDT). Is that the only

way?

This whole area is rather dark and unsupported, with BIOS/mobo vendors create custom solutions not recommended by MS for temperature/voltage/fan control (like AsusProbe and its ATK0110 pseudo-device, and this is not the worst colution - the worst solutions use PortIO-style drivers to ping the SMBus controller’s ports directly).

For instance, let’s talk about exposing ACPI facilities for fans and temperature/voltage probes to WMI. I think only Intel’s expensive servers use this. I personally never ever saw a laptop or a motherboard where this works.

Also note there is some “Intel SMBus Controller driver”. I don’t know how it works and what software is using it.

So, you have the following picture:

  • MS insists that all SMBus stuff must be BIOS-controlled, i.e. ACPI-controlled, and that the software should operate with SMBus via ACPI or even WMI.
  • nevertheless, the BIOS vendors do not provide this facility in their BIOSes, so MS-recommended ACPI- and WMI- ways of operating SMBus just plain do not work on anything except possible expensive Intel’s servers.
  • and, since MS does not provide any BIOS-independent SMBus stuff (it used to do so, but, in Win7 WDK, this stuff was revoked) - then you have just plain no SMBus architecture support in Windows at all.
  • and the only solutions are chipset-dependent and mobo-dependent.

This is a significant weak point of the Windows ecosystem. Actually, the joint policy of MS and the hardware makers lead this particular thing to undocumened unstable close-to-hardware hackery.

Effectively, the status of SMBus in Windows is: Windows does not support SMBus, use hardware-dependent hacks of your own.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

5

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
…
> This is a significant weak point of the Windows ecosystem. Actually, the
> joint policy of MS and the hardware makers lead this particular thing to
> undocumened unstable close-to-hardware hackery.
>
> Effectively, the status of SMBus in Windows is: Windows does not support
> SMBus, use hardware-dependent hacks of your own.

In the MS world all hardware belongs to one of 3 kinds: designed for
Windows, somewhat compatible with Windows and all the rest.
The smbus connected things are the latter.
Linux accepts much broader range of hardware, OTOH it runs on much broader
set of platforms anyway.

– pa

6

Thanks *a lot* for your response, it was really helpful.

Actually the team I cooperate with proposed exactly the PortIO-style solution. Seeing potential problems (concurrent access, to say the least), I’m trying to find a better applicable solution. Note, that there are only 2 chipsets to support (ICH8 and QM57), which narrows the problem a little bit.

BTW, disassembling DSDT on my 2 PCs confirmed what you say - there is no single entity related to SMBus, really. That makes me wonder about how is it really done at OS level. The Device Manager (Win7) shows “Intel(R) ICH9 Family SMBus Controller” node attached to PCI 1F.03 device, yet with no driver files attached, so it’s just a stub to make PCI enumeration happy. I guess that the code talking to the SMBus host is thus inside of another ICH8 chipset related driver.

Do you mind describing briefly what was the pre-Win7 situation? Was there any common SMBus API exposed to the driver developers?

Also I’ve found a documentation for a BIOS int interface for controlling SMBus - is it really in use?

BR,
Przemek

7

For the record, I don’t consider Windows approach to the SMBUS “unstable close to the hardware hackery” as Max apparently does.

Well, it’s to avoid a yellow bang in device manager, really.

No… there IS no code in Windows that talks to the SMBUS host controller. Like I said earlier, Windows leaves this to the BIOS.

Like I told you in my first post: “Windows expects the BIOS to be the one that talks to the SMBus.” I’m not guessing here. I work in this area a lot.

There was a very narrowly defined class driver API back in Windows XP. To the best of my knowledge, it never worked properly, and was only used in two very specific implementations.

All the Intel SMBUS host registers in the ICH/PCH are pretty much the same. So, ICH8, ICH11, whatever… no change.

So, if you really wanted to you could uninstall the Intel SMBUS “driver” (which, as you said, is no driver at all) and install your own. The problem with this, of course, is that you’d need some way to ensure that nobody else tried to do this at the same time. For this to work, you need to be sure that the SMBUS host controller is configured to generate “normal” IRQs and not SMIs or whatever.

Bottom line: Windows really considers the SMBUS to be the province of the BIOS. This is because in most PCs the SMBUS is actually used for a wide variety of things, from configuring the memory to reporting POST codes to interfacing with the network card at power down/up. None of these things is under Windows control, so Windows just stays out of the world of SMBUS.

Therefore, the recommended solution would most typically be to change the BIOS code to do what you want. That could include surfacing a device via ACPI with methods that you can then invoke via IOCTL_ACPI_EVAL_METHOD.

On the other hand you COULD write a Windows driver that talks to the SMBUS host controller in the ICH/PCH. The main problem with that approach is suppose YOU want to talk to the SMBUS host controller, and somebody ELSE’s driver wants to talk to the SMBUS host controller.

I guess it depends on what you want to do, what you’re connecting, and who your client is. If you’re writing a driver for a big OEM, changing the BIOS is no big thing. If you’re writing a driver for some little vendor who thinks they’ve thought of a clever idea by connecting their device via the SMBUS, that might be a good thing or not, depending.

Peter
OSR

8

The other issue is that the BIOS is expecting to use the SMBus controller through a firmware interface, so taking over the controller in a driver could end up hosing the BIOS. Best to handle this through the BIOS.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Thursday, September 29, 2011 11:16 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] SMBus driver and Windows XP - recommended reading?

For the record, I don’t consider Windows approach to the SMBUS “unstable close to the hardware hackery” as Max apparently does.

Well, it’s to avoid a yellow bang in device manager, really.

No… there IS no code in Windows that talks to the SMBUS host controller. Like I said earlier, Windows leaves this to the BIOS.

Like I told you in my first post: “Windows expects the BIOS to be the one that talks to the SMBus.” I’m not guessing here. I work in this area a lot.

There was a very narrowly defined class driver API back in Windows XP. To the best of my knowledge, it never worked properly, and was only used in two very specific implementations.

All the Intel SMBUS host registers in the ICH/PCH are pretty much the same. So, ICH8, ICH11, whatever… no change.

So, if you really wanted to you could uninstall the Intel SMBUS “driver” (which, as you said, is no driver at all) and install your own. The problem with this, of course, is that you’d need some way to ensure that nobody else tried to do this at the same time. For this to work, you need to be sure that the SMBUS host controller is configured to generate “normal” IRQs and not SMIs or whatever.

Bottom line: Windows really considers the SMBUS to be the province of the BIOS. This is because in most PCs the SMBUS is actually used for a wide variety of things, from configuring the memory to reporting POST codes to interfacing with the network card at power down/up. None of these things is under Windows control, so Windows just stays out of the world of SMBUS.

Therefore, the recommended solution would most typically be to change the BIOS code to do what you want. That could include surfacing a device via ACPI with methods that you can then invoke via IOCTL_ACPI_EVAL_METHOD.

On the other hand you COULD write a Windows driver that talks to the SMBUS host controller in the ICH/PCH. The main problem with that approach is suppose YOU want to talk to the SMBUS host controller, and somebody ELSE’s driver wants to talk to the SMBUS host controller.

I guess it depends on what you want to do, what you’re connecting, and who your client is. If you’re writing a driver for a big OEM, changing the BIOS is no big thing. If you’re writing a driver for some little vendor who thinks they’ve thought of a clever idea by connecting their device via the SMBUS, that might be a good thing or not, depending.

Peter
OSR

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

9

> For the record, I don’t consider Windows approach to the SMBUS “unstable close to the hardware hackery” as

Max apparently does.

Peter,

let’s look at the picture from both sides.

a) As you can see, the vast majority of Windows-based laptops and MBs just plain do not have the BIOS support needed by Windows approach.

Well, Asus has one, but using a driver with proprietary and maybe even limited upper-level interface.

So, the SMBus stuff is absolutely closed for most developers, and they need to resort to hacks to access SMBus.

Why not the BIOS vendors expose fans and temperatures via WMI? this is just a question of correct ACPI table for “ACPI Fan” and similar objects.

b) On the other side: SMBus device cannot be plugged to a computer. They are all soldered to the MB. This means that the MB vendor has ultimate control over all SMBus stuff in the machine, and so, why not expose it using BIOS?

The one who has the power of installing SMBus device to the machine also has the power to provide access to it using fake devnode in the ACPI table. At least like Asus does this, or even better - with WMI support or published IOCTL API.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

10

Well… they have the BIOS support that they need… nothing more and nothing less. The DIMMS get properly setup, right? The netcard’s Wake On LAN works, right? So, the interaction between the BIOS and the SMBUS works just fine in Windows systems.

In terms of fans and temps… I’d suggest that most BIOSes regulate the speed of their fans perfectly well. In terms of exposing things as WMI objects, well… who cares, really? Obviously not enough people to make the OEMs tell the BIOS vendors to make this happen.

To repeat, Windows just does not view the SMBUS as something that the OS cares about or wants to get involved in. That’s a conscious decision.

People want to fool with SMBUS on occasion for add-on stuff, and the answer is always the same: No problems if you have access to the BIOS. Just now, as we see Windows 8 on the horizon, there happens to be a move to attach certain devices to the SMBUS on which I won’t comment further. So there are a bunch of folks out looking at solutions and stopgaps prior to Windows 8 to support some of these devices. This is fine, but the answer is still the same “No problem if you have access to the BIOS.” If you want to access the SMBUS some other way, that’s fine, but Windows isn’t part of it.

Peter
OSR

11

SMBus is not generally a pluggable bus. It’s on the system board, and all the parts attached to it are generally chose by the system board manufacturer. The BIOS is also on the system board.

The “Windows approach” to SMBus is that it’s irrelevant. The ACPI BIOS exposes the things on the system board that Windows needs to control through ACPI objects & methods. There’s no compelling reason to expose additional SMBus functionality to the OS just for the heck of it.

It’s not a general purpose bus. There’s no reason to treat it as such.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Thursday, September 29, 2011 12:45 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] SMBus driver and Windows XP - recommended reading?

For the record, I don’t consider Windows approach to the SMBUS
“unstable close to the hardware hackery” as Max apparently does.

Peter,

let’s look at the picture from both sides.

a) As you can see, the vast majority of Windows-based laptops and MBs just plain do not have the BIOS support needed by Windows approach.

Well, Asus has one, but using a driver with proprietary and maybe even limited upper-level interface.

So, the SMBus stuff is absolutely closed for most developers, and they need to resort to hacks to access SMBus.

Why not the BIOS vendors expose fans and temperatures via WMI? this is just a question of correct ACPI table for “ACPI Fan” and similar objects.

b) On the other side: SMBus device cannot be plugged to a computer. They are all soldered to the MB. This means that the MB vendor has ultimate control over all SMBus stuff in the machine, and so, why not expose it using BIOS?

The one who has the power of installing SMBus device to the machine also has the power to provide access to it using fake devnode in the ACPI table. At least like Asus does this, or even better - with WMI support or published IOCTL API.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

12

Hi Peter!

Thanks for you post.

Speaking about a customer - they’re a small OEM provided specialized industrial PCs (NDA stops me from giving more details), I doubt they have enough “power” to dig into the BIOS/ACPI level. Personally I believe their choice of SMBus was influenced by hardware designers, with no software troubles in mind. It was simply the cheapest solution from the PCB design/BOM point of view. There are 2 custom devices attached - both are more or less simple GPIO chips controller via I2C or SMBus (i.e. dirt cheap).

Saying that Windows leaves the SMbus stuff to BIOS, do you mean that Windows only relies on higher-level services provided by BIOS? I probably incorrectly assumed that Windows needs to access SMBus directly for anything (e.g. SPD EEPROMs). But if I understand you correctly, all SMBus-attached devices are really controller by BIOS, with rare exceptions.

I perfectly understand the risks imposed by accessing the SMBus host registers directly, bypassing the BIOS/firmware (or whatever can possibly try to control this peripheral at the same time). I’m wondering what is the bus utilization after the boot phase, when the system is up and running? Of course I expect it to vary, depending on what is actually attached to SMBus on a particular motherboard.

Apologies, if my questions sound silly, but I have a slightly different background (Linux, embedded systems, PCI/USB drivers), and SMBus is a new land for me - I need to build a “big picture” first.

BR,
Przemek

13

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…

> The one who has the power of installing SMBus device to the machine also
> has the power to provide access to it using fake devnode in the ACPI
> table. At least like Asus does this …

Is it possible to patch or override ACPI tables to define an ACPI device on
smbus?
(I’m asking out of curiosity, but can get a similar task soon.)
– pa

14

> On the other hand you COULD write a Windows driver that talks to the SMBUS host controller

in the ICH/PCH.

Sure…

The main problem with that approach is suppose YOU want to talk to the
SMBUS host controller, and somebody ELSE’s driver wants to talk to the SMBUS host controller.

I just don’t see how it may apply to the OP’s situation…

He works for OEM, and all devices attached to SMBUS are known in advance by the very definition of SMBUS, right. Furthermore, he made it clear that they produce some specialized industrial PCs. Therefore, it looks like we are speaking about the system that is pretty closed (probably even embedded one), so that everything is known in advance …

What the OP can do here is to provide his own I2C stack ( that, apparently, he can port from Linux relatively easily, taking into consideration that Windows does not support SMBUS so that there is nothing to get into the conflict with). As far as interactions with Windows OS are concerned, he can write a function driver for SMBUS controller that happens to be PCI device and, hence, gets enumerated by Windows. This is the lower edge. On the upper one he can make his driver expose any interface he likes, and write drivers for SMBUS devices that communicate with his SMBUS controller’s driver via this interface - once Windows does not support SMBUS anyway there is no need to expose it to the child devices as a classical WDM bus driver, right. Therefore, he can borrow almost everything right from the Linux sources - I2C subsystem core and i2c-i801.c that deals with the specific details of SMBUS controller for the wide range of Intel chipsets (including the ones he targets) seem to be of particular relevance here…

I remember a thread around a year ago where I was laughing at some stupid poster who wanted to mess around with SMBUS controller. However, this is a different situation - judging from the way OP presented his questions he has all the skills and understanding required to handle this task…

Anton Bassov

15

On 09/30/2011 09:24 AM, xxxxx@hotmail.com wrote:

> The main problem with that approach is suppose YOU want to talk to the
> SMBUS host controller, and somebody ELSE’s driver wants to talk to the SMBUS host controller.
I just don’t see how it may apply to the OP’s situation…

He works for OEM, and all devices attached to SMBUS are known in advance by the very definition of SMBUS, right. Furthermore, he made it clear that they produce some specialized industrial PCs. Therefore, it looks like we are speaking about the system that is pretty closed (probably even embedded one), so that everything is known in advance …
That’s true. The hardware is pretty much fixed. Unfortunately, it was
not yet delivered to me - I will know a bit more about it in a few days,
hopefully.

As far as interactions with Windows OS are concerned, he can write a function driver for SMBUS controller that happens to be PCI device and, hence, gets enumerated by Windows. This is the lower edge. On the upper one he can make his driver expose any interface he likes, and write drivers for SMBUS devices that communicate with his SMBUS controller’s driver via this interface

That’s my understanding as well. We actually have some code already that
talks directly to ICH registers to control SMBus. Yet I really consider
it a hack (not only because it’s a user-space code, using PortIO), and
I’m concerned about interactions with other components. And I mostly
mean BIOS here, as Windows doesn’t seem involved, at least not directly,
and I do not expect any new devices on SMBus (and thus no more 3rd party
drivers fighting with mine :wink: ).

And that’s essentially my last open issue - I’m not sure if/how is the
BIOS going to utilize the bus after the system is booted (obviously BIOS
would use SMBus to query DIMM SPDs, send POST codes, etc. - but it is
all the boot time). I understand it is very much BIOS/hardware specific
(at least it depends on what is actually connected to SMBus in my hardware).

BTW, googling around I’ve found this interesting post:
http://lwn.net/Articles/349954/
“This driver can give BIOS a chance to avoid SMBus access conflicts on
runtime.” comment doesn’t make me feel any better.

  • once Windows does not support SMBUS anyway there is no need to expose it to the child devices as a classical WDM bus driver, right. Therefore, he can borrow almost everything right from the Linux sources - I2C subsystem core and i2c-i801.c that deals with the specific details of SMBUS controller for the wide range of Intel chipsets (including the ones he targets) seem to be of particular relevance here…
    Exactly. Actually, I’m already after the lecture of i2c-i801.c. SMBus
    host is not a rocket science, anyway. So is driving a basic PCI driver.
    Concurrent access is my only concern now.
    I remember a thread around a year ago where I was laughing at some stupid poster who wanted to mess around with SMBUS controller. However, this is a different situation - judging from the way OP presented his questions he has all the skills and understanding required to handle this task…
    :slight_smile:

BR,
Przemek

16

>services provided by BIOS? I probably incorrectly assumed that Windows needs to access SMBus directly for

anything (e.g. SPD EEPROMs).

Why Windows ever needs SPD EEPROMs? This is BIOS’s stuff.

Windows itself is fine without any access to SMBus at all.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

17

> And that’s essentially my last open issue - I’m not sure if/how is the

BIOS going to utilize the bus after the system is booted

You don’t know. BIOS can have a bulk of SMM code which actually runs as an embedded controller (completely transparent to the OS) and controls the things like fan speeds.

So, you can either contact the BIOS vendor to expose your new devices in the ACPI tables, and, if this will fail, then do as Anton suggested.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

18

On 2011-09-30 11:32, Maxim S. Shatskih wrote:

> services provided by BIOS? I probably incorrectly assumed that Windows needs to access SMBus directly for
> anything (e.g. SPD EEPROMs).
Why Windows ever needs SPD EEPROMs? This is BIOS’s stuff.
Yes, that was exactly my incorrect assumption, that Windows might want
it for any (e.g. diagnostic) reasons.

Windows itself is fine without any access to SMBus at all.
Yes, that’s what I’ve learned so far.

BR,
Przemek

19

On 2011-09-30 11:35, Maxim S. Shatskih wrote:

> And that’s essentially my last open issue - I’m not sure if/how is the
> BIOS going to utilize the bus after the system is booted
You don’t know. BIOS can have a bulk of SMM code which actually runs as an embedded controller (completely transparent to the OS) and controls the things like fan speeds.

So, you can either contact the BIOS vendor to expose your new devices in the ACPI tables, and, if this will fail, then do as Anton suggested.
I’ve also previously overlooked a flag in ICH8’s HST_STS register:

“INUSE_STS — R/WC (special). This bit is used as semaphore among various
independent software threads that may need to use the ICH8’s SMBus
logic, and has no other effect on hardware.”.

That’s pretty much exactly what I need for synchronization - but I can’t
be sure if BIOS uses it, or simply assumes exclusive access.

BR,
Przemek

20

“PrzemysÅ‚aw WÄ™grzyn” wrote in message
news:xxxxx@ntdev…
…
> I’ve also previously overlooked a flag in ICH8’s HST_STS register:
>
> “INUSE_STS — R/WC (special). This bit is used as semaphore among various
> independent software threads that may need to use the ICH8’s SMBus
> logic, and has no other effect on hardware.”.
>
> That’s pretty much exactly what I need for synchronization - but I can’t
> be sure if BIOS uses it, or simply assumes exclusive access.

Does the Linux i2c driver use this flag? It defines SMBHSTSTS_INUSE_STS bit
but I don’t see it used. If not… probably it is not worth anything.

– pa