Access to system specific hardware and system information can be achieved without the need to write a custom device driver.

Normally the only way to access hardware in a Windows Embedded system is by writing a custom device driver. This can be costly and complicated especially when only limited access is needed. It becomes even more difficult when devices on a resource like the SMBUS need to be accessed to get information.

What is overlooked in many cases is the possibility to use the WMI to ACPI mapper driver (wmiacpi.sys).This driver allows mapping of ASL code variables, control methods and events to WMI. By using this method an application can interact safely with system resources. This method of accessing system resources can be used for several purposes:

• Reading and setting of GPIO pins in the system
• Reading system information
• Reading CMOS settings and setting them
• Access to system sensors
• Passing system events to WMI
• many more uses can be envisioned, please feel free to make suggestions

Once the parameters are defined and available in the WMI space they can be used in C++ programs, scripts .NET applications etc.

How to implement

The ACPI to WMI mapping driver will be loaded when ACPI indicates the PNP0C14 device is available.

The BIOS should contain the ASL code required to access the information that should be available to the outside world. The variables, methods and events will be mapped to WMI space using a MOF file. This MOF file can be on disk but since all of this is linked to to the BIOS code it makes more sense to embed this into the BIOS. It will then be automatically available.

There are several ways to implement the functionality. All platform specific items can be handled in a single PNP0C14 device but it is also possible to expose multiple devices and implement a single feature in a device. The latter might make it easier to re-use the BIOS code or to differentiate in the feature set among various boards.

Once all of this is implemented the parameters and methods can be accessed as any other WMI parameter and it can be controlled from user mode.

Examples

As mentioned above there are many possible uses for this method of accessing system resources.

An obvious one are the GPIO pins that are in general available on a system. Normally there is no easy way to access those since a driver is required to do this. What makes it even more difficult is that this driver needs to be aware of the system it is running on. If e.g. a GPIO is used for some critical task the driver should not manipulate it an generate a system crash. By using this method the OEM can define a board independent method of accessing the GPIO pins. By using this method the GPIO pins that should not be updated by a driver will not be exposed to the WMI space. When defined correctly it is even possible to use an application on multiple platforms without the need to rewrite the application. The ASL code in the BIOS can make sure the parameters exposed in WMI space are translated correctly to the underlying hardware.

Another possible uses are, enabling and disabling of integrated peripherals. Instead of just implementing anonymous GPIO pins an OEM can decide to make an interface available to enable and disable onboard features using WMI. By doing this certain OEM specific features can be enabled and disabled using user mode code and even VBS scripts. This can be convenient when large amounts of systems need to be managed. It eliminates the need to enter BIOS SETUP (and reboot) to make these changes.

SMBUS access is another. Besides the fact that a driver is required it is also risky to access devices on the SMBUS when devices are connected that are also used during runtime conflicts can easy occur. Using this method the BIOS will take care of the synchronization of the accesses.

The last one I want to mention here are SETUP settings that can be read and updated. Normally it is virtually impossible to manipulate the CMOS area that the BIOS uses to store it's setup settings. The locations where parameters are store vary from BIOS to BIOS and can even be different from one build to another. Besides that the are is protected by checksum or CRC. By defining fixed parameters it is possible to read and update the parameters the OEM wants to make available to the WMI space. The BIOS will handle the all the dependencies.

Hopefully this gives you a basic understanding of the possibilities the WMI to ACPI driver brings you. If you have an idea and want to know if it can be realized this way please let us know and we'll provide you with the proper feedback.

To implement this method access to the systems ASL code is required. You should contact us to make the necessary additions to the ASL code.