Have a single PCI device which contains three NICs, courtesy of Altera Ethernet cores. Must implement for WinXPe thus NDIS 5.1. MVPs have suggested implementing a WDM driver for each core, then a single NDIS driver that talks to the individual WDM drivers, which I do not understand, given that a single NDIS driver does not appear to have any concept of multiple ports or channels.
What if at DriverEntry the NDIS driver called NdisMInitializeWrapper once for each ethernet core? It would need to call each time with the same DriverObject, but would presumably get back a different NdisWrapperHandle with each call. That unique NdisWrapperHandle could be used as a context specifier for calls to all other NDIS driver functions.
That won't work; NdisMInitializeWrapper can only be called once per driver.
The rule is: you need to have one device node per network interface. Therefore, if you want 3 Ethernet interfaces, you'll need 3 device nodes in the system. There are a couple ways to get there:
The PCI bus will create a device node for each PCI function number. If your PCI device exposes 3 functions to the bus, then Windows will enumerate 3 miniport device objects. This makes the driver super simple. But, obviously, you have to be able to rejigger the hardware to do this.
Alternatively, if you are stuck with only one PCI device with one PCI function, then you need to multiplex the PCI-enumerated device node yourself. This means you should create your own Virtual Bus Driver (VBD). The PCI bus enumerates one device node, which is associated with the driver for your VBD. Then your VBD turns around and enumerates 3 child nodes, each of which is associated with a miniport.
This approach takes considerably more work, since now you need to write two drivers. Fortunately, WDF makes writing a bus driver possible for mere mortals. Your VBD needs to implement code to share resources (interrupts, config space) among the child network miniports.
The big-name vendors are split on whether they chose option #1 or option #2, so both can work. From your description, it sounds like you've already been given advice to implement a VBD.
Related
I have a question about my CAR's ODB function.
I have a USB dongle with AT90CAN128 uE , the uE has CAN driver and i can use this to read the data traffic on the bus.
I have a BMW 116i but this car uses KWP-fast protocol for the obd2.
I want to ask if can i use the CAN bus to send queries to the ECU for the obd2 available variables.
I am not sure because at work we use the KWP2000 protocol via CAN bus, but i don't have the specification, we use a ready tool on CANoe.
KWP2000 is not CAN, they are completly different. OBD2 includes CAN and KWP2000 (also J1850, among others). They use a different physical layer and you won't be able to use CAN to listen/talk KWP2000.
I am trying to understand how PCI Express works so i can write a windows driver that can read and write to a custom PCI Express device with no on-board memory.
I understand that the Base Address Registers (BAR) in the PCIE configuration space hold the memory address that the PCI Express should respond to / is allowed to write to. (Is that correct understood?)
My questions are the following:
What is a "bus-specific address" compared to physical address when talking about PCIE?
When and how is the BAR populated with addresses? Is the driver responsible for allocating memory and writing the address to the peripheral BAR?
Is DMA used when transferring data from peripheral to host memory?
I appreciate your time.
Best regards,
i'm also working on device driver (albeit on linux) with a custom board. Here is my attempt on answering your questions:
The BARs represent memory windows as seen by the host system (CPUs) to talk to the device. The device doesn't write into that window but merely answers TLPs (Transaction Layer Packets) requests (MRd*, MWr*).
I would say "bus-specific" = "physical" addresses if your architecture doesn't have a bus layer traslation mechanism. Check this thread for more info.
In all the x86 consumer PCs i've used so far, the BAR address seemed to be allocated either by the BIOS or at OS boot. The driver has to work with whatever address has been allocated.
The term DMA seems to abused instead of bus mastering which I believe is the correct term in PCIe. In PCIe every device may be a bus master (if allowed in its command register bit 2). It does so by sending MRd, MWr TLPs to other devices in the bus (but generally to the system memory) and signalling interrupts to the CPU.
From your query its clear that you want to write a driver for a PCIe slave device. To understand the scheme of things happening behind PCIe transfer, a lot of stuff is available on internet (Like PCIe Bus Enumeration, Peripheral Address Mapping to the memory etc).
Yes your understanding is correct regarding the mapping of PCIe registers to the memory and you can read/write them.( For e.g in case of linux PCIe device driver you can do this using "ioremap" ).
An address bus is used to specify a physical address. When a processor or DMA-enabled device needs to read or write to a memory location, it specifies that memory location on the address bus. Nothing more to add to that.
"PCIe bus enumeration" topic will answer your 2nd question.
Your third question is vague. You mean slave PCIe device. Assuming it is, yes you can transfer data between a slave PCIe device and host using a DMA controller.
I am working on a project which involves "PCIe-DMA" connected with the host over the PCIe bus. Really depends on your design and implementation. So in my case PCIe-DMA is itself a slave PCIe device on the target board connected to the host over PCIe.
clarification for your doubts/questions is here.
1> There are many devices thats sits on BUS like PCI which sees Memeory in terms that are different from a Physical address, those are called bus addresses.
For example if you are initaiating DMA from a device sitting on bus to Main memory of system then destination address should be corresponding bus address of same physical address in Memmory
2> BARS gets populated at the time of enumeration, in a typical PC it is at boot time when your PCI aware frimware enumerate PCI devices presents on slot and allocate addresses and size to BARS.
3> yes you can use both DMA initiated or CPU initiated operations on these BARS.
-- flyinghigh
I want to understand the performance of one device driver module in linux kernel. In this case I use carl9170 device driver in linux.
If I use two physical interfaces, how can the single module carl9170 handle 2 different physical interfaces?
Because so far, I have known that these 2 physical interfaces will make 2 instances and use different packet buffers for each but just using single carl9170 module. So it's confusing me.
And which file in linux kernel source code can I find about this handling method (relates to carl9170 device driver)?
Thank you very much for your help
For 2, take a look at the folder:
drivers/net/wireless/ath/carl9170/
This folder is located under your kernel source directory. It contains all the sources of the driver.
For 1:
It is pretty much how classes works on oriented object programming: how does an object know which instance of the data it must work with? The this pointer references the correct in memory data.
Take a look at the file drivers/net/wireless/ath/carl9170/carl9170.h. Every function exported by the driver is declared at this file. Note that every function has at its first parameter a reference to the struct ar9170 data type. This is exactly the data set that the driver must work with. It specifies everything the driver need to know about the device and its sates, since the USB buses address where the device is connected, to the state of the device, like its power, connection state and any other data the driver itself need in order to keep the device working properly.
Note that this is driver internal data thought. The kernel has its own set of data to keep both the driver, the device and the kernel itself working.
Take a look at the 546 line of carl9170.h. It is where the function declarations starts. This file is as of the kernel 3.8.8.
Just like in Object Oriented Programming you would allocate as many instances of a class as you need, the kernel will allocate as many ar9170 structures a it needs, one referencing each device.
The device ids can be obtained under the /sys/class/net directory. There will be a soft link for each of the network devices attached to your computer. This link will point the device to something like the following:
$ ls -l eth0
../../devices/pci0000:00/0000:00:04.0/0000:02:00.0/net/eth0
The pci0000:00 is the bus. The 0000:00:04.0 I believe is the bus address. Finally, the 0000:02:00.0 is the device id. Afaik, every registered device follows the same logic.
Finally, if you have two carl9170 devices, both will be under the directory /sys/class/net but probably one of them will be named wifi0 and the other wifi1. Also, each of them will point to different devices (check it with the command ls -l /sys/class/net).
I just would like to note that in the explanation I haven't used any wireless card. So I'm not sure whether wireless cards are shown under /sys/class/net or not. Anyway, it will be something very similar, like /sys/class/wireless.
I want to write a program which will "lock" a computer to a user determined wireless network.
It should automatically establish and maintain the connection with the specified network
Other networks should be hidden and/or inaccessible while the program is running
Should be compatible with Windows XP - 8
Should work for all wireless cards
Could I create an NDIS filter driver or NDIS intermediate driver for this? Which one is a better option? Also, the MSDN documentation I linked does not seem to provide good information about how to actually write the driver, where can I find that?
I am willing to build a prototype of network appliance.
This appliance is suppose to transparently manipulate Ethernet packets. It suppose to have two network interface cards having one card connected to the outside leg (i.e. eth0) and the other to the inside leg (i.e. eth1).
In a typical network layout as in the attached image, it will be placed between the router and the LAN's switch.
My plans are to write a software that hooks at the kernel driver level and do whatever I need to do to incoming and outgoing packets.
For instance, an "outgoing" packet (at eth1) would be manipulated and passed over to the other NIC (eth0) which then should be transported over to the next hope
My questions are:
Is this doable?
Those NIC's will have no IP address, is that should be a problem?
Thanks in advance for your answers.
(And no, there is no such device yet in the market, so please, "why reinvent the wheel" style of answers are irrelevant)
typical network diagram http://img163.imageshack.us/img163/1249/stackpost.png
I'd suggest libipq, which seems to do just what you want:
Netfilter provides a mechanism for passing packets out of the stack for queueing to userspace, then receiving these packets back into the kernel with a verdict specifying what to do with the packets (such as ACCEPT or DROP). These packets may also be modified in userspace prior to reinjection back into the kernel.
Apparently, it can be done.
I am actually trying to build a prototype of it using scapy
as long as the NICs are set to promiscous mode, they catch packets on the network without the need of an IP address set on them. I know it can be done as there are a lot of companies that produce the same type of equipment (I.E: Juniper Networks, Cisco, F5, Fortinet ect.)