Get no access to Jetson Nano Module after flashing

Autonomous Machines Jetson & Embedded Systems Jetson Nano
1

I developed a carrier board for the Jetson Nano and was able to flash the Jetson Nano module with eMMC memory via USB.
As version I used Linux for Tegra R32.4.3 and the sample root filesystem same Revision.

The command was on my Linux computer:
sudo ./flash jetson-nano-emmc mmcblk0p1

After the flash process was completed, I was prompted to reboot.
With the USB cable a USB device including files is created on my Ubuntu computer. I can also open this device.
But I can’t establish a connection with the command

ssh nvidia@192.168.55.1
or
screen /dev/ttyACM0 115200
I get the message “Connection refused”.

I can’t complete the headless installation.
The ethernet interface seems to run up as well, because on my Fritz Box an IP address is assigned to this device. But the SSH access does not work here either.

What am I doing wrong or how can I activate the SSH access?

Does anyone have an idea or the appropriate hint?

2

Since there is not yet any account to log in to, this is working as expected. Headless should work via the serial console. When you say headless, did you mean you tried serial console?

Normally you must complete first boot account creation and set up either with a local keyboard/monitor, or else via serial console. Serial console information is listed here:
https://www.jetsonhacks.com/2019/04/19/jetson-nano-serial-console/

If you have no way to complete this, then you can use a script to set up the flash software to pre-create the login details. See:
https://forums.developer.nvidia.com/t/jetson-nano-all-usb-ports-suddenly-stopped-working/75784/37

3

I have a Linux host machine with Ubuntu 20, so I can’t flash the module with the Jetson SDK, because the SDK Manager only supports up to Ubuntu 18.
My carrier electronics has no HDMI connection. I could only connect a keyboard via USB. But I can’t see what I am typing.

I had the assumption that I could connect to the Jetson via the USB console. But this connection is rejected.

I have a Jetson Nano Devkit too and I have a Jetbot image on the SD Card. Here I can use the USB cable to establish a SSH connection.

When connecting the electronics to the Linux host, this USB device is created where there are several files to read. So in my opinion the USB connection works. Only the SSH client on the Jetson Nano Linux seems not to be activated.

4

You can temporarily set up to “lie” to SDKM and tell it the host is Ubuntu 18.04. You would need to avoid installing packages to the host PC, but this should work for installing to the Jetson. See:
https://devtalk.nvidia.com/default/topic/1048748/jetson-tx2/sdkmanager-quot-not-supported-on-linux-quot-/post/5324501/#5324501

For an Ubuntu 18.04 host the “/etc/lsb-release” file would be:

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.5 LTS"

Command line flashing works with any Linux flavor/release (or at least anything desktop PC architecture released over about the last 10 years). Command line flashing does not install “extras” (like CUDA), but in newer releases many of those extras can be installed via apt-get and are not necessarily mandatory to be added via SDKM (the release used is mandatory, but the Jetson won’t care if it is via SDKM or apt-get). Thus you could use the previously mentioned script to pre-setup the first boot login and flash with that, and perhaps later add the optional packages you are interested in.

Serial console will not care if you have a monitor or not.

Note that the previously mentioned script about first boot being completed on the host prior to flash will also work on an SD card image. You just mount the image over the “Linux_for_Tegra/rootfs/”, and run the script. Just be careful to not run any flash software as this might edit your SD card.

Just to emphasize, if there is no account yet, then it is impossible for ssh to work. You could ping, but there is nobody to log in to. It is absolutely mandatory to complete first boot setup on any of the more recent releases before ssh will work (older releases had default accounts so they could be used immediately with ssh).

Serial console is as close to absolutely reliable as you can get. This console has almost no requirements. If serial console has no output during boot, then I would suspect the serial console setup is incorrect. This doesn’t mean the first boot setup is that reliable, but you can use serial console as debugging just by knowing if anything printed from it during boot.

If serial console has some sort of “permission denied”, then know that either your user must be a member of group “dialout”, or you must use “sudo”. This is a setting on the host PC side, not the Jetson.