[U-Boot] [PATCH 0/3] usb: xhci: Add interrupt transfer support

Bin Meng bmeng.cn at gmail.com
Thu Jun 29 09:54:39 UTC 2017


Hi Stefan,

On Thu, Jun 29, 2017 at 4:57 PM, Bin Meng <bmeng.cn at gmail.com> wrote:
> Hi Stefan,
>
> On Thu, Jun 29, 2017 at 4:09 PM, Stefan Roese <sr at denx.de> wrote:
>> Hi Bin,
>>
>>
>> On 29.06.2017 08:51, Bin Meng wrote:
>>>
>>> Hi Stefan,
>>>
>>> On Thu, Jun 29, 2017 at 2:13 PM, Stefan Roese <sr at denx.de> wrote:
>>>>
>>>> Hi Bin,
>>>>
>>>> On 29.06.2017 07:39, Bin Meng wrote:
>>>>>
>>>>> Hi Stefan,
>>>>>
>>>>> On Wed, Jun 28, 2017 at 8:47 PM, Stefan Roese <sr at denx.de> wrote:
>>>>>>
>>>>>> Hi Bin,
>>>>>>
>>>>>> On 28.06.2017 14:11, Bin Meng wrote:
>>>>>>>
>>>>>>> On Wed, Jun 28, 2017 at 7:00 PM, Stefan Roese <sr at denx.de> wrote:
>>>>>>>>
>>>>>>>> Hi Bin,
>>>>>>>>
>>>>>>>> On 26.06.2017 13:05, Bin Meng wrote:
>>>>>>>>>
>>>>>>>>> This series is the final series of the xHCI driver update.
>>>>>>>>>
>>>>>>>>> This adds the missing interrupt transfer support to xHCI driver, so
>>>>>>>>> that devices like USB keyboard that uses interrupt transfer when
>>>>>>>>> CONFIG_SYS_USB_EVENT_POLL is defined can work.
>>>>>>>>>
>>>>>>>>> Previous two series:
>>>>>>>>> [1]: usb: xhci: Fix USB xHCI support on Intel platform
>>>>>>>>> https://lists.denx.de/pipermail/u-boot/2017-June/296166.html
>>>>>>>>> [2]: usb: hub: Support USB 3.0 hubs
>>>>>>>>> https://lists.denx.de/pipermail/u-boot/2017-June/296284.html
>>>>>>>>>
>>>>>>>>> This series is available at u-boot-x86/xhci-working3 for testing.
>>>>>>>>
>>>>>>>>
>>>>>>>> I'm using this git branch to test all your xHCI related patches
>>>>>>>> now. On my BayTrail platform I get these messages upon "usb reset"
>>>>>>>> scanning:
>>>>>>>>
>>>>>>>> => usb reset
>>>>>>>> resetting USB...
>>>>>>>> USB0:   Register 7000820 NbrPorts 7
>>>>>>>> Starting the controller
>>>>>>>> USB XHCI 1.00
>>>>>>>> scanning bus 0 for devices... cannot reset port 1!?
>>>>>>>> USB device descriptor short read (expected 18, got 8)
>>>>>>>> 5 USB Device(s) found
>>>>>>>>           scanning usb for storage devices... 1 Storage Device(s)
>>>>>>>> found
>>>>>>>>
>>>>>>>> On the 2nd scan, the "cannot reset port 1" line is gone:
>>>>>>>>
>>>>>>>> => usb reset
>>>>>>>> resetting USB...
>>>>>>>> USB0:   Register 7000820 NbrPorts 7
>>>>>>>> Starting the controller
>>>>>>>> USB XHCI 1.00
>>>>>>>> scanning bus 0 for devices... USB device descriptor short read
>>>>>>>> (expected 18, got 8)
>>>>>>>> 5 USB Device(s) found
>>>>>>>>           scanning usb for storage devices... 1 Storage Device(s)
>>>>>>>> found
>>>>>>>>
>>>>>>>> All USB devices seem to be detected correctly though. Here the
>>>>>>>> logs:
>>>>>>>>
>>>>>>>> => usb tree
>>>>>>>> USB device tree:
>>>>>>>>      1  Hub (5 Gb/s, 0mA)
>>>>>>>>      |  U-Boot XHCI Host Controller
>>>>>>>>      |
>>>>>>>>      +-2  Hub (480 Mb/s, 100mA)
>>>>>>>>      |
>>>>>>>>      +-3  Hub (480 Mb/s, 2mA)
>>>>>>>>      | |
>>>>>>>>      | +-5  Mass Storage (480 Mb/s, 200mA)
>>>>>>>>      |      JetFlash Mass Storage Device 3281440601
>>>>>>>>      |
>>>>>>>>      +-4  Vendor specific (5 Gb/s, 64mA)
>>>>>>>>           Realtek USB 10/100/1000 LAN 000002000000
>>>>>>>>
>>>>>>>> => usb info
>>>>>>>> 1: Hub,  USB Revision 3.0
>>>>>>>>     - U-Boot XHCI Host Controller
>>>>>>>>     - Class: Hub
>>>>>>>>     - PacketSize: 512  Configurations: 1
>>>>>>>>     - Vendor: 0x0000  Product 0x0000 Version 1.0
>>>>>>>>       Configuration: 1
>>>>>>>>       - Interfaces: 1 Self Powered 0mA
>>>>>>>>         Interface: 0
>>>>>>>>         - Alternate Setting 0, Endpoints: 1
>>>>>>>>         - Class Hub
>>>>>>>>         - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms
>>>>>>>>
>>>>>>>> 2: Hub,  USB Revision 2.0
>>>>>>>>     - Class: Hub
>>>>>>>>     - PacketSize: 64  Configurations: 1
>>>>>>>>     - Vendor: 0x0409  Product 0x005a Version 1.0
>>>>>>>>       Configuration: 1
>>>>>>>>       - Interfaces: 1 Self Powered Remote Wakeup 100mA
>>>>>>>>         Interface: 0
>>>>>>>>         - Alternate Setting 0, Endpoints: 1
>>>>>>>>         - Class Hub
>>>>>>>>         - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
>>>>>>>>
>>>>>>>> 3: Hub,  USB Revision 2.1
>>>>>>>>     - Class: Hub
>>>>>>>>     - PacketSize: 64  Configurations: 1
>>>>>>>>     - Vendor: 0x0424  Product 0x4604 Version 1.131
>>>>>>>>       Configuration: 1
>>>>>>>>       - Interfaces: 1 Self Powered Remote Wakeup 2mA
>>>>>>>>         Interface: 0
>>>>>>>>         - Alternate Setting 0, Endpoints: 1
>>>>>>>>         - Class Hub
>>>>>>>>         - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
>>>>>>>>         - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
>>>>>>>>
>>>>>>>> 5: Mass Storage,  USB Revision 2.10
>>>>>>>>     - JetFlash Mass Storage Device 3281440601
>>>>>>>>     - Class: (from Interface) Mass Storage
>>>>>>>>     - PacketSize: 64  Configurations: 1
>>>>>>>>     - Vendor: 0x8564  Product 0x1000 Version 16.117
>>>>>>>>       Configuration: 1
>>>>>>>>       - Interfaces: 1 Bus Powered 200mA
>>>>>>>>         Interface: 0
>>>>>>>>         - Alternate Setting 0, Endpoints: 2
>>>>>>>>         - Class Mass Storage, Transp. SCSI, Bulk only
>>>>>>>>         - Endpoint 2 Out Bulk MaxPacket 512
>>>>>>>>         - Endpoint 1 In Bulk MaxPacket 512
>>>>>>>>
>>>>>>>> 4: Vendor specific,  USB Revision 3.0
>>>>>>>>     - Realtek USB 10/100/1000 LAN 000002000000
>>>>>>>>     - Class: (from Interface) Vendor specific
>>>>>>>>     - PacketSize: 512  Configurations: 2
>>>>>>>>     - Vendor: 0x0bda  Product 0x8153 Version 48.0
>>>>>>>>       Configuration: 1
>>>>>>>>       - Interfaces: 1 Bus Powered Remote Wakeup 64mA
>>>>>>>>         Interface: 0
>>>>>>>>         - Alternate Setting 0, Endpoints: 3
>>>>>>>>         - Class Vendor specific
>>>>>>>>         - Endpoint 1 In Bulk MaxPacket 1024
>>>>>>>>         - Endpoint 2 Out Bulk MaxPacket 1024
>>>>>>>>         - Endpoint 3 In Interrupt MaxPacket 2 Interval 8ms
>>>>>>>>
>>>>>>>> Do you have any ideas about the scanning logs that I've noticed
>>>>>>>> above? Would it help if I provided some debug logs (-DDEBUG)
>>>>>>>> for this?
>>>>>>>
>>>>>>>
>>>>>>> "cannot reset port 1" message is annoying, but that may happen
>>>>>>> sometimes due to unstable power supply. I will see if we can mute it
>>>>>>> if it's not the final round of reset try.
>>>>>>
>>>>>>
>>>>>> That would be good, thanks.
>>>>>>
>>>>>>> I am more concerned about
>>>>>>> the "USB device descriptor short read (expected 18, got 8)". This
>>>>>>> message indicates U-Boot cannot get the device descriptor during set
>>>>>>> configuration process. So did you manage to get all USB devices that
>>>>>>> are connected on your board enumerated?
>>>>>>
>>>>>>
>>>>>> Might be that I'm missing some keyboard / mouse, which I'm not
>>>>>> using and not really aware of. One USB port is connected to a
>>>>>> KVM switch, enumberating such devices. Here the log from U-Boot
>>>>>> and Linux again:
>>>>>>
>>>>>> => usb reset
>>>>>> resetting USB...
>>>>>> USB0:   Register 7000820 NbrPorts 7
>>>>>> Starting the controller
>>>>>> USB XHCI 1.00
>>>>>> scanning bus 0 for devices... cannot reset port 1!?
>>>>>> USB device descriptor short read (expected 18, got 8)
>>>>>> 6 USB Device(s) found
>>>>>>          scanning usb for storage devices... 2 Storage Device(s) found
>>>>>> => usb tree
>>>>>> USB device tree:
>>>>>>     1  Hub (5 Gb/s, 0mA)
>>>>>>     |  U-Boot XHCI Host Controller
>>>>>>     |
>>>>>>     +-2  Hub (480 Mb/s, 100mA)
>>>>>>     |
>>>>>>     +-3  Mass Storage (480 Mb/s, 98mA)
>>>>>>     |    USBest Technology USB Mass Storage Device 09092207fbf0c4
>>>>>>     |
>>>>>>     +-4  Hub (480 Mb/s, 2mA)
>>>>>>     | |
>>>>>>     | +-6  Mass Storage (480 Mb/s, 200mA)
>>>>>>     |      JetFlash Mass Storage Device 3281440601
>>>>>>     |
>>>>>>     +-5  Vendor specific (5 Gb/s, 64mA)
>>>>>>          Realtek USB 10/100/1000 LAN 000002000000
>>>>>>
>>>>>>
>>>>>> $ lsusb -t
>>>>>> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 5000M
>>>>>>       |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class,
>>>>>> Driver=r8152, 5000M
>>>>>> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 480M
>>>>>>       |__ Port 2: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
>>>>>>           |__ Port 4: Dev 4, If 0, Class=Hub, Driver=hub/4p, 12M
>>>>>>               |__ Port 1: Dev 6, If 1, Class=Human Interface Device,
>>>>>> Driver=usbhid, 12M
>>>>>>               |__ Port 1: Dev 6, If 2, Class=Human Interface Device,
>>>>>> Driver=usbhid, 12M
>>>>>>               |__ Port 1: Dev 6, If 0, Class=Human Interface Device,
>>>>>> Driver=usbhid, 12M
>>>>>>       |__ Port 4: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage,
>>>>>> 480M
>>>>>>       |__ Port 5: Dev 5, If 0, Class=Hub, Driver=hub/4p, 480M
>>>>>>           |__ Port 1: Dev 7, If 0, Class=Mass Storage,
>>>>>> Driver=usb-storage, 480M
>>>>>>
>>>>>>
>>>>>> Which event polling Kconfig option do I need to enable?
>>>>>>
>>>>>
>>>>> The default one CONFIG_SYS_USB_EVENT_POLL should be OK. By comparing
>>>>> your U-Boot log and Linux one, I found the following devices were
>>>>> enumerated by Linux but not by U-Boot:
>>>>>
>>>>>               |__ Port 1: Dev 6, If 1, Class=Human Interface Device,
>>>>> Driver=usbhid, 12M
>>>>>               |__ Port 1: Dev 6, If 2, Class=Human Interface Device,
>>>>> Driver=usbhid, 12M
>>>>>               |__ Port 1: Dev 6, If 0, Class=Human Interface Device,
>>>>> Driver=usbhid, 12M
>>>>>
>>>>> These devices are full speed devices. I believe the reason is that
>>>>> U-Boot encounters "USB device descriptor short read (expected 18, got
>>>>> 8)" so it does  not continue the enumeration. As to why these full
>>>>> speed devices only return 8 bytes descriptors, this needs to be
>>>>> investigated. Which devices are they?
>>>>
>>>>
>>>> This is my KVM switch with its USB keyboard and mouse. When I unplug
>>>> this USB cable, this message does not appear while running "usb reset".
>>>>
>>>> This also happen, when I only plug a USB mouse to this same USB
>>>> port:
>>>>
>>>> => usb reset
>>>> resetting USB...
>>>> USB0:   Register 7000820 NbrPorts 7
>>>> Starting the controller
>>>> USB XHCI 1.00
>>>> scanning bus 0 for devices... USB device descriptor short read (expected
>>>> 18, got 8)
>>>> 5 USB Device(s) found
>>>>         scanning usb for storage devices... 2 Storage Device(s) found
>>>> => usb tree
>>>> USB device tree:
>>>>    1  Hub (5 Gb/s, 0mA)
>>>>    |  U-Boot XHCI Host Controller
>>>>    |
>>>>    +-2  Mass Storage (480 Mb/s, 98mA)
>>>>    |    USBest Technology USB Mass Storage Device 09092207fbf0c4
>>>>    |
>>>>    +-3  Hub (480 Mb/s, 2mA)
>>>>    | |
>>>>    | +-5  Mass Storage (480 Mb/s, 200mA)
>>>>    |      JetFlash Mass Storage Device 3281440601
>>>>    |
>>>>    +-4  Vendor specific (5 Gb/s, 64mA)
>>>>         Realtek USB 10/100/1000 LAN 000002000000
>>>>
>>>>
>>>> $ lsusb -t
>>>> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 5000M
>>>>      |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152,
>>>> 5000M
>>>> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 480M
>>>>      |__ Port 2: Dev 2, If 0, Class=Human Interface Device,
>>>> Driver=usbhid, 12M
>>>>      |__ Port 2: Dev 2, If 1, Class=Human Interface Device,
>>>> Driver=usbhid, 12M
>>>>      |__ Port 4: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage,
>>>> 480M
>>>>      |__ Port 5: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M
>>>>          |__ Port 1: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage,
>>>> 480M
>>>>
>>>>
>>>> Can you reproduce this on your MinnowMax? Would it help, if I
>>>> would enable some traces (-DDEBUG)?
>>>
>>>
>>> I cannot reproduce this on MinnowMax. Is the KVM switch a USB 2.0 or
>>> 3.0 hub?
>>
>>
>> USB 2.0, its a pretty old device. But the example above is without the
>> KVM and only with the USB mouse.
>>
>>> Is it possible to switch BayTrail SoC to EHCI and do the same
>>> testing?
>>
>>
>> Sure. After disabling CONFIG_USB_XHCI_HC I now get this error:
>>
>> => usb reset
>> resetting USB...
>> USB0:   USB EHCI 1.00
>> scanning bus 0 for devices... Divide Error
>> EIP: 0010:[<7b587862>] EFLAGS: 00010246
>> Original EIP :[<fff33862>]
>> EAX: 00000040 EBX: 7b35db00 ECX: 00000380 EDX: 00000000
>> ESI: 7b33af40 EDI: 7b33aa00 EBP: 7b35a640 ESP: 7b33a990
>>  DS: 0018 ES: 0018 FS: 0020 GS: 0018 SS: 0018
>> CR0: 00000033 CR2: 00000000 CR3: 00000000 CR4: 00000600
>> DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
>> DR6: ffff0ff0 DR7: 00000400
>> Stack:
>>     0x7b33a9d0 : 0x7b35dac0
>>     0x7b33a9cc : 0x7b33af40
>>     0x7b33a9c8 : 0x00000100
>>     0x7b33a9c4 : 0x7b33ac80
>>     0x7b33a9c0 : 0x00000001
>>     0x7b33a9bc : 0x7b33ac80
>>     0x7b33a9b8 : 0x7b35a680
>>     0x7b33a9b4 : 0x00000000
>>     0x7b33a9b0 : 0x00000040
>>     0x7b33a9ac : 0x80000080
>>     0x7b33a9a8 : 0x7b35db00
>>     0x7b33a9a4 : 0x00000040
>>     0x7b33a9a0 : 0x00000002
>>     0x7b33a99c : 0x7b35dac0
>>     0x7b33a998 : 0x1616cae2
>>     0x7b33a994 : 0xc8159ec7
>> --->0x7b33a990 : 0xc1b7c2b0
>>     0x7b33a98c : 0x00010246
>>     0x7b33a988 : 0x00000010
>>     0x7b33a984 : 0x7b587862
>> ### ERROR ### Please RESET the board ###
>>
>> EHCI worked before just fine. Does this (EHCI) work on your
>> MinnoxMax?
>
> I've reproduced the EHCI crash issue. Looks the crash happens in
> ehci_submit_async(). However my patches did not touch this function. I
> will debug this.

It turns out this patch breaks EHCI.
http://patchwork.ozlabs.org/patch/779917/

Regards,
Bin


More information about the U-Boot mailing list