TX1 not booting after complete power cycle.

Hello,

I have an older TX1 module that I’m using with the Jetson Carrier Board, that I have been using for a while.

Recently after I reflashed it with Jetpack 3.3 (L4T 28.2), I see a very peculiar behavior.

I have a Serial-USB cable connected to the serial console (on J21).

Immediately after the flashing is complete, the board reboots and I see the booting messages on the serial console and end up being dropped into the console. (nvidia@tegra-ubuntu:~$ )

At this point, I can use the TX1 as usual. If I reboot the TX1 at this point sudo reboot -h now it reboots and works normally.

However, if I power down the module sudo shutdown -h now and then restart using the Power Button, nothing happens. The LEDs on the carrier board turn on, but there’s nothing on the serial console.

Am I missing something?

You’ll want to verify the host didn’t run out of space since a truncated image can do something similar:

df -H -T /where/ever/your/host/JetPack/is/Linux_for_Tegra/

Verify the Jetson thinks its key driver files are in place:

sha1sum -c /etc/nv_tegra_release

I assume “sudo” is working since it works on reboot.

In the case where serial console drops in to a prompt can you post a log?

Which release is this (see “head -n 1 /etc/nv_tegra_release”)?

Is it correct that this is using the original power supply for the dev kit? I wouldn’t expect software from a flash to have any effect on whether a cold boot fails to begin booting, but a power supply definitely can. If you have a second power supply to swap out as a test, please test that as well for the power on issue…if there were a power issue during a flash this could have had an effect on how the unit boots when it does succeed to boot.

Thanks @linuxdev

The host shouldn’t be an issue. Lots of space and it’s a native Ubuntu 16.04 running on a HP desktop.

○ df -H -T Linux_for_Tegra
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda7      ext4  1.7T   42G  1.6T   3% /home

sudo is working. In fact, right after reboot, I was able to do apt-get, install packages and use it. No problem.

I’ve attached the serial console log during flashing and booting…

The shasums look good.

sha1sum -c /etc/nv_tegra_release
/usr/lib/xorg/modules/drivers/nvidia_drv.so: OK
/usr/lib/xorg/modules/extensions/libglx.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libargus_socketserver.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmedia.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvfnetstoredefog.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvdc.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libtegrav4l2.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmmlite_video.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmm_contentpipe.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmm.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnveglstreamproducer.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libargus_socketclient.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvtvmr.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libglx.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmm_parser.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvfnet.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvwinsys.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvomxilclient.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvddk_vic.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmmlite_utils.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvodm_imager.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvcolorutil.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libscf.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvrm_graphics.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmm_utils.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvcamerautils.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvparser.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvimp.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvos.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvddk_2d_v2.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmmlite_image.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnveglstream_camconsumer.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvfnetstorehdfx.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvtx_helper.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvexif.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvcamlog.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvtnr.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvrm.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvosd.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvjpeg.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvtestresults.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvavp.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libargus.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvcam_imageencoder.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvapputil.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvll.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvcameratools.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvomx.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmmlite.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvrm_gpu.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvidia-egl-wayland.so: OK
/usr/lib/aarch64-linux-gnu/libv4l/plugins/libv4l2_nvvideocodec.so: OK
/usr/lib/aarch64-linux-gnu/libv4l/plugins/libv4l2_nvvidconv.so: OK

And the release is

head -n 1 /etc/nv_tegra_release
# R28 (release), REVISION: 2.0, GCID: 10567845, BOARD: t210ref, EABI: aarch64, DATE: Fri Mar  2 04:58:16 UTC 2018

tx1-boot.txt (91.7 KB)

Also here’s the console log for a reboot.
tx1-reboot.txt (82.5 KB)

The power supply is definitely the one that came with the Jetson Carrier board. Just for completeness I also tried using a Lab power supply and it has the same behaviour.

The actual console messages seem normal. It also looks like the basic install is correct. Between the other power supply and the provided power supply doing the same thing I’d have to say most likely it is a hardware error, but since something could have gone wrong during a flash I’d say to flash again.

It sounds like you’ve used this module on other carriers, so one thing I’d suggest is to look closely to see if it is mounted correctly and that there is no pin damage.

I also see that it still needs a lot of updates:

697 packages can be updated.
404 updates are security updates.

You might try doing those updates in case it is a software issue. Before you update note the location of two libglx.so files in “/etc/nv_tegra_release”:

grep libglx.so /etc/nv_tegra_release

You should see “/usr/lib/xorg/modules/extensions/libglx.so” and “/usr/lib/aarch64-linux-gnu/tegra/libglx.so”. If the command “sha1sum -c /etc/nv_tegra_release” shows the xorg version as bad after the update, then just copy the tegra version over this. These libglx.so files are exact matches…some rare updates might accidentally overwrite the xorg version. When that happens the GUI will fail, but console won’t be affected.

Package updates take a very long time and I’d actually suggest re-flashing first. I doubt updates will help, but consider that the update process is often set up to start automatically ("unattended upgrades) each boot and the update process itself might be hitting a snag. Once this is already updated you’ll know automatic update isn’t going to run for an hour after each reboot. If it still fails, then I think you have a partial hardware failure.

Hello,

I have indeed used this module on our custom carrier boards. But this specific module was used 90% of the time with a Jetson Carrier Board (it’s our build server). It was working fine on an older L4T till a few weeks ago. I was just reflashing it to update to the latest L4T.

I have tried doing a sudo apt-get update && sudo apt-get upgrade when it does boot. Doesn’t help.

But it’s hard to think that it’s an OS level issue. I should at least see some output from TegraBoot when I press the Power On button. I don’t see ANYTHING the serial console.

I have to agree it is probably hardware, but wanted to be sure nothing else was possible. The early boot stages do depend somewhat on software from the flash, although not to the degree the newer systems do.

Other than perhaps flashing with a fresh host side install (in case maybe something was corrupt or mismatched in the “Linux_for_Tegra/” directory there isn’t much left to try. Even for that the issue is more likely hardware because I would expect a corrupt boot-related flash source would cause failure to boot every single time.