Jetson Xavier NX developer kit turns on but doesn't give dsiplay


I got a nvidia Jetson Xavier NX development kit. It was completely working fine, suddenly, one day I turned it on and it didn’t display anything on the screen. It didn’t turn on the keybord nor the mouse, but the led on the board was green.

I read many forums and i got the log with serial console which is the following.
output-error.txt (58.5 KB)

I’ve tried flashing different jetpack versions in differents SD cards and still got the same log.

I don’t know what is the problem. Can someone please help me to figure this out?

Looks like the display driver is failing. Is this natively an HDMI monitor, or does it have adapters? What happens if you boot without the monitor, and then plug in the monitor? Be sure to watch serial console and see if there is a kernel panic prior to plugging in the monitor. Even if there is, see if it repeats with an HDMI unplug/replug.

Yes it is a natively HDMI monitor. I also tried with a DisplayPort monitor and got the same result. I tried plugging the monitor after it turned on, but nothing happened.

Now I’ve tried booting with Jetpack 4.6.3 and I get this outcome.
output-4.6.3.txt (27.7 KB)

I don’t know what to do because the keybord and the mouse don’t turn on. I think the jetson isn’t recognising them. Do you know why this is happening? And what can I do?

This is a soft IRQ (software driver not involving a hardware IRQ to hardware; perhaps it is a software driver triggered by output of a hardware device/IRQ), and it involves HDMI:

[    7.093888]  __do_softirq+0xb4/0x3e8
[    7.097308]  irq_exit+0xc0/0xe0
[    7.100558]  __handle_domain_irq+0x74/0xd0
[    7.104305]  efi_header_end+0xb0/0xf0
[    7.107982]  el1_irq+0xd0/0x180
[    7.110961]  tegra_hda_get_dev_id+0x6c/0x2b0
[    7.115243]  tegra_hda_init+0x234/0x440
[    7.119439]  tegra_dc_hdmi_init+0x820/0xb50
[    7.123290]  tegra_dc_set_out+0x2cc/0x480
[    7.127400]  tegra_dc_probe+0xa90/0x1570

However, it doesn’t really nail down if it is a hardware or software issue. In particular, if device tree is set up wrong, then some issues could arise. The mouse/keyboard might fail to respond if a related driver in the kernel fails. This might be an actual hardware issue if the monitor/cable are correct.

Which release is this flashed with ? See “head -n 1 /etc/nv_tegra_release” if you can boot far enough, or examine the host PC you flashed from using its “Linux_for_Tegra/rootfs/etc/nv_tegra_release”. One of the first things I’d do is to reflash the entire Jetson using JetPack/SDK Manager, and making sure any SD card install is using a version which matches the JetPack install. Mismatched content between the o/s release and device tree could in theory cause such a thing, and it is the first thing to try even if it might be a hardware issue.

1 Like

So I tried to boot the jetson via SDKManager. Everything was fine, but I get until this point:

By many tutorials the monitor connected should turn on, but mine doesn’t. I tried with a DP monitor too and same results. At least, this time the mouse turned on, but the keyboard didn’t. What could be wrong?

These are the logs I get from SDKManager (202.8 KB)

At that stage the flash has completed. The Jetson would have automatically rebooted to a normal boot. However, you’d have to first complete the first boot account setup (if you are just installing components and it isn’t a flash, then you can ignore that).

What it needs now is a valid IP address and a login account. At this point are you able to log in to the Jetson itself? You can leave that SDKM step running and log in to the Jetson as well since it is fully booted. If not, then that needs to be corrected to continue. The address is just one possible address, and is the one provided by the USB cable (which in turn requires the host PC allowing this, but most of the time no extra steps need to be taken for allowing this). Also, when this SDKM menu shows up, what do you see on the host PC for “ifconfig” (or alternatively, “ip -s addr”) and “route” (or alternatively, “ip route”)?

First of all thank you @linuxdev for your quick answers and your help. I really appreciate it.

So, I tried to turn on the jetson and I get the same outcome: no display, no mouse, no keyboard. Therefore I can’t set the account and so on. Furthermore, I can’t continue with the steps from SDKManager. This is the log I got:
error.txt (63.1 KB)

Do you know any other alternative I can try?

Was that log from the serial console? I’m guessing it was, but want to be certain.

The problem you are running into is more than just a first boot account setup. The kernel driver handling HDMI is crashing.

You said this is an actual dev kit, and not a third party carrier board. Is this an SD card model, or one with eMMC? If it is SD card, then I’m guessing the device tree and boot content might not match the release on the SD card. In that case you’d want to flash both the QSPI memory and the SD card to match. If this is an eMMC model, then I think you have to possibly remove and recreate the “Linux_for_Tegra/” content at:

A fresh install should not crash like that.

Yes, that was the log from the serial console. I’m using a SD card. It’s not a third party carrier board.

Can you share some references to try out flashing the QSPI memory and the SD card please. I have been looking for an example, but I haven’t found them.

Just run a normal full flash with JetPack/SDK Manager with the Jetson attached. For the dev kit this will flash the QSPI content. If the SD card is created from a compatible release it should then work. Note that L4T is what gets flashed, and JetPack/SDKM is just a front end to the flash. The two have versions tied together. See:

So I tried out and the flash got until this point and it got stuck in there.
error-stuck.txt (5.4 KB)

It mentions somthing abour CPU bootloader is not running on device. What could be the cause?

Is this being run on a native host PC, or on a VM? If VM, then that might be the cause (and very often is). If on a native Ubuntu, is it Ubuntu 18.04 or 20.04, or something else? Was the Jetson in recovery mode?

Incidentally, if this is not a VM, then there is an export log function on SDKM you can use to post logs of the flash.

It’s native Ubuntu PC. It’s running Ubuntu 20.04. Yeah, the jetson was in recovery mode by placing a jumper on PIN 9 and 10(that’s what the instructions say).

I finally managed to boot it, but I get the following log when turning it on (still no display, no mouse, no keyboard):
error.txt (47.8 KB)
I think it looks like the first log I shared at the beginning of this forum.

Do you think it could be a hardware problem? Or what else can I try?

The error is HDMI:

[    6.444979] tegradc 15200000.display: hdmi: tegra_hdmi_tmds_range_read(bd) failed
[    6.455759] CPU:0, Error: cbb-noc@2300000, irq=15

If this error occurs even when no monitor/mouse/keyboard is attached, then I’m thinking it is either a mismatched device tree (likely if this is not a dev kit), or else a hardware failure. Are you positive this is a development kit and does not use a third party carrier board? If it is a dev kit, then someone from NVIDIA might want to jump in for RMA. Basically, after flashing, that error should disappear and not end up being the same as before flash error.


I would suggest handle the error one by one. First, please just flash the board. Boot it up without connecting any other peripherals. Then, connect only the usb keyboard/mouse. Use serial console and share us the dmesg.

So I followed your instructions and this is the log connecting keyboard/mouse:
error-mouse-keyboard-connected.txt (58.7 KB)

It is not related to keyboard/mouse. It is a kernel panic from display driver even when no display is connected.

Could you reflash your board with sdkmanager and boot it up again? Do not connect anything , only dump the serial console log.

Ok, so I followed your instructions, and got the following log without any peripherals:
error-without-peri.txt (68.1 KB)

Could you also flash your board with jp4.6.3 and see if it can work?

So this is the log I get from jetpack 4.6.3.
output463.txt (11.3 KB)