Board seems to run, but no output on monitor (via HDMI)

I flashed my Tegra X1 board sucessfully with the latest Jetpack (2.1), with the instructions provided in http://developer.download.nvidia.com/embedded/L4T/r23_Release_v1.0/l4t_quick_start_guide.txt . It provides a image of L4T 23.2 .

I think I did OK (although I used a VMWare image of Ubuntu 14.04 (x64) which is not recommended officially), the last output lines on terminal were:
[ 248.2324 ]
*** The target t210ref has been flashed successfully. ***
Reset the board to boot from internal eMMC.

Then I connected the board to a HDMI-capable monitor with a normal HDMI cable.
But, when I reboot, no output is on the monitor (monitor tells me that it does not receives a input signal).

The board seems to work, the two LEDS (power + SOC) are active, as in the photo in https://devtalk.nvidia.com/default/topic/894945/jetson-embedded-systems/jetson-tx1/post/4734065/#4734065

I also waited a bit and tried to plug off and on the HDMI cable, as indicated in
https://devtalk.nvidia.com/default/topic/898077/jetson-embedded-systems/tx1-not-booting/post/4734179/#4734179
https://devtalk.nvidia.com/default/topic/901186/jetson-tx1/jetson-tx1-does-not-start-power-up/
but that does not help me.

I should note that I use not the original AC adapter (was missing in the devkit), but a AC adapter for notebooks with 19 V and 6.32 A, seems to work.

Any hint would be great, what is going wrong. Maybe I have to set some jumper ? Is there another display out on the board except for the HDMI output?
Can I ssh somehow to the board and check if I can ping it ? Our network does not use DHCP, but it uses static IP adresses.

You’ve probably done everything correctly…odds are that the issue is related to how the video drivers determine monitor settings.

The serial console is the preferred way to see how things went. See this:
http://elinux.org/Jetson_TX1#Serial_Console_Wiring

Networking should be up. The trick is knowing the network address for the JTX1. The JTX1 will use DHCP, but without something to assign the address (a router), the JTX1 will not be reachable. I use Fedora so I cannot use JetPack, but it is possible JetPack used your host PC to assign the address during install…and so your JTX1 may actually have an address. Either the dmesg command or logs in /var/log (right after restarting the JTX1) of the host PC would likely mention if it had assigned a DHCP address.

About the software issues of monitors: The EDID wire of anything other than 15-pin VGA can be queried by the video card to find out what settings are valid for the monitor. Anything breaking that connection would cause failure (such as using a 15-pin VGA adapter). Sometimes the length of cable is at issue, sometimes the HDMI version number is insufficient (newer versions have tighter requirements…it isn’t that older cable versions are wired differently, it is that older versions are wired with less strict requirements). There also seems to be a flaw in some of the software correctly reading EDID (EDID is read by different software at different stages of boot, e.g., console versus X11) such that only newer monitors will work…during boot of the JTX1 you could possibly see a very brief note on your monitor about scan rate being outside of the monitor’s maximum rating. Try other monitors and cables if you can.

can you ssh the board? Just to verify that it is up?

ssh ubuntu@
password ubuntu

linuxdev: I don’t think there’s an HDMI specification that was less strict about the wiring of DDC and CEC wires on the cable. They must be connected at both ends of the cable. What’s definitely true, however, is that the HDMI and CEA specifications are targeted at cables, connectors and displays and NOT at people designing PCBs for reference platforms. 99.9% of all your HDMI problems will be down at the device level, not at your TV, not directed at the cable (unless you tied a knot in it…)

The TX1 is well-designed so it conforms with all of the above wiring requirements (since the SoC is picking them up and there are functional units to control them), but that doesn’t belie the possibility that something has gone horribly wrong. Before 23.1 I couldn’t get a display on my TX1 to save my life, and then updating it with JetPack included something, somewhere, that enabled it to display an industry standard 1920x1080p@60Hz mode on a really common Dell business-class monitor.

I’ve not tried 23.2 yet, but I’m a little worried that they changed something… I never did manage to bisect
it to the point where I figured out what fixed 23.1 in the first place.

There are two really common issues with HDMI drivers and “HDMI” monitors:

  • The presence of an HDMI connector on a monitor is not conformance to the full HDMI specification. The only way you can tell that you have an HDMI-capable display is via the HDMI vendor block in the EDID. Without that, it’s a requirement to drive the display as plain DVI video using standard “IT” mode timings (since it re-uses the signalling specification) as originally defined – that means no HDMI InfoFrames, no audio multiplexing, or other messing around and a relatively strict interpretation of display modes. Most drivers don’t bother to make the distinction. Monitors that don’t have real HDMI support tend to be unhappy with that.

  • If you can’t get EDID information at all, the only only valid mode you can display is 640x480@60Hz with a 25.175MHz pixel clock (i.e. CEA VIC #1). Linux has plenty of infrastructure (DRM, framebuffer, Xorg, and so on) that will drive the display at 640x480@60-23MHz (not possible over a digital link), 800x600 (not valid unless the monitor has Windows Logo Certification circa 2007) or 1024x768 (a weird, non-square mode that most monitor vendors only support because of ridiculous scenarios such as this). Xorg ships with default modelines which are not possible on most digital monitors… go figure.

Older HDMI cables, even draft specification ones before HDMI 1.0, unless physically damaged, should work on the TX1 for at least the 1920x1080i@30Hz mode but would be actually phenomenally over-specified for VIC #1. The problem you get when you drive a 640x480 display is a software one: most people don’t consider it a target when they’re designing user interfaces.

But it’s at least a display!

So far as cables go for older versus newer standards, it isn’t the EDID channel which is at issue…all of those other things you mention are more likely, but newer cables designed for running at higher scan rates have also evolved over time for better materials (lower loss), as well as changing the way twisted pairs are twisted. When there is only one twisted pair it won’t matter nearly as much as when more than one twisted pair travels down the same cable (pitch of twist of individual pairs changes noise…ratio of twist pitches of two pairs changes cross-talk)…I don’t know about on HDMI cables, but there are other cases (such as in networking) where pitch of the twist on a second twisted pair is changed to better deal with cross-talk at expected frequencies. Should an EDID suggest to video that a higher scan rate is just fine, but the cable has too much loss, noise or cross-talk when scanning at a high bandwidth which did not exist at the time of the cable design, then the cable itself is a problem.

Incidentally, if you walk along an RF cable with a pure sine wave while carrying a spectrum analyzer to see defects it isn’t unusual to see loss at places where people have stepped on the cable with hard shoes. Not an issue if you don’t need precision, but every little defect (even from nearly invisible shoe deformation) introduces more loss and more susceptibility to noise (if there is no noise source the defect won’t be a noise problem…but as soon as you have two pair or more of cables then by definition you have a noise source).

When my own JTX1 (L4T R23.1) first arrived my monitor would not work (neither GUI nor console), but the reason was briefly noted by the monitor…scan rate was too fast for the monitor. Yet this monitor had full EDID, and worked great on a JTK1. After a Jetson first arrives it does not have the nVidia-specific files used for graphical mode display…so console mode (as a boot/init stage with no GUI stage available until nVidia files were loaded) had to have ignored the valid modes at the software level (the same scenario on JTK1 did not have this issue). Upon using ssh to log in to the JTX1 and install the nVidia-specific files the graphical mode then began to work (which does its own reading and implementation of EDID data separate from console mode software). There is more to the story though because the way the drivers work using older data plus extensions for newer standards (rather than just coming up with a new standard every time something new like high-def or ultra-high-def is added). In the case of R23.2 console modes also work on the monitor which fails console mode under R23.1.

Thanks to all for the tips, helped to steer me into the right direction …
The problem is solved now :-)
Actually, the monitor i was using had only DVI input and only 1024x768, and I used a HDMI to DVI adapter cable. So either the low resolution or the HDMI->DVI adapter cable did make my board unhappy.
I forgot about that, because it was working fine with my Raspberry Pi 2 and also with my Jetson Tegra K1 (Kepler GPU).

I tried now with a Full HD monitor with native HDMI input, now it works, monitor gets a signal from the board.
So everything works fine.

It seems (as you indicated) that the Tegra X1 is more ‘picky’ with the output cables and/or output monitor than other embedded boards …

@linuxdev, @HannesF99,

It’s really, really, really difficult to find a cable that wouldn’t be able to transmit 1920x1080 video reliably in this day and age. It would have to be extremely poorly manufactured, or physically damaged, to cause an actual problem.

As it stands, EDID and CEC are absolutely required to be connected to the monitor per the HDMI specification (otherwise it is technically not an HDMI cable and should never, ever have hit the shelves) - the source of 99.4% of all problems getting a display is poor driver software, the other 0.5% is a broken EDID block in the monitor. The final 0.1% is the cable.

The signalling for DVI and HDMI, apart from some interleaving of special data (which should be well within timings between DVI frames) is absolutely identical. Unless the DVI-HDMI adapter was quite poor, it’s unlikely that the adapter was broken if an RPi 2 worked but yout TX1 didn’t. That almost 100% points at poor software fallback or a bad monitor EDID, and I’d point at the software… if it gracefully went to 640x480@60-25.175 then nobody would ever have had “no display!” problems, and been able to diagnose immediately what caused the fallback mode.

I’m glad the 1024x768 thing was the actual problem.

Hi All,
I am facing similar problem, flashed with the latest jetpack, everything was ok, connected with my 32inch TV display (HMDI) everything was smooth.
But when i connected with a latest Samsung monitor, nothing on display.

I had faced similar problem before where i used a workaround of Serial console but this time i want to fix this issue as i dont want to hang with my laptop for serial console.

Can anyone advice me how can fix this? any setting i need to do at display side?

Some useful information can be obtained from these commands (requires install of packages read-edid and edid-decode):

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

Also, do both TV and monitor use HDMI? Is the Samsung monitor using any kind of cable adapter?

didn’t get ur comment I new to this ,can u explain me stepwise .

Actually the Jetson works fine when I connect it to my LG tv screen it
comes no signal on the output ,basically my connection is through hdmi on=
ly
,so basically what is the thing which is stopping it ? I am trying this f=
or
many days and still no desktop comes up
Help me linux dev

@Myler, are you referring to this? Trying to keep it in one forum thread if possible:
https://devtalk.nvidia.com/default/topic/918934/jetson-tx1/tx1-is-not-booting-up-no-display-response/post/5071558/#5071558

The steps are to track down if video is failing due to configuration, or to other reasons.