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