Hello,
I am having issues with my USB on an agx xavier using the nvidia dev board.
I reset my agx xavier to default by loading jetpack 4.6.2 and when it rebooted ubuntu GUI was there but no mouse or keyboard.
I tried multiple things to no avail.
I saw that 4.6.3 was available so I loaded that with no change.
I noticed that on boot up the keyboard led’s flash for a little bit but it does not respond to the num-lock key.
When the unit is fully booted the keyboard and mouse have no power and no lights.
I can log into it via the console and when I type lsusb it shows no devices I captured the log file by typing dmesg and saving the file and attached it here.
An update:
I verified with usb port tester that there is power to the usb up until around the time the uart is enabled…so between
[ 0.000000] bootconsole [tegra_comb_uart0] enabled
and
[ 1.836674] ucsi_ccg 1-0008: read version failed
Not sure what happens in that space of time to be able to debug further…
Somehow I lost the ability to edit my original post so I am updating here.
I borrowed another xavier dev system and compared the boot logs. Not sure how I missed there was an error…
Here is the comparison
on bad board it can not read address 0x8:
[ 1.858180] Could not get extcon-dev /xudc@3550000:vbus(0)
[ 1.858950] tegra-i2c c240000.i2c: no acknowledge from address 0x8
[ 1.858998] ucsi_ccg 1-0008: read version failed
[ 1.859140] ucsi_ccg 1-0008: get_fw_info fail, err=-121
[ 1.859271] ucsi_ccg: probe of 1-0008 failed with error -121
[ 1.859707] mousedev: PS/2 mouse device common for all mice
but on good board:
[ 1.852614] Could not get extcon-dev /xudc@3550000:vbus(0)
[ 1.855949] ucsi_ccg 1-0008: FW1 Version: gn v12.06, [Base 3.1.2.1487]
[ 1.855973] ucsi_ccg 1-0008: FW2 Version: gn v12.06, [Base 3.1.2.1487]
[ 1.857087] ucsi_ccg 1-0008: fw_mode: 2
What is at address 0x8? Could something be disabled?
yes I borrowed a complete second dev system.
when I put my xavier module on the main board it booted fine and I could use the usb.
when I put the xavier module, from the dev board, on the main board with issues the usb issue remained.
Since I received the main board with issues used I do not know what might have been done to it by previous owner.
Does the usb PD controller control both usb-c ports?
I am using USB-C in back (J512) to do recovery installs without issues.
Also usb mini (J501) works fine for console access.
When the board initialy turns on the usb ports are powered but once ubuntu accesses the ports the power gets turned off to the ports. (I am using a USB monitoring module connected to the ports that shows voltage levels)
I am curious if the eeprom at 0x56 can enable or disable the access to usb-c (0x80)?
Could the previous owner have modified the data there or at some other address that affects what is functional on the board?
It would be nice to know if I can flip some bits in the eeprom to turn it back on. (is there documentation for this?)
Also it would be nice to see documentation showing what a factory eeprom contents should be.
I found a post by you from long ago where you shared the contents of 0x50 and 0x56 but with out knowing what the bits represent it is hard to know if the differences in mine are right or wrong.
I am using USB-C in back (J512) to do recovery installs without issues.
Recovery mode is a pure hardware event. It is not related to this PD controller.
usb mini (J501) works fine for console access.
That micro usb port on xavier devkit is actually not a USB interface… it is a UART. Just made to be like a usb port…
I found a post by you from long ago where you shared the contents of 0x50 and 0x56 but with out knowing what the bits represent it is hard to know if the differences in mine are right or wrong.
0x50 and 0x56 are the eeprom of the module and the carrier board. They have nothing to do with the PD controller.
What I am talking about is there is another i2c device which is for the PD controller 's firmware.
Please just reflash your board with pure sdkmanager and see if it can recover or not. If it is really broken firmware issue, then sdkmanager shall not make it alive.
And there is no “simple method” to recover it, but only RMA.