“Hello, I am facing an issue where my Jetson AGX Xavier won’t connect to my PC for flashing, and the board won’t start either; it stays in boot mode. Is there a solution?”
I’m going to copy my other reply to you here…
This is a fairly common question, and probably should be in the forums for more people to see it. However, the answer is almost always to start with a serial console boot log to see what is going wrong. After what you perceive as a flash attempt, then save the serial console boot log.
The documentation for the AGX Xavier will also show this, but if you look at the left of the 40-pin header, there will be a small USB connector. This is an “OTG” (on the go) connector, which accepts either a micro type-A or micro type-B connector. The type-B is what is used there, and is simply what many people call a “charger cable”. Sadly, two out of three charger cables have extremely poor or missing data wiring are suitable only for charging, and so if you buy a low cost “charger” cable, beware that two out of three will fail for any significant data. For logging purposes the data rate is not all that high, and so even this might work for serial console logging.
You host PC will take the full-sized type-A connector (what you’d normally associate with something like a keyboard or mouse has the type-A connector). If on the host you monitor “dmesg --follow”, then as you plug it in you will see logs of some new device with a name similar to “/dev/ttyUSB0” or “/dev/ttyACM0” (the name usually depends on which manufacturer created the serial UART chip). This uses a setup speed of 115200, 8 bits, no parity, and 1 stop bit (“115200 8N1”). Programs such as minicom use that setting to see the serial console, and can log this from the host PC. I prefer gtkterm, which would start like this if it is the ttyACM# name format:
gtkterm -b 8 -t 1 -s 115200 -p /dev/ttyACM0
(you can install gtkterm with “sudo apt-get install gtkterm”)
Besides gtkterm and minicom there are other programs as well, e.g., PuTTY works from Linux or Windows. You’d need to see the instructions for either, but basically you’ll see the boot logs as the Jetson logs, and you’d enable logging on the host PC, so the log file would be created from the very start of power up on the Jetson. Without that log there is very little that can be done to solve this other than just suggesting to flash again.
You would also need to mention which release you are flashing. L4T is what actually gets flashed (which is Ubuntu plus NVIDIA drivers), and JetPack/SDK Manager is a GUI front end to the flash software. You can look here to find what is suitable for your AGX Xavier:
If the correct USB-C cable (located to the right of the 40-pin header; other USB-C will not work for this) is connected from the AGX Xavier to the host PC, and if you monitor “dmesg --follow” on the host PC prior to plugging this in, then a powered Jetson (or as power is applied) will show a log message regarding the USB-C if the Jetson is in recovery mode. For example, if the AGX is put in recovery mode and then the cable connected the log in “dmesg --follow” would show the connection, or if the AGX is off, and connected via the USB-C, then as the unit is powered on in recovery mode, there would be a log indicating the detection of the Jetson.
Recovery mode itself does not change the Jetson, it merely turns the Jetson into a custom USB device understood by the custom driver (which is part of the flash software on the host PC). The button simply need to be held down at the moment of either powering on the AGX or resetting power. The recovery button is a lot like the shift key on a keyboard when getting capital letters, but it applies to the power on and power reset to produce recovery mode. There is no need to keep holding the button down.
Many people do not realize that when flash completes the Jetson will automatically reboot. This is when first boot account setup runs on a fully booted Jetson. The Jetson is not in recovery mode anymore at this point. It is quite common for flash to work, but first boot account setup to not be visible, and so it is mistaken for a failed flash. Serial console logs will show what is really happening, and also will provide an alternate means of completing first boot account setup. That log while trying to boot is quite important.
JetPack/SDK Manager is actually trying to install optional software, e.g., CUDA, only after the Jetson is fully booted and login account setup is complete. It does this via ssh and failure could be either due to first boot account setup failure or due to network setup. Again, serial console will answer which case this is. There is an optional method to complete first boot account setup if serial console also cannot complete this. There is a reasonable chance that the system is fully booted but you just can’t see it.
Also, you need an actual HDMI or DisplayPort monitor (some digital DVI monitors will work). No VGA monitor, even with an adapter, will work unless you get very lucky.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.