TX1 is not booting up No display/response

when i powered it up, i can see 2 LEDs are illuminated, Fan spins for a sec and then stops.
No display on HDMI no display keyboard light

how to make sure board is fine?

Please re-post this question in the proper Jetson TX1 forum. Thanks!

The fan turning off is normal (the fan is throttled back unless heat rises…normally a JTX1 does not need the fan). LEDs should stay on.

Keyboard lights should work, but may not be guaranteed if USB or input drivers get in the way. Try the caps lock and num lock; try on a powered HUB.

Video is a longer topic. First, if you use any kind of cable which does not support the DDC/EDID channel, the monitor will not work. Basically anything with the older 15-pin D-sub or an adapter for this will not work.

Second, information from the monitor is sent to the video of the JTX1 via the DDC/EDID channel. Some information will be sent for older formats from modes which have existed a long time. Extensions will then send more information for newer modes, e.g., hidef 1920x1080. Finally, if your monitor supports the ultra-high-def, this will be sent as yet another extension. The video is supposed to detect oldest modes first, and even if the video is dated, should understand those settings even if newer settings are not understood. It’s sort of a fail-safe that if newer extensions are not understood, older settings will be understood.

Video data is read under console mode by one driver, and when it gets to the X11 graphics stage, uses different software for parsing of the video data. These packages tend to be independent of each other…one can fail or succeed while the other does the opposite.

Console mode (text-only) has a known issue where it may not detect and older monitor’s mode, and attempt to scan too fast. The result is the monitor remains black. A newer monitor capable of faster scanning at higher resolutions might work in console mode. Watch carefully to see if the monitor complains about scanning too fast.

Booting to graphics mode takes a bit of time, and should then work even if console mode did not…provided that DDC/EDID is readable. What kind of cable do you have on the monitor, including any adapters?

FYI, there is a good reason why people have a serial console cable for embedded work…serial console does not require any drivers per se. You can see everything even when video fails. See here for info on serial console:

Hi linuxdev,
I have computer monitor with HDMI input, reflashed board with latest jetpack but problem persist
i can see board IP on network but i cant connect to it

How are you trying to connect? Using the dotted decimal format (e.g., like “”, not a name) does not require the same degree of network setup. If ssh fails, what is the fail message?

Sometimes cables are also an issue, as JTK1 used an older HDMI standard versus newer JTX1. It may be pickier.

I am using XShell to connect using and port 22, error message is “Not able to connect”

I have tried different cables also result is same.

I answered in the other thread. I am not familiar with XShell, but if this is running from windows, you probably have other firewall issues. You should just use ssh from Linux, or a serial console…once you establish that things work, then you could figure out what’s going on with XShell.

Hi I am able to connect serial using a FTDI converter cable, but output is not readable i am using putty with given settings

any idea?

Can I confirm that settings are speed 115200, 8 bits, no parity, 1 stop bit (115200, 8N1)? Also, is the FTDI cable a 3-pin cable or a 6-pin cable? If 6-pin, can you enable RTS/CTS flow control?

For either cable type, once things are on and you are getting the unreadable output, could you disconnect and reconnect the non-USB side of the connector? Then see if it works better.

NOTE: Trying to keep this to a single forum thread. Answering from the other thread about ssh refused. The refuse could be because of some security setup issue. Was the ssh from a Linux ssh on command line? Or from some sort of ssh program other than ordinary ssh on command line?

I am using 3 pin cable using this converter http://www.digitus.info/en/products/accessories/adapter-and-converter/r-usb-serial-adapter-usb-20-da-70156/ its FDTI based
Tested with 6 Pins also but same result

I tried reconnecting but its same, i am using Putty on windows and minicom on linux both has same results.

ssh was from Linux


The output really looks like just a setting issue. Could you try using gtkterm on Linux? Also, are you positive you have the correct serial port selected (USB moves the port each time something plugs in or unplugs…listening to the wrong data stream would certainly be an issue)? Additionally, maybe restart the terminal while the unreadable text is running.

If this fails I suspect the particular serial USB UART you are using may be the issue. Serial UART cables are notorious for some brands just not working…perhaps because of I/O voltages being so widely different (FTDI USB chips would not be the problem, but the input to the RS-232 side could be 12V on one system and 5V on another, designs don’t always seem to take this into account). The driver at the Jetson side is so simple and basic that it is nearly impossible for the scrambled output to be an issue there…the stream of bytes could be a failure, but the odds are extremely high that this is instead an indicator that the Jetson functions.

Hi You rock :)

I bought an USB to TTL, it works like charm, now can you tell me how can i fix the display and shh issue?

Any link?

For display, you said you re-flashed with JetPack. I do not personally have an Ubuntu workstation/host, so I’m not sure of how JetPack configures installs, and in particular the “apply_binaries.sh” step from a manual install is of interest (JetPack must do this, I’m not sure how obvious it is to the end user). Your JetPack should have created a “Linux_for_Tegra” directory somewhere, and “rootfs” within that. If the “rootfs/etc/nv_tegra_release” exists, then apply_binaries.sh was run, and video files would be installed. Can you verify this file exists? Since you have serial console now, from the serial console, do any errors show up from “sudo sha1sum -c /etc/nv_tegra_release”? Or is all ok?

Here is an explanation about one HDMI display issue:

Can you describe the exact cabling of your video?

For ssh, this is possibly just an ordinary ssh setup issue (common for all ssh setup, more common when mixing Windows ssh clients into the mix). Your serial console client should have a logging option, from that could you post the output of “ifconfig”?

Hi nv_tegra_release file exist.
The hdmi cable i have its A type HDMI

Does everything respond “ok” if you run:

sha1sum -c /etc/nv_tegra_release

During boot, do you ever see any momentary sign of a carrier signal detected, or a note popping up about scan rate?

ubuntu@tegra-ubuntu:~$ sha1sum -c /etc/nv_tegra_release
/usr/lib/arm-linux-gnueabihf/tegra/libnvjpeg.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvddk_2d_v2.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvomxilclient.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvtvmr.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvmm_contentpipe.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvtnr.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvrm_gpu.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvrm_graphics.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvmmlite_image.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libglx.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libtegrav4l2.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvmm_utils.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvmm_parser.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvrm.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvcam_imageencoder.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvmmlite_video.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnveglstreamproducer.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvapputil.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvos.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvomx.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvodm_imager.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvparser.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvmedia.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvmmlite_utils.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvmmlite_audio.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvtestresults.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libscf.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvdc.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvddk_vic.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvmm.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvavp.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvmmlite.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvcameratools.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvwinsys.so: OK
/usr/lib/xorg/modules/extensions/libglx.so: OK
/usr/lib/xorg/modules/drivers/nvidia_drv.so: OK

Here is the problem, when i connect the display and do a reboot here where it got stuck, please advice on this

[ 5.437976] tegradc tegradc.1: Display dc.54240000 registered with id=0
[ 5.443181] display board info: id 0x0, fab 0x0
[ 5.448013] panel_select fail by _node_status
[ 5.451943] display board info: id 0x0, fab 0x0
[ 5.456665] panel_select fail by _node_status
[ 5.460700] parse_tmds_config: No tmds-config node
[ 5.465614] of_dc_parse_platform_data: could not find vrr-settings node
[ 5.472065] of_dc_parse_platform_data: could not find SD settings node
[ 5.478549] of_dc_parse_platform_data: could not find cmu node
[ 5.484481] of_dc_parse_platform_data: could not find cmu node for adobeRGB
[ 5.491324] tegradc tegradc.1: DT parsed successfully
[ 5.497520] display board info: id 0x0, fab 0x0
[ 5.501163] panel_select fail by _node_status
[ 5.505506] gpio wake53 for gpio=225
[ 5.535228] V_FRONT_PORCH < (V_REF_TO_SYNC + 1)
[ 5.537783] tegradc tegradc.1: Display timing doesn’t meet restrictions.
[ 5.545569] tegradc tegradc.1: probed

Up until the very end of that log it looks normal. The part about display timing doesn’t meet restrictions makes this look very much like the R23.1 bug not working with older monitors. This should have been fixed in R23.2. When you flashed, did you use the new R23.2? If not, can you try R23.2?

flashed with 23.2 same results… stuck at same place…
now what should i try?

I think there is a kernel bug, explained further down.

First, is there file “/var/log/X.0.log”? Can you post this?

Second, test EDID response (you may need to install packages “read-edid” and “edid-decode”). This may get complicated, as there is possibly a kernel bug and/or simply a bad monitor EDID format…how this changes things depends on which part of the software is using the data. These commands should work, but may have some subtle failures instead:

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

A typical fail response from get-edid would mention EDID is not found on all bus numbers (one and only 1 bus should have EDID if you have a single monitor)…i.e., a statement of no EDID on bus N, or actual EDID on a bus where EDID is found. In the case of a bus where get-edid is unsure, a potential bus would be mentioned, but no EDID parsing into a nicely formattable output. For you, does any bus show an EDID data set?

In the case of no bus found with EDID, you’ll likely see a message about possibly using different arguments or sending an email to the maintainer. In most cases this would just mean an update is required to get-edid for some quirk in the monitor’s data response. However, I think there is more going on than this due to my own testing. What follows is a description of where I think the process has something more going on.

Just by coincidence, I had a text console going directly on JTX1. My monitor works just fine on the JTX1 in graphical mode, but I left it on a regular console (not serial) simply because I was double-checking that this worked (the same monitor has always worked and provided good EDID testing on JTK1…the monitor’s response is a known good EDID source…we don’t know yet if your monitor is a good EDID source or not). My ssh login from my development host is more convenient though, and I ran the get-edid program on my host screen with JTX1 having console on a separate monitor. The get-edid resulted in the “sorry nothing was successful” statement. At the same time a register dump showed up on the text console…not a full kernel OOPS, but there should not be a register dump if the only issue is EDID format from the monitor…this has to be a kernel level issue.

The register dump:

650.442693] tegra-i2c 7000d100.i2c: --- register dump for debugging ----
[  650.449580] tegra-i2c 7000d100.i2c: I2C_CNFG - 0x22c00
[  650.455062] tegra-i2c 7000d100.i2c: I2C_PACKET_TRANSFER_STATUS - 0x10001
[  650.462207] tegra-i2c 7000d100.i2c: I2C_FIFO_CONTROL - 0xe0
[  650.467834] tegra-i2c 7000d100.i2c: I2C_FIFO_STATUS - 0x800040
[  650.473684] tegra-i2c 7000d100.i2c: I2C_INT_MASK - 0xed
[  650.478910] tegra-i2c 7000d100.i2c: I2C_INT_STATUS - 0x0
[  650.484245] tegra-i2c 7000d100.i2c: msg->len - 1
[  650.488860] tegra-i2c 7000d100.i2c: is_msg_write - 1
[  650.493835] tegra-i2c 7000d100.i2c: next_msg->len - 1
[  650.498881] tegra-i2c 7000d100.i2c: is_next_msg_write - 0
[  650.504289] tegra-i2c 7000d100.i2c: buf_remaining - 1
[  650.509358] tegra-i2c 7000d100.i2c: i2c transfer timed out, addr 0x0050, data 0x00
[  650.518573] tegra-vii2c 546c0000.i2c: no acknowledge from address 0x50

So here is the paradox and notes. Originally, R23.1 was not parsing older EDID/DDC data, and even graphical mode did not work until running the NVIDIA-INSTALLER item which puts nVidia-specific files in place. This made it very obvious to notice that during boot in console mode, prior to reaching graphical mode, that something is wrong with EDID handling…the console was constantly failed from scan rates too fast. The only way to run the NVIDIA-INSTALLER was either ssh or serial console. I had thought R23.2 fixed this, but I realize that initially on boot this same scan too fast occurs…console mode then works later after a short scan-too-fast message, but my R23.2 has the apply_binaries.sh step already done.

Without the EDID/DDC being readable, neither console mode nor graphical mode should work (unless the drivers conveniently default to a value which happens to be within the monitor’s capabilities). Once I reach graphical mode, things work correctly, yet get-edid causes a register dump and get-edid itself claims no EDID data. Different software on the system which depends on EDID data may each have their own implementation, so it is possible that although get-edid fails, some other software could succeed. However, this cannot be the complete case, as none of the software reading EDID should cause a register dump. The register dump comes from the kernel, so I suspect that once this is fixed get-edid and other software will start functioning correctly.