Dynamic driver load specifying hardware resources?

NTDEV
1

Hello,

I have been given a driver that is dynamically loaded at run-time (using CreateService(…, SERVICE_KERNEL_DRIVER, SERVICE_DEMAND_START, …) and StartService). I know that this is not the appropriate method but it is what I have been given.

This driver does IO port accesses (reads and writes) using inline assembly code (__outbyte, __inbyte) to CMOS memory area (0x70-0x71 and software SMI 0xB2).

Sometimes when the program is run, strange results are seen. I think this is because the OS is also accessing CMOS (for real time clock, etc.) at the same time. But, maybe not.

I would like to change this to use (READ|WRITE)_PORT_BYTE functions, but I think in order to do that I need to request (and receive) access to the IO port addresses, right?

And I think the only way I can request IO address access is through the logical configuration directives in the INF, right? (Which is not possible to do with a driver that is dynamically loaded like this one).

And I think I may not be given access to the CMOS ports anyway, right?

Thanks in advance!,
-John.

2

I forgot to ask if I should avoid using Hal(Get|Set)BusData? I think these are deprecated functions (of course, so is dynamically loading the driver like this…)

3

You have a more serious problem, you don’t own the ports so sooner of
later your driver will mess up. Starting with Windows XP using a legacy
driver (i.e. start service) with real hardware is not guaranteed to
work. But you cannot claim he hardware with Plug and Play since the OS
already has.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“jnichol@us.lenovo.com” wrote in message
news:xxxxx@ntdev:

> I forgot to ask if I should avoid using Hal(Get|Set)BusData? I think these are deprecated functions (of course, so is dynamically loading the driver like this…)

4

What’s the SMI for?

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
jnichol@us.lenovo.com
Sent: Friday, November 05, 2010 10:25 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Dynamic driver load specifying hardware resources?

Hello,

I have been given a driver that is dynamically loaded at run-time (using
CreateService(…, SERVICE_KERNEL_DRIVER, SERVICE_DEMAND_START, …) and
StartService). I know that this is not the appropriate method but it is what
I have been given.

This driver does IO port accesses (reads and writes) using inline assembly
code (__outbyte, __inbyte) to CMOS memory area (0x70-0x71 and software SMI
0xB2).

Sometimes when the program is run, strange results are seen. I think this is
because the OS is also accessing CMOS (for real time clock, etc.) at the
same time. But, maybe not.

I would like to change this to use (READ|WRITE)_PORT_BYTE functions, but I
think in order to do that I need to request (and receive) access to the IO
port addresses, right?

And I think the only way I can request IO address access is through the
logical configuration directives in the INF, right? (Which is not possible
to do with a driver that is dynamically loaded like this one).

And I think I may not be given access to the CMOS ports anyway, right?

Thanks in advance!,
-John.

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

5

I did a quick implementation using Hal(Get|Set)BusData. This seems to work, but only for the first 128 bytes of CMOS. Does anyone know if this routine knows about 256 byte CMOS? I think I’ve read elsewhere that it only uses IO ports 0x70 and 0x71, but for the larger CMOS I think one needs to use IO addresses 0x72 and 0x73 (in the same manner). I am currently call these routines repeatedly inside of a loop getting one byte at a time (because that is how the driver was originally…), but I could change this to one call asking for 256 bytes…

@mm:
The SMI is for getting/setting some security variables that are stored in a EEPROM on the board.

-John.

6

Well… hmmm.

You can’t safely just do direct port access, I can assure you that. You’re missing the spin lock that protects this stuff.

So… if you HAVE to do what you’re doing (shudder) HalGetBusData is probably the right way to go. You (and other readers) might note that HalGetBusData and HalSetBusData aren’t even deprecated for use in accessing the CMOS.

In terms of max LENGTH… I’m sorry, but I can’t help you there.

Peter
OSR