I want to know what is the significance of tegra_xusb_firmware . Currently we have a custom board(similar to Jetson) which is unable to detect the usb 3.0 . The only change is the USB2.0 port, which in our case is USB2P0 in case of jetson it is USB2P2 . I have modified the pad configurations and usb_port_monitor_info to ‘1’ to select the corresponding port but i see that there is no response coming from the firmware and still the port acts as USB2.0 .
Do we need to change the firmware or the current firmware would suffice? Any help would be really appreciated.
I’m not sure what you mean by “USB2Px”?
Based on the TRM and the “Jetson TK1 DevKit Specification” there are separate USB controllers and only one of them is USB 3.0 capable.
The docs are here:
There may be an issue where USB3 detection is incorrect, but in which USB3 is actually running correctly at USB3 speeds. How are you determining that the connection is running at USB2 instead of USB3? Read from this thread entry forward:
Within Jetson the firmware file loaded is tegra124-pm375, and within that file a block specifies “xusb@70090000”. The number is the controller address, listed in the TRM as “XUSB_HOST”. This line within that block is probably what is of interest:
nvidia,lane_owner = <4>; /* USB3P0 USB3P1 */
As mentioned by Kulve, only one of the several USB controllers are capable of USB3…the address used in the TRM for XUSB and the base physical address in both TRM and tegra124-pm375 tie this firmware block to the proper USB3 controller. As you may have found from information on enabling USB3 there is a kernel option which is also required:
# Enabled full-sized-A connector as USB2:
# Instead enabled full-sized-A connector as USB3:
Next to usb_port_owner_info in kernel parameters you will see “lane_owner_info=6”. This never changes on Jetson when switching between USB2 and USB3, but this is apparently what corresponds to the firmware section you’re looking at.
I have not looked deep enough to be positive about what I’m about to suggest, but it seems that port owner and lane owner combine to specify logical controllers and pinmux. Without the firmware these parameters would be ignored. Unfortunately I do not know any of the details of this interaction (eventually it is something I’m going to need to know myself).
Thanks for the information. I am using same USB3.0 port as Jetson. So the same lane owner should be working for our custom board also.
Modified the usb_port_owner_info = 1 which will select USB2.0 port 0 . I took the logs from Jetson and our custom board and compared the logs. I could see that there is no response coming back from the controller . Please find the attached logs for reference.
Also modified the pad configurations as indicated by TRM
nvidia,gpio_ss1_sata = <0>;
nvidia,portmap = <0x701>; / SSP0, USB2P0, USBP1, USBP2 /
nvidia,ss_portmap = <0x70>; / SSP0 on USB2P00 - modified /
nvidia,lane_owner = <4>; / USB3P0 USB3P1 /
nvidia,ulpicap = <0>; / No ulpi support. can we remove */
status = “okay”;
Not sure why the interrupt is not getting served . Any help would be really appreciated.
Thanks and Regards,
USB3_Logs_comparision.txt (3.62 KB)
This is just a wild guess, but I noticed the “tegra_xhci_bus_suspend”. Here’s a link which shows some information about this:
The particular part to wonder about is if your USB is simply “sleeping”. A quote from that web link:
# Disable USB auto-suspend, since it disconnects some devices such as webcams on Jetson TK1.
echo -1 > /sys/module/usbcore/parameters/autosuspend