For development, we are using an NFS root filesystem on the
BeagleBoard, using a USB-Ethernet dongle connected through a powered
USB hub to the USB OTG port of the BeagleBoard (which is also the only
USB port we have on a rev B7). The kernel tree used is based on the
linux-omap-2.6 tree (with the PM branch merged in), version 126.96.36.199.
In USB host mode, it works very nicely. The kernel is loaded from the
SD card and boots. We had to integrate a small change in net/ipv4/
ipconfig.c to re-open the net devices after a DHCP timeout since USB
enumeration is an asynchronous process and can complete after the
kernel IP autoconfiguration has started. But the dongle in finally
detected, initialized, and the DHCP request gets an IP, allowing the
system to complete its boot process.
In USB OTG mode though, it's a completely different story. We have the
And the following behavior is experienced:
- On a cold boot, USB gets enumerated, the hub and the attached
Ethernet dongle are found and initialized. Everything is well and goes
very much like while in full host mode as described above.
- But after one warm reset (either by system reboot, or pressing
reset), the hub and dongle are not detected anymore, and the USB Hub
driver goes to suspend and never wakes up. But on the next reset, it
works again. And on the next one, it doesn't work, and so on. It's a
very stable once every two boot failure (or success, depending on how
you see it).
Entirely disabling power management (CONFIG_PM not set) solves the
problem, but that's not really an acceptable solution. Simply
disabling USB_SUSPEND does not, though, make things better.
We first though of a VBUS detection problem, but VBUS is detected the
same way (same linkstat value in drivers/usb/otg/twl4030-usb.c),
regardless of the outcome of the boot attempt. USB probing could have
been a problem as well, as we're running with CONFIG_PREEMPT=y (see
drivers/usb/otg/twl4030-usb.c#twl4030_usb_probe), but disabling kernel
preemption didn't help either.
The fact that it works once every two boots makes this look like a
state problem, like some register that's not reset properly and it
needs an additional cycle to get right, but I must say this goes out
of my very small USB and/or low-level knowledge.
Was this problem experienced by other people? I couldn't find posts
about a similar issue, nor could find any solution :\
Thanks in advance for your help,