TX2 system is up but blanked monitor

Autonomous Machines Jetson & Embedded Systems Jetson TX2
, ,
1

Hi

I had ubuntu 20.04 installed on TX2 that i have to use in project and I decided to flash ubuntu 18.04. I have flashed the TX2 at least 15 times now (with SKDM and without it via ./flash.sh). I cannot access the TX2 via an HDMI connected monitor - nothing shows up. Whats more always when i power on TX2 two green lights are on like in recovery mode but it isn’t recovery mode. After flashing I can see device L4TREDME and info that connection failed.
On host I have ubuntu 18.04.6 LTS installed.

I often get this message when stuck on 99% of flashing in SDKM:
“Installation of ‘Flash Jetson TX2’ is taking longer than expected.
Do you want to continue installing this package?”

I think the board is not broken because it works a week ago.
So what I can do to install OS on my TX2?

[ 34.3742 ] Writing partition secondary_gpt with gpt_secondary_0_3.bin
[ 34.3747 ] […] 100%

[ 34.4241 ] Erasing sdmmc_user: 3 … [Done]
[ 35.8416 ] Writing partition master_boot_record with mbr_1_3.bin
[ 35.8421 ] […] 100%
[ 35.8462 ] Writing partition primary_gpt with gpt_primary_1_3.bin
[ 35.8477 ] […] 100%
[ 35.8521 ] Writing partition secondary_gpt with gpt_secondary_1_3.bin
[ 35.8597 ] […] 100%

[ 35.8713 ] Writing partition mb1 with mb1_prod.bin.encrypt
[ 35.8717 ] […] 100%
[ 35.8785 ] Writing partition mb1_b with mb1_prod.bin.encrypt
[ 35.8995 ] […] 100%
[ 35.9063 ] Writing partition spe-fw with spe_sigheader.bin.encrypt
[ 35.9291 ] […] 100%
[ 35.9358 ] Writing partition spe-fw_b with spe_sigheader.bin.encrypt
[ 35.9704 ] […] 100%
[ 35.9773 ] Writing partition mb2 with nvtboot_sigheader.bin.encrypt
[ 36.0083 ] […] 100%
[ 36.0158 ] Writing partition mb2_b with nvtboot_sigheader.bin.encrypt
[ 36.0556 ] […] 100%
[ 36.0631 ] Writing partition mts-preboot with preboot_d15_prod_cr_sigheader.bin.encrypt
[ 36.1075 ] […] 100%
[ 36.1138 ] Writing partition mts-preboot_b with preboot_d15_prod_cr_sigheader.bin.encrypt
[ 36.1650 ] […] 100%
[ 36.1716 ] Writing partition SMD with slot_metadata.bin
[ 36.2265 ] […] 100%
[ 36.2498 ] Writing partition SMD_b with slot_metadata.bin
[ 36.2558 ] […] 100%
[ 36.2600 ] Writing partition VER_b with emmc_bootblob_ver.txt
[ 36.2624 ] […] 100%
[ 36.2785 ] Writing partition VER with emmc_bootblob_ver.txt
[ 36.3283 ] […] 100%
[ 36.3326 ] Writing partition master_boot_record with mbr_1_3.bin
[ 36.3361 ] […] 100%
[ 36.3400 ] Writing partition APP with system.img
[ 36.3415 ] […] 100%
[ 307.6252 ] Writing partition mts-bootpack with mce_mts_d15_prod_cr_sigheader.bin.encrypt
[ 307.6727 ] […] 100%
[ 307.7688 ] Writing partition mts-bootpack_b with mce_mts_d15_prod_cr_sigheader.bin.encrypt
[ 307.7737 ] […] 100%
[ 307.8692 ] Writing partition cpu-bootloader with cboot_sigheader.bin.encrypt
[ 307.8741 ] […] 100%
[ 307.8875 ] Writing partition cpu-bootloader_b with cboot_sigheader.bin.encrypt
[ 307.8932 ] […] 100%
[ 307.9075 ] Writing partition bootloader-dtb with tegra186-quill-p3310-1000-c03-00-base_sigheader.dtb.encrypt
[ 307.9158 ] […] 100%
[ 307.9302 ] Writing partition bootloader-dtb_b with tegra186-quill-p3310-1000-c03-00-base_sigheader.dtb.encrypt
[ 307.9371 ] […] 100%
[ 307.9524 ] Writing partition secure-os with tos-trusty_sigheader.img.encrypt
[ 307.9591 ] […] 100%
[ 307.9745 ] Writing partition secure-os_b with tos-trusty_sigheader.img.encrypt
[ 307.9822 ] […] 100%
[ 307.9981 ] Writing partition eks with eks_sigheader.img.encrypt
[ 308.0053 ] […] 100%
[ 308.0095 ] Writing partition adsp-fw with adsp-fw_sigheader.bin.encrypt
[ 308.0115 ] […] 100%
[ 308.0180 ] Writing partition adsp-fw_b with adsp-fw_sigheader.bin.encrypt
[ 308.0214 ] […] 100%
[ 308.0279 ] Writing partition bpmp-fw with bpmp_sigheader.bin.encrypt
[ 308.0314 ] […] 100%
[ 308.0500 ] Writing partition bpmp-fw_b with bpmp_sigheader.bin.encrypt
[ 308.0603 ] […] 100%
[ 308.0794 ] Writing partition bpmp-fw-dtb with tegra186-a02-bpmp-quill-p3310-1000-c04-00-te770d-ucm2_sigheader.dtb.encrypt
[ 308.0893 ] […] 100%
[ 308.1103 ] Writing partition bpmp-fw-dtb_b with tegra186-a02-bpmp-quill-p3310-1000-c04-00-te770d-ucm2_sigheader.dtb.encrypt
[ 308.1201 ] […] 100%
[ 308.1406 ] Writing partition sce-fw with camera-rtcpu-sce_sigheader.img.encrypt
[ 308.1502 ] […] 100%
[ 308.1582 ] Writing partition sce-fw_b with camera-rtcpu-sce_sigheader.img.encrypt
[ 308.1621 ] […] 100%
[ 308.1697 ] Writing partition sc7 with warmboot_wbheader.bin.encrypt
[ 308.1734 ] […] 100%
[ 308.1780 ] Writing partition sc7_b with warmboot_wbheader.bin.encrypt
[ 308.1804 ] […] 100%
[ 308.1852 ] Writing partition BMP with bmp.blob
[ 308.1890 ] […] 100%
[ 308.2132 ] Writing partition BMP_b with bmp.blob
[ 308.2171 ] […] 100%
[ 308.2253 ] Writing partition recovery with recovery_sigheader.img.encrypt
[ 308.2298 ] […] 100%
[ 310.2314 ] Writing partition recovery-dtb with tegra186-quill-p3310-1000-c03-00-base.dtb_sigheader.rec.encrypt
[ 310.2368 ] […] 100%
[ 310.2511 ] Writing partition kernel-bootctrl with kernel_bootctrl.bin
[ 310.2574 ] […] 100%
[ 310.2784 ] Writing partition kernel-bootctrl_b with kernel_bootctrl.bin
[ 310.2802 ] […] 100%
[ 310.2855 ] Writing partition kernel with boot_sigheader.img.encrypt
[ 310.2871 ] […] 100%
[ 310.3091 ] Writing partition kernel_b with boot_sigheader.img.encrypt
[ 310.3189 ] […] 100%
[ 310.3405 ] Writing partition kernel-dtb with kernel_tegra186-quill-p3310-1000-c03-00-base_sigheader.dtb.encrypt
[ 310.3522 ] […] 100%
[ 310.3664 ] Writing partition kernel-dtb_b with kernel_tegra186-quill-p3310-1000-c03-00-base_sigheader.dtb.encrypt
[ 310.3733 ] […] 100%
[ 310.3940 ]
[ 310.3962 ] tegradevflash_v2 --write BCT br_bct_BR.bct
[ 310.3973 ] Bootloader version 01.00.0000
[ 310.3991 ] Writing partition BCT with br_bct_BR.bct
[ 310.3993 ] […] 100%
[ 310.4580 ]
[ 310.4617 ] tegradevflash_v2 --write MB1_BCT mb1_cold_boot_bct_MB1_sigheader.bct.encrypt
[ 310.4632 ] Bootloader version 01.00.0000
[ 310.4652 ] Writing partition MB1_BCT with mb1_cold_boot_bct_MB1_sigheader.bct.encrypt
[ 310.4659 ] […] 100%
[ 310.5325 ]
[ 310.5353 ] tegradevflash_v2 --write MB1_BCT_b mb1_cold_boot_bct_MB1_sigheader.bct.encrypt
[ 310.5364 ] Bootloader version 01.00.0000
[ 310.5381 ] Writing partition MB1_BCT_b with mb1_cold_boot_bct_MB1_sigheader.bct.encrypt
[ 310.5386 ] […] 100%
[ 310.5949 ]
[ 310.5950 ] Flashing completed

[ 310.5950 ] Coldbooting the device
[ 310.5978 ] tegradevflash_v2 --reboot coldboot
[ 310.5990 ] Bootloader version 01.00.0000
[ 310.6055 ]
*** The target t186ref has been flashed successfully. ***
Reset the board to boot from internal eMMC.

Thanks Daniel

2

The definition of booting should be the linux OS is up or not.

For your case, I think the topic should be more precise with description “system is up but blanked monitor”.

Please use the uart console to check the board status.

3

BTW, I am curious about this comment. How did you install ubuntu 20.04 on your TX2 before?

4

It is not my TX2, it is from the project. I got it with ubuntu 20.04 and no root password.

5

20.04 is not yet out for Jetsons. Perhaps it is a developer preview? Do you see file “/etc/nv_tegra_release”? If so, what is the output of “head -n 1 /etc/nv_tegra_release”?

6

R32 (release), REVISION: 2.0, GCID: 15966166, BOARD: t186ref, EABI: aarch64, DATE: Wed Jul 17 00:26:04 UTC 2019

7

HI,

Rel-32.2 is a old release that release for like 2 years ago. Please move to new release if possible.

8

Incidentally, your R32.2 release (quite old as mentioned by @WayneWWW) would have loaded Ubuntu 18.04 onto your Jetson. If 20.04 is somehow involved, then it is on the host PC. If for some reason you managed to run a host upgrade which migrated from 18.04 to 20.04, then the Jetson would be essentially rendered unusable until flashing again.

9

I had to bought cable to do that so it took some time. But i have logs now:
log.txt (29.9 KB)
I can’t find the exact solution to last line.

10

Hi,

I am not sure if you are aware that when you firstly flash the board, it requires you to configure the system. The uart log would not go ahead to print the rest of logs unless you finish this configuration.

That is why the last line in the serial console is

[ 6.576380] Please complete system configuration setup on /dev/ttyGS0 to pro.

There are two methods. First one is using the monitor connected on the board. However, you said there is nothing on it.

Thus, you can only use the headless method. Connect the host to the flash port with the flash usb cable.

Check if you have a /dev/ttyACM0 node shows up on your host. If there is, use some serial console tool to open it with baud rate 115200. It shall give you a prompt to configure the system.

11

I see the /dev/ttyACM0.
I tried to use “sudo screen /dev/ttyACM0 115200” but then the console is empty and I don’t see anything.
What should I do now?

12

I’m not sure if screen was intended to be used this, way (although it certainly has the ability). Most people would use “minicom”. It starts something like this (I’m using long format options for clarity):
sudo minicom --baudrate 115200 --8bit --device /dev/ttyACM0
(there are other settings for “no parity”, but not sure of doing that on command line…once in minicom you could set that)

My favorite is “gtkterm”. If you don’t have this you can run the command “sudo apt-get install gtkterm”. This would start something like this:
sudo gtkterm -b 8 -t 1 -s 115200 -p /dev/ttyACM0
(inside the GUI you could then “save configuration”)

One reason to use minicom over gtkterm is that minicom works in a non-graphical environment, but gtkterm only runs in a graphical environment.

Do start this up prior to powering up the Jetson if you can. Assuming the Jetson is started normally you can hit the enter key a couple of times to see if anything shows up.

Btw, if you add your user to the group “dialout”, then you won’t need to use “sudo”. If your user name is “nvidia”, then you could add user “nvidia” to dialout like this (performed on the host PC):
sudo usermod -aG dialout nvidia

13

Thanks, it worked. I don’t try “ gtkterm ”.
But I have another problem. I configure setup and now I connected via ssh. Still monitor is blank and pan is not working.
Any idea what to do next?

14

Whats more I noticed when I was configuring setup I had only 3 option in nvpmodel and none of then had “desktop” in their name. Maybe there is a problem.

15

Hi,

I think you misunderstood something. The point for what we have done so far is not to make your monitor work.

It is just to make you enter the system and make you able to dump the log so that we can check why the monitor is not working…

Since you are able to ssh to it now, please share the dmesg and /var/log/Xorg.0.log.

Please be aware that when dumping those logs, you should have monitor connected.

16

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.