I am trying to understand Linux USB Device drivers, most of the documentation speaks about the USB Device decoded into
configuration
interface
Endpoint
Linux only supports one configuration. Are these hardware entities or simply data present in the driver of the data which it passes on USB Device detection
When referring to a USB device, the terms "configuration", "interface", and "endpoint", are all properties of the device. They can be changed if you are able to reprogram the device, but if not then you can just think of them as part of the hardware.
The device has binary chunks of data called "descriptors" which the computer fetches so the computer can know what configurations, interfaces, and endpoints the device has.
You can learn all about those items and their descriptors by reading the USB 2.0 specification:
https://usb.org/document-library/usb-20-specification
Related
I want to use alsa on a Beaglebone Black to send audio through usb audio out and receive it on my computer.
I have seen that there are some gadgets in a legacy folder in the kernel, and seen some tutorials on how to set up mass storage and network gadgets, but I am confused about what the state of audio gadgets is and what to compile and configure for this.
Can you explain the various components and configurations that need to go into place to make this happen, covering which kernel modules, drivers, kinds of scripts, and configurations that might be needed to do this?
You need to enable USB gadget subsystem in your Linux kernel for Beaglebone Black. Assuming of course that you have USB device controller and USB device connector on your Beaglebone. Here there are more information:
https://www.lynxbee.com/usb-audio-gadget-driver/
USB devices contains so called USB descriptors which tells USB host (PC) as a what device type it works. Audio gadget is one of the type of that descriptor that tells that this device (in this case BeagleBone) should be working as a audio device.
I am learning to program a USB device (iBall 3.5g USB Dongle) using libusb.h header library.
Until now I am able to identify my device using the Vendor ID and also open the device for operation.
As a next step I would like to know the available commands (or the controls) for example : command to scan the surroundings for available GSM networks.
Obviously I will have to talk to the devices' firmware to extract the necessary information.
I tried to search for the technical datasheet for the 3g dongle, but couldn't find any.
The dongle is powered by a Qualcomm chip
Do you know any of the methods in which I can get the control commands for a usb device ?
Thanks in advance.
There is no simple procedure for figuring out what commands a USB device has. You need to use a combination of looking at the descriptors reported by the device, seeing if the device supports any particular USB device class, reading the USB specification, and maybe doing some reverse engineering using a protocol analyzer.
A good first step would be for you to use lsusb -v to print human-readable descriptions of the device's USB descriptors.
Wanted to know how a device is detected in Linux? What exactly is the workflow of the device driver in device detection?
It is the Kernel's job to detect devices as it has the lowest level access to the available hardware. When the Kernel scans through all available addresses it maintains a list of Vendor and Device IDs.
To use PCI bus devices as an example, there is a Vendor ID and a Device ID associated with all PCI devices.
Device drivers are written in such a way as to identify to the Kernel what kinds of devices the driver is able to control. Drivers may advertise that they can handle more than one vendor and device type combination.
The Kernel will allocate a driver to each device based on these IDs. A similar process is in place for USB devices. Older technologies like legacy devices (serial ports, parallel, ps2 mice/keyboards) will have explicitly hardcoded methods of associating particular drivers with devices.
You can use the Linux commands lsusb and lspci to see the available devices and IDs on your system.
So in direct answer to your question - the device driver usually does nothing to detect the device, at least in the first instance. Once the driver is associated with a device (by the Kernel) the driver will likely do further interrogation of the device to ensure it contains the right firmware or is the right hardware revision, etc.
I am trying to find out a high-level overview of how the USB storage driver works in Linux. I'm looking for a simple article or even a picture/flowchart describing how it works.
Basically, I'm looking to get these questions answered:
When you plug the device into your computer, what happens? Is there a daemon that picks up on it, or does the event trigger an interrupt somewhere? Does the core USB driver read information about the device before passing control over to the USB storage driver? How does it decide what type of device it is? How does the device get mounted, and what allows it to communicate with the computer's filesystem? When I copy a file, what does the data flow look like in the kernel?
I hope the question isn't too vague - I tried Google to no avail, so I'm wondering if anyone knows any articles or diagrams that can explain this, or perhaps if they can explain it themselves without too much effort. Thanks.
No, it is a very good question.
The block writing is going in linux with the block device layer. The filesystems are working with this block dev layer.
If this layer wants to write something out, says it to the driver of the usb master device. This driver is talking with the usb controller chip of the motherboard.
This chip is very simple: the usb is practically a serial port, with a lot of extensions, mainly targeting the autoconfiguration and the power management. But basically, you can write out bytes, and read in bytes.
Your questions:
When you plug the device into your computer, what happens? Is there a daemon that picks up on it, or does the event trigger an interrupt somewhere?
The device (usb slave) says the master (in the motherboard): "I am here". The usb controller chip gets the message and says it to the kernel (normally) with an interrupt. The kernel reinitializes and rescans the usb bus, and says the udev: "here is a new 1234:5678 usb device on the usb tree 1.3.5"
"How does it decide what type of device it is?"
Usb devices have a vendor and model id, and they can say this on ask. Google for "usb ids".
"How does the device get mounted, and what allows it to communicate with the computer's filesystem?"
The kernel only loads the driver and says the udev (which is in userspace): "Here is a new block device on device number 22:16". From this, udev tries to mount this with some userspace daemon, it is already distribution-dependant.
I'm researching ways to communicate with a USB device in Linux and would prefer to not write a Linux Kernel driver. I understand that libusb exists and is a user-land library that would work, but our embedded device doesn't support usbfs ( and would be really a pain to change kernels to add the support ).
So my question is basically this: Is it possible / advisable to communicate with a USB device by directly reading and writing to the /dev/USB or the udev file corresponding to the USB device thus bypassing the need for a custom Linux Driver and usbfs?
I'm hoping it's possible to communicate using the USB devices protocol just by reading / writing protocol packets directly through file-type read/write commands once the /dev/USB or udev device file is open.
Thoughts and suggestions please.
FOLLOW UP:
Since the USB device I needed to talk to is a USB HID class device, I was able to use libudev and the standard Linux USB HID RAW driver by reading / writing directly to /dev/hidraw0 ( or the appropriate /dev/hidraw device ). It wasn't necessary to write a custom driver for a simple USB HID device.
Jim, I don't think you can escape the need to write a driver and just manage to read the USB file in /dev. Because who defines as to what should happen when you do a read() on the USB device file? And who defines what action should be initiated when you invoke sysioctl()? Your driver! In other words, the device files are themselves incapable of anything until they are supported by the underlying drivers. In fact, you can treat the device files to be an abstraction of the underlying driver! So, no driver, no use of device file :(
I suggest you go through the following articles about how to write a driver and also understand the USB internals-
http://www.linux-usb.org/USB-guide/c15.html
http://www.linuxjournal.com/article/4786 ( Slightly outdated )