Hi
I received the new Jetson TX2 Development Kit and as the Starter Guide mentioned I tried to flash the newest Jetpack.
The first problem was or still is, that its really random when the Host PC recognizing the Jetson TX2 in recovery mode.
However when I once manage it to flash, the log shows after a while that the boot rom is not running and the flashing takes forever.
I tested this with tow diffrent Hosts with Ubuntu 18.04LTS installt and with the SDK Manager as well manually over the shell.
Both procedures didn’t worked.
Does anyone have an Idea where the problem is?
sdkm.log (1.9 MB)
Hi,
You should at least share some logs or we cannot help you.
To debug flash error
- Please share flash log on host.
- Please share the uart log from device during the flash.
Oka so I loaded the SDK Manager log in to my first post. Sadly I don’t know how to get the uart log while flashing
Thanks for the link. I managed to get a UART Interface communication running. But during the flash process there is no communication going on.
This is what I get when I put the Jetson TX2 into recoveryMode
recoveryMode.log (19.8 KB)
What you see is the boot environment, and then it stops at the interactive prompt option. This particular log is ok, and I suspect that some stray keystroke (probably through minicom) is stopping things via the serial port. Try using gtkterm instead (historically, minicom was designed for modems which are also serial devices, but minicom has macros for sending modem init strings, and you want to avoid that).
On your host PC I don’t know which serial device is your serial UART cable, but I’ll assume it is ttyUSB0 (adjust for your case). To install and then run gtkterm:
sudo apt-get install gtkterm
gtkterm -b 8 -t 1 -s 115200 -p /dev/ttyUSB0
If your PC user is not a member of dialout, then you’d also need sudo on the gtkterm line.
Gtkterm does have logging options. If you do not have any stray keyboard activity detected, and the log still stops at the same spot, then it isn’t a serial terminal causing the stop. This too would be good debug information.
I am not very sure about your log. Your log looks like a normal boot log but stuck in u-boot.
When you press the button to put device into recovery mode, uart log should have nothing.
After your sdkmanager or flash script start to flash, UART would start to print out log and that is what we want to check.
The log would be alike to this user’s comment.
https://devtalk.nvidia.com/default/topic/1064450/jetson-tx2/deploying-with-l4t-flash-sh-breaks-on-my-carrier-board/post/5402230/#5402230
Well I feel like the device can’t enter recovery mode properly. One host cant recognize it anymore even though it gets listed with -lsusb as in recovery mode.
Even if I try to flash with the SdkManager with automatic. The jetson tx2 turn off an start in recovery Mode but can’t get recognized afterwards for flashing.
On the other Host it gets recognized and I’m able to flash, at least till it comes to the “Boot rom not running”
How the posted Uart log was made:
- Turned off Jetson TX2.
- Started minicom
- Pressed Powerbutton
- Pressed and Hold Recovery Button
- Pressed Reset Button
- Waited 2s
- Released Recovery Button
- Start flashing…
So the content of the uart log shows part of the startup process until it get in the recovery mode I guess.
As soon as the Recovery Button was released, there was no uart communication anymore.
What I also noticed is, when I plug in the powercord there is no LED shining.
When I push the power Button too short, only 2 or 3 red led flash up.
To start up the jetson I have to press the power button for at least 2-3s.
As I saw in various videos, when you plug in the powercord there is alway shining one red led.
I don’t konw if this diffrent behavior of my jetson helps or indicates an error but I thought it may help.
Edit:
@linuxdev I will try gtkterm and post what I get from it.
How the posted Uart log was made:
- Turned off Jetson TX2.
- Started minicom
- Pressed Powerbutton
- Pressed and Hold Recovery Button
- Pressed Reset Button
- Waited 2s
- Released Recovery Button
- Start flashing…
These steps look good to me. An alternative way can achieve recovery mode too.
- Pressed and Hold Recovery Button
- Pressed Powerbutton
- Waited 2s
- Released Power button
- Released Recovery Button
On the other Host it gets recognized and I’m able to flash at least till it comes to the “Boot rom not running”
Yes, but I believe even with such error on your host. The uart side should still spew some logs.
It is weird that it is totally empty during flash but able to dump boot log.
So I figured out how start the flashing process with the first Host. I have to put the Jetson TX2 in to recovery Mode and as soon as I plug the USB in to the Host computer, I have to start the flashing process really quick.
However it still stops at Boot rom not running.
@linuxdev:
I tried the gtkterm but its the same as with minicom. I get uart communication while startup, normal running and shutdown. But there is no communication while the Device is in recovery Mode or while the flashing process.
flash_log.log (286 KB)
That log is from a flash which did fail, but the flash went quite far before there was an error. Are you using the micro-B USB cable which comes with the development kit? Is there a VM involved anywhere? It sounds like no VM is involved, but I’d like to confirm.
If you are going through a USB HUB with other device on it, then you might switch to going directly to the Jetson without a HUB. If you are going directly to the PC, then you might try with a HUB (but no other device) between PC and Jetson.
Yes I use the cable which comes with the jetson.
The host computer is a dual boot with windows and linux (ubuntu 18.04 lts).
There is no hub involved but I’ll try next week with one.
Do you still see nothing from uart when running flash command?
Yes so I trird with a hub too and there is still nothing going on on the serial while flashing I guess this is a hardware defect
Is this the only TX2 devkit you have? Or you have any extra devices to try?
It would be better to verify the host setup on each devices.
No just one dev kit but I tried on two different hosts
ok then please file a RMA request to replace a new one :-)