如果在开机前插入 USB 设备,我们的嵌入式 Linux 系统将无法识别它。有什么建议吗?

如果在开机前插入 USB 设备,我们的嵌入式 Linux 系统将无法识别它。有什么建议吗?

我们正在开发一款小型嵌入式设备。该设备使用运行 OpenEmbedded Linux 的 gumstix overo 板。我们的开发工作几乎全部完成,并且遇到了一些我们无法解决的最奇怪的错误。

我们有一个带有 USB2.0 连接的 USB 设备(分光光度计)光源的外部电源。典型行为是插入电源,然后将 USB 连接到主机。当设备检测到 USB 连接时,设备启动并启用光源和风扇。然后主机系统就可以使用该设备。

问题是,如果在打开 Gumstix 之前将设备插入 Gumstix,则系统显然不会探测 USB 设备(因此不会打开)。在正常情况下,当通过插入 USB 电缆初始化连接时,spectro 会自动打开并可供系统使用(通常可以通过“lsusb”看到)。但这两件事都没有发生。通过“lsusb”没有检测到任何设备,我们也没有看到任何类型的 dmesg 错误。 就像设备没有插入一样。

装置如果我们拔下 USB 电缆并在系统启动后重新插入,它就会显示并正常工作。它会打开并显示在 USB 总线上,我们可以使用驱动程序访问它。

在任何其他台式机或笔记本电脑上,当我们插入光谱仪时,主机系统是打开还是关闭都无关紧要。我认为这种行为是“正常的”——USB 系统在启动时被探测和初始化,并且 USB 设备联机。换句话说,只要我们在系统启动后插入 USB 设备,我们的系统就可以完全正常运行。不幸的是,这在我们的最终产品中是不可能的——一切都会同时启动。

附加信息:1) 我们尝试在系统关闭时将闪存驱动器连接到系统。启动系统后,闪存驱动器会按预期联机 2) 没有关于 spectro 或 usb 设备的消息(使用 dmesg)。“lsusb”仅列出 USB 集线器/控制器。这实际上就像设备不存在且未插入一样。3) 我们尝试了 gumstix 的全新映像和去年的旧映像。两个映像都有这个问题。我们使用的所有 3 个 gumstix 设备都存在此问题。

有人有什么建议吗?据我所知,完全“重启”USB 系统实际上是不可能的,这完全模拟了“拔出”和“重新插入”USB 设备。我觉得发生的事情是 USB 总线上没有初始探测来触发 USB 握手,但这在某种程度上是 spectro 特有的。这似乎是内核问题,或者至少是内核如何初始化 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.

答案1

将其从死亡中带回来并完成。

细节尚不清楚,但事实证明设备本身在启动时崩溃了。我认为这与 uBoot 在 USB 线路上产生的抖动有关。本质上,uBoot 轮询了所有硬件线路(包括 USB)以查找可启动映像。这种轮询应该是无害的,但我们的 USB 设备上的固件无法处理它并立即崩溃,导致它无法运行,直到硬重置(物理拔出设备并重新插入)。

我们确实向设备制造商报告了这个错误,但没有收到任何迹象表明修复该问题(显然只影响我们)是优先事项,因此我们只好花费 0.50 美元进行修复。

我们解决这个问题的方法非常有创意,但效果却非常完美。我们构建了一个简单的 GPIO 控制继电器,并通过这个继电器连接了 USB 电源线。本质上,系统在继电器“关闭”的情况下启动,因此 USB 设备没有电源。系统正常启动,在我们的启动脚本中,我们只需切换 GPIO 线即可激活继电器。USB 设备可以正常启动,不会受到 uBoot 的干扰。

答案2

听起来好像设备在第一次启动时尝试与操作系统通信,但由于当时堆栈尚未准备好,它从集线器“注销”。考虑在启动过程结束时添加一个部分以删除驱动程序并强制重新加载。(modprobe -vr ehci_hcd; modprobe -v ehci_hcd如果是 USB2.0,uhci_hcd如果是 USB1.x)

另一种可能性是,当 Gumstix 关闭时,它告诉设备进入省电模式,但设备可能不支持该模式。Windows 可能与 Windows 不同,这可能是供应商测试的全部内容。要测试这一点,您可能需要告诉设备驱动程序不要在系统重启期间暂停或关闭设备。查看Linux 内核节能文档在 USB 部分开始。

相关内容