There is a solution for Usb hotplug issue? thanks
Il giorno domenica 12 maggio 2013 18:08:32 UTC+2, Andrew Henderson ha scritto: > > Hello all. I have been working on porting a project of mine ( > http://www.beaglesnes.org) from the BeagleBoard-xM over to the BeagleBone > Black. I am running a Linux kernel based on the am33x-v3.8 branch of > Robert Nelson's linux-dev GitHub project. It is similar to the kernel > built directly by the branch's build_kernel.sh script, but I've removed a > number of modules, unused file systems, etc. in order to make the kernel a > bit smaller. I use the toolchain fetched by the build_kernel.sh script to > build the kernel. The Linux distro underneath is an Ubuntu Quantal 12.10 > armhf. I'm using the v2013.04 u-boot release that I've built using an > arm-cortex_a8-linux-gnueabi cross-compiler toolchain (GCC 4.4.6) that I > built using crosstool-NG (v1.18.0). > > USB ERRORS: > > I have most of the issues worked out, but I'm still seeing some issues > with the USB subsystem on the board. I picked back through several > thousand messages in the Google group, but I did not see my particular > issue addressed. I will occasionally see the BBB refuse to enumerate an > HID gamepad plugged into the USB1 Host port with the following error: > > usb 1-1: device descriptor read/64, error -110 > > My research has shown that a 110 error refers to being unable to enumerate > the USB device because power is exceeded. I'm not sure why this would be > the case, since I am using a 5V power supply, rather than supplying power > via USB. The gamepad being plugged into the Host port should not be > drawing a lot of power. The odd thing is that the -110 error will occur > after multiple power cycles in a row, but then disappear. At that point, > plugging in the gamepad will work fine for several more power cycles (the > USB device will enumerate and be properly identified). There doesn't seem > to be any rhyme or reason to it. It doesn't matter if the board is hot or > cold, if the reset button is pressed or not at the last power cycle, etc. > I'll just get a string of either "working" or "not working" for the USB > device enumeration. > > I have tried playing with the kernel configuration a bit to see if I might > be able to remove this problem. I tried removing EHCI support to force the > gamepad to be enumerated as a USB 1.1 device, since my research has shown > that going from USB 2.0 to 1.1 will reduce power usage for some devices. > No luck there. I also reviewed the patches currently in the GitHub > repository, but the closest one that I could see that might effect this is > the patch usb/0011-ARM-OMAP-am335x-musb-use-250-for-power.patch. I didn't > see anything in the AM3359A errata that relates to this, either. > > Any suggestions? Has anyone seen something similar? Are there any known > work-arounds? > > HOTPLUG WORK-AROUND: > > Some of you might have already seen something similar to this, but I > figure that it wouldn't hurt to share my approach on it. My application > (BeagleSNES) supports the hotplugging of USB gamepads on the BB-xM, so I've > added support for this in userspace in my BBB port. My review of > the usb/0009-MUSB-Hack-around-to-make-host-port-to-work.patch showed a > comment of "After removing the device, issue lsusb to cause it to scan > the bus again." Using lsusb doesn't work for me, but "cat > /dev/bus/usb/001/001 > /dev/null" does. If I unplug the gamepad, plug it > back in, and then issue that shell command, an ls of "/dev/bus/usb/001" > will show that the gamepad has been enumerated again. I do this > programmatically in my code using the following process: > > 1. I perform a "cat /dev/bus/usb/001/001 > /dev/null" in the launch script > for my app (called from rc.local) to scan the bus prior to start. > 2. In my application, I poll once per second or so via readlink() on the > file /dev/input/by-path/platform-musb-hdrc.1.auto-usb-0:1:1.0-joystick to > see if the gamepad is plugged in. > 3. If it is plugged in, I make a note of it, open the proper /dev/jsX > file, and interact with the gamepad. > 4. If the gamepad has been unplugged (i.e. readlink() fails), I do the > following: > > int usbFD, usbCount; > char buffer[1024]; > sleep(2); /* Give the kernel time to sync up (a sync() also works here, > but is overkill) */ > /* Force a read of the USB bus to emulate hotplugging */ > usbFD = open("/dev/bus/usb/001/001", O_RDONLY); > while((usbCount = read(usbFD, buffer, 1024)) > 0); > close(usbFD); > > > 5. After this, I go back to the regular readlink() polling. If a gamepad > poll now has a successful readlink(), a gamepad has been plugged back in. > Open it via /dev/jsX (whatever device the readlink() points to) and > continue on. > > This addresses the hotplugging issue for me, but I happen to know the > exact USB file to look for and I know which bus to force a rescan on. > There is also the 2 second delay that occurs when a gamepad is unplugged, > but this is a relatively rare occurrence, so the delay is acceptable for my > purposes (better than having no gamepad at all after it gets unplugged, > anyway). > > Andrew > > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
