如果在通电之前插入USB设备，我们的嵌入式linux系统将无法识别该USB设备。有什么建议吗？

我们正在开发一种小型嵌入式设备。该设备是运行OpenEmbedded linux的gumstix Overo板。我们的开发工作几乎已完全完成，并且遇到了我们无法弄清的最奇怪的错误。

我们有一个USB设备（分光光度计），它具有USB2.0连接和用于光源的外部电源。典型的行为是先插入电源，然后再通过USB连接到主机。当设备检测到USB连接时，设备会启动并启用光源和风扇。然后该设备便可以被主机系统使用。

问题在于，如果在打开Gumstix之前将设备插入Gumstix，则显然系统未检测到USB设备（因此无法打开）。在正常情况下，通过插入USB电缆初始化连接后，光谱仪会自动打开并可供系统使用（通常可以通过“ lsusb”看到）。这些事情都没有发生。没有通过“ lsusb”检测到设备，也没有可见的任何dmesg错误。 好像没有插入设备。

如果我们在系统启动后拔下USB电缆并将其重新插入，则设备确实可以正常工作。它会打开并显示在usb总线上，我们可以使用驱动程序进行访问。

在任何其他台式机或笔记本电脑上，插入光谱仪时打开或关闭主机系统都没有关系。我认为这种行为是“正常的”-在启动时探测并初始化USB系统，然后USB设备联机。换句话说，只要系统启动后插入USB设备，我们的系统即可正常运行。不幸的是，这在我们的最终产品中是不可能的-一切都立即实现。

附加信息：1）当系统关闭时，我们尝试将闪存驱动器连接到系统。引导系统，按预期方式使闪存驱动器联机2）没有有关Spectro或USB设备的消息（使用dmesg）。“ lsusb”仅列出USB集线器/控制器。从字面上看，好像设备不存在且未插入电源。3）我们尝试了gumstix的全新图像和去年的较旧图像。两个图像都有此问题。我们使用的所有3个gumstix设备均存在此问题。

有没有人有什么建议？据我所知，实际上不可能对USB系统进行完整的“重新引导”，而这是“拔出”和“重新插入” USB设备的完整模拟。我感觉正在发生的事情是，USB总线上没有任何初始探针会触发USB握手，但这在某种程度上是特定于光谱的。这似乎是内核问题，或者至少是内核如何初始化USB子系统的问题。我不太确定。

我已经尝试过gumstix邮件列表，但似乎没有人以前见过此问题。关于从哪里开始寻找的任何建议都是很棒的。

谢谢！布莱恩

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.

把它从死里拿回来完成。

详细信息是模糊的，但事实证明，设备本身在启动时崩溃。我相信这与uBoot在USB线上产生的颤动有关。本质上，uBoot会轮询所有硬件线路（包括USB）以查找可引导映像。这种轮询应该是无害的，但是我们USB设备上的固件无法处理它并立即崩溃，从而使其无法操作，直到硬重置（物理上拔下设备并重新插入）。

我们的确向设备制造商报告了该错误，但是我们没有收到解决该问题（显然只影响了我们）的信息，因此我们采用了$ 0.50的修复措施。

我们解决此问题的方法颇具创意，但工作无懈可击。我们构建了一个简单的GPIO控制继电器，并通过该继电器拼接了USB电源线。本质上，系统在继电器“关闭”的情况下启动，因此USB设备没有电源。系统正常启动，在我们的启动脚本中，我们只需切换GPIO线即可激活继电器。USB设备可以自由正常启动，而不会受到uBoot的干扰。

听起来好像该设备在首次启动时尝试与OS聊天，并且由于当时堆栈尚未准备就绪，因此它从集线器“注销”。考虑在引导过程的末尾添加一个部分，以删除驱动程序并强制重新加载。（modprobe -vr ehci_hcd; modprobe -v ehci_hcd如果是USB2.0，uhci_hcd如果是USB1.x）

另一种可能是，当Gumstix关闭时，它告诉设备进入省电模式，该模式可能不受设备支持。Windows可能所做的事情不同于Windows，这可能是供应商测试过的所有事情。要对此进行测试，您可能必须告诉设备驱动程序在系统重新启动期间不要挂起设备或关闭设备电源。在USB部分中查看有关节电的Linux内核文档以开始使用。