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
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
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
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