Prev: My WFP driver hits low performance on win7
Next: Building DLL using WDK tool
From: Will Mansell Will on 12 Jul 2010 07:37
I am writing a device driver for an IT871F on POSReady. The idea is to track
voltages and temperatures.
The INF file contains the correct IO port.

[dogwatch_Device.NT]
CopyFiles=dogwatch_Device.NT.Copy
LogConfig=PortIO.LC0

[PortIO.LC0]
ConfigPriority=HARDRECONFIG
IOConfig=A10-A1F

Unfortunately this generates a resource conflict with motherboard resources.
Disabling the motherboard resources in device manager doesn't resolve the
conflict.
In similar drivers such as GiveIO undocumented kernel calls such as
ke386SetIoAccessMap are used to access this IO range and testing shows that
this method works. I don't want to use this in my driver since the call may
be non-existent in future versions of windows and I don't want to give io
access to anything in user space.
The other option is to use the smbus/I2c but then there would be
synchronization issues.
What is the correct way to address this IO space and how do I resolve the
conflict.

Thanks

Will
From: Scott Noone on 12 Jul 2010 10:42
> Unfortunately this generates a resource conflict with motherboard
> resources.

There's already a device out there claiming the resources, so you can't just
poof up another device with the same requirements list. You'd need to load
your driver over the existing device and not create a new one.

But, you have a bigger problem: you don't own those resources and you don't
know who is talking to them. There's no way to serialize access to the
resources, so in the middle of communicating with the ports you might get
hit with an SMI and the BIOS will start partying on the registers. As you
can imagine, this can lead to unexpected results.

-scott

--
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com


"Will Mansell" <Will Mansell(a)discussions.microsoft.com> wrote in message
news:ED13DA21-337A-45C9-A8D6-5E41B68ABB27(a)microsoft.com...
> I am writing a device driver for an IT871F on POSReady. The idea is to
> track
> voltages and temperatures.
> The INF file contains the correct IO port.
>
> [dogwatch_Device.NT]
> CopyFiles=dogwatch_Device.NT.Copy
> LogConfig=PortIO.LC0
>
> [PortIO.LC0]
> ConfigPriority=HARDRECONFIG
> IOConfig=A10-A1F
>
> Unfortunately this generates a resource conflict with motherboard
> resources.
> Disabling the motherboard resources in device manager doesn't resolve the
> conflict.
> In similar drivers such as GiveIO undocumented kernel calls such as
> ke386SetIoAccessMap are used to access this IO range and testing shows
> that
> this method works. I don't want to use this in my driver since the call
> may
> be non-existent in future versions of windows and I don't want to give io
> access to anything in user space.
> The other option is to use the smbus/I2c but then there would be
> synchronization issues.
> What is the correct way to address this IO space and how do I resolve the
> conflict.
>
> Thanks
>
> Will

From: Maxim S. Shatskih on 12 Jul 2010 11:07
> Unfortunately this generates a resource conflict with motherboard resources.

Once some time long ago (in w2k timeframe or such), the Windows architects - probably with a joint effort with the ACPI spec authors - decided to ban accessing the IO ports listed in the ACPI table as "motherboard resources".

The goal was to only allow ACPI BIOS to do this, and not anyone else.

For me, this idea failed miserably, since 100% of CPU temperature/voltage/fan speed monitoring products _use some hacks to bypass the recommended ways (where the recommended ways is to support this in ACPI table and expose to WMI)_.
The community of MS + BIOS vendors just plain failed to impose the standard way of doing this.

The cleanest among these hacks is what Asus does. It provides the root-enumerated pseudo-device of ATK0110 in their ACPI table, and some AsAcpi.sys driver for it, to be installed.

Then, when you have AsAcpi in the kernel, their tools like AsusProbe do work - by sending IOCTLs to AsAcpi, which calls ACPI methods or touches IO ports.

> The other option is to use the smbus/I2c but then there would be
> synchronization issues.

This can also be a good idea.

So, the ideas in the order or decreasing "implementation cleanness":

a) if you have control over BIOS and its ACPI tables - write ACPI methods to implement the temp/voltage/fan sensors, the methods must touch these IO ports. Then access the values via WMI - even VBScript will be OK.
b) write a driver, in it, invoke an ACPI method call from the ACPI BIOS to do the job
c) write a driver, in it, just stupidly access the hardcoded IO ports without ever arbitrating them by means of PnP
d) reset the IO permission bitmap and do the same as c) does, but from user mode.

--
Maxim S. Shatskih
Windows DDK MVP
maxim(a)storagecraft.com
http://www.storagecraft.com

From: Will Mansell on 19 Jul 2010 10:07
Thanks for both your replies.

For those in a similar situation there are some great bios mod tools and
tutorials.
Google "rebels haven bios".
 | 
Pages: 1
Prev: My WFP driver hits low performance on win7
Next: Building DLL using WDK tool