Jetson TX2 is not reboot after flash

The red CR5 LED works, but not the green power light.

What happened when you press the power button? Also, do you have a UART debugger for log?

Absolutely nothing happens on pressing the power button. I also tried serial console using UART debugger, but again no output.

rakshuagarwal,

How about reflash with jetpack? Does recovery + power button have effect?

Hi,
the recovery + power button has no effect. Also while reflashing the jetpack forced USB recovery is not possible.

Do you have only one module and carrier board? Can you move your module to another carrier board and check if problem is from module?

Hi,

No I do not have another carrier board. Could you please send me the contact of any support in India?

Also, are there any bugs with this tutorial?

I tried the steps as mentioned in the tutorial.

You could also follow the RMA steps.

  1. Go to NVIDIA Customer Support
  2. Select “Live Chat” from the options near the top of the page.
  3. Enter your personal information.
  4. Select the appropriate product from the drop-down list (“Tegra” in this case).
  5. Submit the request.

btw, what did you flash when device is still alive?

FYI, the tutorial is valid. Other than hardware failure, about the only thing which would stop a Jetson from reaching recovery mode is an invalid USB cable. If not using the USB cable which came with the kit I’d be very suspicious of this.

After the msg of wait 30 seconds to make sure that the the system is fully up
The tx2 did not reboot but the setup continue and it is taking tooo long time till now what should i do

You can always reboot the Jetson and see if flash worked…perhaps it is just the extra package install failing. Check if your router sees an address request…if so ping that address…if that works ssh in.

After finishing the installation a msg said " clock skew detected your build may be incomplete but the installation complete msg appear

This is an indication that some new files have a timestamp in the future. If the clock on the system was not set up (typically setup is via NTP over the internet), then this is likely to happen. If for example the clock were correct and you wrote files, and then on a later reboot the clock reverted to the year 1970, then the actual correct date files would appear to be time travelers. The first thing to do is to check if the “date” command shows the current date as correct or not (or from output of “timedatectl” which is more comprehensive information).

If not, then perhaps your networking is not accessing the internet. In terms of setting up NTP here is a useful URL:
https://help.ubuntu.com/community/UbuntuTime

If you have your clock correct and want to deal with files in the future you can use “touch” to set the file to “now”. This works recursively as well, but be careful to not “touch” files you don’t want changed. Code for build with a Makefile is a typical place where clock skew gets in the way, so if for example you had downloaded kernel source to “/usr/local/src/kernel”, then you could do any of these to correct skew there (to emphasize, your clock must be correct before doing this…and if the clock is correct, perhaps the clock will no longer call the timestamps skewed):

touch `find /usr/local/src/kernel -print`
find /usr/local/src/kernel -exec touch {} +