Linux usb cdc driver

Linux ACM driver v0.16В¶

Sponsored by SuSE

0. Disclaimer¶

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

For your convenience, the GNU General Public License version 2 is included in the package: See the file COPYING.

1. Usage¶

The drivers/usb/class/cdc-acm.c drivers works with USB modems and USB ISDN terminal adapters that conform to the Universal Serial Bus Communication Device Class Abstract Control Model (USB CDC ACM) specification.

Many modems do, here is a list of those I know of:

3Com OfficeConnect 56k

3Com Voice FaxModem Pro

MultiTech MultiModem 56k

Zoom 2986L FaxModem

Compaq 56k FaxModem

ELSA Microlink 56k

I know of one ISDN TA that does work with the acm driver:

3Com USR ISDN Pro TA

Some cell phones also connect via USB. I know the following phones work:

Unfortunately many modems and most ISDN TAs use proprietary interfaces and thus won’t work with this drivers. Check for ACM compliance before buying.

To use the modems you need these modules loaded:

After that, the modem[s] should be accessible. You should be able to use minicom, ppp and mgetty with them.

2. Verifying that it works¶

The first step would be to check /sys/kernel/debug/usb/devices, it should look like this:

The presence of these three lines (and the Cls= ‘comm’ and ‘data’ classes) is important, it means it’s an ACM device. The Driver=acm means the acm driver is used for the device. If you see only Cls=ff(vend.) then you’re out of luck, you have a device with vendor specific-interface:

In the system log you should see:

If all this seems to be OK, fire up minicom and set it to talk to the ttyACM device and try typing ‘at’. If it responds with ‘OK’, then everything is working.

© Copyright The kernel development community.

Источник

Linux Gadget Serial Driver v2.0В¶

(updated 8-May-2008 for v2.3)

License and Disclaimer¶

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.

This document and the gadget serial driver itself are Copyright (C) 2004 by Al Borchers (alborchers @ steinerpoint . com).

If you have questions, problems, or suggestions for this driver please contact Al Borchers at alborchers @ steinerpoint . com.

Prerequisites¶

Versions of the gadget serial driver are available for the 2.4 Linux kernels, but this document assumes you are using version 2.3 or later of the gadget serial driver in a 2.6 Linux kernel.

This document assumes that you are familiar with Linux and Windows and know how to configure and build Linux kernels, run standard utilities, use minicom and HyperTerminal, and work with USB and serial devices. It also assumes you configure the Linux gadget and usb drivers as modules.

With version 2.3 of the driver, major and minor device nodes are no longer statically defined. Your Linux based system should mount sysfs in /sys, and use “mdev” (in Busybox) or “udev” to make the /dev nodes matching the sysfs /sys/class/tty files.

Overview¶

The gadget serial driver is a Linux USB gadget driver, a USB device side driver. It runs on a Linux system that has USB device side hardware; for example, a PDA, an embedded Linux system, or a PC with a USB development card.

The gadget serial driver talks over USB to either a CDC ACM driver or a generic USB serial driver running on a host PC:

On the device-side Linux system, the gadget serial driver looks like a serial device.

On the host-side system, the gadget serial device looks like a CDC ACM compliant class device or a simple vendor specific device with bulk in and bulk out endpoints, and it is treated similarly to other serial devices.

The host side driver can potentially be any ACM compliant driver or any driver that can talk to a device with a simple bulk in/out interface. Gadget serial has been tested with the Linux ACM driver, the Windows usbser.sys ACM driver, and the Linux USB generic serial driver.

With the gadget serial driver and the host side ACM or generic serial driver running, you should be able to communicate between the host and the gadget side systems as if they were connected by a serial cable.

The gadget serial driver only provides simple unreliable data communication. It does not yet handle flow control or many other features of normal serial devices.

Installing the Gadget Serial Driver¶

To use the gadget serial driver you must configure the Linux gadget side kernel for “Support for USB Gadgets”, for a “USB Peripheral Controller” (for example, net2280), and for the “Serial Gadget” driver. All this are listed under “USB Gadget Support” when configuring the kernel. Then rebuild and install the kernel or modules.

Then you must load the gadget serial driver. To load it as an ACM device (recommended for interoperability), do this:

To load it as a vendor specific bulk in/out device, do this:

This will also automatically load the underlying gadget peripheral controller driver. This must be done each time you reboot the gadget side Linux system. You can add this to the start up scripts, if desired.

Your system should use mdev (from busybox) or udev to make the device nodes. After this gadget driver has been set up you should then see a /dev/ttyGS0 node:

Note that the major number (253, above) is system-specific. If you need to create /dev nodes by hand, the right numbers to use will be in the /sys/class/tty/ttyGS0/dev file.

When you link this gadget driver early, perhaps even statically, you may want to set up an /etc/inittab entry to run “getty” on it. The /dev/ttyGS0 line should work like most any other serial port.

If gadget serial is loaded as an ACM device you will want to use either the Windows or Linux ACM driver on the host side. If gadget serial is loaded as a bulk in/out device, you will want to use the Linux generic serial driver on the host side. Follow the appropriate instructions below to install the host side driver.

Installing the Windows Host ACM Driver¶

To use the Windows ACM driver you must have the “linux-cdc-acm.inf” file (provided along this document) which supports all recent versions of Windows.

When the gadget serial driver is loaded and the USB device connected to the Windows host with a USB cable, Windows should recognize the gadget serial device and ask for a driver. Tell Windows to find the driver in the folder that contains the “linux-cdc-acm.inf” file.

For example, on Windows XP, when the gadget serial device is first plugged in, the “Found New Hardware Wizard” starts up. Select “Install from a list or specific location (Advanced)”, then on the next screen select “Include this location in the search” and enter the path or browse to the folder containing the “linux-cdc-acm.inf” file. Windows will complain that the Gadget Serial driver has not passed Windows Logo testing, but select “Continue anyway” and finish the driver installation.

On Windows XP, in the “Device Manager” (under “Control Panel”, “System”, “Hardware”) expand the “Ports (COM & LPT)” entry and you should see “Gadget Serial” listed as the driver for one of the COM ports.

To uninstall the Windows XP driver for “Gadget Serial”, right click on the “Gadget Serial” entry in the “Device Manager” and select “Uninstall”.

Installing the Linux Host ACM Driver¶

To use the Linux ACM driver you must configure the Linux host side kernel for “Support for Host-side USB” and for “USB Modem (CDC ACM) support”.

Once the gadget serial driver is loaded and the USB device connected to the Linux host with a USB cable, the host system should recognize the gadget serial device. For example, the command:

should show something like this::

If the host side Linux system is configured properly, the ACM driver should be loaded automatically. The command “lsmod” should show the “acm” module is loaded.

Installing the Linux Host Generic USB Serial Driver¶

To use the Linux generic USB serial driver you must configure the Linux host side kernel for “Support for Host-side USB”, for “USB Serial Converter support”, and for the “USB Generic Serial Driver”.

Once the gadget serial driver is loaded and the USB device connected to the Linux host with a USB cable, the host system should recognize the gadget serial device. For example, the command:

should show something like this::

You must load the usbserial driver and explicitly set its parameters to configure it to recognize the gadget serial device, like this:

The legacy way is to use module parameters:

If everything is working, usbserial will print a message in the system log saying something like “Gadget Serial converter now attached to ttyUSB0”.

Testing with Minicom or HyperTerminal¶

Once the gadget serial driver and the host driver are both installed, and a USB cable connects the gadget device to the host, you should be able to communicate over USB between the gadget and host systems. You can use minicom or HyperTerminal to try this out.

On the gadget side run “minicom -s” to configure a new minicom session. Under “Serial port setup” set “/dev/ttygserial” as the “Serial Device”. Set baud rate, data bits, parity, and stop bits, to 9600, 8, none, and 1–these settings mostly do not matter. Under “Modem and dialing” erase all the modem and dialing strings.

On a Linux host running the ACM driver, configure minicom similarly but use “/dev/ttyACM0” as the “Serial Device”. (If you have other ACM devices connected, change the device name appropriately.)

On a Linux host running the USB generic serial driver, configure minicom similarly, but use “/dev/ttyUSB0” as the “Serial Device”. (If you have other USB serial devices connected, change the device name appropriately.)

On a Windows host configure a new HyperTerminal session to use the COM port assigned to Gadget Serial. The “Port Settings” will be set automatically when HyperTerminal connects to the gadget serial device, so you can leave them set to the default values–these settings mostly do not matter.

With minicom configured and running on the gadget side and with minicom or HyperTerminal configured and running on the host side, you should be able to send data back and forth between the gadget side and host side systems. Anything you type on the terminal window on the gadget side should appear in the terminal window on the host side and vice versa.

© Copyright The kernel development community.

Источник

cdc_mbim — Driver for CDC MBIM Mobile Broadband modemsВ¶

The cdc_mbim driver supports USB devices conforming to the “Universal Serial Bus Communications Class Subclass Specification for Mobile Broadband Interface Model” [1], which is a further development of “Universal Serial Bus Communications Class Subclass Specifications for Network Control Model Devices” [2] optimized for Mobile Broadband devices, aka “3G/LTE modems”.

Command Line Parameters¶

The cdc_mbim driver has no parameters of its own. But the probing behaviour for NCM 1.0 backwards compatible MBIM functions (an “NCM/MBIM function” as defined in section 3.2 of [1]) is affected by a cdc_ncm driver parameter:

prefer_mbim¶

Y (MBIM is preferred)

This parameter sets the system policy for NCM/MBIM functions. Such functions will be handled by either the cdc_ncm driver or the cdc_mbim driver depending on the prefer_mbim setting. Setting prefer_mbim=N makes the cdc_mbim driver ignore these functions and lets the cdc_ncm driver handle them instead.

The parameter is writable, and can be changed at any time. A manual unbind/bind is required to make the change effective for NCM/MBIM functions bound to the “wrong” driver

Basic usage¶

MBIM functions are inactive when unmanaged. The cdc_mbim driver only provides a userspace interface to the MBIM control channel, and will not participate in the management of the function. This implies that a userspace MBIM management application always is required to enable a MBIM function.

Such userspace applications includes, but are not limited to:

mbimcli (included with the libmbim [3] library), and

Establishing a MBIM IP session reequires at least these actions by the management application:

open the control channel

configure network connection settings

connect to network

configure IP interface

Management application development¶

The driver userspace interfaces are described below. The MBIM control channel protocol is described in [1].

MBIM control channel userspace ABI¶

/dev/cdc-wdmX character device¶

The driver creates a two-way pipe to the MBIM function control channel using the cdc-wdm driver as a subdriver. The userspace end of the control channel pipe is a /dev/cdc-wdmX character device.

The cdc_mbim driver does not process or police messages on the control channel. The channel is fully delegated to the userspace management application. It is therefore up to this application to ensure that it complies with all the control channel requirements in [1].

The cdc-wdmX device is created as a child of the MBIM control interface USB device. The character device associated with a specific MBIM function can be looked up using sysfs. For example:

USB configuration descriptors¶

The wMaxControlMessage field of the CDC MBIM functional descriptor limits the maximum control message size. The managament application is responsible for negotiating a control message size complying with the requirements in section 9.3.1 of [1], taking this descriptor field into consideration.

The userspace application can access the CDC MBIM functional descriptor of a MBIM function using either of the two USB configuration descriptor kernel interfaces described in [6] or [7].

See also the ioctl documentation below.

Fragmentation¶

The userspace application is responsible for all control message fragmentation and defragmentaion, as described in section 9.5 of [1].

/dev/cdc-wdmX write()В¶

The MBIM control messages from the management application must not exceed the negotiated control message size.

/dev/cdc-wdmX read()В¶

The management application must accept control messages of up the negotiated control message size.

/dev/cdc-wdmX ioctl()В¶

IOCTL_WDM_MAX_COMMAND: Get Maximum Command Size This ioctl returns the wMaxControlMessage field of the CDC MBIM functional descriptor for MBIM devices. This is intended as a convenience, eliminating the need to parse the USB descriptors from userspace.

Custom device services¶

The MBIM specification allows vendors to freely define additional services. This is fully supported by the cdc_mbim driver.

Support for new MBIM services, including vendor specified services, is implemented entirely in userspace, like the rest of the MBIM control protocol

New services should be registered in the MBIM Registry [5].

MBIM data channel userspace ABI¶

wwanY network device¶

The cdc_mbim driver represents the MBIM data channel as a single network device of the “wwan” type. This network device is initially mapped to MBIM IP session 0.

Multiplexed IP sessions (IPS)В¶

MBIM allows multiplexing up to 256 IP sessions over a single USB data channel. The cdc_mbim driver models such IP sessions as 802.1q VLAN subdevices of the master wwanY device, mapping MBIM IP session Z to VLAN ID Z for all values of Z greater than 0.

The device maximum Z is given in the MBIM_DEVICE_CAPS_INFO structure described in section 10.5.1 of [1].

The userspace management application is responsible for adding new VLAN links prior to establishing MBIM IP sessions where the SessionId is greater than 0. These links can be added by using the normal VLAN kernel interfaces, either ioctl or netlink.

For example, adding a link for a MBIM IP session with SessionId 3:

The driver will automatically map the “wwan0.3” network device to MBIM IP session 3.

Device Service Streams (DSS)В¶

MBIM also allows up to 256 non-IP data streams to be multiplexed over the same shared USB data channel. The cdc_mbim driver models these sessions as another set of 802.1q VLAN subdevices of the master wwanY device, mapping MBIM DSS session A to VLAN ID (256 + A) for all values of A.

The device maximum A is given in the MBIM_DEVICE_SERVICES_INFO structure described in section 10.5.29 of [1].

The DSS VLAN subdevices are used as a practical interface between the shared MBIM data channel and a MBIM DSS aware userspace application. It is not intended to be presented as-is to an end user. The assumption is that a userspace application initiating a DSS session also takes care of the necessary framing of the DSS data, presenting the stream to the end user in an appropriate way for the stream type.

The network device ABI requires a dummy ethernet header for every DSS data frame being transported. The contents of this header is arbitrary, with the following exceptions:

TX frames using an IP protocol (0x0800 or 0x86dd) will be dropped

RX frames will have the protocol field set to ETH_P_802_3 (but will not be properly formatted 802.3 frames)

RX frames will have the destination address set to the hardware address of the master device

The DSS supporting userspace management application is responsible for adding the dummy ethernet header on TX and stripping it on RX.

This is a simple example using tools commonly available, exporting DssSessionId 5 as a pty character device pointed to by a /dev/nmea symlink:

This is only an example, most suitable for testing out a DSS service. Userspace applications supporting specific MBIM DSS services are expected to use the tools and programming interfaces required by that service.

Note that adding VLAN links for DSS sessions is entirely optional. A management application may instead choose to bind a packet socket directly to the master network device, using the received VLAN tags to map frames to the correct DSS session and adding 18 byte VLAN ethernet headers with the appropriate tag on TX. In this case using a socket filter is recommended, matching only the DSS VLAN subset. This avoid unnecessary copying of unrelated IP session data to userspace. For example:

Tagged IP session 0 VLAN¶

As described above, MBIM IP session 0 is treated as special by the driver. It is initially mapped to untagged frames on the wwanY network device.

This mapping implies a few restrictions on multiplexed IPS and DSS sessions, which may not always be practical:

no IPS or DSS session can use a frame size greater than the MTU on IP session 0

no IPS or DSS session can be in the up state unless the network device representing IP session 0 also is up

These problems can be avoided by optionally making the driver map IP session 0 to a VLAN subdevice, similar to all other IP sessions. This behaviour is triggered by adding a VLAN link for the magic VLAN ID 4094. The driver will then immediately start mapping MBIM IP session 0 to this VLAN, and will drop untagged frames on the master wwanY device.

Tip: It might be less confusing to the end user to name this VLAN subdevice after the MBIM SessionID instead of the VLAN ID. For example:

VLAN mapping¶

Summarizing the cdc_mbim driver mapping described above, we have this relationship between VLAN tags on the wwanY network device and MBIM sessions on the shared USB data channel:

References¶

USB Implementers Forum, Inc. — “Universal Serial Bus Communications Class Subclass Specification for Mobile Broadband Interface Model”, Revision 1.0 (Errata 1), May 1, 2013

USB Implementers Forum, Inc. — “Universal Serial Bus Communications Class Subclass Specifications for Network Control Model Devices”, Revision 1.0 (Errata 1), November 24, 2010

libmbim — “a glib-based library for talking to WWAN modems and devices which speak the Mobile Interface Broadband Model (MBIM) protocol”

ModemManager — “a DBus-activated daemon which controls mobile broadband (2G/3G/4G) devices and connections”

“MBIM (Mobile Broadband Interface Model) Registry”

“/sys/kernel/debug/usb/devices output format”

Источник