Tegra TX1 HDMI issue

Hello guys,

I just get my brand new Tegra TX1 platform.

  1. I plug HDMI, network and power cables.
  2. Pressed power button and two green leds are on, fat spines just a half a rev.

I can ping the board, but can ssh it. Amber led is on, and green lights is blinking on RJ45 connector.

However there is noting on the HDMI TV, I also tried with two different cables, that are working with Raspberry Pi2.

TV is: Samsung LE40S81B
Digital Television Certification HD ready
Resolution 1366 x 768
Display Format 720p
Input Video Formats 480p, 720p, 1080i, 480i, 576i, 576p

Cay please help be to bring HDMI up.


It may be that the default video mode just doesn’t show up on that monitor. There are cases where the software to query a monitor does not work, and the video falls back to a mode the monitor does not support.

If you have a serial console, this should be a good way to finish the nVidia-specific file install. When the Jetson first arrives it has Ubuntu 14.04 LTS, minus the files from nVidia which provide full hardware functionality, e.g., hardware accelerated video. Completing the install via ssh or serial console to install those files may solve the issue.

Note that ssh keys may be involved in why you can’t ssh, yet can ping the Jetson. Serial console will always work though unless things are catastrophically bad. See:

Once you are logged in there is a subdirectory to the ubuntu home directory, “~/NVIDIA-INSTALLER/”. If from that directory you run “sudo ./installer.sh” you can complete the hardware accelerated file install and reboot (“sudo shutdown -h now” to halt, or “sudo shutdown -r now” to reboot).

If your RPi has get-edid and read-edid or parse-edid, you can see what RPi knows about the monitor via either of these:

get-edid | parse-edid
get-edid | edid-decode

Is it shipped with SSH server running on?

Here is the log from ssh connect attempt:

ssh -vv ubuntu@
OpenSSH_5.9p1 Debian-5ubuntu1.9, OpenSSL 1.0.1 14 Mar 2012
debug2: ssh_connect: needpriv 0
debug1: Connecting to [] port 22.
debug1: Connection established.
debug1: identity file /home/xxx/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/xxx/.ssh/id_rsa-cert type -1
debug1: identity file /home/xxx/.ssh/id_dsa type -1
debug1: identity file /home/xxx/.ssh/id_dsa-cert type -1
debug1: identity file /home/xxx/.ssh/id_ecdsa type -1
debug1: identity file /home/xxx/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.9
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
Connection closed by

debug1: SSH2_MSG_KEXINIT sent
Read from socket failed: Connection reset by peer

By default ssh daemon runs and accepts connections. The default account on all Ubuntu machines is “ubuntu” with login password “ubuntu”.

By default networking uses and configures via DHCP. Any router should see and assign an address when the Jetson boots.

Unrelated to Linux or DHCP, only the router will know the address assigned. No name server knows the address, and so no name lookup is possible by default…only the dotted-decimal address format is available. To find the machine via a named address, such as “tegra-ubuntu”, either the router has to know this name and be accessed from inside the router’s private network, or else the machine accessing the Jetson has to be configured to know the named alias.

If the machine has freshly arrived, check your router for the assigned address. Ping implies the same address as used for ssh. If you have used the JetPack utility, then there may have been network setup changes on both the Jetson and the host computer which ran JetPack, especially changes to allow naming the Jetson as “tegra-ubuntu”.

ssh remembers keys the first time an access is approved. Should those keys change, access will be denied until the old key is removed. Flashing or using JetPack for a new install may change keys at either the Jetson side or the host side. Your address “” closing like that may imply keys or setup have changed…such as via JetPack or flash altering keys.

NOTE: Getting to the point where the ssh port gives a reply before closing the connection tells you the ssh server is running…without the ssh server the connection would never have occurred.

If you use a serial console, then all networking and video issues will be irrelevant, allowing you to set things up or see logs as to why ssh aborted. You could also do a fresh flash, as flash has a setup step in it equivalent to running the NVIDIA-INSTALLER script prior to flash and having this transfer over to the Jetson.


We are using a Samsung 4K TV (UE40HU6900S) and have the problem that the Kernel crashes when the HDMI cable to the TV is plugged in during boot.

If we boot the TX1 without any HDMI cable plugged in, wait for about a minute and then plug in the TV, it is recognized and works. Maybe you could try this workaround?