I'm trying to implement a USB gadget using Linux on NXP iMX6 which implements an isochronous IN endpoint but got stuck as the gadget application on the iMX6 seems to hang, and eventually resulting a reboot of my i.MX6 platform.
Started with the usb.c example from http://www.linux-usb.org/gadget/usb.c and modifying it for the iMX6.
The Linux Kernel used for this development is Ver. 4.1.15.
Then, mounting the gadgetfs framework using:
modprobe gadgetfs
mkdir /dev/gadget
mount -t gadgetfs none /dev/gadget
This results in a 2184000.usb file in the /dev/gadget directory.
Modified the usb.c example to look for this 2184000.usb file and fill a set of USB descriptors. The host computer did recognizing the iMX6 as a USB device with the USB descriptors which I configured. But then, the gadget application on the i.MX6 seems to just hang and then reboot my Linux platform eventually.
Has anyone experience the same situation and got a solution? Please can you share source code or suggestion? Thanks!
Related
I am trying to use .net nano on esp32 cam module. I am able to upload the firmware over serial. After that I can see .net nano boot messages over serial , device explorer also it detects. But no operation on device explorer works eg get device capabilities, erase etc not working.
i am getting ESP32_WROOM_32 # COM8 is not responding, please reboot the device.
Deployment of new application also fails with the same. Is it because wroom firmware not supported on this cam module ?
this is the firmware log
Connected to ESP32 ESP32D0WDQ6 (revision 1) with MAC address CC50E3B6A7AC
features WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Flash information: manufacturer 0x32 device 0x16406 size 4MB
Trying to find ESP32_WROOM_32 in developement repository...OK
Downloading firmware package...OK
Updating to 1.6.1-preview.24
Erasing flash...OK
Flashing firmware...OK
Make sure there is no other application "locking" that COM port. Usual suspects are Arduino VS extensions and other utilities that try to find Arduino devices when new COM ports are enumerated.
I have a STM32373c-eval board and just getting started.
I have installed Truestudio, CubeMX and ST flash utility on my ubuntu 16.04 cause I don't have access to Keil or a Windows PC.
Using CubeMX I generated a code for LED toggle and it worked fine.
Now I did the same for USB CDC - checked the Device(FS), RCC clock at High Speed (Crystal) and
under Middlewares I have set Communication Device Class (COM Port) for Class For FS IP and USB clock is at 48Mhz.
I did no modifications in the generated code just flashed it and connected the kit to my Ubuntu alas I don't see the enumeration.
I also checked for any jumper settings for USB but there ain't any.
Can any one help me out in this regard?
Thanks.
Right. So I've been looking at VBS Scripts and batch files recently and autorun.inf would really be the cherry on the cake (don't worry I don't plan on using it as a tool for evil). I know that it has been turned off by default on Windows 7 onward but I read somewhere that it is still on for CDs. So naturally, I wonder - Is it possible to make the USB drive look as if it were a CD to make autorun work?
a USB pen drive and a USB CD tray have the same device class (USB mass storage device class). the problem is that despite the same device class there are other parts in USB protocol that differ (interface descriptors, configuration descriptors, endpoint descriptors,...) These usb descriptors that are also responsible for what driver / kernel module is loaded by the os, are hardcoded in the firmware of the device. your only chance to make a pen drive appear as a CD is to change these hardcoded descriptors or what is easier, to build your own device using a microcontroller with USB functionality in that you program your custom descriptors. Note that kernel modules and drivers are based on standardized protocol so your descriptors have fit these standards for the device to work.
In http://www.beyondlogic.org/usbnutshell/usb1.shtml is more information about USB protocol and the descriptors...
I have a AM335X ARM processor on a custom board. I am running angstrom linux 3.2.0 on it.
My build environment is a 64 bit laptop running Ubuntu 12.0.4.
I was hoping (I am a newbie), someone could explain what I need to do to configure the board (and host desktop) to run SSH over USB.
Any help would be greatly appreciated
It depends whether you have OTG port or not. If yes, you should configure it to emulate a network device. Connect your board to your laptop and you should see a new networking device (usb0 or something like this). Configure IP addresses for both host usb0 and one on your board and you're done having an extra IP subnet, where you can ping, SSH etc.
The rest of my team will make for my application a simple non-standard USB microphone, but until they finish it I will have to emulate it, for integration testing purposes.
Is there any risk in a physical loopback? Yes there is
Will a physical loopback work? Only with a USB bridge
There is any way to create a logical loopback? (MSDN has something about this)
There is any general purpose USB emulator software?
In case there is many options available I'd rather work it .NET/Matlab/Python solutions.
Edit: Proof of concept here
I strongly recommend this project, USB IP. It is a way of connecting USB devices over the network. There is a Windows client.
What this means is, you install the client on your Windows computer.
This device then expects to talk to a USB device connected to a Linux computer, the server:
What you now do, is either create a fake device driver for Linux, that looks like is connected to a physical USB device, but in reality is just logic pretending to be your USB device. There are tutorials for writing USB drivers for Linux. Or you create your own stub driver for the Device Control Manager (see picture above). This stub driver could run on Windows or Linux, it wouldn't matter. It could even run on the same Windows machine which is the USB client.
The DSF USB Loopback Device mentioned in the question itself, would be the same kind of solution as a stub driver for the Device Control Manager, but taking Linux out of the picture altogether.
You can write virtual USB device using QEMU.
You can duplicate already existing device, like the dev-serial.c found in this QEMU repository and change it for your needs.
After you write and compile your USB device you can simply attach it to your VM using the QEMU command line interface.