如果USB设备是在powerup之前插入的，我们的嵌入式linux系统将无法识别它。有什么建议吗？
我们正在开发一种小型嵌入式设备。这个设备是一个运行OpenEmbedded linux的gumstix板。我们已经几乎完全完成了我们的开发，并且遇到了我们无法理解的最奇怪的bug。
我们有一个USB设备(分光光度计)，有一个USB2.0连接和外部电源的光源。典型的行为是您插入电源，然后USB连接到主机。当设备检测到usb连接时，设备启动并启用光源和风扇。然后，该设备能够被主机系统使用。
问题是，如果在我们打开Gumstix之前将设备插入Gumstix，那么USB设备显然不会被系统探测(因此不会打开)。在正常情况下，当通过插入usb电缆来初始化连接时，频谱会自动打开，并可供系统使用(这通常可以通过"lsusb“看到)。这两件事都没有发生。没有通过"lsusb“检测到的设备，也没有我们可以看到的任何类型的dmesg错误。就好像这个装置没有插上。
如果我们拔掉USB电缆并在系统启动后将其插回，设备就会出现并正常工作。它打开并显示在usb总线上，我们可以通过我们的驱动程序访问它。
在任何其他台式机或笔记本电脑上，当我们插入分光计时，主机系统是打开还是关闭并不重要。我认为这种行为是“正常的”-- usb系统在启动时被探测和初始化，并且usb设备在线。换句话说，只要我们在系统启动后插入usb设备，我们的系统就能充分发挥作用。不幸的是，在我们的最终产品中，这是不可能的--每件事都是一次发生的。
附加信息: 1)当系统关闭时，我们尝试了连接到系统上的闪存驱动器。开机系统带来的闪存驱动器在线，如预期2)没有消息有关的频谱或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.回答 2
Server Fault用户
发布于 2017-09-28 17:07:19
把这个从死里拿回来完成。
细节是模糊的，但事实证明，设备本身在启动时崩溃了。我相信这与uBoot在USB线路上产生的聊天有关。本质上，uBoot对所有硬件线路(包括USB)进行了民意调查，以找到可引导的映像。这个轮询应该是无害的，但是我们USB设备上的固件无法处理它并立即崩溃，这使得它在硬复位之前无法操作(物理上拔出设备并将其插入)。
我们确实向设备制造商报告了这个错误，但是我们没有收到任何迹象表明问题的修复(显然只影响到我们)将是一个优先事项，所以我们求助于$.50修复。
我们解决这个问题的方法很有创意，但效果很好。我们建立了一个简单的GPIO控制继电器，并通过该继电器连接USB电力线。本质上，系统启动与继电器“关闭”，因此没有权力的USB发展。系统正常启动，在我们的启动脚本中，我们只需切换GPIO行来激活中继。USB设备可以正常启动，不受uBoot的干扰。
Server Fault用户
发布于 2010-10-26 22:46:54
听起来，设备似乎在第一次启动时就试图与操作系统聊天，而且由于堆栈当时还没有准备好，所以它从集线器“注销”了。考虑在引导过程的末尾添加一个节，以删除驱动程序并强制重新加载。(modprobe -vr ehci_hcd; modprobe -v ehci_hcd如果USB2.0，uhci_hcd如果USB1.x)
另一种可能是，当Gumstix关闭时，它告诉设备进入节电模式，这可能是设备不适当的支持。Windows可能会做一些与Windows不同的事情，这可能是厂商测试的全部内容。要测试这一点，您可能必须告诉设备驱动程序在系统重新启动期间不要暂停或关闭设备。查看USB部分中的Linux内核关于节电的文档即可开始。
https://serverfault.com/questions/194991
复制相似问题
腾讯云开发者
