Cnfox928

• Download libusbK for free. A complete software solution for windows usb devices. LibusbK is a complete driver/library solution for vendor class usb device interfaces. If you are a usb developer or usb device manufacturer seeking a driver solution for a new USB widget then libusbK could be for you.
• Dxgkrnl is a brand-new kernel driver for Linux that exposes the /dev/dxg device to user mode Linux. /dev/dxg exposes a set of IOCTL that closely mimic the native WDDM D3DKMT kernel service layer on Windows. Dxgkrnl inside of the Linux kernel connects over the VM Bus to its big brother on the Windows host and uses this VM bus connection to.
• The latest programmer software can be downloaded in the Download section. The needed programmer hardware itself is very simple and can easily be built up using a few standard componets. PICPgm supports all kind of serial port programmers as well as parallel port programmers. Furthermore a USB programmer is supported.

1. Linux Developer Community Port Devices Driver Download For Windows 10
2. Linux Developer Community Port Devices Driver Download For Windows 7
3. Linux Developer Community Port Devices Driver Download For Windows Xp
4. Linux Developer Community Port Devices Driver Download For Windows 8

Download Box apps on all your devices: Mac, Windows, iPhone, Android, for seamless collaboration and security that satisfies even the most regulated industries. Downloads Software Downloads Whether you’re looking to enhance the functionality of your app or optimize its performance, Qualcomm Developer Network offers you the software tools and resources to bring out the best in your development.

For most devices, the Ports device setup class and the Serial function driver provide the functionality required to operate serial ports and COM ports. To install serial ports and COM ports using these system-supplied components, do the following:

• Openpilot driver download for windows 10. Provide an INF file that specifies the Ports device setup class and the Serial function driver as the service for the port.

• To configure a serial port as COM port, comply with the requirements that are defined in Configuration of COM Ports.

For more information about installing serial ports and COM ports using the Ports device setup class and the Serial function driver, see the following topics:

If you do a custom installation of a COM port, you must comply with the COM port requirements that are defined in Configuration of COM Ports.

By Mohan Lal Jangir

Introduction

This article has been written for kernel newcomers interested inlearning about network device drivers. It assumes that reader has asignificant exposure to C and the Linux environment.

This article is based on a network driver for the RealTek 8139 networkcard. I chose the RealTek chip for two reasons: First, RealTek providestechnical specifications for its chips free of cost. (Thanks, RealTek!)Second; it's quite cheap. It is possible to get the chip under Rs 300(approximately US$7) in Indian markets.

The driver presented in this article is minimal; it simply sends and receives packets and maintains some statistics. For a full-fledged and professional-grade driver, please refer to the Linux source.

Preparing for Driver Development

Before starting driver development, we need to set up our system for it.This article was written and tested on Linux 2.4.18, which contains thesource code for the RealTek8139 chip driver. It's very likely that thekernel you are running has the driver compiled either within the kernelitself or as a module. It's advisable to build a kernel which doesnot have the RealTek8139 driver in any form, to avert unnecessarysurprises. If you don't know how to recompile the Linux kernel, Irecommend you take a look at http://www.linuxheadquarters.com/howto/tuning/kernelreasons.shtml.

From this point of discussion onwards, it is assumed that you have a workingkernel, which does not have driver for RealTek8139. You'll also need thetechnical specifications for the chip, which you can download from http://www.realtek.com.tw/. The lastactivity in this series is to properly insert the NIC into the PCI slot, andwe are ready to go ahead.

It is strongly recommended to have Rubini's Linux Device Drivers bookwith you for quick API reference. This is the best resource known to me forLinux device driver development, as of now.

Starting Driver Development

Driver development breaks down into the following steps:

1. Detecting the device
2. Enabling the device
3. Understanding the network device
4. Bus-independent device access
5. Understanding the PCI configuration space
6. Initializing net_device
7. Understanding RealTek8139's transmission mechanism
8. Understanding RealTek8139's receiving mechanism
9. Making the device ready to transmit packets
10. Making the device ready to receive packets

Detecting the Device

As a first step, we need to detect the device of our interest. The Linux kernel provides a rich set of APIs to detect a device over the PCI bus (Plug & Play), but we will go for the simplest one and the API is pci_get_device.

Table 1: Detecting the device

Each vendor has a unique ID assigned, and each vendor assigns a unique ID to a particular kind of device. The macros REALTEK_VENDOR_ID and REALTEK_DEVICE_ID indicate those IDs. You can find these values from the 'PCI Configuration Space Table' in the RealTek8139 specifications. The following is thestruct pci_dev declaration.

Enabling the Device

After detecting the device, we need to enable the device before starting any kind of interaction or communication with the device. The code snippet shown in Table 1 can be extended for device detection and enabling the device.

Table 2: Detecting and Enabling the Device

In Table 2, the function probe_for_realtek8139 performs the following tasks:

• Detects the RealTek 8139 device as explained in Table 1
• Enables the device (by calling pci_enable_device), if found

For time being, we temporarily suspend the thread of driver code study;instead, we look into some important topics in order to understand theLinux view of a network device. We will look at network devices, and thedifference between memory-mapped I/O, port-mapped I/O, and PCIconfiguration space.

Understanding Network Devices

We have detected the PCI device and enabled it, but the networking stackin Linux sees interfaces as network devices. This is represented by thestructure net_device. This means that the networking stack issuescommands to the network device (represented by net_device), and thedriver shall transfer those commands to the PCI device. Table 3 listssome important fields of the structure net_device, which will be usedlater in this article.

Table 3: Structure net_device

Although this structure has many more members, for our minimal driver,these members are good enough. The following section describes the structuremembers:

• name - The name of the device. If the first character of the name is null, then register_netdev assigns it the name 'ethn', where n is suitable numeric. For example, if your system already has eth0 and eth1, your device will be named eth2.
• base_addr - The I/O base address. We will discuss more about I/O addresses later in this article.
• addr_len - Hardware address (MAC address) length. It is 6 for Ethernet interfaces.
• dev_addr - Hardware address (Ethernet address or MAC address)
• broadcast - device broadcast address. It is FF:FF:FF:FF:FF:FF for Ethernet interfaces
• hard_header_len - The 'hardware header length' is the number of octets that lead the transmitted packet before IP header, or other protocol information. The value of hard_header_len is 14 for Ethernet interfaces.
• irq - The assigned interrupt number.
• netdev_ops - holds main management functions
  • open - This is a pointer to a function that opens the device. This function is called whenever ifconfig activates the device (for example, 'ifconfig eth0 up'). The open method should register any system resources it needs (I/O ports, IRQ, DMA, etc.), turn on the hardware and increment module usage count.
  • stop - This is a pointer to a function that stops the interface. This function is called whenever ifconfig deactivates the device (for example, 'ifconfig eth0 down'). The stop method releases all the resources acquired by open function.
  • hard_start_xmit - This function transfers a given packet on the wire. The first argument of the function is a pointer to structure sk_buff. Structure sk_buff is used to hold packets in Linux networking stacks. Although this article does not require detailed knowledge about sk_buff's structure, its details can be found at http://www.tldp.org/LDP/khg/HyperNews/get/net/net-intro.html.
  • get_stats - This function provides interfaces statistics. The output of the command 'ifconfig eth0' has most of the fields from get_stats.

Although we have not mentioned all members of the net_device structure,please note especially that there is no member function for receiving packets.This is done by the device interrupt handler, as we will see later in thisarticle.

Bus-Independent Device Access

Note: This section has been taken from Alan Cox's book Bus-Independent Device Accesses available at http://tali.admingilde.org/linux-docbook/deviceiobook.pdf

Linux provides an API set that abstracts performing I/O operations across all buses and devices, allowing device drivers to be written independent of bus type.

Memory-Mapped I/O

The most widely supported form of I/O is memory-mapped I/O. That is, a part of the CPU's address space is interpreted not as accesses to memory, but as accesses to a device. Some architectures define devices to be at a fixed address, but most have some method of discovering devices. The PCI bus walk is a good example of such a scheme. This document does not cover how to receive such an address, but assumes you are starting with one.

Physical addresses are of type unsigned long. These addresses should not be used directly. Instead, to get an address suitable for passing to the functions described below, you should call ioremap. An address suitable for accessing the device will be returned to you.

After you've finished using the device (say, in your module's exit routine), call iounmap in order to return the address space to the kernel. Most architectures allocate new address space each time you call ioremap, and they can run out unless you call iounmap.

Accessing the device

The part of the interface most used by drivers is reading and writingmemory-mapped registers on the device. Linux provides interfaces to readand write 8-bit, 16-bit, 32-bit and 64-bit quantities. Due to ahistorical accident, these are named byte, word, long, and quadaccesses. Both read and write accesses are supported; there is noprefetch support at this time. The functions are named readb, readw,readl, readq, writeb, writew, writel, and writeq.

Some devices (such as framebuffers) would like to use larger transfers that are more than 8 bytes at a time. For these devices, the memcpy_toio, memcpy_fromio and memset_io functions are provided. Do not use memset or memcpy on I/O addresses; they are not guaranteed to copy data in order.

The read and write functions are defined to be ordered. That is, the compiler the the the is not permitted to reorder the I/O sequence. When the ordering can be compiler optimized, you can use __readb and friends to indicate the relaxed ordering. Use this with care. The rmb provides a read memory barrier. The wmb provides a write memory barrier.

While the basic functions are defined to be synchronous with respect to each other and ordered with respect to each other the buses the devices sit on may themselves have asynchronocity. In particular many authors are not comfortable by the fact that PCI bus writes are posted asynchronously. An author of the driver must issue a read from the same device to ensure that writes have occurred in the manner the author wanted it. This kind of property cannot be hidden from driver writers in the API.

Port Space Access

Another form of I/O commonly supported is Port Space. This is a range of addresses different from the normal memory address space. Access to these addresses is generally not as fast as accesses to the memory mapped addresses, and it also has a potentially smaller address space.

Unlike with memory mapped I/O, no preparation is required to access port space.

Accessing Port Space or I/O mapped devices

Accesses to this space are provided through a set of functions which allow 8-bit, 16-bit and 32-bit accesses; also known as byte, word and long. These functions are inb, inw, inl, outb, outw and outl.

Some variants are provided for these functions. Some devices requirethat accesses to their ports are slowed down. This functionality isprovided by appending a _p to the end of the function. There are alsoequivalents to memcpy. The ins and outs functions copy bytes, words orlongs to/from the given port.

Understanding PCI Configuration Space

Linux Developer Community Port Devices Driver Download For Windows 10

In this section, we will look at PCI configuration space. PCI devicesfeature a 256-byte address space. The first 64 bytes are standardizedwhile the rest of the bytes are device dependent. Figure 1 shows thestandard PCI configuration space.

Figure 1: PCI Configuration Space

The fields 'Vendor ID' and 'Device ID' are unique identifiers assignedto the vendor and the device, respectively. (We have seen them in thesection 'Device Detection'.) Another field to note is 'Base AddressRegisters', popularly known as BAR. We will see how BARs are usedshortly.

Initializing net_device

Now it's time to revert back to driver development. Before that I remind you about the priv field of the structure net_device. We will declare astructure which holds data private to our device and that structureshall be pointed to by member priv. The structure has the followingmembers (We will update structure members as we progress).

Table 4: rtl8139_private structure

Now we define a net_device pointer and initialize it, in the rest of the init_module function.

Table 5: net_device initialization

It's time to explain what we have done in Table 5. Function probe_for_realtek8139, we have already seen. Function rtl8139_init allocates memory for global pointer rtl8139_dev, which we shall be using as net_device. Additionally, this function sets the member pci_dev of rtl8139_private to the detected device.

Our next objective is to get the base_addr field of the net_device. This isthe starting memory location of device registers. This driver has beenwritten for memory-mapped I/O only. To get the memory-mapped I/O baseaddress, we use PCI APIs like pci_resource_start, pci_resource_end,pci_resource_len, pci_resource_flags etc. These APIs let us read the PCIconfiguration space without knowing internal details. The secondargument to these APIs is the BAR number. If you see, RealTek8139specifications, you will find that the first BAR (numbered as 0) isI/OAR, while second BAR (numbered as 1) is MEMAR. Since this driver isusing memory-mapped I/O, we pass the second argument as 1. Beforeaccessing the addresses returned by the above APIs, we have to do twothings. First is to reserve the above resources (memory space) bydriver; this is done by calling the function pci_request_regions. Thesecond thing is to remap I/O addresses as explained in section above onMemory-Mapped I/O. The remapped io_addr is assigned to the base_addrmember of the net_device, and this is the point where we can start toread/write the device registers.

The rest of the code in Table 5 does straightforward initialization ofnet_device. Note that now we are reading the hardware address from thedevice and assigning it to dev_addr. If you see 'Register Descriptions'in RealTek8139 specification, the first 6 bytes are the hardware address ofthe device. Also we have initialized function pointer members buthaven't defined any corresponding function. For time being, we definedummy functions to compile the module.

Table 6: Dummy functions

Note that the error-handling part has been skipped in init_module. Youcan write it by looking into the cleanup_module function defined below:

Table 7: Function cleanup_module

Now we have a dummy or template driver ready. Compile the module andinsert it as explained in Table 8 (assuming the kernel source is in/usr/src/linux-2.4.18 ).

Table 8: Compiling the driver

Now execute a series of commands; 'ifconfig', 'ifconfig - a', 'ifconfig rtl8139 up', 'ifconfig' and 'ifconfig rtl8139 down', and observe their output. These callsshow you when each function is called. If everything goes fine, youshould see device rtl8139 when you issue 'ifconfig - a' and should getmessage 'function rtl8139_get_stat' called. You should get message'function rtl8139_open called' when you issue command 'ifconfig rtl8139up'. Similarly you should get 'function rtl8139_stop called' when youissue command 'ifconfig rtl8139 down'.

Now again, we stop driver development in order to better understand the devicetransmission and receiving mechanism.

Understanding the RealTek 8139 Transmission Mechanism

In this section, I describe RealTek8139 transmission mechanism; howeverI recommend to download 'RTL8139 (A/B) Programming Guide', whichprovides exact details. RealTek8139 has 4 Transmission Descriptors; eachdescriptor has a fixed I/O address offset. The 4 descriptors are used round-robin. This means that for transmitting four packets, the driver willuse descriptor 0, descriptor 1, descriptor 2 and descriptor 3 in round-robin order. For transmitting next packet, driver will use descriptor 0again (provided that is available). If you read the RealTek8139specification, the section 'Register Description' has TSAD0, TSAD1,TSAD2 and TSAD3 registers at offset 0x20, 0x24, 0x28, 0x2C, respectively.These registers store 'Transmit Start Address of Descriptors' i.e., theystore starting address (in memory) of packets to be transmitted. Laterdevice reads packet contents from these addresses, DMA to its own FIFO,and transmits on wire.

We will shortly see that this driver allocates DMAable memory for packet contents, and stores the address of that memory in TSAD registers.

Understanding the RealTek 8139 Receiving Mechanism

The receive path of RTL8139 is designed as a ring buffer (A linermemory, managed as ring memory). Whenever the device receives a packet,packet contents are stored in ring buffer memory, and the location of the nextpacket to store is updated (to first packet starting address + firstpacket length). The device keeps on storing packets in this fashion untillinear memory is exhausted. In that case, the device starts again writing atthe starting address of linear memory, thus making it a ring buffer.

Making Device Ready to Transmit Packets

In this section, we discuss driver source used to make the device ready fortransmission. We defer discussion of the receiving source to furthersections. We will discuss functions rtl8139_open and rtl8139_stop, inthis section. Before that, we enhance our rtl8139_private structure, toaccommodate members to hold data related to packet transmission.

Table 9: rtl8139_private structure

Member tx_flag shall contain transmission flags to notify the deviceabout some parameters described shortly. Field cur_tx shall hold currenttransmission descriptor, while dirty_tx denotes the first oftransmission descriptors, which have not completed transmission. (Thisalso means that, we can't use dirty descriptor for further packettransmission until previous packet is transmitted completely.) Arraytx_buf holds addresses of 4 'transmission descriptors'. Field tx_bufs isalso used in same context, as we will see shortly. Both tx_buf andtx_bufs do hold kernel virtual address, which can be used by the driver, butthe device cannot use these addresses. The device need to access physicaladdresses, which are stored in field tx_bufs_dma. Here is a list ofregister offsets, used in code. You can get more details about thesevalues from the RealTek8139 specifications.

Table 10: RTL 8139 Register Definitions

With above definition, we look into function rtl8139_open:

Table 11: Writing the open function

Now, we explain the code in Table 11. The function rtl8139_open starts with requesting the IRQ by calling API request_irq. In this function, weregister the interrupt handler rtl8139_interrupt. This function shall becalled by kernel, whenever the device generates an interrupt. Now, weallocate memory, where outgoing packets reside before being sent onwire. Note that API pci_allocate_consistant returns kernel virtualaddress. The physical address is returned in third argument, which islater used by driver. Also observe that we have allocated memory neededfor all four descriptors. Function rtl8139_init_ring distributes thismemory to four descriptors. Here, we call function rtl8139_hw_start tomake the device ready for transmitting packets. At first, we reset thedevice, so that device shall be in a predictable and known state. Thisis done by writing reset value (described in specification) in CR(Command Register). We wait until the written value is read back, whichmeans device has reset. The next function, barrier ( ), is called to force thekernel to do required memory I/O immediately without doing anyoptimization. Once the device is reset, we enable transmission mode ofthe device by writing transmission enable value in CR. Next, we configure TCR(Transmission Configuration Register). The only thing we are specifying toTCR register is 'Max DMA Burst Size per Tx DMA Burst'. The rest we leave atdefault values. (See specification for more details.) Now we write theDMAable address of all four descriptors to TSAD (Transmission StartAddress Descriptor) registers. Next, we enable the interrupt, by writingin IMR (Interrupt Mask Register). This register lets us configure theinterrupts; the device will be generating. Last, we callnetif_start_queue to tell the kernel that device is ready. The onlything remaining is writing the rtl8139_interrupt function. For the time being,let's skip this. At this time, the device is ready to sendpackets, but the function to send packets out is missing. (Rememberhard_start_xmit.) So, let's do it.

Table 12: Writing start_xmit function

The function rtl8139_start_xmit, explained in Table 12, is very trivial.First, it finds the available transmission descriptor and then checks thatthe packet size is at least 60 bytes (as Ethernet packet size can't be lessthan 60 bytes). Once this is ensured, the function skb_copy_and_csum_devis called, which copies the packet contents to the DMA capable memory.In the next writel, we inform the device about the packet length. At thistime, the packet is transmitted on the wire. Next, we determinethe next available transmission descriptors, and, if this happens to be equalto a dirty descriptor, we stop the device; otherwise we simply return.

Our device is now ready to send packets out. (Remember, we can't receive packets, yet.) Compile the driver, and try sending ping packets out ofthe host. At other end, you should see some ARP packets. Even remotehosts reply to ARP packets; they are useless for us, as we are notready to receive packets.

Making Device Ready to Receive Packets

Now, we will make the device ready to receive packets. For this, we will look into some of already discussed functions, and then the interrupt handler. First,we extend the structure rtl8139_private to accommodate variables needed to receive packets.

Ivi foundation driver download for windows 10 pro. Table 13: Extending rtl8139_private structure

The member stats shall keep device statistics (most of the ifconfigstatistics is from this structure). The next member, rx_ring, is the kerneladdress of memory where received packets are stored, while rx_ring_dmais the physical address of the same memory. Member cur_rx is used to keeptrack of next packet writing, as we will see shortly.

Now we re-look into rtl8139_open function, where we allocated memory for transmission side only. Now, we allocate memory for packet receiving also.

Table 14: Extending rtl8139_open function

The code in Table 14 calculates the memory required for ring buffer. Thecalculation of RX_BUF_TOT_LEN depends upon some device configurationparameters. As we see shortly in rtl8139_hw_start, we configure Bits12-11 of RCR register as 10, which configures a 32K+16 receiver bufferlength. Therefore, we allocate that much memory for the receiver buffer.Also, we configure bits 7 to 1, which means RTL8139 will keep moving therest of the packet data into the memory, immediately after the end of Rxbuffer. Therefore, we allocate 2048 bytes of buffer extra to cope upwith such situations.

Now that we've looked into function rtl8139_open, we look intortl8139_hw_start, where we configure the device for receiving packets.

Table 15: Extending rtl8139_hw_start function

As shown in Table 15, the first change in rtl8139_hw_start function isthat we are writing CmdTxEnb | CmdRxEnb to CR register, which means thedevice will be transmitting as well as receiving packets. The next changeis device receive configuration. I have not used macros in code, butthey are quite obvious, if you see the rtl8139 specification. The bitsused in this statement are as follows:

• Bit 1 - Accept physical match packets
• Bit 2 - Accept multicast packets
• Bit 3 - Accept broadcast packets
• Bit 7 - WRAP. When set to 1, RTL8139 will keep moving the rest of packet data into the memory immediately after the end of Rx buffer.
• Bit 8-10 - Max DMA burst size per Rx DMA burst. We are configuring this to 111, which means unlimited.
• Bit 11-12 - Rx buffer length. We are configuring to 10 which means 32K+16 bytes.

The next major change is configuring RBSTART register. This register contains starting address of receive buffer. Later, we initialize MPC (Missed Packet Counter) register to zero and configure the device for not generating early interrupts.

The last major function we want to discuss is the device interrupthandler. This interrupt handler is responsible for receiving packets, aswell as for updating necessary statistics. Here is the source code foran interrupt handler.

Table 16: Interrupt Handler

As shown in Table 16, the ISR register is read in variable isr. Any further demultiplexing of interrupts is the interrupt handler's job. If wereceive TxOK, TxErr, or RxErr, we update necessary statistics. Receivingan RxOK interrupt means we have received a frame successfully, and the driverhas to process it. We read from the receiver buffer until we have read alldata. (loop while ((readb (ioaddr + CR) & RxBufEmpty) 0) does thisjob.) First, we check if tp->cur_rx has gone beyond RX_BUF_LEN. Ifthat is case, we wrap it. The received frame contains 4 extra bytes atthe start of frame (appended by RTL8139), apart from packet contents andother headers. The first two bytes indicate frame status and next twobytes indicate frame length. (The length includes first 4 bytes, also.)These values are always in little-endian order, and must be converted tohost order. Then, we allocate a skb for received packet, copy the framecontents into skb, and queue the skb for later processing. Then, we updateCAPR (Current Address of Packet Read), to let the RTL8139 know about the nextwrite location. Note that we have already registered this interrupthandler in function rtl8139_open. So far, we had a dummy definition;now, we can replace that with this definition.

The last function we want to add is rtl8139_get_stats, which simply returns tp->stats.

Table 17: rtl8139_get_stats function

This ends our driver development. Compile and insert this again (you must unload earlier module using rmmod), and ping to another host. You shouldbe able to receive ping replies.

Linux Developer Community Port Devices Driver Download For Windows 7

Although a professional-grade driver includes many more features than describedin this driver, the latter gives you a good insight into network drivers andwill help you understanding production drivers.

Talkback: Discuss this article with The Answer Gang

Linux Developer Community Port Devices Driver Download For Windows Xp

Mohan Lal Jangir is working as Development Lead at Samsung India Software Operations, Bangalore, INDIA. He has a Masters in Computer Technology from IIT DELHI, and is keen interested in Linux, Networking and Network Security.

Linux Developer Community Port Devices Driver Download For Windows 8

Copyright © 2008, Mohan Lal Jangir. Released under the Open Publication Licenseunless otherwise noted in the body of the article. Linux Gazette is notproduced, sponsored, or endorsed by its prior host, SSC, Inc.

Published in Issue 156 of Linux Gazette, November 2008