Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

Re: PCI problem - PnP OS settings and Class 6:0 devices

Jake_OshinsJake_Oshins Member Posts: 1,058
The issues here are separate. Setting "PnP OS" in the BIOS causes the BIOS
to skip configuration of some devices, making boot faster. Windows can then
interleave the configuration of those devices with other setup and the whole
machine comes up a little sooner.

In general, Windows will leave any BIOS-based configuration intact, choosing
new BAR values only when old ones don't exist. (There are some corner cases
where this isn't true, but they're not worth going into here.) This
strategy allows the BIOS to work around some chipset bugs that Windows might
not be aware of.

Unfortunately, your device is not part of the chipset and what a BIOS does
with it is going to vary wildly with that class code combination.

Furthermore, we here at Microsoft (and probably others elsewhere) know
empirically that lots of machines die a horrible death if you ever disable
the BARs on a Class 6 - Subclass 0 device. Thus Windows can't even probe
your BARs to find out how large they are, since getting the size of a BAR
involves temporarily disabling it and writing all 1's to it. So Windows
cannot generate a valid resource claim for your device, and setting
something one way or the other in the BIOS isn't going to change that.

- Jake Oshins
Windows Kernel Team


wrote in message news:xxxxx@ntdev...
Hi Jake,
Can you clarify something for me? I thought that windows would only
program BAR's if you enable PNP OS in your BIOS. Microsoft's own Knowledge
Base article recommends turning off PNP in the BIOS. The idea being that
the the mother board manufacturer (BIOS writer) can better balance the
resources since the they have more knowledge about the hardware particulars
on that board. Have I misinterpreted something? If I haven't your reply (a
great one BTW) seems to assume that PNP OS is enabled in the BIOS.

Thanks in advance for your explanation,
-z

At 01:33 PM 10/7/2006, you wrote:

Windows is doing that because the definition of Class 6 - Subclass 0 has
been effectively established by precedent (by lots of existing chipsets) in
such a way that Windows *absolutely positively must never touch the memory
BARs on the the device.* Lots of chipsets die a horrible death if you touch
the BARs on the "host bridge" device, which is the one with that class code.

With that said, you can work around this. You'll have to supply a handler
for IRP_MN_FILTER_RESOURCE_REQUIREMENTS and handle it as the PCI driver
would handle IRP_MN_QUERY_RESOURCE_REQUIREMENTS. Add in the missing memory
requirements. Then program your own BARs. Then remove these extra
resources in IRP_MN_START_DEVICE before the IRP gets down to the PCI driver.
The PCI driver must never see the changes you've made, so you'll need to
keep the original contents of these IRPs around and put them in the various
IRPs when they get sent down to PCI and then put your stuff back when the
IRPs come back up to you.

This is all much easier with KMDF, believe it or not, as Doron and I worked
pretty hard to make this scenario work. You just supply the stuff you're
adding and KMDF will manage inserting and removing it when necessary.

- Jake Oshins
Windows Kernel Team

Comments

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Thank you for the explanation Josh..... It was the other guys board
    however. Our board started working fine after I told our FPGA guy to
    stop putting bridge class codes in (we aren't a bridge). The guy
    originally asking the question can't change his for some reason.

    Thanks again,
    z


    At 07:36 AM 10/11/2006, you wrote:
    >The issues here are separate. Setting "PnP OS" in the BIOS causes the BIOS
    >to skip configuration of some devices, making boot faster. Windows can then
    >interleave the configuration of those devices with other setup and the whole
    >machine comes up a little sooner.
    >
    >In general, Windows will leave any BIOS-based configuration intact, choosing
    >new BAR values only when old ones don't exist. (There are some corner cases
    >where this isn't true, but they're not worth going into here.) This
    >strategy allows the BIOS to work around some chipset bugs that Windows might
    >not be aware of.
    >
    >Unfortunately, your device is not part of the chipset and what a BIOS does
    >with it is going to vary wildly with that class code combination.
    >
    >Furthermore, we here at Microsoft (and probably others elsewhere) know
    >empirically that lots of machines die a horrible death if you ever disable
    >the BARs on a Class 6 - Subclass 0 device. Thus Windows can't even probe
    >your BARs to find out how large they are, since getting the size of a BAR
    >involves temporarily disabling it and writing all 1's to it. So Windows
    >cannot generate a valid resource claim for your device, and setting
    >something one way or the other in the BIOS isn't going to change that.
    >
    >- Jake Oshins
    >Windows Kernel Team
    >
    >
    > wrote in message news:xxxxx@ntdev...
    >Hi Jake,
    > Can you clarify something for me? I thought that windows would only
    >program BAR's if you enable PNP OS in your BIOS. Microsoft's own Knowledge
    >Base article recommends turning off PNP in the BIOS. The idea being that
    >the the mother board manufacturer (BIOS writer) can better balance the
    >resources since the they have more knowledge about the hardware particulars
    >on that board. Have I misinterpreted something? If I haven't your reply (a
    >great one BTW) seems to assume that PNP OS is enabled in the BIOS.
    >
    >Thanks in advance for your explanation,
    >-z
    >
    >At 01:33 PM 10/7/2006, you wrote:
    >
    >Windows is doing that because the definition of Class 6 - Subclass 0 has
    >been effectively established by precedent (by lots of existing chipsets) in
    >such a way that Windows *absolutely positively must never touch the memory
    >BARs on the the device.* Lots of chipsets die a horrible death if you touch
    >the BARs on the "host bridge" device, which is the one with that class code.
    >
    >With that said, you can work around this. You'll have to supply a handler
    >for IRP_MN_FILTER_RESOURCE_REQUIREMENTS and handle it as the PCI driver
    >would handle IRP_MN_QUERY_RESOURCE_REQUIREMENTS. Add in the missing memory
    >requirements. Then program your own BARs. Then remove these extra
    >resources in IRP_MN_START_DEVICE before the IRP gets down to the PCI driver.
    >The PCI driver must never see the changes you've made, so you'll need to
    >keep the original contents of these IRPs around and put them in the various
    >IRPs when they get sent down to PCI and then put your stuff back when the
    >IRPs come back up to you.
    >
    >This is all much easier with KMDF, believe it or not, as Doron and I worked
    >pretty hard to make this scenario work. You just supply the stuff you're
    >adding and KMDF will manage inserting and removing it when necessary.
    >
    >- Jake Oshins
    >Windows Kernel Team
    >
    >
    >
    >---
    >Questions? First check the Kernel Driver FAQ at
    >http://www.osronline.com/article.cfm?id=256
    >
    >To unsubscribe, visit the List Server section of OSR Online at
    >http://www.osronline.com/page.cfm?name=ListServer
  • Robert_GaurieRobert_Gaurie Member Posts: 144
    I can't change mine because we bought the board from Freescale and they messed up. They are supposed to change the subclass to 20 but that is a few months away. That is a long time. You mentioned KMDF. Are there any good books on this? I am new to drivers and my limied experience is with the WDM drivers. I only know that KMDF is built on top of WDM to make life easier.

    Tim
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    I don't have a KMDF book, I learned by writing to WDM. I can tell
    you though that using KMDF will get you up and runny much faster as
    Microsoft has done all the boiler-plate leg work for you. I
    estimated a PCI driver at 2 months, and we were up and running in a
    couple weeks (Interrupts / DMA etc...). They have some great
    samples to look at.

    -z

    At 01:55 PM 10/11/2006, you wrote:
    >I can't change mine because we bought the board from Freescale and
    >they messed up. They are supposed to change the subclass to 20 but
    >that is a few months away. That is a long time. You mentioned
    >KMDF. Are there any good books on this? I am new to drivers and my
    >limied experience is with the WDM drivers. I only know that KMDF is
    >built on top of WDM to make life easier.
    >
    >Tim
    >
    >---
    >Questions? First check the Kernel Driver FAQ at
    >http://www.osronline.com/article.cfm?id=256
    >
    >To unsubscribe, visit the List Server section of OSR Online at
    >http://www.osronline.com/page.cfm?name=ListServer
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Writing WDF Drivers 25 Feb 2019 OSR Seminar Space
Developing Minifilters 8 April 2019 OSR Seminar Space