I am attempting to do a headless setup but I am looking under hardware IDs and I don’t see VID 0955 and PID 7020. My micro usb to USB is plugged in but the correct IDs don’t seem to be showing up.
Hi,
Do you mean you are not able to let Jetson Nano enter device mode?
essentially yes, I ran PUTTY but there was nothing showing up in the config, just a black screen.
Hi,
Do you need to enter recovery mode for flashing system image? Or you have flashed the system image and after booting up, you would like to enter device mode?
I’ve flashed the system image and after booting up would like to enter device mode.
Hi,
If you connect Jetson Nano(micro-B port) to host PC(type-A port) with Ubutu OS, it shall pop up L4T-README and several use-cases are listed. And you can login to Jetson Nano through ssh:
// run the command on host PC
$ ssh _USER_NAME_@192.168.55.1
Please try and check if you can run this.
how do I get Ubutu OS and get my desktop to run it? Is there a tutorial I could watch? I am currently on a windows 7 computer.
Hi,
We would suggest have an host PC in Ubuntu 18.04 or 16.04 for further development. If you connect to a Windows PC/laptop, it may not work properly.
For a Windows computer, you can have Jetson Nano and the computer in same local area network(LAN). So that you can login Jetson Nano by running
$ ssh _USER_NAME_@_IP_ADDRESS_OF_JETSON_NANO_
in PuTTY or Cygwin
I just want to add some background which might help you, but it isn’t a direct answer. It’s just some random details which might help.
Any time you see mention of serial console, this can be used from most any operating system. It’s just easier with Linux. You have have a serial terminal program to talk to the UART. On Windows this tends to be PuTTY. You’d have to tell it to point at the correct COM port, and I have no idea how to do that in Windows with a USB serial UART. Probably the device manager mentions something, but you could try every listed COM port until it works. The setting would have to be 115200 8N1 (speed 115200, 8 bits, no parity, one stop bit; no flow control, or software-only…keep CTS/RTS flow control disabled).
The host PC needs a driver for the particular USB serial UART. This is rarely a problem on Windows, it should detect and install for you. Mostly not an issue on Ubuntu as well with popular chipsets.
The SD card of SD card models holds the root filesystem. There is a lot more content in booting which is in the QSPI memory (QSPI is on the module). One can update the SD card in any way desired, but only if it is compatible with the QSPI boot content. There are various reference images for the SD card, but flash software (using SDK Manager/JetPack) is needed to update QSPI. It is rare that anyone would not suggest updating QSPI via SDKM flash prior to any serious work.
SDKM runs on an Ubuntu 18.04 host PC. Some of the code is binary executable which cannot run on Windows. Even if it could, some of the services available in Linux are needed for generating content, and Windows does not support that content. Some emulations do (not all), but VMs tend to have other issues. If you plan to develop on a Nano, then it is very advisable to dual boot with Ubuntu 18.04 (for newer platforms you’d probably want Ubuntu 20.04, but Nano is old).
Note that JetPack/SDKM is a front end to the actual flash software. It is Linux for Tegra (“L4T”) which actually gets flashed (and L4T is just Ubuntu with NVIDIA drivers). A given release of JetPack/SDKM is tied to a specific release of L4T due to the need to keep boot content and rootfs content compatible.
Some URLs:
Documentation is available with the specific L4T or JetPack release you pick. Only pick one compatible with the Nano. Nano dev kits work directly from that software, third party models with custom carrier boards usually are a modification of this.
I think I have narrowed the problems down to the fact that the model computer is so old that the BIOS is unable to update to a useable version thus causing the COM ports to not detect the Jetson Nano. Would changing the OS to Ubuntu fix this problem because I believe it might just be a hardware issue.
Note that COM ports are just another name for a serial UART. Serial UARTs are themselves not “plug-n-play”, meaning the hardware cannot self-report if it is talking to another working UART. Not detecting the port is different from the port not working. Not detecting the port as existing means the driver is not present. Seeing the port, even if it doesn’t work, means the driver is present. If a port is present but not working, then it is quite possible it is either talking to another UART which has different software settings, or else the voltage levels are off. USB serial UARTs require an extra driver since the UART is not integrated to the motherboard. This is trivial to debug and work with in Linux, and although Ubuntu might not “fix” this, it would certainly make debugging the serial console much easier. Your life would be easier if you had an Ubuntu 18.04 system (dual boot is recommended, but make sure you have plenty of disk space if you plan to flash and develop that way…simply talking over a UART has very little disk requirement).
COM ports are one of the oldest and best supported classes of devices built. They’ve been there since the keyboard was invented. For a USB serial UART there is no need for the BIOS to participate. The BIOS only matters for a port which is integrated on the motherboard, or else used during boot. Neither of those matter for a USB-based serial UART.
Would the latest version of Ubuntu work? Or would Ubuntu 18.04 be more preferable in order to debug my system?
Hi,
For development of Jetson Nano, please use Ubuntu 16.04 or 18.04 in host PC. Later version is not tested and may not work properly.
As an added note, the install software itself won’t work right if newer than Ubuntu 18.04 (for a Nano). The Nano itself, with the most recent compatible release, is Ubuntu 18.04 (L4T is Ubuntu plus NVIDIA drivers; L4T R32.x is the latest for a Nano). Incidentally, much of that requirement for the host PC is due to the GUI front end. However, truly developing, such that you cross compile and run CUDA on the host PC as well, would end up being best on Ubuntu 18.04 in this case as well (flashing with a different release on command line is possible, but other software would lack compatibility).
I have gone and ran Ubuntu 18.04.6 on a VirtualBox machine. Would the .6 part after 18.04 matter when it comes to compatibility? Also, how would I go about debugging this COM port issue?
Any 18.04.x would work. The .6 part is just saying that updates have been applied, and you’d normally want those updates anyway.
A VM is out of the control of the flash software. Flash software does not know anything about the VM. Each VM has its own instructions for passthrough of USB, networking, so on. You’d have to consult the VM’s instructions or help documentation to find out how to correctly pass through the USB. A recovery mode Jetson is a custom USB device, and during flash, it will disconnect and reconnect; the VM configuration needs to pick up not only the original USB plug-in event, but also needs to reconnect if there is a disconnect/reconnect event.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.