OSDev.org

Ive searched high and low (unless ive been looking with the wrong tags) for specifications as to how i can control the cpu fan (without windows libraries)

Ive come across some information about the pic timer having something to do with it, but is there any links or information on how i can control the fans?

Ive read up that Pwm fans are controllable (i believe 4 pin Ground, power, tach, control)

But ive controlled a 3 pin before from software within windows. Correct me, or confirm, id like to know all i need.

Hi,

GhostXoPCorp wrote:Ive searched high and low (unless ive been looking with the wrong tags) for specifications as to how i can control the cpu fan (without windows libraries)

There's 2 ways.

The first way is by implementing an interpreter for ACPI's AML (or making ACPICA work for your OS), and using the "Fan Object" methods. See the ACPI specification for details (e.g. section 11.3.1 of ACPI 5.0).

The other way is to write a different driver for each different motherboard. In this case you'd probably be dealing with some sort of serial link (e.g. SMBus or I2C), or "GPIO" general purpose outputs, or registers specifically designed for fan control. The datasheet for the chipset's southbridge (or "IO Controller Hub" or equivalent) would be the first place to look.

As far as I know, the "PIC timer" (PIT?) is never involved; although some motherboards might have simple "full speed or off" fan control where you might be able to do some sort of pulse-width modulation (using any timer you like) to control the speed; but for these motherboards I'd also expect there's typically also no way of knowing if a fan is connected or not or what the fans current speed might be.


Cheers,

Brendan

Brendan wrote:The other way is to write a different driver for each different motherboard. In this case you'd probably be dealing with some sort of serial link (e.g. SMBus or I2C), or "GPIO" general purpose outputs, or registers specifically designed for fan control. The datasheet for the chipset's southbridge (or "IO Controller Hub" or equivalent) would be the first place to look.

Was the response i had seen on other sites, but what would be more recommended. Option one is alot less of writing drivers and more implementing one standard for all?

ACPI is pretty much mandatory for a modern system anyway, unless you plan on implementing millions of motherboard and chipset specific drivers (and even then you'll still have thousands of little "ACPI devices" gnawing at you...).

True, well acpi it is then, Thank you.

Ive searched high and low (unless ive been looking with the wrong tags) for specifications as to how i can control the cpu fan (without windows libraries)

Usually this function are implemented in Hardware Monitor chip
On desktop PC This chip is within of Super I/O chip, but you can find also as single chip
First place to look is search for Super I/O chip to address 0x2E or 0x4E.
Each Super I/O chipset requires a key to enter in extended configuration mode..
WINBOND/Nuvoton, ITE, SMSC are more common Super I/O Desktop chip...
The second way is scan for SMBus Hardware Monitor,
the common slave address for this chip are ( Left Shifted by 1):
0x52, 0x54, 0x56, 0x58, 0x5A, 0x5C, 0x5E , 0x90, 0x92, 0x94, 0x96, 0x98, 0x9A, 0x9C, 0x9E
Of course you must write a driver for every chip
If you want complete control of your chip then you will search for Super I/O or SMBus HWM,
otherwise you can search for ACPI Method (if present)

djmauretto wrote:

Ive searched high and low (unless ive been looking with the wrong tags) for specifications as to how i can control the cpu fan (without windows libraries)

Usually this function are implemented in Hardware Monitor chip
On desktop PC This chip is within of Super I/O chip, but you can find also as single chip
First place to look is search for Super I/O chip to address 0x2E or 0x4E.
Each Super I/O chipset requires a key to enter in extended configuration mode..
WINBOND/Nuvoton, ITE, SMSC are more common Super I/O Desktop chip...
The second way is scan for SMBus Hardware Monitor,
the common slave address for this chip are ( Left Shifted by 1):
0x52, 0x54, 0x56, 0x58, 0x5A, 0x5C, 0x5E , 0x90, 0x92, 0x94, 0x96, 0x98, 0x9A, 0x9C, 0x9E
Of course you must write a driver for every chip
If you want complete control of your chip then you will search for Super I/O or SMBus HWM,
otherwise you can search for ACPI Method (if present)

Thank you, understood that is one way but it fits in the category where id have to write many drivers. When the time comes (thanks again for the manual brendan) ill get to work on all i can with the book. Id like for my os to be part of the standard. As far as i can tell its a sure shot at controlling not only the fans without having to write many drivers for every chipset. Though i do feel ill be doing that anyway.

Hi,

Owen wrote:ACPI is pretty much mandatory for a modern system anyway, unless you plan on implementing millions of motherboard and chipset specific drivers (and even then you'll still have thousands of little "ACPI devices" gnawing at you...).

Unfortunately (as you already know), in order to use ACPI well you have pretend your OS is the latest version of Windows, and behave as if it is Windows. How different versions of Windows behave is not documented, so writing an OS that behaves like Windows isn't easy, so using ACPI well isn't easy.

On top of that, there's bugs in ACPI's AML, and firmware updates to worry about. For example, Microsoft could release a new version of Windows that does things a little differently (e.g. new features), and motherboard manufacturers can release a firmware update to suit the new version of Windows, and the firmware update can change the AML and break your OS. This has happened before.

Even without these problems, ACPI is a bloated/over-complicated mess.

In my opinion, the best approach would be to have motherboard drivers, where ACPI (or ACPICA) is the default motherboard driver. In this case, if you're lucky and there's a motherboard driver designed specifically for your motherboard then you get all the advantages of ACPI, plus any extra advantages (it can support things that ACPI doesn't) without the bloat, AML bugs and firmware update risk; and if you're unlucky you end up with the default ACPI driver (or the default "no ACPI driver" for ancient computers).


Cheers,

Brendan

Brendan wrote:Hi,

Owen wrote:ACPI is pretty much mandatory for a modern system anyway, unless you plan on implementing millions of motherboard and chipset specific drivers (and even then you'll still have thousands of little "ACPI devices" gnawing at you...).

Unfortunately (as you already know), in order to use ACPI well you have pretend your OS is the latest version of Windows, and behave as if it is Windows. How different versions of Windows behave is not documented, so writing an OS that behaves like Windows isn't easy, so using ACPI well isn't easy.

Microsoft do document it pretty well. Just, unfortunately, not well enough (or: people rely on implementation details...)

Brendan wrote: in order to use ACPI well you have pretend your OS is the latest version of Windows, and behave as if it is Windows

This leads me to guess, that acpi was designed along side the windows operating system? Or a standard, more for windows?

GhostXoPCorp wrote:

Brendan wrote: in order to use ACPI well you have pretend your OS is the latest version of Windows, and behave as if it is Windows

This leads me to guess, that acpi was designed along side the windows operating system? Or a standard, more for windows?

ACPI is an OS independent standard. Macs have pretty good ACPI tables. I'm sure servers (Where non-Windows OSes are not unexpected) have pretty good ACPI tables.

However, desktop-class motherboards inevitably are only tested against Windows. Hence, you need to lie through your teeth to them that you're Windows...

I see, you have to play as windows acpi wise to get ahold of resources