How to develop the GPIO dirver on Win10?

Dear All,

The aim of our project is to access Processor GPIO pins and read/write its high/low. Our OS is Windows10 IoT, and Processor is Intel Atom.
We only have some experience with filter driver and filesystem driver, but no experience with hareware driver development.

Since I am a beginner of hardware driver, I thought the effective way is learning from Microsoft’s ducuoment and sample codes.
I have gone through the following and related links,
https://docs.microsoft.com/en-us/windows-hardware/drivers/gpio/gpio-driver-support-overview
Then I know a GPIO controller drivers and a peripheral device driver are requied to be done.

I built the GPIO sample drivers provided by Microsoft: https://github.com/Microsoft/Windows-driver-samples/tree/master/gpio/samples
And I installed the sample GPIO controller driver “simgpio” by “devcon install simgpio.inf ACPI\TEST0001”.
However, the driver wasn’t loaded successfully. In the callback function SimGpioEvtDeviceAdd, GPIO_CLX_ProcessAddDevicePreDeviceCreate returned the error code STATUS_INVALID_DEVICE_REQUEST.

After that, I found a GPIO controller driver from Intel(iagpio.sys) was already in Windows. Then I tried to start it manually by command line “sc start iagpio”.
It failed, and an error message was found in windows system event log: “The Intel Serial IO GPIO Controller Driver service depends on the following service: GPIOClx. This service might not be installed.
So I listed dirvers already loaded by WinObj, msgpioclx.sys wasn’t there. I thought the GpioClx(msgpioclx.sys) would be pre-loaded, but not really.

We are totally blocked. We had originally planned to begin learning with sample. But the only sample for GPIO didn’t work, it is really despairing for a beginner.
I think we lack of basic knowledge of hardware dirver:
How can OS load a proper driver for an hardware?
When the GpioClx would be loaded?
Is there any essential steps we should do on hardware before install the dirver?

Could any one give me some beginner’s guide for GPIO driver? Any suggestion would be appreciated.

Thanks,
Lei

lei wrote:

The aim of our project is to access Processor GPIO pins and read/write its high/low. Our OS is Windows 10 IoT (Windows 10 Enterprise LTSC), and Processor is Intel Atom C3558.

Then I know a GPIO controller drivers and a peripheral device driver are requied to be done.

After that, I found a GPIO controller driver from Intel(iagpio.sys) was already in Windows. Then I tried to start it manually by command line “sc start iagpio”.

If you have any experience with Windows kernel drivers, then surely you
must know it is not possible to start PnP drivers manually.  The only
way they can get attached to their hardware is to be started
automatically by the PnP mechanism.

By checking the INF, you can see that iagpio.sys is loaded when the ACPI
BIOS exposes an INT33FF device.  If your board’s APCI BIOS is not
exposing that device, then either the BIOS is not up to date, or the
GPIO mechanism it uses is not compatible with iagpio.sys.  Iagpio.sys is
designed for Intel SoC chips.  Are you sure the Atom has GPIO pins?  Do
you have control over the ACPI tables on this board?

Are you working with an Intel representative?  They would have the best
information.

Note: The email was trying to reply to an invalid Discussion (291216).

@Tim_Roberts said:
lei wrote:

The aim of our project is to access Processor GPIO pins and read/write its high/low. Our OS is Windows 10 IoT (Windows 10 Enterprise LTSC), and Processor is Intel Atom C3558.

Then I know a GPIO controller drivers and a peripheral device driver are requied to be done.

After that, I found a GPIO controller driver from Intel(iagpio.sys) was already in Windows. Then I tried to start it manually by command line “sc start iagpio”.

If you have any experience with Windows kernel drivers, then surely you
must know it is not possible to start PnP drivers manually. The only
way they can get attached to their hardware is to be started
automatically by the PnP mechanism.

By checking the INF, you can see that iagpio.sys is loaded when the ACPI
BIOS exposes an INT33FF device. If your board’s APCI BIOS is not
exposing that device, then either the BIOS is not up to date, or the
GPIO mechanism it uses is not compatible with iagpio.sys. Iagpio.sys is
designed for Intel SoC chips. Are you sure the Atom has GPIO pins? Do
you have control over the ACPI tables on this board?

Are you working with an Intel representative? They would have the best
information.

Note: The email was trying to reply to an invalid Discussion (291216).

Thanks Tim,
I asked our BIOS team. They told me that the BIOS didn’t provide the GPIO pins in ACPI table. So they advise me to directly access MMIO.

lei wrote:

I asked our BIOS team. They told me that the BIOS didn’t provide the GPIO pins in ACPI table. So they advise me to directly access MMIO.

Well, that’s simply not the right answer.  If this is a board you are
building for sale (which I assume it is, if you have a BIOS team), then
you cannot possibly hope to sell this as a serious production device
with GPIO resources unless the ACPI DSDT table correctly exposes the
GPIO pins.  You can’t expect production users to use undocumented hacks
to access a resource that you expect to provide.  It’s a design
failure.  The ACPI BIOS modifications are not that hard.  Do it right.

Doing it via MMIO is not that hard, but it’s ugly, and somewhat
delicate.  You need to troll through PCIExpress resources to find the
physical address of the GPIO provider, then map it into virtual memory,
then read and write away.

But I am quite serious that you need to file a defect report through
whatever formal bug reporting system you have.  The situation you have
is not acceptable.

Let’s back-up a bit. I think you’re down the wrong path, Mr. Lei.

You’re using Windows IoT, and you’re using it on a Intel Atom. You don’t say what VERSION of IoT you’re using… but it’s entirely possible that you don’t need to write any driver at all.

Intel will provide the GPIO Controller Driver as part of the BSP. That will work with the MSFT GPIO Class Extensions (GPIOCLX) – These Class Extensions will be loaded when the appropriate GPIO Controller Driver gets loaded (it’s basically a DLL, but in kernel-mode and part of a driver).

Have you installed the correct BSP? Have you read the BPS User Guide and Release Notes?

Then it’s a matter of how the GPIOs themselves are made accessible. IoT Core has a driver that it will load (I can’t remember the name right now, sorry) that lets you use GPIOs in user-mode, like from a C# program, without writing a driver.

OR… if you’re making your own main board based on some CRB, and wiring these GPIOs to some device on that mainboard, your best alternative would be to describe that device in the ACPI BIOS and then write a driver that you load to support that device.

So… let’s back up and start again. What board design are you using and from what was it derived? What GPIOs is it that you want to access? Did you ADD the GPIO Controller or is it part of the standard Intel processor support chip (the PCH)? If it’s part of the PCH, and your board is based on a standard design (almost everyone does this), then the Intel BSP should “just work”;

Once you’ve figured that out, THEN it’s a matter of what you do with those GPIOs and how you access them.

One thing I know for sure “memory map the GPIOs” is not the answer.

I hope that helps,

Peter

@Tim_Roberts said:
lei wrote:

I asked our BIOS team. They told me that the BIOS didn’t provide the GPIO pins in ACPI table. So they advise me to directly access MMIO.

Well, that’s simply not the right answer. If this is a board you are
building for sale (which I assume it is, if you have a BIOS team), then
you cannot possibly hope to sell this as a serious production device
with GPIO resources unless the ACPI DSDT table correctly exposes the
GPIO pins. You can’t expect production users to use undocumented hacks
to access a resource that you expect to provide. It’s a design
failure. The ACPI BIOS modifications are not that hard. Do it right.

Doing it via MMIO is not that hard, but it’s ugly, and somewhat
delicate. You need to troll through PCIExpress resources to find the
physical address of the GPIO provider, then map it into virtual memory,
then read and write away.

But I am quite serious that you need to file a defect report through
whatever formal bug reporting system you have. The situation you have
is not acceptable.

Thanks very much for explaining those to me. I’ll convey those advantages and disadvantages to our team.
I totally agree with you. Accessing GPIO via MMIO is ugly! Since the BIOS team is in a relatively independent branch company, I don’t think they can make a quick response for our requirement.
The worst case is eventually we have to access MMIO, even if it is a bad choice.

@“Peter_Viscarola_(OSR)” said:
Let’s back-up a bit. I think you’re down the wrong path, Mr. Lei.

You’re using Windows IoT, and you’re using it on a Intel Atom. You don’t say what VERSION of IoT you’re using… but it’s entirely possible that you don’t need to write any driver at all.

Intel will provide the GPIO Controller Driver as part of the BSP. That will work with the MSFT GPIO Class Extensions (GPIOCLX) – These Class Extensions will be loaded when the appropriate GPIO Controller Driver gets loaded (it’s basically a DLL, but in kernel-mode and part of a driver).

Have you installed the correct BSP? Have you read the BPS User Guide and Release Notes?

Then it’s a matter of how the GPIOs themselves are made accessible. IoT Core has a driver that it will load (I can’t remember the name right now, sorry) that lets you use GPIOs in user-mode, like from a C# program, without writing a driver.

OR… if you’re making your own main board based on some CRB, and wiring these GPIOs to some device on that mainboard, your best alternative would be to describe that device in the ACPI BIOS and then write a driver that you load to support that device.

So… let’s back up and start again. What board design are you using and from what was it derived? What GPIOs is it that you want to access? Did you ADD the GPIO Controller or is it part of the standard Intel processor support chip (the PCH)? If it’s part of the PCH, and your board is based on a standard design (almost everyone does this), then the Intel BSP should “just work”;

Once you’ve figured that out, THEN it’s a matter of what you do with those GPIOs and how you access them.

One thing I know for sure “memory map the GPIOs” is not the answer.

I hope that helps,

Peter

Thanks Peter! Your answer is greatly appreciated!
Thanks for introduce the concept “BSP” to me. I have found a Intel BSP list for Windows IoT here https://docs.microsoft.com/en-us/windows-hardware/manufacture/iot/bsphardware.
But it seems that Intel doesn’t provide a BSP for our CPU, which is Intel Atom C3558. The vision of IoT OS we use is Windows 10 Enterprise LTSC 10.0.17763.

So I think we indeed need to develop a driver. Since our BIOS team didn’t add GPIO into BIOS ACPI, we cannot use the standard way(using GPIOCLX) to access GPIO.
I’m contacting with BIOS team to see if they can update the BIOS. The worst case is eventually we have to access MMIO, though it is not a good choice.

Any way, thanks very much for writing such a long answer for me! As a beginner of HW driver development, I’m looking forward to learning more from experts like you!

The Atom C3000 series is supported by Microsoft. It’s hard for me to believe there aren’t already drivers for the GPIO controller.

Before investing at lot of time and energy, and coming up with a complex (and bad) solution when nine is needed, I would get some professional assistance. Seriously. Talk to a system builder who has experience with what you’re trying to do. IoT Enterprise is really just “Windows” … it’s not like IoT core. (BTW, this is not a subtle advertisement to get you to contact me or OSR… we’re not really the best folks to help you on this particular question).

It is possible that the only problem that you have is your BIOS is not exposing the resources properly. Your BIOS people make a few entries in the DSDT (this is a table in the BIOS), that causes the Intel/Microsoft GPIO Comtroller driver to load… and you’re good to go from there.

Please… don’t waste possibly months of time playing with writing drivers (writing a GPIO controller driver is a hard job… I know people who’ve done it, and it’s not fun) or, worse, fooling around with memory mapping resources you shouldn’t be touching. Solve the problem correctly.

That’s my advice.

Peter