SMBUS

Hi everyone.

I would like to use a SMBus on my PCI card. I have a processor on it
that is connected to the system SMBus.

My question is - is it possible to create a driver that will be
functional on various chipsets without writing a driver for each of it?
Do you have an example of this driver? I’ve googled some time for any
information about SMBus and I haven’t found anything, only that the
SMBus is not well supported on Windows and that each chipset has its own
driver. The only one example that I’ve found (on smbus.org) should
enumerate the SMBus devices connected to SMBus, but it does not find
anything…

Martin

There’s an SMBus driver for Linux out there somewhere.

But essentially, you have to at least configure your driver individually
for each chipset. The different chipsets are probably not dramatically
different, but sufficiently that you can’t just write an entirely generic
driver, you’ll at least have to determine which chipset you have and how to
wiggle the lines around.

What are you trying to achieve? Just a simpler interface to your PCI card,
or something else?


Mats

-------- Notice --------
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
message by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying or distribution of the message, or any
action taken by you in reliance on it, is prohibited and may be unlawful.
If you have received this message in error, please delete it and contact
the sender immediately. Thank you.

xxxxx@lists.osr.com wrote on 02/25/2005 11:02:55 AM:

Hi everyone.

I would like to use a SMBus on my PCI card. I have a processor on it
that is connected to the system SMBus.

My question is - is it possible to create a driver that will be
functional on various chipsets without writing a driver for each of it?
Do you have an example of this driver? I’ve googled some time for any
information about SMBus and I haven’t found anything, only that the
SMBus is not well supported on Windows and that each chipset has its own
driver. The only one example that I’ve found (on smbus.org) should
enumerate the SMBus devices connected to SMBus, but it does not find
anything…

Martin


Questions? First check the Kernel Driver FAQ at http://www.
osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

ForwardSourceID:NT0000DB06

Yes, I want to have another interface to the PCI card. It would be a
servicing interface, so I need that driver functional on different types
of chipsets.

So there is no generic SMBus driver? I thought that this is a function
of system bios to handle the SMBus and that this is a standardized
interface to the SMBus. I’ve found a mssmbios.sys installed on different
chipsets, isn’t that a driver that manages the smbus? I havent found any
information about this driver over the internet…

My advantage is that I do not have to support other systems than
windows2000 and windowsXP, because the controlling software does not run
under other systems. So if there would be a support for smbus on that
systems it would be enough for me.

Martin

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mats PETERSSON
Sent: Friday, February 25, 2005 12:10 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] SMBUS

There’s an SMBus driver for Linux out there somewhere.

But essentially, you have to at least configure your driver
individually for each chipset. The different chipsets are
probably not dramatically different, but sufficiently that
you can’t just write an entirely generic driver, you’ll at
least have to determine which chipset you have and how to
wiggle the lines around.

What are you trying to achieve? Just a simpler interface to
your PCI card, or something else?


Mats

-------- Notice --------
The information in this message is confidential and may be
legally privileged. It is intended solely for the addressee.
Access to this message by anyone else is unauthorized. If
you are not the intended recipient, any disclosure, copying
or distribution of the message, or any action taken by you in
reliance on it, is prohibited and may be unlawful. If you
have received this message in error, please delete it and
contact the sender immediately. Thank you.

xxxxx@lists.osr.com wrote on 02/25/2005 11:02:55 AM:

> Hi everyone.
>
> I would like to use a SMBus on my PCI card. I have a
processor on it
> that is connected to the system SMBus.
>
> My question is - is it possible to create a driver that will be
> functional on various chipsets without writing a driver for each of
> it? Do you have an example of this driver? I’ve googled
some time for
> any information about SMBus and I haven’t found anything, only that
> the SMBus is not well supported on Windows and that each
chipset has
> its own driver. The only one example that I’ve found (on smbus.org)
> should enumerate the SMBus devices connected to SMBus, but
it does not
> find anything…
>
> Martin
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.
> osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
xxxxx@3dlabs.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com

> ForwardSourceID:NT0000DB06


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are
currently subscribed to ntdev as: xxxxx@centrum.cz
To unsubscribe send a blank email to xxxxx@lists.osr.com

SMBus can be handled through ACPI (there is a defined way of doing this
in ACPI 3.0 (it was there is previous versions as well)). However, it is
optional and many chipsets have their own drivers or mechanisms for
doing so. There is no “host controller” standard or specification for an
SMBus upper edge interface. (Certainly the SMBus specifications clearly
define what a host shall do on the physical interconnect)

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin Zizka
Sent: Friday, February 25, 2005 3:44 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] SMBUS

Yes, I want to have another interface to the PCI card. It would be a
servicing interface, so I need that driver functional on different types
of chipsets.

So there is no generic SMBus driver? I thought that this is a function
of system bios to handle the SMBus and that this is a standardized
interface to the SMBus. I’ve found a mssmbios.sys installed on different
chipsets, isn’t that a driver that manages the smbus? I havent found any
information about this driver over the internet…

My advantage is that I do not have to support other systems than
windows2000 and windowsXP, because the controlling software does not run
under other systems. So if there would be a support for smbus on that
systems it would be enough for me.

Martin

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mats PETERSSON
Sent: Friday, February 25, 2005 12:10 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] SMBUS

There’s an SMBus driver for Linux out there somewhere.

But essentially, you have to at least configure your driver
individually for each chipset. The different chipsets are
probably not dramatically different, but sufficiently that
you can’t just write an entirely generic driver, you’ll at
least have to determine which chipset you have and how to
wiggle the lines around.

What are you trying to achieve? Just a simpler interface to
your PCI card, or something else?


Mats

-------- Notice --------
The information in this message is confidential and may be
legally privileged. It is intended solely for the addressee.
Access to this message by anyone else is unauthorized. If
you are not the intended recipient, any disclosure, copying
or distribution of the message, or any action taken by you in
reliance on it, is prohibited and may be unlawful. If you
have received this message in error, please delete it and
contact the sender immediately. Thank you.

xxxxx@lists.osr.com wrote on 02/25/2005 11:02:55 AM:

> Hi everyone.
>
> I would like to use a SMBus on my PCI card. I have a
processor on it
> that is connected to the system SMBus.
>
> My question is - is it possible to create a driver that will be
> functional on various chipsets without writing a driver for each of
> it? Do you have an example of this driver? I’ve googled
some time for
> any information about SMBus and I haven’t found anything, only that
> the SMBus is not well supported on Windows and that each
chipset has
> its own driver. The only one example that I’ve found (on smbus.org)
> should enumerate the SMBus devices connected to SMBus, but
it does not
> find anything…
>
> Martin
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.
> osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
xxxxx@3dlabs.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com

> ForwardSourceID:NT0000DB06


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are
currently subscribed to ntdev as: xxxxx@centrum.cz
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@nvidia.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

hi

The information below that I’m giving you is based on my experience on type of PC.

The SMBus is the bus that is used to interface with the battery. I’ve seen on the web that SMB refers to both the SMBus as well as SMBattery. I don’t know if this is true on all PCs, but Microsoft has a SMBattery driver that talks to the battery through the SMBus. Also, the SMBus is an I2C bus - serial.

Typically, to talk on the SMBus, you go through a special chip that has SMB interface registers. (How you access the registers is covered in the Mindshare book “PCI System Architecture” and probably in the PCI spec. I used I/O port operations when I did it.)

The special chip is a “South Bridge chip”, a chip that resides on the PCI bus, and interfaces to lots of devices (LAN, USB controllers, etc.) and buses (SMB, LPC, etc). The register interfaces are not exactly standard unfortunately – it varies a bit by manufacturer. For example, the Via South Bridge chip has a slightly difference register interface than the ALI South Bridge chip.

One problem with you getting on the SMBus is that you have to worry about other traffic on the bus and deal with collision detection. So, if you were trying to control a device on the SMBus and your system had a battery driver that also talked on the SMBus, you can run into problems.

In the SMBus registers on a South Bridge part, there is a semaphore bit that is used to gain access to the bus - unfortunately it’s not a true semaphore hardware bit – it’s a half-baked attempt at helping to provide sychronization. You can also check another bit, a busy bit, to see if somebody is using the bus. Handling collisions, by backing off for a random amount of time and then trying again, is one way to deal with things as well.

I’m not sure exactly why you choose a PCI board that had an SMBus interface - that info might help us make recommendations.

Sharon

----- Original Message -----
From: Mark Overby
To: Windows System Software Devs Interest List
Sent: Friday, February 25, 2005 9:12 AM
Subject: RE: [ntdev] SMBUS

SMBus can be handled through ACPI (there is a defined way of doing this
in ACPI 3.0 (it was there is previous versions as well)). However, it is
optional and many chipsets have their own drivers or mechanisms for
doing so. There is no “host controller” standard or specification for an
SMBus upper edge interface. (Certainly the SMBus specifications clearly
define what a host shall do on the physical interconnect)

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin Zizka
Sent: Friday, February 25, 2005 3:44 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] SMBUS

Yes, I want to have another interface to the PCI card. It would be a
servicing interface, so I need that driver functional on different types
of chipsets.

So there is no generic SMBus driver? I thought that this is a function
of system bios to handle the SMBus and that this is a standardized
interface to the SMBus. I’ve found a mssmbios.sys installed on different
chipsets, isn’t that a driver that manages the smbus? I havent found any
information about this driver over the internet…

My advantage is that I do not have to support other systems than
windows2000 and windowsXP, because the controlling software does not run
under other systems. So if there would be a support for smbus on that
systems it would be enough for me.

Martin

-----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mats PETERSSON
> Sent: Friday, February 25, 2005 12:10 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] SMBUS
>
>
>
>
>
>
>
> There’s an SMBus driver for Linux out there somewhere.
>
> But essentially, you have to at least configure your driver
> individually for each chipset. The different chipsets are
> probably not dramatically different, but sufficiently that
> you can’t just write an entirely generic driver, you’ll at
> least have to determine which chipset you have and how to
> wiggle the lines around.
>
> What are you trying to achieve? Just a simpler interface to
> your PCI card, or something else?
>
> –
> Mats
>
> -------- Notice --------
> The information in this message is confidential and may be
> legally privileged. It is intended solely for the addressee.
> Access to this message by anyone else is unauthorized. If
> you are not the intended recipient, any disclosure, copying
> or distribution of the message, or any action taken by you in
> reliance on it, is prohibited and may be unlawful. If you
> have received this message in error, please delete it and
> contact the sender immediately. Thank you.
>
>
> xxxxx@lists.osr.com wrote on 02/25/2005 11:02:55 AM:
>
> > Hi everyone.
> >
> > I would like to use a SMBus on my PCI card. I have a
> processor on it
> > that is connected to the system SMBus.
> >
> > My question is - is it possible to create a driver that will be
> > functional on various chipsets without writing a driver for each of
> > it? Do you have an example of this driver? I’ve googled
> some time for
> > any information about SMBus and I haven’t found anything, only that
> > the SMBus is not well supported on Windows and that each
> chipset has
> > its own driver. The only one example that I’ve found (on smbus.org)
> > should enumerate the SMBus devices connected to SMBus, but
> it does not
> > find anything…
> >
> > Martin
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at http://www.
> > osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
> xxxxx@3dlabs.com To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
>
> > ForwardSourceID:NT0000DB06
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are
> currently subscribed to ntdev as: xxxxx@centrum.cz
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@nvidia.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

The SMBus should be a service interface to a service processor of my PCI
board. Of course that I am using the PCI interface too - for regular
data and communication.

I just wanted to know, if it is possible to use it as service interface

  • if it is so supported that it will be available on new motherboards on
    WindowsXP. I just didnt find enough information about it and only source
    code that I found on smbus.org wasn’t functional.

Martin

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of S. Drasnin
Sent: Saturday, February 26, 2005 4:15 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] SMBUS

hi

The information below that I’m giving you is based on my experience on
type of PC.

The SMBus is the bus that is used to interface with the battery. I’ve
seen on the web that SMB refers to both the SMBus as well as SMBattery.
I don’t know if this is true on all PCs, but Microsoft has a SMBattery
driver that talks to the battery through the SMBus. Also, the SMBus is
an I2C bus - serial.

Typically, to talk on the SMBus, you go through a special chip that has
SMB interface registers. (How you access the registers is covered in the
Mindshare book “PCI System Architecture” and probably in the PCI spec. I
used I/O port operations when I did it.)

The special chip is a “South Bridge chip”, a chip that resides on the
PCI bus, and interfaces to lots of devices (LAN, USB controllers, etc.)
and buses (SMB, LPC, etc). The register interfaces are not exactly
standard unfortunately – it varies a bit by manufacturer. For example,
the Via South Bridge chip has a slightly difference register interface
than the ALI South Bridge chip.

One problem with you getting on the SMBus is that you have to worry
about other traffic on the bus and deal with collision detection. So, if
you were trying to control a device on the SMBus and your system had a
battery driver that also talked on the SMBus, you can run into problems.

In the SMBus registers on a South Bridge part, there is a semaphore bit
that is used to gain access to the bus - unfortunately it’s not a true
semaphore hardware bit – it’s a half-baked attempt at helping to
provide sychronization. You can also check another bit, a busy bit, to
see if somebody is using the bus. Handling collisions, by backing off
for a random amount of time and then trying again, is one way to deal
with things as well.

I’m not sure exactly why you choose a PCI board that had an SMBus
interface - that info might help us make recommendations.

Sharon

----- Original Message -----
From: Mark Overby mailto:xxxxx
To: Windows System Software Devs Interest mailto:xxxxx
List
Sent: Friday, February 25, 2005 9:12 AM
Subject: RE: [ntdev] SMBUS

SMBus can be handled through ACPI (there is a defined way of doing this
in ACPI 3.0 (it was there is previous versions as well)). However, it is
optional and many chipsets have their own drivers or mechanisms for
doing so. There is no “host controller” standard or specification for an
SMBus upper edge interface. (Certainly the SMBus specifications clearly
define what a host shall do on the physical interconnect)

-----Original Message-----
From: xxxxx@listsosr.com
mailto:xxxxx
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin Zizka
Sent: Friday, February 25, 2005 3:44 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] SMBUS

Yes, I want to have another interface to the PCI card. It would be a
servicing interface, so I need that driver functional on different types
of chipsets.

So there is no generic SMBus driver? I thought that this is a function
of system bios to handle the SMBus and that this is a standardized
interface to the SMBus. I’ve found a mssmbios.sys installed on different
chipsets, isn’t that a driver that manages the smbus? I havent found any
information about this driver over the internet…

My advantage is that I do not have to support other systems than
windows2000 and windowsXP, because the controlling software does not run
under other systems. So if there would be a support for smbus on that
systems it would be enough for me.

Martin

> -----Original Message-----
> From: xxxxx@listsosr.com
mailto:xxxxx
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mats PETERSSON
> Sent: Friday, February 25, 2005 12:10 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] SMBUS
>
>
>
>
>
>
>
> There’s an SMBus driver for Linux out there somewhere.
>
> But essentially, you have to at least configure your driver
> individually for each chipset. The different chipsets are
> probably not dramatically different, but sufficiently that
> you can’t just write an entirely generic driver, you’ll at
> least have to determine which chipset you have and how to
> wiggle the lines around.
>
> What are you trying to achieve? Just a simpler interface to
> your PCI card, or something else?
>
> –
> Mats
>
> -------- Notice --------
> The information in this message is confidential and may be
> legally privileged. It is intended solely for the addressee.
> Access to this message by anyone else is unauthorized. If
> you are not the intended recipient, any disclosure, copying
> or distribution of the message, or any action taken by you in
> reliance on it, is prohibited and may be unlawful. If you
> have received this message in error, please delete it and
> contact the sender immediately. Thank you.
>
>
> xxxxx@lists.osr.com wrote on 02/25/2005 11:02:55 AM:
>
> > Hi everyone.
> >
> > I would like to use a SMBus on my PCI card. I have a
> processor on it
> > that is connected to the system SMBus.
> >
> > My question is - is it possible to create a driver that will be
> > functional on various chipsets without writing a driver for each of
> > it? Do you have an example of this driver? I’ve googled
> some time for
> > any information about SMBus and I haven’t found anything, only that
> > the SMBus is not well supported on Windows and that each
> chipset has
> > its own driver. The only one example that I’ve found (on smbus.org)
> > should enumerate the SMBus devices connected to SMBus, but
> it does not
> > find anything…
> >
> > Martin
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at http://www.
> > osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
> xxxxx@3dlabs.com To
> > unsubscribe send a blank email to xxxxx@listsosr.com
mailto:xxxxx
>
> > ForwardSourceID:NT0000DB06
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are
> currently subscribed to ntdev as: xxxxx@centrum.cz
> To unsubscribe send a blank email to xxxxx@listsosr.com
mailto:xxxxx
>
>


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@nvidia.com
To unsubscribe send a blank email to xxxxx@listsosr.com
mailto:xxxxx


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@listsosr.com
mailto:xxxxx


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

Zpr?vaSMBus is or may be inside your machine. SMBus isn’t a software interface. It is a HARDWARE interface to talk to certain chips such as batteries and the like.

The interface of the SMBus to the system is provided either by an SMBus driver chip (on older machines) or usually integrated into the Southbridge chip on newer machines. There are at least TWO common defined interfaces to the SMBus. Which one is used on any machine depends on who built the machine and which chips they liked. You cannnot *depend* on any particular interface being on your machine. But that doesn’t matter.

The reason that it doesn’t matter is because the SMBus interface isn’t designed to be user accessable. It is used by the ACPI driver for controlling the system. There may be some IOCTLs to acpi.sys that might let you have some visibility into the SMBus state. And there are ways that you can indirectly control some SMBus state. Clicking on the Shutdown icon is one of these indirect ways.

If you go in mucking around with the SMBus behind ACPI’s back, it will have an erroneous view of the state of the machine. This in turn means that it will do erroneous things. Considering that ACPI is controlling power levels and monitoring for overtemperature shutdown and the like, I think it would be a really bad idea to get the ACPI driver confused.

Now, a couple of things on the SMBus are the fan speed indicators and system temperature monitors. It would be a real nice thing to have a clean interface to this sort of information. I don’t believe any such clean interface exists, which is a shame. It would have to come from the ACPI driver, because it is the only thing in the system that knows which fans should exist or which temperature sensors should exist, and knows what ranges they should have. Again, there is no “standard fan interface definiton” to the SMBus. Which addresses contain fan speed sensors or speed controls is up to the system designer. This information is reported in the ACPI system definition, at least in theory.

Loren
----- Original Message -----
From: Martin Zizka
To: Windows System Software Devs Interest List
Sent: Sunday, February 27, 2005 2:11 PM
Subject: RE: [ntdev] SMBUS

The SMBus should be a service interface to a service processor of my PCI board. Of course that I am using the PCI interface too - for regular data and communication.

I just wanted to know, if it is possible to use it as service interface - if it is so supported that it will be available on new motherboards on WindowsXP. I just didnt find enough information about it and only source code that I found on smbus.org wasn’t functional.

Martin
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of S. Drasnin
Sent: Saturday, February 26, 2005 4:15 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] SMBUS

hi

The information below that I’m giving you is based on my experience on type of PC.

The SMBus is the bus that is used to interface with the battery. I’ve seen on the web that SMB refers to both the SMBus as well as SMBattery. I don’t know if this is true on all PCs, but Microsoft has a SMBattery driver that talks to the battery through the SMBus. Also, the SMBus is an I2C bus - serial.

Typically, to talk on the SMBus, you go through a special chip that has SMB interface registers. (How you access the registers is covered in the Mindshare book “PCI System Architecture” and probably in the PCI spec. I used I/O port operations when I did it.)

The special chip is a “South Bridge chip”, a chip that resides on the PCI bus, and interfaces to lots of devices (LAN, USB controllers, etc.) and buses (SMB, LPC, etc). The register interfaces are not exactly standard unfortunately – it varies a bit by manufacturer. For example, the Via South Bridge chip has a slightly difference register interface than the ALI South Bridge chip.

One problem with you getting on the SMBus is that you have to worry about other traffic on the bus and deal with collision detection. So, if you were trying to control a device on the SMBus and your system had a battery driver that also talked on the SMBus, you can run into problems.

In the SMBus registers on a South Bridge part, there is a semaphore bit that is used to gain access to the bus - unfortunately it’s not a true semaphore hardware bit – it’s a half-baked attempt at helping to provide sychronization. You can also check another bit, a busy bit, to see if somebody is using the bus. Handling collisions, by backing off for a random amount of time and then trying again, is one way to deal with things as well.

I’m not sure exactly why you choose a PCI board that had an SMBus interface - that info might help us make recommendations.

Sharon

----- Original Message -----
From: Mark Overby
To: Windows System Software Devs Interest List
Sent: Friday, February 25, 2005 9:12 AM
Subject: RE: [ntdev] SMBUS

SMBus can be handled through ACPI (there is a defined way of doing this
in ACPI 3.0 (it was there is previous versions as well)). However, it is
optional and many chipsets have their own drivers or mechanisms for
doing so. There is no “host controller” standard or specification for an
SMBus upper edge interface. (Certainly the SMBus specifications clearly
define what a host shall do on the physical interconnect)

-----Original Message-----
From: xxxxx@listsosr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin Zizka
Sent: Friday, February 25, 2005 3:44 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] SMBUS

Yes, I want to have another interface to the PCI card. It would be a
servicing interface, so I need that driver functional on different types
of chipsets.

So there is no generic SMBus driver? I thought that this is a function
of system bios to handle the SMBus and that this is a standardized
interface to the SMBus. I’ve found a mssmbios.sys installed on different
chipsets, isn’t that a driver that manages the smbus? I havent found any
information about this driver over the internet…

My advantage is that I do not have to support other systems than
windows2000 and windowsXP, because the controlling software does not run
under other systems. So if there would be a support for smbus on that
systems it would be enough for me.

Martin

-----Original Message-----
> From: xxxxx@listsosr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mats PETERSSON
> Sent: Friday, February 25, 2005 12:10 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] SMBUS
>
>
>
>
>
>
>
> There’s an SMBus driver for Linux out there somewhere.
>
> But essentially, you have to at least configure your driver
> individually for each chipset. The different chipsets are
> probably not dramatically different, but sufficiently that
> you can’t just write an entirely generic driver, you’ll at
> least have to determine which chipset you have and how to
> wiggle the lines around.
>
> What are you trying to achieve? Just a simpler interface to
> your PCI card, or something else?
>
> –
> Mats
>
> -------- Notice --------
> The information in this message is confidential and may be
> legally privileged. It is intended solely for the addressee.
> Access to this message by anyone else is unauthorized. If
> you are not the intended recipient, any disclosure, copying
> or distribution of the message, or any action taken by you in
> reliance on it, is prohibited and may be unlawful. If you
> have received this message in error, please delete it and
> contact the sender immediately. Thank you.
>
>
> xxxxx@lists.osr.com wrote on 02/25/2005 11:02:55 AM:
>
> > Hi everyone.
> >
> > I would like to use a SMBus on my PCI card. I have a
> processor on it
> > that is connected to the system SMBus.
> >
> > My question is - is it possible to create a driver that will be
> > functional on various chipsets without writing a driver for each of
> > it? Do you have an example of this driver? I’ve googled
> some time for
> > any information about SMBus and I haven’t found anything, only that
> > the SMBus is not well supported on Windows and that each
> chipset has
> > its own driver. The only one example that I’ve found (on smbus.org)
> > should enumerate the SMBus devices connected to SMBus, but
> it does not
> > find anything…
> >
> > Martin
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at http://www.
> > osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
> xxxxx@3dlabs.com To
> > unsubscribe send a blank email to xxxxx@listsosr.com
>
> > ForwardSourceID:NT0000DB06
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are
> currently subscribed to ntdev as: xxxxx@centrum.cz
> To unsubscribe send a blank email to xxxxx@listsosr.com
>
>


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@nvidia.com
To unsubscribe send a blank email to xxxxx@listsosr.com


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@listsosr.com


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

ZprávaYou’re all confusing some of the issues. Please see my last post on
this subject (in the archives.) I’ll summarize it here. This issue seems
to come up about once a year.

First of all, don’t confuse SMBus, SMBIOS and ACPI. They are separate but
related technologies.

SMBus is a hardware interface for very cheaply connecting chips that need
low-speed data transfers. It’s a protocol on top of I2C.

SMBIOS is a software interface.

ACPI is both a software and a hardware interface used for machine
configuration and for power management. It includes a specification (that’s
used by almost nobody) for attaching SMBus devices through a specific
controller. The idea was that you could attach a battery through this
interface and your controller could ensure that no rogue code could ever
cause a battery to overcharge and explode, since the OS wasn’t in directly
control of the SMBus, the ACPI embedded controller was. The Win98 guys
chose not to bother to support the software side of this interface, and so
the industry decided that it was pointless to use it, even though it was
supported in Windows 2000 and Windows XP. Although we did support it, I’ve
heard rumors that we’re thinking about dropping support for it, particularly
because we have exactly zero customers who are dependent on it and exactly
zero machines to test it with.

In general, SMBus has been used by people who want to do out-of-band system
management. Thus they not only have no incentive to make their interfaces
available to the OS, they actually have a disincentive to, namely that they
don’t want anybody commoditizing their market. Consequently, they’ve made
it really hard for anything but the BIOS to take control of the SMBuses in
the machine.

I learned this the hard way when the TabletPC group built their original
prototype. The effort was led by a guy named Chuck Thacker, who is a long
time hardware designer and industry smart guy, but somebody who had never
built a laptop-like PC before. He decided to save a few bucks by omitting
the ACPI embedded controller, handling everything that it normally does
within OS-level device drivers. (This was partly at my suggestion, as I
offered to help with the project and partly because Chuck was specifically
targeting only Windows XP. Generally, laptop designers use the ACPI
embedded controller partly because they need things to function regardless
of the installed OS.) They used a Transmeta processor and an ALi chipset,
which included an SMBus controller. The guys at ALi were so used to the
BIOS being the only customer for the SMBus controller that they actually
wired it up so that the only interrupt it could generate was an SMI. It
literally couldn’t generate any interrupts that were OS-visible.

Furthermore, even if the chipset guys had built something that the OS (or
third-party drivers) could make use of, it still would have been a bad plan,
as motherboard makers tend to put devices on the SMBus that the BIOS *must*
take control of. Consequently, if you write an OS-level driver for the
SMBus controller, you suddenly find yourself in conflict with the BIOS for
access to and control of the controller itself, causing, at best, corruption
on the bus. There is, of course, no way to know whether the BIOS is going
to start hammering on the SMBus controller at any time.

The last complication in this story is that the PCI SIG, in one of its later
revisions, decided to use a couple of pins for SMBus connections. This was
probably for the telecom industry. I have little idea how you would use
this successfully in the PC industry, as there’s currently no way for you to
get to the SMBus interface to your device in a way that works consistently.

My advice to anyone considering using SMBus in a commodity PC environment
(in contrast to a custom system for a vertical market) is to forget it.
You’ll be battling a lot of industry forces which are beyond any one
person’s control.


Jake Oshins
Windows Kernel Group

This posting is provided “AS IS” with no warranties, and confers no rights.

“Loren Wilton” wrote in message news:xxxxx@ntdev…
SMBus is or may be inside your machine. SMBus isn’t a software interface.
It is a HARDWARE interface to talk to certain chips such as batteries and
the like.

The interface of the SMBus to the system is provided either by an SMBus
driver chip (on older machines) or usually integrated into the Southbridge
chip on newer machines. There are at least TWO common defined interfaces to
the SMBus. Which one is used on any machine depends on who built the
machine and which chips they liked. You cannnot depend on any particular
interface being on your machine. But that doesn’t matter.

The reason that it doesn’t matter is because the SMBus interface isn’t
designed to be user accessable. It is used by the ACPI driver for
controlling the system. There may be some IOCTLs to acpi.sys that might let
you have some visibility into the SMBus state. And there are ways that you
can indirectly control some SMBus state. Clicking on the Shutdown icon is
one of these indirect ways.

If you go in mucking around with the SMBus behind ACPI’s back, it will have
an erroneous view of the state of the machine. This in turn means that it
will do erroneous things. Considering that ACPI is controlling power levels
and monitoring for overtemperature shutdown and the like, I think it would
be a really bad idea to get the ACPI driver confused.

Now, a couple of things on the SMBus are the fan speed indicators and system
temperature monitors. It would be a real nice thing to have a clean
interface to this sort of information. I don’t believe any such clean
interface exists, which is a shame. It would have to come from the ACPI
driver, because it is the only thing in the system that knows which fans
should exist or which temperature sensors should exist, and knows what
ranges they should have. Again, there is no “standard fan interface
definiton” to the SMBus. Which addresses contain fan speed sensors or speed
controls is up to the system designer. This information is reported in the
ACPI system definition, at least in theory.

Loren
----- Original Message -----
From: Martin Zizka
To: Windows System Software Devs Interest List
Sent: Sunday, February 27, 2005 2:11 PM
Subject: RE: [ntdev] SMBUS

The SMBus should be a service interface to a service processor of my PCI
board. Of course that I am using the PCI interface too - for regular data
and communication.

I just wanted to know, if it is possible to use it as service interface - if
it is so supported that it will be available on new motherboards on
WindowsXP. I just didnt find enough information about it and only source
code that I found on smbus.org wasn’t functional.

Martin
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of S. Drasnin
Sent: Saturday, February 26, 2005 4:15 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] SMBUS

hi

The information below that I’m giving you is based on my experience on type
of PC.

The SMBus is the bus that is used to interface with the battery. I’ve seen
on the web that SMB refers to both the SMBus as well as SMBattery. I don’t
know if this is true on all PCs, but Microsoft has a SMBattery driver that
talks to the battery through the SMBus. Also, the SMBus is an I2C bus -
serial.

Typically, to talk on the SMBus, you go through a special chip that has SMB
interface registers. (How you access the registers is covered in the
Mindshare book “PCI System Architecture” and probably in the PCI spec. I
used I/O port operations when I did it.)

The special chip is a “South Bridge chip”, a chip that resides on the PCI
bus, and interfaces to lots of devices (LAN, USB controllers, etc.) and
buses (SMB, LPC, etc). The register interfaces are not exactly standard
unfortunately – it varies a bit by manufacturer. For example, the Via South
Bridge chip has a slightly difference register interface than the ALI South
Bridge chip.

One problem with you getting on the SMBus is that you have to worry about
other traffic on the bus and deal with collision detection. So, if you were
trying to control a device on the SMBus and your system had a battery driver
that also talked on the SMBus, you can run into problems.

In the SMBus registers on a South Bridge part, there is a semaphore bit that
is used to gain access to the bus - unfortunately it’s not a true semaphore
hardware bit – it’s a half-baked attempt at helping to provide
sychronization. You can also check another bit, a busy bit, to see if
somebody is using the bus. Handling collisions, by backing off for a random
amount of time and then trying again, is one way to deal with things as
well.

I’m not sure exactly why you choose a PCI board that had an SMBus
interface - that info might help us make recommendations.

Sharon

----- Original Message -----
From: Mark Overby
To: Windows System Software Devs Interest List
Sent: Friday, February 25, 2005 9:12 AM
Subject: RE: [ntdev] SMBUS

SMBus can be handled through ACPI (there is a defined way of doing this
in ACPI 3.0 (it was there is previous versions as well)). However, it is
optional and many chipsets have their own drivers or mechanisms for
doing so. There is no “host controller” standard or specification for an
SMBus upper edge interface. (Certainly the SMBus specifications clearly
define what a host shall do on the physical interconnect)

-----Original Message-----
From: xxxxx@listsosr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin Zizka
Sent: Friday, February 25, 2005 3:44 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] SMBUS

Yes, I want to have another interface to the PCI card. It would be a
servicing interface, so I need that driver functional on different types
of chipsets.

So there is no generic SMBus driver? I thought that this is a function
of system bios to handle the SMBus and that this is a standardized
interface to the SMBus. I’ve found a mssmbios.sys installed on different
chipsets, isn’t that a driver that manages the smbus? I havent found any
information about this driver over the internet…

My advantage is that I do not have to support other systems than
windows2000 and windowsXP, because the controlling software does not run
under other systems. So if there would be a support for smbus on that
systems it would be enough for me.

Martin

> -----Original Message-----
> From: xxxxx@listsosr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mats PETERSSON
> Sent: Friday, February 25, 2005 12:10 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] SMBUS
>
>
>
>
>
>
>
> There’s an SMBus driver for Linux out there somewhere.
>
> But essentially, you have to at least configure your driver
> individually for each chipset. The different chipsets are
> probably not dramatically different, but sufficiently that
> you can’t just write an entirely generic driver, you’ll at
> least have to determine which chipset you have and how to
> wiggle the lines around.
>
> What are you trying to achieve? Just a simpler interface to
> your PCI card, or something else?
>
> –
> Mats
>
> -------- Notice --------
> The information in this message is confidential and may be
> legally privileged. It is intended solely for the addressee.
> Access to this message by anyone else is unauthorized. If
> you are not the intended recipient, any disclosure, copying
> or distribution of the message, or any action taken by you in
> reliance on it, is prohibited and may be unlawful. If you
> have received this message in error, please delete it and
> contact the sender immediately. Thank you.
>
>
> xxxxx@lists.osr.com wrote on 02/25/2005 11:02:55 AM:
>
> > Hi everyone.
> >
> > I would like to use a SMBus on my PCI card. I have a
> processor on it
> > that is connected to the system SMBus.
> >
> > My question is - is it possible to create a driver that will be
> > functional on various chipsets without writing a driver for each of
> > it? Do you have an example of this driver? I’ve googled
> some time for
> > any information about SMBus and I haven’t found anything, only that
> > the SMBus is not well supported on Windows and that each
> chipset has
> > its own driver. The only one example that I’ve found (on smbus.org)
> > should enumerate the SMBus devices connected to SMBus, but
> it does not
> > find anything…
> >
> > Martin
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at http://www.
> > osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
> xxxxx@3dlabs.com To
> > unsubscribe send a blank email to xxxxx@listsosr.com
>
> > ForwardSourceID:NT0000DB06
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are
> currently subscribed to ntdev as: xxxxx@centrum.cz
> To unsubscribe send a blank email to xxxxx@listsosr.com
>
>


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@nvidia.com
To unsubscribe send a blank email to xxxxx@listsosr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@listsosr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Hi Jake,

sorry, just re-read this message of your due to BIOS/ACPI discussion with
some people.

supported in Windows 2000 and Windows XP. Although we did support it, I’ve
heard rumors that we’re thinking about dropping support for it, particularly
because we have exactly zero customers who are dependent on it and exactly
zero machines to test it with.

Am I correct that this is why fan speeds and temperature sensors are never
available via WMI? Are these sensors sitting on SMBus hardware-wise?

On all machines I saw in 2000ies, I had “ACPI Fan” and “ACPI Thermal Zone”
devices in the Device Manager. WMI supports these classes for a very long time
(it is documented). Nevertheless, trying to access the data always fails on
each machine I had lying around.

Is it due to SMBus issues you mentioned? Am I right that the BIOS misses
the ACPI bytecode to take these sensor data from the SMBus controller?

Also - am I correct that ACPI embedded controller is some hardware sitting
logically on top of the SMBus controller and doing some standard SMBus
transactions without the OS aid? Can BIOS SMM code be also employed in this? Am
I right that ALI replaced the hardware ACPI embedded controller with SMM code
invoked by SMI interrupt from the SMBus controller?

Are commodity motherboards - like the old Asus CUSL2 or the more-or-less
modern Asus P5P-800 - using ACPI embedded controller?

thanks,

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

I’m not sure why you saw failures on the machines that exhibited fan and
thermal zone devices in device manager. Perhaps the team that maintains
that code would be interested in the failures if you can characterize them.
I’ll pass any error reports along.

Since you’re asking, I’ll detail a little more about ACPI and its
relationship to SMBus.

ACPI defines a device called an “ACPI Embedded Controller.” In most
machines that implement this (which are almost entirely mobile, laptop-class
machines) this is actually an 8051 microcontroller with some on-board
firmware. The 8051 runs at a very low clock rate, managing things like
batteries, lid switches, power and sleep buttons, backlight brightness
(sometimes), fans and other laptop features that must be managed even if
there is no OS running that understands them. This microcontroller decodes
two I/O ports, usually 0x62 and 0x66 which an ACPI-aware OS uses to
communicate with it. It can also generate an SCI (ACPI) interrupt.

The ACPI spec also defines an interface to an SMBus controller. The
definition of the SMBus controller is written in terms of the Embedded
Controller. It is expected that the laptop designer will hook the batteries
and other SMBus devices to an SMBus controller which is physically contained
within the Embedded Controller and which the Embedded Controller firmware
will own. If the OS wishes to communicate with any devices on the SMBus, it
sends SMBus commands through the Embedded Controller, indirectly to the
SMBus controller. Any SMBus interrupts are received by the 8051, not the
OS.

This was done for two reasons. First, it was (rightfully) expected that the
average laptop designer would want to control things like batteries and
power switches from within their firmware so that batteries and switches
worked correctly whether an ACPI-aware OS was running or not. And second,
it was done so that an OS-level virus or even an OS-level bug couldn’t
accidentally feed the wrong sequence of commands directly to the battery
charger and cause the batteries to explode.

For Windows 2000, we wrote an ACPI Embedded Controller driver which can pass
commands back and forth between the OS and the ACPI Embedded Controller. We
also wrote an SMBus Class driver, which generally handles SMBus protocols.
And we wrote an SMBus miniclass driver which sends SMBus commands through
the ACPI Embedded Controller driver. Finally, we wrote a single SMBus
client driver for “SMART” batteries, which are a specific kind of
SMBus-attached device. This driver was a client of the SMBus Class driver
and could theoretically be used with any SMBus controller if somebody were
to write a driver for it.

The Win98 folks decided that the only one of these drivers (which were all
written by the Windows 2000 team) that they wanted to ship as part of the
Win98 ACPI implementation was the ACPI Embedded Controller driver. All the
other ones were discarded, I think mostly because they lacked test hardware
and general interest from the industry. This forced the laptop industry to
expose batteries and other SMBus-attached devices through ACPI’s
“control-method” interface rather than the SMBus interface. The
control-method interface involves handing the OS an interpreted byte code
which allows the OS to evaluate various objects. This interface, along with
some fancy 8051 firmware, can produce “devices” like the ACPI Fan and ACPI
Thermal Zone, as well as the ACPI Battery and Charger. Even if these
devices are actually attached through an SMBus, the OS doesn’t see that. It
sees pure ACPI representations. It has to be this way if you want to run
Win98.

Over time, Intel wrote an SMBus miniclass driver for their SMBus controller
that’s attached to their South Bridge and we wrote one for the ALi South
Bridge that was used in the TabletPC prototype, which didn’t have an ACPI
Embedded Controller. We also wrote a few SMBus client drivers for the
various switches and buttons that were in the TablePC prototype and I assume
that Intel wrote a few drivers for their stuff, too.

Both projects were basically worthless. Intel discovered that the things
that they tend to want to attach to the South Bridge’s SMBus didn’t mesh
well with OS-directed management. And we discovered that nobody wanted to
build a machine like the TablePC prototype, as everybody had at least one
good reason to include an Embedded Controller.

In the end, it seems to me that control of the South Bridges SMBus
controller always best resides with either the BIOS or some hardware
management entity, as most of the devices attached through that SMBus are
related to hardware management. When an OS-level driver tries to take
control of it, collision is usually the result.


Jake Oshins
Windows Kernel Group

This posting is provided “AS IS” with no warranties, and confers no rights.

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
> Hi Jake,
>
> sorry, just re-read this message of your due to BIOS/ACPI discussion
> with
> some people.
>
>> supported in Windows 2000 and Windows XP. Although we did support it,
>> I’ve
>> heard rumors that we’re thinking about dropping support for it,
>> particularly
>> because we have exactly zero customers who are dependent on it and
>> exactly
>> zero machines to test it with.
>
> Am I correct that this is why fan speeds and temperature sensors are
> never
> available via WMI? Are these sensors sitting on SMBus hardware-wise?
>
> On all machines I saw in 2000ies, I had “ACPI Fan” and “ACPI Thermal
> Zone”
> devices in the Device Manager. WMI supports these classes for a very long
> time
> (it is documented). Nevertheless, trying to access the data always fails
> on
> each machine I had lying around.
>
> Is it due to SMBus issues you mentioned? Am I right that the BIOS
> misses
> the ACPI bytecode to take these sensor data from the SMBus controller?
>
> Also - am I correct that ACPI embedded controller is some hardware
> sitting
> logically on top of the SMBus controller and doing some standard SMBus
> transactions without the OS aid? Can BIOS SMM code be also employed in
> this? Am
> I right that ALI replaced the hardware ACPI embedded controller with SMM
> code
> invoked by SMI interrupt from the SMBus controller?
>
> Are commodity motherboards - like the old Asus CUSL2 or the
> more-or-less
> modern Asus P5P-800 - using ACPI embedded controller?
>
> thanks,
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>