Just replying to a bit in order, I have not completely read this, so this is more or less starting as notes as I read.
It isn’t always obvious, but you can uncheck or check various items in JetPack/SDK Manager. It is perfectly ok to uncheck flash and install of software to a host PC, etc… You can later perform any non-flash operation without flashing again. The trick is that when that extra software is installed the Jetson must be fully booted and have the admin account ready (such as completing first boot login account setup). You can then use the IP address of the virtual USB ethernet, or any other IP address, such as the wired ethernet (the default tries to use the virtual wired ethernet address of 192.168.55.1). Just uncheck other items, boot the Jetson, and go.
Having a monitor does simplify things, but is not necessary.
Virtual wired ethernet does not depend on a GUI, nor does it depend on Wi-Fi. It is Wi-Fi which Linux and Ubuntu tries to tie to the user’s GUI login, and so everything else should work. This includes 192.168.55.1 (try pinging it from the host PC), and if wired ethernet is plugged in to the same router, then it also includes whatever address the router uses. Serial console cannot be used for this, but can be quite useful in finding out what address the wired ethernet has. Or setting up an address.
Just to reiterate, serial console should work even when much of the system is failing. If you can log in via serial console (which can complete first boot account setup), then you are good to go. If serial console does not work, then some debugging is in order. You might be interested in this:
Note that several generations of Nano use the same serial console and carrier board layout. There are multiple serial UARTs, but only one is the serial console. When UARTs with individual wires are used they require a 3.3V logic level. Some Jetsons have a micro-OTG serial port which uses USB for this function (internally it meets the 3.3V requirement and you no longer need a serial UART cable; this becomes an ordinary micro-B USB cable). Third party commercial carrier boards might be the same, but often will differ.
Serial UARTs are very common, simple, and useful, and so you will have some UART headers which are unrelated to serial console.
USB-C is used for flash, and I do not have an Orin Nano to look at, but this tends to be for flash and not for serial console (it could be used with serial console if configured and wired correctly, but I do not know of this being the case).
You basically have to know about the L4T release from where you download the software. If you have a host PC, and you now have directory “~/nvidia/nvidia_sdk/JetPack_...version.../Linux_for_Tegra/”, then the “version” tells you the JetPack release. JetPack 5.x corresponds to L4T R35.x, and JetPack 6.x corresponds to L4T R36.x. For more detailed information you would go to “Linux_for_Tegra/rootfs/etc/”, and check the content of the nv_tegra_release file. If you have already used cd to go there, then an example is:
head -n 1 nv_tegra_release
On a Jetson which is up and running (which yours is not, but I’m adding this for completeness), one would check the “/etc/nv_tegra_release” there. You can plug in an SD card and mount the partition, and check the nv_tegra_release on the SD card as well.
Now moving on to reply to the later reply…
So far as getting stuck goes, are you using a VM? USB often gets stuck when a VM loses USB. If not, then you can try to simply unplug and replug the USB cable to get it started. For a dev kit you would want to perform a QSPI flash to the Jetson (for which the Jetson is connected via the USB cable). The SD card can be created with Balena Etcher separately. I think you’d have to figure out the part where it stalls at 99% before you could continue.
Flashing the Jetson itself always requires recovery mode. During flash the Jetson does reboot if flash is successful, and this is when optional software is added without being in recovery mode. However, when it gets stuck at 99%, then it means you still need recovery mode.
Incidentally, the fan going on briefly and then off is normal. This is because the Jetson uses such little power and produces almost no heat that the fan can turn off. Under a heavy load the fan would turn on.
USB might seem to be detected either when fully booted or in recovery mode. If fully booted though, this only works if the system is up and running, which is when the wired virtual ethernet shows up. If not fully booted and running the virtual wired ethernet, then USB would most likely not be detected (there are a couple of virtual devices, and normally they all work or all fail). Flash always works only in recovery mode (such as QSPI flash of the module). Adding optional software is always from a fully booted Jetson which is not in recovery mode.
One trick for figuring out a serial console or many other devices: First monitor “dmesg --follow”. Then plug in or replug the particular USB device and see what log lines appear. Part of those log lines would note if USB saw the device change, and the rest would be related to a driver binding to the device. This is a wonderful tool for figuring out USB issues.
When a particular brand of serial UART USB cable is plugged in you will see a note of USB connecting. Then there will be a note of description of the device. Following this, there would be a note of creating the “/dev/ttyACM#” device special file. That file is not a real file, but is actually part of the driver, and lives in RAM; the existence of that file says that not only did USB function correctly, but also that the chipset of the device has a working driver that recognized this and bound to the USB device. If this no longer shows up, then it is likely because the device is one of the following:
- Not powered.
- Has a USB issue.
- Perhaps a driver no longer exists.
Basically, see what the “dmesg --follow” says. Sometimes a USB cable is of low quality and fails, but I’ve not seen that with a USB-C cable. In the case of a micro-OTG cable, a lot of “charger cables” fail due to quality issues. A separate USB serial UART cable would normally work well if the cable is correctly set with a 3.3V logic level.
Which computer is the ifconfig from? I’m guessing it is from the host PC. If the virtual wired ethernet device on the Jetson was seen by the host PC, then the host PC would have had one interface with IP address 192.168.55.100. The host PC would be able to ping itself with “ping 192.168.55.100”, and the Jetson could be pinged with “ping 192.168.55.1”. This would prove the Jetson was functional and fully booted (there could still be ssh issues). One of the same debugging tips here is to monitor “dmesg --follow” on the host PC, and then unplug/replug the relevant USB connector and see what it says (it is good to copy and paste this “new” logging from the unplug/replug).
I don’t know if you have changed addresses of the Jetson. Is the nmcli from the host PC? The virtual wired device probably won’t allow changing it through nmcli, it isn’t a “real” device, and the software interface is somewhat limited. However, the success of the ping 192.168.55.1 tends to say it is working (you probably got this part right even though I haven’t seen someone change it this way).
Now the part that must work is ssh if we are talking about installing optional software (flash is only in recovery mode; ssh and networking are not up when in recovery mode). The ssh failure seems to be an account setup issue, or else the ssh daemon is not running. Because the connection is refused, I’m thinking that the daemon is not running. When the daemon is running, and when security allows it at the host PC side, then you could connect even if the login attempt is rejected. The lack of connection means it failed before a login attempt was ever reached. I would bet that it never got to the point where a first boot account setup was available. A more poetic description is that what you’ve described is that “the lights are on, but nobody is home”.
Can you verify:
- The SD card image was from JP 5.1.4? This is L4T R35.x.
- Can you get flash of the actual Jetson to complete? If this gets stuck at 99%, then the QSPI never completed flash.
