Hello
I am new to DDK. I want to write a driver to use my Xilinx FPGA-based PCI
Express board. How can i write a driver and configure it’s Base Address
Registers?
–
Naveed Ahmed
Mobile no. +92 (0)300 3833106
Start with the sample C:\WinDDK\6001.18001\src\kmdf\pcidrv and modify it to
match your specific hardware and your device IO processing requirements.
On Mon, Aug 4, 2008 at 5:43 AM, Naveed Ahmed wrote:
> Hello
>
> I am new to DDK. I want to write a driver to use my Xilinx FPGA-based PCI
> Express board. How can i write a driver and configure it’s Base Address
> Registers?
>
> –
> -------------------------
> Naveed Ahmed
> Mobile no. +92 (0)300 3833106
> — 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
–
Mark Roddy
After you get sample of pcidrv , take look at the nici_init.c file the function NICMapHWResources, Code is well documented.
Naveed Ahmed wrote:
I am new to DDK. I want to write a driver to use my Xilinx FPGA-based
PCI Express board. How can i write a driver and configure it’s Base
Address Registers?
You don’t configure the BARs. That’s done by the BIOS at boot time.
When your driver loads, the plug-n-play system will hand you the BAR
addresses you were assigned.
There are several examples of simple PCI drivers in the WDK.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> You don’t configure the BARs. That’s done by the BIOS at boot time.
Interrupts - yes, BARs - only for boot disk controller.
When your driver loads, the plug-n-play system will hand you the BAR
addresses you were assigned.
PnP will assign them itself using the arbiter for CmResourceTypeMemory, and
send you the result in MN_START_DEVICE.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Maxim S. Shatskih wrote:
> You don’t configure the BARs. That’s done by the BIOS at boot time.
>Interrupts - yes, BARs - only for boot disk controller.
I don’t know what you were trying to say, Maxim, but as written this is
simply incorrect. *ALL* PCI devices are assigned BARs by the BIOS at
boot time. At least through XP, Windows uses the addresses assigned by
the BIOS. Later systems might do their own rebalancing.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> simply incorrect. *ALL* PCI devices are assigned BARs by the BIOS at
boot time. At least through XP, Windows uses the addresses assigned by
the BIOS.
BARs? or interrupts? I remember BARs being not assigned for non-boot PCI cards
on old Pentium-MMX computers, for instance.
Interrupts are another song.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
For all we know, and perhaps lost in translation, the OP might have meant
“allocate a system mapping foreach of my bars” when he wrote “configure it’s
Base Address Registers”. I figured he was massively lost and needed to stare
at some source code and then consult the ntdev magic eight ball again with a
better formulated question or two.
On Mon, Aug 4, 2008 at 3:39 PM, Tim Roberts wrote:
> Maxim S. Shatskih wrote:
>
>> You don’t configure the BARs. That’s done by the BIOS at boot time.
>>>
>>>
>>
>> Interrupts - yes, BARs - only for boot disk controller.
>>
>>
>
> I don’t know what you were trying to say, Maxim, but as written this is
> simply incorrect. ALL PCI devices are assigned BARs by the BIOS at boot
> time. At least through XP, Windows uses the addresses assigned by the BIOS.
> Later systems might do their own rebalancing.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> 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
>
–
Mark Roddy
Maxim S. Shatskih wrote:
> simply incorrect. *ALL* PCI devices are assigned BARs by the BIOS at
> boot time. At least through XP, Windows uses the addresses assigned by
> the BIOS.
>BARs? or interrupts? I remember BARs being not assigned for non-boot PCI cards
on old Pentium-MMX computers, for instance.
If so, that was a BIOS failure. Memory and I/O BARs are assigned by the
BIOS. There is no guarantee that an operating system is ever going to
be loaded. If the BIOS didn’t assign addresses, the devices would not
be usable.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim, this varies a lot from BIOS to BIOS. Some configure all the
devices and some just configure those necessary for booting. If the
BIOS has a switch within it that is labled “PnP OS?” that switch
usually affects this behavior.
We at Microsoft spent a lot of effort a few years ago trying to get
BIOSes to boot faster and one of the ways to do that was to get them
to only mess with the memory controller and the boot devices.
Depending on how complicated you make your splash screen, they can now
boot very quickly in some cases.
–
Jake Oshins
Hyper-V I/O Architect
Microsoft
This post confers no rights and implies no warranties.
“Tim Roberts” wrote in message news:xxxxx@ntdev…
> Maxim S. Shatskih wrote:
>>> You don’t configure the BARs. That’s done by the BIOS at boot
>>> time.
>>>
>>
>> Interrupts - yes, BARs - only for boot disk controller.
>>
>
> I don’t know what you were trying to say, Maxim, but as written this
> is simply incorrect. ALL PCI devices are assigned BARs by the
> BIOS at boot time. At least through XP, Windows uses the addresses
> assigned by the BIOS. Later systems might do their own rebalancing.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
Jake,
Some configure all the devices and some just configure those necessary for booting.
But even if the OS handles configuration itself, apparently, it still has to rely upon BIOS (for example, ACPI methods) in order to to it, right? After all, BIOS is the only “entity” that knows everything about the target motherboard…
Anton Bassov
I think there are rules about exposing BARs and other information in the
PCIe specification. Also for PCI and PCI-X there are rules and documented
structures. I know there are specific defined data entities located in the
0x200 bytes of the main memory bar.
I remember that for NT4 and a while for Windows 2000 you always selected
Non-PnP OS in the BIOS to not allow Windows to allocate the resources. I
guess some of the choices were not optimal for newer motherboards.
wrote in message news:xxxxx@ntdev…
>
> Jake,
>
>>Some configure all the devices and some just configure those necessary for
>>booting.
>
> But even if the OS handles configuration itself, apparently, it still has
> to rely upon BIOS (for example, ACPI methods) in order to to it, right?
> After all, BIOS is the only “entity” that knows everything about the
> target motherboard…
>
> Anton Bassov
>
> I think there are rules about exposing BARs and other information in the PCIe specification.
Also for PCI and PCI-X there are rules and documented structures.
Please note that some info in PCI Configuration space may be invalid for a given OS configuration. For example, IRQ-related info is invalid for APIC-based system, because it indicates IRQs, rather than IOAPIC pins. Therefore, the OS gets all info from BIOS tables, rather than from PCI Configuration space…
Anton Bassov
> If so, that was a BIOS failure. Memory and I/O BARs are assigned by the
BIOS. There is no guarantee that an operating system is ever going to
be loaded. If the BIOS didn’t assign addresses, the devices would not
be usable.
And they - except the boot disk controller - are really not usable until the OS
and the driver will load.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> Tim, this varies a lot from BIOS to BIOS. Some configure all the
devices and some just configure those necessary for booting. If the
BIOS has a switch within it that is labled “PnP OS?” that switch
usually affects this behavior.
At least this settings affects PCI interrupt assignment for sure.
The thing is that it is not a problem to assign BARs in the OS - they are just
memory addresses, and 0xcf8/cfc ports are here (or their more modern ACPI
analog).
Interrupts are harder, since the interrupt assignment requires the knowledge of
wiring from PCI INTA# wires to PIC/APIC inputs, this wiring is
motherboard-specific and thus the BIOS is the only source of this knowledge.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> But even if the OS handles configuration itself, apparently, it still has to
rely upon
BIOS (for example, ACPI methods) in order to to it, right? After all, BIOS is
the
only “entity” that knows everything about the target motherboard…
Memory and IO port BAR assignment is doable in standard mobo-independent ways,
not so with interrupts.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
David Craig wrote:
I think there are rules about exposing BARs and other information in the
PCIe specification. Also for PCI and PCI-X there are rules and documented
structures. I know there are specific defined data entities located in the
0x200 bytes of the main memory bar.
That’s not true, at least not the way you have written it. The
configuration space is well-defined, yes, but there is no meaning at all
assigned to any part of any BAR, and there is no such thing as a “main”
memory BAR.
I remember that for NT4 and a while for Windows 2000 you always selected
Non-PnP OS in the BIOS to not allow Windows to allocate the resources. I
guess some of the choices were not optimal for newer motherboards.
That setting did not PREVENT Windows from allocating the resources. It
merely told the BIOS that the operating system was not capable it, so
the BIOS had to do a complete job.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Certainly. Your question really has two aspects.
-
What does the OS rely on the BIOS to do?
-
What configurations that the BIOS chose does the OS preserve or
reconfigure later.
For the first one, it’s helpful to know that there are a class of
devices which don’t follow any PnP specs at all, mostly because the
logic predates these specs. On a modern motherboard, this is the
floppy controller (which probably has no floppy drive plugged into
it,) the serial ports, the parallel port, etc. It’s also the root PCI
bus, since there is no public spec for how a processor bus attaches to
a PCI bus. (The lack of a root PCI bus spec is actually a good thing,
as it has allowed a lot of flexibility over the years, leading to the
success of PCI in general.)
These devices can have PnP added into them through the BIOS by
providing ACPI methods. In the past (and possibly in the present,
though I haven’t checked) our Hardware Compatibility Tests would fail
any machine that didn’t supply at least two possible configurations
for every device, so that there was some possibility for rebalance if
a device was hot-plugged while the machine was running and it needed
the particular resources that a device was using.
A later class of PCI devices, ones that didn’t have the power
management capability structure, could have power management added
into them through ACPI, as long as they were on the motherboard and
not in a slot.
An even later class of devices that did have the PM cap struct could
have hot-plug added into them through ACPI.
For the second question, the answer is more complicated. When we were
developing Windows 2000, we read all the various specs (some of which
had essentially been written by the Win9x team) and we decided that we
could figure out how to configure a machine. So we wrote the code to
do that and many of the machines in the world wouldn’t run our first
beta. When we looked at the root cause of the issue, it became clear
that two things were in play. First, chipset makers thought that they
were exempt from actually following the PCI spec if their devices were
embedded in a chipset, even when those devices had a PCI config space.
(They reasoned that there were lots of non-PCI devices in a chipset,
so PCI was clearly not required.) Second, there are just a lot of
hardware bugs in the world. (There are software bugs, too, but those
aren’t the ones that affected this situation.)
So we discovered that the BIOSes were hiding a lot of potential bugs
by configuring the boards in just such a way that they happened to
work. So we rewrote a lot of the code in Windows 2000 and that code
still exists today. The new code looks at the “boot configuration” of
every device before configuring anything (as much as is possible) and
attempts to preserve the configuration of devices which the BIOS
configured. This allows BIOSes to mostly cover up a couple of classes
of defects and intentional deviations from the PCI spec.
It’s still quite possible that the OS will attempt to reconfigure a
device, particularly after you shove something into a PCMCIA or
Cardbus slot. We have a series of HCTs that forces reconfigurations
to try to test that this will actually work, though we’re more
conservative in normal operation.
–
Jake Oshins
former PnP resource arbitration guy
Microsoft
This post confers no rights and implies no warranties.
wrote in message news:xxxxx@ntdev…
>
> Jake,
>
>>Some configure all the devices and some just configure those
>>necessary for booting.
>
> But even if the OS handles configuration itself, apparently, it
> still has to rely upon BIOS (for example, ACPI methods) in order to
> to it, right? After all, BIOS is the only “entity” that knows
> everything about the target motherboard…
>
> Anton Bassov
>
OK, I think we may agree. With the chips for which I write drivers, there
are specific meanings to the 6 32-bit base addresses. Really there are only
three 64-bit addresses since our devices are fully 64-bit addressable. We
also don’t use IO space. I looked in the MindShare book for PCIe and see
that area is far more complex than our implementation since we don’t need
the other capabilities. I know that when the chip is read the physical
address of our memory mapped area is present. I guess the BIOS has to take
something we give it and then it fills in whatever physical address it wants
to assign. I also know I have to get a virtual address for that physical
address during my miniport’s startup callback and by then all the magic is
done with IRQ and addresses ready and available for me to use.
OK, the ‘main’ is probably not implied in the spec, but it definitely is for
our devices. Most only have one but there are a few that have two. Since
those that have two are rather different in that the multiple addresses in
one refer to multiple devices while in the other the second address is for
additional features of the only device, I guess my use of ‘main’ was
specific to my company. Mostly due to the second form being a new device it
was the one that is formost in my mind. I have heard, but not researched
into how it is implemented in that this area can be ‘function’ oriented so
that multiple devices can see different data even if the devices are just
multiple devices of the same type.
“Tim Roberts” wrote in message news:xxxxx@ntdev…
> David Craig wrote:
>> I think there are rules about exposing BARs and other information in the
>> PCIe specification. Also for PCI and PCI-X there are rules and
>> documented structures. I know there are specific defined data entities
>> located in the 0x200 bytes of the main memory bar.
>>
>
> That’s not true, at least not the way you have written it. The
> configuration space is well-defined, yes, but there is no meaning at all
> assigned to any part of any BAR, and there is no such thing as a “main”
> memory BAR.
>
>> I remember that for NT4 and a while for Windows 2000 you always selected
>> Non-PnP OS in the BIOS to not allow Windows to allocate the resources. I
>> guess some of the choices were not optimal for newer motherboards.
>>
>
> That setting did not PREVENT Windows from allocating the resources. It
> merely told the BIOS that the operating system was not capable it, so the
> BIOS had to do a complete job.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> Memory and IO port BAR assignment is doable in standard mobo-independent ways,
I think this is not entirely correct. The problem is that you don’t know anything about available resources/memory ranges at a boot time, and the only “entity” that is able to provide you with this info is BIOS. Please note that BIOS may want to keep some resources/memory ranges reserved, and the OS has to respect this…
Anton Bassov