- Host enviroment PC Intel ubuntu 18.04 LTS
- jetson tx2 developer kit tx2 p3310-1000
There is no way I can restore my jetson TX2 to factory condition. In another topic you advised me to use the flash.sh system.
The test I did consists in putting the tx2 in recovery mode using the buttons, (the system via the terminal forced command, it no longer runs it gives me an error).
I launched the flash.sh command using the file I find in the Tegra folder.
I positioned myself inside it with the terminal and then I started the file according to this command “sudo ./flash.sh jetson-tx2 mmcblk0p1” the system starts but immediately freezes and gives me an error “system is not in recovery”, but the thing does not correspond to the truth in fact by trying several times to start the flash.sh command and inserting the usb cable between host and tx2 a moment before the system starts and begins to try to flash the system, but a few seconds later it stops saying that the “CPU boot is not started” and I stop them.
I don’t know how this type of installation works for these cards both SDK manager and via flash.sh, but I see it very unstable and unreliable I am not a programmer, but I have installed windows, ubuntu, linux, macos systems, on different types of raspberry pc ect. , but one thing had never happened to me and to see many complain about recovery factory problems over all this tx2 developer kit is practically new even if it has been in a closet for over a year and besides everything worked fine but for reasons not understandable to me. ros commands and no longer recognizes the catkin_make command and can’t reinstall them anymore. Kindly help.
terminale message.txt (21.5 KB)
I am guessing that everything is correct up to and including going into recovery mode (the log would not have got as far as it did if initial setup was not correct). At this point it looks like hardware failure, but what it doesn’t define is whether it was the Jetson which failed or if it is the USB system connecting it. Is this dev kit using the micro-B USB cable provided with the TX2 dev kit, and is it using the supplied power supply (I am assuming this is the full TX2 kit and the smaller NX kit)?
If this does not use the supplied USB cable, then this is a rather common failure point…most “charger” cables are not of sufficient quality to work for extended data transfers. If this is the supplied cable, then the only suggestion would be to try a different USB port on the host PC, or better yet, try flashing from a different computer to see if USB itself is the issue. Barring that, then you might have an actual hardware failure since it seems your steps were correct.
thanks for the quick reply, I would like to clarify that both the power supply and the usb cable are the original ones supplied with the kit, the host pc where I installed ubuntu 18.4 LTS is the same one used last year, but I could try with a pc different, I could use my desktop, even if I don’t want to install a dual boot on a windows pc, however I will also try this way.
Or you can use the windows wsl2 ubuntu in win10?
even if it doesn’t have the graphical interface ?.
Is there any way to check if any hardware is faulty?
Can I do tests from tx2 as it boots perfectly?
- Since the flash process is already in below, I think you already put the board into recovery mode. Just due to some unknown reason, it fails.
[ 1.9940 ] tegrarcm_v2 --chip 0x18 0 --rcm rcm_list_signed.xml
[ 1.9958 ] BootRom is not running
[ 7.1855 ]
[ 8.1911 ] tegrarcm_v2 --isapplet
[ 1020.1773 ]
[ 1020.1818 ] tegradevflash_v2 --iscpubl
[ 1020.1831 ] CPU Bootloader is not running on device.
- Could you follow this method to dump two serial log from your device? First log is from the boot process since your board is still able to boot. The second one is the one when flash process gets stuck.
I have already used this method with Manicom by connecting via serial to check what happens when tx2 is running, according to your advice I could launch the flash procedure with host and through the same host connected via Manicom monitor what happens to see the cause? But what should I analyze? if I do, can I send you the result in a txt file in the topic? So we can understand if there is any problem?
Yes, sending me the log will provide more information than only with your description.
Send one normal boot log and another one with flash log.
Serial console logs, both from Jetson boot and from Jetson flash, can be quite useful to post on the forum thread. These logs would be the method of checking if perhaps hardware is faulty.
A fully booted Jetson won’t tell you much about flash or recovery mode errors, for that you’d have to have both the flash log and the Jetson serial console log during flash. An example flash with logging:
sudo ./flash.sh jetson-tx2 mmcblk0p1 2>&1 | tee log_flash.txt
(and you’d have serial console logging what happens when that command runs, which would be the second log)
Regarding using Windows to flash, WSL2 lacks necessary kernel abilities to flash. For example, WSL2 cannot perform loopback mounting, which requires more than a user space emulation. You’ll need a real Linux system to flash. You can indeed flash from command line though, you don’t need a GUI.
this that I am attaching below is the message that arrives from TX2 to host connected via serial uart and Minicom software, when starting tx2. While when I put the tx2 in recovery mode and start the flash procedure, nothing comes from the UART connection. (file minicom ) + (file flash with logging )
log_flash.txtexit (38 Bytes)
Minicom -Tx2-tohost-log (37.3 KB)
Let me clarify one thing, the second fi is generated with the flash procedure as Linuxdev advised me, because from the UART in recovery mode, as I have already explained, nothing comes out
Hi,
What is that “log_flash.txtexit” log…??? This file has no info.
when I connect the UART with host and the tx2 is in recovery mode Minicom with message nothing remains empty if instead I start tx2 normally it starts to write that file that I have attached called Minicom log, I hope to be clear
After you connect the UART and TX2 is in recovery mode, run the flash command. If the host side didn’t say “this board is not in recovery mode”, then it shall have log from the uart.
So you should clarify whether the host side told that or not .
As for this, please use command “dmesg” to dump the kernel log and share it too.
this is the message it sends after starting the flash procedure and as you can see in the other image you can see that the tx2 card is connected, how can I understand if it is in recovery mode I only see Nvidia Corporation …, certainly it is not started normally . Nothing comes from minicom in this condition, but only if I start tx2 normally. I ask you a question is the minicom uart port that communicates with minicom when tx2 is in recovery mode always ttyUSB0? or is it called something else?
If the board is in recovery mode, then your uart console will not give your any response. I mean if you type some command to your board, it shall not give you any feedback
I want to see the uart log when your host side gets stuck in this. Hope this will clarify the purpose here.
at the moment I am connected with the original tx2 usb cable to the card and with another cable and ttl adapter to the uart gpio always of the tx2. What command can I send from minicom to check if it responds or not?
For example, when you dump the log " Minicom -Tx2-tohost-log" to me, you can use the minicom to operate with your board… that is why I said dump “dmesg” to me. dmesg will dump the kernel log.
we did not understand each other when I put the tx2 in recovery mode and connect the usb, when I start the flash procedure it does not always start regularly, but it gives me that message that I have attached as an image:
sudo ./flash.sh jetson-tx2 mmcblk0p1
##################################################################################################### ##############################
L4T BSP Information:
R32, REVISION: 6.1
##################################################################################################### ##############################
Error: probing the target board failed.
Make sure the target board is connected through
USB port and is in recovery mode.
Only by removing and putting the usb several times and restarting the flash command sometimes the procedure starts and starts and then it stops until writing:
[1.9940] tegrarcm_v2 --chip 0x18 0 --rcm rcm_list_signed.xml
[1.9958] BootRom is not running
[7.1855]
[8.1911] tegrarcm_v2 --isapplet
[1020.1773]
[1020.1818] tegradevflash_v2 --iscpubl
[1020.1831] CPU Bootloader is not running on device.
I do not quite understand your English here. Sorry about that.
Are you saying that “sometimes” you will see the log “[1020.1831] CPU Bootloader is not running on device.” but not “always”?