Unable to connect via HDMI or SSH

Robotics & Edge Computing Jetson & Embedded Systems Jetson TK1
1

I’ve connected my TK1 in recovery mode, connected the micro-USB.

I ran the following commands, exactly as the instructions suggest:

$ sudo tar xpf Tegra124_Linux_R21.5.0_armhf.tbz2
$ cd Linux_for_Tegra/rootfs
$ sudo tar xpf …/…/Tegra_Linux_Sample-Root-Filesystem_R21.5.0_armhf.tbz2
$ cd …/
$ sudo ./apply_binaries.sh

Then, I hold down the force recovery button while pressing the reset button on the board. Then I run

$ sudo ./flash.sh jetson-tk1 mmcblk0p1

The output of this command is here:

https://gist.githubusercontent.com/movq/cc156635b18ed830053648882f428148/raw/c00b22b761885e9639d97836301e2c7c0212da60/gistfile1.txt

So everything looks fine to me. But when I connect a monitor via an HDMI-to-DVI cable and reset the board, I see nothing. If I connect an ethernet cable, the board shows up in my router’s LAN page, with the right MAC address. I can ping the IP (192.168.0.14), which is promising, but unfortunately when I try to ssh into ubuntu@192.168.0.14, the board doesn’t respond.

How should I go about debugging this issue? Does the output of the flashing script indicate that the flash was successful? Is ssh disabled by default and if so, how can I enable it before flashing?

Thanks in advance for any advice.

2

The flash log shows success. I would have probably increased the partition size with “sudo ./flash.sh -S 14580MiB jetson-tk1 mmcblk0p1”, but it shouldn’t cause any failure. It is possible that if there is not enough space to write temp files some operations will fail (such as GUI login, or perhaps network logins writing temporary files). You might reflash with more available storage just to check.

About ssh…if ssh has successfully connected at some previous time there is a “fingerprint” of that system saved in the connection client’s “~/.ssh/known_hosts” file. Flashing can change the Jetson’s fingerprint because keys may have changed. In that case your client will reject the Jetson as a possible man-in-the-middle attach. I do not think this happened since it didn’t tell you it is rejecting the connection, but it is worth mentioning. You can find out more about the ssh failure though via the “-v” verbose option (you can add up to 3 “-v” to be even more verbose, e.g., “-vvv”). Normally a number of protocols and tests fail since there are a list of steps, but you may see something useful with this.

If you really want to see what is going on without re-flashing I’ll suggest you get a serial console connected (the 9-pin D-sub connector). Settings would be 115200 speed, 8N1.

3

I’ve reflashed with the increased partition size, but I’m getting exactly the same problems. I’ve added the verbose SSH option show that it gets stuck “Connecting to 192.168.0.14”, and then times out, so I guess the port is closed or the SSH server isn’t running, or the OS isn’t booting properly. It seems strange that it responds to ping, though.

I’ll get a serial console connector and go from there. Thank you for the help.

4

If a firewall were to block the port then it would immediately close connection attempt. The fact that it waits means it is reaching the Jetson, but the Jetson is not responding (“the lights are on, but nobody is home”). This is sort of a long shot, but the machine you did the flash from…was the file system type ext4? Or was it a VM on top of a non-Linux file system type? From the directory you ran the flash in you can find out with “df -H -T .” to see both available system and type.

If this does not give any indication, then it may be time to connect the serial console to see what is going on.

5

So it turns out I was building and flashing the image from a btrfs filesystem.

My root filesystem is ext4 though (Debian Stretch), so I tried doing it there (started from scratch with the tar files) but it’s still not working. It’s actually an old board that’s been sitting unused in the box for a few years. Maybe it’s faulty.

6

If it managed to flash there is a strong chance it isn’t faulty (a lot has to be functional for flash to complete). On your host what is the output of:

gawk '/ext4/,/[}]/' mke2fs.conf

Mostly I’m looking for incompatible 64-bit options, including “64bit” and “metadata_csum”.

7 
$ gawk '/ext4/,/[}]/' /etc/mke2fs.conf 
        ext4 = {
                features = has_journal,extent,huge_file,flex_bg,metadata_csum,64bit,dir_nlink,extra_isize
                inode_size = 256
        }
        ext4dev = {
                features = has_journal,extent,huge_file,flex_bg,metadata_csum,inline_data,64bit,dir_nlink,extra_isize
                inode_size = 256
                options = test_fs=1
        }

So I see the incompatible options are there. Should I remove them and retry flashing?

8

There is a way to enter those options to not use within the flash.sh script where it does the mkfs (I’m not where I can see the flash.sh script at the moment though). There is an option with a carrot “^” symbol which can be used to disable 64bit and metadata_csum without editing “/etc/mke2fs.conf” (a “-O ^64bit,^metadata_csum” type option). However, you can simply eliminate those from mke2fs.conf while you do the flash, and then put them back in (I advise saving a backup file if you alter a system file). If you find the man page for the mkfs command in the flash.sh script you can find the “^” option which is explained (search for “^”).

9

It worked! Thank you so much.