[RFC] usb: xhci: Some USB devices fail to initialize
Hello,
We've noticed that, at least, on the i.MX8M* platforms, some USB devices (especially USB2.0 sticks) fail to initialize with one of the following errors: - scanning bus usb@38200000 for devices... Device not responding to set address. USB device not accepting new address (error=80000000)
- scanning bus usb@38200000 for devices... WARN halted endpoint, queueing URB anyway. Unexpected XHCI event TRB, skipping... (fcf1a5f0 00000000 13000000 01008401) BUG at drivers/usb/host/xhci-ring.c:530/abort_td()! BUG! resetting ...
It seems to be a timing problem, since if we enable the debug messages, the USB device initializes correctly.
We found out that if we add a small delay of 5 milliseconds at the beginning of the _xhci_submit_control_msg() function from the drivers/usb/host/xhci.c file, all devices initialize properly. Essentially, each control message is delayed by 5ms. We tried a smaller delay (1ms), but it is not enough.
static int _xhci_submit_control_msg(struct usb_device *udev, unsigned long pipe, void *buffer, int length, struct devrequest *setup, int root_portnr) { + mdelay(5);
struct xhci_ctrl *ctrl = xhci_get_ctrl(udev); int ret = 0; ... }
We went a little further, and this delay seems to only be necessary for the requests of type: - USB_REQ_GET_STATUS (for the communication with the root) - USB_REQ_GET_DESCRIPTOR ( for the communication with the device)
I don't have too much know-how about the USB, so I would appreciate your opinion related to this issue, and how can we find the root cause. I found several reports on the internet with the same problem on other boards. Maybe some of the USB timing specs are not implemented correctly? U-Boot is maybe sending control messages too aggressively?
If you give me some suggestions of where to look, I could do some debugging myself. Of course, since printing debug messages makes the initialization work, complicates the debugging.
Thank you, Elena
On 5/27/24 7:16 PM, Elena Popa wrote:
Hello,
Hi,
We've noticed that, at least, on the i.MX8M* platforms
Which exact platforms, which SoC, which board ?
, some USB devices (especially USB2.0 sticks) fail
Which exact sticks ? USB IDs and model would be helpful.
Which U-Boot version is this ?
We've noticed that, at least, on the i.MX8M* platforms
Which exact platforms, which SoC, which board ?
Currently I'm testing on the i.MX8M Plus EVK.
, some USB devices (especially USB2.0 sticks) fail
Which exact sticks ? USB IDs and model would be helpful.
The stick is from EBV Generic Flash Disk, VID: 0x058f PID: 0x6387
Which U-Boot version is this ?
The 2 errors I already listed appears using the U-Boot v2023.04.
Now I also tested on the v2024.04. These are the 3 behaviors: - USB device fails to init with the error: "Device not responding to set address" - USB device fails to init with the error: "Cannot read configuration, skipping device 058f:6387" - USB device succeeded to init with the following output: scanning bus usb@38200000 for devices... WARN endpoint is halted WARN endpoint is halted WARN endpoint is halted WARN endpoint is halted WARN endpoint is halted WARN endpoint is halted WARN endpoint is halted WARN endpoint is halted WARN endpoint is halted WARN endpoint is halted WARN endpoint is halted WARN endpoint is halted WARN endpoint is halted WARN endpoint is halted WARN endpoint is halted WARN endpoint is halted WARN endpoint is halted WARN endpoint is halted 2 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found
The succeeded initialization is very random. Sometimes it works, sometimes not.
Looking at the commits, I saw some improvements in the xHCI driver, but still, this issue remains.
I also tried the quick fix of adding the 5ms delay for v2024.04, and it's working: the USB device succeeded to initialize every time.
Thanks, Elena
On 5/28/24 1:04 PM, Elena Popa wrote:
We've noticed that, at least, on the i.MX8M* platforms
Which exact platforms, which SoC, which board ?
Currently I'm testing on the i.MX8M Plus EVK.
, some USB devices (especially USB2.0 sticks) fail
Which exact sticks ? USB IDs and model would be helpful.
The stick is from EBV Generic Flash Disk, VID: 0x058f PID: 0x6387
Which U-Boot version is this ?
The 2 errors I already listed appears using the U-Boot v2023.04.
Now I also tested on the v2024.04. These are the 3 behaviors:
- USB device fails to init with the error: "Device not responding to set address"
- USB device fails to init with the error: "Cannot read configuration, skipping device 058f:6387"
- USB device succeeded to init with the following output:
scanning bus usb@38200000 for devices... WARN endpoint is halted WARN endpoint is halted WARN endpoint is halted WARN endpoint is halted WARN endpoint is halted WARN endpoint is halted WARN endpoint is halted WARN endpoint is halted WARN endpoint is halted WARN endpoint is halted WARN endpoint is halted WARN endpoint is halted WARN endpoint is halted WARN endpoint is halted WARN endpoint is halted WARN endpoint is halted WARN endpoint is halted WARN endpoint is halted 2 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found
The succeeded initialization is very random. Sometimes it works, sometimes not.
Looking at the commits, I saw some improvements in the xHCI driver, but still, this issue remains.
I also tried the quick fix of adding the 5ms delay for v2024.04, and it's working: the USB device succeeded to initialize every time.
Does it also work if you 'setenv usb_pgood_delay 2000' ?
Can you include the 5ms patch ?
Hi Marek,
Does it also work if you 'setenv usb_pgood_delay 2000' ?
No, the USB stick is still not initialized.
Can you include the 5ms patch ?
I've attached the patch which makes it work. Of course, I'm not sure if this is the correct way to fix the problem. You can apply the patch on the master branch.
Thanks, Elena
On 6/1/24 4:23 PM, Elena Popa wrote:
Hi Marek,
Hi,
sorry for the really late reply.
Does it also work if you 'setenv usb_pgood_delay 2000' ?
No, the USB stick is still not initialized.
Can you include the 5ms patch ?
I've attached the patch which makes it work. Of course, I'm not sure if this is the correct way to fix the problem. You can apply the patch on the master branch.
Does this delay have to be added to every control message (unlikely) or to some specific control message (likely) ?
Could you try and use the debug() statement in xhci_submit_control_msg() , as well as move the mdelay(5) there , to find out which exact control message requires this extra delay ? I also suspect this may not really be related to a specific control message, but instead some early part of initialization .
Hi Marek,
Hi,
sorry for the really late reply.
Does it also work if you 'setenv usb_pgood_delay 2000' ?
No, the USB stick is still not initialized.
Can you include the 5ms patch ?
I've attached the patch which makes it work. Of course, I'm not sure if this is
the correct way to fix the problem. You can apply the patch on the master branch.
Does this delay have to be added to every control message (unlikely) or to some specific control message (likely) ?
The delay is necessary, at least for the requests of type: - USB_REQ_GET_STATUS (for the communication with the root) - USB_REQ_GET_DESCRIPTOR (for the communication with the device)
I added the delay one by one to each message type and without the delay for these two, it fails as I described. I created the patch which adds delay for all the messages since its simpler and it doesn’t seem to affect the performance.
Could you try and use the debug() statement in xhci_submit_control_msg() , as well as move the mdelay(5) there , to find out which exact control message requires this extra delay ? I also suspect this may not really be related to a specific control message, but instead some early part of initialization .
participants (2)
-
Elena Popa -
Marek Vasut