我们正在开发一个小型的embedded式设备。 这个设备我们是一个运行OpenEmbedded linux的gumstix overo板。 我们已经完成了我们的发展，并且遇到了我们无法想象的奇怪的错误。
我们有一个USB设备（分光光度计），它具有USB2.0连接和光源的外部电源。 典型的行为是，你插入电源，然后USB连接到主机。 当设备检测到USB连接时，设备启动并启用光源和风扇。 该设备然后能够被主机系统使用。
问题是，如果在打开Gumstix之前将设备插入Gumstix，USB设备显然不会被系统探测（因此不会打开）。 在正常情况下，当连接通过插入USB电缆进行初始化时，光谱会自动打开并可用于系统（通常可以通过“lsusb”查看）。 这些事情都没有发生。 没有通过“lsusb”检测到设备，也没有任何可以看到的dmesg错误。 就好像该设备没有插入。
如果拔下USB电缆并在系统启动后重新插入，设备将显示并正常工作。 它打开并显示在USB总线上，我们可以通过我们的驱动程序访问它。
在任何其他台式机或笔记本电脑上，插入光谱仪时主机系统是打开还是closures并不重要。 这种行为是我认为是“正常”的 – 在启动的时候usb系统被探测和初始化，并且usb设备联机。 换句话说，只要我们在启动系统后插入usb设备，我们的系统就可以正常工作。 不幸的是，这在我们的最终产品中是不可能的 – 一切都马上就来临了。
附加信息：1）当系统closures时，我们尝试了连接到系统的闪存驱动器。 启动系统使闪存驱动器在线，如预期2）没有关于spectro或usb设备（使用dmesg）的消息。 “lsusb”只列出USB集线器/控制器。 从字面上看，就好像设备不存在并且没有插入。3）我们尝试了一个来自gumstix的全新图像和一个去年的旧图像。 这两个图像都有这个问题。 这个问题存在于我们使用的所有3个gumstix设备上。
有没有人有什么build议？ 从我可以告诉它是不是真的有可能做一个完整的“重新启动”USB系统，这是一个完全的“拔除”和“重新插入”USB设备的仿真。 我觉得现在发生的事情是，usb总线上没有任何初始探测会触发usb握手，但这对于spectro来说是某种特定的。 这似乎是内核问题，或者至less是内核初始化usb子系统的问题。 我不确定。
我已经尝试了gumstix邮件列表，但似乎没有任何人看到过这个问题。 任何意见或build议，从哪里开始寻找将是太棒了。
谢谢！ 布莱恩
output etc. $ uname -a Linux overo 2.6.33 #1 Tue Apr 27 08:35:38 PDT 2010 armv7l GNU/Linux When the system is up and running and spectro is plugged in (working as intended), this is lsusb: Bus 001 Device 116: ID 2457:1022 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x2457 idProduct 0x1022 bcdDevice 0.02 iManufacturer 1 USB4000 1.01.11 iProduct 2 Ocean Optics USB4000 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 46 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 400mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 4 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x0000 (Bus Powered) dmesg output: usb usb1: usb auto-resume hub 1-0:1.0: hub_resume usb usb2: usb auto-resume ehci-omap ehci-omap.0: resume root hub hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0000 hub 2-0:1.0: hub_resume hub 2-0:1.0: state 7 ports 3 chg 0000 evt 0000 hub 1-0:1.0: hub_suspend usb usb1: bus auto-suspend hub 2-0:1.0: hub_suspend usb usb2: bus auto-suspend ehci-omap ehci-omap.0: suspend root hub usb usb2: usb resume ehci-omap ehci-omap.0: resume root hub hub 2-0:1.0: hub_resume ehci-omap ehci-omap.0: GetStatus port 2 status 001803 POWER sig=j CSC CONNECT hub 2-0:1.0: port 2: status 0501 change 0001 hub 2-0:1.0: state 7 ports 3 chg 0004 evt 0000 hub 2-0:1.0: port 2, status 0501, change 0000, 480 Mb/s ehci-omap ehci-omap.0: port 2 high speed ehci-omap ehci-omap.0: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT usb 2-2: new high speed USB device using ehci-omap and address 2 ehci-omap ehci-omap.0: port 2 high speed ehci-omap ehci-omap.0: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT usb 2-2: default language 0x0409 usb 2-2: udev 2, busnum 2, minor = 129 usb 2-2: New USB device found, idVendor=2457, idProduct=1022 usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 2-2: Product: Ocean Optics USB4000 usb 2-2: Manufacturer: USB4000 1.01.11 usb 2-2: uevent usb 2-2: usb_probe_device usb 2-2: configuration #1 chosen from 1 choice usb 2-2: uevent usb 2-2: adding 2-2:1.0 (config #1, interface 0) usb 2-2:1.0: uevent drivers/usb/core/inode.c: creating file '002' dmesg has nothing to say, and lusb simply lists nothing else but the two default usb controllers / hubs if we plug the device in before the system is turned on. 这听起来好像设备试图在第一次启动时与操作系统聊天，并且由于当时堆栈还没有准备好，它从集线器“注销”了。 考虑在引导过程结束时添加一个部分，以删除驱动程序并强制重新加载。 （ modprobe -vr ehci_hcd; modprobe -v ehci_hcd if USB2.0， uhci_hcd if USB1.x）
另一种可能是当Gumstixclosures时，它告诉设备进入省电模式，可能会被设备不当的支持。 Windows可能会做与Windows不同的事情，这可能是供应商所testing的。 要testing这一点，您可能必须告诉设备驱动程序在系统重新启动期间不要挂起或closures设备。 在USB部分查看有关节能的Linux内核文档以开始使用。
把它从死亡中带回来完成。
细节是模糊的，但事实certificate，设备本身在启动时崩溃。 我相信这与uBoot在USB线上产生的喋喋不休有关。 本质上，uBoot轮询所有硬件线路（包括USB）以查找可启动镜像。 这个轮询应该是无害的，但我们的USB设备上的固件无法处理它，并立即崩溃，使其无法操作，直到硬重置（物理拔出设备并重新插入）。
我们确实向设备制造商报告了这个错误，但是我们没有收到任何迹象表明这个问题的修复（显然只会影响到我们）将成为一个优先事项，所以我们采取了0.50美元的修复措施。
我们解决这个问题的方式非常有创意，但工作完美无瑕。 我们build立了一个简单的GPIO控制继电器，并通过这个继电器将USB电源线连接起来。 从本质上说，系统启动与继电器“closures”，因此没有权力的USB设备。 系统正常启动，在我们的启动脚本中，我们简单地切换GPIO线来激活继电器。 USB设备可以正常启动，不受uBoot干扰。