TX2 DOA?

After unboxing my TX2 and setting it up on my workbench I was disappointed when power was applied and nothing happened. No boot, no display, no fan. I was under the impression that it should be pre-flashed with the OS. In Forced Recovery mode the board is recognized by my host (Ubuntu 16.04) when executing lsusb. I downloaded Jetpack 3.0 and performed the flashing process twice. Both attempts displayed success but were unable to set the IP address. Still no boot-up.

The power LED should light. There is one near the heat sink (red), and two green LEDs near the power button.

It is quite common for video configuration to fail and have a working Jetson but mistake it for DOA (note that if you have an adapter between HDMI and 15-pin D-Sub VGA it is almost guaranteed to fail). JetPack itself can have issues with network setup (e.g., router issues with either an external router or the host as router…an external router might demand adding the MAC address before it’ll respond to a DHCP request, a host might have firewall software enabled). Fans typically won’t run because not enough power is consumed to generate heat and the fan won’t be needed. Showing as in recovery mode validates much of the hardware; completing a flash is itself a good indication that the hardware is working.

So JetPack may have thought it can’t set address, but what is your router? Is it the host or an external router? Can you see logs on either as you turn on the Jetson and see if there was a DHCP request?

You may want to set up a serial console to see what goes (assuming you can’t get ssh access). The TX1 serial console is the same as TX2, but you may want to start with software flow control and not CTS/DTS…serial console works even when much of the system is failed. See:
[url]http://elinux.org/Jetson/TX1_Serial_Console[/url]

If the flashing succeeded it is unlikely to have been DoA. My guess is it was indeed flashed before with factory image and instead it may not be enumerating your monitor. What kind of display are you using? Can you try a 1080p HDMI panel to start with. Also are you able to toggle caps lock or num lock LEDs on the keyboard? Instead of DHCP on the router sometimes I have to check the IP.

A reliable way to check would be with the debug serial console output. It will print the kernel log interactively at boot. Of course, if you feel your unit is defective, feel free to get in touch with customer service, however they may send you another unit that behaves the same way with your monitor.

Warranty & RMA Process

  • Go to NVIDIA Support (http://www.nvidia.com/nvcc/)
  • Select “Live Chat” or "Ask a Question" from the options near the top of the page.
  • Enter your personal information.
  • Select the appropriate product from the drop-down list (“Tegra” in this case).
  • Submit the request.
  • If the Service agent is unable to resolve the technical issue, an RMA (Return Material Authorization) will be initiated.

Thanks for your replies.

Monitor: Samsung HDMI 930 Syncmaster
Network connect for host and board is via Netgear Gb switch connected to external router

Both network connection and monitor are working when used with an RPi cluster.

When connecting TX2 to network there is no activity displayed on the switch when powered on.

There are 4 LEDs illuminated: The three mentioned above (2 by power button, 1 by heat sink) and a fourth red one by the PCI-E connector.

One note: A small bolt dropped into my lap when unwrapping the board. It appears to be from one of the four standoffs used to support the processor on the underside. This also was true with a second board we purchased for a co-worker. Unfortunately he has been too busy to start experimenting so I cannot compare his results yet.

Probably ethernet should show alive by LEDs. If the module is not bolted down correctly then I would expect a high risk of the very large/complicated connector to be at risk. Is the heat sink/module currently fully bolted down on all four corners? Does the module appear fully seated?

The module does appear to be seated firmly. My co-worker will attempt the setup over the weekend. That may tell us more. Thanks.

So i just ran across this myself, and after wiring up an arduino as a serial console (pretty easy actually) I found it was hanging when trying to init the monitor. unplugged the monitor, and everything hummed along happily again in the serial monitor.

once it got past the monitor probe, I could plug the monitor back in and everything was golden yet again. still have one that didn’t survive a reboot that i’ve got to look at next, but you may be able to boot it sans monitor then plug in to get around it (no permanent fix has been researched at this point)

I’m using an old monitor and an Apple HDMI to DVI adapter if that helps

All automatic monitor configuration is through the DDC/EDID wire. Most DVI will pass this through, although some are purely analog and do not. What is the output from:

sudo cat /sys/kernel/debug/tegradc.1/edid

When unplugging/re-plugging the monitor helps it may be because of bugs dealing with EDID for those monitors which have valid EDID.

FYI, the 4.x kernels take the monitor mode settings out of X (versus 3.x kernels) and I would expect some previous issues with monitor mode issues within X software to go away (versus 3.x kernels issues). Serial console of course is the best since it has no need of any special driver at all (it’s easy to simply pass a string of bytes through a UART).

Thanks again for your replies. I will try removing the monitor until after some amount of boot up time to see if this corrects the problem. In addition, my co-worker’s board started up without issue when set up this afternoon.

Chronoglass - your suggestion worked. Thanks.