tl;dr: How do I compel Linux to reject high-speed USB connections so that it defaults to full speed?
Full explanation:
I'm writing a USB gadget driver based on Linux gadget zero. The hardware I'm testing on has high speed capable USB which won't be the case of the actual product. For some reason, the gadget (although it has no high speed descriptors on any configuration) is being reported as a high speed gadget
(struct usb_gadget->speed==USB_SPEED_HIGH on set_config function of composite gadget).
This makes the driver fail miserably just before configuration bind (trying to load a high speed configuration that obviously doesn’t exist).
I'm looking for a way to inform Linux that the gadget is not high speed capable so that when a host connects the switch from fullspeed to highspeed is denied (or something that would produce a similar results).
uhci and ohci kernel modules drive USB 1.X controllers.
ehci modules drives USB 2.0 controller.
If you unload one of these, you enforce a restriction to the other.
enum usb_device_speed speed;
enum usb_device_speed max_speed;
you can setup usb_composite_driver
Related
I am studying Operating Systems, and came across divice controllers.
I gathered that a device controller is hardware whereas a device driver is software.
I also know that a HDD and a SSD both have a small PCB buit into them and I assume those PCB's are the device controllers.
Now what I want to know is if there is another device controller on the PC/motherboard side of the bus/cable connecting the HDD/SSD to the OS?
Is the configuration: OS >> Device Driver >> Bus >> Device Controller >> HDD/SSD
Or is it: OS >> Device Driver >> Device Controler >> Bus >> Device Controller >> HDD/SSD
Or is it some other configuration?
Sites I visited for answers:
Tutorialspoint
JavaPoint
Idc online
Quora
Most hard-disks on desktop are SATA or NVME. eMMC is popular for smartphones but some might use something else. These are hardware interface standards that describe the way to interact electrically with those disks. It tells you what voltage at what frequency and for what amount of time you need to apply (a signal) to a certain pin (a bus line) to make the device behave or react in a certain way.
Most computers are separated in a few external chips. On desktop, it is mostly SATA, NVME, DRAM, USB, Audio Output, network card and graphics card. Even though there is few chips, the CPU would be very expensive if it had to support all those hardware interface standards on the same silicon chip. Instead, the CPU implements PCI/PCI-e as a general interface to interact with all those chips using memory mapped registers. Each of these devices have an external PCI-e controller between the device and the CPU. In the same order as above, you have AHCI, NVME controller, DRAM (not PCI and in the CPU), xHCI (almost everywhere) and Intel HDA (example). Network cards are PCI-e and there isn't really a controller outside the card. Graphics card are also self standing PCI-e devices.
So, the OS detects the registers of those devices that are mapped in the address space. The OS writes at those locations, and it will write the registers of the devices. PCI-e devices can read/write DRAM directly but this is managed by the CPU in its general implementation of the PCI-e standard most likely by doing some bus arbitration. The CPU really doesn't care what's the device that it is writing. It knows that there is a PCI register there and the OS instructs to write it with something so it does. It just happens that this device is an implementation of a standard and that the OS developers read the standard so they write the proper values in those registers and the proper data structures in DRAM to make sure that the device knows what to do.
Drivers implement the standard of the software interface of those controllers. The drivers are the ones instructing the CPU on values to write and writing the proper data structures in DRAM for giving commands to the controllers. The user thread simply places the syscall number in a conventionnal register determined by the OS developers and they call an instruction to jump into the kernel at a specific address that the kernel decides by writing a register at boot. Once there, the kernel looks at the register for the number and determines what driver to call based on the operation.
On Linux and some place else, it is done with files. You call syscalls on files and the OS has a driver attached to the file. They are called virtual files. A lot of transfer mechanisms are similar to the reading/writing files pattern so Linux uses that to make a general driver model where the kernel doesn't even need to understand the driver. The driver just says create me a file there that's not really on the hard disk and if someone opens it and calls an operation on it then call this function that's there in my driver. From there, the driver can do whatever it wants because it is in kernel mode. It just creates the proper data structures in DRAM and writes the registers of the device it drives to make it do something.
I want to learn how Linux OS understands the underlying hardware.Can anyone suggest me where to start for getting this understanding,As of now i just know the '/dev' sub-directory plays a vital role in that.
It has the device special files which are like a portal to the device driver which then takes it to the physical device.
I read somewhere that Udev daemon listens to the netlink socket to collect this information and Udev device manager detects addition and removal of devices as they occur.
But with these i am just not satisfied with the thought of how Linux reads the hardware.
Please let me know where to start to understand this, i am so thankful to anyone trying to help.
I think at first you need to find out how the memory mapping works. What is the address space and how it relates to physical memory. Then you could read about how the hardware is mapped in address space and how to access it. It is a big amount of docs to read.
Some of those information are in Linux Documentation Project.
Additionally some knowledge about electronic would be helpful.
In general - Linux for communication with devices needs some "channel" of communication. This channel may be for example ISA, PCI, USB, etc bus. For example PCI devices are memory mapped devices and Linux kernel communicates with them via memory accesses. So first Linux needs to see given device in some memory area and then it is able to configure this device and do some communication with it.
In case of USB devices it is a little bit complicated because USB devices are not memory mapped. You need to configure USB host first to be able to communicate with USB devices. Every communication with USB device is achieved via USB host.
There are also devices which are not connected via ISA, PCI or USB. They are connected directly to the processor and visible under some memory address. This solution is usually implemented in embedded devices. For example ARM processors use this approach.
Regarding udev - it is user-space application which listens for events from Linux kernel and helps other applications with recognizing device addition and configuration.
I have two USB devices (host and device) that both support high speed. I am trying to emulate a legacy device on gadgetfs which is full speed. The host device unfortunately complains that there is something odd when it connects to the high speed device. I cannot change anything on the host. my device is a Raspberry Pi zero W.
I can not find any way to restrict the gadgetfs device to connect (negotiate?) as a full speed device. Short term I am using a usb 1.1 hub to sovle the problem. Long term this is not a viable solution.
The only reference I have found for this is in Limit USB gadget driver speed, and I would prefer not to have go into the kernel and modify the drivers.
Does anyone have any suggestion on how I could achieve this?
People,
I have always seen references about how to use a SPI interface to operate a SD memory card.
This is not what I want. I need to do exactly the opposite.
I want to be able to use the SDIO controller (through SD slot) in my "host" (any PC having a SD-card interface) to talk to my devices (basically microcontrollers) that can only "speak" SPI.
If my understanding is not too wrong, I cannot simply tell my SD controller to talk in a raw SPI mode but I can teach my microcontrollers to behave as a SDIO device that can be controlled by my host.
This way I still have two challenges left:
Correctly implement a generic SDIO device in my microcontroller.
Implement/configure the correct drivers in the host to be able to interact with my devices.
Implement the SDIO device seems to be a matter of following the spec.
The host-side driver, though, is something I hope I can accomplish with a user-space driver in Linux using some already existing kernel-space driver to SDIO.
That's the point that I come to ask for help.
Can anyone please point me any samples, documents or any kind of resources that can help me in my task?
On the PC side, this is all you need: http://sourceforge.net/projects/sdio-linux/
This may be useful for reference: http://www.varsanofiev.com/inside/WritingLinuxSDIODrivers.htm (although, I don't think you would be writing a driver)
On the microcontroller side, use "bit-banging" to implement the SDIO spec.
However, first consider why do this. SDIO and SPI are just serial protocols, so is USB; wouldn't you rather make an SPI-to-USB bridge? USB is much more user-friendly on the host side, as well as being more standard/more common. And if you do want a SPI-to-USB bridge, turns out it already exists, the SPI Shortcut (probably other options, this is just the first one that comes to mind)
EDIT Or, you could bit-bang I2C on the micro, if the host supports I2C (many do). Actually, go through every serial protocol the host supports, and see if you can support it easily from the micro side (by bit banging, since the micro is likely to not have a slave mode for that protocol built-in). RS232 (with level shifter), I2C, and SPI are likely to be the preferred choices. SDIO is pretty much the last choice, I think.
SDIO is very tightly specified. Unless your microcontroller has an SDIO block that is designed to act as a device rather than host, I don't think this will be possible. I know of a few special purpose communications controllers that implement an SDIO device, but I haven't come across any general purpose microcontrollers.
You would need a fairly fast microcontroller to be able to bit-bang SDIO initialization at up to 400 kHz. If running an STM32F4 at 180 MHz, this gives you only microcontroller cycles between SDIO clock cycles. If the host turns up the clock speed to the maximum of 25 MHz after initialization, then you're down to 7 cycles between SDIO clocks.
For perspective on the SDIO spec, the one you linked is a simplified spec that doesn't cover the signalling and timing of the bus. The full spec is many times larger.
As Alex I mentioned, there may be better alternatives for what you need. If your SDIO host supports SPI mode, most microcontrollers do have SPI peripherals that can act as slaves rather than hosts, so this may be an avenue without a peripheral. If your data rates are low enough, a simple UART may suffice (you can reasonably hit 1 Mbit over short distances).
I've got usb cable plugged to my computer, which D+ and D- pins are connected to multimeter. I want to send some raw bytes to get some voltage.. is it possible at all?
I'm 99% sure that usb port I've plugged cable in is something like /dev/bus/usb/002
I know that there was possibility to do the same with LPT or RS232 ports.
RS232 and LPT are not bus ! USB devices need to be addressed in order to become reachable.
Maybe unloading and reloading usb driver that drive your usb host... or trying to make a reset on usb hub host...
For doing this kind of operation on usb port, you have to break usb kernel driver and whipe all addressing operation to address directly the chipset...
At all, due to USB concept, I'm not sure you may successfully hold some power state on outlet.
For playing with that kind of physical IO, two solution:
Install a low-cost RS-232 <-> USB adapter
or better
Buy an Arduino micro-controller for prototyping and development.
I'm nearly 100% sure that you can't send anything down your USB lead unless you actually have a device at the other end. If you still want to play with this, get a cheap memory stick, break the casing off it [not too roughly], and measure whilst doing a large file-transfer to the memory stick, or some such.
But I'm not sure your multimeter will show much, as they tend to be a bit slow, compared to USB rates.
USB uses pull-up / pull-down resistors on the data lines to detect whether or not a port is connected (1.5k pull-up to 3.3v on the device side, 15k pull-down on the host side IIRC). The exact connection depends on the device speed.
So if you connect an appropriate resistor, the host should attempt to start signalling. Because of the data-rate, you might not be able to see that on a multimeter; an oscilloscope would be more appropriate.
If you want to by-pass the normal USB protocol and just blindly send data, I think you'll need to get your hands dirty and write code to bypass the usual device drivers and access the USB hardware directly. Even then I'm not sure what's possible - the USB hardware is a lot smarter than good ol' LPT and RS232 ports, which might get in the way of doing this sort of low level stuff.